In the first chapter you were introduced to the HL7 standards. You were also introduced to the following:

• HL7 Version 2.x Message Structure
• Segments
• The MSH Segment

In this chapter, you will be concentrating on the message encoding for HL7 Version 2.x. Let’s start off by looking at the HL7 V2.x message and the encoding types.

The HL7 Message

An HL7 message is used to transfer patient information from one system to another healthcare system. There are various types of HL7 messages defined to carry different types of patient information; for example, the ADT message type is used for patient’s patient administration information. The HL7 message structure defined by HL7 organization is also referred to as HL7 message encoding, which we will talk about in this chapter.

Message Encoding Types

Message encoding types describe how an HL7 message is formatted to carry information from one system to another. There are two different types of encoding for the HL7 2.x version:

• Delimiter-based Encoding
• XML Encoding

Delimiter-based Encoding

Delimiter-based encoding, as the name suggests, defines data fields of variable lengths and separates them using a delimiter. In this encoding, five different delimiters are used to lay out the message structure; for example, a carriage return delimiter is used to group message into different segments, a pipe (|) is used to group each segment into fields, and so on. Listing 2-1 shows an HL7 message with delimiter-based encoding.

Listing 2-1. ­ HL7 Message with Delimiter-based Encoding

MSH|^~&|ADM|HUN|||201302260415||ADT^A01|125|P|2.2|||AL|NE
EVN||201302260250|||REG.RN^Name^Name^^^^|201302260250
PID|1||M123123123^^^^MR^HUN||Name^Name^^^^^L||19891203|F||W|126 LK^^HU
NK1|1|B^K^^^^|MO|2 Street^^City^State^Zip^Country^^^DES|Number CELL
PV1|1|P|F.ECC^^||||||YTU.FR^Y^F^R^^^MD|EDS||||||||ER||MCD||||||||||||||||
ZBC|1
ZCS|N|N^^UNKNOWN^UN^00000|N|||01371

You will learn more about the message structure and its details in the next sections.

Message Structure

The HL7 delimiter-based encoded message structure contains all the information within different components. There are five components that make up the message structure.

• Delimiters
• Segments
• Fields
• Data Types
• Escape Sequences

Delimiters

Delimiters are the key components of the HL7 message. Delimiters allow you to identify these key components within the HL7 message. Table 2-1 provides descriptions of the default delimiters.

These delimiters are found at the start of MSH segment, as shown in Listing 2-2.

Listing 2-2. Delimters in the MSH Segement

MSH|^~&|ADM|HUN|||201302260415||ADT^A01|125|P|2.2|||AL|NE

These delimiters can be customized. For example, if you want # to be a field delimiter, then the code in Listing 2-2 will look like the code in Listing 2-3.

Listing 2-3. Customized Field Delimter

MSH#^~&#ADM#HUN###201302260415##ADT^A01#125#P#2.2###AL#NE

Segments

In Chapter 1, you were introduced to the key segments (components) of an HL7 V.2.x message. As previously mentioned, the HL7 message contains different segments; each segment represents specific information such as patient information, patient visit, patient insurance, lab results, etc., and groups the information into different data fields.

• Each segment is separated using carriage return ( on UNIX-based systems and on Windows) and has a uniquely identified segment name, which is three characters in length. These identifiers can be found at the beginning of the segment.
• As per the HL7 messaging standard defined by HL7, a segment in a HL7 message may be required or optional, and also may or may not repeat depending on the message type.

There are hundreds of predefined segments as part of HL7 2.X specification. Each segment indicates the kind of information it contains; for example, a patient admit HL7 message may contain segments as shown in Table 2-2.

An HL7 2.X message is all about one or more segments. These segments divide the HL7 message into three different parts, as shown in Figure 2-1:

• One message header segment (MSH)
• One or more message body segments
• Z segments

Let’s see what these segments contain.

1. Message Header Segment (MSH): As the name suggests, this contains information about the message, such as the message type, message event, version etc. It provides metadata about the message. Later in this chapter we will discuss the MSH segment in more detail.
2. Message Body Segments: Body segments are one or more segments containing the message data; for example, for a patient administration (ADT) the message contains various segments like PID, PV1, NK1, etc. The body of message may contain any segment as specified in HL7 specification for a particular message type and message triggering event.
3. Z Segments: Z segments are optional segments in a message. These segments are defined for customized solutions based on need. Basically Z segments provide customization to HL7 messages based on particular requirements. The HL7 organization has not or will not define any segment with the letter Z.

Fields

