---

Summary

1. Introduction

Quite often those that already know HL7 version 2 (HL7v2) are baffled by the size of the HL7 version 3 (HL7v3) publication and its focus on modeling. Instead of looking at the formal HL7 version 3 modeling methodology we can also focus on the commonalities in the approach on how the wire formats are constructed. Especially when it comes to HL7v2 implementers look at a couple of examples, read some snippets of documentation, and subsequently one sort of understands how the standard works. In principle the same is true for HL7v3.

Characteristics of HL7 version 2

This section describes some of the core characteristics of HL7v2. Yes, we do assume you are aware of HL7v2, but still it�s useful to highlight some of its characteristics before we look at HL7v3.

A simple HL7v2 partial message example is shown below; a 182 mg/dl Glucose value was observed for Eve Everywoman:

PID|||555-44-4444||EVERYWOMAN^EVE^E^^^^L|JONES|19620320|F||||||||||AC555444444||
OBX|1|NM|1554-5^GLUCOSE:POST 12H CFST:MCNC:PT:SER/PLAS:QN||182|mg/dl|70-105|H|||F

Core characteristics of HL7v2 include:

• The core elements of reusability in the standard are a) data types and b) segments and to a certain degree c) segment groups (e.g. �OBR {OBX}� or �PID [PD1] {[NK1]}�).The syntax used is an EDI syntax � the industry standard at the time of creation of HL7v2 in 1987.
• It supports the exchange of EDI-style �messaging�.
• The standard was created in order to mainly support the administrative, logistical and financial processes within hospitals. It has the capacity to support the exchange of medical data of relatively low complexity (e.g. lab result, textual radiology report).

Characteristics of HL7 version 3

This section examines some of the core characteristics of HL7v3.

A simple HL7v3 partial message example is shown below; a 182 mg/dl Glucose value was observed for Eve Everywoman:
Part 1: Patient CMET

<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>

Part 2: 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"/>
   <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>
</observationEvent>

Core characteristics of HL7v3 include:

• The core elements of reusability in the standard are a) data types and b) Common Message Element Types (CMETs).
  • CMETs are the HL7v3 equivalent of a segment or segment group; example CMETs are Patient (which includes next of kin), Provider and Coverage (i.e. insurance).
• The syntax used is XML � the industry standard at the time of creation of HL7 version 3 in 1995. This, by its very nature, leads to more human readable, but also more bloated messages.
• Everything is a model � Model Driven Engineering (MDE) methods are used to derive XML Schema; the models can also be used for class/code generation.
• It supports the exchange of EDI-style �messaging�, services as well as an e-Document approach (Clinical Document Architecture, CDA).
• The standard was created in order to support all healthcare workflows, including (but not limited to) the exchange of data between organizations. It has the capacity to support the exchange of medical data of high complexity (e.g. for decision support, EHRs, clinical research).
  • When one exchanges data between organizations there is less in terms of shared context. The lower the shared context, the more context one has to include in the data which is exchanged. As such HL7 version 3 is richer in content than HL7 version 2.

HL7 v2 / HL7 v3: a structural comparison

The core structure of HL7v2/HL7v3 messages is based on reusable building blocks: segment / segment groups in HL7v2, and CMETs in HL7 v3.

In HL7v3 models one activity is defined as being the core one � this part of the message structure is not a CMET. Whereas an ORU^R01 has a �PID PV1 {OBR {OBX}}� structure, the HL7v3 message would be something like �{OBX} OBR PID PV1�, placing the core activity at the heart of the message structure.

Given that HL7v3 is designed to also capture complex clinical data that can�t be properly expressed in HL7v2, the v3 message structure also allows for relationships between activities (shown as a loop in the figure above).

Example: suppose we wish to convey �Eve Everywoman underwent emergency surgery and was given medications X and Y after having been diagnosed with a rupture of the lungs which was determined using an ultrasound scan.� One simply can�t express the various relationships (e.g. temporal, causal) between the various medical activities in HL7v2. HL7v3 (in HL7v2 terms) has the ability to express all of those relationships, effectively creating a graph consisting of segments. One doesn�t use those when sending a simple admit message, but of one sends a referral then one may need this capability of HL7v3.

HL7v2 messages contain a message header, consisting not just of the MSH segment but effectively the group of segments �MSH [SFT] [EVN] [MSA] {[ERR]}�. HL7v3 messages have two layers of wrappers: an outermost Transmission Wrapper (the equivalent of MSH [SFT] [MSA] {[ERR]}, where ERR is limited to errors related to the Accept Acknowledgement), and a Trigger Event ControlAct Wrapper (the equivalent of EVN {[ERR]}, where ERR is limited to errors related to the Application Acknowledgement).

HL7v3 uses a set of data types that basically consist of improved versions of the HL7v2 data types. With close to 25 years of experience on how HL7v2 data types are implemented, and (in hindsight) the errors that have been made in defining them, a much-improved set of data types has been defined.

Example: the CE data type is build around three key components: �code^description^ID of coding system�. None of these components is mandatory, which leads to a lot of problems: �^Glucose� is a valid instance of this data type, as is �1554-5^Glucose�. Especially in a context where one cannot assume that the receiver is aware of the coding system used by the sender one has to identify the coding system that has been used. For this reason the corresponding HL7v3 data type has two mandatory components: sending applications SHALL value both the �code� as well as the �ID of coding system� components.

HL7v3 is fully model driven, and all models are derived (in an object oriented fashion) from one relatively abstract Reference Information Model (RIM). This model serves to promote consistency between the various messages. In HL7v2 terms it is as if one has defined an abstract/generic OBS segment (generic observation) with predefined specializations in the form of the OBX, the NTE, the AL1 and the IAM segments. OBX in turn has been further specialized in (for example) a MOB, a microbiology oriented observation segment. The ability to derive/specialize models leads to a higher consistency and the use of properly constrained models for specific use cases. As shown by the example it also leads to a fairly high number of segments, the definition of which, and the derivation context of which, one has to be aware of as a software application.

One of the more widely implemented HL7v3 specifications is its e-Document standard known as the Clinical Document Architecture (CDA). CDA ensures human readability as well as software processability � effectively the same concepts as described in the HL7v2 MDM messages where one has the capability to sent both text (e.g. plain ASCII, or a PDF) as well as a series of OBX segments which contain the very same data for the purpose of software processability.

Summary

To a certain degree HL7v3 is a next-generation-HL7v2: it is based on reusable structures, an underlying data type definition, and it uses an industry standard as the syntax encoding method.

HL7v3 (compared to HL7v2) however has the capability to express complex medical data and is suitable for the exchange of data between organizations. This capability comes at a price: added complexity. The goals of HL7v2 were much more modest than those of HL7v3; which also renders it effectively unsuitable for use when one has a requirement to exchange complex medical data.

References

• Full transformation examples between HL7v2 and HL7v3.

---

About Ringholm bv

Ringholm 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.