Sharing Electronic Medical Records Across Multiple Heterogeneousand Competing Institutions

Isaac S Kohane, MD, Ph.D.I, drs. F. J. van Wingerde', James C. Facklerl, ChristopherCimino, MD3, Peter Kilbridge, MD4, Shawn Murphy MD, Ph.D.4, Henry Chueh, MD4,David Rind, MD2, Charles Safran, MD2, Octo Barnett, MD4, Peter Szolovits, Ph.D.5

IChildren's Hospital Informatics Program, Boston, MA, 2Div. Clinical Computing, Beth IsraelHospital, Boston, MA, 3Albert Einstein College of Medicine, NY., 4Lab. of Computer Science,Mass General Hospital, Boston, MA, 5Lab. for Computer Science, MIT, Cambridge, MA.

Most early reports of implemented World-Wide Web(W3) medical record systems describe singleinstitution architectures. We describe W3-EMRS, amulti-institutional architecture, and itsimplementation. Thorny problems in d sharingunderlined by the W3-EMRSproject are reviewed.

INTRODUCTION

Despite the upheaval in the structure and economicsof organized medical care, delivery of healthcare to asingle patient over his or her lifetime remains amulti-institutional enterprise. Within organizedhealthcare delivery systems, such as managed careorganizations, several distinct institutions mayparticipate in the care of the patient. In emergencycare, or for specialized refenral services, the patientmay obtain care outside their usual healthcarenetwork. In our increasingly mobile society, changein employer or employment location and consequentchange in healthcare plan and/or providers is hardly anuncommon event in a patient's lifetime. Safe,comprehensive and cost-effective patient care dependson the ability to obtain an accurate"history of thepatient's health care. In the absence of thisinformation, tests may be repeated or prior resultsignored, idiosyncratic reactions may be misreported,and drug dosage details may be miscommunicated. Inthe emergency care of an unconscious patient,lifesaving information may be unavailable. Theclinical information relevant to a particular patientfrom multiple providers and institutions that mayhave had care responsibility over the patient's lifetimeshould therefore be accessible in a timely manner.Whereas Electronic Medical Record Systems (EMRS)have begun to be implemented on a large scale toprovide efficient access to clinical data at individualsites, the technologies and policies of inter-institutional EMRS data sharing are currently only inthe design or prototype phase.We have implemented an architecture called W3-EMRS that enables sharing of patient data acrossmultiple institutions and automatically collates thepatient data arising from these multiple sites. Thisarchitecture takes advantage of emerging standards forcommunicating clinical data, and the rapidly evolvingcapabilities of W3. This paper motivates anddescribes our architectural decisions and addresses

several of the many thorny problems that even atechnically successful, data sharing architecture mustgrapple with. Our concerns about the need forresolution of these issues has caused W3-EMRS toremain in a purely experimental and demonstrationstate. That is, all the databases it accesses representsmall numbers of patients for which all patient andphysician identifiers have been replaced and allnarrative text has been manually reviewed and editedto remove any identifying information. Further, eachdatabase has been loaded into its own database,separate from any hospital system.In our work to date, we have encountered fourparticular challenges: display of data obtained fromdifferent institutions, selection of patients in theabsence of a national identification system,vocabulary translation, and authorization of access torecords outside an institution. For developers of inter-institutional data sharing efforts, awareness andsensitivity to these issues is likely to be central tothe success of their efforts. The W3-EMRSarchitecture permits experimentation with differentsolutions to these challenges but does not necessarilyprovide them. In effect, W3-EMRS overcomes manyof the technical problems of sharing clinical data onlyto reveal more clearly differences in clinical practice,documentation, protection of privacy and use ofmedical terminology.The World Wide Web (W3) is the collection ofsoftware protocols that allows users of computersthroughout the global network of interlinkedcomputers-the Internet, to access W3 files, typicallyformatted in the HyperText Markup Language(HTML), on any other machine on the Internet solong as that machine can respond to the W3communication protocol, the HyperText TransferProtocol (HTTP).