Fields in an HL7 message contain message information; in the OOPS world, we would consider them as properties of a class where the class is the segment. In this section, you will learn about following:

• Field Identification
• Subfields
• Sub-subfields
• Repeatable Fields

Field Identification

As you learned in the delimiter section, fields in an HL7 segment are identified using a delimiter, which is a pipe (|) by default. Listing 2-4 shows how the delimiter is used.

Listing 2-4. Field Delimiter Sample

PID|1|123456|M123123123^^^^MR^HUN||Name^Name^^^^^L||19891203|F||W|126

Each field in the segment is referred to by its ordinal position in the segment; in Listing 2-3, the highlighted field is referred to as PID1, PID2, and PID3, and the values are 1, 123456, and M123123123^^^^MR^HUN, respectively.

MSH|^~&|ADM|HUN|||201302260415||ADT^A01|125|P|2.2|||AL|NE

In a HL7 message, if you want to make sure that the receiving application deletes the data in their data store corresponding to the field, then the message should have the field value as “” e.g. |“”|. If the field is sent like ||, it will indicate that no change is required to the data store.

Subfields (Components)

Subfields are referred as components in the HL7 message specification. Throughout this book we will refer to them as subfields to make it easier to understand the relationship between fields and subfields.

A field can have subfields. You can find subfields within fields using the subfield delimiter, which is a caret (^) by default. In the following example, PID3 has six subfields highlighted; these fields are referred as PID3.1, PID3.2, and so on.

PID|1|123456|M123123123^^^^MR^HUN||Name^Name^^^^^L||19891203|F||W|126

Sub-subfields (Subcomponent)

A subfield can also have subfields; they are referred as subcomponents in the HL7 specification. We will refer to them as sub-subfields.

Sub-subfields are separated by ampersand (&) within the subfield. In following example, SFT segment field 1, subfield 6th has three sub-subfields referred to as SFT1.6.1, SFT1.6.2, and SFT1.6.3.

SFT|MEDITECH, Inc. ^L^^^^MEDITECH&1.3.6.1.4.1.24310&ISO^XX^^^MEDITECH|5.6.6

Repeatable Fields

The repeatable field is like an array of a field and is identified by repeat delimiter (~) in the field. In following example, there are three PID3 fields:

PID|1||0266432^^^Test&Test^MR^.~151-22-5907^^^^SS^.~104475^^^^PI^.||

Each PID3 will have its defined subfields and so on.

Data Types

All fields (PID1, PID2, etc.) have data types defined as part of HL7 2.x standard. The data type definition includes following key information:

1. Position (SEQ): It defines the position of the field in the segment. This number is also used to refer to the field, such as PID1.
2. Length (LEN): It indicates the number of characters the data field may contain.
3. Data Type (DT): Similar to any programming language variable data types, data types represent the type of data field. Data types may be either primitive such as “text” or a complex type mde of of primitive types.
4. Optionality: A field may be required, or optional, or it may be required in a particular condition in a segment. Conditionally required fields are either based on a triggered event or on some other field.
5. Repetition: For each field, repetition is defined to indicate whether the field can repeat or not. In the HL7 specification, a field man not repeat, may repeat indefinitely, or may repeat up to a specified number depending on the definition.
6. Optionality: A field may be required, or optional, or may be required in a particular condition in a segment. Conditionally required fields are either based on a triggered event or on some other field.
7. Name: Each field has a purpose, and its name in the segment is defined to indicate that purpose (such as PID3).
8. ID Number: It uniquely identifies the data item throughout the standard.

Use of Escape Sequences

The escape sequence allows you to have special characters in the HL7 message text that are not allowed normally; for example, delimiter characters can be included in the message field by using an escape sequence. An escape sequence as defined by HL7 organization (www.hl7.org/implement/standards/index.cfm?ref=nav) consists of an escape character which is defined in MSH.2, normally ‘’, followed by an escape code ID of one character then zero or more data characters, and another occurrence of the escape character, according to the spec. Table 2-3 shows the escape sequences that are defined for delimiters and other characters.

Some examples of escape sequences are shown in the following sections.

Highlight Text

The escape sequence of H can be used to format the text in many ways; for example, a receiving application can display the highlighted text in bold or in red color. The message fragment "OBX| TOTAL H240*N   [90 - 200]" can be used by receiving application to display the text as "TOTAL 240* [90 - 200]" or show the 240* in red.

Delimiter Escape Sequences

The HL7 messaging standard delimiters can be included in the message text by using the escape sequence of “F, S, R, T, and E”. For example, the message fragment

