The Evolution of a Standard for Patient Record Communication:A Case Study

Sean McLindentt, Gina D'Ascenzo Carlost, and Charles E. OlesontDecision Systens Laboratoryt andInformation Services Division*

University ofPittsburgh Medical Center

AbstractThe establishnent of a standard for electronic

patient record communication has been an iterative pro-cess invlving the integration of information from avariety of sources representing multiple interests in thehealth care process. We discuss the development ofMEDIX, an evolving IEEE standard for medical datainterchange, as it evolved from the earliest concerns forthe communication ofpatient data to what is the currentscope ofmedical knowledge representation and communi-cation in the context of the inplementation ofa prototypedistributed multimedia patient record.

1. IntroductionPatient care is a decision making process, represen-

tative of a class of problems which interest informationscientists known as collaborative or multiagent processes.The characteristics of these collaborative efforts are thesubject of a great deal of research into the socialprocesses by which human agents act in distributed prob-lem solving scenarios. Sadly, little of this research hasbeen focused on the domain of patient care, specifically,and few of the agencies charged with research into healthcare have explored the significance of these researchadvances to health care delivery.

It is interesting to note, then, that a unlikely nidusof enthusiasm for such research comes from what is,nonetheless, a logical source: the medical data inter-change standardization process. For the social nature ofthis process becomes most manifest in the communicationof patient knowledge and human patient communicationis the most sophistcated example to which we can refer.The ability of electronic communications protocols topreserve the knowledge content of human communicationand to represent not only the da, but the process ofpatient care may lead to applications of technology farbeyond that of which we are now capable.

The capture and representation of human patientrecord communication is not, merely, of academic interestsince it often provides information on the rationale of carenot found in the explicit medical record documentation.Such knowledge has proven to be of increasing interest toagencies charged with the evaluation of health care qual-ity and cost such as the Health Care Finance Administra-

tion. Through the evolution of communications protocolshas come awareness of both the complexity of the patientcare process and the research needed to better formalizedescriptions of that process.

For the design of a prototype implementation of adistributed multimedia electronic patient record system,we explored the use of existing and developing standardsfor patient record communication and settled on, not astandard, but rather, a process by which a standard wasbeing developed (MEDIX). The chaacteristics of thatprocess, and of other patient record data standards is thetopic of the following discussion.

2. ASTM 1238-88[1]The American Society for Testing and Materials

(ASTM) Stard 1238-88, one of the earliest standardsfor communication between agents in a health care pro-cess (and by agents we mwan either humans or patientcare systems), involved the description of protocols forinformation exchange between a laboratory and a clinicaloffice. The protocol modeled (as most good protocols do),what occurred in the real world: A request and specimenare sent by mail or courier to a laboratory for a particulartest. Typically the request contains enough contextualinformation to allow it to be cataloged in an unambiguousfashion and to allow results to be queried by or returnedto the originator of the request. Frequently this is done bycontaining, in the request, a great deal of informationwhich is irrelevant to the requested procedure but essen-tial to the identification of the requestor or patient. Atsome point, the test result becomes available and isreturned to or requested by the originator. The return mes-sage may also contain information sufficient to identifythe patient but irrelevant to the clinical concern.

Communications systems such as ASTM 1238-88utlize a post office type protocol. Each message is com-plete with respect to content and address and not depen-dent upon the order or arrival of any other messages.Objects within a message cannot be anaphoristic withrespect to objects contained in other messages, at least notinsofar as the communication protocol is concerned.References to other objects within a message are handledby nesting records within contextual hierarchies. Forexample, in ASTM 1238-88, result records are contined

2390195-4210/90/0000/0239$01.00 X 1990 SCAMC, Inc.

within observation order records which are, in turn, con-tained within patient records. Reference to the contents ofother messages must be resolved at the time that the mes-sages are dispatched. Reliability is maintained by insuringthat the strwcture of the message as it affives is no dif-ferent than that as it was sent. Consistency extends only tothe type of data that is each field of the message; there isno attempt to determine consistency within the messageor between messages.

