HL7 PMI – 7 Implementation Tips

HL7 is a health data communication standard. HL7 version 2 covers the exchange of patient demographics (otherwise known as Patient Master 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 the HL7 V2 standard is interpreted in different ways by implementers and software developers. The outcome is two similar but not exactly matching interfaces that require analysis in order to identify the differences.

2. Translation of HL7 messages

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

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

It is also common that fields may be needed to be moved based on business rules. Fortunately specialist software called interface engines are quire good at this task. For example the iCan Integrator software from Sun Microsystems (formally Seebeyond) provides this kind of functionality.

3.Code table mismatching

HL7 messages are littered with coded data. For example the martial status field contains a coded value such as ‘M’ for Married, ‘D’ for divorced and so on. However the receiving system may expect ‘1’ for married and ‘2’ for divorced. National standards have gone a long way to address this issue. Still, the odds are that one or more fields in your PMI message will 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. PID-2 Patient ID (external ID), PID-3 Patient ID (internal ID) and PID-4 Alternative Patient ID. 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 are distinguished from MRNs for other facilities by a facility code (passed as a subcomponent of the PID-3 field). The facility code may need mapping (see Tip 2!).

In another twist, the sending system may handle multiple hospitals (e.g. a patient administration system covering several hospitals) but the receiving system may only want to know about patients from just one facility. A typical example is a independent (but HL7 interfaced) applications such as an ICU clinical application. If the ICU system only manages patients from one hospital, it will only want HL7 messages for patients at that hospital. It may even only want HL7 messages for patients admitted to the ICU. Interface engines are good at the filtering, routing and translating of messages require to make this happen.

5.Repeating fields

Fields that repeat, such as the address field (PID-11) may also cause problems. The challenges include

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

6.Repeating segments

Segments that repeat, such as ‘Next of Kin’ (NK1) and alerts/allergies (AL1/IAM) pose similar challenges to repeating fields.

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

7.Shared fields

It is not unusual that the fields interfaced from the sending system can also be modified in the receiving system. Basically if the receiving system was not interfaced, then all of the information would need to have been duplicated by manually typing into the application. Unless the capability to edit data fields covered by the HL7 interface is ‘removed’ from the receiving system, changes made to the data (e.g. adding or changing an allergy, deleting a patient contact) by users in the receiving system, may be list with the next HL7 message received, process and stored for that patient.

Fortunately persistent and diligent interface analysis can overcome these and other challenges. HL7 PMI interfacing is one of the most common and best understood health application interfacing challenges. By applying these tips you will have made a good start along the road to a successful HL7 PMI interface implementation.