Medical Enterprises and Open Source

It is a great thing to make scientific discoveries of rare value, but it is even greater to be willing to share those discoveries and to encourage other workers in the same field of scientific research. -- W.J. Mayo, January, 1928

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.
    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.

Three hundred year ago, doctors, particularly surgeons, were entrepreneurial craftsmen. Those who had discovered secrets of anatomy, surgery, or medication used this special knowledge to make themselves famous and rich. They used this knowledge to attract clients and apprentices, and an apprenticeship to a famous surgeon was not purchased cheaply. Their discoveries were published after decades, or posthumously, if at all.

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.

Free or Open software is misunderstood as being "without payment." It is true that it is possible to acquire and possess open source software and to use it gainfully in business without paying money to anyone. But "free" means "academic freedom," not "free beer." The payment is on the honor system, entailing an obligation to return an in-kind contribution to the open source community by participating in it -- reporting bugs, describing needed features, and contributing code.

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.

In the 1970's, the success of proprietary operating systems, particularly UNIX, created frustration in the academic community, who could not use these systems for study or teaching. This was a tremendous hindrance to their effectiveness. This situation motivated Richard Stallman to begin the GNU project in the mid 1980's. At first this project produced utilities and applications, but its fundamental goal was a free OS. Meanwhile, the proliferation of different flavors of UNIX resulted in development of the POSIX standards. In 1991, the world still was without a functional OS that was available for teaching.

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 (Return to Table of Contents.)

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

Now that I have your full attention, let me explain why I use the word "moral" here. It is simply to explain the basis for the sometimes bad behavior of a few immature folks in the free software community, and to explain the strength of feeling and commitment many have. Skip it if you'd like.

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.

The history of the medical community's discovery of the importance of sharing discoveries is a paradigm for what has been more recently developing in the free software/open source community, as the same debates have occurred at opposite ends of intervening centuries.

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.

It will be worth exploring the possible benefits to medical enterprises, of participating in collaborative development with other institutions, of the costs and benefits of using open source desktop software for word processing and email, and of the benefits of using open source software in the IT infrastructure: servers and tools.

III. A. Collaborative Development.

The "other side" of open source -- the practice of collaborative software development -- is more important to its success than being "open" (freely available to the community of users). Folks have focused on "free software" so fixedly that they don't realize that the true revelation of the open source movement is collaborative development within a broadly defined community, who share code and effort in order to meet a common need.

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.

We can expect others to be interested in working together only on projects that meet their own needs; so to encourage collaboration it is necessary to consider as important the needs and interests of potential collaborators.

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.

A successful campaign for collaborative development of health care software will require several kinds of 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.

Our community is the community of health care organizations and the commercial vendors that serve us; release of code outside this community is not necessary, even if we wish to be faithful to open source principles; however, we also belong to other "communities," and we will discover that many software tools have general use in other work settings, and the IT community has many shared needs that transcend health information management.

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.

It's important to keep the core of any shared application generalizable to all users. Idiosyncrasy belongs in modules, patches and enhancements. Identifying successfully what is "general" and what is "idiosyncratic" requires vigorous discussion and debate; we all tend to think our own priorities and practices are more universal than they are. It takes great intellectual discipline to divest oneself of idiosyncrasy, to see broadly, especially when our own practices are efficient and successful, and based on careful study and sound logic. It takes great flexibility to perceive someone else's solution, that accomplishes the task successfully but with a different flavor, look, and feel, as being acceptable to ourselves. I believe that the greatest barrier to successful collaborative development in the health care community is our powerful tendency to prefer idiosyncratic solutions and our natural and skillful independence.

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.

If we wish others to work on code together with us, it must be intellectually accessible to them: modules small enough to wrap one's mind around in a single sitting, code that's easily read and deciphered, a versioning system that helps folks avoid work on stale code.

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

III. A. 3. iii. Documentation

Version control, bug tracking, and documentation go hand in hand; Docbook is the most commonly used tool for Linux documentation. Bugzilla, developed by Mozilla staff, is the most capable but also has the most complex interface. CVS or Subversions are recommended for version control.

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

It is important to begin with code that works; that does a job, meets a need. It may be ugly at first, but it needs to be functional. So the first task is for the community to identify a common need that is central and that can quickly be addressed by a relatively simple project. Enhancements and extensions are added progressively to improve function, make the tool more generalizable, and to make it more efficient and attractive.

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

An explicit productization process is important to making the developed package as useful as possible. In its most simple form, it means that someone or a team must focus on keeping the most functional current code, documentation, and install scripts together in a distribution. This may be in an archive on a server accessible to the community or may be distributed on CD-ROM. The important point is that the work will be used most readily if installing updates is not difficult for users, including the geeks who are designing it.

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

