Doing EHR data conversions (hl7) with the power of Open Source.

Recently, I was tasked with doing some data conversions from legacy systems to Epic. The client I was working for; had been saving results/transcriptions from various different applications (Sunquest, Medilinks, Provation, Excelera, GE RIS, SoftMed) and wanted them loaded in Epic. Above this, they also wanted to do a demographic load and an account load (or visit load) ahead of loading results/transcriptions to make sure all clinical data gets tied back to historical encounters. Most of the data was saved as hl7 flat files by the interface engine and needed to be heavily modified and loaded in Epic through Bridges.

When I was told to bring in the data to Epic, I decided to use MirthConnect (an excellent Open Source Interface Engine). Setting up MirthConnect was very painless. I decided to use the default database (derby) to store the messages as they go in and out of MirthConnect. To start off the conversion process, I created a few channels and a file based architecture that allowed me to queue up flat files, archive them off once processed and a place to save the errors should anything not translate correctly.


Alot of concepts for hl7 transformations that MirthConnect has are similar to Lawson Cloverleaf. You have a place to put a filter on what goes through a channel (or thread); you have a place to define multiple destinations for  messages and the biggest of all, the Transformer (or Xlate/Cloverleaf term) which allows to modify messages. It was pretty simple and straight forward to setup primitive rules and default certain values (for example, PID-3.5=IIT 620, etc). Setting up some complex rules do require the knowledge of JavaScript. One of the transformations I had to do was convert ORU to MDM. To get this done, I had add a TXA segment right after PV1 and also remove the OBR segment from going out of MirthConnect. For adding segments to a message, the syntax is as simple as ...


- createSegmentAfter('TXA', msg['PV1']);


... and here is how you delete segments from a message


- delete msg['OBR'];


Simple?!?


Once I had the messages translated appropriately, it was time to do some Epic Chronicles searches to map out the procedures (OBR-4.1 = EAP records) as well as some transcription types (TXA-2.1 = I EPT 19104). MirthConnect does offer a way to define mappings for a particular field, but to get information in and out is a major chore and when you have > 100 mappings to enter, it becomes a pretty tedious job. To work around this, I used Epic Identity where possible, but ultimately also had to use a SQLite database on the MirthConnect side to do some translations for me.


Overall, the conversions went very well and I was very pleased with the results. Between MirthConnect and Epic Bridges, I was able to get everything filed correctly and with no errors. 


In terms of ROI, here is what I saw my client benefit from,
- No added burden on my client's interface engine analysts (They had 0 involvement in this process)
- Complete control over how things are displayed in Epic
- Epic Bridges errors were next to none. I think for 2.4 million records loaded for ADT and account load, we had about 600 errors.
- End users were very satisfaction was very high with the end result.


I will be doing another conversion pretty soon and this time around, I will be using Cloverleaf instead of MirthConnect. I am hoping to capitalize my experience of MirthConnect and using similar ideology when running the conversions.

Integrating Epic with SureScripts/RxHub

Since my last blog about MUSE/Epic integration, I have done a number of interfaces that I will be blogging about. The first one that I did like to talk about is Epic with SureScripts/RxHub; or some people might simply call this as enabling their CPOE with ePrescribing. I was part of a 4-person team on the west coast who went live with this integration. Much of this was done in getting in compliance with the CMS ruling of making sure all prescriptions are sent electronically vs. print or fax. (There is more to this ruling but I will keep it simple as my audience is primarily technical.)

The integration from an Epic standpoint involves the following interfaces

• Orders to SureScripts – This interface will be responsible for communicating all prescriptions to SureScripts network
• Provider add/updates to SureScripts – This interface does two things; (1) As a new provider is added at the medical care facility, he/she is automatically communicated to SureScripts (2) If a provider is updated (name, practice address), he/she is automatically communicated to SureScripts
• Pharmacy downloads from SureScripts – This will download all pharmacies from SureScripts and update the Epic database (specifically the PHR masterfile)
• Refills requests from SureScripts (as part of my project, we never went live with this)
• 270/271 RxHub eligibility request interfaces – This will be responsible for getting mail order benefits for a given patient
• RxHub medication history request/response interface – If the patient is found to have mail order benefits, he/she is then queried to determine if there are is any medication history available. (Do not worry, any history found is not downloaded directly to the patient record (EPT record), but is actually stored in a holding tank (DXR record))
• Orders to RxHub – This sends mail orders to RxHub
• Provider add/updates to RxHub – This is almost the same as SureScripts that is mentioned above
• Formulary, Coverage’s and Medication alternative downloads from RxHub – This interface download a few gigs of data from RxHub that was then tediously (did I say painfully) imported into Epic. The main masterfiles that are impacted are LCA, LCO, LMA, ALT

From a technical standpoint the information goes out of Epic via an intermediately server that is often known as Interconnect. Cache and Interconnect talk to each other via generic queues (ICOSYNC and ICOASYNC). This communication layer is very much proprietary to Epic. The Interconnect server has SSL certificates installed that enables it to be a trusted source for SureScripts/RxHub. Not only this, but SureScripts/RxHub will only accept connections from trusted IP addresses, and for this purpose the Interconnect server IP address needs to be communicated to them.

From a business sense, this was a bit of challenge. Some of the challenges that I noticed were

