CHAPTER 225 HL7 Preface - FPAarchive.forumpa.it/forumpa2003/sanita/cdrom/cnr/documenti/225ch… · 10/02/1998 · healthcare system in the United States of America. In this context

NHS IT Standards HandbookPart 2

Version 0.3 Crown Copyright 2001 H225-1

CHAPTER 225HL7

PrefaceWorldwide, HL7 claims, probably rightly, to be the most widely used message communicationstandard in medicine.

The HL7 (Health Level Seven) communication standard was originally developed for thehealthcare system in the United States of America. In this context it enables electroniccommunication between nearly all their involved institutions and in all fields. To date, the mostextensive experience as to its use exists in hospitals and with the reimbursement organisationsthat underpin healthcare in the USA.

This chapter is gives an introduction to HL7 in the context of its growing availability and de factouse within the NHS. Goals and basic concepts are explained; examples and figures illustratethe design and application of the standard. Current and future developments and challenges ofHL7 are discussed. These current developments indicate that HL7 has not only become animportant messaging standard in hospital medicine, but also provides powerful drivers for towardworldwide standardization of communication in the wider healthcare context.

The worldwide HL7 community is seeking to co-ordinate its efforts with those of otherstandardization bodies like CEN/TC 251, DICOM, ISO/TC 215, and W3C. In parallel with thisformal co-ordination, from its parent organisation in the USA HL7 is encouraging the formationof international affiliate organisations, one which now exists in the UK as HL7-UK.

Much of the text of this chapter (including the illustrations) is adopted or adapted, by kindpermission, from an excellent introductory booklet prepared by HL7 Germany1 and now availablefrom the HL7-UK website. Much detailed information about HL7 is available from the website ofthe HL7 Inc. in the USA, some of which has been used here with kind permission of the HL7Secretariat.


H225-2 Crown Copyright 2001 Version 0.3

CONTENTS

1 Introduction

1.1 What is HL7?

1.2 Basic principles of HL7

1.2.1 Introduction

1.2.2 System architecture

1.2.3 HL7 message communication standards

1.2.4 Interoperability

1.3 Adoption of HL7

1.4 Status of HL7

1.5 HL7 publications

1.5.1 Introduction

1.5.2 HL7 Version 2

1.5.3 HL7 Version 3

1.6 Strengths and Weaknesses

1.6.1 HL7 Organisation

1.6.2 HL7 Version 2

1.6.3 HL7 Version 3

1.6.4 Summary of strengths and weaknesses

1.7 HL7 in the NHS

1.7.1 The role of HL7-UK

1.8 HL7 v2 to v3 migration strategy

2 HL7 Version 2 fundamentals

2.1 Introduction

2.2 General Version 2 design principles

2.2.1 Trigger events

2.2.2 Messages

2.2.3 Multi-purpose messages

2.3 HL7 Version 2 message structures

2.3.1 Message content

2.3.2 Messages

2.3.3 Segments

2.3.4 Fields

2.3.5 Abstract Message Syntax

2.3.6 Encoding Rules

2.3.7 Lower Layer Protocol

2.3.8 Segment tables

2.4 HL7 Version 2.3

2.5 HL7 Standard Version 2.3.1

2.6 HL7 Version 2.4



2.6.1 Introduction

2.6.2 Chapter structure of Version 2.4

3 Version 3 fundamentals

3.1 Introduction

3.2 Design principles

3.2.1 Introduction

3.2.2 Compatibility with Versions 2.x

3.3 The HL7 Message Development Framework (HDF)

3.4 The Reference Information Model (RIM)

3.4.1 Introduction

3.4.2 The Unified Action Service Model (USAM)

3.5 Encoding

3.6 UK involvement in development

4 Other aspects of HL7

4.1 Introduction

4.2 Arden Syntax

4.3 The Clinical Context Management Specification (CCOW)

4.3.1 Introduction

4.3.2 The Clinical Context Management Specification (CCOW) Version 1.3

4.4 Clinical Document Architecture (CDA)

4.4.1 Introduction

4.4.2 CDA Levels

4.5 Security solutions

4.6 Vocabulary

5 XML

5.1 Introduction

5.2 XML in Version 2

5.2.1 Encoding Rules

5.2.2 Example Message


6 Strategies with HL7 in the NHS

6.1 Introduction

6.2 Timescales

6.3 Options

6.4 HL7 versus European Health Informatics Standards

6.5 HL7 v EDIFACT

6.6 Relationship to eGIF

7 Conclusions

Annex A Glossary

Annex B Contacts

Annex C Bibliography



1 Introduction

1.1 What is HL7?Founded in 1987, Health Level Seven, Inc., abbreviated "HL7", is a not-for-profit standardsdeveloping organisation that provides standards for the exchange, management and integrationof data that supports clinical patient care and the management, delivery and evaluation ofhealthcare services. Its 2200 members represent over 500 corporate members, including 90percent of the largest information systems vendors serving healthcare.

HL7 is now an officially accredited as a Standards Development Organisation with the AmericanNational Standards Institute (ANSI). Worldwide, HL7 is involved in the standardisation of manyinterfaces between healthcare systems. HL7 international affiliates are active in Argentina,Australia, Canada, China, Finland, Germany, India, Japan, Korea, The Netherlands, NewZealand, Southern Africa, Switzerland, Taiwan, and the United Kingdom.

HL7 specifies communication contents and exchange formats on the seventh (application layer)of the seven-layer model (Figure 1) of communication between open systems, which led to thename Health Level Seven.

The HL7 communication standard was developed especially for the healthcare environment andenables communication between nearly all institutions in most fields of healthcare. With HL7,most important healthcare communication tasks of a hospital can be handled and the efficiencyof the communication process improved.

The goal of HL7 is the largest possible measure of standardisation while providing openness forlocal variations. This concerns both the use itself, and also the formats of specific dataelements: the integration of locale-specific code tables, special business events, and theadaptability to growing communication demands.

The claimed features are:

• formats and protocols are made available for the exchange of data records betweencomputer systems in healthcare

• standardisation of formats and with this, the unification of interfaces

• improvement of the efficiency of communication

• a guide for dialogue between involved parties when negotiating interface arrangements

• minimisation of the number of interfaces

• minimisation of the expenditure for implementing the interfaces

• international standard (ANSI-accredited, and with strong involvement in ISO/TC 215).

1.2 Basic principles of HL7

1.2.1 IntroductionThe name HL7 stands for "Health Level Seven" and refers to the top (seventh) level of theInternational Standards Organization's (ISO) communications model for Open SystemsInterconnection (OSI) - the application level. The application-level addresses the definition ofthe data to be exchanged, the timing of the interchange, and the communication of certain errorsto the application. The seventh level supports such functions as security checks, participantidentification, availability checks, exchange mechanism negotiations and, most importantly, dataexchange structuring.

HL7's stated mission is to: "To provide standards for the exchange, management and integrationof data that support clinical patient care and the management, delivery and evaluation ofhealthcare services. Specifically, to create flexible, cost effective approaches, standards,guidelines, methodologies, and related services for interoperability between healthcareinformation systems."

A frequent misconception about HL7 is that it develops software. In reality, HL7 developsspecifications; the most widely used being a messaging standard that enables disparatehealthcare applications to exchange keys sets of clinical and administrative data.



Figure 1: The ISO/OSI Reference ModelAs an organisation, HL7 has a tradition of working at the fastest possible speed that is bothresponsive and responsible to its members, to develop solutions to the interface requirements ofthe entire healthcare organisation. Typically, this has meant that the early versions of thestandards have used very pragmatic, but not always rigorous, solutions to meet therequirements of already installed hospital and departmental systems, some of which use maturetechnologies.

1.2.2 System architectureAlmost no assumptions are made about the system architecture required by HL7:

• communicating systems can be distributed or centrally organised, e.g., regarding the storageof findings

• the entire extent of HL7 does not need to be implemented; typically most users begin with thetransmission of patient administration/demographic data

• exchange of data between systems can be implemented using various operating systems orprogramming languages

• as a rule, communication over a network is intended, but is not required.

The most varied communication conditions are conceivable: network interconnections (TCP/IP,IPX, Apple Talk), serial connections (e.g., RS232), or batch-input via diskette or magnetic tape.Individual and multiple transactions are also supported.

1.2.3 HL7 message communication standardsHL7 message communication standardises:

• message structures (abstract message definition)

• representation of messages for transmission (encoding rules)

• message triggering application events (trigger events).

It is up to application providers to adapt their data structures to the structures required by HL7messages. However, more and more commercial tools (interface engines) are used for theaccomplishment of this and other tasks concerning communication between subsystems inhealthcare.



1.2.4 InteroperabilityIn general the variation between business processes in the worldwide healthcare environmentmilitates against the development of a universal data model. Therefore HL7 made noassumptions about the architecture of the systems and at this time HL7 can still not be used asa "plug and play" interface.