We implemented, in November 1994, our firstworking W3 system for accessing EMRS . For thisfirst early demonstration system, we used the databaseof a pediatric EMRS-The Clinician's Workstation(I)-which includes access to the Children's HospitalIntegrated Hospital Information System (THIS) datarepository. The data repository uses an Oracledatabase management system. One version of thissystem is in operation running against the entireChildren's THIS, but within the hospital's network

0195-4210/96/$5.00 0 1996 AMIA, Inc. 608

"firewall". Initial clinician response to this early W3results reporting system has been positive (2).Furthermore, congruent with the experience of earlyimplementors of W3-based EMRS (W3BE) (3, 4)clinicians have been able to use the prototype with noor minimal training.

The first W3-based results reporting system atChildren's, and most of the aforementioned W3BEdepend on the particulars of their local, existingEMRS. By "existing EMRS", we mean the systemthat is primarily responsible for managing theinformation requirements of healthcare providers.Therefore, to the extent that a W3BE's functionalitydepends on the particulars of an existing EMRS, itdoes not address the problems of sharing data betweenheterogeneous systems. The heterogeneity of theseEMRS occurs at many levels including their databasemanipulation language, their information model, theirlocal vocabulary and the policies and organizationalstructures of each institution. The W3-EMRSarchitecture allows the use of W3 browsers, and otheruser interface technologies to share data acrossmultiple institutions despite their heterogeneousparticularities. In the following sections we motivateand describe the architecture, and then outline itsimplementation. Subsequently, we review specificchallenges and unresolved issues in this and similarefforts in multi-institutional clinical data sharingefforts.

ARCHITECTURE

A common computer science technique for developingand maintaining complex data exchange andtransformation tasks is to develop a series ofabstraction layers. Ideally, each abstract layer providesa distinct service which can be implementedindependently of all the other layers. We applied thistechnique to the problem of moving data frommultiple data repositories to a consistent userinterface. The W3-EMRS abstraction layers include:1) A common information model, called theCommon Medical Record (CMR). 2) A shared set ofconventions for visual presentations of the clinicaldata represented in the CMR. 3) The ScreenRendering layer which is the set of programs thatimplement the abstract functions of the visualpresentation layer as user interfaces on the clinician'scomputer.

The CMR is designed to bridge the divergentinformation model of each institution. For example,in some EMRS, the problem list is directly linked tothe clinical note that describes each problem whereasin others the problems and clinical notes are storedseparately and can only be indirectly linked by date.Sharing data between two EMRS typically involvesconverting data from the information model in oneinstitution to that in another. The number of suchtranslations grows approximately, as the square of thenumber of EMRS involved. However, if there were asingle standard information model, then it could serveas an intermediary information model for all EMRS

and therefore the number of distinct translationswould only grow linearly with the number of EMRS.

The development of a shared information model-theCMR-has been a central task as it is a prerequisitefor data sharing. The definition process was driven byour medical task domain, obtaining patient dataduring an emergency room visit at any of ourhospitals. Our initial task was to rank in prioritythose medical data objects which would be the mostuseful to share for the acute management of thepatient in the emergency room. These included activeproblems, clinical notes, medications, allergies,patient demographics, and the visit history. For eachdata object, we had to agree upon its attributes (e.g.some of the problems CMR object include problemname, vocabulary used, date first noted, comments,document describing the problem) based both on whatwas required for the task domain and by what wasavailable in the existing EMRS of each of thehospitals. As could be expected, arriving at aconsensus set of attributes was challenging,particularly as a close correspondence between theseattributes and those of the existing EMRS wouldboth simplify the implementation of a translator fromthe existing EMRS and also might make thetranslation process more efficient and therefore,swifter. For example, if the existing EMRS did notstore the problem corresponding to each clinical note,the translation program would have to compute thiscorrespondence based upon the dates of the problemand clinical note. In retrospect, the specificity of theemergency room task domain was particularly helpfulin moving us to a consensus on the CMR.

