v2 segments
MSHEVNPIDPV1
FHIR R4
PatientEncounterMessageHeader
PV1 admit-attending populates Encounter.participant; Z-segments need custom extension URLs to round-trip safely.
Mirth Connect Services & Consulting
Mirth Connect services across the lifecycle of healthcare's most widely deployed integration engine. Channel development, AWS and Azure cloud deployment, channels-as-code DevOps, and 24/7 managed support across HL7 v2, FHIR R4, DICOM, and EDI X12 — for Mirth Connect (now NextGen Connect) and the MPL 2.0 community forks Open Integration Engine and BridgeLink.
MIRTH CONNECT
Production Mirth: channels, clouds, and SLAs.
From channel development to cloud deployment, channels-as-code DevOps, and 24/7 managed services — Saga IT runs the full lifecycle of healthcare's most widely deployed integration engine. Mirth Connect, Open Integration Engine, and BridgeLink all welcome.
Workflow Patterns
Four architecture shapes Mirth Connect runs every day.
Four production-shape workflow patterns we build for — each with its own architecture, tradeoffs, and reference implementations. Pick a pattern to see what we deliver.
HL7 v2 ↔ FHIR R4 inside one engine
Modernize the integration layer without ripping out v2.
Most production environments will run HL7 v2 internally for years. Mirth Connect is the right place to bridge — keep your existing MLLP listeners untouched while exposing FHIR R4 endpoints on the same engine, mapping ADT to Patient/Encounter, ORU to Observation, ORM to ServiceRequest, with per-EHR conformance baked into the transformer layer.
- ADT^Axx → Patient + Encounter + Coverage with version-aware field mapping
- ORU^R01 → Observation + DiagnosticReport + Specimen with LOINC mapping
- Bidirectional FHIR → v2 reverse-mapping for write-back from cloud apps
- USCDI v3 conformance + CMS-9115 / TEFCA endpoint exposure on the same engine
One engine, many EHRs
Route the same patient context across every EHR in your estate.
Health systems that ran M&A consolidation are often running 2-3 EHRs simultaneously — Epic at the flagship, Meditech at the community sites, athenahealth at the ambulatory practices. One Mirth Connect instance routes the same ADT broadcast, the same MRN reconciliation, the same lab result feed to every endpoint, with per-EHR conformance and version-aware transformations isolated per channel.
- Single ADT source → fan-out to Epic Bridges, Oracle Health Open Engine, Meditech NPR/MOX
- MRN reconciliation channel for cross-EHR patient identity
- Per-EHR Z-segment handling isolated to its own transformer
- Channel-version pinning so an upstream EHR upgrade doesn't break downstream
CPOE → ancillary → result-back
The classic Mirth job — bidirectional order workflows that just work.
The most common Mirth Connect channel pattern is the order/result loop: an ORM goes out from the EHR's CPOE to the lab / radiology / pharmacy system, and an ORU comes back with the result, with DFT^P03 charge messages riding on the side for the billing system. The transactional integrity matters — every order needs its result, every result needs its charge.
- ORM^O01 outbound from CPOE with placer-order-number tracking
- ORU^R01 inbound with structured OBX values and LOINC coding
- DFT^P03 charge capture forked from result completion
- Reconciliation queue for orders missing results past SLA threshold
Mirth → AWS HealthLake / Azure FHIR / GCP Healthcare
Bridge on-prem MLLP into managed cloud FHIR stores.
Hospital data still originates on-prem in HL7 v2 over MLLP — but your analytics, ML, and patient-facing apps want FHIR R4 in a managed cloud datastore. Mirth Connect runs in the cloud, listens to on-prem MLLP over site-to-site VPN, transforms in real time, and writes to AWS HealthLake, Azure Health Data Services, or GCP Healthcare FHIR store. Same engine, three cloud-native destinations.
- Mirth Connect on EKS / AKS / GKE with HA autoscaling and KMS-encrypted secrets
- Site-to-site VPN or PrivateLink ingress from on-prem MLLP source
- Transformation to managed FHIR store (HealthLake / FHIR API / Healthcare API)
- OMOP / dbt downstream for analytics teams; SMART launch for patient apps
Our Services
Mirth Connect Services
Mirth Connect software is healthcare's most widely deployed integration engine — the open-source-rooted middleware now sold commercially as NextGen Connect, with two MPL 2.0 community forks (Open Integration Engine and BridgeLink) preserving open-source licensing. Saga IT provides full lifecycle Mirth Connect services: channel development, cloud deployment, channels-as-code DevOps, and 24/7 managed support — pick a service to see what the work looks like.
24/7 monitoring · MDDS Console · SLAs
We run your Mirth Connect environment 24/7
After go-live, our managed-services team monitors channel throughput, queue depth, JVM heap, and message-error rates 24/7. Alerts route through PagerDuty/Opsgenie with SLA-backed response times. MDDS Console provides AI-assisted diagnostics for channel failures, root cause analysis, and capacity planning across all your Mirth Connect instances.
- Channel-level uptime SLAs (99.95% on critical feeds)
- MDDS Console AI diagnostics for failed-message triage
- JVM tuning, garbage collection optimization, thread pool sizing
- Version upgrade management with compatibility testing
HL7 v2 · FHIR · DICOM · EDI
Production-grade Mirth Connect channels
We build Mirth Connect channels for every major healthcare standard — HL7 v2 (ADT, ORM, ORU, SIU, MDM, DFT), FHIR R4 REST, DICOM C-STORE/C-FIND/C-MOVE, EDI X12 (837/835/270/271), and database/file/web-service transports. Each channel ships with message validation, error handling, retry logic, and full code-template documentation.
- HL7 v2 over MLLP/TCP with full ACK/NAK + Z-segment coverage
- FHIR R4 REST with Bundle transactions + US Core profile validation
- DICOM channels for PACS, modality, and VNA integration
- EDI X12 837/835 claims + 270/271 eligibility workflows
AWS · Azure · Docker · Kubernetes
Production cloud architectures, HIPAA-compliant
We deploy Mirth Connect on AWS or Azure with high-availability clustering, encrypted RDS/PostgreSQL backends, multi-AZ failover, and infrastructure-as-code templates. Every cloud environment is HIPAA-eligible by default — encryption at rest + in transit, network isolation, audit logging, and BAA-eligible services only.
- AWS reference architecture: EC2 + ALB + RDS Multi-AZ + CloudWatch
- Azure reference architecture: VMSS + Azure Database for PostgreSQL
- Docker + Kubernetes deployment for cloud-native environments
- Terraform / CloudFormation templates for repeatable provisioning
Channels as code · CI/CD · GitOps
Channel development with Git, code review, and CI/CD
Manage Mirth Connect channels as version-controlled code. Pull channels into a Git repo, review JavaScript transforms in pull requests, run automated tests in GitHub Actions or Jenkins, and promote changes across dev/staging/prod with audit trails. The same DevOps workflows your application engineers already use — powered by our open-source MirthSync product.
- CLI for pull/push channel synchronization
- GitHub Actions + Jenkins CI/CD pipelines for channel promotion
- Pull-request review workflows for JavaScript transform changes
- VS Code extension for in-IDE channel editing
Channel Types
Every Major Healthcare Data Standard
Mirth Connect speaks every major healthcare data transport. Each channel is purpose-built for its protocol with optimized connectors, message validation, and error handling.
H2
HL7 v2
ADT, ORM, ORU, SIU, MDM, DFT over MLLP/TCP with ACK/NAK retries and Z-segment coverage.
FhFHIR R4
RESTful FHIR with OAuth2, Bundle transactions, US Core profile validation, Bulk $export.
DcDICOM
C-STORE, C-FIND, C-MOVE, WADO-RS for PACS, modalities, and VNA integration.
EXEDI X12
837/835 claims, 270/271 eligibility, 276/277 status workflows.
DbDatabase
PostgreSQL, SQL Server, Oracle, MySQL — readers, writers, stored-procedure execution.
FsFile / SFTP
CSV, XML, JSON, flat files over SFTP/SCP/SMB with locking + dedup.
WsWeb Service
SOAP and REST endpoints — webhooks, AWS API Gateway, third-party APIs.
Need something else? Mirth Connect supports custom transports via Java connectors and JavaScript transforms. Talk to us about your channel.
HL7 v2 ↔ FHIR R4
What Mirth Connect Actually Transforms
Six HL7 v2 message families cover ~95% of clinical traffic in production hospitals. Here's what Mirth Connect channels emit on the FHIR R4 side — segment-by-segment, with the gotchas that catch first-time integrators.
v2 segments
MSHORCOBR
FHIR R4
ServiceRequestPatient
Each OBR becomes one ServiceRequest; ORC-2 placer-order-number maps to ServiceRequest.identifier with a system URI.
v2 segments
MSHOBROBX
FHIR R4
ObservationDiagnosticReport
LOINC codes in OBX-3 transfer cleanly; abnormal flags (OBX-8) become Observation.interpretation with v3-codesystem mappings.
v2 segments
MSHSCHPIDRGSAIL
FHIR R4
AppointmentServiceRequest
A single SIU yields one Appointment plus the ServiceRequest that drove it; participant references encode each resource (patient, provider, room) without producing separate Appointment entries.
v2 segments
MSHEVNPIDTXAOBX
FHIR R4
DocumentReferenceBinary
Free-text OBX-5 content is base64-encoded into a Binary resource; TXA metadata populates DocumentReference attributes.
v2 segments
MSHEVNPIDFT1
FHIR R4
ChargeItemEncounter
FT1 transaction codes map to ChargeItem.code; the clinical context lives in a linked Encounter via ChargeItem.context.
Cloud Architecture
Production AWS + Azure Reference Architectures
Same Mirth Connect, two cloud baselines — both HIPAA-eligible, both with multi-AZ failover, encrypted databases, infrastructure-as-code, and CloudWatch / Azure Monitor observability built in.
Mirth Connect on AWS
Our reference Mirth Connect on AWS architecture runs the application server on EC2 (m6i family, with auto-scaling groups across multiple Availability Zones), backed by RDS PostgreSQL with Multi-AZ failover for the channel and message store. An Application Load Balancer terminates TLS 1.3 in front of the cluster; CloudWatch handles metrics, logs, and alarms; S3 archives long-term message logs with lifecycle policies. The full stack is HIPAA-eligible, BAA-covered, and provisioned via Terraform — channel deploys flow through the channels-as-code pipeline above with no manual console clicks.
- EC2 Auto Scaling + Application Load Balancer
- RDS PostgreSQL Multi-AZ with KMS encryption
- CloudWatch + S3 audit log archival
- Terraform + AWS Systems Manager for IaC
Mirth Connect on Azure
Our Mirth Connect on Azure baseline uses Virtual Machine Scale Sets (VMSS) for the Mirth application tier, Azure Database for PostgreSQL (Flexible Server with zone-redundant HA) for the persistence layer, and Azure Application Gateway for TLS termination and WAF. Azure Monitor + Log Analytics handle observability; Key Vault manages secrets and TLS certificates; Private Endpoints isolate the database from public networking. The same Mirth Connect software, the same channel-compatible deployment model, with Azure-native HIPAA controls and Bicep / Terraform IaC.
- Virtual Machine Scale Sets + Application Gateway (WAF)
- Azure Database for PostgreSQL Flexible Server (zone-redundant)
- Azure Monitor + Log Analytics + Key Vault
- Bicep / Terraform IaC + Azure DevOps Pipelines
Healthcare integration delivered for
Decision Stage
Mirth Connect vs Alternatives
How Mirth Connect compares to its MPL 2.0 community forks (Open Integration Engine, BridgeLink) and the major commercial integration engines. Saga supports the platforms in bold — for the rest, we'll point you to the right specialist.
| Platform | License | FHIR R4 | Hosting | Typical fit | Saga supports? |
|---|---|---|---|---|---|
| Mirth Connect (NextGen) | Commercial (since Mar 2025) | Yes (4.x) | Self-hosted + Mirth Cloud Connect (NextGen-hosted SaaS) | Existing Mirth shops staying on commercial license | Yes — full lifecycle |
| Open Integration Engine | MPL 2.0 (free) | Yes (channel-compatible with Mirth 4.x) | Self-hosted; we deploy on AWS / Azure | Mirth shops escaping the commercial license; new deployments | Yes — full lifecycle |
| BridgeLink | MPL 2.0 (free) | Yes (channel-compatible with Mirth) | Self-hosted or AWS Marketplace support | Mirth shops who prefer a vendor-stewarded fork | Yes — full lifecycle |
| Rhapsody (Lyniate / Orion Health) | Commercial | Yes | Self-hosted + Rhapsody Cloud (managed by Lyniate) | Enterprise health systems wanting polished commercial UX | No — refer to Lyniate |
| Iguana (iNTERFACEWARE) | Commercial | Yes | On-prem, cloud, or iNTERFACEWARE-hosted | Teams prioritizing Lua-based rapid channel development | No — refer to iNTERFACEWARE |
| Corepoint (Lyniate / Rhapsody) | Commercial | Yes | Self-hosted; cloud options via Lyniate | Mid-market hospitals on Lyniate stack | No — refer to Lyniate |
| Cloverleaf (Infor) | Commercial | Yes (via add-on modules) | Self-hosted; check with Infor for managed options | Legacy Infor shops; uncommon in greenfield deployments | No — refer to Infor |
Hosting / FHIR / pricing details change frequently — confirm directly with each vendor before making a buying decision. For a deeper comparison of the three Mirth-lineage forks, see our OIE vs BridgeLink vs Mirth Connect writeup. For broader category context, the Mirth Connect alternatives post covers Rhapsody, Iguana, Corepoint, and Cloverleaf in more detail.
Migration Paths
Three Mirth Connect Migration Patterns
Every Mirth Connect deployment is reckoning with at least one of these moves right now: NextGen's 2025 license change, the lag of older 3.x clusters, or the on-prem-to-cloud lift. We've done all three at scale.
Total Cost of Ownership
What does running Mirth Connect actually cost?
Mirth Connect TCO has four cost lines, only one of which has a vendor-set price. Knowing how the other three behave is the difference between a clean budget and a surprise.
01
Software license
$0 to vendor-set
Commercial Mirth Connect is now per-channel or enterprise pricing through NextGen Healthcare — contact NextGen directly for current quotes; pricing varies by org size and channel count. Open Integration Engine and BridgeLink are free under MPL 2.0 — same channel format, same Java runtime, no license cost.
Most cost relief lives here.
02
Cloud infrastructure
$300 – $2,000 / month
Single-node AWS or Azure deployment (EC2/VMSS + managed PostgreSQL + ALB/Application Gateway + monitoring) typically runs $300–$800/mo. High-availability multi-AZ clusters with active-active failover land at $800–$2,000/mo. Reserved instances or savings plans typically cut steady-state spend 20–35%.
Predictable; scales with channel volume.
03
Implementation
Project-based
One-time engagement to stand up channels, configure cloud infrastructure, and validate against parallel-run message volumes. Single-channel project: 2–6 weeks. Multi-hospital cluster migration: 3–6 months. Pricing is fixed-fee or T&M depending on scope clarity.
One-time; amortized over the deployment's lifetime.
04
Managed services
Monthly retainer
24/7 monitoring, channel-level uptime SLAs (99.95% on critical feeds), JVM tuning, version upgrades, and incident response. Right-sized to your channel count and SLA needs. Bundles with MDDS Console AI-assisted diagnostics for failed-message triage.
Optional; replaces in-house on-call.
The honest read: for organizations escaping the commercial license, the OIE / BridgeLink path eliminates line 01 entirely. Lines 02–04 are where Saga's engagements add value — the cloud architecture, the channel work, and the operational support are where Mirth Connect either thrives or stalls. Book a consultation for a TCO model tailored to your specific org size and channel inventory.
Specialty channels by domain
Mirth Connect builds we ship — labs, imaging, EDI, pharmacy, patient apps, public health.
The Mirth Connect channel builds Saga delivers most often, across implementation, migration, and 24/7 managed-services engagements — each anchored on a vertical use case with its own protocol mix, vendor quirks, and reference patterns. Pick a domain to see what we build.
Lab-specialty channels in Mirth Connect
Beyond the generic order/result loop (covered under workflow patterns above), the lab specialties each have their own protocol quirks — anatomic pathology with its multi-stage accession lifecycle, clinical pathology with its instrument-middleware layer, blood-bank with its component-traceability requirements, and molecular with its panel-driven result structures. Mirth Connect is the engine that connects each of these to the EHR, the billing system, and the patient record cleanly.
- HL7 v2.5.1
- LOINC
- AP / CP / BB
- Instrument middleware
What we deliver
- Anatomic pathology workflow — accession lifecycle, addenda, amended reports
- Blood-bank component traceability (donor / unit / cross-match / transfusion)
- Instrument-middleware adapters for major analyzer vendor families
- Microbiology susceptibility panels with sensitivity grids in OBX repeats
- Molecular / NGS panel results with structured variant + LOINC mapping
Mirth Connect as the HL7 ↔ DICOM bridge
The Mirth-runtime view of imaging: channel patterns that translate between HL7 v2 (the EHR / RIS / billing side) and DICOM (the modality / PACS side) — Modality Worklist queries, accession reconciliation, structured-report write-back. The broader imaging integration practice (PACS, VNA, IHE conformance, AI workflow) lives on our medical imaging integration page.
- Medical Imaging
- DMWL
- DICOM SR
What we deliver
- ORM^O01 / SIU^Sxx → DICOM Modality Worklist channel pattern
- DICOM Structured Report → HL7 ORU^R01 with embedded report payload
- AccessionNumber + StudyInstanceUID reconciliation in transformer JS
- Charge capture (technical + professional) on study-completion events
X12 EDI healthcare channels in Mirth
The Mirth-runtime angle on healthcare EDI: channel templates for the 837 / 835 / 270 / 271 / 276 / 277 transaction set, with X12 5010 validation in the transformer, clearinghouse-route switching at the destination connector, and denial-loop reconciliation back into the source. Full EDI bridge architecture, payer-program selection, and Da Vinci alignment live on our CMS interoperability page.
- CMS interop
- X12 5010
- Da Vinci
What we deliver
- X12 5010 schema validation inside the transformer layer
- Clearinghouse-route destination switching (per-payer, per-state, per-program)
- Denial-loop reconciliation: 277CA / 835 → source workqueue
- EDI ↔ FHIR mapping when downstream is a Da Vinci program
Pharmacy / eRx channels
Pharmacy workflows that bridge the hospital CPOE / EHR side (HL7 RDE^O11 pharmacy orders) with the pharmacy world (NCPDP SCRIPT for retail / mail order, PDMP queries, EPCS for controlled substances). Mirth sits at the boundary and handles the protocol translation, formulary checks, allergy / DUR alerting, and the audit trail PDMP / EPCS compliance requires. Includes Surescripts directory integration where the workflow is community-pharmacy facing.
- NCPDP SCRIPT
- EPCS
- PDMP
- Surescripts
What we deliver
- RDE^O11 pharmacy order routing from EHR CPOE to pharmacy system
- NCPDP SCRIPT 2017071 + outbound retail / mail-order pharmacy feeds
- PDMP queries for controlled-substance prescribing decision support
- EPCS-compliant audit trail for DEA Schedule II–V prescriptions
- Surescripts directory + formulary check + drug-interaction screening
Patient app feeds from Mirth
Mirth Connect as the FHIR endpoint that powers patient-facing apps, portals, and consumer health platforms. We build the v2 → FHIR R4 conversion inside the engine (ADT → Patient + Encounter, ORU → Observation, etc.), expose FHIR subscription topics for real-time push to mobile / web clients, and handle the SMART on FHIR launch handshake for apps embedded inside the EHR. CMS-9115 patient-access-API compliance baked in. For the FHIR side of the story see our FHIR API integration service.
- FHIR APIs
- SMART launch
- Subscriptions
- CMS-9115
What we deliver
- HL7 v2 → FHIR R4 conversion in real time on inbound clinical events
- FHIR Subscription topics for patient-app push (Observation, Appointment)
- SMART on FHIR launch — both EHR-launched and standalone-launched apps
- CMS-9115 Patient Access API conformance — USCDI v3 data classes
- Portal / app authentication via OAuth 2.0 + PKCE on the Mirth FHIR endpoint
Public health reporting from Mirth
Outbound reporting channels to state and federal public health agencies — immunizations to state IIS via HL7 VXU, syndromic surveillance to BioSense / NSSP, cancer registries via NAACCR XML, and clinical document push to state HIEs via Consolidated CDA. Mirth Connect handles the transport (TCP, sFTP, NHIN, IHE XDR), the message construction, the timing rules, and the acknowledgment / error reconciliation each agency expects. Useful for hospitals, public-health-software vendors, and EHR add-on integrators.
- C-CDA R2.1
- NAACCR XML
- IHE XDR · XDS.b
- NSSP
What we deliver
- VXU^V04 immunization reporting to state IIS / CDC platforms
- Syndromic surveillance to NSSP / BioSense via HL7 ADT^A04 stripped feeds
- NAACCR XML cancer registry reporting (NAACCR v22 / v23)
- Consolidated CDA (C-CDA R2.1) document push to state HIEs / regional networks
- IHE XDR / XDS.b document submission profiles for cross-network exchange
Case Studies
Mirth Connect in Production
Real-world Mirth Connect engagements — from multi-hospital migrations to active-active AWS clusters to MirthSync-driven CI/CD at scale.
Multi-Hospital Mirth Connect Cluster Migration
A regional health system upgrading from Mirth Connect 3.x to 4.x across 12 hospitals — including channel rebuilds, cluster reconfiguration, and parallel-run validation against 200K+ daily messages.
Mirth 3.x cluster
// existing channel inventory
channels: 218
code_templates: 47
version: "3.12.0"
channels: 218
code_templates: 47
version: "3.12.0"
Compatibility test + rebuild
migrate(channels, {
target: "4.6.0",
parallel: true,
validate: "per_channel"
})
target: "4.6.0",
parallel: true,
validate: "per_channel"
})
12-hospital production
Migrating Mirth Connect to AWS, evaluating the new commercial license, or scaling to a high-availability cluster? Let's scope your project.
Book a Mirth Connect Consultation Frequently Asked Questions
Common Questions
NextGen Healthcare owns Mirth Connect. The platform was originally developed by Mirth Corporation, acquired by Quality Systems Inc. (now NextGen Healthcare) in 2013. In March 2025, NextGen moved Mirth Connect (versions 4.6+) from open-source to a commercial per-channel license. The previously open-source codebase continues as two MPL 2.0 community forks: Open Integration Engine (OIE), governed by a non-profit Steering Committee, and BridgeLink. NextGen continues to develop and sell the commercial Mirth Connect product alongside its broader EHR business.
Mirth Connect's open-source status changed significantly in March 2025 when NextGen Healthcare transitioned the product to a commercial licensing model. Prior to that change, Mirth Connect had been available under an open-source MPL license for over a decade. Two MPL 2.0 community forks — Open Integration Engine (OIE), a vendor-neutral fork governed by a non-profit Steering Committee, and BridgeLink — continue to be available under open-source licensing. Organizations that relied on Mirth Connect's free licensing now have the option to either adopt NextGen's commercial terms or migrate to one of the open-source forks, both of which maintain full channel compatibility with Mirth Connect.
In March 2025, NextGen Healthcare discontinued the free open-source distribution of Mirth Connect and moved to a commercial per-channel or enterprise licensing model. This change affected organizations that had been running Mirth Connect without a commercial agreement. NextGen continues to develop and support Mirth Connect (also branded as NextGen Connect) as a commercial product with enterprise features. In response, the community launched the Open Integration Engine (OIE) — a vendor-neutral MPL 2.0 fork governed by a non-profit Steering Committee — which preserves the original open-source licensing terms. BridgeLink, supported by its maintaining vendor, is a second MPL 2.0 fork.
Open Integration Engine (OIE) is a community-maintained fork of Mirth Connect created after NextGen Healthcare changed Mirth Connect's licensing in 2025. It is a vendor-neutral project governed by a non-profit Steering Committee, with a multi-vendor maintainer and support ecosystem. Both platforms share the same core codebase and are fully channel-compatible — you can export channels from Mirth Connect and import them directly into OIE. The key differences are licensing (OIE is open source under MPL 2.0, Mirth Connect is commercial), support (OIE is supported by its multi-vendor community including Saga IT, Mirth Connect by NextGen), and roadmap (each platform is now evolving independently). Saga IT provides full consulting and support for both platforms.
Migration from Mirth Connect to OIE is straightforward because both platforms share the same channel format and Java-based architecture. The process involves deploying an OIE instance in parallel, exporting channels and code templates from Mirth Connect, importing them into OIE, and running a parallel validation period before cutting over production traffic. Custom Java libraries, JavaScript transforms, and database configurations transfer without modification. Saga IT's migration methodology includes full compatibility testing, performance benchmarking, and a documented rollback plan to ensure zero downtime during the transition.
Mirth Connect and NextGen Connect Integration Engine are the same product. Quality Systems Inc. acquired Mirth Corporation in 2013 and rebranded the open-source Mirth Connect as NextGen Connect Integration Engine after Quality Systems itself rebranded as NextGen Healthcare in 2019. Despite the name changes, the community and most healthcare organizations still refer to it as Mirth Connect. In March 2025, NextGen Healthcare changed the licensing model, making versions 4.6 and later commercial-only (no longer open source). Two open-source forks of Mirth Connect have since emerged under MPL 2.0: the Open Integration Engine (OIE), a vendor-neutral community fork governed by a non-profit Steering Committee, and BridgeLink. Saga IT supports all variants — commercial Mirth Connect, OIE, BridgeLink, and migration between platforms.
The most direct alternatives to Mirth Connect are the two open-source MPL 2.0 forks of its codebase: the Open Integration Engine (OIE), a vendor-neutral community fork governed by a non-profit Steering Committee, and BridgeLink. Both preserve full channel compatibility with existing Mirth Connect deployments. For organizations evaluating other integration engines entirely, the healthcare market includes Rhapsody, Corepoint Integration Engine, Iguana by iNTERFACEWARE, and Cloverleaf by Infor. Each has different strengths — Rhapsody and Corepoint offer polished enterprise UIs, Iguana focuses on rapid development, and the Mirth-lineage forks preserve the open-source flexibility that made Mirth Connect popular. The best choice depends on your existing channel inventory, budget, and team familiarity.
Deploying Mirth Connect on AWS requires an EC2 instance (or ECS container) running the Mirth Connect application server, an RDS PostgreSQL or MySQL database for the configuration and message store, and VPC networking with private subnets for HIPAA compliance. A production deployment should include an Application Load Balancer for TLS termination, CloudWatch for monitoring and alerting, and S3 for log archival. For high availability, deploy across multiple Availability Zones with auto-scaling groups and database Multi-AZ failover. Saga IT provides Terraform templates and managed deployment services for AWS Mirth Connect environments.
MirthSync is Saga IT's open-source tool for managing Mirth Connect channels as version-controlled code. It connects to a Mirth Connect instance via the REST API, serializes channels, code templates, and configuration maps into a structured file format, and stores them in a Git repository. This enables pull-request code reviews for channel changes, diff-based auditing of transform logic, and automated CI/CD promotion across development, staging, and production environments. MirthSync is available as a CLI tool, a Mirth Connect admin console plugin, and a VS Code extension.
Mirth Connect includes a built-in revision history that tracks changes within the application database, but it lacks key capabilities that modern DevOps workflows require. MirthSync stores channels as files in Git, enabling branch-based development, pull-request reviews, merge conflict resolution, and integration with CI/CD pipelines like GitHub Actions or Jenkins. Mirth Connect's native history is limited to a single timeline per channel with no branching, no cross-channel diffs, and no mechanism for promoting changes between environments. MirthSync fills these gaps by treating Mirth channels the same way development teams treat application source code.
Yes. NextGen Healthcare continues to offer commercial support for Mirth Connect under their enterprise licensing agreements. For organizations that prefer the open-source path, a multi-vendor ecosystem (including Saga IT) provides commercial support for Open Integration Engine (OIE), and BridgeLink is supported by its maintaining vendor (including via AWS Marketplace). Saga IT offers consulting, managed services, and 24/7 support for Mirth Connect, OIE, and BridgeLink regardless of your licensing arrangement. Our team has been working with the Mirth Connect codebase since 2016 and can provide the same level of channel development, cloud deployment, and administration support on any of these platforms.
Production costs for Mirth Connect include the software license (now commercial under NextGen, or free with OIE), infrastructure (cloud compute, database, networking), and operational support. On AWS, a typical single-node deployment costs $300-800/month for EC2 and RDS, while a high-availability multi-AZ cluster runs $800-2,000/month. NextGen's Mirth Connect licensing is priced per-channel or as an enterprise agreement — contact NextGen directly for current pricing. OIE eliminates the software license cost entirely. Saga IT offers managed services that bundle infrastructure, monitoring, and 24/7 support into a predictable monthly fee.
Related Services
Explore More Services
Keep reading
Related resources
blogCI/CD for Mirth Connect Using MirthSyncblogGetting Started with MirthSyncblogMirth Connect Best PracticesblogUsing MirthSync with GitblogMirth Connect on AWS SQSdocsMirth Connect & OIE DocsdocsMirth Connect TroubleshootingdocsMirthSync DocumentationdocsCI/CD Setup GuidedocsMirthSync Plugin Guide
Talk to a Mirth Connect Expert
From channel development to cloud migration — let's optimize your integration engine.
- 15 min conversation
- Healthcare IT engineers, not sales
- Reply within one business day
Book a 30-min call · or email us and we'll reply within one business day.
Intent
Details
Contact