Mirth Connect: the open source integration engine of healthcare

AIHealth

On-premise clinical platform with local LLMs, RAG on FHIR/DICOM data, diagnostic support, remote follow-up. Architecture designed for the MDR pathway.

Discover AIHealth →

Digital Health

Medical software development compliant with CE and MDR regulatory standards. Clinical decision support systems, AI integration in clinical workflows.

Discover →

What an integration engine is

In a real hospital, information systems are never few: enterprise clinical record, HIS, LIS, RIS/PACS, patient demographics, pharmacy, specialised labs (pathology, microbiology), ward departmental systems, tessera sanitaria system, regional portals, FSE gateway. Each speaks its own HL7 v2 dialect, each has its own version of segments, each expects ACKs slightly differently. Connecting everything to everything point-to-point leads to an unmanageable graph growing as n², where every addition or change requires intervention on dozens of existing integrations.

The integration engine is the component that breaks this complexity by introducing a central point of message input and output: systems read and write to the engine, not to each other. The engine listens, validates, transforms, filters, routes, records — leaving application systems the job of doing medicine, not translation.

In the open source world the most widespread reference is Mirth Connect.

History

Mirth Connect was born in 2006 at Mirth Corporation (California). Version 1.x defined the foundational architecture — channel, listener, destination, transformer, filter — substantially unchanged across subsequent major releases. Version 2.x (2010-2014) introduced the separation between multiple destinations, message queueing, and the retry model.

In September 2013 Mirth Corporation was acquired by Quality Systems Inc., the holding of the NextGen Healthcare ecosystem. The acquisition did not close the open source project: Mirth Connect remained available under the Mozilla Public License, with regular releases. In 2017-2018 the official rebrand to NextGen Connect Integration Engine began, even though the historical name Mirth Connect continues to be the one the product is universally known by.

The 3.x series (2014-2020) has accompanied the maturation of the product, with support for new formats (JSON, FHIR), additional connectors, and performance improvements. Version 4.0, released in 2021, introduced a set of modernisations — JavaScript engine update, Java 11/17 support, improved secret management, dependency refresh — while keeping backward compatibility on channels.

The channel architecture

Mirth’s operational model is the channel. A channel is a pipeline of this shape:

Source connector (listener)
      │
      ▼
Source filter  ──►  Source transformer
      │
      ▼
      ┌── Destination 1 (connector + filter + transformer)
      │
      ├── Destination 2 ...
      │
      └── Destination N ...

The Source connector receives messages from a source:

• MLLP — TCP listener for HL7 v2 wrapped in MLLP, the most common case
• TCP — raw TCP listener, for non-MLLP protocols
• HTTP — HTTP or HTTPS listener, for RESTful or SOAP APIs
• File — file system directory polling
• Database Reader — periodic or triggered database reads (JDBC)
• Web Service — SOAP endpoint
• JMS — ActiveMQ, IBM MQ, other broker queues
• DICOM — DICOM C-STORE listener
• SMTP/IMAP/POP3 — email streams

Filters and transformers operate on the incoming message or on each destination. A filter is a JavaScript function that decides whether a message proceeds; a transformer is a JavaScript function that modifies the payload. Developers can use graphical Mappers for trivial field-to-field mappings, or write JavaScript for more complex logic.

Destinations forward the message. Every destination has the same connector repertoire as the source, plus some output-specific connectors (FHIR HTTP client, database writer, file writer).

Data types

Mirth natively supports numerous healthcare data formats, with optimised parsers:

• HL7 v2.x — the most common use case. MLLP parser, segment access through E4X/XML notation (msg['MSH']['MSH.3']['MSH.3.1']), profile-based validation, automatic ACK generation
• HL7 v3 / CDA R2 — XML support with XPath for header and section navigation
• FHIR — JSON/XML support; the engine exposes Java APIs for creating FHIR REST clients and handling Bundles
• X12 — administrative/insurance messages (less relevant in the Italian context)
• XML / JSON / Delimited — generic formats
• DICOM — metadata parsing and object encapsulation

