HL7 Conformance Checking with NeoIntegrate
Using the Power of Neointegrate to Discover and Manage Message Format Differences
Overview
Although the HL7 2.X messaging standard is the most widely used standard in the United States for the exchange of clinical patient data, it varies greatly in how it is implemented by each medical device and application. Consequently, it is often called the “non-standard standard”. The purpose of HL7 2.X is to provide a framework for negotiation so that each healthcare interface is closer to 20% custom rather than 100%.
The variances in implementation lead to different message formats among healthcare vendors and external providers. In order to communicate effectively between systems with different message formats, you must determine where the messages are incompatible and make changes to at least one, and potentially both, of the interfaces that are accepting or sending messages.
Gap analysis or conformance checking for HL7 messages, is a logical process used to determine whether a message from one particular medical device or application is compatible to the standard HL7 messaging format, or a custom format, adopted by another device or application.
Why Does Nonconformance Occur?
Nonconformance occurs for two main reasons:
- An application team utilizes the flexibility of the HL7 2.X message standard to meet their system’s unique requirements. This occurs primarily in the areas of cardinality and the HL7 version that is used.
- The HL7 messaging standard can be complex and sometimes is easily misinterpreted.
Cardinality
Cardinality, another cause of nonconformance, represents the minimum and maximum of number of values that could exist inside a given element of the message. The HL7 messaging standard allows segments and fields to be either optional or required, and either singleton (non-repeating) or repeating.
This same functionality exists for sub-components as well in 2.5. For example, the Patient Address field (PID-11) can be optional and repeating. One development team may implement this exactly as the standard says and allow zero to infinite patient addresses.
Another development team may require one patient address but not allow more than one. Messages from these two systems would not be conformant with each other.
Cardinality
Cardinality, another cause of nonconformance, represents the minimum and maximum of number of values that could exist inside a given element of the message.
The HL7 messaging standard allows segments and fields to be either optional or required, and either singleton (non-repeating) or repeating. This same functionality exists for sub-components as well in 2.5. For example, the Patient Address field (PID-11) can be optional and repeating.
One development team may implement this exactly as the standard says and allow zero to infinite patient addresses. Another development team may require one patient address but not allow more than one. Messages from these two systems would not be conformant with each other.
HL7 2.X is designed to be backward compatible to work with systems using different versions. However, there are a few instances where problems occur, such as when message triggers vary from version to version, for example MDM-TO2 exists in 2.3 but not in 2.2.
An application development team or implementation team may adjust the HL7 messaging standard to better support their application or system. Sometimes these adjustments make the message format used by that application or system noncompliant with the HL7 standard.
For example, an application may have a database that only has one field for a patient alias and therefore the application only allows one patient alias to be entered in the GUI. The HL7 standard says that the patient alias field can repeat, so it is conceivable that a message received through an HL7 interface would have more than one patient alias.
Finally, while development teams are experts in their specialized area, such as a lab or pharmacy, that expertise does not necessarily transfer to HL7 messaging. The HL7 messaging standard, while extremely flexible, is also complex.
Additionally, interfacing with other applications may not be the highest priority on the list when creating a clinical application. By the time interfacing is approached, decisions regarding how the application will work may have already been made. This could result in any number of messages from the application to lack HL7 compliance.
Like most things regarding HL7 2.X, these differences need to be negotiated between the external healthcare vendors trying to exchange data.
How Do You Check for Conformance?
As an analyst trying to ensure correct communication between medical devices and applications, you will have to look at all the possible predictable and unpredictable causes for nonconformance. Where do you start?
____________________________________________________________________To download a complete PDF version of HL7 Conformance Checking with NeoIntegrate, follow the attachment below.
| Attachment | Size |
|---|---|
| HL7 Conformance Checking with NeoIntegrate.pdf | 125.29 KB |