Netsoft Blog

7 Common Problems with HL7

July 8, 2013

Do these problems prevent you from communicating? 

HL7 was designed as a standard language to allow health care service companies to send and receive information, but HL7 is often anything but standard. Do any of these common problems prevent you from communicating effectively? If so, HL7 integration may solve your frustrations.

1. Different versions of HL7

HL7 is supposed to be compatible across all versions, but there are many optional and required fields that change. Some of these fields may be required by an implementation of the standard. If someone is sending you data in V2.5.1 that you cannot read in V2.3, then you have a problem. Imagine reading a book in Old English – it’s still English, but it probably doesn’t make much sense.

2. Use of customized extensions

Z-extension segments are great for encoding information that does not fit any existing HL7 segment, but this customization requires special processing to understand the data. Radiology centers, for example, typically send reports in the Observation Group (OBX) segment, but what happens if the report is a PDF document? In this case, the PDF needs to be embedded in the HL7, and, because there is no designated place for a PDF report, senders often stick it in a custom extension field. If someone puts the report in a custom extension field and your system does not know how to interpret the data, then you cannot see the report.

3. Mismatch field usage

Simple tasks, such as where a patient’s date-of-birth (DOB) is encoded, or how it is encoded, can create problems. An Electronic Medical Record (EMR), for example, may look for the DOB in a different field than where it was recorded. DOB is often used to route messages to the appropriate physician, but if the DOB is not found by the receiving EMR than the message is not processed. Just like you would not think to look for your lost keys in the freezer, the receiving EMR does not look for DOB in the field labeled “Last Name.”

4. Coded values

Coding sets can differ from application to application. There may be two or more codes for a widely used medication, but if one systems uses code A while another system uses code B then someone must translate the codes. This translating, known as mapping, can become involved and complex.

5. Weak message delivery

Few systems support “enhanced mode acknowledgement” so most senders are only aware that their message was received, but not if it was accepted or understood by the receiving system. Receivers usually send an ACK to say ‘I got your data, but I haven’t looked at it.’ Without viewing and accepting the contents of the message, the data could fail when the EMR tries to load it.

6. Mismatch segment usage

Some systems ask for report information in the Note (NTE) segment, while others want it in the Observation (OBX) segment. Someone has to change the message to meet these nuances in order for the receiver to view the report. If an EMR is looking at the NTE segment for a cancer report, for example, but the report was sent in the OBX segment, then no one is made aware that the patient has cancer. Fortunately, testing typically reveals these disconnects and the integration engines modify the message so receiving system can understand it.

7. Optional segments and fields

The HL7 specification may clearly note that a segment or field is optional, but some systems require the inclusion of the data in order to successfully exchange information. If you are unaware that a receiver’s system requires an entry in a certain field, however, then you may leave that section blank and the message may not be received.

Are you about to replace HL7 with carrier pigeons? Don’t give up just yet. These problems can be solved with HL7 integration.

 

Topics: Application Development