File: medicalfreesource.html

package info (click to toggle)
med-doc 0.6
links: PTS, VCS
area: main
in suites: lenny
size: 4,140 kB
ctags: 180
sloc: sh: 142; makefile: 53
file content (2041 lines) | stat: -rw-r--r-- 115,183 bytes
parent folder | download | duplicates (3)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
   <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
   <META NAME="GENERATOR" CONTENT="Mozilla/4.07 [en] (X11; I; Linux 2.0.36 i586) [Netscape]">
   <TITLE>Title</TITLE>
<!--Created by Applixware HTML Author, Release 4.4 on Sat Nov  6 00:00:46 1999-->
<!--Ax:WP:DocVar:HTMLOriginalPath@:"/tmp/ex03380d.aw"-->
</HEAD>
<BODY>

<CENTER><B><FONT FACE="helvetica, helv, geneva"><FONT SIZE=+2>Open-Source
Medical Information Management</FONT></FONT></B>
<P>Copyright 1999, Daniel L. Johnson</CENTER>

<BR>&nbsp;
<P><BR>
<P><B>Disclaimers</B>
<P>I have no commercial interest in any of the software discussed in this
essay; in fact, I've spent a lot of my own money on this project just for
the pure pleasure of it. My only conflict in this arena is that I have
lately come to own a little Red Hat stock through accident of birth.
<P>I am not a <I>GNU/Linux</I> or <I>free software / open source</I> zealot;
I simply recognize its genuine strengths and enormous potential. I am not
opposed to commercial software; in fact, I am an investor and board member
of a company, Technology Concepts, Inc., that is a provider of real estate
database software and which does not use any free or open source technology,
and is wedded to Microsoft technolgy.
<P>My employer, the Red Cedar medical Center, and our owner, the Mayo Regional
Health System,
<BR>have not supported this work, nor have they been asked to endorse it.
It is purely my own
<BR>work.
<P>I have done enough coding to know that my time is better spent supporting
skilled hackers rather than trying to become one. I have watched the computer
industry carefully for twenty years, but I do not know nearly enough about
it; in this essay I have done my best to tell the truth: all errors are
inadvertent, and I'll be grateful to be educated where you see a need for
it.
<P>Whenever something I say in this document seems not to make sense, please
consider it a failed attempt at humor.
<P><B>Author's background</B>
<P>I am Daniel L. Johnson, an internist from Menomonie, Wisconsin. I've
had an interest in office ergonomics for about 30 years, since being an
office supervisor before medical school; and an interest in finding ways
to use computers to aid clinical efficiency since about 1983, when I found
a replacement for the accounts-receivable software that my clinic was using.
In 1985, after a change in practices, I became interested in the intellectual
and manual processes of mining information from a clinical record for medical
decision-making. This led me in 1986 to write a specification for software
to make the intellectual tasks of the office physician more efficient,
but the databases and tools did not yet exist to make this feasible. This
specification, updated for current technology is available at
<P>http://lorenzo.uwstout.edu/QQMIM/qq4.html.
<P>The tools now exist to create such a system, but it remains to be determined
whether interest, motivation, and human capital can be assembled to bring
this about. This specification I whimsically call "QuickQuack."
<P>The html version of this essay will be located at
<P>http://lorenzo.uwstout.edu/QQMIM/medicalfreesource.html
<P>You may contact me at
<BR>&nbsp;&nbsp;&nbsp; johnson.danl@mayo.edu
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; or
<BR>&nbsp;&nbsp;&nbsp; johnsondanl@m1.uwstout.edu
<P><B><FONT SIZE=+1>Open-source medical software.</FONT></B>
<P>The focus of this essay is medical-record software aimed at the outpatient-care
setting. Hospital care requires record-keeping with an entirely different
philosophy than outpatient clinical care, such that it is not possible
to do justice to both in one presentation.
<P>Hospital documentation is oriented around single, completely encapsulated
events of care, lasting hours to weeks. Outpatient-clinic documentation
is oriented around longitudinal care for at least an episode of illness,
but in primary medicine, the "episode of care" is the patient's entire
life. In the most general sense, any chronic illness or primary care requires
rapt attention to the longitudinal aspects of the patient's condition;
a transient condition is an "interlude"<SUP>1</SUP> of care.
<P>Thus a hospital-based electronic medical record could be subsumed within
an outpatient-clinic record, as a "lobe" off the main record; but it is
not possible to take a record designed for the hospital and generalize
it to the outpatient-clinic setting.
<P>A strategy of any project must be to begin simply; to identify accurately
the essentials of the electronic record and focus on these while planning
for the inevitable addition of complexity and evolutionary needs. One of
my goals here is to begin to identify the "kernel" of the record and recognize
the directions it must take.
<P><B>Extant Computerized Medical Information Management Projects</B>
<BR>&nbsp;
<TABLE BORDER CELLPADDING=0 WIDTH="524" >
<TR ALIGN=CENTER>
<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>Project</B></TD>

<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">Internet address for more information,
if any
<P>(principal author or project leader, project location)</TD>
</TR>

<TR ALIGN=CENTER>
<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>Perceptions</B></TD>

<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://www.enjellic.com
<P>(Greg Wettstein, Fargo, North Dakota)</TD>
</TR>

<TR ALIGN=CENTER>
<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>VistA</B></TD>

<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://www.hardhats.org/apps/APPSmain.html
<P>or http://www.va.gov/vama.htm</TD>
</TR>

<TR ALIGN=CENTER>
<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>Arachne</B></TD>

<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://www.arachne.org/arachne_overview.html
<P>(Stephan R.A. Deibel, John Ehresman, Massachusetts)</TD>
</TR>

<TR ALIGN=CENTER>
<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>Littlefish</B></TD>

<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://www.paninfo.com.au/intro/littlefishproject_homepage.htm
<P>(Chris Fraser, Australia)</TD>
</TR>

<TR ALIGN=CENTER>
<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>Tk_familypractice</B></TD>

<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://www.psnw.com/~alcald/Tk_familypractice.README.html
<P>(Alexander Caldwell, California)</TD>
</TR>

<TR ALIGN=CENTER>
<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>FreeMed</B></TD>

<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://freemed.org/&nbsp;
<P>(Jeff Buchbinder, Connecticut)</TD>
</TR>

<TR ALIGN=CENTER>
<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>FreePM</B></TD>

<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://www.freepm.org/
<P>(Tim Cook)</TD>
</TR>

<TR ALIGN=CENTER>
<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>Circare</B></TD>

<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://www.minoru-development.com/circare/
<P>(Brian Bray, Joseph Dal Molin, Hamilton, Ontario)</TD>
</TR>

<TR ALIGN=CENTER>
<TD ALIGN=LEFT VALIGN=TOP WIDTH="22%"><B>QQ-MIM</B></TD>

<TD ALIGN=LEFT VALIGN=TOP WIDTH="78%">http://lorenzo.uwstout.edu/QQMIM/medicalfreesource.html
<P>and /QQMIM/qq4.html</TD>
</TR>
</TABLE>

