Copyright (C)2001, Daniel L. Johnson, MD

I. Introduction

We in the health care industry, both software vendors and institutions, need to share code that meets common needs, and work together to develop it. We are wasting precious resources competing with duplicated effort. To share development of code that meets shared needs will spread R & D across the whole industry, and enhance useful competition to meet the individual needs of customers and to provide highest quality service.

We already have a model for this in our sharing of research and medical discovery. This sharing of knowledge does not hinder competition, and allows greater attention to excellence and service. We can best meet our responsibility to society by sharing development of our software tools in the same way we share discovery of medical advances.

Collaborative software development -- "open-source" development -- is a powerful technique of shared knowledge and research to meet common need. It can allow our health care industry, now beleaguered with complex data processing demands on top of which has been added HIPAA mandates, to work together to meet our shared needs. Many understand this concept, but few understand that collaborative development is not hostile to commercial development -- it's only hostile to monopoly. And many understand the benefit of shared work, but we lack a core of health care institutions who see this vision and understand how to manage it. The GNU/Linux Open Source (Free Software / Software Libre) community has successfully developed techniques for collaborative development which the health care community cannot afford to ignore. The GNU/Linux community provides a functional model for us; our academic roots provide a heuristic model. There are opportunities for cost saving from open source tools "on the desktop," in the IT substructure, and among our peers.

Table of Contents

1. Introduction
2. What is Open Source?
1. Possible Benefits.
2. Freedom of Ideas.
3. Misconceptions about Free / Open Software.
4. A Brief History of Open Source.
5. The Moral Basis of Free Software/Open Source.
6. Academic Freedom and Capitalist Opportunity.
3. Areas for Evaluation.
1. Collaborative Development.
1. Pragmatism.
2. Leadership.
3. Programming standards and Practices.
1. Structured use of code.
2. Programming best practices.
3. Documentation.
4. Strategy.
5. Productization.
2. Office Applications.
• Office suites for Linux.
3. Infrastructure.
4. Opportunities.
1. Vendor relations.
2. Support of free operating systems and platforms.
3. Participation in collaborative development.
4. Licensing concerns.
5. Benefits.
5. Current Open Source Medical Software Projects
6. Summary of Intent.
7. Recommendations for Action.
8. Author

II. What is Open Source?

II. A. Possible Benefits.

If each health care institution in a consortium were to tax itself 2% of its IT budget to fund participation in collaborative software development with its peer institutions, we could begin getting some serious work done to meet the vast mutual needs in our industry. This is not to propose another HL-7 effort; this is a proposal that we actually write working software, beginning with a relatively simple project such as a Master Patient Index with a generic infrastructure such as Minoru's Circare project, or design a system to do document imaging with .pdf files as output, using no proprietary systems.

It is important to note that the software vendors serving health care institutions belong to this community; only we must help them understand how open source works: that it does not mean giving up all proprietary code, but that essential code which meets foundational needs is best developed and owned by the community -- institutions and vendors together; and that the customizations and enhancements of code that provide quality IT service to customers need not be community owned. Vendors who understand and accept this model can function and prosper within this community.

There are three potential benefits to using open source software:

Medical enterprises are likely to experience significant abatement of software costs in both the short and long run, and institutions that cooperate together to share efforts in meeting needs for security and data infrastructure and exchange will be able to gain efficiencies.

Medical enterprises will be better able to control their responsibilities for security of their intranets and confidential data, especially in view of HIPAA requirements.

Academic freedom is a fundamental value of the medical tradition and enterprise. We have a tradition of sharing knowledge with the community which benefits the community; to do otherwise would be to withdraw intellectually from it. (Return to Table of Contents.)

II. B. Freedom of Ideas; academic freedom.

In fact, publication itself is a late development. Gutenberg's invention of the printing press was not done in order to make mass publication possible. The motive and the first use was simply to reduce the production cost of illuminated manuscripts, to sell these for the (very high) going rate, and make a large profit. Mass communication became possible only with inexpensive methods of typesetting, paper production, and printing -- and with the discovery that a mass market might indeed exist -- a nineteenth-century phenomenon.

Today we doctors, particularly surgeons, still put energy and political sophistication into justifying and protecting our high fees and comfortable incomes. But this is no longer done through entrepreneurial promotion of medical secrets; it is done by maintaining competence and special expertise in areas of highly complex public knowledge and providing service of extremely high quality, and we justify our compensation by pointing to the societal benefit.

In fact today, if a health practitioner claims to have special, secret knowledge, this is assumed to be quackery, as if the claimant has something to hide -- until it is published and subjected to the rigors of scientific validation. The "doctor" who practices strictly entrepreneurial medicine using "peculiar" knowledge is viewed contemptuously by colleagues, and is in reality acting immorally based on the standards (social norms) of the medical community using the cross-cultural definition of "morality" offered below.

This is exactly the transformation that free software, particularly GNU/Linux, is fostering. Software is becoming a community asset, and community ownership is becoming a moral standard. In this regard, it is also important to realize that in this community are many intersecting communities, it is not a monolithic one. Only those who have a common need form a particular community. For example, the high school hacker is not part of the health care community and has no interest in our software; we would release it to each other and allied workers, but not to everyone.

Why is this dissemination of knowledge and software happening? Because there is unequivocal community benefit.

The justification for academic freedom is ultimately that common knowledge benefits society -- "community" in the broadest sense.

