NeoTool — Singular Focus, Healthcare Integrated

Posted in HL7 Standard, HL7 Integration

HL7 defines character sequences to represent ’special’ characters not otherwise permitted in HL7 messages. These sequences begin and end with the message’s Escape character (usually ‘\’), and contain an identifying character, followed by 0 or more characters. The most common use of these escape sequences is to escape the HL7 defined delimiter characters. These delimiter or separator characters are defined in MSH-1 and MSH-2 of the HL7 message and typically have the following values:

| Field Delimiter
^ Component Delimiter
& Sub-Component Delimiter

The other 2 special case characters defined in MSH-2 are:

~ Repetition Separator
\ Escape Character

When parsing HL7 messages, interface engines and HL7-enabled applications should be able to recognize these special escape sequences and properly convert them. Similarly, if producing HL7 messages that contain special data, the application should properly escape the data using the HL7 escape sequences.

A simple example of this can be seen in the following OBX segments:

OBX||10|||Current Medications
OBX||11|||DILANTIN & NORVASC

The OBX-5 field is defined by HL7 to contain data conforming to an ST datatype. This should be a single string value. What we see in our message is the value DILANTIN & NORVASC. The ‘&’ character is typically used as the sub-component separator in an HL7 message. By the rules of HL7 this message is not properly formatted. Since the ‘&’ character in this case is meant to be part of the resulting text, it needs to be escaped. The correct representation of this message should be as follows:

OBX||10|||Current Medications
OBX||11|||DILANTIN \T\ NORVASC

When a receiving application reads this message it should follow the rules of the HL7 standard, and convert the \T\ to the ‘&’ character prior to importing this information into their system. When pursuing an HL7 integration project in the real world, it is very common to interface with a system that claims to be HL7 compliant, but they do not support the HL7 encoding sequences.

This means that you may receive an HL7 message with improperly formatted data. This also means that when interfacing with one of these non-compliant HL7 systems, they may actually require you to send them HL7 messages where the special characters of HL7 are not properly escaped.

The table below shows the HL7 Escape sequences, and how they are converted:

Character	Description Conversion
\Cxxyy\	Single-byte character set escape sequence with two hexadecimal values not converted
\E\	Escape character converted to escape character (e.g., ‘\’)
\F\	Field separator converted to field separator character (e.g., ‘|’)
\H\	Start highlighting not converted
\Mxxyyzz\	Multi-byte character set escape sequence with two or three hexadecimal values (zz is optional) not converted
\N\	Normal text (end highlighting) not converted
\R\	Repetition separator converted to repetition separator character (e.g., ‘~’)
\S\	Component separator converted to component separator character (e.g., ‘^’)
\T\	Subcomponent separator converted to subcomponent separator character (e.g., ‘&’)
\Xdd…\	Hexadecimal data (dd must be hexadecimal characters) converted to the characters identified by each pair of digits
\Zdd…\	Locally defined escape sequence not converted

Last 5 posts by Mike Stockemer

• Comparing HL7 Messages to HL7 Documents - January 25th, 2008
• Monitoring and Alerting for HL7 Interfaces - October 22nd, 2007
• Variations of the HL7 ORU^R01 Message Format - September 10th, 2007
• Point-to-Point Interface vs. Interface Engine in Healthcare - August 23rd, 2007
• Getting Started with Your HL7 Interface - August 16th, 2007