IntroductionLet's talk about Mirth. At it's simplest, Mirth link is an Open Source HL7 interface engine. HL7 (Health Level 7) is an NPO involved in the development of healthcare standards and the HL7 v2.x and HL7 v3 standards are commonly used in Medical Information for data interchange - including but not limited to clinical, financial, logistical and administrative messaging. I first ran across Mirth over a year ago on a personal quest to find an alternative to our client's legacy HL7 application. Academically, I wrote a number of lexical analysis tools using lexx, yacc, bison and JavaCC and knew the challenges of writing and maintaining complex parsers. I was simply looking for something that could parse HL7 for us, and perhaps log messages and provide a little more transparency than our application currently allowed. A year later and our legacy application is still going strong (read: my proposal was declined), but Mirth is being used in production, far away from the world of HL7.
I don't work for a Medical Company, so what do I care??
Why I Use Mirth
Realizing that our client was unlikely to redesign a HL7 system that has worked successfully for the best part of a decade, I gave up on the idea of using Mirth. However, not long afterwards an interesting challenge presented itself in another project. The requirement was simple: read data from a SQL Server 2000 database, convert the data to XML (third party XML schema - not just the SOAP envelope) and send it via SOAP to a third part JSP web service. A few bells and whistles were required (logging, message auditing, failure notification etc.) but the core requirements were pretty straightforward.
Obviously, there were a few solutions to this one:
1. Create a SQL Server CLR stored procedure, using the .NET framework's web service APIs to call the web service.
Frankly, this would not have been a bad option...had the data resided in a SQL 2005 database. Unfortunately, this is an older database without the possibility of using the CLR.
Isolation of databases is emphasized in our production environment, so linking servers and invoking a CLR procedure on a separate server was not desirable. Furthermore, while
certainly a feasible approach in terms of performing the base functionality, such an approach would not (without somewhat more work) have provided transparency into the
process, nor detailed logging or notifications.
2. Create an extended stored procedure
This was the pre-SQL2005 approach and was undesirable for the reasons listed for the CLR approach, plus one additional problem. Ours is a .NET shop and while we have developers
comfortable programming outside of the confines of the CLR/.NET Framework, maintainability is a key issue. Such an extended stored procedure would have been developed in C/C++
making things more difficult (for a .NET shop) to maintain in the long-run. It is difficult to say whether this issue alone would have been enough to nix this approach - but with the
other listed drawbacks, we decided against this one.
3. Write an external .NET application to read from the database and invoke the web method of choice
The obvious negative here was the time investment required. The base functionality would have been exceedingly straightforward. Creating a robust user interface would not.
We chose to use Mirth...
Our Mirth Experience
The experience of implementing the above scenario with Mirth was an exciting one. The obvious first impression when using this application for the first time is it's maturity. It is obvious that the product has been through many iterations of the development lifecycle and the interface and offered functionality are (dare I say it) downright professional. In order to achieve the above goal i was able to use a Database Reader to pull information from my SQL 2000 database and a SOAP Sender to pass the (transformed) data to a web service of my choosing. The SOAP Sender allowed me to specify a second channel to process information returned from the third party web service.
a. The Good
Getting a basic channel up and running was extremely simple. The database reader allowed me to write my own SQL statement to pull information from the database of my choosing. The SOAP Sender setup, though not without glitches that I will undoubtedly blog about at a later date, was straightforward and I was talking to the third party web service in no time. Moreover, the logging and notification abilities surpassed anything I had envisioned for this project. Mirth allows alerts to be setup for specific channels and specific events and sent via SMTP. The dashboard (the main Mirth screen) allows a simple view of message stats, flagging errored messages and those received, queued, sent and filtered. Double-clicking on a specific (deployed) channel on the dashboard allows further drilldown making investigation of a failed message a breeze. It allows messages to be viewed at every stage of their lifecycle, from the raw message received to the transformed message sent to the web service and the message returned from the web service. I've personally maintained this nightly job since its inception and the dashboard has been an invaluable source of information.
b. The Bad
Mirth is an amazing application and quite mature to boot. Whether your company works with medical information systems or you just want a system you can use to port and track data Mirth is a must. In future posts I will go into more technical details, but for now download it, play with it and love it like I do. [At the time of writing Mirth 1.80 RC2 has been released and I am very much looking forward to playing with the RTM version.]