OBX|25|TX|||     FAF. PROCEDURE - WIDE RESECTION.||||||F|
OBX|26|TX|||     B. TUMOR T SITE - LEFT LOWER BACK.||||||F|

will be displayed as

|A|. PROCEDURE - WIDE RESECTION
B. TUMOR & SITE - LEFT LOWER BACK.

Usage and Examples of Formatted Text

Apart from the normal escape sequence, there are different commands that can be used alone or together with an escape sequence to format the text especially for fields with the FT data type. Formatted text commands start with a dot ‘ . ’ Table 2-4 shows different formatting commands available.

Message Types

Message types (MSH9.1) in the HL7 2.x specification correspond to a group of real world events. For example, Patient Administration has number of real world events, such as patient admit, patient registration, and many more. All such patient administration messages are grouped into one message type, which is referred to as ADT. There are more than 100 message types defined within HL7 specification. Some of the most common message types are listed in Table 2-5.

Message Trigger Event

Each message contains one or more trigger events (MSH9.2), which correspond to real-world events in the healthcare system. Some of the real world examples are the following.

1. Patient is admitted.
2. A request of service is created for lab.
3. Patient is discharged.
4. Patient appointment notification.

These real world events initiated the need for the HL7 2.x messaging standard to transfer information from one system to another. These events are bundled into specific message types; for example, Patient Administration-related events are bundled into message type ADT.

MSH|^~&|ADM|HUN|||201302260415||ADT^A01|125|P|2.2|||AL|NE

The message type and trigger event has a one-to-many relationship, so one message type can have more than one trigger event; however, one trigger event can only be part of one message type. The combination of message type and trigger event governs the layout of the message, so which segments are required or optional all depends on this combination. Table 2-6 is a partial list of message types and their events.

For each message type, a complete list of triggered events can be found in specific HL7 standard documents. If you need to find all events for ADT messages, then look for the CH03_PatientAdmin document of the HL7 message standard, which can be downloaded from: www.hl7.org/implement/standards/product_brief.cfm?product_id=185.

Message Version

A message also carries its HL7 2.x version to which it conforms within in message header MSH12 field. In the following sample, the version of the message is 2.4:

MSH|^~&|ADT1|MCM|LABADT|MCM|198808181126|SECURITY|ADT^A01|MSG00001|P|2.4

Message Control ID

The message control id (MSH10) field in the message header represents an identity for the message, which the sending application should generate so that it is unique and can be used to correlate the message acknowledgment sent by receiving application. In an enterprise, the message control id field should be used to track messages. The following example shows how to create the message control id:

MSH|^~&||COCFH|||201304210056||ADT^A08|FHGTADM.1.7230428|P|2.1

Message Acknowledgment

In an HL7 message exchange between two systems, the receiving application sends an acknowledgment of the message received to the sending application. This way message delivery is guaranteed between two systems. Also, the sending application does not send the next message until the acknowledgment is received from the receiving application. Figure 2-2 shows an example of the acknowledgment message.

Key Elements of the Acknowledgement Message

There are few key elements of an acknowledgment message.

1. Message Type (MSH9.1): The acknowledgement message type is ACK and it is same for all other message types.
2. Acknowledgment Code: MSA1 contains the acknowledgment code returned by the receiving application, which lets the sending application know the status of message, such as the receiving application has returned an error, rejected the message, or processed the message successfully. Using these acknowledgment codes, the sending application can decide the next step.
3. Message Control ID (MSH10): Sent by the sending application, this is also returned in the acknowledgment message, which makes it easier to correlate.

Acknowledgement Modes

There are two modes that determine how an acknowledgment should be returned. They are the original and enhanced modes.

Original Mode

In original mode, an application acknowledgment is returned, which means that before returning an acknowledgment to sending application not only is the message received by the receiving application but also it is processed successfully.

The message processing by the receiving application may vary depending on the functional requirements of a system; for example, a system can return the acknowledgment after storing the message in an input queue for later processing.

Enhanced Mode

The enhancement mode breaks the acknowledgment into two parts:

• Accept Acknowledgement: The receiving application sends the accept acknowledgment after storing the message to safe storage for later processing.
• Application Acknowledgment: Optionally, an application acknowledgment may also be returned to indicate the final message status to the sending system.

Acknowledgment Types

There are four acknowledgment types that can be used by the sending application in enhanced mode to request an acknowledgment from the receiving application. Table 2-7 lists them.

These same acknowledgment type can be used for both MSH15 and MSH16 and accordingly the receiving application sends the acknowledgment back.

Acknowledgment Code

