[Gnumed-devel] On using Mirth (in place of coding every import inside of an EMR)

[Jim Busser]

A Canadian doctor on another list, who sees Mirth's value, was asked  
the following which spawned a thread:

	"why use Mirth, instead of coding the various imports inside of an  
EMR?"

which which I extracted:

It is true that if you have a gateway dumping HL7 at your feet, then
writing a custom channel in the EMR will suffice and you can skip Mirth.
This may be what you want to do where EMRs can have Mule working
to pull results. Writing and debugging the channel will take the same
amount of programming time and effort (ie cost) in Mirth or an EMR.
However Mirth has its advantages.

Having Mirth on the receiving end is more robust as the Mirth system
is full featured and will generate ACK files as handshakes indicating
that the message got through, log comprehensively, email results or
errors, launch other programs etc etc.  Much as people may like their
EMRs, one can *really* like Mirth as its the Swiss army knife of HL7.

Having Mirth (or something else) preprocess makes debugging a
production system easier.  You simply divert the test output stream
and check it without upsetting what half works.  It also stores the
messages internally so if you flubbed the last run, just reprocess the
messages the new way without any bugs.... promise, this time for sure.

Mirth also is easier if you have multiple input streams.  Where you may
have a hospital system AND a particularly obscure lab system to
connect to, neither of which your EMR (nor competing local EMRs)
likely to take natively, it is easier to write them both to a common
standard and then funnel to your EMR.

HOWEVER Mirth really shines if you don't have anything being pushed to
your doorstep.  It's prepackaged and easy to deploy on the hospital
end, and then you have your choice of how to deal with the rest.
Mirth to Mirth is easy as pie.

It handles SOAP LLP SFTP SMPT or it can write directly into your
database if you want,

Mirth also shines if you are interested in being able to push to
various EMR's. Yes Virginia there are other EMR's out there.  Playing
nice with the hospital AND your colleagues makes it easier to get
things to happen.

Mirth is handy when you want several ways to play with output at the
same time.  Some choose to have it logging to a file all the sent  
results.
While a developer was debugging it, he sent emails to himself telling
him when there was output coming through.  A real joy of a framework.

Mirth is also useful when you get a different incoming stream.  A  
group is
developing a way to sidetrack data from their PACS system, including a
different way to get Xray results and DICOM messaging

another list member asked:

> there is a mirth appliance available , is it possible to attach to  
> the oscar
> server ,so one  could get lab reports from hospitals and other labs  
> which
> can send result in HL7 format, and the lab get attached  to the pt"s  
> file, .
> how easy it is to set up?


The problem is that there is no generic HL7 handler that will handle
every mangled piece of s* that has a HL7 extension and stuff it into
EMR without tuning.  For a standard, HL7 is remarkably poorly
implemented on both the output system and on input systems.  By
example some EMRs can't handle batch files, a perfectly legitimate HL7
defined spec that our lab system outputs to.  It doesn't handshake
with ACK files reflecting that messages have been received (you would
think a useful thing to prevent labs going missing and tracking those
that do) and so on.

To be fair all EMRs have lots of company as everyone seems to use ad hoc
implementations here in this country.  Even if an EMR grew ACK handling
there are few systems on the sending end that know what an ACK file
is.  Then there is the lab nomenclature.  While LOINC is a standard
lab coding system (which some EMRs understand well), my lab has to use
something obscure and arbitrary that I have to manually map into the EMR
(luckily only once per test type, and there are only so many tests
that I need to graph....).  I suppose I could use CML but what, they
too have an arbitrary system, and its different!

Once you get away with writing half compliant outputs of "HL7" (and if
you have spent 5 years arguing for a HL7 interface from the hospital
you are happy to get anything) and the EMRs write half compliant
inputs for each and every lab source,...  Then the sender changes
their output (tell me about it, while the hospital interface is new I
have been manipulating HL7 to import labs for 9 years) and there you
are again rewriting to accommodate broken standards.

Brings me back to discussing useful places to spend government eHealth
money...  Enforce a national HL7 standard.