Category Archives: Mirth

Integrating Mirth with Tolven

Roberts-Hoffman Software integrated Mirth Connect with Tolven as part of our inpatient EHR.  We use Mirth to handle our bidirectional HL7 feeds, managing messaging between live hospital information, lab, and radiology systems.

 Mirth can communicate with Tolven in a variety of methods.  For inbound communication, we implemented our interface with Tolven using Tolven’s Web Services API.  Tolven provides a sample Web Services Client that we modified slightly to meet our needs.  Mirth allows you to include jar files and instantiate java objects to use within your channels. We create an instance of this Web Services Client, which allows us to call Tolven’s Web Services API and submit documents to the document queue for processing.  Tolven also provides a RESTful API which can be called in much the same way.  The RESTful API is newer and more full-featured than Web Services, and is the Tolven recommended method for new interfaces.  We’ve successfully tested using REST to communicate from Mirth to Tolven.

We chose to use Mirth to translate the incoming HL7 v2 messages to TRIM, Tolven’s internal message format.  This way, Tolven already knows how to process them.  Tolven can also natively handle CCD and CCR documents, although in a more limited fashion.  However, you can create a document processor to process just about any type of document you wish to process in Tolven.  These document processors can easily be plugged in and give you very granular control of how the data is processed and stored.

For communication from Tolven to Mirth, we use Mirth’s SQL query functionality.  Depending on encryption settings, Mirth can query the Tolven PostgreSQL database to access the necessary data.  SQL views can be used if necessary to simplify and consolidate the data, as Tolven’s data structure can make direct SQL queries quite complex.

One source of difficulty in implementing the connection between Mirth and Tolven is SSL.  Making sure Mirth and Tolven can communicate securely can be tricky.  Installing Mirth and Tolven on the same server simplifies the process, as they can then share SSL certificates.  It is possible for Mirth to live on a different server than Tolven, but setting up the SSL certificates can be difficult.

EHR Launched with HL7 Interface & Medication Orders

The Roberts-Hoffman team, in association with Family Health West has implemented the first functional module of the Roberts-Hoffman EHR system.  In late January, we installed the HL7 interface between the existing HIS system and the EHR using the open source tool, Mirth.   In addition, we have created a medication ordering plugin that allows the pharmacy tech to electronically enter medication orders using the RxNorm medication list, and then print a customized medication administration record (MAR).  Thanks to all who worked to make this an amazing first step toward ONC 2011 certification!

Bi-directional Occupancy Management

For July of 2013 we have bundled a pretty large update, which includes some advanced interface features.  One predominant feature is the bi-directional occupancy management between the EHR system and the HIS system.  For our inpatient facility, end-users have the option to make patient location changes in either system, and so we needed to make sure both systems have the most current information.  Prior to this release, the discharge operation happened only in the Medical Records department, and often not until several days after the patient had left.  Consequently, we added a discharge wizard to the EHR system that allows the clinical staff to indicate that the patient has left, and remove the entry from the inpatient list.  But wait, there’s more…

In addition to discharging the patient, the nurses will add a discharge note at the same time, and they can also provide information pertinent to Clinical Quality Measures (CQM), too.  So, we made a dynamic wizard for discharge that allows the nurse to do all three at once upon discharge.  This, again, is like the CPOE wizard we created, which creates a single document but multiple separate placeholders for the items therein.  First, the discharge information impacts the encounter placeholder.  Then, the discharge note creates an electronic nursing note that is added to the note list with a focus word of Discharge.  Finally, the CQM information updates its own list and portlet.  To preserve the integrity of the data, if the nurse nullifies the discharge event (because it was entered in error), then the system will locate and nullify any discharge note or CQM data that was entered as part of the discharge.

All of these events automatically generate interface messages through our Mirth-based interface to the HIS system and other ancillary systems (lab, radiology, etc).  All the systems get the information in real-time and everyone is up-to-date.  This is a good example of using technology to help make a job easier.

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.