Conformance Checking for HL7
Ensuring Messages Are Understood by Healthcare Vendors Before and During Processing
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?
You may wonder why you need to perform a gap analysis or check for conformance between devices or applications that say they are HL7 compliant.
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 represents the minimum and maximum number of values that can exist inside a given element of a message. The HL7 messaging standard allows cardinality, where elements can be either optional or required, and either singleton (non-repeating) or repeating. Examples of HL7 message cardinality are shown in the following table.
How Does Cardinality Cause Nonconformance?
When looking at cardinality, it would seem to provide enough flexibility to be followed by all systems. However, this is an area that frequently causes nonconformance. The following example shows one way this can happen.
One development team (team 1) may implement the cardinality of the Patient Address Field (PID-11) exactly as the standard says. Therefore, they would allow zero to infinite patient addresses (cardinality of 0 to n).
Another development team (team 2), may require one patient address but only allow one (cardinality 1 to 1). Team 2, in this example, is not HL7 compliant.
If the application developed by team 1 sends a message to team 2’s application without a patient address, the application from team 2 would not accept it, even though the message is HL7 compliant.
There are clinical healthcare systems that have misapplied cardinality rules and are not technically HL7 compliant. However, these systems are in use and actively trading HL7 messages with other systems.
HL7 Versions
HL7 2.X is designed to be backward compatible. As new segments and fields are added they are marked as optional, so that older systems communicating with newer systems do not need to contain those elements. In theory, the version of HL7 2.X does not matter. There are a few instances of where nonconformance occurs due to version differences.
Nonconformance due to differing versions is most often caused by one system requiring a message element that did not exist in a previous version, even though HL7 defines it as optional.
Misinterpretation of Standard
Development teams are experts in their specialized area, such as a lab or pharmacy, but not necessarily in HL7 messaging. The HL7 messaging standard, while extremely flexible, is also complex.
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.
________________________________________________________________________
To download a complete version of Conformance Checking for HL7, follow the PDF link below.
| Attachment | Size |
|---|---|
| Conformance-Checking-for-HL7.pdf | 71.86 KB |
