If you work in healthcare IT and you have not heard of Mirth Connect, you will. If you have heard of it but are not sure what it actually does, you are in the majority. Integration engines are the plumbing of modern healthcare: invisible when they work, catastrophic when they fail, and poorly understood by the executives who approve the budgets for them.
This guide explains Mirth Connect in plain English for healthcare IT leaders who need to understand what it is, why it matters, and whether it belongs in their technology stack. No code dumps, no vendor marketing. Just a clear, honest overview of the most widely deployed healthcare integration engine in the United States.
According to HealthIT.gov, healthcare organizations exchange billions of clinical messages annually across disparate systems. The engine that routes, transforms, and delivers those messages determines whether a lab result reaches a physician in seconds or gets lost for hours. That engine, for roughly one-third of US Health Information Exchanges, is Mirth Connect.
What Is an Integration Engine and Why Do Hospitals Need One?
A modern hospital runs dozens of software systems: an Electronic Health Record (EHR) from Epic or Cerner, a Laboratory Information System (LIS), a Radiology Information System (RIS), pharmacy dispensing software, billing and claims processing, patient scheduling, and more. These systems were built by different vendors, at different times, using different data formats and communication protocols.
An integration engine is middleware that sits between all these systems and translates messages from one format to another, routes them to the correct destination, and ensures nothing gets lost in transit. Think of it as an air traffic control tower for clinical data: every message (a lab order, an admission notification, a prescription) passes through the integration engine, which determines where it needs to go and what format it needs to be in when it arrives.
Without an integration engine, hospitals face a nightmare of point-to-point connections. If you have 10 systems, you need up to 45 individual interfaces (n*(n-1)/2). With 20 systems, that number jumps to 190. Each interface must be built, tested, monitored, and maintained individually. Integration engines collapse this complexity into a hub-and-spoke model: every system connects to the engine, and the engine handles all the routing and transformation.
According to a HIMSS Analytics report, 60-80% of US hospitals still rely on HL7 v2 interfaces for the majority of their clinical data exchange. These interfaces are the backbone of healthcare operations, and the integration engine is what keeps them running.
How Mirth Connect Works: The Plain English Version
Mirth Connect processes messages through channels. Each channel is a self-contained integration pipeline with a source (where messages come in), processing logic (filters and transformers), and one or more destinations (where messages go out).
Here is how a typical message flows through Mirth:
- A source system sends a message. A lab system generates an HL7 v2 ORU (Observation Result) message containing a patient's blood test results. It sends this message to Mirth via a TCP connection using the MLLP (Minimal Lower Layer Protocol) standard.
- The Source Connector receives it. Mirth's source connector is listening on a specific port for incoming messages. It receives the raw HL7 message and passes it into the channel for processing.
- The Filter decides whether to process it. You can configure filters to accept or reject messages based on their content. For example: only process ORU messages with critical lab values, or reject messages from a deprecated sending facility.
- The Transformer modifies the message. This is where the real work happens. Transformers can remap fields (move the patient MRN from one field to another), translate codes (convert the lab's internal code to a standard LOINC code), reformat dates, add or remove segments, or completely convert the message from one format to another (HL7 v2 to FHIR JSON, for example).
- The Destination Connector delivers the message. The transformed message is sent to the destination system. This could be another MLLP connection, an HTTP REST API call, a database insert, a file write, or an email.
- Acknowledgment flows back. The destination system sends an acknowledgment (ACK) back through Mirth to the source system, confirming receipt.
A single Mirth instance can run hundreds of channels simultaneously, each handling a different type of message or connecting a different pair of systems. This is how one integration engine can manage an entire hospital's data exchange needs. For a deeper dive into how these channels are structured, see our guide on Mirth Connect channel design patterns.
What Protocols and Formats Does Mirth Handle?
One of Mirth's core strengths is its protocol versatility. Healthcare is not a single-standard industry. Different systems, different eras of technology, and different departments all speak different languages. Mirth handles them all:
Messaging Standards
- HL7 v2.x (versions 2.1 through 2.8): The dominant standard in US healthcare. ADT (admit/discharge/transfer), ORM (orders), ORU (results), SIU (scheduling), MDM (documents), and dozens more message types. Mirth has native HL7 v2 parsing and generation.
- FHIR R4 and R5: The modern REST-based standard. Mirth can consume and produce FHIR resources as JSON or XML. For organizations bridging legacy HL7 v2 and modern FHIR, Mirth is the translation layer. Learn more in our article on turning HL7 v2 streams into modern FHIR APIs.
- DICOM: The standard for medical imaging data. Mirth can route DICOM messages between radiology systems, PACS, and imaging archives.
- X12/EDI: Used for insurance claims, eligibility checks, and other administrative transactions (837, 835, 270/271, 276/278).
- CDA/CCD: Clinical Document Architecture for structured clinical summaries.
Data Formats
- XML: Native parsing and generation with XPath support.
- JSON: Full JSON handling for modern REST integrations.
- CSV/Flat File: For legacy batch file exchanges.
- Database: Direct JDBC connections to read from and write to PostgreSQL, MySQL, Oracle, SQL Server, and other databases.
- Raw/Binary: For proprietary formats that need custom parsing.
Transport Protocols
- TCP/MLLP: The standard transport for HL7 v2 messages.
- HTTP/HTTPS: REST API calls for FHIR and other web services.
- SFTP/FTP: Secure file transfers for batch processing.
- SOAP/Web Services: For legacy enterprise integrations.
- JMS/AMQP: Message queue integration for high-throughput scenarios.
- Email (SMTP): For notification-based workflows.
This breadth of protocol support is why Mirth is often the integration engine of choice. In a single hospital, you might need HL7 v2 for the LIS, FHIR for the patient portal, DICOM for radiology, X12 for billing, and database writes for the analytics warehouse. Mirth handles all of these from one platform. For an in-depth look at how these standards compare, check our guide on interoperability standards in healthcare.
Who Uses Mirth Connect?
Mirth Connect is one of the most widely deployed healthcare integration engines in the world. Here is where it is used:
- Health Information Exchanges (HIEs): Mirth powers approximately one-third of US Health Information Exchanges. These regional networks connect hospitals, clinics, labs, and payers across entire states or metropolitan areas. The Sequoia Project (which operates the national Carequality framework) and numerous state HIEs rely on Mirth for their core data exchange.
- Hospital Systems: From small rural hospitals with 5-10 interfaces to large academic medical centers with 200+ interfaces, Mirth scales across the spectrum. Health systems like CommonSpirit Health (the largest Catholic health system in the US) use integration engines based on Mirth's architecture.
- Healthcare Technology Vendors: EHR vendors, lab companies, telehealth platforms, and health IT startups embed Mirth into their products to provide interoperability features out of the box.
- Government and Public Health: State public health departments use Mirth for electronic lab reporting (ELR), immunization registries, and syndromic surveillance. During COVID-19, Mirth-based interfaces were critical for scaling up test result reporting nationwide.
- Payers and Insurance Companies: Claims processing, eligibility verification, and prior authorization workflows often run through Mirth-based integration platforms.
According to KLAS Research, Mirth (now marketed as NextGen Connect) consistently ranks among the top integration engines in healthcare, particularly for value and community support.
Core Use Cases
1. EHR Integration
The most common use case. Connecting the EHR to every other system in the hospital: labs, radiology, pharmacy, scheduling, billing, and patient portals. ADT messages (Admit, Discharge, Transfer) flow from the EHR to downstream systems so they know which patients are in which beds. Orders flow from the EHR to the lab or radiology system. Results flow back. Mirth sits in the middle, translating and routing all of it. For more on this topic, read our deep dive on how EHR integration unlocks seamless interoperability.
2. Lab Results Delivery
When a lab completes a blood panel, the results must reach the ordering physician within the EHR. Mirth receives ORU (Observation Result) messages from the LIS, maps lab-specific codes to the EHR's expected format, handles critical value flagging, and delivers the results. A well-tuned Mirth channel processes thousands of lab results per hour without human intervention.
3. Pharmacy and Medication Orders
CPOE (Computerized Provider Order Entry) generates medication orders that need to reach the pharmacy dispensing system. Mirth translates RDE (pharmacy/treatment encoded order) messages, performs drug code mapping, and ensures the pharmacist sees the order in their system seconds after the physician enters it.
4. Billing and Claims
After a patient encounter, charge data must flow from the EHR to the billing system, and claims must be generated in X12 837 format for submission to payers. Mirth handles the DFT (detailed financial transaction) messages and can transform clinical data into the billing codes and formats required by insurance companies.
5. Patient Referrals
When a primary care physician refers a patient to a specialist, the referral information (REF messages or FHIR ServiceRequest resources) must reach the specialist's system with all relevant clinical context. Mirth routes these across organizational boundaries, often through an HIE.
6. Public Health Reporting
Hospitals are required to report certain conditions (infectious diseases, immunizations, cancer cases) to public health authorities. Mirth generates the required HL7 messages or electronic case reports and transmits them to state and federal registries.
Architecture Overview: Channels, Sources, Destinations, and Transformers
Understanding Mirth's architecture does not require being a developer. Here are the key components:
The Mirth Connect Server
The core application that runs on a server (Windows, Linux, or macOS). It manages all channels, processes messages, and provides the management interface. The server connects to a database (PostgreSQL, MySQL, Oracle, or SQL Server) where it stores channel configurations, message history, and statistics.
The Mirth Administrator
A desktop application (Java-based) or web interface that lets administrators create, configure, and monitor channels. This is where integration engineers build interfaces, debug message processing, and monitor system health. For production monitoring best practices, see our article on what reliable Mirth Connect monitoring looks like in production.
Channels
The fundamental unit of integration in Mirth. Each channel represents one integration interface. A hospital might have:
- ADT_INBOUND: Receives ADT messages from the EHR
- ADT_FANOUT: Distributes ADT messages to all downstream systems
- ORU_LAB_TO_EHR: Delivers lab results from LIS to EHR
- ORM_EHR_TO_LAB: Sends lab orders from EHR to LIS
- DFT_TO_BILLING: Sends financial transactions to billing
Source Connectors
The input side of a channel. Defines how messages enter the channel: listening on a TCP port for MLLP, polling a database table, monitoring an SFTP directory, or receiving HTTP requests.
Destination Connectors
The output side. A channel can have multiple destinations. For example, an ADT channel might send the same admission message to the lab system (via MLLP), the pharmacy system (via database insert), and the patient portal (via FHIR REST API) simultaneously.
Transformers
JavaScript-based processing logic that modifies messages. Transformers can:
- Remap fields from one location to another
- Translate codes (facility codes, department codes, provider IDs)
- Enrich messages by looking up additional data from databases
- Convert between formats (HL7 v2 to FHIR, XML to JSON)
- Apply business rules (route critical results differently from normal results)
Filters
Boolean logic that determines whether a message should be processed or skipped. Filters evaluate message content and return true (process) or false (skip). This is how you build routing logic: only process ADT^A01 messages, only process results from the chemistry lab, only route messages for patients in the ICU.
The Community and Ecosystem
Mirth Connect's history is unique in healthcare IT. Originally developed as open-source software by Mirth Corporation, it was acquired by NextGen Healthcare. For years, the community edition was free to download and use, which drove massive adoption. Integration engineers could learn Mirth without a license fee, and startups could deploy it without budget approval.
In March 2025, NextGen Healthcare announced that Mirth Connect version 4.6 and later would no longer be available as open-source software. The last freely available version is 4.5.2 (released September 2024). This licensing change is significant for the community. For an analysis of what this means and how to respond, see our article on Mirth Connect's commercial transition and migration strategies for open-source users.
Despite the licensing change, the Mirth ecosystem remains substantial:
- Community Forums: Active user forums where integration engineers share solutions, channel templates, and troubleshooting advice.
- Extensions and Plugins: A marketplace of add-ons for FHIR support, advanced monitoring, cloud connectors, and specialized transformations.
- Consulting Ecosystem: Dozens of healthcare IT consulting firms specialize in Mirth implementations, including Nirmitee Healthtech.
- Training and Certification: NextGen offers official Mirth Connect training and certification programs. Third-party training providers fill additional gaps.
- Talent Pool: Because of years of open-source availability, there is a larger pool of engineers with Mirth experience than with any other healthcare integration engine. That said, experienced Mirth engineers command salaries of $120,000-$180,000 per year, and training new engineers takes 3-6 months.
When Mirth Is the Right Choice
Mirth Connect is a strong fit when:
- You need HL7 v2 support. Mirth has the most mature HL7 v2 implementation of any integration engine. If your primary need is connecting legacy HL7 systems, Mirth is proven.
- You need protocol versatility. If you need to handle HL7 v2, FHIR, DICOM, X12, and database connections from one platform, Mirth covers more ground than most alternatives.
- You have (or can hire) Mirth engineers. The talent pool for Mirth is larger than for Rhapsody or Iguana. Finding an engineer who already knows Mirth is easier than finding one who knows a competing product.
- You want community knowledge. Decades of forum posts, blog articles, and community-shared channel templates mean most problems have already been solved by someone else.
- You are building an HIE or data exchange network. Mirth's track record in powering HIEs is unmatched.
When Mirth May Not Be the Right Choice
Mirth may not be the best fit when:
- You need enterprise-grade support and SLAs. While NextGen offers commercial support, competitors like Rhapsody (17 consecutive years as Best in KLAS for integration engines) provide more mature enterprise support packages.
- You need cloud-native architecture from day one. Mirth was designed as an on-premises application. While NextGen now offers "Mirth Fully Managed" as a cloud option, competitors like Rhapsody were built with cloud deployment as a first-class feature.
- You have extreme throughput requirements. For very high message volumes (millions per day), competitors like Iguana from Interfaceware claim faster raw performance. For large-scale tuning guidance, see our guide on Mirth Connect performance tuning for 10,000+ messages per hour.
- Your team has no Java/JavaScript experience. Mirth's transformers are JavaScript-based, and advanced customization requires Java. If your team is purely .NET or Python, the learning curve may be steep.
- You are concerned about licensing uncertainty. The shift from open-source to commercial licensing introduces risk. Future pricing changes are at NextGen's discretion.
Getting Started with Mirth Connect
For organizations evaluating Mirth Connect, here is a practical starting path:
Step 1: Download and Install
Download Mirth Connect 4.5.2 (the last open-source version) from the NextGen GitHub repository. Install it on a development server with PostgreSQL as the database backend. The entire setup takes under an hour.
Step 2: Build a Simple Channel
Create a channel that listens for HL7 v2 messages on a TCP port, transforms a field, and writes the result to a file. This gives you hands-on experience with the channel builder, transformer editor, and message processing pipeline.
Step 3: Test with Real-World Messages
Obtain sample HL7 messages from your existing systems (anonymized, of course). Send them through your test channel and observe how Mirth parses, transforms, and routes them.
Step 4: Evaluate for Production
If Mirth fits your needs, plan a production deployment. Consider high availability requirements (see our guide on setting up Mirth Connect for high availability), database sizing, monitoring, and staffing. Budget for at least one dedicated integration engineer and factor in licensing costs for version 4.6 and above.
Step 5: Engage Expert Help
For complex implementations involving dozens of interfaces, consider engaging a healthcare integration consulting firm. Experienced consultants can accelerate deployment by months and help you avoid common pitfalls. Nirmitee Healthtech specializes in Mirth Connect implementations and can help you from architecture design through production deployment.
Struggling with healthcare data exchange? Our Healthcare Interoperability Solutions practice helps organizations connect clinical systems at scale. We also offer specialized Healthcare Software Product Development services. Talk to our team to get started.
Frequently Asked QuestionsIs Mirth Connect still free?
Mirth Connect version 4.5.2 and earlier remain available under an open-source license. However, as of March 2025, NextGen Healthcare has transitioned Mirth Connect 4.6 and later to a commercial-only model. Organizations running production environments should budget for licensing costs going forward or evaluate whether the open-source 4.5.2 version meets their needs.
What is the difference between Mirth Connect and NextGen Connect?
They are the same product. NextGen Healthcare acquired Mirth Corporation and rebranded the product as "NextGen Connect Integration Engine." The community still widely refers to it as "Mirth Connect" or simply "Mirth." NextGen also offers "Mirth Fully Managed," a cloud-hosted version of the integration engine.
How many interfaces can Mirth handle?
There is no hard limit. Small deployments run 5-10 channels; large health systems run 200-500 channels on a single Mirth cluster. Performance depends on hardware, database configuration, message volume, and transformer complexity. A properly tuned Mirth instance on modern hardware can process 10,000+ messages per hour.
Does Mirth support FHIR?
Yes. Mirth can send and receive FHIR resources via REST APIs. It can also transform HL7 v2 messages into FHIR resources and vice versa. This makes it a practical bridge for organizations transitioning from HL7 v2 to FHIR, which is the direction the entire industry is moving. For more on this transition, see our article on when healthcare organizations need both HL7 and FHIR.
What database does Mirth use?
Mirth supports PostgreSQL, MySQL, Oracle, and Microsoft SQL Server as its internal database. PostgreSQL is the most common choice for new deployments due to its performance, reliability, and zero licensing cost. The database stores channel configurations, message history, statistics, and user accounts.
The Bottom Line
Mirth Connect is the integration engine that powers a significant portion of American healthcare data exchange. It is versatile, widely understood, and backed by a large community of engineers and consultants. The recent licensing changes add a cost factor that did not previously exist, but for organizations that need a proven, multi-protocol integration platform, Mirth remains a strong contender.
The decision to adopt Mirth should be based on your organization's specific needs: the protocols you need to support, the volume of messages you process, your team's technical skills, and your budget for both licensing and staffing. No integration engine is perfect for every scenario, but Mirth Connect has earned its position as the default starting point for healthcare integration conversations.
Whether you are a CTO evaluating integration platforms, a VP of IT building a business case, or a clinical informaticist trying to understand why your lab results are delayed, understanding Mirth Connect is essential to understanding how modern healthcare technology works. For a broader perspective on the challenges of healthcare data exchange, read our analysis of true interoperability in the world of fragmented data.