This multi-format handling makes Mirth useful not only as a classic hospital gateway, but also as a standards converter — an increasingly common use case in recent years: receive HL7 v2 from legacy HIS, transform to FHIR R4, send to a modern FHIR data platform.

Operational features

Beyond the base pipeline, Mirth offers tools that are vital in production:

• Message Browser — historical inspection of every processed message, searchable by status, content, channel, time
• Message Pruner — per-channel retention management (crucial on systems processing millions of messages/day)
• Error Handler — recovery of failed messages, with exponential retry
• Code Templates Library — shared repository of reusable JavaScript functions (parsers, validators, external API clients)
• User Roles and Audit Log — configurator access management, change traceability
• Command-Line Interface — mirthcli for deployment and backup automation
• Clustering (Premium, not open source) — active-active high availability

Typical deployment is Java on Linux with an external database (PostgreSQL, MySQL, Oracle, SQL Server). The architecture is resilient but requires operational attention: channel configurations are first-class assets that must be versioned, code-reviewed, integrated into CI/CD pipelines like any other code.

Typical healthcare uses

The most recurring scenarios:

• Enterprise HL7 gateway — a single Mirth instance receives all messages from departmental systems and routes them to EHR, FSE, administrative systems, data warehouse
• RIS/PACS broker — ORM/ORU conversion between vendors, MWL/MPPS management
• HL7 → FHIR bridge — progressive modernisation, keeping legacy systems on their dialect and exposing a FHIR REST view to newer systems
• Regional FSE feeding — conversion of HL7 v2 messages produced by systems into Italian CDA R2 documents, digital signature, submission to XDS.b Document Source
• Telemedicine platform integration — collection of device parameters, forwarded as FHIR Observation to records
• Data pipeline to lakehouse — capture of clinical streams, pseudonymisation, writing to Kafka topics or Parquet files

Alternatives

Mirth is not the only choice. Within open source:

• Apache Camel + healthcare components (camel-hl7, camel-fhir, camel-dicom) — more general integration framework than Mirth, requires more code but is extremely flexible and integrates with Spring Boot in microservice architectures
• WSO2 Enterprise Integrator — open source ESB broker (Apache 2.0), healthcare connectors via Apache Camel
• Apache NiFi — orchestration of generic dataflows with HL7 processors
• Orthanc routers — for DICOM streams
• LinuxForHealth (IBM/Red Hat) — suite of FHIR-centric components under Apache 2.0

In the commercial space, the historical competitors are Rhapsody (Lyniate, formerly Orion), InterSystems IRIS for Health / HealthShare, Cloverleaf (Infor). They are more structured enterprise products — scalability, vendor support, vertical functionality — but come with licence costs and vendor dependency.

In Italy

Mirth Connect adoption in Italian hospital infrastructures is broad, both as main engine and as conversion engine alongside commercial products. Several Regions have standardised portions of their FSE stack on Mirth; many hospital trusts use it as broker between clinical record and departmental systems.

The adoption model is typically community edition: the engine is deployed on enterprise servers, configured and managed by the internal IT team or by a service provider. The absence of recurring licence costs and the full transparency of the code are factors that make it particularly suited to the Italian public context. The perceived limit is the lack of open source clustering and operational dependency on the team’s JavaScript competence.

Trajectory

The scenario in which Mirth operates is changing. The reasons for its existence — translating between vendor HL7 v2 dialects, coexisting with standards from different generations — will not disappear soon. HL7 v2 systems are still the majority and will be in production for years. In parallel, the maturity of FHIR R4 and the growth of healthcare data platforms make the role of the integration engine progressively more oriented to cross-standard conversion and integration with modern systems, less to pure routing.

Looking ahead, the natural successor of an engine like Mirth in a FHIR-first architecture will be a set of transformation microservices deployed on Kubernetes, with event brokers (Kafka) in place of the proprietary message store. The point of continuity will remain the model — channel, transformation, destination — on which Mirth has trained a generation of healthcare integrators.

References: Mirth Connect / NextGen Connect Integration Engine, NextGen Healthcare, MPL licence. Official GitHub repository. Apache Camel. WSO2 Enterprise Integrator. HL7 v2.x, HL7 CDA R2, HL7 FHIR R4.