Mirth

Introduction

Let'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??

Mirth was originally intended as a HL7 interface engine. However, with no hacking or magic tricks involved, the application can be used as a rhobust middleware messaging system which supports reading from and writing to database/FTP/soap/TCP/Local or Network Shared File/JMS channels. A channel is simply that, a pipe through which information flows with at least two endpoints - a source and a destination (though multiple destinations are possible for a single channel). Data passing through a channel can be either transformed or filtered using a combination of SQL,Javascript and Java. Most of the examples on the Mirth website contain pretty simple Javascript examples, but under the hood lies a full Java API allowing for more complex logic to be implemented. [As an aside, Java objects must be created using a strange hybrid syntax where loosely typed variables are used when declaring instances of Java classes. I've never delved deep enough to determine if/how type inference is being handled, but i'd certainly be interested to know...].

 

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

The most obvious deficiency of Mirth at the time of my original interaction was the lack of substantial documentation. One of the specialties of Webreach Inc., the organization behind Mirth, is application support. While I would not accuse them of purposefully neglecting to document the application, it is obvious (and respected) that their goal is less to support the non-paying user population and more to foster the user community to become self sufficient in terms of issue resolution. The forums were indeed my primary source of information during the trial and error phase and a wonderful source of information they were. Quite a large community appears to be growing around the application and I never waited long before receiving a suggestion/resolution regarding an issue I reported. They were and remain the the only source of more complex information (including creating filters and transformations in Javascript combined with Java!!!). Recently a new Wiki was created (link) which covers the fundamentals quite well and would have been very welcome to me when I first used this product. I recommend newcomers check it out...

Conclusion

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.]