Patient Data Matching with HL7 Messages

January 26th, 2007 by Sonal Patel

7 Votes | Average: 4.71 out of 5 (7 votes, average: 4.71 out of 5)

Loading ...

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?

The interface engine took apart or parsed the ORM messages received from the EMR system.
The data from the parsed messages was put into an Access database designed by the interface team to be queried later.
When the interface engine received the result from LIS, it performed a patient/order matching algorithm against the Access database.
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.
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:
1. Patient ID, Patient Last Name, Patient First Name, Patient Date of Birth (DOB), and Order Codes.
2. Patient SSN, Patient Last Name, Patient First Name, Patient Date of Birth (DOB), and Order Codes.
3. 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.

Last 5 posts by Sonal Patel

The Benefits of Improving Your Healthcare Billing Operations - January 8th, 2008
HL7 Messages in Healthcare Billing Environments - January 4th, 2008
Radiology Workflow - Integrated - December 20th, 2007
Placer Order Number vs. Filler Order Number - September 28th, 2007
HL7 Separator Characters - September 24th, 2007

5 Responses to “Patient Data Matching with HL7 Messages”

Arthur Schwartz says:

I am an integration analyst at a healthcare system in the Tampa, FL area. We also are trying to do something similar with orders and results to doctor’s offices. Our issue is that our lab system can not store the doctor’s patient identifier so the result is sent back without it. This creates problems in the doctor’s office matching results to the correct patient and/or order.

If we could store the order # and patient identifier from the inbound order on a database and match the result to the order we could plug in the patient/order number and make the match on the doctor’s side much easier.

I have some questions: What interface engine was used? How and where is the matching done in the engine? Within the database?
Sonal Patel says:

Thank you for your comment. As you indicated, your interfacing dilemma is extremely similar to this blog. To answer your question, the interface engine used to solve this issue is NeoIntegrate. NeoIntegrate allows for easy connectivity to most any database. The logic for patient matching can be done in the engine or the engine can call stored procedures that perform some of the functionality.
David says:

I was looking on the web for something regarding a query and I came upon this blog and thought I would add my 2 cents. The solution that they give certainly is a unique one but so many questions come up, what do you do if the query is down?, doesn’t this clog up the responses?, what’s the response time of the query?, Do you hold back results if the query is down? what do you do with STAT results and something is not connected? etc……….

Since you had an engine did you ever consider massaging some piece of data which you know is returned to you just as you sent it? I would have looked at having the engine massage perhaps the accession number element and embed within that PID.18 and physician code if you used fixed lengths you’d be able to parse that back out in the result and plug it back into the appropriate PID and OBR elements. (I’m assuming you are using a doctor code and not the doc name as you stated otherwise you’d have a problem with multiple doc’s that have the same name)
Sonal Patel says:

Thank you for your comments. Your insight seems to speak from experience. Let me try to address each question with regards to this specific solution.

What do you do if the query is down? Doesn’t this clog up the responses?
The technology or interface engine used in the solution has solid database connectivity. We have a significant number of OEM or independent software vendors who use our product as their interface module.

The architecture of the engine allows for repeated attempts to connect to the database. If for any reason that the connection cannot be established, proactive alerts can be configured to notify the needed personnel. Overall, the responses get only as clogged up as it would if a connection went down.

What’s the response time of the query?
Query response can be measured in milliseconds.

Do you hold back results if the query is down?
There are two potential meanings to your question:
1) What if the query is unsuccessful where there is no match found? The results would be processed through logic in the engine for a default method of completing the record and passing the message to the EMR.
2) What if the database connectivity is down? In these cases, the message being processed would error and, in turn, an alert would fire to notify the appropriate personnel. Once the database is up again, the message can be reprocessed.

What do you do with STAT results and something is not connected?
- For the lack of a query response, the engine can be configured to handle STAT messages in a special way as long as there is something in the message to identify it as STAT.
- For a database down situation, the process would probably be the same.
- If your connection is down, NeoIntegrate could send an alert to the key operator to troubleshoot the issue for correction and until connected, the message would not be transmitted.

Did you ever consider massaging some piece of data which you know is returned to you just as you sent it?
As you know there are multiple possible solutions. You are absolutely correct in attempting to use this methodology as it would eliminate another potential point of failure. We also evaluated this option first, because concatenating and stripping data are easy tasks within an engine. We chose the database option after exhausting all other options.

Dr. code vs name?
For the purpose of this blog, I tried to document one specific aspect. The actual scenario experienced by our client was much broader including involving both the physician code and the name. The LIS was throwing away the code and truncating the name. We could not append these items to any other field that would be returned; therefore, the resulting problem was getting both pieces correct on the outbound.

Since this issue was related to one specific EMR utilized at one clinic, we confirmed unique doctor names at that facility.
Jonathan Hunter says:

We are working on an order entry interface from our client offices to our LIS. The main problem with the interface is that due to limitations in our LIS, everytime a patient is created from a client and the order is placed a new patient is created. If a patient goes to 2 separate clinics, then 2 patient records are created in our LIS for the same person. Our LIS only checks to match the patient ID on the client side with the patient name.

Is there any solution out there that can help match incoming patient information with patients already in the database?