In the earliest of these systems, data abstractionwas uncommon, primarily because these systems tendedto deal with only a small part of the health care process.While E.3 1, the parent committee of ASTM 1238-88, hasa generic concern for computerized systems, includingthose used in health care 1238-88, itself, focuses on theinteraction between office and laboratory. Though consid-erable attention was paid to conceptual consistency withother actions outside the domain of laboratory testing(1238-88 chose, wherever possible, to use standard dataelements for the contents of each message), formalmodeling of these other areas was limited to those dataelements which might influence laboratory test values.ASTM 1238-88 is a remarkably clean and robust protocolthe utility of which was virtually guaranteed by the focuson clinical processes which was maintained by theprotocol's authors and much of ASTM 1238-88 has beenmigrated through HL-7 and into MEDIX. While it pro-vides strong data typing of message content it representslittle of the process of patient care about which MEDIX isconcerned.

3. Health Level Seven (HL-7)[21While the initial focus of ASTM 1238-88 was on

the interaction of clinical record with ancillary laboratory,the focus of the Health Level Seven committee was, fromthe outset, the management of information in hospital-based systems. In ASM 1238-88, there was a manifestconcern for the cost to establish a connection betweenagents since most ASTM systems were to be modem-based asynchronous connect systems. This considerationresulted in a design which allowed considerable amountsof information to packed into single messages. In con-trast, HL-7 assumed that physical connections betweenagents would be static with the cost of the connectionbeing incurred at acquisition time. HL-7 messages aretypically (but not necessarily) more compact and moreatomic with respect to patient specificity. The static asso-ciation model allowed the designers of HL-7 to imple-ment trigger events; real world events which result in theflow of data between systems. The prototypic example ofa trigger event is the admission of a patient to the hospitalwhich causes a number of other systems to be notified ofthat patient's arrival. Trigger events provide a powerfulconceptual framework in which to associate patient

events with changes in the state of the information sys-tem. In addition to trigger events, HL-7 requires that mes-sage acknowledgement reflects an intent on the part of therecipient system to commit the contents of the message toa database. Acknowledgement of receipt alone, such aswhat happens in ASTM 1238-88, is insufficient.

HL-7 addresses many of the concerns of reliablecommunications between static agents in the hospital set-ting, though a number of problems are not addressed bythe current version of the protocol. HL-7 makes noattempt to address issues of network management,authentication of services, or information hierarchies.Although, conceptually, HL-7 could be used to communi-cate any kind of data, the protocol itself makes no attemptto preserve medical record structure. Most importantly,however, HL-7 is, quite strictly, a communications proto-cols. No attempt is made to deal with patient informationas it might be a network rather than a host commodity.And while trigger events are a mechanism by which aminimal amount of process information can be conveyed,there is no formal modeling of the health care process asit exists apart from the patient care data and only minimalsupport for relationships between data elements.

Some of these concerns may be obviated, in thefuture, as both HL-7 and MEDIX have agreed to supporta formal process of convergence on a common subset ofmessage and data formats.

4. IEEE MEDIX[31The developers of the IEEE P1157 Medical Data

Interchange Standard (MEDIX) imposed upon them-selves, frxm the outset, a constraint which might beregarded as quite favorable: MEDIX should be based onOSI Level 7 applications service element. It is unclearwhether the implications of this decision were completelyunderstood by all of those who advocated it for it has, atleast, two levels of meaning.

At the lowest level, OSI is the now famous seven-layered stack; a suite of protocols, built one on top ofanother, which separated levels of functionality into whatare, conceptually, distinct areas. Whether or not this viewof OSI was technically attractive, it was attractive from amarketing point of view and many vendors were quick toannounce OSI compliance as being in the migration path-way for the development of their networidng capability.On this level, then, the decision by MEDIX to go withOSI had market appeal.

But aside from the market appeal of OSI, there is atechnical appeal which is more subtle, but lies at the heartof the MEDIX strategy. In OSI, information is con-sidered to exist within communities which typically tran-scend the traditional boundaries of hardware andsoftware. In the OSI view, it is the information, not the

240

machine, that is important to the user. And so when atenet of the MEDIX effort states that MEDIX will assumeno particular decomposition of the health care system,what is really being said is that there is no decomposingthe health care system. The patient referred to in thelaboratory system is the same patient that exists in theorder entry system. The episode of care under which testA was ordered is the same episode of care in which medi-cation B was delivered. At some level, even withindiscrete implementations of patient care systems there arereferences to objects which are common to all systems.

The commonality of objects in the patient care set-ting suggested that an object oriented representation ofthe world was best suited to task of communication infor-mation about the patient. Object oriented systems supportencapsulation, that is, the association of data and pro-cedures with the object, itself. Each object may haveattributes which are the visible features of the object,management operations which can be sent either to thewhole object, or to the object attributes, behaviours whichare exhibited by the object in response to an operation,and notifications which are emitted from the object inresponse to some external or internal event.

Object oriented systems support inheritence, theability of an object to inherit the attributes and operationsof a parent object. For example, in MEDIX, a patientobject inherits the attributes of the person object and alloperations which can be performed on an object of typeperson will apply to objects of Wpe patient, as well. Thissimplifies the task of developing interfaces to each objectsince where they share common features with otherobjects they can also share operations.

By default, most object oriented systems provide aset of predefined management operations for all attributesof an object. These are: get, set, derive, add, and remove.All management operations occur on the objects, them-selves. These serve as points of reference for the actualdata elements within the application and it is for the appli-cation to detmine what the effects of these operationswill be.

There are many benefits of an object orientedmodel which are being exploited by the MEDIX develop-ers. First, by focusing on the description of low-levelcompact objects, we are able to build a palette fromwhich higher-level systems can be described. The com-monality of the low level objects insures that the stndardcan be used to exchange information between very dis-similar systems while the use of inheritance allows forvery rich higher level descriptions to be shared whereverthere is agreement to support them.

Another value of the object model is that it can beused to create object interfaces to foreign systems whichmap between MEDIX and these systems in a manner

transparent to the user. A MEDIX system could com-municate with a bedside device using the Medical Infor-mation BUS (MIB), a picture archiving system using theACR/NEMA[4] standards, or voice mail messaging sys-tem, with the mapping of information into MEDIX forcommunication with the patient record.

For example, a medicationOrder instance is cratedto support an order for Ampicillin 2 gm IV q. 6 hourstimes 10 days. This object instance is used to dispatch 40instances of a medicationAdministration object to thepharmacy system. Each of these 40 instances will, at theappropriate time, contain a reference to the intravenousinfusion pump located at the patient's bedside. At anytime, the medicationOrder object instance can bequeried as to its status. This query would be referred tothe most recent instance of medicationAdministration,which might be PENDING, COMPLETED, ON-HOLD or RUN-NING, etc. In the case of a RUNNING status, the querywould be passed on to the bedside infusion device, whichmight return an indication that 150cc of a 200cc totalvolume had been infused at 25cc/hour and that 50ccremained to be infused.

Finally, it is significant that almost from the startMEDIX considered, as its scope, the entire patient record(including those data not, commonly, capured in the trad-itional paper record). As a result, co-evolving within theMEDIX communications development is a documentationeffort to express medical record organization and processin strucured, hierarchical mulimedia documents usingthe ISO standard Open Document Architecture (ODA).At least one MEDIX prototype has been built using theODA for medical document representation (NorwegianComputing Center)[5], and another prototype (Universityof Pittsburgh) has been developed which maps ODA tothe datastream employed by the CMU-IBM AndrewToolkit (Atk)[6], a portable X window implementation ofa multimedia document architecture. In addition, plansare underway to provide convergence between the Atkdatastream and the Standard Generalized MarkupLanguage (SGML)[7] using a toolkit developed at OhioState University.

5. The FutureThe architectural reference model for MEDIX was

the Common Management Information Protocol(CMIP)[8], an ISO standard developed for the manage-ment of network objects. While there are many advan-tages to the use of object-oriented frameworks such asCMIP, some drawbacks were identified in the prototypeconstruction process which should be the subject of futuremodifications to the standard. Although CMIP does pro-vide for user customized data types, shared objectrepresentations across systems which extend beyond insti-tutional or organizational boundaries depend upon object

241

registry. Common object definitions must be agreed uponand registered prior to their utilization in a communica-tions platform. Typically ISO registries rely on central ordelegated authorities through which object definitions arerecorded. The need for formal registration slows the pro-cess by which new objects classes are defined, but helpsto restrict the proliferation of ill-considered or untestedobjects. This limitation has prompted a number of partiesto investigate the establishment of dynamic registies inthe form of dictionaries, but the problem of managingthese on an international scale is complex and beyond thescope of this discussion.

An alterative mechanism is suggested by studiesof human communication as approached by research intolmowledge representation and natural language process-ing. It has been observed that human communicationschannels of relatively high bandwidth are supported byshared contexts in which communication contents areinterpret. These contexts are frequently established apriori but not uniquely so, and there are many examplesin human clinical communication where context is nego-tiated as the communication is underway. This negotia-tion allows for the discussants to elevate the current andsubsequent conversations to bandwidths higher than thatestablished early in the process. Negotiation is essentialto human communication. By this process, conversationscan be made to include new contexts and in ationseven as they are in progress. Through negotiation, twodiscussants can begin with very narrow shared contexts,which are quickly expanded to include richer and richerinterpretations. In particular, two discussants can beginwith very different mappings of the world but can quicklyleam where common grounds for discussion exist.

The need to establish mappings for negotiablebiomedical communication is not a new one. The UnifiedMedical Language System is one example of a strategyfor allowing conceptual mappings between the uses ofbiomedical terminology. But missing from UMLS, is fteability to negotiate higher forms from lower level con-cepts in a dynamic fashion. At some level, there is still acentral registry of mappings which are applied to particu-lar communications and representation of the hierarchy isstatic.

The firt efforts to build dynamic mappings intonetworked communications protocols were undertaken aspart of a larger effort to look at the management of com-puter networks where functionality was distributed acrossmachines with varying capabilities and levels of service.It was appreciated that only a base level of service couldbe required of each system in the network, while optionalservices of significant complexity might exist but not beavailable on each system. A prototype network manage-ment system developed for this problem, the HigherEntity Management System (HEMS)[9], relied on nego-

tiation as a mechanism for establishing the capabilities ofsystems participating in a conversation (though HEMS isnot, itself, a conversation-based protocol). HEMS pro-vided a capability equivalent to "Tell me about yourself"from which a communicating agent could learn what werethe features of the system to which it was speaking. Thisinformation could, then, be used to construct higher leveldescriptions of these agents to serve as the basis for com-munication. This type of negotiation is but one of thecapabilities to be explored in future enhancements of theprotocol; distributed transaction processing is another.

It is recognized dtat in a network of communicatingentities, it is common to see data collisions and problemsof maintaining secure and consistent data ma distributednetwork of concurrent processes. The sitaton is some-what simplified for medical applications since rarely candata be changed or destroyed. More often than not,corrections are made to shadow existing or reportedvalues, while incorrect values are made to persist for thepurposes of audit and error recovery. The MEDIX archi-tectural model does not, currently, include a specificationfor trnation processing (TP) or consistency and con-currency reporting (CCR) since these do not, as of yet,exist as ISO standards, but plans are underway to incor-porate such systems when they become available. In addi-tion, current MEDIX prototyping efforts are exploring theuse of fault tolerant stategies within MEDIX environ-ments, even in advance of the formnal standards. It ishoped that this process of prototyping, in parallel withformalizaton of the standard specification, will help toguarantee that the final standard is workable andaddresses the needs of the users.

A third difficulty with MEDIX architectural modelis what it doesn't say, that is, it is conceivable that theuser could specify for some object a behavior which can-not be supported by the protocol, alone. This can be illus-trated by returning to the medication example, above:

Consider that the medicationOrder instance resultsin the creation of some number of medicationAdminis-tration instances (equal to the total number of doses). Aquery of the order object instance for the status of theadministration instance requires that the former alwaysmaintain knowledge of the latter. The ability of system toguarantee that an object can always refer to another objectis known as orthagonal persistence, and is a commonfeature of object oriented dases but not of communi-cation protocols such as CMIP. In order to allow suchfunctionality within our MEDIX implementation, we havecoupled the prototype to an object oriented dasewhich is used to cache objects whose persistence isrequired by the object behaviors. Through this database,we are able to track and record the flow of informationwhich, we hope, will give us greater insight into the pro-cess of patient care.

242

Finally, it is important to note that research intohuman communication suggests that conversationinvolves a relationship between discourse intentions, (i.e.,what is the intent of the discussion?), and commonsensetask plans, (i.e., what is plan which underlies thediscourse?)[10]. For example, in human clinical conversa-tion, the question "What is the patient's coumadin?"might have as a simple discourse intention to obtain thevalue for the patient's coumadin dosage or level. Whichof these is actually being requested depends upon com-monsense knowledge (coumadin levels are not, typically,measured in a clinical setting since they are of question-able clinical value). But the commonsense task plan sug-gests other possible discourse intentions, as well. Forexample, commonsense knowledge states that the meas-urement of the therapeutic efficacy of coumadin is typi-cally obtained through a physiologic assay, the prothrom-bin time (T). Therefore, an alternative discourse inten-tion might be to ask 'What is the patient's PT?". Theknowledge as to which of these is the case depends uponthe clinical context and may depend upon what priorknowledge exists on the part of the discussants.

Though the relevance of discourse models tohuman communication may be obvious, less obvious aretheir relationships to machine to machine communication.But as MEDIX is concerned with conversations betweenagents in the health care process (where agents may bedefined as simple systems which support databases or ascomplex systems which support artificially intelligententities such as decision support systems), the ability tomodel more sophisticated patterns of intelligent discoursemay provide us with new levels of communication not,previously, imagined. To the best of our knowledge thisview of communications protocols, that they shouldmodel human communication, has not been advocated inany other standards process and is has been inadequatelystudied in medical applications due to lack of support forsuch research at the Federal levels.

6. ConclusionIn developing prototype of a distributed patient care

system we have explored many standards for patientrecord communication but in the end, we have settled ona process, rather than a protocol in which to work. Thisprocess builds on the successes of earlier efforts whilepromising to extend our capacity to support high levelinformation management in patient care. Our progresssuggests that an iterative effort is needed, and that Federaland commercial support for these iterations is critical tocontinued development of these technologies. We hopethat the limited successes of efforts such as these will pro-mote the establishment of new avenues of research.

7. AcknowledgementsThe early phases of this work was supported

through grants from the National Library of Medicine (5-R01-LM03710) the National Institutes of Health (3-R24-RR01101) and Sun Microsystems, Inc. Additional, gen-erous, continued support has been provided by DigitalEquipment Corporation (DEC), and IBM, and the Infor-mation Services Division (ISD) of the University of Pitts-burgh Medical Center. Our thanks, especially go to Wil-liam Reight (DEC), Alan DeWitt (IBM), Paul Sikora(ISD), and Ken Olsen (3M) for their support and assis-tance.

8. References[1] American Society for Testing and Materials, Stan-

dard Specification for Transferring Clinical Obser-vations Between Independent Computer Systems(Designation E 1238), Philadelphia, 1989.

[2] HL-7 Working Group, Health Level 7 InterfaceStandard Version 2.1 Philadelphia, 1989.

[3] IEEE Electonics in Medicine and Biology Society,IEEE Draft Standards 1157.1, 1989.

[4] Best, D., Folders: Version 5 of Tuesday Jun 19,1990, Exhibit F of Minutes of Working Group VI,ACR-NEMA, June 21-22, 1990.

[5] Hannemyr, G. (ed), A Reference Model for HealthCare Information Processing and Communication,and its Implementation in ODA, Report no. 836,Norwegian Computing Center, Oslo, 1990.

[6] The Andrew Toolkit: Programmer's Guide(Volumes 1 and 2), Information Technology Center,Carnegie Mellon University and IBM, Inc., 1989.

[7] ISO JTC 97 N 8079, 2nd DP 9595-1 InformationProcessing: - Text and Office Systems - StandardGeneralized Markup Language (SGML),December, 1986.

[8] ISO/IEC JTC 1/21 N 2058, 2nd DP 9595-1 Infor-mation Processing Systems - Open Systems Inter-connection - Management Information ServiceDefinition - Part 1: Overview, December, 1987.

[9] Partridge, C and G. Trewitt, The High-Level EntityManagement System (HEMS), RFC 1021, InternetNetwork Working Group, Stanford, California,October, 1987.

[10] Litman D. J. and J. F. Allen, "Discourse Processingand Commonsense Plans", in Formal Theories ofCommunication L1271A, 1978 Linguistics Institute,Stanford University, Jul 29-Aug 7, 1987.

243