The reason that medical knowledge has become public property is that there have been successive revolutions in knowledge of anatomy, surgical technique, anesthesia, bacteriology, antibiotics, physiology, pharmacology, and now immunology and molecular genetics which have transformed medical care from shamanism to reliability. To share this knowledge benefits mankind -- "community." And the reason that operating systems and basic tools are coming under the rubric of academic freedom -- the underlying significance of "free software" -- is that computers are becoming a ubiquitous and essential tool of society. (Return to Table of Contents.)

II. C. Misconceptions about Free / Open Software.

Some believe that Open Source means that internal computer systems, files, or proprietary information are somehow accessible to hackers, or must be released to the general public. This is not at all true; in fact, the open source community has a deep and abiding interest in security and confidentiality, and some of the best algorithms and procedures for maintaining security are to be found here.

Some believe that all F/O software must be released to the general public. This is not true. F/O code must be released to the users of the compiled programs derived from it. It is not necessary to expose free code to the general public; this is sometimes inappropriate or counterproductive.

Some believe that making code publicly available is a security risk. This is true only if you make specific implementations public, something that isn't needed, and is about as logical as making your passwords and private encryption codes public. In reality, making the tool public increases the likelihood that security holes will be identified and subsequently fixed.

Some believe that if you use any F/O software in a product, that all your code must be freely released. This is not true. The GPL (GNU Public License -- see the discussion of copyleft or the text of the GPL), which requires only that you release your own derivations of F/O code, not that code be opened just because it uses F/O tools.

Some claim that F/O software is unreliable and unsupported. This has never been true; unreliable software exists, but the community is quite careful to differentiate alpha and beta software from stable versions; support has always been available freely within the Linux community, and for the last five years, excellent commercial support has been available. If one takes the time to investigate and compare, the Linux OS and related packages will be found to have the soundest design, the most readable code, and the best reliability when compared with other options.

There may be reasons why an institution may not choose to employ free and open software, but these misconceptions are not those reasons. Some companies have used Linux commercially for years. For example, The Weather Channel runs entirely on Red Hat Linux.

In a recent review of misconceptions about open source development Brian Behlendorf, founder and chief technology officer of CollabNet and co-founder and president of The Apache Software Foundation, notes, "What the open-source community has proven is that individuals--and, by extension, companies--can work together on a much more discrete, iterative level." (Return to Table of Contents.)

II. D. A Brief History of Open Source.

The FSF had already begun an OS project, but this had bogged down due to hardware limitations and its own complexity. Into this vacuum, Linus Torvalds in 1991 posted his preliminary work on making a UNIX-compatible OS for Intel processors. This project was sufficiently simple and its goals quite clear; and the felt need was very great, so that it attracted the interest of many skilled programmers around the world.

It is important to realize that Linux was initially a success: it immediately was a useful teaching tool and its development quickly liberated academicians from the vendor lock that had paralyzed them for a quarter-century. These developments are more important to the rapid progress of software and connectivity than is its subsequent commercial success, as free access by programmers to code and basic tools makes them significantly more efficient and more effective.

A by-product of this success has been a controversy over the meaning of "free" and the development of an interesting variety of points of view on what restrictions are or are not important for the continued development of such software. The controversy ends up, of course, with some disagreement over whether there is some code that must be or should be confidential and proprietary in order to ensure the viability and reliability of businesses that develop it and are expected to maintain it.

This controversy is unnecessary. As Torvalds and others who understand the community say, "It's about freedom, not free beer." That is, the goal is academic freedom, freedom of ideas, rather than philanthropy. It is understood that programmers need food, clothing and shelter. The open source advocates believe that income should be derived from service rather than royalties.

The underlying principle is: A tool that meets common needs belongs to the community; tools that meet individual needs belong to individuals. In this conception, the "community" is whatever group has a common need. The most efficient solution is for everyone having the need to participate in its solution, yielding a generalizable tool to which individuals can attach customizations as needed. It is grossly inefficient for everyone to create their own tools; and it is inefficient for an individual to create a tool for the community that is not generalizable.

For a more extended discussion, see the Free Software Foundation page and Eric S. Raymond's account of hacker history. To review more open-source material, visit Opensource.org. (Return to Table of Contents.)

II. E. The Moral Basis of Free Software/Open Source.

