Interfacing Challenge: Patient Data Matching with HL7 Messages

More independent reference laboratories and imaging centers are connecting to their referring community of physicians by creating interfaces between their Laboratory Information System (LIS), Radiology Information System (RIS), and the physician’s Electronic Medical Record (EMR) system.

In their efforts to create a seamless process of transmitting electronic results, they typically find challenges in various aspects of interfacing. One example of the issues that arise is the requirement by the EMR to match on specific patient information. This requirement translates to a lab or diagnostic imaging center that they must include specific information, as identified by the EMR, within the HL7 result message (ORU) to send the reports electronically.

As with any interface, the issues and solutions vary depending on many factors. The following example documents one healthcare integration scenario including the patient data matching challenge and the corresponding resolution.

Problem:

• One of ABC Reference Lab’s clients uses an EMR application that requires the exact ordering physician name in addition to the patient demographics and order information to match the result message with the patient record.
• The orders are sent electronically from the EMR via an HL7 TCP/IP interface to the laboratory in near real-time.
• When the order message (ORM) is accepted by the LIS, the LIS files the referring physician from PV1-8 as the accession level ordering physician. The original ordering physician name in OBR-16, which could potentially be different, is not filed. Therefore, when the result message (ORU) is ready to be sent back to the client EMR system, the ordering physician in the OBR segment is often times empty or incorrect.
• The client EMR system does not accept the results because the ordering physician does not match for the specific order. Consequently, the patient record is never updated with the results electronically.
• The only way to get the results into the EMR system is with manual entry.

Obviously, due to the volume of lab test results at this clinic, the manual data entry from faxed lab reports was unacceptable. The laboratory’s healthcare integration team was tasked with how to resolve this issue because the LIS and the EMR vendors were both unable to modify their applications to accommodate any changes.

Solution:

• The lab interface team utilized an interface engine to help resolve the issue.
• The interface engine was used to store patient info in a database as the order messages were routed to the lab.
• As the outbound results were processed from the LIS to the EMR, the interface engine was utilized to query the database, find the matching patient and order, and replace OBR-16 with the original ordering physician’s name.

How did the interface engine serve as a mediator between the EMR and the LIS?

1. The interface engine took apart or parsed the ORM messages received from the EMR system.
2. The data from the parsed messages was put into an Access database designed by the interface team to be queried later.
3. When the interface engine received the result from LIS,it performed a patient/order matching algorithm against the Access database.
4. When a match was found, the interface engine would retrieve the ordering physician name as it was originally sent and replace OBR-16 in the ORU message with the name.
5. The same processing was applied to all result types: preliminary, final, and corrected results.

Details of the matching algorithm:

• Patient data matching was only invoked if the ORU message was to be routed to the client or clinic with the EMR in question. The condition evaluated the client code the LIS sent in the PV1-3 field, Assigned Patient Location.
• Due to the variability of data in the tables, multiple algorithms were created and utilized to ensure a correct match.
• Three algorithms were applied in the following priority order until a patient and order match was found:
  • Patient ID, Patient Last Name, Patient First Name, Patient Date of Birth (DOB), and Order Codes.
  • Patient SSN, Patient Last Name, Patient First Name, Patient Date of Birth (DOB), and Order Codes.
  • Patient Last Name, Patient First Name, Patient Date of Birth (DOB), Requisition Number and Order Codes.
  • In the rare case of a no patient match due to manual order entry, a safety net was implemented to error out the result message for manual correction and reprocessing.

In the end, the solution allowed the lab to secure additional clients by being able to accommodate for the unique interfacing need. The interface engine gave the lab the flexibility and the power to incorporate a creative solution for the patient matching challenge in this EMR interface.