Nonconformance occurs for a variety of reasons. The HL7 2.X message standard provides a great deal of flexibility so that application teams can choose to vary the message formats to best meet their system’s requirements.
Primarily this occurs in the areas of cardinality and the HL7 version that is used. Additional nonconformance occurs because of decisions made by development or implementation teams for the good of their system, or misinterpretations of the complex HL7 messaging standard.
HL7 2.X is designed to be backward compatible. However, there are a few instances where problems occur, such as when message triggers vary from version to version.
An application development 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 noncompliant with the HL7 standard.
For example, an application may have a database that only has one field for a patient alias; 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.
The HL7 messaging standard can be complex. Development teams are usually experts in the area they are developing for, such as a lab or pharmacy, but not necessarily HL7 messaging. Interfacing with other applications tends to be the last thing on the list when creating a clinical application so it is often left to the last task. By that time, application decisions may have already been made that could cause a message to be nonconformant.
Like most things regarding HL7 2.X, these differences need to be negotiated between healthcare providers and vendors.
Latest posts by Nita O'Neal (see all)
- Kudos to a Physician for Transferring to an EHR - May 20, 2011
- How Do You Learn? - January 20, 2011
- Up Close and Personal with Electronic Medical Records - November 30, 2010