Written and maintained by CASRAI Editorial Board
Last updated
Mirth Connect—rebranded by NextGen Healthcare as NextGen Connect—is the most widely deployed cross-platform healthcare integration engine for parsing, transforming, and routing HL7 v2 messages, C-CDA XML documents, X12 EDI transactions, DICOM objects, and HL7 FHIR resources. Built in Java and deployed across thousands of hospitals, reference laboratories, clinical research networks, and health IT vendors, Mirth Connect provides a channel-based message pipeline managed via the Mirth Connect Server daemon and the desktop Mirth Connect Administrator (launched through the standalone Mirth Connect Administrator Launcher).
How Do You Configure Source and Destination Connectors in NextGen Connect (Mirth)?
Every interface workflow in Mirth Connect (NextGen Connect) is encapsulated inside a Channel. When an inbound clinical message enters a channel, it traverses a deterministic seven-stage processing pipeline:
- Source Connector: Listens for or polls inbound data (for example, an MLLP TCP socket on port
6661, an HTTPS REST endpoint, an SFTP directory, or a SQL database table) and writes the raw message to the internal channel table (D_MM/D_MCin PostgreSQL, SQL Server, MySQL, Oracle, or embedded Apache Derby). - Pre-Processor Script: A channel-level JavaScript hook that manipulates the raw string payload before XML/JSON serialization (frequently used to sanitize malformed non-ASCII bytes or normalize non-standard segment delimiters).
- Source Filter and Transformer: The engine parses the inbound payload (using its built-in HL7 parser) into an internal XML representation (`msg` variable). Filter rules evaluate boolean conditions (returning
trueto accept orfalseto filter/drop the message), while Transformer steps modify fields, query lookup databases, and populate map variables (channelMap,connectorMap,globalMap). - Destination Filter and Transformer(s): A single Source Connector can fan out to one or many Destination Connectors. Each destination runs its own independent Filter and Transformer against a cloned copy of the message, allowing Destination 1 to send an HL7 v2.5.1
ORU^R01lab result to an EHR (such as Epic Bridges) while Destination 2 transforms the exact same event into a FHIR R4ObservationJSON payload for a clinical research data warehouse. - Destination Connector(s): Transmits the transformed outbound message to the target system and captures the remote response (such as an HL7
ACK/NAKor HTTP status code), placing failed deliveries into a persistent disk-backed Destination Queue for automated retry. - Response Transformer: Inspects and optionally modifies the downstream system’s acknowledgment before returning it to the originating sender.
- Post-Processor Script: Executes final cleanup, custom audit logging, or metrics reporting after all destinations have completed or queued.
| Connector Type | Direction | Primary Protocol / Transport | Key Configuration Parameters in Mirth Connect Administrator |
|---|---|---|---|
| TCP Listener / TCP Sender | Source / Destination | MLLP (`0x0B` … `0x1C 0x0D`) over TCP/TLS | Transmission Mode (`MLLP`), Listener Port, Keep Connection Open, Send ACK (`Auto-generate` vs. `From destination`), Response Timeout |
| HTTP Listener / HTTP Sender | Source / Destination | HTTP / HTTPS REST & Webhook | Context Path, Multipart/XML Body parsing, Custom Headers, Basic/OAuth2 Bearer Authentication, Response Status Code variable |
| FHIR Listener / FHIR Sender | Source / Destination | HL7 FHIR RESTful API (DSTU2, STU3, R4) | FHIR Version (`R4`), Base URL, Supported Interactions (`read`, `vread`, `update`, `delete`, `search-type`, `create`), Resource Type |
| Database Reader / Database Writer | Source / Destination | JDBC (PostgreSQL, MSSQL, Oracle, MySQL) | JDBC Driver URL, Polling Interval/Cron, `SELECT` query, Post-Process `UPDATE` statement (marking rows processed), Parameterized `INSERT` |
| File Reader / File Writer | Source / Destination | Local Filesystem, SMB, FTP, SFTP, Amazon S3 | Polling Directory, Filename Filter/Regex, After-Processing Action (`Move` to archive directory or `Delete`), Batch splitting rules |
| Channel Reader / Channel Writer | Source / Destination | In-Memory Inter-Channel VM Routing | Target Channel ID, Source Map forwarding, Synchronous vs. Asynchronous handoff (decoupling complex ingestion from transformation) |
Launching the GUI: Mirth Connect Administrator Launcher
Because modern Java distributions deprecated browser applets and Oracle Java Web Start (`javaws`), engineers do not configure channels inside a standard web browser. Instead, administrators install the Mirth Connect Administrator Launcher—a desktop wrapper (bundling IcedTea-Web / OpenWebStart) that connects to the Mirth Connect Server’s HTTPS port (default 8443), downloads the version-matched JNLP client descriptor and libraries from the server, and opens the full Swing-based Mirth Connect Administrator IDE.
How Does the Mirth Connect FHIR Extension Handle FHIR R4 Resources?
While standard HTTP Listeners and Senders in Mirth Connect can exchange raw JSON payloads, the dedicated Mirth Connect FHIR Connector Extension (maintained in the NextGen Healthcare ecosystem alongside the nextgenhealthcare/fhir-example-channels repository) embeds the open-source HAPI FHIR library directly into the Mirth runtime to provide native FHIR DSTU2, STU3, and FHIR R4 parser, validator, and RESTful server capabilities:
- FHIR Listener Source Connector: Turns a Mirth Connect channel into a compliant FHIR R4 endpoint. Administrators check which official FHIR RESTful interactions the channel accepts—such as
create(POST /[type]),read(GET /[type]/[id]),vread(GET /[type]/[id]/_history/[vid]),update(PUT /[type]/[id]),delete,search-type(GET /[type]?param=val), or system-leveltransaction/batchBundles. - Automatic Context Variables in `sourceMap`: When a client calls the FHIR Listener, the extension automatically populates Mirth’s
sourceMapwith structured routing metadata:fhirVersion(e.g.,R4),fhirInteraction(e.g.,readorcreate),fhirType(e.g.,PatientorObservation),fhirId(logical resource ID), andfhirParameters(URL query parameters). - `FhirUtil` and `FhirResponseFactory` Helper Classes: Inside JavaScript transformers, engineers call
FhirUtil.fromJson(msg, 'R4')orFhirUtil.fromXml(msg, 'R4')to instantiate native HAPI FHIR Java objects (`IBaseResource`), validate resources against StructureDefinitions, and return properly formatted FHIR responses (with HTTP status codes, `ETag` version headers, and `OperationOutcome` diagnostics) viaFhirResponseFactorystored in theresponseMap.
What Happened to Mirth Connect’s Open-Source Repository and Community Forks?
For nearly two decades, Mirth Connect was developed and distributed on GitHub (`nextgenhealthcare/connect`) as free, open-source software under the Mozilla Public License 2.0 (MPL v2.0), while NextGen Healthcare monetized commercial support tiers (Silver, Gold, Platinum) and proprietary closed-source plugins (such as advanced RBAC, clustering, and SSL manager extensions). In 2024–2025, a major licensing transition reshaped the Mirth Connect ecosystem:
- Version 4.5.2 — The Final Open-Source Release: Mirth Connect 4.5.2 represents the final release distributed under the open-source MPL v2.0 license on the historical GitHub repository. Organizations running
4.5.2(or earlier) retain perpetual rights under MPL v2.0 to inspect, modify, and self-host that codebase without commercial license fees. - Version 4.6+ Commercial Licensing Model: Starting with NextGen Connect 4.6.0, NextGen Healthcare transitioned future releases to a closed-source, commercial subscription model, discontinuing public open-source binary downloads and source commits for post-4.5.2 versions.
- Open Integration Engine (OIE) and Community Forks: Because MPL v2.0 explicitly permits community forking of the `4.5.2` codebase, healthcare integration engineers, digital health vendors, and former contributors established the vendor-neutral Open Integration Engine (OIE) project (`github.com/OpenIntegrationEngine/engine`) and related community distributions (such as BridgeLink). OIE maintains 100% channel XML compatibility with Mirth Connect `4.5.2` while continuing open-source security patching (Java 17/21 runtime upgrades, Rhino/JavaScript engine modernization, and dependency CVE remediation) under the MPL v2.0 license.
Frequently Asked Questions
What is the difference between channelMap, connectorMap, and globalMap in Mirth Connect?
In Mirth Connect JavaScript transformers, variable scope is strictly partitioned: connectorMap is local to a single Destination Connector; channelMap (`$c(‘key’, val)`) persists across all destinations within a single message’s lifecycle in that channel; globalChannelMap (`$gc`) persists in memory across all messages processed by that specific channel; and globalMap (`$g`) is shared across all channels on the Mirth Connect Server.
Why did Mirth Connect scripts historically use E4X (`msg[‘PID’][‘PID.5’][‘PID.5.1’].toString()`)?
Mirth Connect embeds the Mozilla Rhino JavaScript engine, which supports ECMAScript for XML (E4X, ECMA-357). Because Mirth converts pipe-delimited HL7 v2 ER7 messages into an internal XML tree (`<HL7Message><PID><PID.5>…`), E4X allows interface developers to traverse and mutate HL7 segments and subcomponents directly using dot or bracket notation in JavaScript.
How does Mirth Connect compare with commercial engines like Rhapsody or Cloverleaf?
While Mirth Connect (and Open Integration Engine) offers unmatched flexibility for JavaScript-savvy developers and low barrier to entry, commercial platforms such as Rhapsody, Corepoint, Infor Cloverleaf, and InterSystems HealthConnect provide vendor-backed 24/7 clinical SLAs, low-code GUI rule builders for non-programmers, and turnkey multi-node failover clustering.