Nevertheless HL7 is an important step towards interoperability in communication. Although HL7currently does not provide "plug and play" it can still save considerable time and costs for bothusers and manufacturers of application systems. In the newest versions, HL7 pursues theambitious goal to define a healthcare information model and to integrate most of the advancedconcepts for information systems' architecture. In the future HL7 may evolve to become a "plugand play" standard.

1.3 Adoption of HL7While the main focus of HL7 remains on addressing immediate needs in the USA, the groupcontinues to dedicate its efforts to ensuring concurrence with other United States andInternational standards development activities. Australia, Canada, China, Finland, Germany,India, Japan, Korea, The Netherlands, New Zealand, Southern Africa, Switzerland and theUnited Kingdom all now have HL7 affiliate organisations. Moreover, HL7 provides the mainmeans of inter-system messaging in the hospital sector in Australia, Canada, Finland, Germanyand the USA: probably sufficiently widespread use to justify HL7's claim to be the predominanthealthcare communications standard.

In Australia, Canada, Finland, Germany, Japan, Korea, The Netherlands, New Zealand and theUSA there is governmental recognition that HL7 has a central role in healthcarecommunications.

1.4 Status of HL7HL7 is one of several American National Standards Institute (ANSI) accredited StandardsDeveloping Organizations (SDOs) operating in the healthcare arena in the USA. Most SDOsproduce standards (sometimes called specifications or protocols) for a particular healthcaredomain such as pharmacy, medical devices, imaging or insurance (claims processing)transactions. HL7's domain is clinical and administrative data.

Health Level Seven's members (providers, vendors, payers, consultants, government groupsand others who have an interest in the development and advancement of clinical andadministrative standards for healthcare) develop the standards. Like all ANSI-accredited SDOs,HL7 must adhere to a strict and well-defined set of operating procedures that ensuresconsensus, openness and balance of interest.

Members of HL7 are known collectively as the Working Group, which is organised into technicalcommittees (TC) and special interest groups (SIG). The technical committees are directlyresponsible for the content of the Standards. Special interest groups serve as test beds forexploring new areas that may need coverage in HL7’s published standards. A list of thetechnical committees and special interest groups as well as their missions, scopes and currentleadership is available from the main HL7 web site.

HL7 is not, itself, formally represented within the International Standards Organisation TechnicalCommittee on Health Informatics (ISO/TC 215) but has many of its members participating asindividual experts recognised by their respective National Standards Bodies. In a Europeancontext, in 2000 the Comité Européen de Normalisation (European Standards Committee)Technical Committee on Health informatics (CEN/TC 251) established a formal memorandum ofunderstanding designed to enable co-operative working between European experts active inTC251 and their counterparts in HL7.

1.5 HL7 publications

1.5.1 IntroductionConfusingly, there are two messaging aspects of HL7 that are being worked on, the so-calledVersion 2 standard and the major recent development of the Version 3 standard. In additionthere are other significant publications covering:



• The Clinical Context Object Workgroup (CCOW) Context Management Specifications: the most current official ANSI-approved version being v1.2.

• Arden Syntax for Medical Logic Systems: the latest ANSI-approved version being v2.

• Recommendations for HL7 Messaging Over Component Technologies Version 1.0, Rev. 9,January 12, 1998

• Secure HL7 Transactions Using Internet Mail, Rev. 1.7

• Using XML as a Supplementary Messaging Syntax for HL7 Version 2.3.1

• Claims Attachment

• HL7 Security Service Framework

• Standard Guide for Implementing HL7 EDIT Communication Security

• HL7 Version 2.x Message Profiling Specification, Dec 2000.

1.5.2 HL7 Version 2HL7 is best known for its messaging standard, usually taken to mean one of the Version 2.xincarnations. This is a direct result of the original focus of facilitating the core business activitiesof hospitals in the USA by enabling inter-system communication. Only HL7 v2.3 (1997) andhigher versions are now supported, and the latest version (v2.4, 2000) is planned to be the lastmain release in the v2.x series. This is because, as the level of detail required to support themore clinical activities became clear, it was apparent to the board of HL7 that a more rigorousapproach to the development of communications standards would be required. The ad hocapproach that had served well to establish the standard would not work in the more complexarea of tightly integrated support of clinical activity so work started on development of a model-based messaging methodology commonly referred to as "Version 3".

1.5.3 HL7 Version 3Version 3.0 utilises a formalised methodology, outlined in the HL7 Message DevelopmentFramework (HDF), to create messages. That process involves the development of a variety ofmodels, including the Reference Information Model (RIM), an object-oriented data model.

The HDF also calls for the creation of the Interaction Model, which captures information flowsand defines application roles needed to support messages.

An additional goal of HL7 v3 is an expanded suite of data interchange formats. Until now, HL7messages supported a single format using ASCII encoding. In addition to supporting XML it issaid that Version 3 will support the component technologies of ActiveX and CORBA.

1.6 Strengths and Weaknesses

1.6.1 HL7 OrganisationThe obvious strength of HL7 as a standards development organisation is that internationally ithas the largest constituency of developers, vendors and users amongst any of the standardsbodies currently active in the area of Health Informatics. This has enabled it to call upon worldexperts to address difficult problems on a timescale that other bodies in this area cannotcompete with.

The establishment of International Affiliate organisations is now beginning to significantly impactthe output of the US parent organisation, which, however, remains firmly in control. In terms oftimeliness the effect of the widening of the consultative process is as yet unknown, it alreadyappears to be improving the quality of early draft documents.

1.6.2 HL7 Version 2The uptake for the Version 2 messaging standard, particularly since it stabilised at the time ofv2.3, has made it the de facto worldwide healthcare messaging standard. This is chieflybecause it deliberately focussed on the "easy win" areas of patient demographics, ADT andorders and results communications. The vast range of clinical activity that is covered has madeit attractive to vendors from the major integrated HIS/PAS vendors to the smallest niche



specialists. In a UK context however, it has no effective tools to offer within the primary caresector.

The speed of work, and the need for rapid consensus, has often led to a lack of rigour in HL7.This has resulted in more optionality (or room for misinterpretation) than is desirable in astandard, the use of which might be expected to improve interoperability of applications. Anumber of international HL7 affiliates have therefore undertaken the production ofImplementation Guides in order to set out local best practice.

Further, while developing an analytic object model for the definition of a comprehensive HL7Database, the German HL7 user group became aware that the relationship between messagetypes, event types, and the structure of a message is problematic and not handled satisfactorilyin v2. There is no distinct rule defining the relationship between events and messages.Sometimes the event type describes the structure and function of the message. In other cases,it defines the target file to which the data in the message has to be transmitted.

In the past, the requirement for messaging standards was singular: to enable the flow of databetween systems. But interchange requirements needed to meet today's and tomorrow'sdemands have evolved to encompass the ability not only to move the data but to use the dataonce it is moved. HL7 Version 3.0 is being developed to meet that requirement.

1.6.3 HL7 Version 3Version 3.0 utilises a formalised methodology, outlined in the HL7 Message DevelopmentFramework (HDF), to create messages. That process involves the development of a variety ofmodels, including the Reference Information Model (RIM), an object-oriented data model whichprovides a consistent view of the data being moved as well as that data's relationship to otherdata, hopefully ensuring that the messages carry data that is consistent and "useable" to theapplications involved in the data exchange. The result of this structured approach to messagedevelopment will be more trigger events and message formats, but messages that are precisewith very little optionality.

The Interaction Model required by the HDF includes the specific trigger events, messageformats and data elements that are required for each application role, thereby providing a meansto test a vendor's conformance to any particular application role. HL7 plans to certify systemsthat "pass the test."

Version 3 will also take advantage of the benefits of XML to increase interoperability. HL7 hasdeveloped the Clinical Document Architecture (CDA), an XML-based clinical documentarchitecture that provides an exchange model for documents of varying levels of complexity.Using the CDA, Version 3 will enable systems to create XML documents that incorporate HL7message content, to generate messages from document content, and exchange and processmessages and documents between disparate systems.

So Version 3 promises to correct the problems of Version 2 - and more. The downside of is thatin March 2001 only CDA Level 1 exists in a balloted form. The task of achieving a stable, andincreasingly internationally applicable, RIM has proved time-consuming and although anaggressive programme of activity has been commenced to achieve a balloted v3.0 by the end of2001 the real outcome of this (in terms of fitness for purpose) remains to be proven.

1.6.4 Summary of strengths and weaknessesThe following table attempts to highlight some of the strengths and weaknesses of HL7 Version2 with respect to Version 3. It is necessarily somewhat subjective, and is certainly simplistic andincomplete, but is intended to provide an accessible way of assessing the relative merits of twoversions and their development.



