HL7 Version 3—An object-oriented methodology for collaborative standards development

International Journal of Medical Informatics 48 (1998) 151–161

HL7 Version 3—An object-oriented methodology forcollaborative standards development1

George W. Beeler

Mayo Clinic, 200 First St. S.W., Rochester, MN 55905, USA

Abstract

In January of 1997, Health Level Seven (HL7) began developing Version 3.0 of its standard. The Version 3 effortrepresents a transformation of the way that HL7 and its Technical Committees will develop future HL7 informationinterchange standards. This transformation involves applying object-oriented modelling to the development andspecification of information interchange standards. This paper discusses the rationale that led HL7 to undertake thischange and provides an overview of the Version 3 Message Development Framework which is HL7’s newmethodology. It also considers the features of the Version 3 methodology that can facilitate the development ofinternational collaboration and consensus in health informatics standards. © 1998 Elsevier Science Ireland Ltd. Allrights reserved.

Keywords: Object-oriented modelling; Informatics standards; Object-orientated modelling

1. What is HL7 today?

In order to understand the changes thatHL7 is undertaking, it is necessary to look atwhat HL7 has accomplished and what it istoday. HL7 was formed eleven years ago. Itbegan as a consortium founded at the instiga-tion of a group of health care providers, andset out to develop a protocol for the ex-

change of healthcare information in clinicalsettings. The organization adopted a ‘just doit’ approach, i.e. they followed a pragmaticpath to a solution with no particular fore-thought to the message development method-ology they would be using. With thisapproach, HL7 produced a prototype specifi-cation in the first year, and the first formalversion of the standard, Version 2.0, followeda year later.

The core concept behind the HL7 Version2 specifications is the notion that an externalevent, a trigger event, occurs and is recog-

1 Presented at the International Medical Informatics Associ-ation Working Group 16 Conference on Standardisation inMedical Informatics—Towards International Consensus andCooperation, Bermuda, 12 September, 1997.

1386-5056/98/$19.00 © 1998 Elsevier Science Ireland Ltd. All rights reserved.

PII S 1 386 -5056 (97 )00121 -4

G.W. Beeler / International Journal of Medical Informatics 48 (1998) 151–161152

Fig. 1. Segment diagram for one of the HL7 Version 2.3 messages.

nized by a healthcare computer application.After recognizing the event, this applicationsends a specific message based on that triggerevent through the network to one or morereceiving applications. It is important to notethat HL7 does not specify the communica-tion protocol, only the trigger event and themessage.

The Version 2 messages are delimitedASCII strings divided into segments, and intofields within the segments. Generally, the in-formation content of each segment relates toa particular concept or entity in the health-care domain. Fig. 1 is a sample segmentdiagram for one of the Version 2.3 messages.This diagram provides the segment structure,segment optionality and cardinality, and acomment indicating the information contentof each segment in the context being used.

HL7 has grown significantly using thistechnical foundation. It has published threemore releases of the standard. In 1994, it wasaccredited by the American National Stan-dards Institute resulting in Versions 2.2 and2.3 ranking as American National Standards.HL7 has maintained upward compatibility ofthe message structure in the Version 2 series,and has greatly increased the scope of clinical

functions that its messages support. The cur-rent HL7 standard, Version 2.3, specifies over300 distinct messages and trigger events thatuse 113 segment types, 50 datatypes, and1250 defined data elements. HL7 standardsare widely used both in inpatient and outpa-tient clinical care settings.

At present, HL7 has 1700 members includ-ing individual members and representativesfrom 450 member organizations. HL7 hassix, active international affiliate organizationsthat are working to create HL7 implementa-tions for use in their own countries. Over 400participants registered for the most recentHL7 meeting. The HL7 Working Group ismade up of Technical Committees and Spe-cial Interest Groups (SIGs) that provide thehealthcare domain and technology expertiseneeded to develop the standards.

The current Technical Committees andSIGs provide domain expertise in: patientadministration, financial management, medi-cal orders, inter-enterprise referrals andscheduling, clinical results reporting, infor-mation and medical record management, vo-cabularies and medical terminology, patientcare goals and guidelines, decision support,and home health services. Other committees

G.W. Beeler / International Journal of Medical Informatics 48 (1998) 151–161 153

provide technical expertise in the areas of:message control and queries, interface imple-mentation, modelling and methodology, HL7architecture and quality assurance, auto-mated data, interface conformance, imagemanagement, object broker technologies, se-cure transactions, and SGML-based messag-ing.

