[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] On using Mirth (in place of coding every import insid

From: Jim Busser
Subject: Re: [Gnumed-devel] On using Mirth (in place of coding every import inside of an EMR)
Date: Tue, 20 Oct 2009 13:09:41 -0700

On 2009-10-20, at 12:51 PM, Karsten Hilbert wrote:

+1   That's the problem with HL7. And that's why I favor Mirth.

when the author of that post wrote "HOWEVER Mirth really shines if you don't have anything being pushed to your doorstep" the case was made in a solution in which he had enlisted the co-operation of the hospital to "print" their character reports to PDF and then make those available which were then transformed using cron jobs as described below and refactored in an HL7 wrapper for processing by Mirth... shows nicely what can be done for "legacy hospital systems".

If the author needs contacting, I can serve as intermediary.


It took us 5 years of talking about connecting the hospital system to
the clinic to do it, and finally it boiled down to money (neither side
wanted to spend any, and in particular spend on the $n00,000 '"custom"
solution' that the hospital information system vendor was willing to
implement).  Once we realised that was the only serious hangup we had
a rapid acceptance of open source approach with a100K dollop of
_javascript_ to make it hum...


You will note that the response is quite techy and for it to work for
you the implementation person(s) will require
1) some knowledge of Mirth (fairly easy)
2) a good knowledge of _javascript_ and regular expressions to parse the input
3) a thorough understanding of HL7 messaging
4) some understanding of how to set up the mule transport that [the EMR]
uses to suck up Hl7 (fairly easy)
5) significant time to tune to your particular output formats
I can help with the first 4


This is how to transfer any hospital system report that has enough
written on it to identify the patient and the doctor to import to [the EMR]
 via its Lab function, or any other EMR that handles HL7.  The
how to is written assuming the hospital system is on Windows(R),
however some of these steps may be even easier if it is Linux or Unix.

all software is open source unless identified as not

Step 1. Have the hospital set up a pdf printer
dead easy on a Linux system
for windows not hard pdfcreator run as a service
we use PDFcreator currently 0.9.7
set to automatically time stamp the file and deliver into C:\HL7
Step 2. Print hospital reports to pdf as well as the regular paper
jobbie (for now)
Step 3. Strip out the text out of the pdf
for windows I use
its free but closed source
Step 4. run a cron job to run your script
the script will stuff the text into a HL7 "wrapper" but first you need
to remove the line feeds as this is not tolerated in HL7
in windows
Taskmanager runs C:\HL7\pdf2txt2hl7.bat hourly which in turn
a) copies all pdfs to c:\HL7\temp for processing
b) uses Text Miner to extract the ASCII from the pdf currently 1.1.42
c) uses TR to tokenize carriage returns and clean up some characters
it a port of the unix tool
d) prepends and appends start.bnk and end.bnk - a nominal HL7 wrapper
for the text
e) moves the pdf's to processed and the HL7 to C:\HL7

ECHO. PDF2TXT2HL7.BAT 2009 (C) Peter H-C
IF NOT (%1)==(/?) GOTO :START
ECHO.::  This batch file extracts text from hospital pdf     ::
ECHO.::  and preprocesses it removing illegal characters     ::
ECHO.::  and carriage return line feeds <CR><LF>             ::
ECHO.::  And then wraps it in a HL7 ish wrapper for Mirth    ::
ECHO. usage
ECHO.      /? gives this text



REM temporarily add path to GNUwin32 toolset and Text_Mining
PATH=%PATH%;"C:\Program Files (x86)\GnuWin32\bin";C:\Text_Mining;

COPY *.pdf C:\HL7\Testing\
MOVE *.pdf C:\HL7\temp\
CD C:\HL7\temp

for %%I in (*.pdf) do minetext "%%I" "%%~nI.tx1

REM remove ’ from the text with tr first by stripping the first
for %%I in (*.tx1) do tr -d '\342\200' < "%%I" > "%%~nI.tx2

REM remove ’ from the text with tr second converting
for %%I in (*.tx2) do tr '\231' '\047' < "%%I" > "%%~nI.tx3

REM remove <CR><LF> and <LF> from the text with tr
for %%I in (*.tx3) do tr '[\r\n]' '[%%%%]' < "%%I" > "%%~nI.tx4"

REM copy pdf to processed
MOVE *.pdf C:\HL7\processed\

REM append the prototype files to form a validish HL7 with placeholders
for %%I in (*.tx4) do copy start.bnk /B + "%%I" /B + end.bnk /B "%%~nI.HL7"

MOVE *.HL7 C:\HL7\

REM Test for exact ERRORLEVEL 0
ECHO. *********************************
ECHO. ***Failure***Failure***Failure***
ECHO. *********************************

REM insert delay of 1 hour
ECHO. Control C to quit
ping -n 3500 > NUL


REM And if good then can cleanup files
del *.tx?
del *.pdf


Step 5. Install Mirth (open source multiplatform) at the hospital end
This, once they realise what it is, becomes very interesting for the
hospital IT people as they will find all sorts of uses for it as they
struggle with HL7 transport for their own internal purposes
I use Mirth currently with Sun Java 1.6.0_11
it transforms the HL7 by using _javascript_ RegEx to strip out data from
the text to populate the HL7 fields and routes the fully formed HL7
messages as appropriate to
a) me by email for blank pdf's and unassigned reports (DR.DOCTOR)
c) the [local] clinic by unencrypted low level protocol via SSH
tunnel to another Mirth instance

Step 6. Install Mirth on the clinic end
We use Mirth to channel the output to an unused Mule HL7 input on the
[EMR] end, in our case as "CML" input

the _javascript_ invoked by Mirth on both ends (hospital and clinic) are
saved as XML configurations, a bit obtuse to list plain text but I
attach for your pleasure.  The LLP to Peter sits on the hospital Mirth
instance and the LLP from Hospital to file sits on our clinic server
which drops files into a file directory that is configured to import
CML type HL7

reply via email to

[Prev in Thread] Current Thread [Next in Thread]