Version 2.x Version 3Characteristic Strength Weakness Strength WeaknessParticipation Multi- vendor

and userworldwide

Dominated bylarge US bodies

Large USvendor and USusers and withworldwide input

Smaller vendorsand users not soactive

Development Fast andresponsive

Fast andresponsive

Still responsive Slower

Stability Now very stableand with goodbackwardcompatibility

No furtherdevelopmentbeingsanctioned

Still able toembrace newrequirements

Still notsufficientlystable toencourageimplementation

Current use Widespread Very limitedEase of use Relatively simple

conceptsSignificantambiguity

Said to besimple

Complexconcepts

Internal rigour Improved on thebasis ofrefinement inuse

Poor - just grewon the basis ofneed

Intended to becomprehensive

Significantcompromises insome areas

Use domains Acute sectorpredominates

Primary care Intended to beall embracing

Unproven inclinical systems

UK usability UKImplementationguide

Oriented to USprocesses

Wideinternationalinput

Relationship toUK modelsunproven

XML support XML messagescan be producedusing definedDTDs

Ambiguity ofrepresentation

Designed fornative support ofXML

Unproven inmessaging andcomplexdocuments

Implementationissues

Significantexpertiseavailable

Life limited tosay 10-15 years

Some UKexpertiseavailable

Fitnessunproven

Costs ofmessage

implementation

Lowest currentoption

Only certain iffullunderstanding ofrequirements

Should be easyto quantify

Unknown;should be nohigher than v2 -but moredemanding ofinfrastructure

Table 1: Summary of strengths and weaknesses of HL7 Versions 2 and 3

1.7 HL7 in the NHSThe potential value of HL7 Version 2.3 (and newer) to the NHS is that there is a lot of it about.Most commercially available systems purchased in the last two years from non-UK basedsuppliers (and some UK-based ones too) have some HL7 v2.x capability. To use that for manyof the more mundane, but high volume, message transfers would seem to be a good use ofexisting resources - and because of the massive user and supplier base it is unlikely that theinvestment to date will be quickly abandoned. That this capability comes at the lowest possiblecost for the task increases further the attraction of v2.x for many messaging tasks.

Given the uncertain position of HL7 v3 it is likely that most vendors will stay with v2.x messagearrangements till well into 2002. At that stage, and on new product, they are likely to startreworking messages into the v3 structures, so it may be 2005 or 2006 before any productsincorporating v3 appear in significant volume.

Thus it would seem that, at least for the acute sector, there will be increasing HL7 v2.x capabilitydelivered (effectively at no extra cost) with many commercial software applications from bothlarge and small vendors.



The relatively new Clinical Context Object Workgroup (CCOW) Context ManagementSpecifications offer an increasingly widely used means of taking elements of the user, clinicaland shortly, disease context from one application to another at a graphical front-end (asopposed to the back-end such as a database). While this may not appeal to purists, it doesprovide a work around which can provide apparent (to the user) integration of systems andproducts that do not share a common modelled view of healthcare.

HL7 Version 3 promises many of the functions that should simplify conformance with theGovernment's eGIF requirements, most notably extensive native support for XML andmiddleware component technologies. This, together with the extensive provisions for productionand access to "structured documents" is likely to bring significant benefit in the process ofachieving the higher levels of EPR and of building an EHR framework.

The dilemma, if such there be, is whether to use Version 2 - or to wait for Version 3. This issueis dealt with more extensively in Section 6 of this Chapter and requires knowledge of some moreof the fundamental issues related to the two versions. However, suffice it to say at this stagethat HL7 has some bridging tactics identified - these are examined briefly in Section 1.8.

1.7.1 The role of HL7-UKHL7-UK was established formally in April 2000 as an independent limited company withcharitable status. It is therefore independent of vendors, users, consultants, academia and theNHS, but has members drawn from all these groups.

It was intended by the founding members to have two main short-term benefits in a UK context;firstly, to enable a common understanding of the use of existing HL v2.x standards (written inAmerican English primarily for a US market) to be unambiguously interpreted in the UK. Theirproduction of the Standard for implementing HL7 v2 in the UK has already begun to address thisneed.

Secondly, it was thought, rightly as has transpired, that the experience of various UK experts inthe development CEN/TC 251 standards would be able to influence the US-centric v3development to better reflect the needs of UK healthcare. There is now significant input fromthe UK in many (but not a majority) of the parent HL7 TCs and SIGs and parts, but not all, of theemerging v3 have been strongly influenced.

1.8 HL7 v2 to v3 migration strategyHL7 policy is that future revisions of v2 are limited to minor corrective measures - and will notaddress new areas of scope.

The extensive use of XML assumed in v3 has been thought to provide an opportunity fordevelopment of a migration strategy. However, the v3 (including XML) project is seeking toaddress a number of moving targets, and consensus on XML representation has not yet beenreached for all areas. Given the different philosophies underlying v2.3.1 and v3.0, there willprobably be differences in messaging syntax.

A mapping from HL7 v2.3.1 into XML exists and uses a formal algorithm, driven from the HL7Database mentioned in Section 1.5. As such, ambiguities or errors in v2.3.1 are reflected "as is"in the XML encoding. Fixing such errors in the XML requires making appropriate modificationsto the HL7 Database. Given the current HL7 v2 revision policy, and the small amount of effortnow being dedicated to it, it is not therefore clear to what extent the use of XML implementationsof v2 as a migration strategy is useful - except in so far as it might teach familiarity with XML.

So, although the use of XML in encoding v2 has been promoted as a migration strategy, it hasmore value because of its inherent ease and cost of use -and its compatibility with othercommonly used tools. It is for this reason that there already exist a number of XMLimplementations of v2 - although not all are compliant with the HL7 v2.3.1 XMLrecommendations.



2 HL7 Version 2 fundamentals

2.1 IntroductionHL7 Versions 1 and 2 were originally developed as "bottom-up" solutions to a communicationsproblem. There was little effort expended to derive rigorous data models; nevertheless, therelatively simple message structures defined, using ASCII text and positional notation, haveproved remarkably fit for their intended purpose (providing the ambiguous areas areunderstood).

2.2 General Version 2 design principles

2.2.1 Trigger eventsNormally an event in the real world initiates the exchange of data between two systems.

Example: A patient is admitted into the hospital. The demographics (name, date of birth,information about relatives, insurance, etc.) are recorded in the patient administration system.The event "patient admission" leads to the exchange of data, e.g., between the administrationsystem and a laboratory information system, so that the master data of the patient is madeknown to the laboratory.

In HL7 such an event is called a "trigger event".

Figure 2: Basicprinciple of HL7: anevent in the realworld(trigger event) leadsto the acknowledged(ACK) exchange ofdata between two ormore systems (seetext).

2.2.2 MessagesIn general, two categories of messages are distinguished:

• an unsolicited update as in Figure 2 above

• a query, e.g., the specific inquiry of the laboratory subsystem if the demographics of thepatient in question are available.

A so-called "unsolicited update" (see Figure 3) is produced by an event (e.g., patient admission).This event leads to an internal transaction in the sending system (e.g., database insert). Thenthe data is sent via HL7. The receiver receives a message and can react with an internaltransaction on the receiving system.



Figure 3: Theevent "admissionof inpatient" inHL7 leads to adata exchange bymeans of aspecific, relatedmessage (A01).

Acknowledgement messages (ACK, see Figure 4) are sent back to the sender as a receiptindicating "message arrived" (accept ACK) or "message understood and processed" (applicationACK).

Figure 4:"Acknowledgement"messages canconfirm the senderthat the messagehas been received.

Patient transfer and other messages such as updates can be communicated in the same way(Figure 5).



Figure 5: Using messages, the event "transfer patient" (A02) can be communicated.During a transaction in a system, a query is generated if data is missing. The receiver shouldrespond; beyond that, no further transaction is made. The answer allows the completion of thetransaction for the querying system (Figure 6).

Figure 6: If a patient is unknown, e.g., in a laboratory system, an enquiry using an HL7query can be generated and addressed to the administrative system. The answer

contains the missing patient information.

2.2.3 Multi-purpose messagesIn HL7 not only messages for administrative data are defined. HL7 deals with other areasoutlined in section 2.6.2, together with locale-specific requirements.

2.3 HL7 Version 2 message structures

2.3.1 Message contentThe content of messages can be defined:

• in tables containing values defined in the HL7 Standard

• in user-defined tables

• through references to code tables or other standards (ISO, ICD, ICPM, etc.)

• only as a data type (patient name, pat-ID, etc.)

The hierarchical structure of HL7 is described briefly in the following sections.



2.3.2 MessagesA message is the smallest transferable unit in HL7 v2 and is comprised of segments. It beginswith the Message Header Segment (MSH) and is identified by the message type and theinitiating event (trigger event).

Example: The message which transmits the data of the admission of a patient is identified by themessage type ADT and the trigger event A01 (ADTÂ01).