• Physicians were initially skeptical of using ePrescribing. The fact that for many years prescriptions have been faxed to pharmacies, or hand-written played a role in this. However, once they started to use it and noticed the low error rate, they gained confidence in the system.
• Sending mail orders to RxHub seemed picky or so we thought initially that was the case. Apparently, RxHub will return benefits for all PBM’s (Pharmacy Benefit Managers), however; they will only accept mail order prescriptions that are routed to PBM’s that have a mail order pharmacy defined. It was hard to understand which PBM’s had mail order pharmacy vs which one didn’t. The solution to this was that we turned off all PBM’s that did not have a mail order pharmacy defined. This resulted in lesser confidence in relying on patient mail order benefits., but nonetheless this feature continues to improve with time.
• Since SureScripts is really now the owner of your PHR masterfile (only for external pharmacies), any updates made to any PHR record are now over-written by SureScripts. Hence, if you want to change a phone /fax number, or address, you need to open a request with SureScripts to do that.
• Provider records that need to be communicated to SureScripts are now really picky. You cannot miss a provider address, phone number, fax number in their SER records.

Those were pretty much the highlight issues that came, there are definitely things that Epic and SureScirpts can improve, and I am hopeful they will improve the integration with time. At this time, this is a very much do-able implementation with a few kinks here and there. As always, please do not hesitate to leave me a comment if you have any questions.

Having issues with adding values in drop down when adding options via AJAX in IE only?

Well, in my case this happened because IE and FF/Safari/Chrome treat the option object's constructor [option(arguement-1)] differently.
IE's interpretation = The name of the option is what was passed in arguement-1. The value is null.
FF/Safari/Chrome interpretation = The name of the option is what was in arguement-1. The value is also arguument-1.
So, make sure you pay special attention to this. Since IE does not set the value if 2nd parameter is not passed in, make sure to pass it! It can save you hours!

Windows mobile marketplace main memory filled?

I started using Windows Mobile Marketplace about a month ago on my HTC diamond phone. Initially, I thought ... *finally* an app store from Microsoft, awesome! .. but it didn't take me long till I filled my main memory. I figured no problem, I will just tell the cool-tiny-little Marketplace app to install it on my internal storage.

Oh no .. there is no such option. Once again, I fail to understand why Microsoft leaves stuff in a limbo ...

• Was it too hard to give some configuration options?
• What purpose did it serve to lock down a user to only allow him/her to install on main memory?

These are questions that sadly will never be answered from Microsoft even though, they have read them again and again on numerous forums online. Alas! the world of Microsoft.

However, fear no evil, there are a couple options to retro this scenario ...

• Our friends at XDA have developed a hack that will allow you to install applications on the internal storage card
• The other option is to use Pocket Mechanic that will allow you to move applications from one place to other.
  

Integerating Muse (GE) and Epic EMR (Epic Systems)

Although, I am roughly about six months late in posting this article, but I wanted to talk about my experience with integrating Muse and Epic EMR together with an ADT, Orders and Results interfaces.

Overall, I was really pleased with the overall improvement in ROI that was observed with the integrating these two applications. Some key elements are

• Availability of ECG exams in one centralized place for all inpatient/outpatient medical providers
• Excellent automatic ECG result notification for individual outpatient medical providers.
• Complete history of preliminary, final and edited results in the primary EMR application.
• Viewing of complete ECG strips on a single click of a button.
  

From a technical standpoint, following is the list of items that were performed,

• Configure order transmittal (Epic component) to send ECG orders to an HL7 outbound interface.
• Design/build mapping documents for ORM/O01 and ORU/R01 messages between Epic and MUSE. The Epic interfaces that were used were the generic outbound 'orders interface' and inbound 'radiology results' interface into Epic. (The inbound radiology results interface is capable of handling both ORM and ORU messages)
• Since the MUSE web server which hosted the EKG strips in a PDF format, was protected under the standard IIS basic authentication security model, we had to write a small wrapper script that would allow automated logins when the EKG strip links were clicked in Epic EMR.
• Epic EMR in basket routing was adjusted per organizations clinical care settings.

Overall, it was a great project and the end result was absolutely an improvement in patient care.

Implementing a Paceart HL7 results interface to Epic

Okay, this post has nothing to do with the Medtronic recall that just occurred, but with all honesty, the paceart application that Medtronic offers, sucks. Yep, Sorry, but it really does. In trying to integrate the paceart application with Epic, it was really sad and unfortunate to see the limitations that paceart has in place with the way they have implemented their interfaces, but not only this, the highly unhelpful staff they provided us for support purposes, sucked as much.

Here are some things that I think Medtronic needs to accommodate in order for their application to succeed

- Provide an accession number that is unique per study, and will remain the same even if the study is edited/deleted/merged, etc.
- Accept critical fields like an external systems account number/accession number
- Accommodate more characters for provider numbers
- Accept a real-time orders interface, this means the ability to handle O01, O02 messages
- Fix the abnormal results message that consists of multiple OBR segments, even though, they are part of the same order

That is at the least they should provide along with better support so that HIT folks can successfully integrate EMRs with paceart.

Interface Talker (Java program)

1. Basic functionalty
1. Manage communication on multiple ports. Communication can be incoming or outgoing.
2. Means to create log files of all communication that gets carried over different ports.
3. Ability to add/remove/configure ports/message types/activities.
2. GUI
   
1. Each communication should have its own tab.