HL7 It is a health data communication standard. HL7 version 2 covers the exchange of patient demographic data (also known as Patient Master Index or PMI). HL7 V2 also covers other types of data, such as intake details, schedules, 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 similar but not exactly matching interfaces that require analysis to identify the differences.

2. Translation of HL7 messages

Once differences have been identified, one application’s messages must be modified before they can be processed by the other application. Some translations can be relatively simple, like 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 in a proprietary segment.

It is also common that fields need to be moved based on business rules. Fortunately, specialized software called interface engines are quite 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 encrypted 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 come a long way in addressing this problem. Still, most likely 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 revisions of HL7 (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 PID-3.

If the scope of the interface is more than one hospital, then the MRN for one facility is distinguished from MRNs for other facilities by a facility code (passed as a subcomponent of the PID-3 field). The installation code may need to be mapped (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 the patients at a single facility. A typical example is a stand-alone application (but with HL7 interface), such as a clinical ICU application. If the ICU system only manages patients from one hospital, you will only want HL7 messages for patients in that hospital. You may even only want HL7 messages for ICU patients. Interface engines are good at filtering, routing, and translating the messages necessary to make this happen.

5. Repeated fields

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

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

6. Repetitive segments

Repeating segments such as ‘Next of kin’ (NK1) and alerts/allergies (AL1/IAM) pose similar challenges as 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 only support 2.
• The shipping system can add, update, or remove the repeating field. Removing a field can cause headaches for the downstream system. Sometimes this is overcome by the downstream system that replaces the entire 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 have been 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 on 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 have a good start on the road to a successful implementation of the HL7 PMI interface.