Figure 7: Schematic content of a message withsegments

2.3.3 SegmentsSegments are a way of grouping items of information in a logical way, e.g. all the patient identityinformation may be held together in a segment. Ordered sequences of fields, they can bedeclared as required, optional, or repeatable. Segments are clearly identified by three letterslocated at the beginning (segment identifier) and are separated by segment separators. So, forexample, an ADT message can consist of the following segments:

Figure 8: Schematic content of an ADT message with thesegmentsMSH message header,EVN description of the trigger events,PID patient identification,PV1 patient visit information.

Despite their wide scope, HL7 v2.x standards are not complete and, as is inevitable in suchsituations, developers produce their own extensions. In HL7, all segments beginning with Z arereserved for such locally defined messages. In the HL7 Standard itself, no Z segments aredefined. Increasingly, Z segments are established or co-ordinated by national user groups. Inthe UK, for example, the transmission of required Augmented Care Profile (ACP) information willbe possible using the segment ZU2, and Waiting List information with ZU4. Where no publicagreement is in place, Z segments need to be used with extreme caution.

2.3.4 FieldsThe information (semantic content), such as patient details, is contained in the fields of thesegments.

Figure 9: Schematic content of a segment with fieldsFields can be of variable length and are separated by field separators. For each field, a datatype is defined, e.g., string, value, time (duration), time stamp.



ST String XPN Person NameTX Text XAD AddressFT Formatted Text XTN Telephone NumberNM Numeric ID Coded Value (HL7 table)DT Date IS Coded Value (user defined)TM Time CM CompositeTS Time Stamp CN ID and NamePL Person Location CQ Quantity and Units

Table 2: Field data typesField contents can be required or optional and individual fields can be repeated. Datadictionaries are used to administer Field definitions; for coded elements, the relevant codes arestored in tables.

Multi-component fields are used for further subdivision of a field and facilitate the transmission oflogically related contents. For example, the data type CE (coded element) combines thetransmission of a code value (e.g. ICD code), the textual description, and the code system fromwhich the code value is taken. Examples of fields with several components are shown in thefollowing table and example.

CN Identification number + NameCE Coded element = Code value + Code designator + Code systemCQ Quantity + UnitMO Monetary value + Currency

Table 3: Fields with typical components

CN 00477^Bloggs^Katherine U.^^Dr. med.

CE 620.2Ôvarian Cyst Nec/NosÎ9

CQ 17,2^g/dl

MO 12,75^GBL

Figure 10: Fields with example contents

2.3.5 Abstract Message SyntaxIn order to enable straightforward exchange of HL7 messages they are structured using AbstractMessage Syntax. This describes the frequency of occurrence (cardinality) and definition(required/optional/repeatable) of control and data segments in a message.

Required segments are identified by the segment identifiers, optional segments enclosed in [ ],repeatable in { }.

Every message begins with information about the message itself (message header MSH, eventdescription EVN, etc.). What follows is usually data about the patient (patient identification PID,patient visit information PV1 and PV2, allergy information AL1, …). Then additional informationis transmitted (request, result, performance data, invoice, …). Figure 11 shows an example ofsuch an abstract message specification.



Figure 11: Example of an abstract message specification from the HL7 Standard

2.3.6 Encoding RulesIn order simplify implementation, HL7 provides a specification for the presentation of data(presentation layer). The so-called encoding rules define a specification of the charactersequences for the representation of messages.

The separating characters used are also specified. Segments, for example, are separated bycarriage return <CR>. The other separating characters are defined in the first five charactersafter the identification of the message header MSH. The default characters are shown in Table4.

| Field Separator^ Component Separator~ Repetition Separator\ Escape Character& Subcomponent Separator

Table 4: Default separators used in messages

2.3.7 Lower Layer ProtocolThe exchange of HL7 messages requires that an error-free and complete transmission isensured within the networks (e.g. by TCP/IP) and an unlimited message length is possible.

If a network is not available, HL7 proposes an alternative for the lower layers of the ISO/OSImodel in the so-called Lower Layer Protocol.

2.3.8 Segment tablesThe exact description of a segment and its attributes are defined in the segment table. Table 5is an extract from the segment table of the Patient identification (PID) segment.



SEQ LEN DT R/O RP# TBL# ITEM # ELEMENT NAME1 4 SI O 00104 Set ID - Patient ID2 20 CX O 00105 Patient ID (External ID)3 20 CX R Y 00106 Patient ID (Internal ID)4 20 CX O Y 00107 Alternate Patient ID5 48 XPN R Y 00108 Patient Name6 48 XPN O 00109 Mother's Maiden Name7 26 TS O 00110 Date of Birth8 1 IS O 0001 00111 Sex9 48 XPN O Y 00112 Patient Alias10 1 IS O 0005 00113 Race11 106 XAD O Y 00114 Patient Address12 4 IS B 00115 County code13 40 XTN O Y 00116 Phone Number - Home14 40 XTN O Y 00117 Phone Number - Business15 60 CE O 0296 00118 Language - Patient16 1 IS O 0002 00119 Marital Status

Table 5: Extract from the segment table for the PID segmentKey to headings: SEQ:Position (sequence within the segment), LEN: Maximum Length,

DT: Data Type, R/O: Optionality, RP/#: Repetition, TBL#: Table Number(of referred values), ITEM#: Number of the Item

2.4 HL7 Version 2.3Although still the most commonly referenced version of HL7, this dates back to 1997 and wassuperseded by Version 2.3.1, which made corrections and additions. In practice, this has littleimpact on most messages, but to ensure trouble-free implementation it is always good practiceto clarify the precise version (and any variations!) implemented before entering into contractualagreements.

2.5 HL7 Standard Version 2.3.1(American National Standards Institute (ANSI) approved April 14, 1999)

Version 2.3.1 includes significant enhancements including updates to the Timing Quantity (TQ)data type to better manage order occurrences, changes to the Observation Request (OBR)segment and the Observation Results (ORU) message to facilitate public health relatedreporting, and various updates to tables, segments and data types to accommodate internationalparadigms for reporting names and pharmaceutical orders.

2.6 HL7 Version 2.4

2.6.1 IntroductionApproved by American National Standards Institute (ANSI) in October 2000, HL7 Version 2.4introduced Conformance Query profiles in Chapter 5, and added messages for laboratoryautomation (Chapter 13), application management and personnel management.

This version has been as the basis for the HL-UK Standard vA.1.

2.6.2 Chapter structure of Version 2.4

Chapter 1 - IntroductionProvides a general overview and history of Health Level Seven.

Chapter 2 - ControlProvides the rules that apply to HL7 control methodology. Includes provisions for conformance.



Chapter 3 - Patient AdministrationProvides the transaction set for transmitting new or updated demographic and visit informationabout patients.

Chapter 4 - OrdersProvides transaction sets to order observations, medications, diets, and supplies.Orders for observations can be made in inpatient, outpatient, nursing home, and homehealthcare settings.

Chapter 5 - QueryProvides the rules that apply to HL7 query methodology.

Chapter 6 - Financial ManagementProvides the transaction set for maintaining patient accounts.

Chapter 7 - Observation ReportingProvides transactions for reporting clinical information such as results of diagnostic studies,consultations and notes, nursing observations, equipment settings, etc. It accommodates bothobservations that result from a request for a diagnostic study and observations performed at theobserver’s initiative. Results reporting can transmit the individual sections of narrative reports(e.g., the left ventricular diameter, the fractional shortening element of a cardiac echo report).

Chapter 8 - Master FilesProvides transactions for synchronising common reference files across various applications at agiven site.

Chapter 9 - Information ManagementProvides transactions for transmitting new or updated documents (or information about theirstatus) that become part of the medical record.

Chapter 10 - SchedulingProvides transactions for transmitting events related to the scheduling of appointments forservices and/or resources.

Chapter 11 - Patient ReferralProvides transactions for exchanging data between disparate systems of primary care providers,specialists, payers, labs and other entities involved in patient referrals.

Chapter 12 - Patient Care Provides transactions to support the communication of records that track a patient’s healthcareproblems, related goals, pathways for meeting those goals, and persons helping attain thosegoals.

Chapter 13 - Clinical Laboratory Automation Defines messages for communication between automated lab devices and laboratoryinformation systems.

Appendix A Data definition tables

Appendix B Lower layer protocols

Appendix C Network management

Appendix D Backus Naur Form message descriptions

Appendix E Glossary

3 Version 3 fundamentals

3.1 IntroductionHL7 Version 3 represents a significant departure from "business as usual" for HL7. Offeringconsiderable optionality, and thus flexibility, the v2.x series of messages were widelyimplemented. These messages evolved over several years using a "bottom-up" approach thathas addressed individual needs through an evolving ad-hoc methodology. There is neither aconsistent view of that data that HL7 moves nor that data's relationship to other data. HL7'ssuccess is also largely attributable to its flexibility. It contains many optional data elements anddata segments, making it adaptable to almost any site. While providing great flexibility, itsoptionality also makes it impossible to have reliable conformance tests of any vendor's



