HL7 is a health data communication standard. HL7 version 2 covers the exchange of patient demographics (also known as the Master Patient Index or PMI). HL7 V2 also covers other types of data such as admission details, scheduling, orders, and results.

1. HL7 interfaces are not plug and play

Unfortunately, software developers and implementers interpret the HL7 V2 standard in different ways. The result is two interfaces that are similar but do not match exactly and require analysis to identify the differences.

2. Translation of HL7 messages

Once differences have been identified, messages from one application must be modified before the other application can process them. Some translations can be relatively simple, such as moving a particular field from one place in the message to another.

For example, the shipping system may place an insurance number in the insurance segment (IN1). However, another provider may not support that segment, and instead expect the insurance number to be placed in the patient identification (PID) segment, or perhaps a proprietary segment.

It is also common that fields need to be moved based on business rules. Fortunately, specialized software called interface engines is pretty good at this task. For example, iCan Integrator software from Sun Microsystems (formerly Seebeyond) provides this type of functionality.

3. Code table mismatch

HL7 messages are alphabetized with encoded data. For example, the marital status field contains a value encoded as ‘M’ for married, ‘D’ for divorced, etc. However, the receiving system may expect ‘1’ for married and ‘2’ for divorced. National standards have gone a long way in addressing this problem. Still, chances are one or more fields in your PMI message need to be mapped. Fortunately, interface engines are also good at this task.

4.HL7 PID Identifier List

The patient identification segment has three fields dedicated to identifiers. Patient ID PID-2 (External ID), Patient ID PID-3 (Internal ID), and Alternate Patient ID PID-4. The recommended use of these fields has changed with successive HL7 releases (HL7 V2.1, HL7 V2.2, HL7 V2.3, HL7 V2.3.1, HL7 V2.4). Different vendors have interpreted these fields differently. Almost everyone puts the patient’s medical record number (MRN) in the PID-3.

If the scope of the interface is more than one hospital, then the MRN for one facility is distinguished from the MRNs for other facilities by a facility code (passed as a subcomponent of the PID-3 field). The installation code may need mapping (see Tip 2!).

In another twist, the sending system may handle multiple hospitals (for example, a patient management system that covers multiple hospitals), but the receiving system may want to know about patients from a single facility. A typical example is a standalone application (but with HL7 interface), such as an ICU clinical application. If the ICU system only manages patients from one hospital, you will only want HL7 messages for patients at that hospital. You may even only want HL7 messages for ICU admitted patients. Frontend engines are good at filtering, routing, and translating the messages needed to make this happen.

5. Repeating fields

Repeating fields, such as the address field (PID-11), can also cause problems. The challenges include

• Different systems support different numbers of repetitions. For example, the sending system may support 7 addresses and the receiving system may support only 2.
• The submission system can add, update, or remove the repeating field. Deleting a field can cause headaches for the downstream system. Sometimes this is overcome by the downstream system replacing the full set of repeating fields each time.

6. Repeating segments

Repeating segments such as ‘Next of Kin’ (NK1) and Alerts/Allergies (AL1/IAM) pose similar challenges to repeating fields.

• Different systems support different numbers of repetitions. For example, the sending system can support 7 patient contacts (sent as 7 NK1 segments) and the receiving system can support only 2.
• The submission system can add, update, or remove the repeating field. Deleting a field can cause headaches for the downstream system. Sometimes this is overcome by the downstream system replacing the full set of repeating fields each time.

7. Shared fields

It is not unusual that interconnected fields from the sending system can also be modified in the receiving system. Basically, if the receiving system was not interconnected, then all the information would have to be duplicated by manually typing it into the application. Unless the ability to edit data fields covered by the HL7 interface is “removed” from the receiving system, changes made to the data (eg, adding or changing an allergy, deleting a patient contact) by users in the receiving system, can be listed with the next HL7 message received, processed and stored for that patient.

Fortunately, persistent and diligent interface analysis can overcome these and other challenges. The HL7 PMI interface is one of the most common and well understood healthcare application interface challenges. By applying these tips, you will be off to a good start on the road to a successful implementation of the HL7 PMI interface.