In the first post of our Mirth Connect Series, we gave a brief introduction of Mirth and its architecture. As promised, we are back with another post on Mirth Connect to show how we integrated Epic EHR with a lab system using Mirth Connect.

EHRs are an important part of healthcare ecosystem but their integration with insurance, billing labs, and other EHRs still remains a challenge. Although there have been numerous technology solutions over the years to tackle the integration challenges but no one-stop solution like Mirth which seamlessly listens, validates, transforms, routes and manages to create a robust and scalable integration channels.

Recently we worked with one of our customers to integrate their Epic EHR installation to an in-house lab information system(LIS). Their current process was manual and cumbersome. A complete pathology workflows would take days to complete. Although, they had built an integration solution but it was not as effective as they anticipated since their internal  IT team had limited exposure on both Epic as well as custom built LIS.

Considering Epic is based on Mumps, we had limited options to get data directly from Epic. It is quite easy to turn on HL7 data hose as Epic has a strong support for HL7 exports.

Let us take a look at how we integrated Epic with Mirth to create a faster, easier, secure, and effective system to integrate Epic with a custom LIS.

Extracting Data from Epic

Since Epic takes care of the message generation, all we needed was a listener to accept the messages and normalize to build a format which LIS would accept. Here is how to create a simple TCP listener channel in Mirth

Steps to define TCP settings on the Source tab:

1. Connector Type- Select TCP Listener
2. Listener Settings – Select All interfaces and add port to Local port.
3. Listener Settings – Specify a TCP/IP Port Number make sure that this port must not conflict with any other ports in use by Mirth or any other software running on the machine.
4. TCP Listener Settings – Select MLLP in Transmission Mode:
5. Once you are done save, enable and deploy the channel

After defining these settings our channel was ready to pull data from Epic, and we were able to pull data successfully.

De-Identifying HL7 data

The Customer had a specific requirement to not transfer any PHI to LIS. They maintain a universal patient index and multiple patient identities in various applications were linked with this Universal Patient ID. This could be easily handled at the
Mirth level with a simple transformer or another chained Mirth channel. We opted for another channel as there were some specific requirements to preprocess the message before it gets routed to LIS.

Lab application workflow:

Although data insertion to their LIS was straightforward but customer’s LIS had a specific workflow implementation around provider and patient notifications e.g. any entry to LIS interface via the frontend would:

• Flag the lab record if any abnormality.
• Generate a notification for the provider on abnormality as well as lab results availability.
• Generate a notification for the patient on lab results availability.

To flag the lab record if lab results are out of range, we had to build out a rules repository. Every lab result was put through a range check and marked normal or abnormal based on range check results. For the notification, we interfaced with their notification API directly from Mirth to generate provider and patient notification as each record got processed and saved.

We were able to get the interface live within 2 months time, which would not have been possible, hadn’t it been for the infrastructure provided by Mirth. This is just an example that when it comes to creating cost-effective implementation of business rules and workflows,  no one does it better than Mirth.

Need any assistance on Mirth? Get in touch we would love to help!