Several options were available to implement theCMR, ranging from creating a relational databasewith data tables that correspond to each data object inthe CMR to the definition of an arbitrary sharedmessage format. We selected to implement the CMRwithin a messaging format but chose to exploit thelarger consensus represented by the Health LevelSeven (HL7) messaging standard. HL7 is one of themore popular interchange formats for communicationbetween clinical information systems. HL7communicates data as a sequence of defined ASCIIcharacters which is hierarchically organized intosegments, fields, and components. Although futureversions may describe a full clinical informationmodel, the HL7 information model remainsunderspecified and incomplete. That is, it allowsmultiple alternate messages for communicating thesame data and also it does not have a set of standardsegment or component formats for all the data typesone might find in an EMRS. Consequently, whereHL7 has defined a particular attribute of a CMRobject, we adopted it. Where there are several HL7structures for representing the same datum, we agreedwhich one was to be used. Where an HL7 structurefor a CMR attribute was absent, we used the HL7mechanisms for defining additional message segmentsto represent that attribute. Also, we had to agree onthe format of standard CMR transactions, such as theHL7 format to issue a query for the problem list overa specified date range.

609

The Visual Presentation layer is the secondabstraction layer designed to provide independencefrom the particular presentation conventions of anexisting EMRS. It defines a set of archetypal clinicaldata presentation motifs such as flowsheets, timelinegraphs, annotated pictures and how the elements ofthese presentations correspond to the CMR. Itdescribes whether data from multiple institutions willbe shown in one time ordered list, in a table with aseparate column for each institution or in multipleseparate pages. The Visual Presentation layer alsodefines permitted user interactions with these Visualpresentation elements. In a table of clinical notes, andproblems, it may be specified that if the clinicianselects a particular clinical note, the entire text of theclinical note is retrieved and presented to the clinician.

The topmost layer in the W3-EMRS architecture isthe Screen Rendering layer. This can be implementedin any technology that uses abstractions of the VisualPresentation layer to guide the creation of thecorresponding displays and functions on theclinician's computer's screen. Although severaltechnologies could be used for this purpose (e.g.Visual Basic or Powerbuilder) we have focused on W3presentation technologies for the reasons stated above.

To implement the W3-EMRS architecture, a set oftranslator programs have to be implemented tomediate the set of transformations between theexisting EMRS, the abstraction layers. The onlytranslator that needs to be rewritten for each distinctEMRS is the one that translates queries against theCMR into queries in the database manipulationlanguage of the existing EMRS and then returns theresults of the query in the agreed conventions of theCMR. This is referred to as the Site Server program..We have implemented a W3-EMRS architecture thatprovides these translators and have written Site Servertranslators for scrubbed databases extracted from threeexisting EMR (Children's CWS, (1) the Beth Israel'sClinical Information System (5), the MGH EMR (6))with quite divergent information models. Thisimplementation is described below.

IMPLEMENTATION

In the description below, it should be clear that thedatabases referred to are the aforementioned scrubbeddatabases extracted from each hospital's existingEMRS and not the actual production systems at eachsite.

The implementation is most simply outlined bydescribing how a query is executed. Selecting a buttonor data element displayed on the browser generates aquery that is transmitted by the HTTP server to aprogram called the "Agglutinator." The Agglutinatorbroadcasts, using the HTTP protocol, this query as anHL7 message to all the sites that might have somerelevant patient information (i.e. the three sites of ourEMR "Collaborative"). At each existing EMRS site,upon receipt of the HL7 query, the Site Servertranslates the query into the data manipulationlanguage of the existing EMRS. After the results of

the query are obtained, they are repackaged as an HL7message that contains all the specified elements of theCMR and sent via the HTTP protocol back to theAgglutinator. The Agglutinator program thenunpacks all the HL7 messages from each site serverand builds data-type specific Visual Presentationobjects (e.g. a table for the problem list with adifferent column for each hospital site) (7).Once, the Visual Presentation objects have beengenerated, they are translated into the ScreenRendering layer which in this instance is HTML.These pages are sent by the Agglutinator to theHTTP server which then forwards them to the webbrowser where the query originated. If the VisualPresentation object for the problem table specifies aquery that is associated with each data element in thetable (e.g. what are the clinical notes associated withthe problem) then this query is embedded as hiddenfields in the HTML pages so that the query is sent tothe Agglutinator if the clinician selects a problem. Inthis way, the clinician can review the interlinkedrecords of a patient across multiple hospitals.