implementation and also forces implementers to spend more time analysing and planning theirinterfaces to ensure that both parties are using the same optional features.

Version 3 attempts to address the problematic Version 2 conformance and optionality issues byusing a well-defined methodology based on a reference information (i.e. data) model. Usingrigorous analytic and message building techniques, and incorporating more trigger events andmessage formats with very little optionality, HL7's primary goal for Version 3 is to offer astandard that is definite and testable, and provide the ability to certify vendors' conformance.Version 3 uses an object-oriented development methodology and a Reference InformationModel (RIM) to create messages. The RIM is an essential part of the HL7 Version 3development methodology, as it provides an explicit representation of the semantic and lexicalconnections that exist between the information carried in the fields of HL7 messages.

The initial release of Version 3 is due for publication in December 2001 and will use only XMLencoding. The first of the suite of documents to comprise Version 3 will be the Version 3Abstract Data Types, its accompanying XML Implementation Technology Specification, and thev3 Messages XML Implementation Specification.

3.2 Design principles

3.2.1 IntroductionHL7 Version 3, like Version 2, will be a standard for exchanging messages among informationsystems that implement healthcare applications. However, a new goal is that "Version 3 shall bedeveloped to permit HL7 Affiliates to use it or to develop localised variants".

As with prior versions, Version 3 is being be designed to permit implementation in "legacysystems." In practical terms, this means that Version 3 will be able to exchange messagesformatted in strings of printable characters, as is the case for all previous versions. However,this does not preclude HL7 from deciding to develop variants of its specification that make useof modern technologies - provided that system builders will not be required to buy software froma sole source in order to implement Version 3.

Version 3 will not be a standard for the functionality of the systems that exchange HL7messages; however, where it includes a requirement to accept or send certain data or to sendspecific messages in response to trigger events or other messages, the application system mayhave to develop functionality to support those requirements.

3.2.2 Compatibility with Versions 2.xIs has been asserted that the goals of Version 3 cannot be achieved while maintaining fullcompatibility with previous versions. However, Version 3.0 will be developed to cover theinformation content of the last version in the v2.x series including attributes and trigger events.This should not be construed to mean that all attributes and trigger events will be included in 3.0in exactly the same form.

A network that includes a mixture of systems that implement Version 2 and Version 3 will requiremessage translation. Because the Version 2 standards have substantial optionality, thetranslations will use rules specific to the systems on that network. It is expected that "interfaceengines" and translation software will be able to provide the translations between specificinterpretations of 2.x and implementations of Version 3.

The indications from the NHS Electronic Record Development and Implementation Programme(ERDIP) projects are that the EHR functionality required will not be supportable solely bymessages. Common interfaces will need to be developed; the HL7 CCOW methodology maybe one candidate in this area (see section 4.3).

3.3 The HL7 Message Development Framework (HDF)The HL7 Version 3 HDF sets out to describe the generic tasks that must be undertakenrigorously in order to produce a set high quality of HL7 message specifications. UML modellingis used throughout: relying on storyboards and Use Cases to capture the processes which arebeing performed, Interaction and Sequence diagrams to show the detailed processing, Classand State diagrams to indicate the information classes and their behaviour. The HL7 RIMprovides the core Information Model for the process.



The HDF describes the processes deemed necessary in order to develop the specification formessages to completion. However, it does not describe how to verify the need for, qualityassure, prototype or implement a message.

The major stages of the method are shown in Figure 12.

Figure 12: The basic development process for HL7 Version 3

3.4 The Reference Information Model (RIM)

3.4.1 IntroductionThe Reference Information Model (RIM) is the cornerstone of the HL7 Version 3 developmentprocess. An object model created as part of the Version 3 methodology, the RIM is a largepictorial representation of the clinical data (domains) and identifies the life cycle of events that amessage or groups of related messages will carry. It is a shared model between all the domainsand as such is the model from which all domains create their messages. The RIM provides anexplicit representation of the semantic and lexical connections that exist between the informationcarried in the fields of HL7 messages. The RIM exists to support the development of messages.

The HL7 RIM Version 3 still contains a number of open issues, including the definition of classesand their attributes, the recognition that some classes and attributes will need to be removedand their functionality incorporated into other classes in order to harmonise with the USAMmodel.

Figure 13: The core classes of the RIM.Figure 13 shows the simplest model of the core classes for the RIM. This simplicity is achievedby using the so-called Unified Service Action Model (USAM), which is dealt with in the nextsubsection. This enables complex clinical concepts that would otherwise be parts of the RIM tobe streamlined by collapsing knowledge and information representation into one model (albeitmore detailed than Figure 13); then differentiating context by introduction of the "mood".



3.4.2 The Unified Action Service Model (USAM)The Unified Action Service Model (USAM) represents one of the most complex parts of the RIM,dealing with clinical functions. Not only does it simplify this area, but it is better able toaccommodate new messaging requirements.

The notion of "mood" is key to the model. Services are distinguished on the value of themood_cd attribute (e.g. possible, actual, intended, expected, etc.), thus enabling the RIMclasses to be "reused" in different contexts.

3.5 EncodingThe initial release of Version 3 will use only XML encoding. The first of the suite of documentsto comprise Version 3 - the Version 3 Abstract Data Types and its accompanying XMLImplementation Technology Specification - passed the Committee Level Ballot in September2000.

3.6 UK involvement in developmentThere has always been some UK involvement in HL7 developments - mostly from a fewinterested and motivated individuals.

The level of UK involvement became more significant and co-ordinated in 1999, deriving chieflyfrom the completion by a number of individuals of the CEN ENV13606 series of standards forthe Electronic Health Care Record. It was apparent as this work came to a conclusion that therewas probably not going to be sufficient European commercial backing for this rigorous set ofstandards and that the HL7 community provided the main focus for commercial interest (largelybecause of the larger market it addresses).

The key choice was therefore whether effectively to abandon the ENV13606 standards, or totake the valuable insights that their production had enabled and to use that knowledge in HL7Version 3. A number of the leading workers in the CEN EHCR effort decided that they couldmake a significant contribution to the HL7 work - and have been doing so very effectively in awide variety of Technical Committees and Special Interest Groups.

4 Other aspects of HL7

4.1 IntroductionWe noted in the introductory part of this chapter that HL7 is known chiefly for its Version 2standard, but increasingly for its work on Version 3. Associated with these "mainstream" effortshowever, are a number of other areas of endeavour. These are addressed briefly in thefollowing sections.

4.2 Arden SyntaxStrictly known as "The Arden Syntax for Medical Logic Systems", the latest Version 2.0 wasapproved as an ANSI Standard in July 1999.

Developed by HL7's Arden Syntax and Clinical Decision Support technical committee, thisstandard is a language for representing and sharing medical knowledge among personnel,information systems and institutions. It is designed for organisations that require or developsystems that automatically assist clinicians in decisions and alerts. The logic for making thesedecisions or issuing these alerts is encoded into health knowledge bases called MLM, each ofwhich contains sufficient knowledge to make a single decision. Contradiction alerts,management suggestions, data interpretations, treatment, protocols, and diagnosis scores areexamples of the health knowledge bases than can represented using the Arden Syntax.

This specification covers the sharing of computerised health knowledge bases in topic areassuch as those mentioned below, among personnel, information systems, and institutions. Thescope has been limited to those knowledge bases that can be represented as a set of discretemodules. Each module, referred to as a Medical Logic Module (MLM), contains sufficientknowledge to make a single decision. Contraindication alerts, management suggestions, datainterpretations, treatment protocols, and diagnosis scores are examples of the health knowledgethat can be represented using MLMs. Each MLM also contains management information to helpmaintain a knowledge base of MLMs and links to other sources of knowledge. Health personnel



can create MLMs directly according to this specification and the resulting MLMs can be useddirectly by an information system that conforms to this specification.

Although well established in some areas in the USA, this specification is widely thought to berather too simple to meet the demands of such applications as drug prescribing in the context offull electronic healthcare. The technical committee structure has recently been changed andfuture clinical decision support work is likely to result in some modernisation of the wholeapproach; meanwhile the Arden Syntax maintenance work is being carried on by a SIG withinthe Clinical Decision Support TC.

4.3 The Clinical Context Management Specification (CCOW)

4.3.1 IntroductionThe Clinical Context Object Workgroup TC (CCOW) publishes standards for the visualintegration of cooperative interaction among independently authored healthcare applications atthe point of use. The term visual integration is intended to emphasise the specific scope theworkgroup chose to address: applications with graphical user interfaces operating together on apersonal computer or workstation.

