Using HL7 for more than just Integration

When I first started in medical integration I realized that when our vendor quoted us for a new integration suite that an HL7 ADT feed was included each and every time.   I thought that was odd as this same vendor had already provided us with two individual ADT streams (one in V2.2,  and the other in V2.4).   When I asked it was explained that each receiving system required its own ADT feed.   Naturally this is the case when dealing with several different systems,  but modern Integration Engines eliminate the need for redundant feeds from your HIS (Hospital Information System),  or EHR (Electronic Health Record).
Over the years whenever we implemented a project that required an ADT feed we used our Mirth Integration Engine to send a copy of an existing feed to the new interface.   Mirth allows us to do any customization or filtering for each system so in the end we save ourselves tons of money in purchasing and maintaining seperate ADT feeds from our HIS.

This is a pretty simple example of what I want to talk about in this entry.  With the right Integration Engine,  and enough data in your HL7 message you can easily use existing feeds as a unique and robust solution to day to day issues that come up.   Here are some of the things we’ve done at the Huron Perth Healthcare Alliance.

Enhanced Data Analysis and Reporting
At one point we were having a problem with guarantors not being properly associated in our HIS.   This was causing our analysts fits as they would have to spend hours trying to track down potential mis-matches.
Mirth’s versatility and powerful javascripting abilities allowed us to implement an interface that would watch our main ADT feed and an analysis on every message.   Business rules were drawn up to identify a potential mis-match and,  if a message met those parameters the patient details would be written into a database.     Every night just after midnight,  another Mirth channel would trigger,   read the database and email the analyst a list of potential problem accounts  reducing workload and catching potential problems before they became problems.
This functionality can be easily adapated to watch for any records meeting certain business rules.

Custom Data Repository
We needed a way for several applications (including Mirth) to be able to pull certain information from our HIS.   The problem is that our HIS doesn’t allow direct queries.   We were faced with writing a script to pull this information periodically,  thereby limiting our ability to pull real time data and adding a level of complexity to the solution,   or,  we could write everything to a database and use SQL to pull the information.
Again,  we used existing HL7 feeds from our HIS to populate and update a lighweight data repository.   This gave us real-time information in an easy to query format simplifying our reporting tasks and allowing us to provide better data to the users.

Downtime Reporting
Anyone working in healthcare has come to dread what happens when the HIS is unavailable for any reason.  Of course,  in an electronic environment this means that vital patient info is not available.
Again,  using the Mirth Integration Engine and an existing HL7 results feed that gives us every test result and dictated note entered into the system we devised a solution.   Every report is converted into a human readable PDF.   This PDF is then picked up by another Mirth channel which determines what nursing unit the patient report belongs to and will write it o a folder on a PC on that floor.   This way the patient information is available to staff on the floor in the event of an HIS or network downtime.
Phase 2 of this project will involve moving patient records to another floor upon receipt of a patient transfer message,  or removing them if a patient discharge message is received.

These are just a few of the many functions a powerful integration engine such as Mirth will allow facilities to enhance the utility of HL7 messages coming from their systems.