NeoTool — Singular Focus, Healthcare Integrated

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:

When embarking into an HL7 integration project, specifications can be a great resource of information. HL7 specifications for an interface project to exchange clinical data is no different.

An interface implies two sides, each side being a clinical application that should be able to provide HL7 specifications for the project.

The specifications will detail important information regarding the interface including the following:

• Communication protocol
• HL7 standard version
• HL7 message(s) to be sent or received
• Message format or segment layout for each message
• Field list for all segments including Z segments
• Other details (e.g., use requirements, field content, optionality, etc.)

If you are able to obtain good specifications detailing all the needed information, you should be ready to begin the gap analysis phase. 

However, specifications or useful specifications may not be provided. In these cases, you can try to request sample messages from the application. With the right tools, you can probably determine the HL7 messaging format to be used.

With or without specifications, asking for sample messages is always a good idea. Often times, don’t be surprised to find that the sample messages do not match the specifications. You can simply add these items to the gap analysis.

Good luck in your HL7 integration project!

One of the first challenges when researching HL7 interfaces and connectivity is answering the question, “How do download a copy of the HL7 standard specification?” The unfortunate answer is that there is no free copy of the HL7 manual. You purchase the document from the HL7 standards organization.

To get the HL7 specification / guide, visit the official HL7 web site. The cost for the reference will vary based on what version(s) of HL7 you want. Figure spending around $500 if you not a member of HL7.

If you are a technical type — software developer, product manager, clinical application installer, etc. — it seems “wrong” that a standard should cost money. The need to purchase the standard is much different than the approach taken by so many other broad Internet standards.

In the more vertical standards world, often you have to purchase the handbook documents; they are not available for free. Whether it is X.12 (for HIPAA standards) or ASTM (for the CCR standard), you need to plunk down your credit card to get the guidebook.

HL7 tools, such as an HL7 message examination tool, can drastically help reduce the dependency on the paper standard. However, any software tool is not a replacement for the standard itself – the browser (or interface engine) only augments the narrative found in the standard proper. That is, an HL7 integration tool can tell you that “PID-8″ is the patient’s gender or that an ADT A01 transaction is an inpatient admission, but you’ll need the HL7 specification proper to help understand the intent of the message.

In addition to the formal specification, you’ll need your vendor’s HL7 specification. This implementation guide tells you what choices a vendor has made in their HL7 interface. How a vendor implements HL7 messaging is as interesting as the formal specification.

In prior posts I described the Continuity of Care Record (CCR) and the relationship between HL7 2.X and CCR. This article addresses a need to mix the two formats. Specifically, the desire to move a CCR document via HL7 messaging.

Previously I established that HL7 2.X is typically used to move data within a facility in a real time fashion while CCR was designed to move data between facilities in a summarized fashion.

In HL7 training classes, I talk about the “sphere of influence” of healthcare systems deployment. Mostly what I mean by sphere of influence is that HL7 2.X messaging is often used to move data between clinical systems that are owned by one organization.

That is, I want my hospital information system (HIS) system to talk to my lab information system (LIS) and my radiology information system (RIS). Having purchased these systems and customized them to my institution’s clinical and business work flows, I want them to exchange data in my own special way. The HL7 standard has lots of flexibility built in to support each facility’s “special” needs.

Suppose that you want to move a CCR document between two systems by having the CCR document encapsulated inside an HL7 message? The motivation for this touch point could be that there is already an interface between two applications. For example, an HIS might be delivering ADT (registration) data and lab results to an outpatient clinic. That clinic now wants to use “the same” interface to receive discharge summaries. So, if both the HIS and EMR vendors support this additional data flow, we could package the CCR inside of an HL7 message. How?

From an HL7 2.X standpoint, moving a CCR document is no different than encoding / sending a Word document, PDF file, DICOM image, or even a .wav sound file inside of an HL7 message.

The method proposed by HL7 2.X to move such an object is using an OBX segment with and OBX-5 flavor of encapsulated data (ED) or reference pointer (RP). 

The details of this HL7 integration approach are covered in another post here on this site.