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“
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.
There are four key components of Mirth architecture:
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” :
B. Navigation menu on the left
C. Log panel at the bottom
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.
It has four horizontal tabs:
Each message can have one source and one or more destinations.
It includes general information about the Channel, such as name and description.
It has further 4 sections-
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.)
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:
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.
It lets you add a tag for the Channel and define meta data that you want to save in Channel.
To add a description for the Channel.
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-
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.
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.
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.
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:
The Destination has similarities to Source tab, it lets you chose Connector type, and further edit the settings of selected Connector type.
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.
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.
Last tab under Channel is for Scripts, there are four types of Scripts which is mentioned below, each used for a separate reason-
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.
This script is executed each time engine is stopped,it is used to clean up anything created by Deploy script.
This script is executed every time a message is received immediately before the message is normalized to XML.
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!