The Acknowledgment code (MSA1) in the acknowledgment message returns the acknowledgment code that indicates the message status returned by the receiving application. Table 2-8 lists the acknowledgment codes.

ERR Segment

The error segment (ERR) is used to return error information in the acknowledgment message when the returned acknowledgment code is not AA or CA. One example of an acknowledgment with ERR segment is shown below:

MSH|^~&|TEST2|MCM|TEST|MCM|20131226132358||ACK|10000GSM|P|2.5.1|||NE
MSA|AA|MSG00001
ERR||PID^1^5|102^Data type error^HL79999|E||||||||^^^^^^^^^^^
ERR||NK1^1^2|102^Data type error^HL79999|E||||||||^^^^^^^^^^^

As you can see, the ERR segment include details about the errors the receiving application sends in acknowledgment. Some of the key fields of ERR segment are defined in Table 2-9.

XML Encoding

Using XML is an alternate encoding for an HL7 message that can be used where both the sender and receiver can understand XML. The XML representation of HL7 Version 2.x messages is algorithmically derived directly from the HL7 database. This is done to prevent work has to be done by hand, which often is susceptible to errors. Furthermore, deriving the XML representation algorithmically allows generating schemas for future HL7 v2.x versions easily.

Message Structure

In XML encoding, message segment fields are represented as XML elements. Listing 2-2 shows an example of an HL7 acknowledgment message in both delimiter and XML encoding.

Listing 2-2. Sample Delimiter and XML Encoding

MSH|^~&|TEST2|MCM|TEST|MCM|20131226132358||ACK|10000GSM|P|2.5.1|||NE
MSA|AA|MSG00001
ERR||PID^1^5|102^Data type error^HL79999|E||||||||^^^^^^^^^^^
ERR||NK1^1^2|102^Data type error^HL79999|E||||||||^^^^^^^^^^^

<?xml version="1.0" encoding="UTF-8"?>
<ACK>
  <MSH>
    <MSH.1>|</MSH.1><MSH.2>^~&amp;</MSH.2><MSH.3><HD.1>TEST2</HD.1></MSH.3>
    <MSH.4><HD.1>MCM</HD.1></MSH.4><MSH.5><HD.1>TEST</HD.1></MSH.5>
    <MSH.6><HD.1>MCM</HD.1></MSH.6><MSH.7><TS.1>20131226132358</TS.1>
    </MSH.7><MSH.9><MSG.1>ACK</MSG.1></MSH.9><MSH.10>10000GSM</MSH.10>
    <MSH.11><PT.1>P</PT.1></MSH.11><MSH.12><VID.1>2.5.1</VID.1></MSH.12>
    <MSH.15>NE</MSH.15>
  </MSH>
  <MSA>
    <MSA.1>AE</MSA.1><MSA.2>MSG00001</MSA.2>
  </MSA>
  <ERR>
    <ERR.2><ERL.1>PID</ERL.1><ERL.2>1</ERL.2><ERL.3>5</ERL.3></ERR.2>
    <ERR.3><CWE.1>102</CWE.1><CWE.2>Data type error</CWE.2><CWE.3>HL79999</CWE.3>
    </ERR.3><ERR.4>E</ERR.4><ERR.12><XTN.12> </XTN.12></ERR.12>
  </ERR>
  <ERR>
    <ERR.2><ERL.1>NK1</ERL.1><ERL.2>1</ERL.2><ERL.3>2</ERL.3></ERR.2>
    <ERR.3><CWE.1>102</CWE.1><CWE.2>Data type error</CWE.2><CWE.3>HL79999</CWE.3>
    </ERR.3><ERR.4>E</ERR.4><ERR.12><XTN.12> </XTN.12></ERR.12>
  </ERR>
</ACK>

Root Element—Message Structure IDs

In the HL7 Version 2.x standard, several trigger events share the same abstract message syntax. An example of this could be an ADT message that is triggered by event A04, which the same message structure as ADT A01. In addition to A04, other events like A05, A08, A13, A14, A28, and A31 share the same A01 message structure. Until Version 2.3.1, there was no way to represent this in an HL7 message; however, with version 2.3.1, this fact became standardized and represented as Message Structure ID in an HL7 message by adding a new field called MSH9.3 to the message type MSH9 field. The following is an example of the ADT_A01 delimited message structure used by ADT A04 message event:

MSH|^~&|ADT2||LAB||198808181121|SECURITY|ADT^A04^ADT_A01|MSG00001|P|2.4

The message structure ID is relevant for XML encoding since this is used as a root element in an XML instance document, as shown:

<?xml version="1.0" encoding="UTF-8"?>
<ADT_A01>
        ...(Segment Elements)
