Using Mirth with a Tolven Platform

The well-deserved explosion in the popularity of Mirth Connect is a testament to its versatility and stability.  You can add Roberts-Hoffman to the list of satisfied users!  We have been using the open source version of Mirth Connect since the first production deployment of our EHR system to manage interfaces.  More recently, we have made use of the Mirth engine to perform some even more sophisticated tasks and integrate more closely with our EHR system.

There are two options for using Mirth with a Tolven Platform-based system like ours:  Webservices or REST.  The webservice interface is a little more basic, meaning that there are only two options:  processDocument() or queueDocument().  This can be a good thing, because it is a bit more simple to configure.  If you have a document processor ready to accept the type of electronic document you are working with, this might be your best option.  REST, on the other hand, requires different authentication, but once you get connected you have access to quite a few native REST-enabled functions, as well as the capacity to write your own.  REST is the way you want to go if you really need to access placeholder information directly as you might for matching or updating information.

The channel is the basic unit of currency in the Mirth world.  You make them to talk to outside entities, read or write to databases, or to perform transformations, filters, or anything else you can write in Javascript.  The functions of Mirth are unbelievably powerful, and as Ben Parker said, “With great power comes great responsibility.”  I think it is channel implementation that separates a Mirth playground from a production-ready design that is maintainable.  Yes, you can clone a channel and make a new interface in Mirth, but at some point in the near future, you must think about re-usability and portability. The Roberts-Hoffman team has been creating and maintaining Mirth channels for production interfaces for over a year now.  During this time we have improved our channel architecture with both portability and re usability in mind.

There isn’t (or shouldn’t be, anyway) a production interface anywhere that doesn’t have a staging or test area.  You must have portable channels in order to minimize errors when transferring between instances.  Mirth gives you a nice feature set that supports importing and exporting channels, which forms the foundation for portable channels, but what about all the instance specific settings?  We’ve made use of the global scripts and properties to make channels that can localize themselves to whatever environment they are deployed.

How many times to you want to parse the PID and extract the patient ID?  That was the question our team began to ask as we were proliferating Mirth channels for different flavors of the ADT message series.  In response to this need, we designed a system of channels that accept a message of a specific type (e.g. ADT) and perform a specific function.  Then the channels essentially pass a message back and forth to complete all the  necessary translations.  We coupled this channel hierarchy with Mirth’s database reading capability to make these reusable channels portable by equipping each channel to know what channel to call next.

Mirth is a really great tool.  It has been very stable in our production environment and it has an enormous feature-set.  You can save yourself some pain if you plan your channel structure and do a little extra work to make them reusable.