HL7 Message examples: version 2 and version 3The contents of this whitepaper are published under the Creative Commons Attribution-Share Alike license. Summary
This whitepaper contains 2 use case descriptions. Each use case could be supported by either the HL7 v2.x or the HL7 v3 messaging standard. Each example use case has two example messages associated with it: a HL7 v2.x message, and its functional equivalent in v3. The whitepaper aims to show some the differences as well as similarities between example v2.x and v3 message instances.
1. IntroductionThis whitepaper has the aim to illustrate how v2 message strcutures are present in v3, and vice versa. As you're probably aware of, HL7 v3 is not backwards compatible with the v2.x standard although some of the message constructs (e.g. data types) are similar in nature. Nevertheless, all use cases supported by v2.x are supported by v3. Not that it is not the intent of this whitepaper to discuss migration issues from v2.x to v3, nor to discuss the circumstances where using v3 may be more appropriate than v2.x as a messaging standard. It merely attempts to show some of the similarities between v2.x and v3 using message examples.2. Laboratory Results use caseThis section contains an example business use case related to a laboratory results message, as well as a V2.4 and a v3 representation. The v3 message is based upon the normative XML ITS 1.0 and schema from the May 2006 Informative Edition of HL7 v3. The use case is the completion of a serum glucose laboratory result of 182 mg/dL authored by Howard H. Hippocrates. The laboratory test was ordered by Patricia Primary for patient Eve E. Everywoman. The use case takes place in the US Realm.2.1 The V2.4 MessageThe V2.4 representation of the use-case is a ORU^R01 message. The syntax encoding is based on the classic HL7 v2 syntax, commonly referred to as the vertical-bar syntax. The MSH (Message Header) segment contains the message type, in this case, ORU^R01, which identifies the message type and the trigger event. The sender is the GHH Lab in ELAB-3. The receiving application is the GHH OE system located in BLDG4. The message was sent on 2002-02-15 at 09:30. The MSH segment is the initial segment of the message structure.MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL-3456|P|2.4<cr> PID|||555-44-4444||EVERYWOMAN^EVE^E^^^^L|JONES|19620320|F|||153 FERNWOOD DR.^ ^STATESVILLE^OH^35292||(206)3345232|(206)752-121||||AC555444444||67-A4335^OH^20030520<cr> OBR|1|845439^GHH OE|1045813^GHH LAB|15545^GLUCOSE|||200202150730||||||||| 555-55-5555^PRIMARY^PATRICIA P^^^^MD^^|||||||||F||||||444-44-4444^HIPPOCRATES^HOWARD H^^^^MD<cr> OBX|1|SN|1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN||^182|mg/dl|70_105|H|||F<cr>The PID (Patient Identification) segment contains the demographic information of the patient. Eve E. Everywoman was born on 1962-03-20 and lives in Statesville OH. Her patient ID number (presumably assigned to her by the Good Health Hospital) is 555-44-4444. The OBR (Observation Request) segment identifies the observation as it was originally ordered: 15545^GLUCOSE. The observation was ordered by Particia Primary MD and performed by Howard Hippocrates MD. The OBX (Observation) segment contains the results of the observation: 182 mg/dl. 2.2 The v3 MessageThe v3 representation of the use case is a POLB_IN224200 interaction. The root element of the XML instance contains information necessary for its proper validation. The root element is POLB_IN224200. The XML ITS version 1.0 uses a single v3 namespace for all instances. All IDs use OIDs as the method of ensuring global uniqueness. The following object identifiers (OIDs, not present in the HL7 V2 message) are used within the Good Health Hospital (GHH):
2.2.1 The v3 Message - Transmission WrapperNote that the root element uniquely identifies the message�s interaction identifier, in this case, POLB_IN224200, which identifies the message type, the trigger event, and the receiver responsibilities. The receiving application is described in the receiver/device element, the sender/device element and sender/asLocatedEntity/location identify the sending application and facility. The receiver is the GHH_OE system in Bldg4. The sender is GHH_LAB at location E-LAB3. The root element wraps the payload, which is the Control Act wrapper for this message.
<POLB_IN224200 ITSVersion="XML_1.0" xmlns="urn:hl7-org:v3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<id root="2.16.840.1.113883.19.1122.7" extension="CNTRL-3456"/>
<creationTime value="200202150930-0400"/>
<!-- The version of the datatypes/RIM/vocabulary used is that of May 2006 -->
<versionCode code="2006-05"/>
<!-- interaction id= Observation Event Complete, w/o Receiver Responsibilities -->
<interactionId root="2.16.840.1.113883.1.6" extension="POLB_IN224200"/>
<processingCode code="P"/>
<processingModeCode nullFlavor="OTH"/>
<acceptAckCode code="ER"/>
<receiver typeCode="RCV">
<device classCode="DEV" determinerCode="INSTANCE">
<id extension="GHH LAB" root="2.16.840.1.113883.19.1122.1"/>
<asLocatedEntity classCode="LOCE">
<location classCode="PLC" determinerCode="INSTANCE">
<id root="2.16.840.1.113883.19.1122.2" extension="ELAB-3"/>
</location>
</asLocatedEntity>
</device>
</receiver>
<sender typeCode="SND">
<device classCode="DEV" determinerCode="INSTANCE">
<id root="2.16.840.1.113883.19.1122.1" extension="GHH OE"/>
<asLocatedEntity classCode="LOCE">
<location classCode="PLC" determinerCode="INSTANCE">
<id root="2.16.840.1.113883.19.1122.2" extension="BLDG24"/>
</location>
</asLocatedEntity>
</device>
</sender>
<! �- Trigger Event Control Act & Domain Content -- >
</POLB_IN224200>
2.2.2 The v3 Message - Trigger Event Control Act wrapperThe message control act is yet another wrapper around the actual message. It represents the trigger event POLB_TE224200. Information about the date and time the trigger event occurred, as well as the responsible parties for the trigger event is not present in this example, even though it could be conveyed as part of the wrapper. Note that the date and time of the laboratory observation as well as the author of the observation are contained in the Domain Content and not in the Control Act wrapper.
<controlActProcess classCode="CACT" moodCode="EVN">
<code code="POLB_TE224200" codeSystem="2.16.840.1.113883.1.18"/>
<subject typeCode="SUBJ" contextConductionInd="false">
<!-- domain content has been removed
see next section of this whitepaper-->
</subject>
</controlActProcess>
2.2.3 The v3 Message - Domain ContentThe "Domain Content" starts with its own root element � observationEvent. The elements within specify the type of observation, the ID, the time of the observation, statusCode, and the results. The value for the actual result is shown in the value element. The interpretationCode element shows that the value has been interpreted as high (H), while referenceRange provides the normal values for this particular observation.
<observationEvent>
<id root="2.16.840.1.113883.19.1122.4" extension="1045813"
assigningAuthorityName="GHH LAB Filler Orders"/>
<code code="1554-5" codeSystemName="LN"
codeSystem="2.16.840.1.113883.6.1"
displayName="GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN"/>
<statusCode code="completed"/>
<effectiveTime value="200202150730"/>
<priorityCode code="R"/>
<confidentialityCode code="N"
codeSystem="2.16.840.1.113883.5.25"/>
<value xsi:type="PQ" value="182" unit="mg/dL"/>
<interpretationCode code="H"/>
<referenceRange>
<interpretationRange>
<value xsi:type="IVL_PQ">
<low value="70" unit="mg/dL"/>
<high value="105" unit="mg/dL"/>
</value>
<interpretationCode code="N"/>
</interpretationRange>
</referenceRange>
The performing provider, Mr. Harold H Hippocrates, is included with his ID and name. There are two levels of information present, the practitioner level and the person level. The ID is on the practitioner level, while the name is on the person level.
<author>
<time value="200202150730"/>
<modeCode code="WRITTEN"/>
<signatureCode code="S"/>
<assignedEntity>
<id root="2.16.840.1.113883.19.1122.3" extension="444-444-4444"/>
<assignedPerson>
<name>
<given>Harold</given>
<given>H</given>
<family>Hippocrates</family>
<suffix qualifier="AC">MD</suffix>
</name>
</assignedPerson>
</assignedEntity>
</author>
The patient, Eve E. Everywoman, is also represented with two levels - the patient and the person. The available elements within the patient element are few since this is part of a closely-coupled message (e.g. the address isn�t sent). On the other hand, the id is available as well as the name, thus providing for at least some form of error checking.
<recordTarget>
<patientClinical>
<id root="2.16.840.1.113883.19.1122.5" extension="444-22-2222"
assigningAuthorityName="GHH Lab Patient IDs"/>
<statusCode code="active"/>
<patientPerson>
<name use="L">
<given>Eve</given>
<given>E</given>
<family>Everywoman</family>
</name>
<asOtherIDs>
<id extension="AC555444444" assigningAuthorityName="SSN"
root="2.16.840.1.113883.4.1"/>
</asOtherIDs>
</patientPerson>
</patientClinical>
</recordTarget>
The original order for the laboratory observation is referenced by the FLFS act relationship named inFulfillmentOf, which identifies the order by placer number. This number should be used by the receiver to match the results to the order. The available elements within the placerOrder element are few since this is part of a closely-coupled message (e.g. the details of the ordering provider aren�t sent).
<inFulfillmentOf>
<placerOrder>
<id root="2.16.840.1.113883.19.1122.14" extension="845439"
assigningAuthorityName="GHH OE Placer orders"/>
</placerOrder>
</inFulfillmentOf>
</observationEvent>
3. Mapping a v3 demographics message to v2.4This section contains an example business use case related to a demographics message, as well as a v3 and a v2.4 representation. The use case is an update of the person demographics data of Patricia Patient in the Regional MPI system. The updated information is sent, in the form of a notification, to the Master MPI. The demographics data incudes 3 different person/patient identifiers and address/telecom information.3.1 The v3 message - PRPA_IN101001UV01The v3 representation of the use-case is a PRPA_IN101001UV01 interaction. The message instance is shown below. The v3 message is based upon the normative XML ITS 1.0 and schema from the Normative Edition 2006 of HL7 v3.3.1.1 The v3 Message - Transmission WrapperNote that the root element uniquely identifies the message�s interaction identifier, in this case, PRPA_IN101001UV01, which identifies the message type, the trigger event, and the receiver responsibilities. The receiving application is described in the receiver/device element, the sender/device element and sender/asLocatedEntity/location identify the sending application and facility. The receiver is the Master MPI system in the Alpha Hospital. The sending application is the application identified in the wrapper as (root=2.16.840.1.113883.19.9, extension=1). The root element wraps the payload, which is the Control Act wrapper for this message.
<?xml version="1.0" encoding="UTF-8"?>
<PRPA_IN101001UV01 ITSVersion="XML_1.0" xmlns="urn:hl7-org:v3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<id extension="3948375" root="2.16.840.1.113883.19.10.700363.2288"/>
<creationTime value="20060501140010"/>
<versionCode code="NE2006"/>
<!-- Interaction is a notification of a person registration -->
<interactionId extension="PRPA_IN101001UV01" root="2.16.840.1.113883.1.6"/>
<processingCode code="P"/>
<processingModeCode code="T"/>
<acceptAckCode code="ER"/>
<receiver>
<device>
<id extension="922" root="2.16.840.1.113883.19.9"/>
<name>Master MPI</name>
<asAgent>
<representedOrganization>
<id extension="1002003" root="2.16.840.1.113883.19.200"/>
<name>Alpha Hospital</name>
</representedOrganization>
</asAgent>
</device>
</receiver>
<sender>
<device>
<id extension="1" root="2.16.840.1.113883.19.9"/>
</device>
</sender>
3.1.2 The v3 Message - Trigger Event Control Act wrapperThe message control act is yet another wrapper around the actual message. It represents the trigger event PRPA_TE101001UV01. Information about the date and time the trigger event occurred, as well as the responsible parties for the trigger event is not present in this example, even though it could be conveyed as part of the wrapper.
<controlActProcess moodCode="EVN">
<code code="PRPA_TE101001UV01" codeSystem="2.16.840.1.113883.1.18"/>
<effectiveTime value="20060501140008"/>
<authorOrPerformer typeCode="AUT">
<assignedPerson>
<id extension="000338475" root="2.16.840.1.113883.19.201"/>
<assignedPerson>
<name use="L">
<given>Arthur</given>
<family>Author</family>
</name>
</assignedPerson>
<representedOrganization>
<id extension="1002777" root="2.16.840.1.113883.19.200"/>
<name>Regional Person Registry</name>
</representedOrganization>
</assignedPerson>
</authorOrPerformer>
<subject>
<!-- registration event has been removed
see next section of this whitepaper-->
</subject>
</controlActProcess>
</PRPA_IN101001UV01>
3.1.3 The v3 Message - Registration EventThe registrationEvent represents the registration activity of a person record. It contains information about who registered the data in the MPI, when the record was registered and the custodian of the registration.
<registrationEvent moodCode="EVN">
<id extension="393736355" root="2.16.840.1.113883.19.200.51"/>
<statusCode code="active"/>
<effectiveTime nullFlavor="UNK"/>
<subject1>
<!-- domain content has been removed
see next section of this whitepaper-->
</subject1>
<author>
<assignedEntity>
<id extension="000338475" root="2.16.840.1.113883.19.201"/>
<assignedPerson>
<name use="L">
<given>Arthur</given>
<family>Author</family>
</name>
</assignedPerson>
</assignedEntity>
</author>
<custodian>
<assignedEntity>
<!-- The custodian for the registered data, here the same as the scoper -->
<id extension="1002777" root="2.16.840.1.113883.19.200"/>
</assignedEntity>
</custodian>
</registrationEvent>
3.1.4 The v3 Message - Domain ContentThe "Domain Content" starts with its own root element � identifiedPerson. The elements within specify the identifiedPerson role, the Person (entity) that plays the role. Note that the primary ID of the Person is 000197245, and that this same person has secundary IDs 4532 and 3242346.
<identifiedPerson>
<!-- Primary ID as used/known by this registry -->
<id extension="000197245" root="2.16.840.1.113883.19.3"/>
<addr use="H">
<streetName>Randomroad</streetName>
<houseNumber>25a</houseNumber>
<postalCode>1200</postalCode>
<city>Anytown</city>
</addr>
<telecom use="H" value="tel:555 3542557"/>
<telecom use="H" value="fax:555 3542558"/>
<telecom use="WP" value="tel:555 5557865"/>
<statusCode code="active"/>
<identifiedPerson>
<name use="L">
<given>Patricia</given>
<family>Patient</family>
</name>
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>
<birthTime value="19750103"/>
<maritalStatusCode code="F" codeSystem="2.16.840.1.113883.5.2"/>
<!-- Secundary IDs of same person in other Roles -->
<asOtherIDs>
<id extension="4532" root="2.16.840.1.113883.19.2.400566"
assigningAuthorityName="Careful Care Clinic"/>
</asOtherIDs>
<asOtherIDs>
<id extension="3242346" root="2.16.840.1.113883.19.2.450998"
assigningAuthorityName="Dr.Goodman GP Practice"/>
</asOtherIDs>
</identifiedPerson>
<assigningOrganization>
<!-- Scoper, the registering organisation -->
<id extension="1002777" root="2.16.840.1.113883.19.200"/>
<contactParty nullFlavor="UNK"/>
</assigningOrganization>
</identifiedPerson>
3.2 The v2 message: MSH SegmentThe v2 representation of the use case is a ADT^A28 message. The v2 delimited syntax encoding is used. The following Namespace identifiers (strings, not present in the HL7 v3 message) are used within the message:
MSH|^~\&|Regional MPI||Master MPI|Alpha Hospital|20060501140010||ADT^A28|3948375|P^T|2.4|||ER<cr> EVN|A28|20060501140008|||000338475^Author^Arthur^^^^^ ^Regional MPI&2.16.840.1.113883.19.201&ISO^L|20060501140008<cr> PID|||000197245^^^NationalPN&2.16.840.1.113883.19.3&ISO^PN~4532^^ ^CarefulCareClinic&2.16.840.1.113883.19.2.400566&ISO^PI~3242346^^ ^GoodmanGP&2.16.840.1.113883.19.2.450998&ISO^PI||Patient^Particia^^^^^L||19750103|F|| |Randomroad 23a&Randomroad&23a^^Anytown^^1200^^H|| 555 3542557^ORN^PH~555 3542558^ORN^FX|555 5557865^WPN^PH<cr> PV1||N|<cr>The EVN (Event, i.e. Trigger Event) segment contains the timing of the trigger event (2006-05-01 at 14:00:08) and an identification of the person that caused the trigger event to happen (Arthur Author). The PID (Patient ID) segment contains the identifiers (3 identifiers, 1 person identifier and 2 patient identifiers) of patient Patricia Patient as well as other demographics data (e.g. address, 2 telephone numbers and a fax number, birthdate). The PV1 (Patient Visit) segment (a mandatory segment in the ADT^A28 message) contains information about an encounter between a healthcare provider and the patient. Given the use case no data is conveyed, the N denotes that the segment isn't applicable. 4. Additional examplesSee www.ringholm.com/download/NE2006_examples.zip for additional v3 examples.
About Ringholm bvRingholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards. |
