10 Tips and Tricks to Make Mirth™ Connect Work for You

10 Tips and Tricks to Make Mirth™ Connect Work for You

In our last blog post in this series, we introduced the Mirth™ Connect interface engine and discussed how it stacks up against the competition in the healthcare IT space. What we love most about Mirth™ is the breadth of customization options that are offered, and today we want to give you a deeper look inside the application with our tips and tricks segment. For a deeper dive into Mirth™ Connect, download our whitepaper.

  • Add channel metadata to troubleshoot faster: You may already be storing useful information about incoming messages in channel variables, such as the MRN of a patient, an identifier for a hospital, or the HTTP response code of a message you are POSTing via Mirth™. By adding these channel variables to the metadata of a channel, you can view the values for these variables on the message log screen and also speed up your searches when using the Advanced search filter and specifying the metadata you have defined.

    Figure 1: In the Source screen of your channel, enter your variable names and provide a name for the column where you can view the variable on the message log screen.

    Figure 2: Now in the message log screen for your channel you can see your new metadata, adding important information to your message log. Use the Advanced search option with metadata specified to experience faster search results.

  • Stay DRY (Don’t Repeat Yourself): Apply the abstraction principle by using code templates and global scripts in place of duplicate code. For example, if you have multiple channels, destinations, or transformers that all need to connect to the same database, move your database connection string into a code template and reference the code template any time. This way, if you ever change your database credentials, you will only need to update your code template instead of every database-accessing channel.
  • Don’t reinvent the wheel – leverage external code libraries: Mirth™ allows you to import external Java and JavaScript libraries just like you would in a traditional IDE. When we needed to store data securely in our database, we used the CryptoJS JavaScript library to encrypt our data instead of writing our own complicated encryption algorithms. Pro-tip: when using external JavaScript libraries, host the library locally to avoid making expensive (slower) calls to an external server with every message that Mirth™ processes.
  • Don’t catch errors gracefully: You don’t often hear this, but in your Mirth™ JavaScript code, you may not want to catch errors gracefully. If you wrap your code in try/catch blocks but do not throw the error, Mirth™ will let the message continue processing and anything could happen with a broken message downstream. Throw your errors to let the message fail.

    Figure 3: Wrap your JavaScript code in try/catch blocks to capture errors and make sure to throw the error so that the message gets set to ERROR and does not continue being processed.

  • Don’t code (or test) in production: Once the save button is clicked on a channel or code template, your changes are permanent and can’t be undone (unless you have backups). As with anything else in IT, don’t code or test in production – use a separate instance of Mirth™ as your development/staging environment. Create new channels and change existing ones there, and once you’ve tested your changes thoroughly, export your channel from the staging environment and import it into production.
  • Handling source control yourself: Another feature still lacking in Mirth™ Connect is channel source control. As of Mirth™ 3.2, there are no ways in the Mirth™ user interface to view or revert changes made by users. If someone else has broken a channel, you have very little information available to know what has changed. However, one nice thing about Mirth™ channels and code templates is that they are saved as XML files. You can use an external source control tool such as GitHub or BitBucket and export your channels from Mirth™ into them.
  • Use an external IDE: With the 3.2 release of Mirth™ Connect in February, some improvements were made to the JavaScript Editor, including code completion and bracket matching. Still, for many of us used to coding in a dedicated IDE like Visual Studio or Eclipse, Mirth’s JavaScript Editor lacks some of the features we’ve grown accustomed to, like source control, writing unit tests with JUnit (Java) or QUnit (JavaScript), or refactoring with Resharper for Visual Studio. Nothing is stopping you from writing your JavaScript code in your favorite IDE and copying and pasting into Mirth™ when you’re finished.
  • Safely restarting Mirth™: If your instance of Mirth™ is handling hundreds of thousands of messages a day like the ones we have worked with, your channels are likely using a lot of system memory. When restarting Mirth™ – maybe because you are upgrading the application or you are doing server maintenance – you should make sure to disable and undeploy all of your channels before restarting. If not, Mirth™ will attempt to quickly halt all traffic during the shutdown phase, potentially causing errors to messages being processed, and during the restart phase Mirth™ will try to automatically deploy all channels at the same time. Since your channels may have upstream or downstream dependencies on other channels, manually launching your channels in a specific order may be necessary.
  • Give yourself some more memory to work with: If you ever get an OutOfMemory error in Mirth™ and the heap size is mentioned, you may want to think about increasing the heap size of both your Mirth™ Connect server and client. This will provision more RAM for Mirth™ to use when handling heavy traffic or opening the logs for large messages. You can increase the server’s heap size by going to Mirth™ Connect Settings in your appliance and you can increase the client’s (the actual instance of Mirth™ Connect you interact with) by editing the .jnlp file in a text editor and looking for where the heap size is defined.
  • Fine tune the message storage option for each of your channels: Some channels may handle more traffic than others or process messages with greater magnitudes of length. As these messages and their metadata (channel variables, HTTP response statuses, etc) are stored in Mirth’s database, space can run out fast depending on the disk space of your server. In each channel, you can use the Message Storage slider to configure what Mirth should save, ultimately changing what level of detail you have to work with in the Message Log screen. Pair this setting with the Message Pruning option to let Mirth save the exact kind of content you need for as long as you want. If you notice that you’re running out of disk space, change the settings and get to that sweet spot that lets you have robust archives without bringing your server down.Mirth 2.4

At Galen, we have worked with Orion Rhapsody, Epic Bridges, InterSystems Ensemble, and almost every other healthcare interface engine out there, and helping our clients achieve interoperability is something we are passionate about. For our next article in this series on Mirth™, we will leverage our years of experience in the industry to present our final opinion on Mirth™ and explain why it may be the right interface engine for you.

To learn about how Galen can assist your organization with using Mirth™, please contact us:

Facebook Twitter Email


Add yours
  1. 1
    Cole Bittel

    This is wonderful! I consistently refer back to these tips as I learn how to make Mirth work for.
    You’ve done an excellent job here, and I wish I could find more tips like this through the web.

  2. 2

    Hi, It’s a very good article. And it would be great if you can give an example to use external java script libraries in Mirth Connect.

+ Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.