<P>A listing of most projects is at
<P><FONT FACE="helvetica, helv, geneva">http://www.minoru-development.com/en/healthlinks.html#projects</FONT>
<P><B><FONT SIZE=+1>A brief history of free software:</FONT></B>
<P>(See http://www.fsf.org/gnu and http://www.tuxedo.org/~esr/writings/hacker-history/)
<P>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.
<P>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.
<P>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.
<P>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.
<P>To review the open-source material, visit
<P>http://www.opensource.org
<P><B><FONT SIZE=+1>The Moral Basis of Free Software/Open Source.</FONT></B>
<P>Now that I have your full attention, let me explain why I use the word
"moral" here. 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. 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.
<P>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 individuals.
These groups did not form on the basis of economic need, but of educational
and functional need. Economic use followed.
<P>Let's step aside briefly to understand the free-software/open-source
revolution better:
<P>Capitalism has traditionally been a bastion of individualism, and personal
freedom is thought to be part of its foundation. On the other hand, academia
and commercial enterprise have often been in conflict, partly because free
exchange of ideas is the most important principle of an academic community,
while privileged knowledge has always been a source of riches for the businessman.
<P>In the centuries since Adam Smith's work, economists have paid ever-closer
theoretical attention to the idealized construct of "perfect competition."
Two of the requirements of perfect competition are freedom to participate
in the economy ("to trade") and equal access to information. Businessmen
who profess loyalty to "competition" and to the ideals of capitalism are
assertive in advocating their rights to freely participate in trade and
to compete, but don't share information, favoring imperfection as long
as it favors them. Academicians have paid scant attention to trade and
have devoted much attention to freedom of ideas, often with trumpeting
and breast-beating.
<P>In 1986, David Gauthier famously wrote in <I>Morals by Agreement</I>
that a perfectly competitive market, "Were it realized, would constitute
a morally-free zone, a zone within which the constraints of morality would
have no place. ...this is not a fault, but the essential virtue of the
market." This libertarian ideal has had significant influence on the behavior
of judges and businessmen. But it is not correct. The reason it is not
correct, and the fact it is not correct, are important to understanding
the vitality of the open-source, free-software community.
<P>In his forthcoming book, <I>The Moral Conditions of Economic Efficiency,
</I>Walter
Schultz analyzes the Fundamental Theorem of Economics and clarifies its
presuppositions, and proves rigorously that an idealized economy cannot
be efficient if the agents acting within it have neither moral constraints
nor an internal incentive to act morally.
<P>One key to understanding is that "morality," at its kernel, is neither
religious nor absolute. It is relative to the values of a particular community.
Schultz, a philosopher, presents a minimal definition of "morality" that
is valid across Western and modern Eastern cultures:
<P><I>Morality</I> is
<BR>&nbsp;&nbsp;&nbsp; - a normative social practice,
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
the purpose of which pertains to collective and individual well being,
<BR>&nbsp;&nbsp;&nbsp; - guided by beliefs held in common,
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
concerning
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- criteria by which to evaluate behavior,
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- criteria for mutual responsibility, and
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- procedures for mutual accountability.
<P>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.<SUP>2</SUP>
<P>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.
<P>So Robert Young of Red Hat is taking a consciously moral stance when
he states that Red Hat releases all its code because "it is the right thing
to do," and when he refers to partnerships with developers and users as
"setting up an ecosystem" that creates a "virtuous circle." (See PC Week,
Sept. 27, 1999, p.100)
<P>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 enduring
conflict 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" <I>does not</I> imply <B>consensus</B>!
Anyone who's lived in a small town knows this.
<P>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...)
<P>Robert Young notes the lack of consensus in the same 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."
<P><B>Academic Freedom and Capitalist Opportunity.</B>
<P>The history of the medical community is a paradigm for what has been
developing in the free software/open source community, as the same debates
have occurred across recent centuries.
<P>Two and three hundred years 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.
<P>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.
<P>Today doctors, particularly surgeons, still put enormous energy and
politically-sophisticated efforts 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 special expertise
in areas of highly complex <I>public</I> knowledge and providing <I>service
</I>of
extremely high quality.
<P>In fact, if a health practitioner claims to have special, secret knowledge,
this is always assumed to be quackery -- 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 physicians, and is in fact acting immorally based on the standards (social
norms) of the medical community using the cross-cultural definition of
"morality" above.
<P>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.
<P>Why is this happening?
<P>Because there is unequivocal <I>community benefit.</I>
<P>The justification for academic freedom is ultimately that common knowledge
benefits society -- "community" in the broadest sense.
<P>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" in the broadest sense.
<P>And the reason that proprietary 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.
<P>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.
<P>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.
<P><B>How does this apply to the development of medical software?</B>
<P>It means that those features of software which will be of general use
to the entire medical community in promoting communication, appropriate
data exchange, and those features which tend to improve health care in
society should be subject to the principles of academic freedom: the code
should be open.
<P>It means that software designed to perform tasks that tend to be unique
to organizations or matters of individual preference, or knowledge that
is special to a particular enterprise need <I>not</I> be open; in fact,
opening such code does jeopardize the security of the vendor.<SUP>3</SUP>
<P>Nevertheless, users of software tools are learning that open code helps
protect them from vendor lock and exploitation, and sophisticated users
are beginning to require, as part of vendor agreements, that the code as
well as the executables be released to the user, typically with a non-disclosure
agreement executed by the user on behalf of the vendor.
<P><B>Rights of the Programmer</B>
<P>Dr. Schultz, after proving rigorously that economic inefficiency is
the outcome of a morality-free community, then asks what are the normative
conditions that will provide efficiency in an idealized competitive economy.
He rigorously proves that at least four exist in respect to economic exchange
situations, which happen to moral rights in the cross-cultural sense already
given. I list them without his proof:
<BR><FONT FACE="symbol">&middot;</FONT><B> A right to truth.</B> This is
a right to truth regarding goods and services and acceptable prices; it
entails an obligation not to lie.
<BR><FONT FACE="symbol">&middot;</FONT><B> A right to property.</B> This
permits a set of defined property rights; it entails an obligation against
theft.
<BR><FONT FACE="symbol">&middot;</FONT><B> A right to autonomy.</B> This
is a liberty right, to act freely within group constraints; it prohibits
exploitation and slavery.
<BR><FONT FACE="symbol">&middot;</FONT><B> A right to welfare.</B> The
Fundamental theorem presumes an "initial consumption bundle;" this right
obligates the community to restore a minimally adequate consumption bundle
to the person whom disaster strikes; everyone else contributes to its restoration;
it entails an obligation to give. (This is what commercial insurance and
government disaster relief provide.)
<P>It is useful, in seeking to understand the nature of the free-software/open-source
movement, to extend these rights to production situations, specifically
the economics of software production and service. In this sense, what do
these rights entail? I attempt here to connect them with the known mores
of the community, to the extent that there appears to be any consensus.
<P><FONT FACE="symbol">&middot;</FONT> <B>A right to truth.</B>
<P>The hacker has a right to verifiable code.
<P>There is an obligation not to distribute (deliberately) obfuscated code,
rogue patches or binaries, Trojan horses, and not to give false instruction.
<P><FONT FACE="symbol">&middot;</FONT> <B>A right to property.</B>
<P>There can be a set of ownership rights by which a hacker may own and
distribute code, and there is (separately) an absolute right to have possession
of code.
<P>This right also implies a right to hack; there is an obligation not
to hinder hacking, an obligation not to plagiarize code; and an obligation
not to destroy code or its repositories (an obligation not to disseminate
destructive viruses).
<P>This property right gives a hacker the right to earn a living from the
community's code and his/her own modifications.<SUP>4</SUP>
<P><FONT FACE="symbol">&middot;</FONT> <B>A right to autonomy.</B>
<P>There is a right to liberty within the community; to hack in whatever
way the individual wishes; the right not to be exploited, interfered with,
or enslaved. It entails an obligation not to intrude on the autonomy of
others (e.g., with false announcements).
<P><FONT FACE="symbol">&middot;</FONT> <B>A right to welfare.</B>
<P>There is a right to receive a "grubstake" from the community, either
as a newbie or after a destructive disaster. This entails a right to learn
to hack new code (apprenticeship) and an obligation to teach others in
the community. (Property welfare is in our society covered by commercial
insurance.)
<P>Programmers in the free-software/open-source community are not, of course,
in any sense consciously working under these principles; what I have done
is to attempt to take a well-defined set of theoretical rights that apply
to an idealized exchange economy and ask informally whether there is commonality
with what I've observed in the f-s/o-s community. These parallels are interesting.
<P><B><FONT SIZE=+1>Motivations of Open-Source Participants</FONT></B>
<P>What causes programmers to participate in the f-s/o-s community? Several
people have commented on this with interest, and after reading some of
this commentary and after analyzing my own observations, the only possible
conclusion is that people participate in this activity for the full range
of reasons that they participate in any other activity, and it is not realistic
to attribute any particular motive to the entire community, even though
one part of the community might be easily characterized for one reason
or another.
<P>Regardless, there are some important factors to consider, that are important
in understanding the free software / open software communities.
<P><B>Non-economic incentives.</B>
<P>In the beginning of free software, there was "officially" only Richard
Stallman, and he has made his motives clear in his own writings. Some of
those who latched on perhaps shared his motives, but it's also clear that
not all did. Nevertheless, for several years, free and open software was
not commercially useful, so while economic dreams might exist, participants
had to satisfy their economic needs elsewhere. Thus free software was the
hobby of the "rich," and those who devoted time to it were doing so for
reasons other than simple avarice.
<P>By "rich," I do not mean that the participants have been or are financially
wealthy; only that their survival needs are somehow satisfied in a way
that left considerable time for experimentation with free software. Some
may have been wealthy; most simply had "day jobs" or were students with
the usual sources of student support.
<P>My own impression, from the sidelines, was that to some extent the free
software community was a "sandbox culture." That is, like play in a child's
sandbox, some of the work was done for the sheer pleasure of being able
to build something by yourself, which one did not have the opportunity
to do otherwise, for any variety of natural reasons. Linus Torvalds was
quoted in an interview in the November, 1999, <I>Linux Journal</I>, as
saying, "Linux didn't start out as a message to the masses. Unlike Richard
Stallman, I really don't have a message. He has one and can go on about
it forever. I'm just an engineer. Let's see. Do things well! Do them with
heart!..." The desire to build seems to be built into the human psyche,
and to build well is a natural goal.
<P>It is also clear that some participation is morally based, as Stallman's
seems to be; often this is a response or adverse reaction to negative commercial
values such as greed or debilitating secrecy. In any case, as a community
develops, it intrinsically develops a morality that defines its borders
and its purposes. This results in strong and even militant advocacy of
these characteristics. To the extent that non-economic incentives are seen
as an essential characteristic of the community, there will be emotional
and persuasive argument against permitting economic incentives to guide
the community. We have seen such debates.
<P><B>Economic Incentives.</B>
<P>The quality and usefulness of the mature GNU/Linux system has been great
enough to make these tools useful in many ways to people who must make
their living with software. This has led to non-commercial successes such
as <I>Apache</I> and <I>Debian</I> and to commercial successes such as
<I>Red Hat
</I>and <I>Caldera.</I> As a result, we now have a larger community,
which presently includes all the usual economic motives for participating.
This has resulted in the "free" versus "open" software debate, and the
recognition by most people that it is economically appropriate for some
software not to be free. (Overall, the commercial-software community does
not understand the strength of freedom for power and quality, does not
understand its benefits to the end user, and does not understand when software
is most suitably "open" and when it is suitable to keep it "closed.") The
agreement that some software is best "free" and other software may be suitably
proprietary has, of course, resulted in vigorous and sometimes intense
debate about where to draw the grey zone.
<P><B>"Open" vs. "closed" medical software.</B>
<P>The medical community brings a special complication to this debate,
because the information that is kept by this community is <B><I>confidential</I>
</B>.
The requirement for confidentiality will inevitably confuse the debate
about what aspects of medical software may be open-source. Some of this
confusion will likely be deliberate. While the code may be free, the information
it contains and manipulates must never be free. It is perhaps less obvious
that commercial exploitation of this confidential information, whether
or not behind the veil of closed code, is unethical.
<P>Briefly, our need in the medical community is for open-source connectivity
tools, common databases, and open-source security and authentication tools.
That is, we medical professionals need to be able, on behalf of good care
for our patients, to transfer clinical information electronically to other
professionals involved in a patient's medical care, either concomitant
with a referral or by the direction of the patient. At the same time, we
must protect this data from mining by insurance companies, government agencies,
and interested individuals who have no right to the information, and who
might use it in ways adverse to the patient's benefit.
<P>It is clear that user interfaces, productivity tools, and display techniques
can be as proprietary as desired. Business offices, medical ancillary staff,
and physicians do need to have top-level tools that help them work efficiently,
and this is best done by being able to customize theses tools to local
and individual needs.
<P><B><FONT SIZE=+1>Open-source Medical Software Projects</FONT></B>
<P>With this philosophical rubric in mind, let's review current open-source
projects and consider how they meet the need for free code in medical information
management.
<P><B><FONT SIZE=+1>Classification of software:</FONT></B>
<BR>&nbsp;
<TABLE BORDER CELLPADDING=0 WIDTH="525" >
<TR ALIGN=CENTER>
<TD VALIGN=TOP WIDTH="50%">
<CENTER><B><I><FONT FACE="helvetica, helv, geneva">Project</FONT></I></B></CENTER>
</TD>

<TD VALIGN=TOP WIDTH="50%">
<CENTER><B><I><FONT FACE="helvetica, helv, geneva">Classification</FONT></I></B></CENTER>
</TD>
</TR>

<TR ALIGN=CENTER>
<TD VALIGN=TOP WIDTH="50%">
<CENTER>Perceptions</CENTER>
</TD>

<TD VALIGN=TOP WIDTH="50%">
<CENTER>Creviceware</CENTER>
</TD>
</TR>

<TR ALIGN=CENTER>
<TD VALIGN=TOP WIDTH="50%">
<CENTER>DHCP / VistA&nbsp;</CENTER>
</TD>

<TD VALIGN=TOP WIDTH="50%">
<CENTER>Whaleware</CENTER>
</TD>
</TR>

<TR ALIGN=CENTER>
<TD VALIGN=TOP WIDTH="50%">
<CENTER>Arachne</CENTER>
</TD>

<TD VALIGN=TOP WIDTH="50%">
<CENTER>Creviceware</CENTER>
</TD>
</TR>

<TR ALIGN=CENTER>
<TD VALIGN=TOP WIDTH="50%">
<CENTER>Littlefish</CENTER>
</TD>

<TD VALIGN=TOP WIDTH="50%">
<CENTER>Wholeware</CENTER>
</TD>
</TR>

<TR ALIGN=CENTER>
<TD VALIGN=TOP WIDTH="50%">
<CENTER>Tickle-FP</CENTER>
</TD>

<TD VALIGN=TOP WIDTH="50%">
<CENTER>Taskware</CENTER>
</TD>
</TR>

