Mirth Connect Series: Introduction

With the advent of digital technologies and always connected devices, integration still remains a challenge in healthcare. To deliver better patient care, electronic health data needs to flow across across boundaries and systems. However, reluctance of providers to share data, non-standard and proprietary data formats, privacy and security requirements have made it impossible for disparate system to talk to each other.

Although various ontologies, data and, messaging standards were introduced but they have not been as successful in increasing the efficiency and effectiveness of application integration as originally intended. As the standards evolved, so did the complexity of integration. Keeping up with new standards and maintaining the current integration engines became a huge burden for healthcare organizations.

And that is how “Mirth took birth“

What is Mirth?

Mirth is a platform that connect various HIT systems to create faster, easier, more secure, and cost-effective interoperable mechanism for exchanging healthcare messages. Mirth is designed in a way that makes integration among healthcare system easy & fast as it accepts all the leading healthcare message standards like HL7, EDI, X12 etc.

To achieve this, Mirth Connect uses a channel-based architecture to connect HIT systems to filter, transform, and route the messages on user-defined rules.

Let’s have a look at Mirth Architecture and its components.

Mirth Architecture

There are four key components of Mirth architecture:

•  Mirth Connect Server– Contains back-end for the management interface and integration engine component, performs message filtering, transformation, and transmission
•  Mirth Connect Administrator – GUI that Connects to Mirth Connect server. It allows to configure interfaces, Monitor interface activity & browse the message store.
•  Mirth Connection Server Manager – GUI that manages Mirth Connect Service, display log files and contains other configuration settings for the Mirth Connect Server.
•  Mirth Connect Command Line Interface – A command line tool allows Connection to Mirth Connect server to Deploy/Import/Export Channels and performs other administrative tasks.

Mirth Interface

Logging into Mirth would take you to Mirth Connect Administrator, which has three sections:

A. Dashboard in the center

The dashboard shows the following “Channels” :

• Currently deployed.
• Channels status.
• Channel name.
• Last deployed Channel.
• Number of Messages Received – Filtered, Queued, Sent, Errors.

B. Navigation menu on the left

C. Log panel at the bottom

Channels

The bulk of work in Mirth is done through the “Channels”. All the messages are created & sent through Channels. The data format of messages is also defined here. The Channel appears on the left side navigation menu.

Clicking on a Channel’s name will expand the “Channel Tasks Menu” that includes links for editing, cloning, deleting and disabling a Channel. When the user creates a new Channel or edits an existing Channel, the Edit Channel page is displayed.

Edit Channel

It has four horizontal tabs:

A) Summary  
B) Source
C) Destination  
D) Scripts

Each message can have one source and one or more destinations.

Summary

It includes general information about the Channel, such as name and description.

It has further 4 sections-

a. Channel properties

They define the basic properties of Channel like Name,ID, Data types (It allows user to define incoming data type, and options to choose from HL7, ASC (X12), XML, Delimited text etc. data types.)

b. Message storage & pruning

It defines how a message should be stored or when it should get purged. To store the messages, Mirth allows you to choose from 5 different levels:

• Disabled (no message storing)
• Meta data (only stores meta data if any)
• Raw (stores raw & meta data)
• Production (stores raw, encoded, sent messages, response, & mapping)
• Development (stores everything)

The users can select storage level by scroller which is present under message storage. They can also decide if the messages received by the Channel should be saved or not and if saved, should they be encrypted so that private patient data is preserved and for how long the messages should be stored in the DB before getting purged.

c. Channel tags & metadata

It lets you add a tag for the Channel and define meta data that you want to save in Channel.

d. Channel description

To add a description for the Channel.

Source

The “Source” let you define how Channel receives the data.

On top, the user can select Connector type. Connectors listed here in no particular order:  

HTTP Listener, LLP Listener etc, TCP sender, the File reader, JMS listener, Database reader etc. You can add a Source by selecting your preferred connector type available in the drop-down option.

Once a Source type is added it shows you various setting options of that Source. For example, here we will show Database reader as selected connector type, in the image given below we have set up “Database Reader” as the Source for the Channel.

On selecting Database reader as Source it lets you decide settings from three options-

a. Poll settings

Decide interval when you want Mirth to run a query to Database to get the data. You can also set a particular time or run a Cron job for this as well.

b. Source settings

It allows you to set source queue, you can get a response before processing or after processing, you can also set no. of threads of processing which will run to process data.

c. Database reader settings

The DB reader settings lets a user decide what kind of DB it is – MySQL, Oracle, PostgreSQL, SQLite etc. You can also set if you want to save cache results or not, or can keep the connection open as well. Under settings, you can choose no. of retries in case of error.

Destination

The “Destination” is pretty much similar to Source. Here we define the destination of the message. One of the main differences between Source & Destination is that there could be multiple destinations for a Channel.

The top bar of the Destination tab shows:

• Status
• Destination ID
• Connector type
• Chain of a Channel

The Destination has similarities to Source tab, it lets you chose Connector type, and further edit the settings of selected Connector type.

Filters

Source & Destination tab under Channels have an option of Filters on left side panel. Filter lets you determine if the message should be accepted or rejected.

Clicking on Filter takes you to the “Edit Filter” screen. On top of Edit Filter screen, there is an empty list of active filters. At the bottom, it show parameters of active filters. On the right, there are three tabs showing the reference functions, the available message trees, and the message templates.

Transformers

This also comes under both Source & Destination, it is on left side and clicking on it will take user to Edit Transformer screen. Transformers are rules that changes or re-arranges data in source message to create destination message. Transformer basically transforms the data in the way you want it to be transmitted.

Scripts

Last tab under Channel is for Scripts, there are four types of Scripts which is mentioned below, each used for a separate reason-

a. Deploy

This script is executed each time engine is started, it is mainly used to construct and initialize common objects that needs to persist while Mirth is running.

b. Shutdown

This script is executed each time engine is stopped,it is used to clean up anything created by Deploy script.

c. Preprocessor

This script is executed every time a message is received immediately before the message is normalized to XML.

d. Postprocessor

This script is executed immediately after a message is sent,it contains channel specific variables.

So, these are the basic key elements of the Mirth Connect interface.

But with Mirth being a big system, it is not easy to place an in depth analysis of all Mirth Connect elements at once. We have tried to cover all the details of the “Channel” in this part of the series. More posts about the rest of the Mirth elements will make their way to you soon!