2. Why adopt a Version 3 methodology?

Given the current strength and scope ofHL7, one might ask why HL7 is changing toa new methodology. The answer is that thetechnical structure of Version 2 has carriedthe organization about as far as it can.

The principal limitation is that the currentstandard is not easily implemented. Any par-ticular interface may require many weeks ofanalyst time to implement. The communicat-ing systems must agree on whether to use theoptional fields, and must be certain that theyhave the same semantic interpretation of thedata elements. Without this analysis, an in-terface will suffer from the inconsistenciesthat are either inherent in the standard orthat arise because of the way various groupsinterpret the standard.

Secondly, the messages in Version 2 have alarge number of optional segments and fields.These preclude rigorous conformance testing.Finally, the amorphous development processmakes collaboration between HL7 technicalcommittees difficult, and the standard doesnot lend itself to implementation in alternatecommunication protocols.

3. Overview of HL7 Version 3

To address these shortcomings, HL7 un-dertook development of the Version 3methodology. This development began for-

mally in 1994. The Version 3 Task Forcebenefited from prior collaboration betweenits members and members of other standardsgroups in such efforts as the IEEE P1157(MEDIX) Committee, and the activities ofCEN TC-251 (especially Project Team 25 forWorking Group 3).

In January of 1997, the Version 3 TaskForce published the HL7 Version 3 MessageDevelopment Framework (MDF) and intro-duced it to the Working Group for its use.The MDF is a complete, fully documented,model-based methodology for developingmessage specifications. It specifies four mod-els to be developed in the course of produc-ing a message standard. Fig. 2 is a diagram ofthese models. This figure includes a box foreach of the four models, and symbols repre-senting the documentation for the model. Italso shows annotation balloons that indicatethe development steps for each model. Al-though the arrows between models indicatethe primary sequence of development, theactual development process will be cyclical.Development teams will return to refine ear-lier models after they have undertaken defini-tion of one of the later stages, and havelearned of additional requirements. (TheMDF document can be reviewed at http://www.mcis.duke.edu/standards/hl7/hl7.htm)

The methodology of the MDF is based onobject-oriented methodologies for the usecase, information and interaction models.These methodologies are constrained in orderto ensure that the resulting process meets theneeds of message standards developmentrather than of application development.

HL7 message development is a distributedprocess. Each Technical Committee con-tributes to the standard in its domain ofexpertise. A modelling facilitator from theModelling and Methodology Committee as-sists each committee in doing its modellingand helps with the tasks of model harmoniza-


Fig. 2. Diagram of the primary models, development steps and documented deliverables specified by the HL7 Version3 MDF. Figs. 2–5 are reproduced with permission of Health Level Seven, Inc.

tion. Technical specialists and HL7 staff sup-port the committees in the specification of theImplementable Message Specifications and inpublishing the standard.

3.1. Use Case Model

The Use Case Model is the first in theseries of models to be developed. It definesthe circumstances in which information mustflow between applications, and be managedby them. It documents the expectations forthe behavioral relationships between commu-nicating systems that use HL7, and forms thebasis for identifying and defining the keyinformation concepts.

3.2. Information Model

The Information Model is perhaps themost critical element in the process, becauseevery HL7 message must draw its informa-tion content from a single shared model. Theshared model is known as the HL7 ReferenceInformation Model (RIM). It is a completeclass model that includes subject areas, at-tributes for each of the classes, inheritancestructures and instance connections or rela-tionships between the classes. In addition,it includes a state transition diagram to ex-press the life cycles for each of the subjectclasses.


3.2.1. Information model de6elopment processDue to RIM being used by technical com-

mittees, and because each committee is ex-pected to provide model content in its area ofdomain expertise, HL7 develops the RIMusing a process that provides for distributeddevelopment within each committee coupledwith periodic harmonization reviews to com-bine the changes recommended by the vari-ous committees. Each class in the model hasa steward committee responsible for coordi-nation of changes for the class. This steward-ship provides critical review and continuityduring distributed development.

At the beginning of the process, each com-mittee extracts from the RIM the classes ofinterest to their task. It uses these classes as aworking model. Subsequently, the committeedevelops proposals to extend or change thisworking model in order to meet the needs oftheir domain. This usually occurs during theWorking Group Meetings. In between eachpair of Working Group meetings, theMethodology and Modelling Committee col-lects the proposed RIM changes from eachcommittee. It posts these on the HL7 web sitefor review. Finally, before the next WorkingGroup meeting, it conducts a harmonizationmeeting. During this meeting, each commit-tee presents and defends its changes to aharmonization committee made up of a stew-ard and a modelling facilitator from eachtechnical committee. After hearing the discus-sion, including the recommendation of theclass steward, the harmonization committeevotes to accept or deny each proposedchange. Regardless of the outcome, the tech-nical committees are expected to use the har-monized version of the RIM as the basis fortheir message development.

The goal of the harmonization process is todevelop the RIM as a coherent, shared infor-mation model which will provide all of thecontent of HL7 messages. The process as-

sures that the RIM is a joint work product ofthe Working Group as a whole, and is builtusing the functional knowledge of the Tech-nical Committees.

3.2.2. Subject classesSubject classes in the information model

provide a direct link to the trigger eventsspecified in the interaction model. Subjectclasses are those classes whose informationmust be actively managed by clinical health-care computer systems. For example, in theHL7 domain, classes like patient, orders andresults are commonly the management re-sponsibility of one or more computer applica-tions. On the other hand, classes like‘insurance contact’ may provide content formessages, but are rarely actively managed bythese applications. Because of their centralrole in HL7 domains, the subject classes arethe foci for trigger events. Therefore, a com-plete life-cycle is specified for them in theform of a state diagram. Each state transitionin the diagram is a potential trigger event.

3.2.3. Starter 6ersion of HL7 RIMIn order to launch Version 3, HL7 com-

missioned and funded a project to develop astarter, draft RIM. The project used modelsfrom a variety of sources. These include mod-els from HL7 technical committees, fromother standards developing bodies, and fromseveral organizations that are members ofHL7. The concepts embodied in these modelswere combined in a single model, givingprecedence to the HL7 Technical Committeemodels. The draft starter model received apreliminary review by representatives of sev-eral technical committees and then was pub-lished in January 1997 for use by the HL7Working Group.

HL7 used this starter RIM to initiate theiterative harmonization process describedabove. As of this writing, there has been one


harmonization cycle, and a second will com-plete in November 1997. The complete RIMis fully documented in a variety of modalitiesand can be downloaded from the HL7 website at http://www.mcis.duke.edu/standards/HL7/hl7.htm.

3.3. Interaction Model

The Interaction Model defines the behav-iors of systems that communicate using HL7messages. In the Interaction Model, the com-mittees define trigger events, interactions andapplication roles. Trigger events are derivedfrom the use case model and from the statetransitions of the subject classes in the RIM.

Interactions are single, one-way informa-tion transfers that associate a message, atrigger event, and two application roles. Oneapplication role sends the message and onereceives it. The interactions are equivalent tothe trigger event/message combinationsdefined in versions 2.x of the standard.

Application roles are new in Version 3.They are sets of responsibilities for messagingthat a particular application may take on.Each role is defined in terms of the interac-tions it must send or receive in order tosupport a particular function.

Typically, an application will play severalroles. For example, an orders system mighttake on the roles and responsibilities of a‘patient tracker,’ an ‘order manager’ and a‘results tracker.’

Application roles are central to the defini-tion of application conformance. Messageformats in Version 3 will not have optionalfields or segments. This is possible becausethe message design process (next section) sim-plifies the creation of multiple formats orprofiles for a given message structure. Be-cause of this simplification, the standard de-velopers will be able to create a specificmessage format for each interaction. Thus,

each application role will be defined as aspecific set of interactions where the role hasthe responsibility to send or receive a particu-lar, unambiguously defined message. Thisspecificity will allow both exact definition ofconformance claims and rigorous testing ofthese claims.

3.4. Message Design Model

The final design step undertaken by a tech-nical committee is the Message DesignModel. It is here that a message format isdefined from the information content of theRIM to meet the message requirements ofeach interaction. The committee extractsfrom the RIM those classes, attributes andconnections needed for a particular set ofmessages. This extract is the message infor-mation model (MIM). Not only is the MIMa proper subset of the RIM, but it may alsofurther constrain elements of the RIM suchas object cardinality attributes and allowablespecialization. Fig. 3 is an example MIM.

The MIM provides the basis for construct-ing a message object diagram. This diagramis a structured set of objects that instantiatethe classes of the MIM. The process of con-verting the MIM to a data structure is toodetailed to present in full in this paper. Itinvolves a ‘walk’ along the graph of theMIM, guided by the cardinality of the con-nections and the known requirements of thetask. In the course of the walk, class in-stances are selected and deposited in the mes-sage object diagram. This process was firstdeveloped in CEN TC-251 WG-3 ProjectTeam 25 [1], and used in several CEN mes-sage standards.

The next message design step expands theobjects in the message object diagram byspecifying for each object in the diagram theattributes that are candidate data fields forthe message. The result is the structural


Fig. 3. Hypothetical Message Information Model for exemplar HMD in Figs. 4 and 5.

(right-hand) portion of a Hierarchical Mes-sage Description (HMD). This structure isthe abstract representation from which eachmessage format is drawn. Fig. 4 contains anexample right-hand side of an HMD. TheMIM from which the HMD is drawn isshown in Fig. 3. This HMD structures theobject views and the attributes, expresses therelationships that led to the inclusion of theseelements in the diagram, and provides iden-tifiers, labels and an additional descriptionfor each row. Note that the bold-faced rows,those with an assigned ‘Seg ID,’ are directlyanalogous to the message segment structurediagrams of the Version 2.x standards. (SeeFig. 1)

The final step in the process starts with thecore structure contained in the right-handportion of the HMD. This step defines one ormore message formats that are recorded inthe left-hand portion of the HMD. Thesemessage formats are profiles defined for par-

ticular interactions. An example is shown inFig. 5. Each of the message formats showwhether a particular row is included in thatformat, whether it is conditionally includedand what its optionality and cardinality willbe in the message. The series of messageformats or profiles for a particular HMD arerepresented in the left hand sets of columns,as in Fig. 5 which shows all columns of theformat for message A55, and the first fewcolumns of the format for message E31. Atypical HMD will have several such formats.The example includes two different profilesdefined to meet the requirements of two dif-ferent interactions.

To a certain degree, HL7 Version 2.xstopped with the specification of the messagestructure (right-hand side of the HMD) andleft the specification of profiles as an imple-mentation activity. In contrast, Version 3 willinclude particular profiles or formats for eachinteraction.


Fig. 4. Details of the right side of a Hierarchical Message Description.

3.5. Implementable message specification

HL7 will use the Hierarchical Message De-scription as the primary focus for its ballots.Once the HMD is approved by ballot, it willbe used in combination with one or moreImplementable Message Specifications (IMS)to define actual messages and communica-tions. An IMS is specific to a particular com-munication protocol. It provides thealgorithm for using an HMD to generate orinterpret message structures appropriate forthat communication protocol.

The communication protocols for whichIMS’s will be defined may be printable char-acter streams, similar to HL7 Version 2, alter-nate character syntaxes such as EDIFACT,object interfaces suitable for communicationwith object middleware (such as CORBAORBS and Microsoft’s OLE automation) oralternate representations such as SGML.

4. Features of Version 3 that favorinternational collaboration

The preceding section of this paper outlinesthe methodology HL7 will be using indeveloping Version 3 of its standard. HL7plans to begin publishing V3 specificationsduring 1998, and will make its ‘work-in-progress’ available at the web site through-out this period. The next question to con-sider is how might the Version 3 processassist in bringing about cooperation and con-sensus for international health informaticsstandards. Four particular topics are worthyof consideration—communication adap-tability, collaborative standards develop-ment, the ability to use a variety of codesand vocabularies; and the option to specia-lize portions of the standards in order toaddress region- or nation-specific require-ments.


Fig. 5. Hierarchical Message Description HMD of Fig. 4 with a message format added.

4.1. Communication adaptability

Communication adaptability is the abilityto realize messaging in a variety of forms inorder to meet the specific protocol require-ments of a given country or area. This adapt-ability exists because the entiredomain-specific content of messages is cap-tured in the abstract message definitions ofthe HMD, and these definitions can be read-ily mapped to multiple protocols.

Thus the methodology provides equallywell for communications with ASCII stringsor via ORB interfaces; for protocols that arestandard protocols or those that are not; forbroadcast or point-to-point communications;for file, message or transaction-based messag-ing; and for the definition of a variety ofapplication roles which aggregate communi-cation responsibilities.

4.2. Collaborati6e standards de6elopment

The second feature of the methodologythat lends it to international collaboration isthat the methodology is designed to supportcollaboration between disparate interests. Af-ter all, the HL7 technical committees and

SIGs collaborate in the development of HL7.The prospect of international collaborationarises because the process is model-based,and thus there is the opportunity to harmo-nize the models on a broader scale.

Indeed, in August 1997, HL7 agreed toaccept recommendations for RIM changesfrom any accredited standards developing or-ganization. This was undertaken as a firststep towards opening the process to abroader range of participants. The HL7 pro-cess offers the opportunity for collaboration;for discourse on national and regional differ-ences and similarities; and for specializationof the model to meet local needs. Thus, itmay serve as a prototype for harmonizingdisparate standards in the future.

4.3. Adoption of 6arious codes and6ocabularies

The third advantage of Version 3 lies inoptions that it provides for using variouscodes and vocabularies in its messages. In1996, HL7 formed a Special Interest Groupon vocabularies. This SIG is co-chaired byDrs Stan Huff, James Cimino and W. EdHammond. According to its charter, the SIG


seeks to provide an organization and a repos-itory for maintaining a coded vocabulary thatcan be used in conjunction with HL7 andrelated standards and that will enable theexchange of clinical data and information insuch a way so that sending and receivingsystems have a shared, well defined, and un-ambiguous knowledge of the meaning of thedata being exchanged.

To achieve this goal, the group will workcooperatively with other groups having aninterest in coded vocabularies used in clinicalcomputing. These groups will include: stan-dards development organizations, creatorsand maintainers of vocabularies, governmentagencies and regulatory bodies, clinical pro-fessional specialty groups, vocabulary con-tent providers, and vocabulary tool vendors.

In order to accomplish its goals and tominimize redundant effort, the SIG will seekto use existing vocabularies or term lists fromauthoritative governmental and privategroups. During its meeting in August 1997,the SIG began to articulate a series of princi-ples defining the kinds of terminologies thatmight be used. These preliminary, unballotedprinciples would accept: terminologies thatare compliant with the semantics of the HL7message structure; terminologies that are con-tributed as a source to the UMLS meta-the-saurus; terminologies for which there existsan organization committed to the timelymaintenance and update of the terminology;terminologies that are free from excessivelicense fees; and terminologies that are com-prehensive for the intended domain of use.

These principles will not exclude country-specific terminologies mandated by regula-tions, provided that such terminologies arecompliant with the semantics of the HL7message structure. Finally, the group willprobably favor terminologies that have over-sight by nonprofit professional organizationsin the healthcare field. Once the SIG has

refined these principles, it will offer them forballot by the HL7 membership.

4.4. Specialization to meet region- ornation-specific requirements

The models upon which Version 3 is basedprovide numerous opportunities to define so-lutions that meet region-specific or nation-specific needs. In particular, the informationmodel can be adapted to meet these needs byadding new classes or by creating specializa-tions of existing classes. Local terminologiesand coding structures unique to a particulararea can be used with the standard messages.Application roles may be tailored to the spe-cific requirements of a set of users. Newtrigger events and/or new interactions can bedefined, thus creating a region- or nation-spe-cific message interaction. Regional or culturaldifferences in such things as patient demo-graphics (e.g., name, address, orthographicvariety of name, etc.) are readily accommo-dated via specialization.

5. Conclusion

The strength of HL7 Version 3 comes fromthe flexibility of the models upon which it isbased, coupled with the defined methodologyfor using these models to develop standards.These same strengths make HL7 Version 3 aworthy candidate as a methodology to use ingenerating collaboration and consensus be-tween multiple standards developers in aninternational effort.

Because of its limited length, this paper hasprovided only a flavor or sense of what HL7Version 3 entails. The reader is encouraged tovisit the HL7 web site at http://www.mcis.duke.edu/standards/HL7/hl7.htmto learn more. Links from that page lead tothe complete Version 3 Message Develop-


ment Framework; the current rendition ofthe HL7 Reference Information Model; andthe Work in progress of each of the manytechnical committees and SIGs of HL7.

Acknowledgements

The author wishes to acknowledge the ef-forts of the HL7 Version 3 Task Force, bothfor its definition of the methodology and forits contribution of figures and editorial re-

view of this submission. Particular thanks areoffered to Jacob Golder, Ted Klein, WesRishel, Mark Shafarman, Abdul-MalikShakir, Mead Walker.

References

[1] Segars, D., Methodology for the Development ofHealth Care Messages, CEN/TC 251/PT3-025Draft Final Document, Dirk Segars Project TeamLeader CEN Central Secretariat, Brussels, 1995.

.

Documents

HL7 Version 3—An object-oriented methodology for collaborative standards development