The standard supports the synchronisation and sharing of information between applications.When the user of an application changes the selected patient, the other applications on theworkstation follow the change. The cooperation frees the user from the tedium of repeating theaction (such as entering the same patient ID) in more than one application.

The CCOW standard is based on software component technologies that define a very tightinterface contract. The applications developers add code to their system to meet the specificrequirements of the interface and accept the responsibility to maintain that code throughsubsequent software releases. Consequently, CCOW-based integration should be more robustin the face of different user input and software updates.

Despite the advantages of the CCOW approach, it does not eliminate the need for ad hocintegration tools. The majority of legacy systems are based on character-cell technology. Thoseare not addressed in the CCOW standard. In fact, the best solution for environments that includecharacter-cell and GUI applications would be to use the ad hoc integration tool working inconjunction with the CCOW standard.

Since its inception as an HL7 Technical Committee, CCOW has focused on specifying theContext Management Standard. The context is primarily comprised of the identity of real-worldthings, such as patients, and real-world concepts, such as encounters, that establish thecommon basis for a consistent set of user interactions with a set of healthcare applications. Theelements of the context may be provided directly by users as they interact with applications, ormay be provided automatically by underlying programmatic sources.

Context management entails the co-ordination and synchronisation of applications so that theyare mutually aware of the set of common things - known as the context - that frame andconstrain the user's interactions with applications.

Specifically, the Context Management Standard defines a protocol for securely "linking"applications so that they "tune" to the same context. The context is represented as a set ofsubjects, each of which generally identifies a real-world entity such as a patient or a real-worldconcept such as an encounter. Linked applications remain automatically synchronised evenwhen a context subject changes, for example, due to the user's inputs (e.g., the user selects adifferent patient). The user inputs of particular interest are those that are used to identifysomething, such as medical record number for patients, or an account number for a clinicalencounter.

4.3.2 The Clinical Context Management Specification (CCOW) Version 1.3The latest balloted version of CCOW is Version 1.2. The structure of the forthcoming Version1.3 and its content is outlined below:

Context Management ("CCOW") Specification Technology- and Subject-IndependentComponent Architecture-Specifies the HL7Context Management Architecture (CMA). This architecture enables multipleapplications to be automatically co-ordinated and synchronised in clinically meaningful ways atthe point-of-use. The architecture specified in this document establishes the basis for bringinginteroperability among healthcare applications to the point-of-use, such as the clinical desktop



Context Management ("CCOW") Specification Subject Data Definitions-Provides a specification of the standard context data items that are supported for all subjects inthe HL7 Context Management Architecture (CMA) as well as custom subjects and items that arenot defined explicitly in this version of the CMA.

Context Management ("CCOW") Specification User Interface: Microsoft Windows andWeb Browser- Specifies the user interface requirements and guidelines for Microsoft Windows -based and webbrowser-based applications that are compliant with the HL7 Context Management Specification,Technology- And Subject- Independent Component Architecture.

Context Management ("CCOW") Specification Component Technology Mapping: ActiveX-Specifies the details needed to develop Microsoft ActiveX implementations of applications andcomponents that conform to the HL7 Context Management Architecture (CMA).

Health Level-Seven Standard Context Management ("CCOW") Specification ComponentTechnology Mapping: Web-Specifies the details needed to develop web implementations of applications and componentsthat conform to the HL7 Context Management Specification, Technology- And Subject-Independent Component Architecture.

4.4 Clinical Document Architecture (CDA)

4.4.1 IntroductionThe CDA, which was until recently known as the Patient Record Architecture (PRA), provides anexchange model for clinical documents (such as discharge summaries and progress notes) andclaims to bring the healthcare industry closer to the realisation of an electronic medical record.

A CDA document is defined as a persistent information object that can exist outside of amessaging context and/or can be a payload within an HL7 message. The scope of the CDA TCis the standardisation of clinical documents (legally authenticated, persistent entries into thepatient record) for exchange. The clinical content of CDA documents is defined in the RIM.

Out of scope are:

• non-clinical documents, although these may be covered in later HL7 work,

• pre-authenticated documents,

• birth-to-death patient record (although this can be constructed from CDA entries),

• standard extractions (although such views can be based on the CDA) and

• communication between applications

By making use of XML, the HL7 Reference Information Model (RIM) and coded vocabularies,the CDA makes documents both machine-readable and human-readable. CDA documents canbe displayed using XML-aware Web browsers or wireless applications such as cell phones.

The Clinical Document Architecture (Level 1) was approved as an ANSI Standard in November2000.

4.4.2 CDA LevelsThe Clinical Document Architecture has three levels, where each level is derived from a morebasic level, representing increasing levels of granularity of markup but in which the clinicalcontent remains constant, regardless of the extent of added markup. Levels are distinguishedby the degree of markup granularity and the degree to which conformant documents use RIM-derived markup.

"CDA Level One" is the root of the hierarchy and is the most general document specification.Level One CDA documents specify RIM semantics only in the CDA Header.

Specialisations of the CDA Level One DTD will form the hierarchy of document specificationscomprising the architecture.

“CDA Level Two" will be a specialisation of CDA Level One. Level Two CDA documents willspecify RIM semantics in the CDA Header and in the structural components (sections andnested sub-sections) of the document body.



“CDA Level Three" will be a specialisation of CDA Level Two. Level Three CDA documents willspecify RIM semantics for the complete contents of the document.

4.5 Security solutionsThe scope of the HL7 Security SIG is network and Internet security of HL7 transactions at theapplication level independent of underlying transport. Within this scope the SIG seeks toidentify: user requirements; the services needed to meet those requirements; the mechanismsfor providing those services; and specific implementations for those mechanisms. It will thenseek to identify related work in other Standards Developing Organizations as well as PubliclyAvailable Specifications (PAS) and will report to HL7 on available options and recommendactions that the organization may take to address those needs.

It would therefore seem that, given the existence of BS 7799, this new SIG would have little tooffer NHS practice in the foreseeable future.

4.6 VocabularyIn information management a vocabulary is designed to enable a shared, well defined, andunambiguous knowledge of the meaning of the data transferred. This is important when suchinformation may otherwise be represented in ways unintelligible to other systems, particularly ifthe systems are produced by a different vendor or in a different country. In many areas ofhealthcare informatics a vocabulary is represented in coded terms, this has the benefit of beingshorter to communicate and, sometimes, language independent; although it does require thecommunicating systems to be able to interpret the codes correctly.

The objective of the HL7 Vocabulary TC is to identify, organise and maintain coded vocabularyterms used in HL7 messages. It does this by providing an organisation and repository formaintaining a coded vocabulary that, for use in conjunction with HL7 and related standards.

There are at least five types of coded domains referenced by the HL7 standard:

• Domains whose content is entirely controlled by HL7 committees. This category includestables that enumerate trigger events, message types, segment identifiers, format types,event types, etc.

• Domains where HL7 committees have included incomplete lists of terms or "starter sets" fora given domain. This category includes tables that enumerate sex, marital status, race,ethnicity, order priorities, etc.

• Domains that have a specific use, but no data elements are defined, and it is assumed thatthe coded values used would come from one or more available coding systems such asSNOMED, ICD-10, LOINC, "Read", etc.

• Domains that fill the value field in an OBX message for a specific Observation ID. It isassumed that the coded terms used would come from one or more available coding systems.

• Domains that are referenced in the HL7 standard, but for which the structure and contents ofthe tables is assumed to be locally defined. This category includes, user identifiers, codesthat represent clinics or facilities, and identifiers for nursing divisions, rooms, beds, etc.

Although not principally concerned with producing codes and nomenclature systems, HL7 iscommonly associated with the LOINC Database, the purpose of which is to facilitate theexchange and pooling of results, such as blood haemoglobin, serum potassium, or vital signs,for clinical care, outcomes management, and research.

With the moves towards production of structured documents in HL7, the LOINC approach toterminology is being adapted/adopted to describe the components of these documents.Whether this will prove satisfactory is as yet unclear.

In parallel with this extension of LOINC, HL7 has recently established a register of "recognised"coding and nomenclature schemes, perhaps a tacit recognition that LOINC cannot fulfil allrequirements?



5 XML

5.1 IntroductionHL7 has been actively working with XML technology since the formation of the SGML/XMLSpecial Interest Group within HL7 in September of 1996. Since that time, the SGML/XML grouphas evolved into two separate groups:

• the XML Special Interest Group - which supports the HL7 mission through recommendationson use of Extensible Markup Language (XML) standards for all of HL7's platform- andvendor-independent healthcare specifications.

• the Structured Documents Technical Committee - which support the HL7 mission throughdevelopment of structured document standards for healthcare.

Both of these groups have produced work items that have been ratified by the HL7 membership.In 1999, HL7 endorsed a recommendation for using XML as an alternative syntax for HL7 v2.3.1messages. This recommendation was informative in nature (not required for compliance) andwas thus not submitted to ANSI for approval.

