HL7 Engine Mapping

May 14th, 2007 by Dave Shaver

3 Votes | Average: 4.67 out of 5 (3 votes, average: 4.67 out of 5)

Loading ...

In a prior post, I described the motivation for mapping HL7 messages. As described in that post, the HL7 2.X messaging standard is the most widely used method to move healthcare information yet the details of the messages vary greatly from system to system.

An HL7 engine provides several functions and one of the key features of an engine is the ability to map from one set of application assumptions to another set. Said another way, an HL7 integration engine takes a message in one format and maps or transforms it into another format.

The starting and ending message formats will be controlled by the applications involved. Prior to HL7’s market dominance, the variety of message formats was large. This meant that typically an interface’s data elements closely matched the data model in the source application. Further, this made the creation of the interface “easy” by the sender of the data but “very hard” for an engine in the middle or the receiving application.

The HL7 community’s approach to define a base data model for the messages makes the variety of message formats smaller in today’s engine market. This reduction in the number of message formats is somewhat offset by the huge number of interfaces that must be created.

In the current market, typically an interface engine is mapping in one of the following ways:

Mapping between two or more interpretations of the HL7 standard to resolve data model or workflow issues between incompatible applications
Mapping between XML and HL7 and/or HL7’s 2.XML format
Parsing an HL7 message and writing message contents to a database
Reading a database and creating an HL7 message
Working with a mixture of proprietary message formats such as CSV or flat files (sometimes called COBOL copybooks)

An HL7 interface engine needs to be flexible enough to deal with non-standard HL7 messages in an efficient and accurate manner, without having to manually code the differences for each external healthcare vendor with which it is communicating.

An HL7 interface engine also must provide a quick way to start with a standard “base HL7 version” and modify it to mirror the differences in the message that is sent or received by a particular application.

As an example, NeoTool’s interface engine supports non-standard HL7 formats by:

Including all the standard HL7 versions loaded and available for easy modification
Allowing for modification of these base versions by creating a derivative of the standard message format that inherits all the characteristics of the standard format – supports Z segments, non-standard separator characters, etc.
“Change once” segment definitions so that a single change is properly reflected in all messages that use that segment
Providing the ability to leverage prior derivative work and create a derivative of a derivative – to support two versions of a single application, for example

The message format support of an interface engine is combined with a method of actually mapping from one format to another format. Typically this is accomplished via some graphical mapping tool and executation environment. In a future post, I will describe some of the techniques used while actually mapping messages.