In the implementation, described above, the display ofclinical data is uniform and independent of theunderlying existing EMRS. It is also fixed by theprogrammed design of the Visual Presentation objectsin the Agglutinator. We therefore have implemented aprogram called WYSIWYG HTML Authoring forMedicine (WHAM) (8) that allows non-programmersto generate clinical presentation specifications using a"drag and drop" interface similar to those of popularsoftware for drawing.In the implementation described above, the physicallocation of the components of the W3-EMRSarchitecture will determine performance of the systemand several security considerations. Clearly, the W3browser is located wherever the clinician happens tobe, in this case the Emergency Room where thepatient is being seen. Also, because most institutionswant to have tight control over any process thataccesses their EMRS, the Site Server is located at thesite of the EMRS it accesses. There is much moreflexibility in the location of the Agglutinator.Regardless of its location, the Agglutinator can accessany specified EMRS from any point on the WorldWide Web. It is unclear how many Agglutinatorswould be required to serve large numbers ofinstitutions, or whether the Agglutinator is bestlocated at every site or at a few central sites.

PROBLEMS IN DATA-SHARING

Shared Data PresentationIn the presentation of data from multiple institutions,it is tempting to integrate the data from all theEMRS into displays that collate similar data intosingle tables or graphs. It has become clear, evenwith the restricted data sets that we have used in ourexperimental multi-database demonstration that thereare substantial differences in semantics, clinicalpractice and documentation style that make simplecollation misleading and potentially threatening to

610

patient care. For example, if the Agglutinatorreceives an active medication list from each of thethree institutions of the Collaborative, it is possibleto generate a single table showing all themedications, sorted by time. However, this tablemight be misleading. Whereas in some EMRS, thestart and end of each medication prescription might beencoded, in most others only the start or prescriptiondate might be noted. This might lead to a dangerousmisunderstanding. Similar difficulties arise with theother data types of the CMR. If in one institution,problems are added to the problem list only once,when they are first noted (e.g. asthma) and in othersfor each episode associated with that problem (e.g.asthma is added to the list for each exacerbation), thismay mislead clinicians as to the chronicity orrelevance of the problems to the patient condition.Also, we have found that in one institution, problemlists tend to include findings whereas in another theyare principally used as lists of diagnosed or suspectedpathological conditions. To address this problem, weare investigating a range of solutions to minimize thepotential for misleading presentations including:separate display tables for each responding EMRS, orintegrated tables labeled in various ways todistinguish the institutional source of each datum(e.g. different columns for each institution, coloredicons corresponding to each institutions). In thefuture, some heuristic collation techniques may beused. There are other data types, such as clinicaldocuments, which tend to carry along enough of thecontext in which they were created (e.g. in the bodyof the narrative text of a clinical note) so that thelikelihood of mistaken interpretation is diminished.

Standardized VocabularyIn the E.R. task domain, the use of a singlestandardized vocabulary is perhaps not quite aspressing as in other domains. If the problem list atMGH includes Grave's Disease and the problem list atthe Beth Israel Hospital includes Thyrotoxicosis,most clinicians will understand how the problems arerelated. Nonetheless, if in one EMRS there is aproblem of "Palpitations" five years ago and inanother "Arrhythmia" two months ago, it would beuseful to know whether the palpitations signifiedarrhythmia in the first EMRS. Also, linkage ofW3BE to W3 decision support tools (e.g. the On-lineMendelian Inheritance of Man and MEDLINE) onlyworks well if the vocabulary of the EMRS can bemapped reliably to the vocabulary of the W3resources (e.g. MESH for MEDLINE). Furthermore,if the W3-EMRS architecture is to be used foraggregate queries across institutions, using the CMRas a common interchange format, then it becomesessential to use a standardized vocabulary so that, forinstance, all patient's with Grave's Disease can becorrectly identified. Several national and internationalefforts are underway to enable mapping betweenmultiple vocabularies, most notably in this country,the Unified Medical Language System (UMLS)Metathesaurus (9), sponsored by the National Libraryof Medicine.

