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

[Karsten Hilbert]

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

Karsten

On Tue, Oct 20, 2009 at 11:07:31AM -0700, Jim Busser wrote:
> X-Mailer: Apple Mail (2.1076)
> Subject: [Gnumed-devel] On using Mirth (in place of coding every import
>       inside of an EMR)
> 
> 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.
> 
> 
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel

-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346