ADT-A01
Admission 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 interface engine. We handle 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.
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.
The Engine
What is Mirth Connect?
Mirth Connect is a healthcare interface engine: middleware that receives clinical messages from one system, transforms them, and routes them to another. Hospitals use it to connect EHRs to lab, radiology, pharmacy, billing, and HIE systems across HL7 v2, FHIR R4, DICOM, and EDI X12. The work is organized into channels: each one a configured source, transformer, and destination.
Since March 2025 the engine itself has been commercial software, sold by NextGen Healthcare as NextGen Connect, while open-source development continues in the MPL 2.0 community forks, led by Open Integration Engine (OIE) alongside BridgeLink and other forks. Saga IT builds, migrates, and operates all of them, across the full lifecycle.
- Open source 2006–2025
- Commercial since Mar 2025
- MPL 2.0 forks: OIE · BridgeLink
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, with Oracle Health (Cerner) or eClinicalWorks joining after the next acquisition. 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
Channel Development, Cloud Deployment, DevOps, and 24/7 Support
Mirth Connect software is healthcare's most widely deployed integration engine, the open-source-rooted middleware now sold commercially as NextGen Connect, with MPL 2.0 community forks (Open Integration Engine, BridgeLink, and others) 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 · OpenShare · 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. OpenShare provides browser-based fleet monitoring and 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)
- OpenShare 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
Mirth Connect Channels for Every 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.
ORM-O01
Order v2 segments
MSHORCOBR
FHIR R4
ServiceRequestPatient
Each OBR becomes one ServiceRequest; ORC-2 placer-order-number maps to ServiceRequest.identifier with a system URI.
ORU-R01
Result v2 segments
MSHOBROBX
FHIR R4
ObservationDiagnosticReport
LOINC codes in OBX-3 transfer cleanly; abnormal flags (OBX-8) become Observation.interpretation with v3-codesystem mappings.
SIU-S12
Schedule 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.
MDM-T02
Document v2 segments
MSHEVNPIDTXAOBX
FHIR R4
DocumentReferenceBinary
Free-text OBX-5 content is base64-encoded into a Binary resource; TXA metadata populates DocumentReference attributes.
DFT-P03
Charge v2 segments
MSHEVNPIDFT1
FHIR R4
ChargeItemEncounter
FT1 transaction codes map to ChargeItem.code; the clinical context lives in a linked Encounter via ChargeItem.context.
Running Mirth Connect on AWS? Buy our services through AWS Marketplace.
Procure through AWS Marketplace and draw down your committed AWS spend (EDP). No new vendor onboarding, no new paperwork.
Links to the AWS Marketplace listing ↗ 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
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 interface 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® (Rhapsody Health) | Commercial | Yes | Self-hosted + Rhapsody-managed cloud | Enterprise health systems wanting polished commercial UX | Yes, consulting + integration |
| Iguana® (iNTERFACEWARE) | Commercial | Yes | On-prem, cloud, or iNTERFACEWARE-hosted | Teams prioritizing Lua-based rapid channel development | No, refer to iNTERFACEWARE |
| Corepoint® (Rhapsody Health) | Commercial | Yes | Self-hosted; cloud options via Rhapsody Health | Mid-market hospitals on the Rhapsody Health stack | No, refer to Rhapsody Health |
| 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.
Healthcare integration delivered for
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 OpenShare fleet monitoring and 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), covering 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
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 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
AWS-Hosted Mirth Connect with Active-Active HA
A specialty clinic network deploying Mirth Connect across two AWS regions with active-active clustering, RDS Multi-AZ, and CloudWatch-driven alerting, for 99.99% uptime on critical ADT feeds.
Terraform IaC
// main.tf
module "mirth_cluster" {
source = "./mirth"
regions = ["us-east-1","us-west-2"]
}
module "mirth_cluster" {
source = "./mirth"
regions = ["us-east-1","us-west-2"]
}
Multi-region cluster
CloudWatch alerts
MirthSync CI/CD for 50+ Channels
A health-tech vendor implementing MirthSync-based Git workflows + GitHub Actions CI/CD across 50+ HL7 v2 and FHIR channels, with PR-gated promotion across dev → staging → production.
mirthsync push
// pull/push workflow
$ mirthsync push --env staging
→ ADT-A01...deployed
→ ORU-Lab...deployed
→ FHIR-Bridge...deployed
$ mirthsync push --env staging
→ ADT-A01...deployed
→ ORU-Lab...deployed
→ FHIR-Bridge...deployed
GitHub Actions
# .github/workflows/deploy.yml
on: push [main]
jobs:
lint → validate → test → deploy
on: push [main]
jobs:
lint → validate → test → deploy
Production deploy
FAQ
Mirth Connect Questions
Mirth Connect is a healthcare interface engine (also called an integration engine): middleware that receives a clinical message from one system, transforms it, and routes it to another. Hospitals and health-tech vendors use it to connect EHRs with lab, radiology, pharmacy, billing, and HIE systems over HL7 v2, FHIR R4, DICOM, and EDI X12. Work is organized into channels, each pairing a source connector, transformer scripts, and one or more destinations. Since March 2025 the product is commercially licensed by NextGen Healthcare, with open-source development continuing in MPL 2.0 forks led by Open Integration Engine (OIE).
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). Open-source forks have since emerged under MPL 2.0, led by the Open Integration Engine (OIE), a vendor-neutral community fork governed by a non-profit Steering Committee, alongside BridgeLink and other forks. Saga IT supports all variants: commercial Mirth Connect, OIE, BridgeLink, and migration between platforms.
No, not since March 2025. NextGen Healthcare moved Mirth Connect 4.6 and later to a commercial per-channel or enterprise license, ending more than a decade of free MPL distribution. Release 4.5.2 stays under MPL 2.0 and that license cannot be revoked, but the open-source line no longer receives updates from NextGen. Open-source development continues in the MPL 2.0 community forks, led by Open Integration Engine (OIE), a vendor-neutral project governed by a non-profit Steering Committee, alongside BridgeLink and other forks. OIE and BridgeLink both keep full channel compatibility with Mirth Connect, so moving is a re-platform, not a rewrite. You can download the open-source Mirth Connect (OIE) for free.
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 in MPL 2.0 community forks: Open Integration Engine (OIE), governed by a non-profit Steering Committee, alongside BridgeLink and other smaller forks. NextGen continues to develop and sell the commercial Mirth Connect product alongside its broader EHR business.
The difference is licensing and governance, not the engine. Open Integration Engine (OIE) is the MPL 2.0 community fork of the Mirth Connect codebase, governed by a non-profit Steering Committee with a multi-vendor support ecosystem; Mirth Connect 4.6 and later is a commercial NextGen Healthcare product. The two share the same channel format and Java architecture, so channels export from one and import into the other without modification. Saga IT provides full consulting and support for both platforms.
Mirth Cloud Connect is NextGen Healthcare's hosted SaaS edition of Mirth Connect: NextGen operates the engine infrastructure and you manage channels through their cloud service, priced and sold directly by NextGen. The self-managed alternative is running Mirth Connect or OIE in your own AWS or Azure account, which keeps the engine, PHI handling, and spend under your control. Saga IT designs and operates those self-managed cloud deployments, using the reference architectures shown on this page.
A typical Mirth Connect implementation covers discovery (interface inventory and message volumes), environment build (server or cloud infrastructure), channel development and testing, parallel-run validation against production traffic, and cutover with a documented rollback plan. Single-interface projects run 2–6 weeks; multi-hospital migrations run 3–6 months. As a Mirth Connect implementation partner, Saga IT delivers fixed-fee or T&M scopes and can hand off to your team or stay on for 24/7 managed support.
A production Mirth Connect deployment on AWS needs three pieces: an EC2 instance (or ECS container) for the application server, RDS PostgreSQL or MySQL for the configuration and message store, and a VPC with private subnets for HIPAA compliance. Around that core, add 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.
Yes. Mirth Connect is supported on every path: NextGen Healthcare sells commercial support under its enterprise agreements, a multi-vendor ecosystem including Saga IT supports the 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 provides the same channel development, cloud deployment, and administration support on any of these platforms.
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