Although I have seen programmers deride the enthusiasms of f-s/o-s enthusiasts as "religious," this accusation is inaccurate, and the movement is not in any way a religion. (And, anyway, it's derogatory to all religions to describe emotional or behavioral incontinence as "religious.") The word "moral" is an important secular term to describe the fact that when we form groups and associations, we encourage and follow rules that define the group and that help the group produce benefit for all its members. Such rules are, in the most general sense, "moral" obligations, which are relative to the goals of the group. The social nature of mankind is such that group loyalties are strong, and the norms of any tightly-knit group may sometimes be enforced with "religious" zeal. The f-s/o-s movement was begun by people with strong convictions, and continues to attract some people with strong convictions about what it can and should be.

Hence, to understand the strength of the "free software"/"open source" community and the vigor of the debates over proper handling of free software, we must notice that these phenomena involve groups of people, not merely individuals. These groups did not form on the basis of economic need, but of educational and functional need. Economic use followed.

"Morality," at its kernel, is neither religious nor absolute. It is relative to the values of a particular community. Walther A. Schultz, a philosopher, presents in his book The Moral Conditions of Economic Efficiency a minimal definition of "morality" that is valid across Western and modern Eastern cultures: "Morality is a normative social practice, the purpose of which pertains to collective and individual well being, guided by beliefs held in common, concerning criteria by which to evaluate behavior, criteria for mutual responsibility, and procedures for mutual accountability."

That is, "morality" is the word we use to describe the behavioral standards or limits a group evolves to define itself, for the benefit of the group and the individuals in it. The well being of the individual does not necessarily conflict with group well-being, but when they do conflict, the balance is tipped somewhat in favor of the well being of the group as long as the individual is not harmed. (Back to quackery.)

We humans are social animals; we--that is, our self-concept and our public identity--are significantly defined by the groups we belong to and which will have us. Some of our deepest convictions and strongest emotions involve group dynamics. Much of what we regard as "right" or "wrong," "just" or "unjust," stem not from religious moral absolutes but from informal group or community dynamics.

As Linux has drawn millions into the fringes of the free-software movement, we have seen vigorous debates over the standards and "normative constraints" which are proper for this evolving community. These debates are an essential part of community formation and evolution; their outcomes define the community and the nature of the "well being" it confers on its members. The enduringconflict of values and priorities between the commercial and the academic communities, both of which can benefit from free software, has fueled the fires of debate. The existence of "community" does not imply consensus! Anyone who's lived in a small town knows this.

In fact, the objectivity and the personal restraint of most participants in this debate is more remarkable than the occasional bursts of intolerance or foolish egocentrism. (As opposed to prudent egocentrism...)

Robert Young of Red Hat, Inc., noted the lack of consensus in a Septemver, 1999, PC Week interview, "This term 'Linux Community' and the implication to outsiders that the community is cohesive--it has never been cohesive. It is, far and away, the most argumentative, acerbic group I have ever had the misfortune to be a part of. But don't get me wrong. That has been good for the technology. It's a community that values truth and values engineering excellence over marketing and compromise." (Return to Table of Contents.)

II. F. Academic Freedom and Capitalist Opportunity.

Our definition of "moral" limns (highlights) the observation that social benefit, in practice, outweighs individual benefit. That is, if a group is to exist at all, benefit to the group must outweigh benefit to an individual when they are in conflict. To put it another way, the group exists to benefit its members: this is an individual benefit. But when taking an action that benefits an individual will "harm" the group in some way, then the individual is "morally" constrained in some way to avoid the harm; ideally without also harming the individual.

The "harm" that proprietary, secret code brings to a community of users (end-users and the programmers that serve them) is (for examples) delayed development and failure to resolve bugs, frustration from achieving goals of known feasibility, inefficiency, and financial exploitation. The "benefit" of open code is (for examples) to accelerate development, enhance efficient use of code, freely exchange and debate ideas, which leads to improved algorithms and techniques, to expedite agreement on communication and exchange protocols, and to hinder financial exploitation and gouging by introducing competition for service.

Against the community-oriented "morality" of shared information is a competing "morality" of individualistic capitalism. This is not a new disparity, but theoreticians have cloaked it in new rhetoric. It is claimed, without proof, that there are (undectectable) natural forces inherent in capitalism (in an ideal economy) that tend toward market order and even social justice (see, for example, David Gauthier's Morals by Agreement). This world view holds that it is unnecessary to pay attention to group values and norms; that individuals pursuing selfish aims will, in a sort of "trickle-down," unintentionally create social order and justice.

Few people seem to realize that between these points of approach is a disparity of fundamental values and worldviews, which are incompatible and irreconcilable even though they can coexist successfully. Much of the debate between closed and open source advocates stems from this disparity of world views, though those debating seldom seem to be conscious that they argue from different sets of values. Academicians long ago adopted a community value of shared information; entrepreneurs believe secrets help them prosper financially. This "town versus gown" dichotomy will probably never disappear. We need to recognize that this debate exists, and its basis, so that we can judciously choose what information should belong to the community and which need not. My thesis is that we in healthcare cannot afford (financially) to continue to meet common needs with secret, un-shared, proprietary code.

III. Areas for Evaluation.

III. A. Collaborative Development.

Vendors and institutions belong together, sharing efforts, not being captives to each other in manipulative interdependency. The challenges we face are shared, and they are so complex that attacking the basic needs of our industry in dozens of different ways is wasteful. It risks causing (or perpetuating, depending on your point of view) an unacceptable financial burden that will weaken institutions and that will make health care services even more expensive for our country.

III. A. 1. Pragmatism.

Our slogan should not be, "Where do you want to go today?" but "What do you need to get done today?" We should be oriented toward solving the needs of our institutions to get work done; we should collaborate simply in order to pool resources on those needs we share.

A health care technology leader noted that development efforts have tended to be grandiose and abstract, mushrooming in scope and complexity before any useful functional core has been constructed, citing HL-7 3.0 as an example. He said, "What we need to do is to drop in something that will solve a problem; write simple components with clean interfaces. For example, write a Master Patient Index with a generic infrastructure, or design a system to do document imaging with .pdf files as output, using no proprietary systems."

"Then we go on from simple needed tools to extensions and interactions of tools, built gradually into a larger system. For example, when development has worked in the open source community, usually one person writes the alpha version of a tool that's needed. It has lots of warts. But then it's picked up by 3-5 other people who share the need and pretty soon you have a beta version, and so on."

"The other strength of the open source community is that most of the things people have built have had good working models. We don't have a good working model of a medical records system. Perhaps we should start with a good, clean, generic prescription-handling tool that can be plugged into medical records systems."

A notorious example of design over-reaching development is the late lamented failed deployment of a new air traffic control system (the reason the FAA is working with 1970's hardware) by the FAA and IBM. The "customer" kept asking for what was becoming technologically possible, the vendor kept trying to expand the project, everyone lost sight of the feasible, and after a decade of effort and hundreds of millions of dollars, the project was abandoned, a monument to the possibilities of a demanding bureaucracy who wanted the best that could be had and an ambitious vendor who was unable to judge cost effectiveness.

III. A. 2. Leadership.

It is necessary to identity a single person who is assigned the responsibility of coordinating the project and defining its standards and goals. This person is a benign dictator who rules only when consensus is blocked. Along with this strong chairman, a small executive team of technically knowledgeable experts who understand both the technology of programming and the intellectual needs of clinicians will be necessary, formed from the participating institutions.

Leadership of this project will require that each institution discipline itself to use the core code as it evolves, and to attach customization to it, not modify it locally; and to participate assertively and responsibly in the debates that will of course occur. It is impossible to reach useful consensus without vigorous and detailed debate. Co-developing software and fostering debate are essential to useful leadership. Debaters must understand that their goal is not personal victory or the defeat of one's opponent, but is discovering strengths to share and reaching consensus. (Return to Table of Contents.)

III. A. 3. Programming standards and Practices.

The material that follows is abstracted from a tutorial, "How Open Source Really Works," given at AMIA 2000 by Michael K. Johnson, co-founder of the Linux Documentation Project, working with Linux since Linux kernel version 0.02, co-author of Linux Application Development, and Red Hat Kernel Group Manager. It is supplemented by comments from other sources.

III. A. 3. i. Structured code.

Modular, generalizable code is essential to collaborative development, to permit each user to add appropriate and necessary customization without undue time and effort.

III. A. 3. ii. Programming best practices.

The techniques of collaborative programming are well known to the O/F source community. These include:

• Use of a language that is "spoken" by a number of programmers, to ensure a substantial pool of potential participants.
• Use of standard open source tools, for the same reason.
• Meaningful variable and function names, easily read by a new participant.
• Highly modular structure, sufficiently small for a new participant to encompass intellectually.
• Simple components with clean interfaces.

III. A. 3. iii. Documentation

Documentation is an essential part of the collaboration that must be begun when coding is begun or even before (by writing down consensus on specifications and performance), and continued in parallel with coding.

III. A. 3. iv. Strategy

Expect to completely re-write the code at least three times as the project matures. Even if the software is excellent out of the gate, needs and paradigms will change, ultimately making complete revision attractive. Code should be written with revision in mind (modularity and clean interfaces help).

Releases should be done often; development and production releases should be clearly distinguished with standard version numbers.

III. A. 3. v. Productization

A neglected aspect of productization is usability for both the programmer and the end user. The ergonomic needs of end users are more important than the need to have elegant code and nice functionality. On the other hand, the need to have high quality, maintainable code is more important than extra functionality. Moreover, administrators tend to lose sight of the needs both of workers and of technicians by spending too much time in meetings with each other and not enough time observing workers or being taught by technicians. End of sermon. (Return to Table of Contents.)

III. B. Office Applications

Scott McNeely said recently that customers do not really want all the features in software. Excel and Word are so feature-rich, so complex, that people waste time struggling with the software. What people need in the workplace are closely customized tools aimed at their work needs. I judge this to be generally true; over the last twenty years word processing software has tended to serve either very specialized markets or has become "bloatware" trying to provide everything anyone has thought of asking for. Effective writing requires very little adornment.

If any conversion is done, it would be prudent to first ask what features of our office software we really cannot live without, and make sure these necessary functions are available. Then we should consider the ergonomics of any proposed replacement, and then compare the acquisition, training, and maintenance costs of current software any any proposed replacement. In any case, it is costly to be a Windows-only shop.

Here's a brief list of possible replacements for Word, PowerPoint, Excel, and Outlook:

Office suites for Linux

AnywareOffice(Applix): The Anyware application server permits VistaSource applications to be accessed from any Internet connection, anytime, from a single, centrally located server. Anyware Desktop is a native, full-featured suite of integrated applications that includes a word processor, spreadsheet, presentation and graphics tools, mail client, and graphical relational database client. It has an extensive set of filters and gateways, to permit conversion of other file formats, including Word and Excel, across platforms. Because it is native, it is faster and more stable than WordPerfect. It has a small memory footprint, making it usable from thin-client devices to servers. Its SHELF/Builder application permits customization of documents and integration techniques. AnywareOffice 5.0 is about $40 per copy from VistaSource; click on "buy now" and then "software." Reference manuals are available separately for $100 (five volumes) and $30 (as above, click on "books").

WordPerfect: The WordPerfect Office Suite 2000 for Linux is a Windows product, ported to Linux by using WINE. The use of WINE causes this suite to be slower and less stable than other choices. In addition, since Microsoft has purchased a majority interest in Corel, continued support of the Linux version is in doubt. In the Windows environment, the main reason to change to WP would be to escape the known security issues of Outlook. WordPerfect 8 is natively available for Linux only as a stand-alone word processor, which is useful for importing and reading WordPerfect documents, but is not a replacement for an office suite. Corel seems to have stopped development of this since Microsoft became a Corel shareholder. It can't replace Outlook, so I would not recommend its deployment.

OffiX: This is an effort to create an office suite for the freeBSD flavor of Unix; it has been ported to Linux and is available with the Red Hat Linux Deluxe Workstation distribution. While it appears well designed, it does not seem to be a suitable candidate for deployment in a shop that is now Windows based and which has a large archive of Word documents. I cannot judge its suitability for any particular use, nor its stability.

Gnome Office: This includes SourceGear's AbiWord. It appears that there is little work proceeding on AbiWord. The spreadsheet, Gnumeric, is an Excel work-alike that was already getting good reviews in 1998. Sun is integrating their OpenOffice Suite with GNOME, which means all the applications of OpenOffice will become part of GNOME Office. The Open Office applications are currently not as integrated into GNOME as AbiWord and Gnumeric, but they have more functionality. See the Open Office site for more information on this. I would guess that StarOffice will eventually become "OpenOffice" via upgrades; the two packages are based on completely different development styles, and I'd recommend considering Open Office only after it reaches maturity.

Koffice: Koffice has adequate functionality, but its import/export abilities are limited, and it has not gathered enough support from developers to ensure that it will come to maturity. It is not suitable now for consideration for deployment in any enterprise that requires document format translation, in my judgment.

Lotus Suite Lotus Suite is available for several platforms, including NT and Linux. IBM Small Business Suite for Linux includes IBM Suites Installer, Lotus Domino Application Server for Linux V5.0.4, Lotus Notes for Windows V5.0.4, IBM DB2 Universal Database Workgroup Edition for Linux V7.1, IBM WebSphere Application Server for Linux V3.0.2, IBM HTTP Server for Linux V1.3.12, Lotus SmartSuite for Windows, IBM WebSphere Studio Entry Edition V3.0.2, Lotus Domino Designer for Windows V5.0.4, and IBM WebSphere Homepage Builder for Linux V4.0. Price is $450 for the package including the server, and $78 per registered user. It is of course available for Windows NT; when I wrote this their link to NT pricing was broken.

IBM has published a summary of its support of open source and is this is also covered in an article on zdnet. (Return to Table of Contents.)

III. C. Infrastructure

Linux's greatest strengths are in infrastructure and security, and it is here that our system can experience immediate benefit. (I am not an expert on infrastructure or security issues. I report here my impressions from observation.)

Linux is being adopted extensively for infrastructure uses, particularly routers and servers. In this regard, its rate of growth is reported to be currently outpacing Microsoft's. Little attention is being paid to the home or office desktop market by Linux vendors because of the lack of profitability in this sector and the aggressive way in which Microsoft protects its monopoly position. A few enterprises are becoming Linux shops, and some are willing to discuss their experiences. One recently getting publicity is the City of Largo, FL. An insightful internet news article is on newsforge, and technical discussions by the Largo IT manager are available in an email and an essay on the KDE site.

There are a number of security concerns with Microsoft operating systems, servers, and software. The design of applications such as Word and Outlook make them susceptible to attack by worms and viruses, and the Windows operating systems are notoriously susceptible to security problems. I have read that Windows is designed such that Microsoft can't redesign code to quash a class of viruses and so is stuck with writing rescues one virus at a time (PC Week, sometime in 1999), except when it does a new OS. Microsoft IIS servers currently are facing some security problems, most recently with the Red Code and sircam worms.

Unix and thus Linux have been designed to handle text strings; hence a strength of Linux has always been file and data management. Dr. Greg Wettstein, a pharmacist, using version 0.96c of the Linux kernel, in 1992 with Dr. Paul Etzell, an oncologist, developed a system referred to as Perceptions, which was a set of "interrogatory robots" that mined four non-interactive legacy databases, gathered new data from providers, and updated the legacy databases. When a patient came to the center and registered, these interrogatory robots were dispatched from the workstation to collect data for a packaging utility. This data packaging utility followed the patient through the center and additional data was added. Update utilities were used to maintain parallel database concurrency.

This system was used from 1993 through 1997, when in a merger it was replaced with a less efficient commercial system. This system provided a means to perform the fundamental clinical information task of the center -- collection, organization, and presentation of clinical data -- and also increased staff efficiency sufficiently that a 75% increase in patient load required only a 20% increase in staff. New mid-level languages and standards would make this task easier today, but functionally the needed design is the same: both horizontal and vertical modularity of software, particularly to separate the process of data acquisition from the task of presentation. This system was actually implementing functional data interchange long before XML was in vogue.

I cite this example to show that even in its infancy, a decade ago, Linux had inherently strong and reliable functionality for data handling and connectivity between disparate systems. This is even more a strength today, with enhanced tools and new languages.

Dr. Mike McCoy, Chief Information Officer of UCLA Healthcare, states that he has used similar capabilities to save his facility millions of dollars in costs.

I have been told of a medical center that may convert to Linux servers from Microsoft to better meet HIPAA requirements; I have not yet been able to confirm this due to confidentiality issues and of two major health care systems that are exploring infrastructure conversion to Linux because of the increased costs associated with Microsoft's new licensing fee structure.

It is important to note that it is more efficient to use Linux servers than NT servers for institutions running multiple processes, as one must have a separate NT box for each process; on Linux one can have multiple processes. With VMWare, for example, one can have multiple virtual machines running NT within a single Linux server.

Perhaps more effectively, using Citrix, Windows applications can be served to from a single Linux box to thin clients, saving money in license fees and server maintenance. Citrix MetaFrame permits internet-based access to Windows, Unix, or Java-based applications. This system is scalable, reliable, and efficient. It's worth investigating.

And CodeWeavers, Inc., has just announced the availablity of CrossOver Plugin, the first Windows-To-Linux adapter for Windows browser plugins and email viewers, and is working toward a commercial release of WINE, with CodeWeavers Wine Preview 4.

To investigate costs of training and support from Red Hat, Inc., visit Red Hat's Commerce page. For best estimates of actual use, it's best to contact Derrick.
Return to Table of Contents.)

IV. Opportunities.

IV. A. Vendor relations.

Dr. Mike McCoy, Chief Information Officer of UCLA Healthcare, who has extensive experience with both Unix and Windows based software, said to me, "Commercial vendors are wholesale adopting Microsoft OS when it's needless: IDX and Clinicomp for example: they have had excellent systems running on UNIX and instead of porting it to Linux, they have moved off the platform on which it was working well and onto Windows. We must stop vendors from moving applications off these working platforms by refusing to buy the Windows-based versions."

He noted that this is because Windows OS are too complex and difficult to manage, compared with Linux, in which "the config files tell the story -- you can telnet into them, manage them remotely." And it's because Microsoft is locking up markets: "What will MS pricing be when earnings growth is possible only by gouging their present customers? Their prices are high now; what will they be when further slowing of sales growth has occurred?"

He said, "The advantage of Linux is its simplicity, reliability, manageability, and its straightforward tools. In contrast, NT is unmanageable. No one understands the registry; upgrades are fraught with difficulties and incompatibilities." Vendors who already have applications running on any flavor of Unix and X Windows should be told that continued use of (future versions of) their product is contingent on porting it to Linux.

He noted that some vendors actually run their applications on Unix OS's and use Windows only as an expensive and complex front end, ignoring the simple solution of using X Windows instead, simply because some customers are demanding a Windows environment.

IV. B. Support of free operating systems and platforms.

Every health care institution that does any software development should seriously consider active participation in the open source medical software community by contributing software and programming efforts.

IV. C. Participation in collaborative development.

Wise, discerning, and selfless leadership will be necessary in order to successfully forge a useful working alliance in the health care community. It is not clear whether health care institutions are able to identify, recognize, or follow such leadership.

IV. D. Licensing concerns.

Fundamentally there are three classes of open source license:

• GPL: The GPL and its derivatives have in common that code derived from GPL'd code must be distributed if the compiled program is distributed. If the derived work is not distributed, then the code need not be.
• BSD: The BSD license places no restrictions on use of the code. This is little used because it does not prohibit users from closing modified BSD code. As a result of this, programmers have been required to pay licenses fees for code they wrote and distributed freely that was later modified for strictly commercial use by someone else. Causes unhappiness.
• Commercial: This license requires that a single company maintain the code, although it may be freely distributed. The prototype is the Mozilla Public License; IBM and Sun have similar licenses. This license is necessary to prevent Microsoft (or another company) from using its usual "embrace, extend, destroy" strategy on the code, and to ensure that the author is able to maintain control over its development, particularly to prevent forking (to "fork" code is to make new modifications of it that are not compatible with previous versions or with newer versions of the base code).

IV. E. Benefits

UCLA Healthcare has been using open source software for several years, and their Chief Information Officer has been able to save millions of dollars by this means. For example, he is developing a payroll time and attendance system for all employees including nursing (which has complex requirements) using only open-source tools, Enterprise-JavaBeans + Apache + TomCat + Jbox. He expects this software to save $1M annually: $500K for forms and $500K for key entry and coding. He plans to release the finished version as Version 1.0 as open source. To do this it will have to be modularized sensibly so that components are easily inactivated and will need a clean interface so that it can be matched to various back end software (different payroll systems).

For another example, he is installing a new imaging system. Because there are good open-source libraries to handle images, he is using only open source software to process images, ending with .pdf files for display. The only purchase software is and OCR package that costs $1500-2000. This is a per-process license, so a single server processes all image requests with a daemon, handling about one document every five seconds 24 hours a day. If this turns into a bottleneck, he'll purchase a second license.

The potential benefits to medical enterprises of using open source software are in reducing costs and gaining management control:

• From use of Linux and extant open source software tools, we would gain efficiency from the relative simplicity and clear logic of Linux systems and code structure, the ability to control and modify our IT resources, the ability to manage our own IT shop and projects without needlessly applying to a vendor for a simple fix, and reduced costs because of the absence of license fees; and the opportunity to return in kind contributions to the software libre community.
• From use of server and office applications, we would gain freedom from mandated upgrades of Windows products, avoidance of the manifold security issues that attend Outlook and Word, ability to control and manage the office computer desktop environment, and better control over software costs.
• From release of dependency on software vendors, we would gain freedom from vendor lock -- we would not find an important software function in our enterprise at the mercy of a vendor who owns but who may stop supporting or developing code, and we would be able to outsource software support to any shop with trained staff -- we would be in control of maintenance and development.
• From release of software dependency on Windows products, we would be freed from exploitive license fees and fears of having accidentally unregistered software copies; and having desktops with which employees were not completely familiar from their use at home, we would be less subject to security holes produced by trojan horses brought in with games, screen savers, and other "enhancements."

The potential benefits to medical enterprises of participating in collaborative development are to reduce costs by avoiding duplication of development effort, to have better quality software, and to make a substantial contribution to society by helping to reduce the redundant and incompatible software systems that exist by:

• Freely publishing to the health care industry code that medical enterprises have already developed, with the expectation that if this code is intellectually accessible to programmers, meets general needs, and continues to have enterprise support, that it will help form a nucleus of common tools for our community;
• Searching for open-source code that is already extant which could be usefully modified to meet each institution's needs, contributing our enhancements back to the developers as an in-kind royalty;
• Helping to form a consortium of collaborators in health care to coordinate work on projects in health care informatics, and devoting resources to supporting the consortium; and
• Lending the prestige and integrity of the each institution's name to an effort that could benefit health care everywhere.

V. Current Open Source Medical Software Projects

Here's a list of important open source projects.

Circare

Circare is a Canadian project, the brainchild of Brian Bray, that includes a Master Patient Index. It is open source. I believe that the project included extensive additional work aimed at creating an electronic community resource for patients. It was funded through a government agency, which I believe has ceased work on the project. The code, however, is available, and the authors are interested in the project.

GEHR

GEHR is a very important effort to define a medical record structure that is independent of language and culture. It is a superset of other coding and record schemes. It is the brainchild of Australian physicians Thomas Beale, Sam Heard, and Peter Schloeffel (well, Beale may be a programmer) that has garnered interest in Europe. It is the only comprehensive effort I know of to actually define what is the essential nature of the medical record. The essays by Thomas Beale are worth reading. An html presentation is available.

HL-7

Well, who can mention medical information technology without genuflecting at the Temple of HL-7, whose work will never end. A mandatory stop on the road to universality. Also see The HL7_lib Handbook, an open-source attempt to produce a simple, correct HL7 library that can be embedded in projects to enable rapid development of powerful tools and robust interfaces..

OIO

OIO, Open Infrastructure for Outcomes, is the brainchild of psychiatrist Andrew Po-Jung Ho of UCLA. Dr. Ho has produced an effort that is a significant contribution to outcomes assessment, that would be important to academic use of an electronic health record.

OpenGALEN

OpenGALEN is a European effort to provide a new technology for medical terminology and coding. Their motto is very European: "Making the impossible very difficult."

FreePM

FreePM is an open source practice management system built by Tim Cook, in use in the central US. There is a recent review at LinuxMedNews. FreePM has been superceded by TORCH.

FreeMed

FreeMED is an open source practice management system built by Jeff Buchbinder, in use in the northeastern US. Also see the version at Lutheran Homes Society Family & Youth Services. For current news, see LinuxMedNews.

TkFP

Tk-Family Practice is an electronic medical record written by Alex Caldwell, MD, for use in his own practice. It is written in Tcl/Tk, which limits its use in enterprises, but in any case it is an interesting demonstration by a single physician of some of the opportunities that exist for gaining efficiency for the busy clinician. He has done ground-breaking work with Dr. David Pepper in the automated production of narrative progress notes from point-and-click entry of historical and physical findings, linked to consensus disease management guidelines.

GNUMed

GNUMed is an Australian practice management system written by Horst Herb. It is under active development

OpenEMR

OpenEMRis an actively deployed and supported EHR based on work by David Forslund. Also, go to LinuxMedNews and search for "OpenEMR."

VISTA

VISTA is the worlds largest, best functioning open source EMR. It is the US VA systems' health information management system and is comprehensive and capable. It is in the "open" because the US government owns the copyright. One vendor sells this system to civilian hospitals. As an open source effort, it suffers from being written in M (The Language Formerly Known as Mumps), which is hard to read and lacks a population of skilled programmers. Vista developers are frustrated at the lack of enthusiasm for this very functional system. It is actively supported commercially and is in use in several centers.

VI. Summary of intent.

VII. Recommendations for Action.

A. Collaborative Development

Collaborative development of health information software has great potential, for health care institutions, in general, have many common needs. If we would each tax ourselves a small proportion of our IT budgets annually and devote this to collaboration with other institutions, focusing on working software and doing planning and design only to support function, great progress could be made. We would gain each others' efforts and contributions rather than money royalties. Some of the important steps to forming such a collaboration would be:

• Make an institutional commitment to participate in collaborative development with other institutions.
• Identify administrators in sister institutions who may be approachable regarding collaboration, and present our proposal.
• Sponsor a meeting to review best practices of collaborative development, to identify what common needs are most amenable initially to this approach, and to review what each institution can bring to the collaboration in terms of existing software, skills, experience, or personnel.
• Form a consortium for collaborative healthcare sofware development by seeking commitment from participants: identify a liaison and participants at each institution, a budgetary commitment within the institution, and participation in a discussion forum.
• Contribute internally developed extant (pre-existing) software to the consortium under a GPL.
• Identify leaders and roles: these will comprise a flexible collection of working committees with strong chairmen, to fill at least these important roles:
  • Overall coordinator/dictator: this might be a triumvirate of an experienced adminstrator who also understands clinical and technical issues, a clinician who understands clinical intellectual ergonomics and appreciates administrative concerns and technical issues, and a technical expert who is sensitive to clinical and adminstrative needs.
  • Technical coordinator: a geek with broad knowledge of open source software resources, database, and connectivity.
  • Documentation project coordinator: a person to organize documentation and supervise its production
  • Code repository manager: someone must maintain a code versioning system.
  • Distribution/productization manager: a person to coordinate and advise the process of putting project code into an installable package and maintaining this. (Return to Table of Contents.)

B. Use of Open Source Software in Health Care Infrastructure

The greatest strength of Linux is in its ability to handle our infrastructure needs more efficiently, more reliably, and at lower cost. In considering these design features of Linux, it's important to bear in mind that Linux is simply an implementation of POSIX-standard UNIX, originally for x86 microprocessors. Essentially all UNIX software tools have been ported to Linux.

• Security:Unix was designed with security and privacy in mind; Windows was not. Thus it is easier to protect Linux servers from attack. For example, if a security hole is discovered in an application, that program can be closed while it's fixed, and can then be restarted without rebooting the system. This process is invisible to users of the server unless they're using the faulty application.
  The Linux system keeps extensive logs of user activity, so that system administrators can readily investigate irregularities.
• Reliability: Linux servers don't crash often. Many users, including myself, can offer examples of Linux servers that have run continuously for more than a year without crashing or being rebooted. Linux can shut down a rogue application; if an application crashes (the prototype example is Netscape running Java), the program at fault can be identified and killed in seconds.
  Linux can be reconfigured on the run; it is not necessary to interrupt users to upgrade applications.
  Linux' open character permits the knowledgeable administrator to readily perform maintenance without using outside contractors or appealing to a vendor who may not have interest in resolving a "small" problem.
• Cost-effectiveness: Linux has no royalties or user fees. Commercial support is available, but the customer pays only for service, and can switch to a competing vendor at any time, and because the customer has the source code, vendor lock is impossible. This permits the user to maintain control of maintenance strategy and expense.
  It is not necessary to buy applications; Linux distributions come with a very wide array that generally contain all tools an administrator needs to build and maintain a system. There is generally a broad range of choices among equivalent tools, so that if one flavor of a tool isn't quite what one wants, there is a good chance that an alternative version will be more comfortable. This is daunting to the new user, who generally feels some compulsion to initially pick the "best" among alternatives, but it also means that there are generally a variety of adequate choices for a task.
• Control: The fact that with Linux the systems administrators have all the code, tools, and languages means that an enterprise is always able to control its implementations, network structure, security, and applications, using outside consultants as needed; the Linux user is never at the mercy of a vendor.
• Scalability: Linux is highly scalable; much more than Windows.
  Linux can run multiple applications from the same server; NT requires a separate server for each application.
  The experience of the City of Largo, FL, has been recently publicized; from a single $10K Linux server the city runs 400 thin clients, 800 users, and has supported 235 simultaneous users in peak times without bogging down.
  On August 28th, the American and New York stock exchanges announced that the electronic trading service that supplies brokers with data from the New York and American stock exchanges is shifting its key applications to Linux.
  The State of Texas manages its drivers' license database, about 2GB of data, on a Linux server.
  The Weather Channel has run entirely on Linux for several years.
  More than half of the image rendering for the movie Titanic was done with Linux and open source applications.
• Connectivity and networking: Linux has superior reliability, scalability to large numbers of servers and clients, security, and interoperability. The Internet runs largely on UNIX; most internet servers are Linux boxes. Apache is a Linux application. Samba interconnects Linux with systems you'd not expect; CIFS/SMB permits Linux to serve Windows applications. Linux also can serve Macintosh applications.
  Perceptions, written in 1992-1993 beginning with Linux 0.96 by Dr. Greg Wettstein for the Roger Maris Cancer Center in Fargo, was novel middleware that linked four disparate systems, permitting continuous, real-time data interchange among them in a clinical setting.
• Encryption: Encryption is easy to integrate in Linux, a potential benefit in meeting HIPAA requirements. in particular, openssh, (open secure shell), is a flexible tool for all sorts of encrypted commands. In its simplest use, it forms an encrypted link between a server and any terminal. But it can also be automated to perform many automated functions securely, for example, tunneling processes between servers using the tcp protocol, permitting one to export network services securely from one machine to another,
• File transformation: Unix is able to transform text files readily, and can process text streams (textual data fields, for example) between applications and systems. This is because Unix was originally designed as a document-handling system for Bell Labs, and Linux thus, has a large array of suitable tools and languages.
  Linux has acquired, since graphical systems have become important, an array of image-manipulation tools that are readily automated, so that large numbers of images can be acquired, transformed, stored, or displayed programmatically.
• Straightforward maintenance: Configuration of Linux system and application files is done through ASCII config files. These are readily edited with any text editor, and are immediately implemented, usually simply by restarting the associated program. (Return to Table of Contents.)

C. Desktop Applications

Adequate desktop applications exist:

• StarOffice & Anyware are usable, cover essential needs; OpenOffice is in advanced development.
• Organized support for installation, training, maintenance? It would be necessary for us to create an internal training and maintenance program, which would be easily done and might be less than the licensing fees.
• Internal support for change will depend on magnitude of cost savings, adequacy of replacement.
• Some use of Word and Excel will be necessary because of their wide use.
• Proprietary software could be served to thin clients using Citrix Metaframe, VMware, or open source software. This would abate licensing costs even if we do not change desktop applications immediately, because the number of actual users at any time is usually significantly fewer than the number of machines on which an application must be installed if it is distributed to each user. (Return to Table of Contents.)

Author.