In September 2000, the HL7 membership ratified Version 1 of the Clinical DocumentArchitecture, which defines an XML architecture for exchange of clinical documents. Theencoding is based on XML DTDs included in the specification and its semantics are definedusing the HL7 RIM (Reference Information Model) and HL7 registered coded vocabularies. Thisis a normative document that will be submitted to ANSI for approval.

HL7 actively participates in and supports the W3C, the organisation responsible for thedevelopment of XML.


5.2.1 Encoding RulesHL7 has produced recommended XML encoding rules for HL7 Version 2.3.1 messages thatcould be used in environments where senders and receivers both understand XML. It is not theintent of the recommendation to replace the standard encoding rules, but to supplement them.

Many XML encodings could serve as alternative messaging syntaxes for HL7 Version 2.3.1;resulting, however, in different messages. Most of these would probably work and there arecertainly a number in, presumably successful, commercial use. The advantage for all parties inusing the official one is the same as for using other aspects of HL7 or any other standard; it willenable inter-working to be achieved more easily.

The Recommendation specifies one such encoding of HL7 Version 2.3.1 messages in XMLusing an algorithm that translates normative diagrams and tables within the HL7 Standard to anXML Document Type Definition (DTD).

The Recommendation also addresses the translation between standard encoded and XMLencoded HL7 Version 2.3.1 messages.

Based on experience to date, XML shows promise as an interchange format for HL7 messages.Findings have shown that XML can serve as an implementable message specification for HL7Version 2.3.1 messages and that the ability to explicitly represent an HL7 requirement in XMLconfers the ability to validate that requirement with an XML parser.

The XML representation presented here represents HL7 message structures as XML elements.Message structures contain segments, also represented as XML elements. Segments containfields, again represented as XML elements. A field's data type is stored as a fixed attribute inthe field's attribute list, while a field's content model contains the data type components. Otherfixed attributes are used to expand abbreviations and indicate HL7 Table value restrictions.



5.2.2 Example MessageHere we see a simple message in the syntax of the standard encoding rules.

MSH|^~\&|LAB^foo^bar|767543|ADT|767543|19900314130405||ACK^|XX3657|P|2.3.1<CR>

MSA|AA|ZZ9380<CR>

Figure 14: HL7 v2 message in Standard Encoding Rules syntaxIn Figure 15 we see the same message in the syntax of the recommended XML encoding rules.

<!DOCTYPE ACK SYSTEM "hl7_v231.dtd">

<ACK>

<MSH>

<MSH.1>|</MSH.1>

<MSH.2>^~\&</MSH.2>

<MSH.3>

<HD.1>LAB</HD.1>

<HD.2>foo</HD.2>

<HD.3>bar</HD.3>

</MSH.3>

<MSH.4><HD.1>767543</HD.1></MSH.4>

<MSH.5><HD.1>ADT</HD.1></MSH.5>

<MSH.6><HD.1>767543</HD.1></MSH.6>

<MSH.7>19900314130405</MSH.7>

<MSH.9><CM_MSG_TYPE.1>ACK</CM_MSG_TYPE.1></MSH.9>

<MSH.10>XX3657</MSH.10>

<MSH.11><PT.1>P</PT.1></MSH.11>

<MSH.12><VID.1>2.3.1</VID.1></MSH.12>

</MSH>

<MSA>

<MSA.1>AA</MSA.1>

<MSA.2>ZZ9380</MSA.2>

</MSA>

</ACK>

Figure 15: HL7 v2 message in Recommended XML Encoding Rules syntaxUnderlying the HL7 Standard is a normative Microsoft Access database (the "HL7 Database")that contains the official definitions of events, messages, segments, fields, data types, data typecomponents, tables, and table values.

While developing the analytic object model for the definition of the comprehensive HL7Database, the German HL7 user group became aware that two problems are not handledsatisfactorily in the Standard:

• the relationship between message types, event types, and the structure of a message;

• the relationship between fields, data types, data type components, and tables.

The XML representation of HL7 messages presented in the recommended XML encoding isalgorithmically derived directly from the HL7 Database. Therefore ambiguities or errors in theStandard are reflected "as is" in the XML encoding. Fixing any such errors in the XML requiresmaking appropriate modifications to the HL7 Database.

An XML encoding for Version 2.4 will be balloted and submitted for approval to ANSI in 2001.



5.3 XML in Version 3The initial release of Version 3 will use only XML encoding. The first of the suite of documentsto comprise Version 3, the Version 3 Abstract Data Types and its accompanying XMLImplementation Technology Specification, passed the Committee Level Ballot in September2000.

The XML messaging syntax in the recommended XML encoding rules for HL7 Version 2.3.1messages is not the same as that which is being proposed for Version 3.0 [HL7 v3/XML]. TheVersion 3 XML project is a moving target, and consensus on XML representation has not yetbeen reached. Given the different philosophies underlying Versions 2.3.1 and 3.0, there will bedifferences.

It should be recognised that the XML representation of messages in Version 3 is a separateactivity from the building and passing of structured XML documents of the type envisaged in theClinical Document Architecture (section 4.3).

6 Strategies with HL7 in the NHS

6.1 IntroductionThe previous sections may make an interesting quick survey of the current, but ever changing,state of HL7 deliverables and endeavours. In the context of the timely, appropriate and secureprovision of health information within and from the NHS, what implications does it have?

6.2 TimescalesVersion 2.4 of HL7 exists and is the latest, balloted and ANSI-approved, version of the mostcomprehensive heath-oriented messaging standard available anywhere worldwide. In practice,most vendors are currently shipping products that support Version 2.3 or 2.3.1. Thus it can beseen that there is a delay of at least three years before a new (but directly derivative) version ofthe standard becomes widely available from software vendors.

Version 3, while promising to overcome a number of the shortcomings of Version 2, will remainchiefly a messaging standard and will not guarantee easy backward compatibility to Version 2.xsemantics. Version 3 is not yet available - and will not be until 2002. Given the two-year delayseen with manufacturers adoption of new incremental versions of the Standards, the high costsof writing software and the uncertainty about the maturity of the Version 3 standards it seemsunlikely that Version 3 will be in widespread use by large numbers of the existing vendorcommunity before, say, 2006.

Are there significant factors that could in specific instances adapt this general situation?

The current use of HL7 is, in most places, focussed on acute healthcare in the hospital sector.With a worldwide shift to more provision of care in the home or community it is likely that newcommunication channels will need to be established to carry subtly different content for thesesectors. The greater involvement of other types of carers and the patients themselves willincrease the pressure for evolution in this direction. If these new areas do indeed open up asanticipated then vendors will have to chose which health information content communicationstandard best suits their needs. Current indications are that HL7 Version 3 would be first choice.

6.3 OptionsMost current inter-system communication in the NHS is handcrafted; but increasingly"integration engines" are providing some level of, if not exactly off-the-shelf, then less labourintensive communication.

In the acute sector, many of the more recent (last two to five years) patient index systems and alarge array of specialist functionality (Laboratory, Radiology, Clinical, Theatre, Order-Comms,Pharmacy, etc) systems have HL7 Version 2.3 capability in one or more areas.

To use this capability, possibly through the auspices of an "integration engine" will generally be agood use of existing resources - particularly if HL7-UK is able to quickly complete its HL7 vA.nStandards to reduce some of the uncertainties that exist in interpretation of the Standard. Toseek HL7 UK Implementation Guide compliant Version 2.3.1 (or newer) capability in newprocurements over the next four or five years would logically extend this approach.



For the reasons indicated at the end of the previous sub-section, some vendors active in the GPand community sector may introduce Version 3 compliant systems earlier than 2006. However,Version 3 potentially offers a lot of advantages over Version 2; therefore migration to Version 3should be considered carefully in all UK healthcare contexts.

So what about the migration problem?

In reality, the migration problem is probably largely theoretical. The US domestic market use ofHL7 in the secondary care and related reimbursement sectors is nearly universal, and there is arecognised eventual need to integrate clinical records between secondary care and theirfragmented primary care sector. Commercially, the likely scenario is that the existing"integration engine" vendors will switch emphasis from enabling non-HL7 to HLv2.xcommunication toward HL7 v2.x to HL7 v3 integration as the latter becomes widely used. Thiswill enable the creation of so-called "birth to death" cross-sector medical records. So, non-USusers of HL7 will in general gain from the large scale of use in the USA and be able to accessnear commodity technology to smooth any future connectivity and migration path.

The HL7 Context Management ("CCOW") may well, in the medium term, "enable multipleapplications to be automatically co-ordinated and synchronised in clinically meaningful ways atthe point-of-use" thus permitting users to operate as if they have access to an integratedinformation environment without full system integration being achieved. For this reason it mayprove valuable in enabling achievement of the EPR, and indeed the EHR.

