Conformance Checking for HL7

Ensuring Messages are Understood by Healthcare Vendors Before and During Processing

X is to provide a framework for negotiation so that each healthcare interface is closer to 20% custom rather than 100%. 2 . 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. 2. Consequently. Gap analysis or conformance checking for HL7 messages. adopted by another device or application. This occurs primarily in the areas of cardinality and the HL7 version that is used. it varies greatly in how it is implemented by each medical device and application. and either singleton (non-repeating) or repeating. In order to communicate effectively between systems with different message formats.X message standard to meet their system’s unique requirements. Nonconformance occurs for two main reasons: 1. where elements can be either optional or required. you must determine where the messages are incompatible and make changes to at least one. The variances in implementation lead to different message formats among healthcare vendors and external providers. An application team utilizes the flexibility of the HL7 2. or a custom format. Cardinality Cardinality represents the minimum and maximum number of values that can exist inside a given element of a message.Overview Although the HL7 2. The purpose of HL7 2.X messaging standard is the most widely used standard in the United States for the exchange of clinical patient data. of the interfaces that are accepting or sending messages. The HL7 messaging standard allows cardinality. The HL7 messaging standard can be complex and sometimes is easily misinterpreted. 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. and potentially both. it is often called the “non-standard standard”.

they would allow zero to infinite patient addresses (cardinality of 0 to n). it would seem to provide enough flexibility to be followed by all systems. this is an area that frequently causes nonconformance. Therefore.X does not matter. Team 2. There are a few instances of where nonconformance occurs due to version differences. If the application developed by team 1 sends a message to team 2’s application without a patient address. in this example. In theory. The following example shows one way this can happen. the version of HL7 2. may require one patient address but only allow one (cardinality 1 to 1). these systems are in use and actively trading HL7 messages with other systems. Field or Segment Patient address field (PID-11) Rule optional and repeating optional and nonrepeating required and nonrepeating required and nonrepeating Cardinality 0 to n Patient primary language field (PID-15) Patient class field (PV1-2) 0 to 1 1 to 1 The Patient Identification (PID) segment in the Patient Admission message (ADT-A01) 1 to 1 How Does Cardinality Cause Nonconformance? When looking at cardinality. the application from team 2 would not accept it.X is designed to be backward compatible. HL7 Versions HL7 2. There are clinical healthcare systems that have misapplied cardinality rules and are not technically HL7 compliant. However.Examples of HL7 message cardinality are shown in the following table. is not HL7 compliant. A few of these are shown in the following table: 3 . However. Another development team (team 2). so that older systems communicating with newer systems do not need to contain those elements. even though the message is HL7 compliant. One development team (team 1) may implement the cardinality of the Patient Address Field (PID-11) exactly as the standard says. As new segments and fields are added they are marked as optional.

4 contains an ADT-A60 message to update allergy information. This could result in any number of messages from the application to lack HL7 compliance. For example.2 contain an ORUR03 message. but previous versions do not contain this message. Interfacing with other applications may not be the highest priority on the list when creating a clinical application. even though HL7 defines it as optional.5 required datatype component. Where do you start? 4 . while extremely flexible.3.3 and beyond do not contain this message.5 system will not accept the message. accordingly.2 sends an ORU-R03 message to a system that uses HL7 2. Version 2. the HL7 2. ignores it. The HL7 messaging standard. the allergy information will not get updated. Version 2.1 and 2.4 sends an ADT-A60 message to update allergy information to a system that uses an earlier HL7 version. one of the components of a datatype can be required or can repeat.5 system that does not contain the 2. the receiving system may not know what to do with the message and. decisions regarding how the application will work may have already been made. By the time interfacing is approached. Result If a system using HL7 2. Misinterpretation of Standard Development teams are experts in their specialized area.4 sends a message to a 2.5 has the new ability to define cardinality for datatype components.Difference Version 2. If a system using HL7 2. How Do You Check for HL7 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. but not necessarily in HL7 messaging. Nonconformance due to differing versions is most often caused by one system requiring a message element that did not exist in a previous version. If a system using HL7 2. Version 2. such as a lab or pharmacy. is also complex.

Most interfacing experts agree that it is much easier to use an existing tool to parse and encode HL7 messages than to create one individually. This sample of messages should be large enough to represent each type of message you may receive from the external healthcare vendor.First. Finally. Teaching Your System to Understand the Message Differences There are many reasons systems that claim to be HL7 compliant have message formats that are not quite HL7 compliant. This is commonly accomplished by using an HL7 interface or communications engine that sits between the two separate systems and parses and encodes the messages coming into or leaving the system. However. sample messages will provide you with the most accurate view of the message formats you will receive. Next. teach your system how to understand the different message format in order to receive and send messages. Determining Message Format Differences Determining format differences begins with analyzing the external healthcare vendor’s message specifications and sample messages. record those issues. Additionally. If you find additional areas of nonconformance in the sample messages. therefore. The areas of nonconformance found within the specifications and message samples provide critical information for you to use when negotiating with the external healthcare vendors or providers. walk through the message samples to confirm that the sample messages match the specification. If it does not. The best tools have extensive HL7 knowledge built in and provide maximum flexibility to adjust to varying message formats. determine how closely the incoming and outgoing message formats matches your own. 5 . each message should be checked as it is coming into your application during run-time in order to verify that it provides your application with the fields you require. and so it needs to be able to accept and receive messages that are not conformant with your own format standard. all the flexibility within the HL7 standard creates differences in the messages. Second. Compare specifications with your message format to determine the areas of nonconformance. make sure it is put aside to be evaluated for possible noncompliance. These specifications are rarely up-to-date. There are a number of different tools available that provide assistance in the creation of the interfaces. the fact remains that your system is communicating with these applications.

which complies with HL7’s recommendation to ignore unexpected elements. Summary Although complex. Any quality interfacing tool will have configurable conformance checking available at run-time. you should ignore the unexpected segments when you are in runtime mode. You may. want to require the existence of required elements in your message to avoid having incomplete data.Conformance Checking During Run-Time You must weigh the advantages and disadvantages of how strict your conformance checking treats incoming messages. however. the more messages will error and require manual intervention to process. engaging in a conformance checking process will greatly improve the integrity of the exchange of clinical data via the HL7 standard. Typically. several items will need to be checked for conformance to the HL7 standard used:     Cardinality within fields or segments HL7 version features used by both the sending and receiving entity Customization and/or misinterpretation of the HL7 standard Differences in message formats 6 . Whether you utilize an interfacing tool or engage in a manual process. The stricter your conformance checking at run-time.

.corepointhealth.com Corepoint Health 6509 Windcrest Drive Suite 160B Plano. Texas 75024 469-229-5000 info@corepointhealth. laboratories. consulting and training.About Corepoint Health Corepoint Health solutions deliver interoperability for healthcare organizations and simplify the complexities of healthcare data through practical software applications. Corepoint Health is not responsible for errors in typography or photography. www. imaging centers. Our innovative and proven software solutions leverage clinical data flow efficiently for a diverse group of healthcare entities including hospitals.com 7 © 2009 Corepoint Health. clinics and healthcare vendors. This next generation approach to healthcare data and streamlined workflow is where Corepoint Health specializes in helping customers discover the power of integration.