[text-only]
A Revolution
in Electronic Medical Record Systems
via the World Wide Web
Peter Szolovits[1]
MIT Laboratory for Computer Science
Cambridge, MA 02161, USA
psz@mit.edu
This is an informal extended abstract prepared for a talk at the
conference The Use of Internet and World-Wide Web for Telematics in
Healthcare. The conference, sponsored by the International Association for the Advance of
Health Information Technology (IAHIT), was held in Geneva,
Switzerland, September 6-8, 1995.
Lament
Astonishingly, most health care institutions in the United States still
maintain most of their patient records in the form of paper charts. If a
traveler from the future had told me and my colleagues in 1975 that this
would be the case in 1995, we would have been shocked.[2]
Surely, simply the cost of maintaining records in electronic form must be
less than continuing to keep records on paper, I would have argued. In
addition, electronic records are far less likely to be lost, temporarily
unavailable, delayed in transit, rendered unreadable by physical accident,
etc. Furthermore, the capture of the entire record, in a form amenable to
computer processing, would open up myriad possibilities for building
proactive, intelligent systems. All of the work of the past twenty-five
years on the development of expert systems, for example, assumes that
relevant facts about the patient will be routinely available to the system,
just as they are available to human practitioners.
Progress has, of course, been made in the development of electronic medical
record systems (EMRS). Very little of the data that are routinely
generated by computer-such as laboratory test results-are now lost to
electronic accessibility, as they typically were twenty years ago, when the
typical lab instrument would print its results on paper and discard the
electronic version. Nevertheless, much of the information on which
clinical care is based continues, in most institutions, not to be captured
in electronically usable form. This includes the results of patient and
family histories, physical examinations, doctors' and nurses' notes, etc.
Fortunately, both academically-inclined hospitals and commercial companies
now recognize that the failure to capture these data is costly and
represents an opportunity for progress. Many institutions and vendors are,
therefore, developing and installing new hospital information systems that
try to capture a growing fraction of the total medical record. Alas, there
is not much commonality in the approaches being taken, and therefore it is
difficult to transfer lessons learned, technology, or patient data from one
such effort to another.
How to Build EMRS?
My own interest in taking a new look at medical record systems was sparked
by a frustrating visit to the "trade show" at the 1993 SCAMC.[3] The big news was that two competing vendors were,
finally, offering the ability to interoperate their proprietary systems: it
was now going to be possible, while using system X, to view a screen
generated by system Y, and vice versa! Such capabilities have
existed in all kinds of computer systems for about two decades, and I found
it disgusting that this offering even counted as news, much less that it
represented the state of the art. Nowhere among the vendors was there a
discussion of information sharing among these systems, or of the many
conceptual and practical issues that arise if one wishes to provide a
seamless fabric of medical information about a patient across multiple
institutions and systems.
By contrast, I had been engaged in discussions with my computer scientist
colleagues at MIT and elsewhere throughout 1993 about the emerging
international information infrastructure, whose most visible manifestation
is the World Wide Web (WWW). From the most naive perspective, this is a
system that provides uniform access to a vast interlinked resource library
of information around the world. It is available independently of the
computer and operating system platform on which one happens to run (e.g.,
PC, Mac, Unix), it allows access to multimedia data (including formatted
text, pictures and graphical images, sound, and video), and it is defined
in terms of a general, relatively flexible, and extendible set of protocols
that allow and encourage experimentation and evolution. The contrast
between the rapid advance of the Web and the glacial pace of evolution of
medical record systems was shocking.
Developers of medical record systems concluded, as early as the 1960's,
that the needs of medicine were not adequately served by much of the
commercial data processing technology of their time. Therefore, they seem
to have evolved an attitude that because medicine is unique, technology for
medical systems must be unique as well. In fact, early systems did exhibit
advanced features that were well ahead of commercial data processing
systems of their time. This legacy led, however, to a tradition of
continued independent development, in which medical system developers did
not share in the adoption by almost all others of technologies such as
relational data base systems, networking, open sytem interfaces,
client-server computing, a degree of platform independence, and access and
communication security. Today, many medical systems still use the
techniques of the 1960's, and are doomed to play catch-up with more
broadly-based commercial vendors.
MedWeb
After the SCAMC meeting, with my colleague (and former student) Dr. Isaac
Kohane, now a pediatric endocrinologist at Boston's Children's Hospital, we
conceived a bold experiment to address this frustration: We proposed to put
the actual medical records of Children's Hospital on the WWW.[4] Children's has a relatively modern hospital information
system, designed and built in the late 1980's, whose core is a central
relational database repository, with networked access to allow departmental
systems to dump in patient data, coordinated by a central patient registry
and architectural rules to try to maintain consistency. Our intent was
(and continues to be) to apply the phenomenally rapid development of
computer technology to medical computing by layering medical record keeping
on top of state of the art methods, and by trying to assure that nothing
will get in the way of continually adapting new techniques to medical use.
By late 1994, with Philip Greenspun, an MIT graduate student, we had been
able to build a simple prototype system, called MedWeb, that does in fact
allow access to a small subset of actual records from Children's via the
Web.[5] Our obvious primary concern was to safeguard the
confidentiality of patient data. Thus, currently instead of accessing the
live data at Children's, we maintain a small subset of Children's data[6] on a server at MIT, and we have created pseudonyms for
patient's names, identification numbers, addresses, etc. to assure that
the widely-available data cannot be used to trace back to the actual
patients. Within the hospital, we plan shortly to allow access for
authorized users to the real data simply by pointing our tools at the
actual clinical database rather than the pseudonymized copy at MIT. I will
show the capabilities of our prototype system in my presentation.
Security provides an interesting and central illustration of the potential
value of our approach. In the decade since the Children's system was
designed and built, access to data from outside the institution has become
a critical concern. Not only do doctors now expect to be able to call in
from their home or office computers via phone lines and get access to the
latest clinical data, but even traditional outsiders such as the referring
doctor are seeking rapid access to data, notes, and care plans. The
initial security design of the system distinguishes simply between those
with full access (insiders) and those with none (outsiders), corresponding
roughly to minimal restrictions on access to older paper charts. Today,
Children's supports outlying clinics that require full access and would
like, as part of its attempt to appeal to more referring doctors, to
support direct access by them to the records of their own patients, while
hospitalized. In a custom-built system, such security is expensive, needs
to be individually grafted on, and may not provide adequate protection.
The current system, for example, uses sophisticated means of assuring that
only those off-site people who can authenticate themselves have access.
However, once accessed, the data are sent unencrypted over ordinary
telephone lines. A custom solution to this problem has, so far, been
deemed too costly.
When we began, we did not have a specific design for how to provide
security, but we were convinced that others would build the technology at
no cost to us,[7] and that it would prove adequate to our
needs. Although we have yet to implement it in our prototype, the same
capability is virtually free to provide in a system using the WWW-based
architecture. Because authentication and end-to-end encryption of data are
critical needs for many Web applications, the technology to support them is
already being built, standardized, and (almost) freely distributed.
Popular Web browsers include SSL or S-HTTP protocols to provide these
services, and compatible servers are inexpensive and easily available.
Thus, consistently with our original intuition, we will be able to count on
the Web to provide the tools for implementing our security system.
Similarly, in contrast with the historical difficulty at Children's of
augmenting "dumb terminal" access by availability of the same data through
a Macintosh interface, our Web-based EMRS gains multi-platform capabilities
through the efforts of others. Macintosh, PC's and Unix works now, and
whenever a new platform (such as a Newton hand-held device) gains a Web
browser, the EMRS automatically accomodates it.
Issues
The difficult part of building a modern EMRS is not simply providing access
to data within a single institution. It includes, in addition, the
following (non-exhaustive) list of issues:
- How to capture and encode complex data in forms that are amenable to
intelligent interpretation by computer. This is a central problem of EMRS,
for which we have no unique answers. We hope that by eliminating many of
the mechanical difficulties of building the EMRS, we will allow focus to
shift to addressing these truly difficult problems. New forms of
information capture, such as speech or gesture recognition can help, and
standardization on acceptable and accepted ways of describing medical
conditions will certainly be needed.
- How to share medical information across multiple institutions, to allow
doctors to access a lifetime of medical data about a patient who develops
records at several institutions. This is the focus of our major current
collaborative work, with two other Boston-area hospitals, and I will return
to it below.
- How to provide timely and not too cumbersome access to medical records
without compromising the privacy of patients. Although the technology of
cryptography stands ready to provide valuable alternative solutions, much
work is needed to define appropriate policies. How are we to determine the
tradeoffs between risk to privacy from liberal access policies and risk to
health from strict access policies that may protect privacy better, but may
occasionally deny access when it could be critical. I will present some
ideas on this issue, but it certainly remains a major issue for further
study.
- How to engage the patient in his or her own health care. In principle,
we have always recognized that health care is for the patient, and
therefore should take into account the patient's preferences and take
advantage of the patient's self-interest to involve him or her in the
ongoing process of monitoring care. In practice, however, this has rarely
been achieved. I will take this opportunity to introduce the concept of
the Guardian
Angel, a life-long active personal health information system that is
intended to act as an agent representing the patient's interests throughout
a lifetime of interactions with the health care system. It will form not
only the repository of all medically-relevant data about the patient, but
will actively interpret those data to help explain the significance of
diagnostic and therapeutic intervention to the patient, to present
customized educational material, to enable the patient to make observations
and influence the course of his or her care, and to allow automated
monitoring of health status. A fundamental feature of the approach is that
data thus collected and organized will be primarily under the control of
the patient. I will also describe a prototype application we are currently
developing for use by women with gestational diabetes.
Inter-institutional Sharing of Medical Data
With our colleagues at Massachusetts General Hospital (MGH) and at the Beth
Israel Hospital in Boston (BI), we have defined an interesting experiment
to address the question of sharing data among institutions. We are
building a demonstrable system that will allow access from, say, the BI's
emergency room, to a patient's records who is normally seen by doctors at
MGH but whose medical care as a child took place at Children's. We have
agreed that such access requires the ability to identify the right records
at each institution, and to present in some coherent way each institution's
problem list for the patient, as well as medications, allergies, laboratory
data,
visit history, and procedures.
At present, much of the data in different institutional systems is coded,
if at all, in idiosyncratic ways. Standard use of ICD-9-CM codes is
mandated by some reimbursement schemes, but this is very limited in scope
and addresses mostly conclusions about disorders, not primary clinical
information. Of three systems, therefore, one might characterize a high
blood pressure reading as "190/120" in some numerical fields, another might
call it a finding of "elevated blood pressure," and a third may list
"hypertension" among the patient's current problems.
One possible resolution of such diverse forms of description might be the
adoption of national or international standards to regularize the use of
medical terms. Efforts such as the CPRI's in the United States fall into
this category, but are faced with immense difficulties of securing
widespread agreement. As a result, such top-down efforts tend to take a
very long time and face the risk of being bypassed and becoming irrelevant
before standardization is achieved. We are trying an opposite approach in
our efforts. Our initial model of the "common medical record" is simply an
abstraction of the records at Children's, and we plan to evolve this model
as our network of collaborators grows, bottom-up. We also hope that tools
such as the NLM's Unified Medical Language System (UMLS) project provides
tools useful to recognize terminological relationships among descriptions
in different systems that we try to integrate. Ultimately, however, we
think it will require good will and flexibility among participants to iron
out semantic disagreements, matters of style, and historically diverse
means of description.
We have defined a reasonably flexible architecture for our
three-institution prototype, which will build on data exchange standards
such as HL7, presentation standards such as HTML, generalizable
communication mechanisms such as HTTP, security protocols such as SSL, and
conventional, off-the-shelf tools and components wherever possible. I will
describe the approach we are taking, lay out our current architecture, and
discuss our work in progress.
Future
Our current EMRS project is being conducted as part of the NLM's national
EMRS collaborative project. Still in the first year of this project, we
have persuaded our Boston- area colleagues to work with us on the next
phase of our efforts. Several others in the NLM-sponsored group have
already expressed an interest in joining our effort shortly. Responses to
our demo, from both academic medical centers and commercial developers, has
been very positive. We believe that the bottom-up model we are pursuing
may well have a chance to sweep out a large path of enthusiastic supporters
and participants in the near future. MIT and Children's Hospital have held
discussions about the possibility of forming an EMRS consortium, along the
lines of our previously successful X-windows consortium and the current WWW
Consortium (W3C) to provide a focus for bringing together participants, a
forum for setting standards, and a group of implementors to create
reference implementations of components needed by adherent systems.
Notes
[1] The author's work is supported by the National Library of
Medicine (NLM) under National Institutes of Health Grant number LM 05296
and LM 05877 and by the DOD Advanced Research Projects Agency (ARPA) under
contract number N66001-95-M-1089.
[2] This note represents a personal viewpoint and is,
therefore, written in a personal style. Not only is the language informal,
but many of my views are stated as opinions without scholarly backing. I
hope the reader will excuse this informality, which I hope will spur
discussion.
[3] Symposium on Computer Applications in Medical Care, held
in Washington, D.C.
[4] Our other partner in this endeavor is Dr. Chris Cimino,
at Albert Einstein school of medicine. He is particularly interested in
the issues of medical language standardization.
[5] This was shortly after securing funding from NLM. We
estimate that the initial effort to create an interesting demo took no more
than two or three weeks' effort, mostly by Phil. Even of this, most of the
effort concerned scrubbing the data to support privacy. The tools to build
the Web pages dynamically are reasonably good, and easy to use. Our current
demonstration version can be accessed at URL
http://luke.lcs.mit.edu/medweb/.
[6] Initially, the experiment gave access to data about twenty
patients from the endocrine clinic, and is now being scaled up to about 250
patients.
[7] My favorite anecdote from this early time was the rumor
that Rolling Stone magazine was financing the creation of one of the
earliest secure authentication methods for the Web, to limit access to
their past issues' contents to those net surfers who were subscribers.
Surely, this would have been the first instance of an icon of popular
culture subsidizing a critical component of medical record keeping systems.
©
HON