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.
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.
