The Tolven Platform version 2.1 has upgraded to the JBoss Application server version 6. The JBoss Drools engine is a powerful tool for implementing business intelligence. The Roberts-Hoffman plugins make use of Drools to implement several powerful workflow components of the RHS EHR System, including occupancy management, order verification, and interface triggers.
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.
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.