Mirth Connect Consulting and Integration Services

Mirth Connect is a Java-based integration engine that sits between clinical systems, receiving messages, transforming them and routing them onward. Each interface is configured as a channel with a source connector, transformation logic in JavaScript and one or more destinations. It handles HL7 v2 over MLLP, FHIR over HTTPS, X12, DICOM, database connections and file transfer, which is why it ends up carrying such a broad range of traffic in most estates that adopt it.

Channel development is the core of most Mirth engagements, and the variance between a simple channel and a difficult one is far wider than channel count suggests. A one-way feed from a system that follows the HL7 specification cleanly is a few days of work. A bidirectional interface against a system that adds proprietary segments, deviates under load and sends inconsistent identifiers is weeks. We scope against the source system’s actual behavior rather than its documentation, because those routinely differ.

HL7 v2 carries the majority of clinical traffic in US healthcare and will for years. Mirth handles the full message set, and most of our engine work is v2 interface development, remediation or support. The message families below account for nearly all production traffic, and the engineering difficulty is concentrated in identity, ordering and acknowledgement rather than in parsing, which is the part everyone expects to be hard.

Mirth is frequently assumed to be a v2-only engine, and it is not. It serves and consumes FHIR R4 over HTTPS, which makes it a practical bridge between the messaging estate an organization already runs and the API surface its newer systems expect. In most deployments we build, FHIR and v2 coexist deliberately: v2 for high-throughput clinical events, FHIR for retrieval, patient-facing applications and analytics consumers who want JSON rather than pipes.

The licensing position changed in March 2025, when NextGen Healthcare moved Mirth Connect to a single commercial licence at version 4.6. Version 4.5.2 is the final open-source release under the Mozilla Public License 2.0 and receives no updates, security patches or bug fixes. Open Integration Engine is the community-governed fork of that codebase and the maintained open-source continuation. Every organization running Mirth now has a decision to make, and increasingly our work is helping make and execute it.

Most organizations come to us for support rather than for a build, and usually because an interface failed in a way nobody saw coming. A retainer covers message-layer monitoring, incident response, channel maintenance and upgrade management, handled by engineers who already understand your configuration. That last point is what makes third-party support work or not work, because an engineer who has to reverse-engineer your channels before diagnosing anything is slow at exactly the wrong moment.

Mirth work is priced by scope with a stated number and timeline rather than by hour against an open estimate. The drivers are channel complexity rather than channel count, source system quality, validation depth, environment count and whether anyone will operate the engine afterward. The engine itself is free at 4.5.2 and on Open Integration Engine, which means engineering and operations account for essentially the entire cost in those deployments.

Useful proof is not the engagement with the largest number attached. It is the one whose constraint resembles yours: an undocumented engine, a feed that drifted, a platform that outgrew its architecture. The engagements below involved production clinical or financial data, live users and a compliance posture that had to hold, and we can discuss the architecture decisions behind them in technical depth on a call, including the ones we would make differently today.