6.4 HL7 versus European Health Informatics StandardsOne is not comparing like with like here, as the CEN Technical Committee for Health Informatics(CEN/TC251) originally set itself a more ambitious goal in tackling all application related aspectsof healthcare information systems. Nevertheless, it is likely that the growth in use of HL7 inEurope will reduce the use of some CEN Health Informatics Standards.

Particularly at risk are the messaging and healthcare records standards produced byCEN/TC251. This is not a reflection of their ability to address the problems well, but rather of theeffects of under-resourcing the production process at critical times. Simply put, the existing CENStandards are excellent patchwork squares in an incomplete (and indeed fragmentary) piece ofwork. HL7 will win out because of its more comprehensive coverage and wider commercialsupport.

As indicated in an earlier section, much can be (and is being) learned form the CEN work withinthe HL7 community. Lessons from many areas of CEN will be absorbed into the evolvingprovisions of Version 3.

6.5 HL7 v EDIFACTIn many respects, at the syntax level, EDIFACT is similar to HL7 Version 2.x; - it is rather old-fashioned; but can, and does, still deliver what is required in day-to-day use.

HL7 message content is at the same level as the National Standard Messages (NSMs). Thereare only 39 NSMs, hardly any of them are used and few are clinical. This comparesunfavourably with the scope of the HL7 messages; where, for example, in the area of PatientAdministration alone there are in excess of 50 defined Trigger Events, 10 Messages Segmentswith an average of 20 Elements in each. Multiplied to reflect the other 11 HL7 v2.4 chapters withsignificant relevant message content, this provides unequalled coverage - particularly for acutecare and administrative functions.

Outside its mandated use for results reporting to GPs is there a case for extending the use ofNSMs using EDIFACT in preference to HL7v2, possibly using XML?

The answer looks to be simple: probably not. The user base for EDIFACT is not growing inhealthcare generally, while that for HL7 is growing. Likewise vendor support is diminishing infavour of HL7. However, for purely messaging purposes co-existence and inter-communicationbetween the standards can continue, as now, to be handled by "integration engines". Further,the use of XML as a syntax for either type of message renders both NSMs and HL7 v2Messages amenable to integration into "web" application environments.



6.6 Relationship to eGIFReference was made in Section 1.7 to the eGIF requirement for native support of XML. As wehave seen (Section 5.2) there already exists, albeit with some theoretically problematic areas, anXML encoding of HL7 Version 2.3.1.

We have also noted (Section 5.3) that Version 3 will at least initially use XML exclusively.

The migration difficulty, highlighted in Section 1.8, is that given the different philosophiesunderlying v2.x and v3.0, we can expect differences in messaging syntax. It is not thereforeclear to what extent the use of XML implementations of v2 as a migration strategy is useful -except in so far as it might teach familiarity with XML. For this reason careful local examinationof the issues is recommended before conversion to wholesale XML encoding of Version 2messages is adopted.

However, as the applications deployed in the NHS move inexorably toward browser-basedplatforms, there are likely to be significant technical advantages to the adoption of (HL7 v2.x)XML messages for local and national purposes. This is the rationale for the mandating of XMLoutside healthcare - and there is nothing to justify the conclusion the healthcare can go againstthe technical flow. In this context addressing the migration "problem" may well be somethingthat should be postponed, secure in the knowledge that there will be sufficient demand tosupport a market for conversion products.

In order to support the general "joining things up" philosophy of eGIF, HL7 recommendations forXML encoding should be followed.

7 ConclusionsHL7 will retain, or even increase, its significance in healthcare system communication, chieflybecause of the continuing high level of activity and commitment of its commercial contributorsand because of the many years of experience represented by the various HL7 working groups.In that context the development of Version 3 will, in time (soonest in document communicationand non-acute care), introduce a new level of quality to the HL7 communication standard.However, for much of the acute care sector the existing availability of HL7 Version 2.x offers a"quick-win" - particularly if deployed in accordance with emerging UK implementation guidelines.

The development of XML is solidly integrated in HL7, which is working not only on specifications,but also on the development and testing of tools for the automatic conversion of HL7 informationinto the XML format and vice versa. Nevertheless, the transition between HL7 Version 2 DTDbased XML and the eventual Version 3 XML syntax may not be straightforward and will need tobe approached with care. However, this should not be used as an excuse for doing nothing.The standardisation of uniform documentation description and exchange formats by means ofXML is of great importance and the emphasis placed on it both inside and outside HL7 cancontribute to harmonisation of the various communication standards. With this, thecommunication and co-operation between the diverse structures of government and healthcarecan become a reality to the benefit of patients.



Annex A GlossaryACK Acknowledgement messagesADT Commonly used abbreviation for Admission, Discharge, TransferAL1 Allergy Information segmentANSI American National Standards InstituteCCOW Clinical Context Object WorkgroupCDA Clinical Document ArchitectureCEN Comité Européen de Normalisation (European Standards Committee)CEN/TC251 Comité Européen de Normalisation (European Standards Committee) Technical

Committee on Health informaticsCoded Value Coded vocabulary item that is a member of a coded domain; corresponds to a table entry

in HL7 tablesData element Any data field, component, or subcomponent of HL7.Domain Set of all appropriate values for a data element;

for a coded data element, the coded domain is the set of all coded vocabulary items thatare appropriate values of the coded data element

DTD Document Type Definition, used in SGML to define the structure of a class of documentsEVN Event Description segmentHIS Commonly used abbreviation for Hospital Information SystemHL7 Abbreviation of “Health Level Seven, Inc.”; refers to the top, application and seventh, level

of the ISO OSI communications model.HDF HL7 Message Development FrameworkISO International Standards OrganisationISO/TC215 International Standards Organisation Technical Committee on Health InformaticsMDF In a formal standardisation context: Message Development FrameworkMSH Message HeaderNSM National Standard MessageOBR Observation Request segmentORU Observation Results segmentOSI Open Systems InterconnectionPAS Commonly used abbreviation for Patient Administration SystemPAS In a formal standardisation context: Publicly Available SpecificationPID Patient Identification segmentPRA Patient Record Architecture (now Clinical document architecture (CDA))PV1 and PV2 Patient Visit Information segmentsRIM Reference Information ModelSDO In a formal standardisation context: Standards Developing OrganisationSIG Special Interest GroupTC In a formal standardisation context: Technical CommitteeTQ Timing Quantity data type to better manage order occurrence changesUSAM Unified Service Action ModelWG In a formal standardisation context: Working GroupZ segment Special message segment reserved for locale-specific messages.

HL7-UK specific messages defined in Standard for implementing HL7 v2 in the UK aredesignated ZUn



Annex B ContactsCEN/TC251 Web pages

www.centc251.org

UK Government Interoperability Frameworkwww.e-envoy.gov.uk

HL7-Germany Web pageswww.hl7.org.de

HL7 CCOW TC Web pageshttp://www.hl7.org/special/Committees/ccow_sigvi.htm

HL7 CDA TC Web pageshttp://www.hl7.org/special/Committees/structure/struc.htm

HL7 Security SIG Web pageshttp://www.hl7.org/library/committees/Secure/HL7_Sec.html

HL7 Vocabulary TC Web pageshttp://www.hl7.org/special/Committees/Vocab/vocab.htm

HL7 USA central Web pageswww.hl7.org

HL7-UK Web pageswww.hl7.org.uk

ISO/TC215 Web pageswww.astm.org/cgi-bin/SoftCart.exe/COMMIT/ISO/tc215

LOINC Web pageswww.regenstrief.org

HL7 v2.3.1 XML recommendationswww.hl7.org/Special/Committees/sgml/hl7v231xml.pdf

XML.org Web pageswww.xml.org

Extensible Markup Language (XML) 1.0. W3C Recommendation 10-February-1998.www.w3.org/TR/1998/REC-xml-19980210.html

http://www.centc251.org/

http://www.e-envoy.gov.uk/

http://www.hl7.org/special/Committees/ccow_sigvi.htm

http://www.hl7.org/special/Committees/structure/struc.htm

http://www.hl7.org/library/committees/Secure/HL7_Sec.html

http://www.hl7.org/special/Committees/Vocab/vocab.htm

http://www.hl7.org/

http://www.hl7.org.uk/

http://www.astm.org/cgi-bin/SoftCart.exe/COMMIT/ISO/tc215

http://www.regenstrief.org/

http://www.hl7.org/Special/Committees/sgml/hl7v231xml.pdf

http://www.xml.org/

http://www.w3.org/TR/1998/REC-xml-19980210.html



Annex C Bibliography

1 HL7 - Communication standard in medicine. K. U. Heitmann, B. Blobel and J. Dudeck. 1stEdition (English version), 1999, Verlag Alexander Mönch. ISBN 3-933819-06-7