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.
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.
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.
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.
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.
[3] Symposium on Computer Applications in Medical Care, held in Washington, D.C.
[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/.