We are investigating implementing UMLS-basedtranslation procedures as part of the Site-Serverfunctions within the W3-EMRS architecture. Someof the clinical vocabularies for the data objects in theCMR are already the same in all the EMRS of theCollaborative. Specifically, the names of medicationsand their NDC codes are all drawn from the databaseof the same commercial vendor. For other attributessuch as the problem name, each member of theCollaborative has their own vocabulary. To presentproblems in a single, standardized terminology, wehave to provide the means to map terms in each localvocabulary to a standardized vocabulary. If the localvocabulary is in the UMLS, then the UMLSMetathesaurus can be used to guide automatictranslation to a target vocabulary that is also withinthe UMLS. Of our three EMRS, only one, the MGHCostar vocabulary is currently being added to theUMLS Metathesaurus. If the local vocabulary is notin the UMLS, then each Site Server must be able toprovide a mapping function from the local vocabulaiyto one of the UMLS standard vocabularies.

As the benefits for shared, standardized vocabulariesbecomes clearer from multi-institutional projects,such as this one, we anticipate that many moreEMRS will adopt standardized vocabularies as theirlocal vocabulary to avoid the cost of customizedtranslation.

Patient SelectionReliable selection of a patient's record is a knownproblem for even single institution EMRS. Name anddate of birth is insufficient to reliably and uniquelyidentify patients. This problem is one of the reasonswhy most EMRS create a unique identifier for eachpatient seen. Even so, this does not prevent errorssuch as multiple ID's per patient. With multi-institutional record access, the problem is larger. Inthe absence of a national health identifier, we arereduced to using collections of patient attributes toidentify the patient. The attributes supported by allthe EMRS of the Collaborative include name, date ofbirth, gender, address, insurance plan and telephonenumber. Each Site Server can respond with an HL7message describing all the patients matching theattribute values sent in a query. The E.R. cliniciancan then specify which of the patients is the desiredone or reformulate the initial query. Potential pitfallsinclude overspecifying a query and thereby excludingthe desired patient (e.g. using an out of date address)or selecting an incorrect patient from a list retrievedby an underspecified query. These problems are wellknown to implementors of single-institution EMRSand their solution is not tractable by computationaltechniques alone. Instead, the solution typicallyinvolves institutional, organizational and workflowchanges. Similarly, the solution of these problems atthe inter-institutional level is likely to involve thecreation of regional information infrastructure thatincludes a regional, cryptographically protected (10),master patient index or directory.

611

Confidentiality Across Multiple EMRS

An obvious potential problem of W3-EMRS is theopportunity to abuse access privileges to invade apatient's privacy. Although similar concerns existwithin any single EMRS, they are more acute herebecause W3-EMRS uses a publicly accessiblenetwork-the Internet-as its communicationsmedium. Fortunately, because there is such a largepublic interest in keeping Internet communicationssecure (e.g. to protect credit card transactions) thecryptographic protection of communications over theInternet is continually being challenged and upgraded.Nevertheless, it remains the case that no matter howgood the cryptographic protection provided, suchsystems remain vulnerable to "insider" abuse.Therefore institutions contemplating sharing datamust first have a shared policy for data security,authentication and disciplinary action in case ofbreach of this policy. It may be that in the comingyear, the U.S. Congress will enact medical privacylegislation that addresses some of the issues relevantto data sharing. In the interim, the Collaborative hasdrafted a Common Confidentiality Statement to serveas policy for our own efforts. This Statement includesseveral requirements of any institution participatingin W3-EMRS. Among these are: 1) Each E.R. willhave one provider at all times designated as beingresponsible for accessing information from W3-EMRS. 2) The designated E.R. provider will use botha hardware token and a hand-entered password toauthenticate themselves to W3-EMRS. 3) Access toW3-EMRS will be limited as a matter of policy tothe time they are in the E.R. 4) Digital signatures,cryptographically authenticating both the E.R. siteand each site server will be required. The digitalsignatures will have to be issued by a mutually agreedupon trusted certifying authority. 5) Patient consentfor record access.

