Mirth consulting, development and support
Build, repair, upgrade and support the Mirth Connect channels your hospital or product depends on. We cover HL7 v2 and FHIR channels, the 4.6 licensing and Open Integration Engine decision, migrations from Cloverleaf, Rhapsody and Corepoint, high availability and day-to-day support.
Book a call with a Mirth engineerOr request a free written Mirth risk review. For hospitals, labs and health tech teams.
The short answer
Nirmitee builds, repairs, upgrades and supports Mirth Connect for US hospitals, labs and health tech companies. We develop HL7 v2, FHIR, X12, database and API channels, help you decide between licensing Mirth Connect 4.6 or later, moving to Open Integration Engine or holding on 4.5.2, migrate interfaces from Cloverleaf, Rhapsody or Corepoint, and run the engine in production with high availability, monitoring and support. Our team has built more than 350 interfaces on Mirth Connect.
Mirth licensing in 2026
On 19 March 2025 NextGen Healthcare moved Mirth Connect to a commercial, proprietary license with version 4.6 and stopped publishing source code. Version 4.5.2 is the last open-source release. Every Mirth owner now picks one of these paths.
| Path | What it means | Choose it when | Plan for |
|---|---|---|---|
| Stay on 4.5.2 | The last open-source Mirth Connect release, with no further fixes from NextGen | You need time to decide and the engine is stable, internal-only and patched at the OS and Java level | Security reviews that flag an unsupported version, and a dated exit plan |
| License Mirth Connect 4.6 or later | Commercial license from NextGen or an authorized reseller; source code no longer published | You want vendor support, new releases and a contract your compliance team recognizes | License cost, Java 17 as the minimum from 4.7 and regression testing of every channel |
| Move to Open Integration Engine | Open-source fork of Mirth Connect 4.5.2 under MPL 2.0; OIE 4.5.2 shipped July 2025 and v4.6.0 in July 2026 with Java 17 as the minimum | You want to stay open source with channel compatibility and no license fee | Community support, so you own patching, testing and on-call or contract a team that does |
| Move to BridgeLink | Innovar Healthcare's open-source engine derived from Mirth Connect, with commercial support available | You want a Mirth-compatible engine with a support contract from a smaller vendor | Version parity, extension support and contract terms checked before you commit |
| Migrate to another engine | Rebuild channels on Rhapsody, Corepoint, Cloverleaf, InterSystems or Interoply | Mirth is one of several engines and you are consolidating | A channel-by-channel rebuild, parallel run and partner retesting |
We scope the engineering for every path. Mirth Connect 4.6 and later licenses are bought from NextGen or its resellers.
Ways to work with us
Pick the engagement that fits where you are. Each one ends with configuration and documentation your team can own.
We review your channels, hosting, license position and the systems you connect, then give you a written recommendation: license Mirth 4.6 or later, move to Open Integration Engine or BridgeLink, or hold on 4.5.2 with a dated exit plan. The free written Mirth risk review is the usual first step. Compare the Mirth alternatives after 4.6
We build new channels and repair existing ones: HL7 v2 feeds such as ADT, ORM and ORU, HL7 v2 to FHIR transformations, JavaScript transformers, and file, database and REST connectors. Each channel ships with its mapping specification, test messages and agreed error handling. See our Mirth interface build cost matrix
For a new Mirth rollout, or a move to a new server, cloud or engine, we plan the install, environments, security settings and cutover with your team and run it alongside you. Our team has built 350+ interfaces on Mirth Connect. Planning a Mirth Connect implementation
We keep running engines healthy: monitoring and alerts, triage of queued and errored messages, database pruning, version and Java upgrades, and channel changes when a partner changes its feed. Response times and escalation are written into the support agreement. What a Mirth support contract should cover
Healthcare workflows, not just connections
Every interface needs a clear clinical purpose, a defined data contract and a plan for the message that cannot be delivered.
Route registration and encounter updates to the systems that need them, with identifiers, event ordering, cancels and A40 merges handled.
Map orders and observations, preserve identifiers and units, and handle corrected results and NAKs.
Map the agreed source messages to the FHIR resources and US Core profiles your application expects, and validate them.
Scheduled or event-driven exchanges with reconciliation, retries and access controls.
What we build
Consulting, development, implementation and support, delivered as workstreams with outputs you can inspect.
New channels for HL7 v2 (ADT, ORM and OML, ORU, SIU, MDM, DFT, VXU), FHIR R4 REST, X12 files, databases and SFTP, with JavaScript transformers, code templates and agreed error handling.
TCP/MLLP · HTTP · SFTP · JDBC · JavaScript
Mirth channel design patterns →ADT, ORU and SIU mapped to Patient, Encounter, DiagnosticReport, Observation and Appointment, validated against US Core 6.1.0 and bound to LOINC and SNOMED CT.
FHIR R4 · US Core 6.1.0 · terminology services
HL7 v2 to FHIR R4 in Mirth →Channel, extension, custom library and database compatibility checked against the target release, then every channel replayed in staging before cutover.
3.x and 4.x to 4.5.2, 4.6+ or OIE · Java 17
Mirth 4.6 commercial transition →Interfaces moved from Cloverleaf, Rhapsody or Corepoint to Mirth or OIE, or off Mirth to another engine, with both engines running side by side on replayed traffic.
Tcl and Xlate · Rhapsody filters · Corepoint action lists
Infor Cloverleaf integration services →Active-passive or clustered Mirth on a shared PostgreSQL database, load-balanced MLLP, recovery of in-flight messages and tested failover on AWS, Azure or on-premise.
PostgreSQL · load balancers · Terraform
Mirth Connect high availability →Alerts on queued and errored messages, silent channels and heap use, data pruning, version and Java upgrades, and channel changes when a partner changes its feed.
Alerting · pruning · CI/CD · on-call
Reliable Mirth monitoring in production →Buyer decisions
Engine migrations fail on hidden logic, not on connections. This is where the work sits for each source engine.
| Source engine | What maps across | What gets rebuilt | How we prove it |
|---|---|---|---|
| Infor Cloverleaf | Threads, routes and protocol settings map to Mirth channels and connectors | Tcl TPS procedures and Xlate translations become JavaScript transformers | Replay production samples through both engines and diff every output message |
| Rhapsody | Communication points and routes map to source and destination connectors | Filters, mappers and embedded JavaScript | Parallel run on replayed traffic, then partner-by-partner cutover |
| Corepoint | Connections and message models map to channels and data types | Action lists and Corepoint-specific alerting | Output diff reports signed off per interface before cutover |
| Mirth to another engine | Channel exports, code templates and global scripts are inventoried | JavaScript transformers and custom Java libraries | The same replay-and-diff method in reverse, with rollback kept ready |
Every migration keeps the old engine ready for rollback until each partner signs off.
Integration boundaries
Clear ownership keeps upgrades and migrations predictable.
Mirth Connect 4.6 and later licenses come from NextGen or its resellers. We help you size the license and compare it with OIE and BridgeLink.
Epic, Oracle Health, labs, registries and payers configure their side and test with us. We run the partner correspondence.
Servers, database, network and backups run in your cloud or data center, or we operate them under a support agreement.
Channels, code templates, scripts, alerts, runbooks and the CI/CD pipeline that promotes channels between environments.
We sign a BAA, work inside our ISO 27001:2022 certified management system, and use de-identified test messages until production.
Deliverables
Configuration and documentation your team can own.
Every channel, connector, extension and custom library, with owner, consumer and risk.
Exported channels and code templates in git, promoted between environments by pipeline.
Field and terminology mappings with annotated test messages for each interface.
Replay diff reports and partner sign-offs for every interface that moves.
Failover design, alert rules and dashboards, tested before go-live.
Replay and recovery steps, escalation path and response times agreed in writing.
Delivery phases
Most channel builds and upgrades run 4 to 12 weeks. Engine migrations are planned in waves of interfaces.
1 to 2 weeks
Channel inventory, version and license position, risk register and a recommended path
2 to 8 weeks
Channels or migrated interfaces in version control, with mapping specifications
2 to 4 weeks
Replay diffs, partner test sign-off and a performance check
1 to 2 weeks, then ongoing
Cutover, hypercare, monitoring and the support agreement
Cost drivers
You get a fixed scope and price after the assessment. These factors move it.
A pass-through ADT route and a transformer-heavy HL7 v2 to FHIR channel are very different builds.
Mirth 4.6 license fees, or the support effort you take on with OIE or 4.5.2.
Tcl, Rhapsody filters and custom Java libraries are the slowest parts of any migration.
Clustering, disaster recovery and cloud or on-premise hosting.
Each partner's retest window and sign-off process.
Business-hours support or round-the-clock on-call, and how many channels are covered.
Proof
Client names are withheld. The repositories linked here are public.
Our team has built more than 350 interfaces on Mirth Connect for hospitals, labs and health tech products.
Channels, transformers and code templates from our Mirth work: ADT to FHIR bundles, ORU to DiagnosticReport, Java 17 HTTP calls and Kafka producers.
View the cookbook on GitHub →Our open-source operations layer for Mirth Connect and OIE: web administration, clinical observability and channel CI/CD.
View OpenMirth on GitHub →When a product needs HL7, FHIR and X12 behind one API, Interoply runs the connectors with monitoring and replay built in.
See Interoply →We are ISO 27001:2022 certified and sign Business Associate Agreements for work that touches patient data.
FAQ
Assessment of your current engine, channel development, HL7 v2 and FHIR transformations, 4.6 and OIE upgrades, migrations from Cloverleaf, Rhapsody or Corepoint, high availability, monitoring, CI/CD for channels, and ongoing support and maintenance.
No. On 19 March 2025 NextGen Healthcare released Mirth Connect 4.6 under a commercial, proprietary license and stopped publishing source code. Version 4.5.2 is the last open-source release. Open-source users can stay on their version, move to 4.5.2, license 4.6 or move to a fork such as Open Integration Engine.
Open Integration Engine (OIE) is an open-source fork of Mirth Connect 4.5.2 under the Mozilla Public License 2.0. It shipped OIE 4.5.2 in July 2025 and v4.6.0 in July 2026 with Java 17 as the minimum. Channels move across with little change; support comes from the community or a team you contract.
Stay on 4.5.2 only as a short, planned hold. License 4.6 when you want vendor support and new releases. Move to OIE or BridgeLink when you want to stay open source. Our assessment compares all three against your channels, security requirements and team.
Mirth Connect 4.6 and later is licensed by NextGen Healthcare, so the cost depends on the license and support level you choose and how many servers you run. OIE and 4.5.2 carry no license fee but move patching and support onto your team. Our Mirth 4.6 pricing and total cost of ownership guides break down each option.
Yes. We inventory every thread, route or action list, rebuild the logic as Mirth channels and transformers, then run both engines side by side on replayed production traffic and diff the output before each partner cuts over.
Yes. We design active-passive or clustered Mirth on a shared PostgreSQL database with load-balanced MLLP, recovery of in-flight messages and tested failover, on AWS, Azure, Google Cloud or on-premise.
Monitoring and alerts, triage of queued and errored messages, database pruning, version and Java upgrades, certificate and credential rotation, and channel changes when a partner changes its feed. Response times and escalation are agreed in writing.
Yes. We plan and run new Mirth installs, cloud moves and engine migrations with your team, from environments and security settings through testing, cutover and handover. We are ISO 27001:2022 certified and sign BAAs when the work involves patient data.
Yes. Mirth channels can map HL7 v2 segments to FHIR R4 resources and post them to a FHIR server. Production-grade conversion needs explicit mappings, terminology binding and validation against the target profiles such as US Core 6.1.0.
A new channel or a single upgrade typically takes 4 to 12 weeks including partner testing. Engine migrations are planned in waves, with each wave running in parallel before cutover.
Channel count and complexity, the licensing path, custom code in the source engine, high-availability and hosting needs, partner testing windows and the support coverage you want. We give a fixed scope after the assessment.
Next step
Share your Mirth version, hosting, channel count and connected systems. We reply with the risks on your target release, the licensing path that fits and a fixed scope.
From our Engineering Knowledge Base
Learn common Mirth Connect REST API pitfalls and best practices for automating channel deployment, version control, and DevOps workflows.
Learn how to implement message replay, dead letter queues, and failed message recovery in Mirth Connect for resilient healthcare integrations.
Learn how to build scalable population health pipelines using FHIR Bulk Data Export, Mirth Connect, and automated healthcare data processing.
Scope the right next step
Tell us what you have and what needs to change. An engineer replies with the scope, dependencies and delivery approach.
Please don't include patient data, credentials or sensitive system details.
Prefer a conversation? Book a callMirth Connect is a product of NextGen Healthcare. Open Integration Engine and BridgeLink are separate open-source projects.
