So here is the story, with a not-so-agile ending, but effective solution. Our EKG system is robust enough to send out various formats of the resulting EKG embedded in an HL7 segment. Depending on your dip switches, this can be TIFF, postscript, and more notably, PDF. This is all good, because the customer wants them into the EMR, which supports multiple ways to do this, however getting the pdf out of the message is the kung fu integration staff may sometimes have to deal with.

Goal: Receive Message from EKG system, and place resulting PDF on a remote filesystem with the name, fin, mrn of the patient as its filename. This sub-intellectual blathering on the interwebs outlines: - how I stripped the pdf from the HL7 message - how I used my own custom java class in Mirth. - how Mirth and iText saved the day for the second time in the solution. Mandantory Screencast Freshly Brewed Java Strip/Encode Class Convert a PDF Version using Mirth Channel

If you are still hanging in there, here is the process flow:
- EKG system sends out HL7 Message with PDF embedded.
- Mirth, takes the inbound message, grabs 3 variables from the message and passes the UUENCODED (I know, Base64 would have been elegant) segment to a java class for appropriation as a file. Mirth then ftp’s the file to a remote filesystem.

For starters, lets take a look a the Message from Mike Litherland’s HL7 Browser. The Name, FIN, MRN of the patient (and the requirement) are easy and quite frankly are no fun at all. The Good, Bad, and the Ugly exist in the not so popular ZPD segment as in the screenshot below.

If you take a closer look at this segment you will notice that its telling you what kind of file it is PDF (ZPD2.1), some integrity checks on the size of the file in (ZPD3.1, ZPD3.2), and the “meat” of our solutions exists in ZPD3.3. So check it, by looking at it, its UUencoded. This really sucks, but is not a big deal, and gives us the opportunity to flex some of Mirth’s ability to include some custom stuff and also to flex some java foo. Im going to note here that I actually think Mirth can do this nowadays, and I can recall also Brendan Haverlock showing me some Mirth utils in the form of:

importPackage(Packages.com.webreach.mirth.util);
Entities.getInstance().encode("String");
Entities.getInstance().decode("String");

But im NOT using this here, I whooped up a Java Class StripDecode, with two methods Strip/Decode, the first method will escape all the HL7 escape chars from the segment, the second method Decode, Decodes it and write it to a target file name. I uploaded it to the ‘lib\custom’ folder on Mirth and was able to access it in the channel transformer via javascript.

Here is the Java Class.

And below is a screenshot to the javascript that includes the Java Class:



Ok, pretty sweet, we are now writing the extracted pdf’s to the local filesystem on Mirth, we compliment the channel with another channel that reads the files and ftp’s them to a remote server which ends up in the specified target location.

But, HOUSTON WE HAVE A PROBLEM.

After all the hackery, it ends up that the EMR has having issues with our PDF version(1.0) we are writing out. Its not our fault, its the pdf version that is all encoded up in the segment. We need at least a 1.2, so what to do now?

Chris Bonis and I googled it about and ended up at the iText site. Cool, maybe we can include it and do some conversions? Better yet, Mirth had iText already included in the libraries, all we had to do was call it and BAM! We were writing out 1.4’s from our Adobe 1.0’s using the Stamp method. We seriously read it in, and write it out.

Isn’t that just awesome?



Special thanks to Jeff Peters, and Chris Lang at WebReach Inc for the opportunity to hack on some Mirth appliances!