SUMMARY

The first generation of W3BE were single institutionimplementations that have already shown significantuser acceptance. The W3-EMRS project of the BostonCollaborative represents an initial set of experimentsin implementing a second generation W3BE, one thattakes full advantage of the geographic breadth of theWeb to allow access to the longitudinal patient recordas it is distributed across multiple sites, providers andinstitutions. Other groups, notably those of theCERC/ARTEMIS project (I I) are developing secondgeneration W3BE. Our experience with W3-EMRSsuggests that if the institutions, accessed by a secondgeneration W3BE, have truly heterogeneous EMRS,then all of them will have to resolve the challengeswe have noted above. Each of these challenges aresubstantial. Fortunately, there is a large body ofmedical informatics research in these areas and we areoptimistic that we will be able to leverage these priorefforts to meet their challenge. We have found thatthe implementation of W3-EMRS and its ability to

dynamically collate a uniform view acrossheterogeneous EMRS provides a useful laboratory fortesting our solutions to these problems. Finally, wehave found the W3-EMRS project to be an importantfocus for the collaboration of informatics researchersinteresting in advancing the state of the art of EMRS.To this end, none of the W3-EMRS code or design isproprietary. Members of the informatics communityinterested in collaborating on this effort may contactthe authors or visit our web site athttp://www.emrs.orgl.*

REFERENCES1. Kohane IS. Getting the Data In: Three-Year

Experience with a Pediatric Electronic MedicalRecord System. In: Ozbolt JG, ed. Proceedings,SCAMC. Washington, DC: Hanley & Belfus,Inc, 1994:457-461.

2. Kohane IS, Greenspun P, Fackler J, Cimino C,Szolovits P. Building National Electronic MedicalRecord Systems via the World Wide Web. Journalof the American Medical Informatics Association1996;3(3): 191-207.

3. Willard KE, Hallgren JH, Sielaff B, Connelly DP.The deployment of a World Wide Web (W3) basedmedical information system. In: Gardner RM, ed.SCAMC. New Orleans, Louisiana: Hanley &Belfus, Inc, 1995:771-775.

4. Cimino JJ, Socratous SA, Grewal R. Theinformatics superhighway: Prototyping on theWorld Wide Web. In: Gardner RM, ed. SCAMC.New Orleans, Louisiana: Hanley & Belfus, Inc,1995:111-115.

5. Bleich H, Beckley R, Horwitz G, et al. Clinicalcomputing in a teaching hospital. New EnglandJournal of Medicine 1985;312:756-764.

6. Barnett GO, Castleman P. A time-sharingcomputer system for patient-care activities.Comput. and Biomedical Research 1967;1 :41.

7. Wingerde FJv, Szolovits P, Kohane IS. et al.Using HL7 and the World Wide Web for unifyingpatient data from remote databases. In: Cimino Jed. SCAMC. Washington, DC: Hanley & Belfus,Inc., 1996.

8. Hinds A, Greenspun P, Kohane I. WHAM! Aforms constructortor medical record access via theworld wide web. In: Gardner RM, ed. SCAMC.New Orleans, LA: Hanley & Belfus, Inc,1995:116-120.

9. Lindberg D, Humphreys B. The Unified MedicalLanguage System (UMLS) and computer-basedpatient records. In: Ball M, Collen M, eds.Aspects of the computer-based patient record. NewYork: Springer-Verlag, 1992:165-175.

10. Szolovits P, Kohane I. Against simple universalhealth identifiers. Journal of the American MedicalInformatics Association 1994;1(4):316-319.

1i1.Jagannathan V, Reddy YV, Srinivas K, et al. Anoverview of the CERC ARTEMIS Project. In:Gardner RM, ed. SCAMC. New Orleans,Louisiana: Hanley & Belfus, Inc., 1995:12-16.

This research was supported by the National Library ofMedicine (UOI LM05877-01, LM05854, LM4-3512), the Agencyfor Health Care Policy and Research (HS 08749), and in part bySun Microsystems and Oracle Corporation.

612