Microsoft's mandated upgrades and licensing fee policies make alternatives attractive. In my limited experience with Microsoft office applications,) Word is used for medical transcription and by secretarial staff, Outlook is used for email, and physicians and administrators use PowerPoint to distraction for presentations. Except that voice recording (transcription) software is integrated tightly with Word, this functionality could quickly and easily be replaced with any competing product, particularly AnywareOffice or StarOffice. I have used the Applix Presents, for example, instead of PowerPoint.

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

StarOffice: (Sun). The StarOffice 5.2 suite includes word processing, spreadsheet, and presentation applications. It also has support for AutoPilot Web page design software, 3D graphics, diagrams, HTML editing, and calendar, newsgroup, browser, email and scheduler, photo editing, and other applications. Its interoperability with other desktop productivity suites, including Microsoft Office, is better than any other open source suite. A full description of its components is on Sun's web site. It is available on Windows platforms, and thus can replace Microsoft Office without converting to Linux. StarOffice is available without charge by download from Sun, is provided in the Red Hat Linux Deluxe Workstation boxed set (about $80), and is available in boxed sets from Amazon for about $45. There are no licensing fees. I installed and used it in preparing this manuscript; it has many nice features, but it can do only simple html documents, and it unexpectedly "fixes" code not to its liking; emacs is a better html editor.

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.

By representing these important community values publicly, by pointing out that collaborative development is an extension of the fundamental values we hold as medical professionals, researchers and teachers, by insisting on appropriate public ownership of tools and techniques that fundamentally benefit society, we will be able to favorably influence the course of health care IT during the next decades. It is important that we work with other institutions on mutual needs, and invite additional participants as this bears fruit. It would be unmanageable to try to be all-encompassing at first; it will be important to begin with just a few, only those with vision and energy, but enough to ensure that the software developed is general rather than idiosyncratic.

IV. A. Vendor relations.

We need to bring vendors into our medical free software community by educating them on how it can make them more efficient, freeing up resources to serve individual customers more effectively.

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.

Free / Open source software is compatible with continued commercial development. If our system participates in collaborative development of key software, commercial vendors serving us should be strongly encouraged to use the tools, protocols, and code that have been collaboratively developed, and to contribute to their improvement. This will may require that the copyright used be different from the GNU "copyleft" (GPL), which requires developers to release to users all code derived from open code. The copyright must permit commercial use, require that the code not be "forked," and require that improvements made to it be contributed back to the community that develops it.

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.

Instituional participation in collaborative development will lend needed weight to the dissemination of sofware solutions that meet common needs. This participation well provide moral suasion within the health care community. The central needs for such a program are to discriminate between common and idiosyncratic needs -- letting common need guide the kernel and relegating idiosyncrasy to attached modules -- and to focus on writing code that gets work done rather than fostering endless committee meetings to refine and expand priorities, paradigms, and protocols (a real danger in large professional group endeavors).

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.

The Free Software Foundation maintains a fairly comprehensive list of various open-source licenses, with annotation. Also, the Open Source Initiative maintains a list of licenses.

Fundamentally there are three classes of open source license:

The "shared code" licenses offered by Apple, Sun, and Microsoft are not open source licenses. I can't point to a scholarly legal review of open source licensing. I spoke to an academic attorney specializing in cyber copyright law, Ronald Chichester, who stated that there is none.
(Return to Table of Contents.)

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:

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:

Return to Table of Contents.

V. Current Open Source Medical Software Projects

A listing of many projects is at LinuxMedNews; this includes only their names and links, without comment. A more informative annotated, somewhat different list, was kept by Minoru, but maintenance of this listing stopped in September, 2002. See also Health Informatics Europe. For a list that's current as of June, 2004, see LinuxMedNews.

Here's a list of important open source projects.

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 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.
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, 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 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 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 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.
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 is an Australian practice management system written by Horst Herb. It is under active development
OpenEMRis an actively deployed and supported EHR based on work by David Forslund. Also, go to LinuxMedNews and search for "OpenEMR."

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.

"Open software" means sharing code within a community that is defined by a common need; "collaborative development" means working together to meet that common need. Our community is the community of health care organizations and the commercial vendors that serve us; release of code outside this community is not necessary. Improved control of our tools and our destiny, benefits to the public from improved quality and consensus, gains in efficiency to our industry and our institution, and a decreased software financial burden can result from joining the open source community. (Return to Table of Contents.)

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:

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.

C. Desktop Applications

Adequate desktop applications exist:


Daniel L. Johnson, MD, FACP, is a general internist with the Red Cedar Clinic -- Mayo System in Menomonie, Wisconsin. He has been an interested observer of the computer revolution since 1980, has worked with the development of word processing software (1980's), wrote a specification for an intelligent medical record in 1986, "QuickQuack," that hasn't been produced. He has been observing the development of the open source software world as an interested spectator with the guidance of his son, Michael K. Johnson (above). He has been suffered to operate a simple Linux network at the Red Cedar Clinic that serves his exam rooms and office. He is not a geek, programmer, or engineer. You may contact him -- johnson DOT danl AT mayo DOT edu -- with questions or comments to him if you like. Complete CV available on request if he gets around to it.