<TR ALIGN=CENTER>
<TD VALIGN=TOP WIDTH="50%">
<CENTER>FreeMed</CENTER>
</TD>

<TD VALIGN=TOP WIDTH="50%">
<CENTER>Cloneware</CENTER>
</TD>
</TR>

<TR ALIGN=CENTER>
<TD VALIGN=TOP WIDTH="50%">
<CENTER>FreePM</CENTER>
</TD>

<TD VALIGN=TOP WIDTH="50%">
<CENTER>Designware</CENTER>
</TD>
</TR>

<TR ALIGN=CENTER>
<TD VALIGN=TOP WIDTH="50%">
<CENTER>Circare</CENTER>
</TD>

<TD VALIGN=TOP WIDTH="50%">
<CENTER>Foundationware</CENTER>
</TD>
</TR>

<TR ALIGN=CENTER>
<TD VALIGN=TOP WIDTH="50%">
<CENTER>QuickQuack</CENTER>
</TD>

<TD VALIGN=TOP WIDTH="50%">
<CENTER>Demoware</CENTER>
</TD>
</TR>
</TABLE>

<P>The classifications are whimsical, and should not need elaborate definition;
there is no "hidden meaning."<B><FONT SIZE=+1>Perceptions</FONT></B>
<P>At the beginning of this decade, the Roger Maris Cancer Center was formed
in Fargo, ND. The staff was faced with the challenge of managing four legacy
systems which could not communicate with each other. Important goals were
to develop an information support system (for the clinicians brought together
by the center) and to increase business efficiency. The usual barriers
were encountered while trying to link the four legacy systems through cooperative
efforts with the vendors, and during this process Linux emerged into the
world.
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Dr. Wettstein has
offered some reflections on my comments, which I quote in this typeface
(Helvetica).</FONT></FONT>
<P>Dr. Greg Wettstein developed this information system, deployed with
Linux 0.96c and continuously upgrading kernels as Linux matured, which
successfully achieved all the functional goals of the group, and which
survived from 1993 until 1997, when it was replaced by a less efficient
commercial system. The design and functionalities of <I>Perceptions</I>
are important to this project.
<P>I call <I>Perceptions</I> "creviceware" because an important prerequisite
for clinical usefulness is to fill the (very large) interstices left by
commercial software, which is characteristically single-task software,
and which is never designed primarily with the information needs or efficiency
needs of clinicians in mind.
<P>Using shell scripts, Dr. Greg created a set of "interrogatory robots"
to mine 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. A modular mid-level
tool set, written in Perl 5, was used to manage this process. The user
interface was written with tcl/Tk.
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1><I>Perceptions</I>
was basically built as a series of software packages that sat on top of
the information distribution system. This design strategy basically flowed
from the fact that Perceptions started out as simple patient tracking software.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>This paradigm actually
proved to be quite powerful. One of the most interesting features of the
system from a pharmacy perspective was that the pharmacy component of the
tracking system actually 'looked' for patients that were scheduled for
treatment. This work was actually motivated by my study of Just In Time
Inventory (JITI) control methods that were being deployed in the late 1980's
and early 1990's in American industry.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>A big component of
ambulatory treatment of cancer patients involves administration of multi-day
treatment regimes, eg. VP16/CDDP, CF/5-FU. The pharmacists would designate
that treatment orders were multi-day in nature and Perceptions would immediately
schedule subsequent treatment dates. On subsequent days the pharmacy software
would watch the tracking logs to see when a patient registered at the front
desk. When they did the orders would automatically be executed in the pharmacy
and labels created to initiate creation of the chemotherapy product.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>This system allowed
logical enhancements to be made to the system. One of the problems with
JITI was that as dose-intensity increased, situations began to arise when
the patient's clinical state warranted discontinuation or modification
of therapy. The pharmacy tracking system component was modified to implement
a state-engine which required that multiple criteria be recognized from
the tracking log analysis before an error could be generated. For example
the patient had to check in to the front desk and be placed in a treatment
room before the order would be executed. Extensive work was being initiated
on this component of the software when the roof fell in.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>The Linux workstations
that composed the system basically replaced terminals at many locations
that were used to contact legacy systems. Typically these terminals had
serial connections to the legacy systems which Linux talked to. When a
patient arrived at the front desk an initial tracking message was broadcast
to all the workstations. These workstations than contributed additional
information that they were able to find on these patients and broadcast
this information as well.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>The software was
designed on the following hierarchy:</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Shell script wrapper
-> Perl functionality -> tcl/TK interface</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>All the utilities
and programs were encapsulated with a shell script wrapper which did things
like parse options etc. Major functionality was implemented with Perl programs
which could stand by themselves if necessary. In the case where a GUI was
needed the Perl scripts were designed to open a wish shell and would talk
back and forth over a bidirectional pipe to implement the user interface.</FONT></FONT>
<P>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.
<P>Subsequent development of 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.
<P>Two crucially important features of this system, not present in any
commercial software I've seen, are that it was specifically designed :
<P><FONT FACE="symbol">&middot;</FONT> to aid clinical decision-making
by collecting, organizing, and displaying information for physicians, and
<P><FONT FACE="symbol">&middot;</FONT> to make the work of business staff
and ancillary medical staff more efficient.
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Another major feature
of the system is that it was actually implementing functional data interchange
long before XML was in vogue.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>The data abstraction
was carried out interestingly enough by using TeX. When a pharmacist entered
an order into the pharmacy component of the system the function of the
data entry was to basically encapsulate all the patient information into
a TeX script. Running the TeX script through a document header file specific
to the needs of the pharmacy resulted in generation of IV labels etc. The
same TeX script run through a document header specific to the nursing unit
caused it to generate a charting label which met the requirements laid
out by the Oncology Nursing Society (ONS) for chart notes.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>This worked to support
one of the most important design criteria of the system. This criterion
was that information obtained and/or entered by one discipline or group
within the center should work to increase or aid the functioning of other
groups. More simplistically we were trying to address the age-old issue
of having to double enter data.</FONT></FONT>
<P><I>Perceptions</I> is no longer in use due to the merger of the Cancer
Center with a large hospital and the administrative insistence on a commercial
"solution." Perceptions is not maintained, nor is the code available to
the community. Dr. Wettstein and his colleague, oncologist Paul Etzell,
MD, presented an excellent summary of their work at the first MIT conference
on Free Software in 1996. Dr. Wettstein has promised to convert this paper
to .html and .ps or .pdf and place it on his web site "shortly" at
<BR>&nbsp;&nbsp;&nbsp; http://www.enjellic.com/
<BR>and he is considering making the entire code available to the free
software community.
<P><I>Perceptions</I> deserves a place of honor in f-s/o-s annals not only
as the first open-source medical information manager but also because it
was thoughtfully conceived, ergonomically designed, and well engineered.
<P>We hope that future medical information management software will be
not only creviceware, but the central software tool of the enterprise.
Still, the special strength of the GNU/Linux system is in communications
and data acquisition, so that this is the best choice for linking disparate
systems no matter what other tasks are assigned to it.
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>I would have to say
quite unequivocally that the most important component of the success of
Perceptions was that it was based on an open source philosophy and toolset.
I was never really afraid of failure since we were in control of all aspects
of the project. If something didn't work we simply invented something different
that did work. That sense of flexibility and solution mobility simply does
not exist when working with commercial solutions.</FONT></FONT>
<P><B><FONT SIZE=+1>DHCP / VISTA</FONT></B>
<P>This is the medical software project of the (USA) Veterans Administration
system. We'll call this <I>Whaleware</I> because it is the largest public-domain
medical information mammal on earth. Originally called the DHCP (Decentralized
Hospital Computer Program), it was begun in 1982. It is now called <B>VistA</B>,
Veterans Health Information Systems &amp; Technology Architecture. Information
about this sophisticated and complete medical information system is available
at the VA's web site at
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; http://www.va.gov/vama.htm
<BR>and at a programmers' web site
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; http://www.hardhats.org
<BR>where it is maintained by volunteers who are current and former employees
of the Department of Veterans Affairs (DVA). The VistA system is available
on CD-ROM through a Freedom of Information Request, which can be initiated
at the hardhats web site. Some software components have been published
to the hardhats web site. A full descriptive monograph is published at
http://www.va.gov/monogrph.htm
<P>VistA is clearly well developed and in use. It comprises more than 80
integrated DHCP applications which include both administrative and clinical
functions, including medical imaging, laboratory management, and pharmacy
management.
<P>The M computer language is the foundation of DHCP / VistA. This non-proprietary
4GL began life at Massachusetts General Hospital as MUMPS, and has become
an ANSI-standard programming language, database management system with
related bindings and protocols (for a non-technical explanation of M, see
http://www.mcenter.com/mtrc/whatism.html).
<P>I do not know whether this work, designed around the needs of the VA
system, could be "ported" to the private-sector medical community with
an acceptable expenditure of time and effort. There are two barriers to
use: the M language, which "makes sendmail scripts seem organized and Perl
seem well structured;" and that it was designed around the needs of the
VA system, which is like no other medical organization on earth.
<P><B><FONT SIZE=+1>Littlefish</FONT></B>
<P>The <I>Littlefish</I> project is an ambitious enterprise led by an Australian,
Chris Fraser, to bring the power and efficiency of database tools, particularly
epidemiologic analysis, to third-world and remote practices. The project
will follow the GEHR or Good Electronic Health Record standards (see http://www.gehr.org/
The GEHR standards are at http://www.gehr.org/gehr_architecture.html in
.pdf format).
<P>I lightheartedly call such software "wholeware" because their goal is
to be a complete solution to the perceived needs. This project is in design.
I have not investigated it in detail yet.
<P><B><FONT SIZE=+1>Tk-FP</FONT></B>
<P>This is a personal project of Dr. Alexander Caldwell, a family physician
in California. He uses tcl/Tk to produce an information-gathering and documentation
system. Features include menu-driven progress note generation, prescription
management, preventive health management, and importation of lab values
from his lab information system.
<P>This software is available for Linux, Windows 95/98/NT, and Macintosh
OS's. It is oriented toward specific tasks important to the physician,
so I'll call this "taskware."
<P>Dr. Caldwell is constructing a system that serves the primary care physician's
ergonomic needs, as can be seen by his list of working modules. Inspection
shows that some of these tasks are essential to efficiency, others are
decorative enhancements made possible by powerful software tools. I quote
from his own description.
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Insert drawings into
progress notes - mods to Impress, a Tcl/Tk program. Store templates for
various anatomical or other drawings, draw on them, then save directly
into a progress note.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Lab Results - automated
download from an IBM AS/400 directly into Tk_familypractice with some user
intervention on Linux only. Requires a TCP/IP connection to the AS/400.
Script edited by hand to suit each user's log in and host configuration.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Clinical Decision
MAPs - integrated with progress note writing module. Tcl/Tk widgets used
in clinical decision making algorithms create chart notes as you interact
with the program.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Prescription Module
- Fax based, stores and sends drug refill information to drugstores. The
stored data can be used to compile a medication list for inclusion in clinical
notes. Prints hardcopy Rx and patient education monograph for the patient.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Demographic Data
Module - addresses, phone numbers etc.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Problem List Module
- stores problem list, allergies, past medical history. Data can be inserted
into clinical notes.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Progress Note Generator
- History and Physical Synthesizer - GUI based program that presents menus
for numerous common office problems or presenting complaints. Your commonly
used phrases can be inserted at the click of a mouse. Phrases are easily
added or removed from the menus. Automatic saving to patient's file and
a daily file that can be printed out at the end of the day for hard copies.
Integrated with the other modules so data from problem list, allergies,
medications can be inserted into the notes with the push of one button.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Progress Note Display
Module - data stored as HTML so you can insert pictures, tables, etc. and
enables data to be accessed via a web server. Can work with IBM's Via Voice
for speech recognition under Windows 95/98, or run the Linux version on
one machine and use X-win 32 (an Xwindow server that runs on a Windows
machine) for the display to dictate into the Tk text widgets using Via
Voice with the data stored on the Linux machine.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Allergy Checking
- checks prescription refills against patient's allergies</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Drug Interactions
- checks prescription refills against the patient's drug profile for drug
interactions.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Drug Doses - checks
prescription refills for appropriate doses, with Pop-up menus.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Drug Information
- patient package insert information can be viewed or printed out for the
patient.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>HMO authorization
request generation - generates an HMO authorization request form that can
be faxed or send via e-mail to an HMO office. Includes copies of progress
notes you specify.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Recall Letter Generator
- when writing a progress note, you can set a future date for a recall
letter .</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Referral Letter Generator
- fax or e-mail a referral letter to the consultant, including a copy of
your patient's progress note if desired. You just highlight the part of
the note you want to send and pick from a menu of consultants you use.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Statistics - view
or print various stats on no. of prescriptions, list of patients on a certain
drug, most commonly prescribed drugs etc.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>Graphic data plotting
- scan your data and plot weights, blood pressures and lab data, etc.,
over time.</FONT></FONT>
<P><FONT FACE="helvetica, helv, geneva"><FONT SIZE=-1>The modules are linked
so that if you are working on a patient's drug refills, all his or her
data in the other modules are pulled up at the same time so you have access
to all information on that patient if you need it.</FONT></FONT>
<P><B><FONT SIZE=+1>Arachne</FONT></B>
<P>The Arachne project was a "Toolset for the Development of Clinical Workstation
Applications from Distributed Components." It currently is a more general
tool designed to provide an extensive, CORBA-2 compliant, object-oriented
tool set for integration of disparate systems. The first iteration was
done in order to permit the development of clinically useful tools. The
Arachne group, whose principals were IT specialists in Massachusetts, was
part of an "Internet Collaboratory" project, InterMed, that included medical
informatics specialists at Columbia, Stanford, Massachusetts General Hospital,
and others. This part of the project has been abandoned. The open source
license does not include any healthcare-specific parts of the code. So
at this point the project has been pared down to purely an open source
CORBA implementation.
<P>The motivation for its development was the frustration inherent in the
current state of commercial medical software, based primarily on large,
single-vendor systems not designed for integration or customization. This
is characterized by a lack of common software infrastructure, services,
or paradigms. The Arachne project has as its goal the ability to construct
richly interoperating software components via a suite of cross-platform
software tools, collectively referred to as Arachne. A description of this
ambitious project is at
<P>http://www.arachne.org/arachne_overview.html
<P>Work on Arachne began in 1992. Its first release was in August, 1997;
its current version is 0.8.4.2, is dated Dec 16, 1998. The developers of
course discovered that cost and limited function prohibited the use of
commercial products as a basis for portable component development and integration.
The development of Arachne required laborious tracking of relevant and
conflicting industry standards, and consists of several largely independent
subsystems, which are capable of platform independence and permit the construction
and integration of arbitrary software components. Arachne is currently
available for Windows 95/NT, Linux, HP/UX, SunOS, and Macintosh .
<P>Arachne fits into the category of "creviceware" because its most important
purpose was to permit connectivity and data exchange for the purpose of
presenting integrated medical data to clinicians to support decision making.
<P><B><FONT SIZE=+1>Freemed</FONT></B>
<P>This is a project of a Connecticut IT professional, Jeff B, and a podiatrist.
It is designed to be an functional clone of a commercial medical management
system, The Medical Manager
<P>(http://www.mdmgr.com/).
<P>It uses MySQL, a proprietary SQL server. It is functional. I have not
been able to access its site for a couple of weeks, so I don't know the
current public status of the project.
<P>Its chief limitation as an open-source/free software "solution" is that
it was designed to duplicate the functionality of a particular commercial
product, and thus has the inherent limitations that this design approach
entails.
<P><B><FONT SIZE=+1>FreePM</FONT></B>
<P>FreePM is a new project, aiming to produce a completely open-source
practice management system. Design was begun in June, 1999.
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; See http://www.freepm.org/
<P>The design of this project appears to be carefully done, and the database
is currently in design.
<P>PostgreSQL is being used for the database; ZOPE for middleware. They
plan to use CORBA based OMG's (object management groups).
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; see http://www.omg.org/omg/background.html
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
http://www.zope.org/
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
http://www.corba.org/
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
http://www.postgreSQL.org/
<P>FreePM's efforts are being coordinated with Circare.
<P><B><FONT SIZE=+1>Circare</FONT></B>
<P>Circare is a new project to build an open source patient centered network
index system. It is a commercial project of Minoru Development, Inc., a
Toronto firm. Primary funding has been by the non-profit Hamilton, Ontario,
Information Network, HappIN. The project's goal is to provide key infrastructure
for Regional Health Networks, by developing new modules which include
<BR><FONT FACE="symbol">&middot;</FONT> a clinical management system,
<BR><FONT FACE="symbol">&middot;</FONT> a Web-based physician-pharmacist
consultation system (this involves an effort by pharmacists to electronically
notify physicians of the full list of medications--including herbal remedies--taken
by an individual and potential interactions; and
<BR><FONT FACE="symbol">&middot;</FONT> a geriatric patient index: this
includes a minimum clinical data set.
<P>Circare is a client and provider index that ties together the information
about a single patient and makes it available securely to care providers
in a distributed network. Thus it aims to be a solution to the "portability"
problem that hinders the exchange of clinical information necessary to
care for patients as they are referred from one provider to another in
an extended health care system, or as they necessarily change primary providers
for all the usual reasons.
<P>Overall, this appears to be a sophisticated and well-managed project
by experienced IT professionals.
<P>Circare is open source software, distributed under the GNU public license:
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; http://www.fsf.org/copyleft/gpl.htm
<P>Minoru Development maintains a web page that collects all the open-source
efforts related to health care
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; http://www.minoru-development.com/en/healthcare.html
<P>Minoru sponsored an Open Source Practice Management Summit, held in
Toronto, Canada, on September 23, 1999. I was not able to attend this conference,
and have not seen a summary of it yet. At this conference, Minoru staff
offered to coordinate open-source coding projects by sponsoring a discussion
group and offering space.
<P><B><FONT SIZE=+1>QQ-MIM</FONT></B>
<P>QQ-MIM is my project. It began in 1985, when I changed practices, and
been able to learn about database, medical software, and microcomputers,
so that the clinician's need to gather information came into focus while
I adjusted to a new charting system at the same time that I became fully
aware of the potential of computers as a tool to information storage and
retrieval. I wrote a long specification that I whimsically called "QuickQuack"
that described the ergonomics a physician needed in such a system, but
was unable to persuade any of the leaders I knew in software firms to invest
their capital in solving all the world's problems.
<P>It also turned out that the leadership of my clinic and most of the
other physicians were extremely comfortable with the world as it was, and
had neither sufficient discomfort with the limitations of the paper chart
to motivate interest, nor sufficient knowledge of computing to understand
what I was trying to say. In retrospect, they have not been interested
in learning, either; but I naively believed that if they saw a system that
put a few concepts into practice, that the light would dawn. It has not.
<P>Meanwhile, my First Offspring, Michael K. Johnson, who had been immersed
in the free software world since Linus Torvald's first post, has worked
diligently to educate me on its potential.
<P>After I was done paying college tuition, I decided to fund a demonstration
project with some simple programming. Stage One was the development of
a simple progress-notes reader: In this project we took a collection of
ASCII progress notes, created a simple PostgreSQL database, and used Perl
to create a reader that displayed each patient's notes in a standard browser,
in reverse chronological order.
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; http://www.postgreSQL.org/
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; http://www.perl.com/
<P>Stage Two was the development of a prescription-tracking system. This
was done in two steps: First, the drugs in the FDA Orange Book (available
in several segments on the web) was reduced to a PostgreSQL database.
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; http://www.fda.gov/cder/ob/
<P>Later, ZOPE was used to create a medication-tracking system and prescription
writer that is still in development.
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; http://www.zope.org/
<P>One criterion of this project has been to use only free software, and
to donate the finished work to the free software community when it is sufficiently
mature to do so.
<P>During this project, I came out of my hole into the sunlight and looked
around, blinked, and discovered that several other projects were under
way, most begun in 1999, to perform many of the same functions. This has
redirected my interests toward the overall effort to create a free-software
medical information manager; the most important question to answer, in
aiming to contribute, is to ask how free software can be most useful to
the medical community.
<P>The functional priorities seem clear to many people: connectivity, data
exchange, and usability (ergonomics) are worth attention, energy, and time.
A crucial secondary priority, because we deal with confidential information,
is authentication and security. (It is secondary not in importance but
is functionally subordinate to the task of achieving connectivity and exchange
while creating tolerable ergonomics.)
<P>I assume that you understand the need for connectivity and easier data
exchange. It is not clear whether the need for efficient ergonomics is
well understood by anyone. Administrators seem to assume that the inherent
efficiencies of computers are obtained automatically; programmers insulate
themselves from users to increase their work output and do not do "time
and motion" studies to see if users are actually made efficient. Users
are hindered both administratively and technologically from making their
tasks more efficient. Physician-users sometimes have the power and sophistication
necessary, but tend to be afflicted with egocentrism, which tends to produce
idiosyncratic solutions rather than general solutions.
<P><B><FONT SIZE=+1>Important tasks for medical software projects:</FONT></B>
<P>I believe that the most effective evolution of free and open source
medical information management software will be roughly like this: First,
the greatest strength of the GNU/Linux system is connectivity. This is
why the first clinically effective use of free software, the <I>Perceptions</I>
project, was "creviceware," a collection of tools and programs that made
connectivity and efficiency possible among independent commercial products
that were never designed to work together.
<P>Second, free and open software tends to begin as hobby projects. These
begin with individuals designing tools that meet their own needs. Superficial
examination of such projects may leave the impression that they are purely
idiosyncratic; the truth is that beneath the idiosyncracy there are usually
useful, generalizable paradigms. More importantly, they serve as demonstration
projects that teach users, observers, and programmers how to make the next
iteration of software design more efficient and functional. In this stage
specific tools are designed -- "taskware."
<P>If specific tools are designed <I>within</I> a culture that understands
their design principles ("has a clue") and recognizes the importance of
connectivity, then the project can begin to actually reshape the medical
community, producing "wholeware" -- software systems that actually begin
to meet the needs of an enterprise.
<P>At first, these enterprise systems will need to "embrace" proprietary
legacy software; but as the power and flexibility of using open code becomes
generally understood, strictly proprietary solutions will atrophy.
<P>How can we best proceed to build shareable open code? I believe that
the following conceptual foundations are necessary:
<BR><FONT FACE="symbol">&middot;</FONT> Protocols and data structures for
area-wide exchange of individuals' basic health information: a <B>"medical
demographic."</B> This is the significance of the <I>Circare</I> project
in Hamilton, Ontario.
<BR><FONT FACE="symbol">&middot;</FONT> Agreement on <B>database design
</B>.
I believe that it is important for the medical f-s/o-s community to maintain
a common database design, independent of code. This is the significance
of the <I>FreePM</I> project of Tim Cook.
<BR><FONT FACE="symbol">&middot;</FONT> Free availability of <B>coding
systems
</B>for clinical information. The fact that the CPT system is proprietary
to the AMA is a great hindrance, and the AMA should be pressured to make
this coding system freely available to the community, under appropriate
commercial restrictions that permit the AMA to recover the high costs of
maintaining this complex system.
<P>Let's look at these principles in more detail.
<P><B><FONT SIZE=+1>Foundational needs of open-source medical software</FONT></B>
<P>Contemplating the various f-s/o-s efforts that are being attempted,
and the work that has been done, such as the Health Level 7 project (http://www.hl7.org/
), to create data standards for medical software it is difficult to envision
how to effectively corral the enormous efforts that are going on and harness
them to a single wagon.
<P>Each "player" is performing in a different arena; has unique needs;
has individual priorities. There is such a large variety of tools and mid-level
languages that it is difficult to envision how it may be possible to provide
a substrate suitable for every need.
<P>I conclude that it is impossible to create a software project that can
encompass the needs of everyone in the medical community, and therefore
we should not attempt to do so. Instead, we must focus first on identifying
the commonalities: what <I>everyone</I> needs (whether they realize it
or not).
<P>Let's approach this logically. The reason this community exists is to
provide health care for individuals. Hence the first consideration is,
what are the fundamental "data needs" of the individual?
<P><B>Demographics must include health information</B>
<P>The first mistake made by commercial software developers is to assume
that the standard "demographic information" is an adequate description
of a patient. It is not. For billing we try to collect enough information
about each person to uniquely identify them. Name and date of birth are
the starting points; in a large population this is not sufficient. Social
security number is used in the USA, but organizations do not have a legal
right to require this, and many people either refuse or provide a false
one. So we collect a large amount of ancillary, usually temporary, information
that serves to locate rather than identify persons.
<P>But in all this effort, we have not included in our demographics the
<I>medical</I> identity of the patient: their <I>conditions</I>. Every
physician knows that this is the medical identity of a person; this is
why we refer to "the gallbladder in room 320A." Such talk can be demeaning,
but in a professional context it is a whimsical way of focusing discussion
on a disease process rather than on a personality.
<P>So a minimum medical demographic must include some version of what is
called a person's "problem list." The fact that this is not "public knowledge"
and must be protected from inappropriate access and use has been an absolute
hindrance to adding it to the demographics. But medically to do so is an
absolute necessity. There is a corresponding obligation to include in the
specification of the complete medical demographic <B>a confidentiality
rule and procedure</B>.
<P>This rule and procedure is at its heart simple: the public and non-public
data in the medical demographic record must be differentiated within the
record; release of non-public data is permissible from one provider to
another in order to provide health care to the individual and other release
is permissible only with the express, documented, permission of the individual.
Any software project must therefore include security procedures that permit
protection of this confidentiality.
<P>But without this "problem list" the patient remains "unidentified" medically;
no software will be clinically useful that excludes this data.
<P>As an aside, it is worth mentioning that all the information in the
demographic record, <I>including the patient's name,</I> may be considered
confidential and non-public by the patient. Famous or notorious people
may not want anyone to know they are part of your organization's client
list; telephone numbers may be unlisted, addresses private. The medical
information is <I>especially sensitive</I> to breaches of confidentiality,
but it is proper and prudent to give equal importance to preserving the
confidentiality and privacy of every datum held on a person.
<P>This has smaller implications for area-wide data repositories than might
be thought. First, the patient must be informed that this area-wide repository
exists, its purposes, the conditions under which consent to share data
is implied, the conditions under which explicit release is necessary, and
the recourse the patient has for violations. If all the organization's
data is held in an off-site repository, the organization has the responsibility
to ensure its security and confidentiality. There is no reason for an individual
to object to an area-wide data-sharing arrangement if the privacy protection
is as good as it should be.
<P>In fact, practices are already beginning to use data services located
as far as across the continent from the practice location, and there will
of course the suspicion that vendors will mine this data for commercial
purposes. I have no doubt that this will occur unless contractual and procedural
protection is added to the legal protections that already exist.
<P><B>Dynamic inaccuracy.</B>
<P>The most important feature of the medical demographic is its <I>dynamic
inaccuracy
</I>. What do I mean by this?
<P>Persons are real, and exist until death (after which they are at least
no longer dynamic). Any demographic information is a representation of
a person, to permit indexing of records and to aid locating persons in
order to communicate with them. Historically, the only interest in communicating
with the patient was to send a bill. Recent changes in practice paradigms
have led to communications about health maintenance, which a cynic would
see as a means to ensure the sending of more bills.
<P>Anyone who has ever interacted with demographic records knows that they
are inherently inaccurate for several reasons:
<BR><FONT FACE="symbol">&middot;</FONT> The person is constant, but characteristics,
even names, change.
<BR><FONT FACE="symbol">&middot;</FONT> Typographical errors and incomplete
or partially duplicate entries are made by operators.
<BR><FONT FACE="symbol">&middot;</FONT> Locations change.
<BR><FONT FACE="symbol">&middot;</FONT> Medical conditions change.
<P>This means that any demographic record is only temporarily accurate,
and that the degree of inaccuracy will increase with the passage of time.
I call this <I>dynamic inaccuracy</I>, and it is, in my judgment, the most
important characteristic of a demographic record.
<P>Thus the most important task for the keeper of the record is maintenance.
Who is willing to take responsibility for "keeping" the record? There are
four people who have clear and primary interest in its accuracy:
<BR><FONT FACE="symbol">&middot;</FONT> the person about whom the record
is a summary
<BR><FONT FACE="symbol">&middot;</FONT> the medical professional using
the record to make healthcare decisions
<BR><FONT FACE="symbol">&middot;</FONT> the fiscal intermediary who is
responsible for making proper compensation for correct claims
<BR><FONT FACE="symbol">&middot;</FONT> the programmer who creates the
repository and the tools to access it.
<P>Note that this list <I>does not</I> include the well-meaning receptionist
who records the information in the data repository, the manager of the
clinic or hospital providing care, or anyone's attorney. These folks have
a <I>secondary</I> interest in its accuracy.
<P>Successful continual validation of the dynamically erroneous record
requires that there be an <B>audit trail</B> of changes. It should include
(or point to) the prior field contents and the new contents, and include
<I>when</I> the change was made, <I>who</I> made the change (i.e., who
was the source or informant and which entry tech recorded the change),
<I>why
</I>the change was made, if a reason is relevant (such as "marriage"
"adoption" or "divorce" for a name change; "moved" "postal office directive"
or "temporary address" for an address change). This audit trail need not
be kept forever; once changes are validated independently and confirmed,
the audit trail becomes irrelevant, and the record is ready to acquire
fresh inaccuracy.
<P>The remarkable thing about our current record-keeping practices is that
we never allow the person whose data is stored to see, enter, or verify
its accuracy directly. With rare exceptions, even the medical information
stored there is not reviewed or verified by the healthcare professional
who created it. (In most current systems this is the collection of diagnosis
codes in the accounts-receivable system.)
<P>A goal therefore, of any clinical information system must be to allow
the patient and the physician each to have access to this summary record
and to propose corrections to it.
<P>What should this "medical demographic" contain?
<BR><FONT FACE="symbol">&middot;</FONT> Identifying information
<BR><FONT FACE="symbol">&middot;</FONT> Location
<BR><FONT FACE="symbol">&middot;</FONT> Payors
<BR><FONT FACE="symbol">&middot;</FONT> Medical data set.
<P>The minimum contents of this medical data set are well known to practitioners:
<BR><FONT FACE="symbol">&middot;</FONT> Medication allergies and intolerances
<BR><FONT FACE="symbol">&middot;</FONT> Active medical problems
<BR><FONT FACE="symbol">&middot;</FONT> Past health events that will affect
future health decisions
<BR><FONT FACE="symbol">&middot;</FONT> Heritable health influences
<BR><FONT FACE="symbol">&middot;</FONT> Continuing medication use.
<P><B>Ergonomics</B>
<P>Two seductive characteristics of computers lure the unsuspecting: the
potential for automated data handling, and the possibility of enhanced
efficiency. But computers do not save time, money, or effort -- unless
they and their use are managed intelligently and with discipline. To use
computers to manage large databases efficiently and effectively does require
technical expertise. <I>Ergonomic design for efficiency requires detailed
knowledge of how specific work is or should be done</I>.
<P>Studies have shown that the chief barriers to acceptance and deployment
of computerized medical record systems are <B>cost</B> and <B>usability</B>.
It is not my purpose to address cost, except to note as an aside that medical
enterprises are throwing away money on commercial systems that turn out
to be extremely expensive to maintain due to needless inefficiency and
to the economic captivity of <I>vendor lock</I>.
<P>It is important to acknowledge the major barriers to usability, well
identified in the literature:
<BR><FONT FACE="symbol">&middot;</FONT> workflow integration
<BR><FONT FACE="symbol">&middot;</FONT> geographic access to devices
<BR><FONT FACE="symbol">&middot;</FONT> the importance of actually improving
productivity
<BR><FONT FACE="symbol">&middot;</FONT> the effect of the "learning curve"
on the use of systems
<BR><FONT FACE="symbol">&middot;</FONT> the effect of failing to use web-based,
modular, "lightly structured" approaches.
<P>Executives seldom have knowledge of either information technology or
physician work patterns; in any organization they tend to isolate themselves
from detail and often become captives to a whirlwind of communication with
each other and communiques to their underlings. IT professionals and physicians
are both often thought to be too "narrow" to be effective leaders; American
management culture is mistrustful of experts, who are presumptively viewed
as egocentric and biased, as if ignorance granted objectivity or wisdom.
<P>Commercial medical software has been and remains "pieceware," applications
designed to serve a particular part of the enterprise. More importantly,
data exchange with other applications has been completely and deliberately
ignored, in the best circumstance to ensure that when a company expands
its efforts to another area within the medical enterprise, it will not
have "given away" anything to a potential competitor.
<P>The first software in clinics and hospitals was <I>accounts-receivable
</I>systems,
and these products continue to dominate the market. They have been completely
unsuccessful in producing useful computerized medical record applications
because they have designed their efforts around the needs and requirements
of medical records technicians, which has characteristically produced software
that is ergonomically stressful for physicians.
<P>Comprehensive <I>laboratory</I> data-management systems have emerged
in this decade; they are chiefly oriented to the needs of laboratory technicians
and their regulatory responsibilities; providing data to clinicians is
superficially considered, and interfacing to clinical systems is not planned
for.
<P>Pharmacy software has emerged to aid in pharmacy management and dispensing;
this has not been designed with the idea of providing integration with
physician prescription-writing, or receiving prescriptions from physicians
with electronic validation.
<P><I>Transcription </I>software has been designed around the needs of
typists, and has not been planned to create any kind of a structured record
that might be useful in creating even a modestly useful database.
<P>Some <I>hospitals</I> have tried to create ordering software and integrated
charting; but these are characteristically oriented toward complete documentation,
not for ergonomic efficiency; in any case, the hospitals that have felt
able to invest in such systems are large and complex; the temptation is
to try to do everything imaginable at once, which spawns bloatware, and
hinders the discipline that could progress from a simple system that does
essential, easily-automated tasks well into a collection of simple systems
that interact smoothly, later adding features and complexity in a logical
and ergonomically-driven sequence.
<P>A few <I>physicians</I> have tried to create electronic medical records;
not surprisingly, the only clinically respected EMR/CPR systems are those
that have been designed by physicians for clinical usefulness. These developers
have discovered that integration with legacy systems, especially those
doing accounts receivable and laboratory data management, has been an interesting
and laborious challenge.
<P><B><FONT SIZE=+1>Security, Confidentiality, and Authentication</FONT></B>
<P>It is not my goal to reproduce here the important discussions that have
taken place regarding the challenge that the Internet presents for security
and authentication for system access and data exchange. Instead, I wish
to point out that there are several important issues, of which the technological
challenge of S &amp; A is only the foundation.
<P>It is worth pointing out, as an aside to this discussion, that the most
important threat to confidentiality of medical information is <I>not</I>
unauthorized access to either paper or electronic records. The greatest
threat is <I>authorized</I> access. Insurance companies, in particular,
have for decades habitually required applicants to sign a blanket release
for all medical records. Their signature authorizes exactly this, and clinics
comply. What electronic records do is merely to make release easier and
less expensive, and permit extremely sophisticated searches and statistical
analysis. They also present an opportunity to use the information for commercial
purposes without release, which itself presents some ethical concerns.
<P><B>Confidentiality</B>
<P>Ethically, all information regarding a patient, whether provided voluntarily
or at the insistence of the nice receptionist, or produced by the clinicians
and consultants, belongs jointly to the patient and the organization; despite
having a share in ownership, the organization has only a limited "property
right" over this information, as the patient has a greater interest in
its control and more to lose by mishandling than does the organization.
<P>There are no ethical levels of confidentiality; there are regulatory
levels, related to the adverse consequences to the organization or to individuals
in it that may follow inappropriate release. The organization does not
have the right to release even the "public" information about a patient,
for to do so reveals that the patient is in fact a client of the organization.
<P>Based on the likelihood of "injury" to the patient and the consequences
to the miscreant of inappropriate release, there are at least three levels
of confidentiality:
<BR><FONT FACE="symbol">&middot;</FONT> Public information: address, telephone
number, names of related persons, etc.
<BR><FONT FACE="symbol">&middot;</FONT> Routine medical information: ordinary
diagnoses, lab results of no "general" interest and so on.
<BR><FONT FACE="symbol">&middot;</FONT> Sensitive medical and counseling
information: psychology and psychiatry notes, pregnancy test results, lab
results and clinical notes regarding sexually transmitted disease and the
like.
<P>Because of this construct, clinics customarily create "superconfidentiality"
for psychology notes and HIV test results, which in most states is protected
by law.
<P>Thus any medical information management system should be designed to
provide multiple levels of confidentiality.
<P>Medical enterprises depend primarily on a <I>culture of confidentiality
</I>rather
than strict policing to preserve the privacy of medical records. The rules
have been simple and clear for ages; the incentive to comply with these
rules is part of "professionalism," and we store the records in mildly
inaccessible places, not in bank vaults. Within our buildings, we leave
charts laying all over, in stacks that are part of the records-handling
process, and only a few employees are permitted (by rule) to have access
to them. Security <I>within an intranet</I> can use professionalism similarly
to keep security procedures simple enough that they do not hinder efficient
work.
<P>But the Internet poses special problems for security and authentication,
both to make sure our firewalls effectively prevent unauthorized access,
but also with the growing use of off-site data storage pioneered by Oracle
and others, to devise effective protections against both confidentiality
breaches and against commercial exploitation of their contents.
<P><B><FONT SIZE=+1>Clinical data</FONT></B> (database design)
<P>The key to creating a community medical informatics system is common
agreement on the database configuration. It is not necessary to agree on
every detail, as any user is free to modify the structure and any code
as desired. But the felt need for such modifications will be minimized
by careful attention to defining the essentials. The <B>FreePM</B> project,
led by Tim Cook, is paying careful attention to database design in this
manner. He realizes that it is more important to design well than to begin
coding promptly. He expects to spend several months with database design.
<P>There are four arenas which require this fundamental attention:
<P><B>Professional fees</B>. To create a billing system for the salaried
health care provider is a non-task. All other professionals have some fee
structure that has these components:
<BR>- the service(s) provided
<BR>- the condition(s) treated
<BR>- the identity of the provider (with location)
<BR>- the identity of the patient (with location)
<BR>- the date or duration of the encounter
<P><B>Clinical documentation.</B> This is most importantly "progress notes,"
but also related records such as prescription or medication tracking, problem
lists, immunization history, growth charts, pregnancy flow sheets, and
other documents created by the provider that serve as an institutional
memory.
<P>We must remember, in designing the database, that individual practitioners
have strong personal preferences for various types of organization and
presentation of clinical documents, so the database design must not presume
any particular display organization for the elements that contribute to
this material.
<P>For example, some providers produce a single, unfragmented, narrative
clinical document for each encounter. At the other end of the spectrum
are technologically sophisticated providers such as Dr. Alex Caldwell,
author of Tk-FP, who has written finely granular menuing software that
permits creation of a progress note via mouse clicks from boilerplate text
and can past text from the problem list, medication list, etc.
<P>The solution for the database designer is to create a finely granular
structure, as this can accommodate the highly subdivided note structure,
and can be easily adapted to the needs of the user who creates a less structured
note.
<P>But to create a clinical record, even an organized one, is not the real
task. The real challenge is to create a clinical record from which either
oneself or <I>another provider</I> can easily cull newly-important information.
The difficulty of this task is apparent when one thinks about the fact
that the record created today, for a well patient with a sprained ankle,
may be reviewed next month when the same person presents with abdominal
pain. The fragments of history and observation that are <I>generally pertinent
</I>across
time need to be recorded or displayed differently that those fragments
that are not of enduring interest medically, and are preserved only because
the profession of law has a representative down the block who also may
serve the patient in the indefinite near future.
<P>What does a clinician actually look for in reviewing past notes. I claim,
based on twenty years of experience in internal medicine, that a clinicial
is never interested in the continuous narrative of an old note. We chiefly
look for the following types of information:
<BR><FONT FACE="symbol">&middot;</FONT> The (approximate) date of onset
of a chronic condition; e.g., when hypertension was noted, or diabetes
began.
<BR><FONT FACE="symbol">&middot;</FONT> The(approximate) date and nature
of any life-changing isolated events; e.g., when the left ankle fracture
occurred, how severe it was, and what treatment was used; or when the laparotomy
was done, why, and what was found; or significant but temporarily medical
illnesses like tuberculosis.
<BR><FONT FACE="symbol">&middot;</FONT> A history of (dates of and results
of) "health maintenance" actions: e.g., mammograms, endoscopies. immunizations,
pap smears, and the like.
<BR><FONT FACE="symbol">&middot;</FONT> A medication history: allergies
and intolerances, hopefully with a contemporaneous description; what medications
were prescribed (especially for chronic conditions), what was the clnical
response, and when and why they were discontinued.
<BR><FONT FACE="symbol">&middot;</FONT> Treatment history of chronic disease:
especially radiation or chemotherapy for malignancies, immunologic treatment
of non-malignant disease (e.g. Crohn's or RA), or significant changes in
insulin regimens for diabetics
<BR><FONT FACE="symbol">&middot;</FONT> "Descriptive" historical data:
baseline and recent chest xrays, EKG's, laboratory values, weight, blood
pressure, visual acuity, etc.
<P>We tend to depend on <I>summaries</I> for this information, and so look
for hospital admission and discharge summaries, surgical reports, radiology
reports, problem lists, and laboratory flow sheets.
<P>Ergonomically, the clinician's task in reviewing past clinical notes
is to sort out what has become "chaff" from what has been made "wheat"
by the current complaint. It is possible to design our database, the display,
and the user interface either to hinder or to expedite this task.
<P>New enforcement pressures have been put on providers from the US government,
which threatens criminal fraud action if the "level of documentation" does
not match or exceed the "level of care" charged for. This has resulted
in sometimes massive increases in verbiage to guarantee that the clinical
note is as fat as the professional fee, and the result for the clinician,
winnowing old notes in the chart for kernels of crucial information, has
been a blizzard of chaff that often successfully obscures essential factoids
and at least make the information-gathering task laborious.
<P><B>Dual-track Clinical Notes Record Needed.</B>
<P>The best solution to this challenge is to judiciously fragment clinical
notes, using boilerplate as needed for documentation of charges, but to
store separately the <I>boilerplate</I> and any <I>customization</I>. The
electronic record, then, would consist of a collection of pointers to boilerplate
text and a collection of unique observations about the individual.
<P>When the entire note is to be printed or displayed, the boilerplate
and customizations are merged to produce a complete document; but the clinician
when viewing the record can choose to view only the unique observations.
<P>Problem lists, flow sheets, medication lists and prescription writing
are all features of a clinical notes system that each requires its own
specification. It is not now my purpose to create such specifications.
<P><B>Clinical supporting data: intelligent system needed</B>.
<P>This supporting data is pre-eminently laboratory results. The clinician's
need for presentation of this data is usually different than the standard
laboratory output provides. Hence the extensive use of <I>flow sheets
</I>in
clinical practice, for patients with conditions that persist for some time.
Not nearly enough is done with data analysis. We need an <B>intelligent
system</B> to mine and present this physiologic data in ways that are pertinent
to the patient's current and continuing medical conditions.
<P>This intelligent system would, based on the diagnoses in the patient's
"problem list" (summarized as ICD-9 codes, for example) and the presenting
complaint(s) (gathered by ancillary staff and summarized as V-codes, for
example), "mine" the electronic record for pertinent laboratory data, radiology
reports, health maintenance actions, and relevant clinical notes. It would,
between the time the patient checks in and the time the physician joins
the patient, prepare customized flow sheets of lab data and an index to
relevant narrative notes, and have these available for display on screen.
<P>Here's how this could work for laboratory results:
<P>The flow sheet format that will work best is one which does not display
empty columns, and that "collapses" into a single column those values obtained
on approximately equivalent dates. The older the lab value, the less important
for clinical decisions is its exact date. Use actual dates for the past
month, monthly dates for four months, quarterly for a year, and then annual
data telescoped in single columns. The "collapsed" or "telescoped" columns
might contain several values, in which the rang) and number of observations
could be reported, e.g.,
<BR><TT><FONT FACE="courier, courier new"><FONT SIZE=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|alk ptase | 32-75 (4)
</FONT></FONT></TT>| .
<BR>If exact numbers are wanted, the user should be able to reference the
cell or column with the cursor or keystrokes and "expand" perhaps by clicking
on it. e.g.,
<BR><TT><FONT FACE="courier, courier new"><FONT SIZE=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
YR - QTR - MON - DAY .</FONT></FONT></TT>
<P>The rightmost column could simply be labelled "older," and either contain
simply a tag noting that values exist (this would be easier to implement
and faster to calculate and display), or the range of all older values.
It would be useful to summarize lengthy reports such as a urinalysis or
complete blood count by simply noting than they have been done--with a
minus if no abnormal values are reported or a plus if there are abnormal
values (the plus could be over-ridden by a doctor if the abnormalities
were judged to be trivial, so the display would not be misleading in the
future.) An"expand" feature would open to the complete report, or to a
flow sheet devoted to a set of complete reports for the period of time
encompassed in the column. For example,
<BR>&nbsp;
<P><BR>
<CENTER>
<P>Joe Markiewicz
<BR>Wednesday 3-20-99
<BR>Clinic # 377-95-2287
<BR>&nbsp;DOB 12-17-64
<BR>Dr. Gruenhagen</CENTER>

<BR>&nbsp;
<TABLE BORDER WIDTH="525" >
<TR ALIGN=CENTER>
<TD WIDTH="14%">
<CENTER>Dates:</CENTER>
</TD>

<TD WIDTH="14%">
<CENTER>3-20-99</CENTER>
</TD>

<TD WIDTH="14%">
<CENTER>3-14-99</CENTER>
</TD>

<TD WIDTH="14%">
<CENTER>Jan 99</CENTER>
</TD>

<TD WIDTH="14%">
<CENTER>4 Q 98&nbsp;</CENTER>
</TD>

<TD WIDTH="14%">
<CENTER>1997&nbsp;</CENTER>
</TD>

<TD WIDTH="16%">
<CENTER>&nbsp;Older</CENTER>
</TD>
</TR>

<TR ALIGN=CENTER>
<TD WIDTH="14%">
<CENTER>Test</CENTER>
</TD>

<TD WIDTH="14%"></TD>

<TD WIDTH="14%"></TD>

<TD WIDTH="14%"></TD>

<TD WIDTH="14%"></TD>

<TD WIDTH="14%"></TD>

<TD WIDTH="16%"></TD>
</TR>

<TR ALIGN=CENTER>
<TD WIDTH="14%">
<CENTER>potas.</CENTER>
</TD>

<TD WIDTH="14%">
<CENTER>&nbsp;4.2</CENTER>
</TD>

<TD WIDTH="14%">
<CENTER>3.8</CENTER>
</TD>

<TD WIDTH="14%"></TD>

<TD WIDTH="14%">
<CENTER>3.3-4.0 (2)</CENTER>
</TD>

<TD WIDTH="14%">
<CENTER>3.5-4.3 (3)</CENTER>
</TD>

<TD WIDTH="16%">
<CENTER>&nbsp;3.2-5.0 (12)</CENTER>
</TD>
</TR>

<TR ALIGN=CENTER>
<TD WIDTH="14%">
<CENTER>Creat.&nbsp;</CENTER>
</TD>

<TD WIDTH="14%">
<CENTER>2.7</CENTER>
</TD>

<TD WIDTH="14%">
<CENTER>2.4&nbsp;</CENTER>
</TD>

<TD WIDTH="14%"></TD>

<TD WIDTH="14%">
<CENTER>1.8&nbsp;</CENTER>
</TD>

<TD WIDTH="14%">
<CENTER>1.6 (2)</CENTER>
</TD>

<TD WIDTH="16%">
<CENTER>1.2</CENTER>
</TD>
</TR>

<TR ALIGN=CENTER>
<TD WIDTH="14%">
<CENTER>HgbA1c</CENTER>
</TD>

<TD WIDTH="14%">
<CENTER>&nbsp;8.3&nbsp;</CENTER>
</TD>

<TD WIDTH="14%"></TD>

<TD WIDTH="14%">
<CENTER>&nbsp;7.8&nbsp;</CENTER>
</TD>

<TD WIDTH="14%"></TD>

<TD WIDTH="14%"></TD>

<TD WIDTH="16%">
<CENTER>10.2 (3)</CENTER>
</TD>
</TR>

<TR ALIGN=CENTER>
<TD WIDTH="14%">
<CENTER>Fast. gluc</CENTER>
</TD>

<TD WIDTH="14%">
<CENTER>&nbsp;186</CENTER>
</TD>

<TD WIDTH="14%"></TD>

<TD WIDTH="14%">
<CENTER>&nbsp;204&nbsp;</CENTER>
</TD>

<TD WIDTH="14%"></TD>

<TD WIDTH="14%">
<CENTER>193 (2)&nbsp;</CENTER>
</TD>

<TD WIDTH="16%">
<CENTER>92-420 (15)</CENTER>
</TD>
</TR>

<TR>
<TD ALIGN=CENTER WIDTH="14%">
<CENTER>UA</CENTER>
</TD>

<TD ALIGN=CENTER WIDTH="14%"></TD>

<TD ALIGN=CENTER WIDTH="14%">
<CENTER>&nbsp;+</CENTER>
</TD>

<TD ALIGN=CENTER WIDTH="14%">
<CENTER>&nbsp;-&nbsp;</CENTER>
</TD>

<TD ALIGN=CENTER WIDTH="14%"></TD>

<TD ALIGN=CENTER WIDTH="14%"></TD>

<TD ALIGN=CENTER WIDTH="16%">
<CENTER>- (7) + (2)</CENTER>
</TD>
</TR>

<TR>
<TD ALIGN=CENTER WIDTH="14%">
<CENTER>hemogram</CENTER>
</TD>

<TD ALIGN=CENTER WIDTH="14%"></TD>

<TD ALIGN=CENTER WIDTH="14%">
<CENTER>&nbsp;-&nbsp;</CENTER>
</TD>

<TD ALIGN=CENTER WIDTH="14%"></TD>

<TD ALIGN=CENTER WIDTH="14%">
<CENTER>+&nbsp;</CENTER>
</TD>

<TD ALIGN=CENTER WIDTH="14%"></TD>

<TD ALIGN=CENTER WIDTH="16%"></TD>
</TR>
</TABLE>

<P>Besides clinical notes, there are many other types of narrative supporting
data:
<P>- medical imaging - typically consisting of a report by a physician
of a graphic
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xray and fluoroscopy
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nuclear medicine
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ultrasound
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MRI
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PET
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; procedure videos
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clinical photographs
<BR>- pulmonary function
<BR>- EKG
<BR>- EEG
<BR>- nerve conduction (EMG)
<P><B>Chart index.&nbsp;</B> It is not be necessary, for example, to always
show the actual xray report (or other narrative report). Just having the
xray procedure and its date would permit the creation of a table of contents
to this part of the chart as well as a flow chart of the procedures that
had been performed. At most, one could add a summary diagnosis to the list:
<BR>&nbsp;
<TABLE BORDER WIDTH="525" >
<TR>
<TD WIDTH="33%">Date</TD>

<TD WIDTH="33%">Exam</TD>

<TD WIDTH="34%">Result</TD>
</TR>

<TR>
<TD WIDTH="33%">6-85&nbsp;</TD>

<TD WIDTH="33%">Barium Enema</TD>

<TD WIDTH="34%">diverticulosis</TD>
</TR>

<TR>
<TD WIDTH="33%">8-99</TD>

<TD WIDTH="33%">&nbsp;CXR</TD>

<TD WIDTH="34%">nl</TD>
</TR>

<TR>
<TD WIDTH="33%">11-94</TD>

<TD WIDTH="33%">&nbsp;UGI</TD>

<TD WIDTH="34%">DU</TD>
</TR>

<TR>
<TD WIDTH="33%">8-98&nbsp;</TD>

<TD WIDTH="33%">BE</TD>

<TD WIDTH="34%">&nbsp;tics, polyp</TD>
</TR>

<TR>
<TD WIDTH="33%">9-00&nbsp;</TD>

<TD WIDTH="33%">MRI lumbar spine&nbsp;</TD>

<TD WIDTH="34%">HNP Rt L5</TD>
</TR>
</TABLE>

<P><B>Professional communication.</B> Many types of communication need
to be kept in a patient's record. Many of these need not be reduced to
electronic form. At most, the electronic record should be an <I>index</I>
to the paper documents that have been archived in a paper file. Examples
of historical records that do not require electronic access are:
<BR>- reports from consultants
<BR>- hospital admission and discharge summaries, operative and procedure
notes
<BR>- letters to or from patients
<BR>- correspondence with employers and attorneys
<BR>- forms from or for employers, DME providers, home health nurses, insurance
companies, etc.
<BR>- old records sent from past caregivers
<BR>- nursing home documentation
<BR>- reprints from the medical literature
<BR>- archival clinical records
<P>Communication between providers is more and more likely to be in electronic
form, usually as email. If intranet connectivity is achieved between providers'
clinical databases, it will be possible to directly add data and notes
generated by other providers in a clinician's own electronic record. If
this is done, then the <I>source</I> of the data must be indicated within
the clinician's database.
<P><B>Prescriptions and a drugs database</B>
<P>This I consider to be a part of the "clinical notes" function, because
it is the clinician who uses it, and the results of the prescribing process
belong with the clinical note. I will briefly list here the essential features
of a prescription system.
<P><FONT FACE="symbol">&middot; </FONT><B>Drugs database</B>. It is not
a difficult task to import the FDA <I>Orange Book</I>, available at their
web site (http://www.fda.gov/cder/ob/), into a database, and the FDA publishes
monthly updates which could be used to automatically the drugs database.
<P><FONT FACE="symbol">&middot; </FONT><B>Prescription-writing tool</B>.
A prescription should be easy to create, and the software should be capable
of printing a prescription on paper for signature, faxing a signed prescription
directly to the pharmacist, or electronically submitting the prescription
if the pharmacy is capable of accepting this.
<P><FONT FACE="symbol">&middot; </FONT><B>Medication list</B>. It is important
to be able to produce not only a complete list of current and recent medications
for the chart, but to prepare a list of the patient's current medications
for the patient, for the pharmacist, and for home health nurses.
<P><FONT FACE="symbol">&middot; </FONT><B>Allergy/intolerance list</B>.
It is not essential for this list to be part of the database if the clinician
is working from a paper chart, as it is the clinician's responsibility
to be sure that all medication intolerance is considered prior to writing
a prescription, and such lists are notoriously incomplete. But it is helpful
to have this feature, and the clinician should work diligently to maintain
an accurate list in the database.
<P><B><FONT FACE="symbol">&middot;</FONT> Medication interactions.</B>
The <I>Medical Letter</I> has a web site,
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; http://www.medletter.com/
<BR>and during this last year has made their drug interactions software
available to subscribers via the Internet. As set up on the Internet, the
user can check interactions on up to six drugs at a time. This is a limit
of the web page, not of the software. The program does not check for interactions
with food or "natural" products, but does provide reprints of literature
for many interactions. I have found it more than sufficient for my own
needs, and the response has been very fast.
<P>It is important to the clinician providing longitudinal care to have
an audit trail of past prescriptions, listing when each was begun and stopped,
and when a change was made in medication, form, dosage, or schedule, to
indicate succinctly a reason. Such an audit trail can eliminate the repetition
of past futility.
<P><B><FONT SIZE=+1>Coding Systems</FONT></B>
<P>It is not my purpose in this document to review coding systems for symptoms,
diagnoses, supplies, and professional services. A concern is that the AMA
does not make the CPT coding system freely available; nevertheless the
cost of this database is within the means of any practice.
<P><B><FONT SIZE=+1>Information Resources</FONT></B>
<P>Two software technological advances have greatly reduced the work needed
to bring a usable integrated medical information system into the exam room:
These are the multi-windowed desktop and the web browser.
<P>The <B>Multi-window desktop</B>, with proper tools, permits the clinician
to simultaneously have access to disparate systems that live on the same
network. It is not necessary to switch from one application to another.
I can have simultaneously open a word processor for patient instructions
and educational material that can be customized for the patient's individual
needs in seconds, a terminal session to access their lab data, an Internet
session to check drug interactions, an intranet session for access to an
electronic medical library, and a window on real-time radar so she can
see if the rain will quit before she has to go back out to her car.
<P>The <B>web browser</B> solves an access and display problem, and its
ubiquity has made information and tools readily available without the intervention
(i.e., work) of the local programmer. We will do well if all displays use
this technology to present information. However, HTML is presently has
very limited ability to use screen real estate efficiently, and has inadequate
flexibility in managing keyboard input, so that the ergonomics of browser-based
data display and entry are awkward. A current example of this is the FAA's
new DIWS software for Aviation Medical Examiners. Most of you will never
see this, and it is not possible for me to demonstrate it here; so let
me say simply that its ergonomics is awkward, error checking of input is
scant, response times are highly variable from seconds to tens of minutes,
and security and authentication were a daunting challenge. After talking
personally to the programmer, I am confident that this system pushes pure
HTML as far as it can.
<P>Despite its severe ergonomic limitations, HTML and browsers prove that
a shared display technology is an important part of the foundation for
the necessary clinical connectivity of the future. In my own institution,
the use of XML is being specified for all future clinical applications,
and many commentators have agreed that this will likely be the future common
specification for presentation and display.
<P><B><FONT SIZE=+1>The Organizational Politics of Systems Design</FONT></B>
<P>This discussion about the genuine and perceived strengths and shortcomings
of commercial versus open software is in fact a political one, as within
institutions decisions are usually made politically, even though experts
would prefer that technical merit be the basis for planning and decisions.
<P>Commercial software solutions <I>do</I> have some strengths. These are,
by and large, well understood. But vendors, no surprise, obfuscate or deny
their deficiencies.
<P>Free and open source software <I>does</I> have some limitations and
deficiencies, upon which vendors focus; but also some strengths, which
are not widely recognized in part because vendors deny their existence
and partly because they are simply new and word has not gotten out.
<P><B>Strengths of commercial software</B>
<P>Commercial applications <I>exist</I>, they are supported, many have
a very long history, the companies understand their customers' needs, and
many commercial systems provide extensive training as well as installation,
customization, and usually maintenance. Only a commercial solution can
provide a "turnkey installation." A customer with no technical expertise
whatever can own and use a well designed software application.
<P>A strength of commercial software that is not well understood is the
cutting off of political unrest by taking huge portions of a company's
IT efforts outside company walls. Is there controversy in the company over
technical or ergonomic issues? The canny administrator can obviate all
this infighting simply by going to a turnkey commercial solution. A side
benefit is that the internal combatants then become allies against the
alien invader that management has so "stupidly" obtained.
<P>A corollary to this principle is that if a company is not able to bring
organizational discipline and focus to its IT efforts, a commercial solution
may be less costly. Organizational "focus" is particularly difficult in
academic institutions and highly democratized firms which have powerful,
independent department heads, particularly when IT professionals are kept
in a "service" role and not permitted to participate at leadership levels.
<P><B>Myths about commercial software</B>
<P>The assumption that in buying commercial software the customer is typically
getting a reliable, cost-effective, well supported system is wrong. Some
very good commercial solutions exist, but good experiences are hardly universal.
<P>In particular, the <I>cost effectiveness</I> of commercial software
is often assumed, without actually examining costs carefully before purchase,
and almost no one actually does a continuing cost analysis of such software
after installation. My former clinic, the Rhinelander Medical Center, which
did this in the mid 1980's and responded to favorable numbers by opening
a service bureau as a profit-making subsidiary after reviewing excellent
performance, is exceptional.
<P><B>Weaknesses inherent in commercial software</B>
<P>The two greatest hindrances to the use of commercial software are the
proprietary (and therefore unique) files, databases, protocols, display
technology, etc.; and inflexibility toward any single user. Getting two
separate vendors to cooperate with exchanging data is difficult and slow.
At the two clinics with which I am affiliated, approximately eight disparate
systems in two locations were more or less wedded by creating a single
common demographic database which all applications must access and use
(to some extent), a task that was not easy or brief.
<P>Administrators often say that one reason they use commercial software
is that if something goes wrong, there is someone to sue. This is one of
those rhetorical bites that is catchy but wrong. An economically strong
vendor will be able to resolve genuine difficulties; an economically weak
one might be unable to garner the resources to solve a difficult issue,
may have "thin" technical support staff, and the failing company will have
nothing for the user to recover in a suit -- never mind the years it takes
to get a settlement.
<P>In fact, the chance that a vendor might disappear while their application
is still needed is one of the biggest potential weaknesses of a commercial
product.
<P>The most difficult situation that plagues the users of commercial software
is <B>vendor lock.</B> This is a real phenomenon; fundamentally it involves
the vendor milking the cow once it is in the barn. For example, our hospital's
accounts-receivable software vendor told us that A) they planned not to
upgrade or support the product we had been using; B) it was not Y2K compatible;
C) they had replacement software, a completely different system, available
for $1 million and we should plan to purchase and install it well before
December 31. A conflict followed, wasting time and money for both parties,
following which the old software became Y2K compliant.
<P><B>Strengths of free and open source software</B>
<P><I>There is no vendor lock</I>. If one manages projects poorly, there
can develop "programmer lock," if code is not well designed or properly
documented. But the organization possesses its own code, and is free to
hire any programmer, as a contractor or employee, to improve, modify, or
adapt to the organization's specific needs.
<P><I>Interconnectivity</I>. The majority of the Internet is run by GNU/Linux
systems and tools. The genesis of the free and open source community was
within the Internet, and so this system has the best toolset and best expertise;
and it is designed to use old, out of date, inexpensive equipment efficiently.
<P><I>Large numbers of skilled programmers</I>. The GNU/Linux community
has thousands of developers, most able to work remotely, by contract. The
challenge to an organization is not finding them, but managing its projects
and personnel. Organizations which cannot manage technical professionals
well should purchase commercial solutions and be happy with vendor lock.
<P><I>Robust, redundant toolset</I>. The GNU/Linux system, bolstered by
more or less open software, has the broadest, most complete collection
of software tools, including the most interesting middleware. (Medical
information will continue to be dominated by commercial vendors of proprietary,
closed software for at least a decade, and there is no solution for the
clinician who hopes to create a comprehensive system for data access and
display except to use middleware to mine data from disparate proprietary
systems.
<P><I>Reasonable and controllable costs.</I> There are no royalties to
be paid in this arena; the organization that is able to manage software
projects and is able to focus strategically to use free and open software
for its strengths will be rewarded with the ability to control its costs
and manage the pace of its development, as well as focusing software on
its own priorities.
<P><B>Weaknesses of open source software</B>
<P><I>No medical applications.</I> In the past, GNU/Linux was disparaged
because it had no applications; this is because this is a new OS and free/open
software is a new paradigm for development and management. This will change,
but it is true that now there are no applications ready for deployment.
In fact, non-commercial code will likely be slow to enter this arena.
<P><I>No turnkey installations.</I> Obviously.
<P><I>No training</I>. This is a corollary of "no apps."
<P><B>Myths about open-source software</B>
<P><I>No support.</I> Actually, one of the fascinating characteristics
of the free-software community is its broad and skilled support via Internet
discussion groups. But commercial support has become available as companies
have emerged to serve this arena. As commercial offerings continue to develop,
the growing number of organizations offering 24 x 7 support will continue
to increase.
<P><I>Unreliable.</I> This is simply false. My Linux systems have been
up without crashing since installation, and have been down only for kernel
upgrades. Device drivers can be installed without re-booting. My Windows98
system must be taken down every third day, or memory leaks lock it up.
WinNT/2000 must be re-booted for installation of any device driver.
<P><B>Summary</B>: Free/open software solutions are suitable for medical
organizations who have managers with technical understanding who need maximal
cost effectiveness; and are best used as "creviceware" for connectivity
and data gathering, and "taskware" that is designed for display and manipulation
of stored data.
<P>The most important limitation of open source solutions now is that an
enterprise needs truly to manage its IS <I>and</I> its "internal customers"
well in order to benefit efficiently from their use. For many businesses
to purchase turnkey software, with all its obvious severe limitations and
inherent frustrations, is a way to avoid managing IS personnel or to obviate
internal debates over ergonomics, priorities, and function. As turnkey
open-source solutions emerge, this concern will abate.
<P>Commercial solutions are most appropriate for organizations that are
unable to understand or manage technical resources, who have more money
than knowledge, which are not able to agree on IT priorities, and for those
who need proven software or turnkey solutions.
<P>It is my judgment that it will not be possible to provide a complete
free/open source medical information management system for three to five
years; that the chief mistake managers are making with regards to open
software is to ban it or ignore its genuine strengths, as it is extremely
cost effective.
<P>I am not sure whether vendors and users can agree on a basis for interchange
of common data; but that we do so is important for our patients, who need
their health information to be portable as they are referred among specialists
and move about the country and the world.
<P>Responses may be directed to me at:
<P>johnson.danl@mayo.edu
</BODY>
</HTML>