Complete Guide to Mirth Connect Alerting and Monitoring

Zen engineers have been working with Mirth Connect, the most popular open-source interface engine in the world, since its release in 2006. Like many interface engineers, we spend a lot of time focusing on interface design and deployment. But as many of you have learned, that is just the beginning.

Once a Mirth Connect channel is fully deployed into production, the real work begins. The data flowing through the interface is vital to clinical workflows. Channels need to keep flowing 24X7 and be operating at maximum efficiency. You need to monitor for channel errors, queuing rates, and message volumes. You need to be sure your Mirth Connect instances are actually up and running at all times. And if at all possible, be able to intervene BEFORE a channel goes down, or worse, takes your entire Mirth Connect instance down.

So what are your options for alerting and monitoring on your Mirth Connect channels?

To answer this question we need to consider what version of Mirth Connect you are running: The open-source version or the commercial version with the Advanced Alerting plugin.

Mirth Connect Open Source Capabilities

The open source version does not come with a sophisticated channel alerting solution. However, there are a few steps you can take to enable some types of notifications that are native to the application.

As described in the Mirth Connect User Guide: “Mirth Connect comes with a built-in Error-based alerting system that listens for error events from selected channels”.

Error based Alerts can be modified in three ways:

Error Type

Here you can choose the type of error you want to alert on from a predefined list, or optionally use Regex to define a more specific error source or even stacktrace that matches to the alert type you wish to use as a trigger

Alert Enabled Channels

Select which channels a given alert can be triggered by.

Alert Actions

Define how an alert is sent. Alerts can be sent either via an email, or via a Mirth Channel to allow for further processing/routing.

Unfortunately, channel errors are not the full picture in terms of a channel’s condition.

The other alternative for Mirth Connect open-source users is that you could invest a lot of time and money into working with the Mirth Connect API and building an alerting solution out yourself, While that is theoretically possible, we do not know very many IT departments managing interfaces that have that kind of time available. And having created our own monitoring and alerting solution already – warning! Be prepared for a very large investment if you want to try to “build your own” and actually end up with an efficient and effective solution that will stand the test of time.

Commercial Mirth Connect Advanced Alerting Extension Capabilities:

When purchasing a commercial license for Mirth Connect, certain license tiers will include the Advanced Alerting extension. This extension allows for more configuration and flexibility than the Alert tool included with the open source. Some of the features and benefits include:

• Go beyond system generated errors to trigger an alert
• Create alerts based on various metrics and a given state of a channel or connector
• Support for escalation and de-escalation until an alert is resolved
• Be able to send different alert messages to defined user groups based on the escalation level, time, or day.
• Alert scheduling with groups
• Define a schedule for given users or roles to ensure the right person gets the alert at the right time
• Notification throttling
• Reduce alert “spam” by avoiding repeat notifications for the same alert for a defined period of time

So what’s missing? The biggest issues with the Advanced Alerting Plugin from our perspective is the following:

1. No Consolidated Alerting Strategy Across Instances – The Advanced Alerting plugin needs to be configured on each production instance, and for each channel in an instance. This adds operational overhead and allows for the possibility that you will have different alerting rules for different instances or channels.

2. Alert Fatigue – The alerting model is a “one issue – one email alert” type scenario. This means that your team could be getting a LOT of incoming emails. Therefore most people will only alert on big issues or, throttle the alerts, potentially missing out on information that a new issue might be emerging.

3. Lack of a Unified Dashboard – In the newest version, the Advanced Alerting Plugin has a Dashboard to show alerting history, but you must log into each production instance of Mirth Connect to view it. We think Mirth Connect users need a single “pane of glass” to access their Mirth Connect Monitoring Dashboard that gives them data on all Mirth Connect production instances in a single unified view.

4. Channel Alert Configuration Overhead – Individual channel behavior varies a lot. To be effective, the Advanced Alerting plugin requires that you adjust the alert settings for each channel’s behavior. For example, let’s say you want to alert on message volumes or the lack of messages. For one channel, you have a very low message volume, that comes in mostly on one specific day a week. For another channel, you have a very high message volume that is well distributed over time. You will need to set up a specific alert for each of those channels to match that expected behavior.

5. Cost – To use the Advanced Alerting plugin, you must purchase a commercial license from NextGen. For those who want channel advanced alerting capabilities, but who have smaller deployments, it is an expensive option.

Zen Insight Option Capabilities:

Zen’s Gemini Integration as a Service solution offers a Mirth Connect user interface for our Developer Edition clients who want to build and manage their own interfaces. We wanted to be sure that Zen engineers and our clients had the most effective channel alerting and monitoring solution possible. This led us to create Zen Insight.