A Revolution
in Electronic Medical Record Systems
via the World Wide Web

Peter Szolovits[1]
MIT Laboratory for Computer Science
Cambridge, MA 02161, USA

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.


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.


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.


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:
  1. 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.
  2. 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.
  3. 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.
  4. 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.


    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.


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