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