</ADT_A01>

Segments

Message structures contain segments also represented as XML elements. Each segment name is three characters long, similar to HL7 V2.x encoding; these names are used as an XML element. The following example shows a few segments as an XML element:

<?xml version="1.0" encoding="UTF-8"?>
<ADT_A04>
        <MSH>
              ...(MSH Field Elements)
        </MSH>
        <PID>
             ...(PID Field Elements)
        </PID>
        <PV1>
             ...(PV1 Field Elements)
        </PV1>
        ...(Other Segment Elements)
</ADT_A04>

Segment Groups

One benefit of XML encoding is the ability to represent segment grouping easily. In a group, whether a segment is optional or repeatable is represented using brackets [ ... ] or braces { ... } in the standard. So segments [{ IN1, [ IN2 ], [{ IN3 }], [{ ROL }] } ] represent the INSURANCE group, where each group itself is optional or may repeat, and within the group segment, IN1 is required, IN2 is optional, IN3 is optional or may repeat, and ROL is optional and may repeat as well.

The explicit grouping is one major difference between delimiter and XML encoding as there is no grouping in traditional delimiter encoding.

Segment group naming includes upper case names. So ADT_A01.INSURANCE and the name itself represents the purpose of the segment group. In other words, the “INSURANCE” group bundles all INx segments, and the “VISIT” group bundles PV1 and PV2 segments, as shown in following example:

<?xml version="1.0" encoding="UTF-8"?>
<ADT_A04>
        <MSH>
        ...(MSH Field Elements)
        </MSH>
        <EVN>
        ...(EVN Field Elements)
        </EVN>
        <PID>
        ...(PID Field Elements)
        </PID>
        <ADT_A04.INSURANCE>
                <IN1>
                ...
                </IN1>
                <IN2>
                ...
                </IN2>
                <ROL>
                ...
                </ROL>
        </ADT_A04.INSURANCE>
</ADT_A04>

Another way of grouping segments is by a choice; here a decision has to be made as to which set of segments should be conveyed in a message: This is indicated in the HL7 standard documents by angle brackets: < and >. The different options for a choice are then separated by a vertical bar. In the XML schema, the choice is represented using the xsd: choice element.

Fields

In XML encoding, XML elements representing fields and their naming conventions are based on segment names and the field positions in the segment. So the first field in PID segment is named PID.1, the second is PID.2, etc., like so:

...
<PID>
  <PID.1>1</PID.1>
  <PID.2>
    ...
  </PID.2>
</PID>

In delimiter-based encoding, empty fields are also required to be separated by a pipe; however, in XML encoding, an element with no contents simply can be omitted (unless explicit use of the “” is required to force a data delete action by the receiving application).

Data Types

The data types for the fields are defined similarly to that of delimiter-based encoding for each field. Please refer to the “Data Types” section of the “Delimiter-based Encoding” section for more details.

Use of Escape Sequence

There are some basic differences in the escape sequence between delimiter- and XML-based encoding. These differences are as follows:

• In XML encoding, there is no use of a delimiter character escape sequence, as these are not used to form the message structure.
• Instead of using “” as an escape sequence character, XML encoding uses an XML element to define escape sequence, as shown in Table 2-10.

Similarly, the command also indicates using XML elements, as shown in Table 2-11.

Message Header Segment

As mentioned before, with XML encoding there is no change to message semantics. All header properties and their definitions remain as in delimiter-based encoding.

Message Acknowledgment

Both message acknowledgment modes, original and enhanced processing, remain the same in XML encoding, except that validation of messages now includes well-formed and valid XML by the receiving system. This means sender system must ensure that the HL7 message’s XML is well-formed and valid as per its schema.

XML Schemas

HL7 provides XML schemas for each version supported by HL7 Version 2.x.XML specification, as shown in Table 2-12.

An XML instance of a specific message should refer to the corresponding schema. The following code shows a schema reference within a v2.XML XML message instance fragment:

<ADT_A04
        xmlns="urn:hl7-org:v2xml"
        xmlns:xsi="http://www.w3.org/2001/XmlSchema-instance"
        xsi:schemaLocation="urn:hl7-org:v2xml ADT_A04.xsd">

        <MSH>...
<ADT_A04>

Summary

In this chapter, you took an in-depth tour of the HL7 message structure, encoding, and acknowledgment model. Understanding these concepts is key to any implementation of healthcare-based system. In Chapter 3, you will learn about the Microsoft BizTalk HL7 Accelerator and its capabilities for HL7 2.x message processing.