Mirth Connect is no longer open source: licence, forks and connecting AI

What is Mirth Connect?

Mirth Connect is an interface engine (in German hospitals often called a “Kommunikationsserver”): it routes messages between a hospital’s systems and translates their formats, for example from the hospital information system (HIS) to the laboratory or from radiology to billing. Mirth understands HL7 v2 and v3, FHIR, DICOM, X12, XML, JSON and text files. Each connection is called a channel; for every channel, administrators define where messages come from, how they are transformed and where they go.

Mirth was developed by Mirth Corporation and has belonged to NextGen Healthcare since 2013. NextGen in turn has been owned by the private equity firm Thoma Bravo since November 2023. Between 2018 and 2021 the product was called “NextGen Connect”; since version 3.12 it has been “Mirth Connect by NextGen Healthcare” again. German hospitals have used it for many years; University Hospital Bonn, for example, since 2013, as described in an experience report from 2014.

How the HIS, interface engine, data platform and AI platform share the work is explained in HIS, interface engine, data platform, AI platform.

What has changed in the licence?

Version	Licence	Status
up to 4.5.2 (23.09.2024)	Mozilla Public License 2.0, plus commercial extensions	Source code freely available
from 4.6 (announced 19.03.2025)	commercial only, proprietary	Tiers Enterprise, Gold, Platinum; fixed annual fee per server
4.7.2 (current)	commercial only	Download via the NextGen customer portal

NextGen announced the change on 19 March 2025. For organisations on the open version, NextGen named three paths: stay on their own version, move to 4.5.2 as the last open version, or buy a licence. For non-profit research there is a free licence, “Mirth Connect for Research”. The licence is charged per server, not per interface; NextGen does not publish prices.

What licence changes in open-source software mean in general, illustrated by three examples: Licence risk with open-source tools.

Why does this matter for security?

An interface engine sees almost all of an organisation’s messages. Security vulnerabilities in it are therefore particularly sensitive. In September 2026, the US agency CISA reported three vulnerabilities in Mirth Connect, including an SQL injection via the interface of the database connector (CVSS 8.3) and two vulnerabilities in XML processing. According to CISA, all versions up to 4.7.1 are affected; they are fixed in 4.7.2, which NextGen delivers through its customer portal.

For organisations on 4.5.2 this means: NextGen provides no fixes for this version. Anyone staying on it has to assess and mitigate vulnerabilities themselves, for example through network segmentation, or move to a version that is still maintained. For NIS2 and the B3S Krankenhaus (the German industry security standard for hospitals), this belongs in risk management; a software bill of materials (SBOM) helps to find affected versions.

Which forks exist?

Because the code up to 4.5.2 is under the Mozilla Public License 2.0, the community was allowed to continue developing it. Two forks are active in 2026:

• Open Integration Engine (OIE): developed by the community, Mozilla Public License 2.0. Version 4.6.0 was released on 9 July 2026. The project has been accepted by the Eclipse Foundation; two feature releases per year are planned. It carries a neutral name because of the “Mirth” trademark.
• BridgeLink: from Innovar Healthcare, also Mozilla Public License 2.0, with calendar-based versions (most recently 26.9.0 of 1 October 2026). Innovar offers extensions and support for a fee, in Germany through MARIS Healthcare. The licence of each component deserves its own look; not every one is under the same licence.

Both build on 4.5.2. Channels can therefore usually be carried over; test before switching whether this holds for your extensions and channels.

What should hospitals running Mirth Connect check now?

1. Determine the version: Which version is running, with which extensions? Are the vulnerabilities up to 4.7.1 closed?
2. Clarify the licence: Do you use the open version, a commercial licence or both? Commercial extensions from before 4.6 have their own terms.
3. Choose a path: secure the open version yourself, commercial licence, fork or a different interface engine. Every path has costs: for the licence, for in-house maintenance or for moving the channels.
4. Document the channels: Which systems are attached to which channel? You need this list for every path, including for tenders.
5. Check message storage: Mirth stores messages per channel at different levels, from metadata only to full content. How long is governed by the deletion function (Data Pruner). These settings belong in the record of processing activities.

How does an AI get access to Mirth Connect?

Mirth Connect has a REST interface, which its own administration interface also uses. The description is publicly available in the NextGen documentation, and every installation shows the full list of calls under /api. Sign-in uses an account in Mirth.

For an AI, three things are particularly useful:

• Channel status and errors: Which interface is down, where are messages backing up, which errors occurred last night? There is hardly any patient data here.
• Statistics: throughput per channel, for example for the report to the head of IT.
• Message search: time, status, error text and channel of a message. The content itself is health data.

A question such as “Why have no lab results arrived in the HIS since 6 a.m.?” is then answered by the AI from channel status and errors, with a source.

Two things need attention. The interface can also write, that is, stop channels or resend messages. An AI connection therefore needs its own account with restricted permissions. And by default it should not read message content; if it does, then only after agreement with the data protection officer and only for the people who are allowed to see this data anyway.

How does this work with basebox?

basebox connects systems through connectors; for specialists: via MCP (Model Context Protocol). A connector for Mirth Connect has been announced (“Coming soon”). It uses the REST interface and therefore also works with the forks Open Integration Engine and BridgeLink, which have the same interface. By default it only reads; message content only after agreement with you. Every call is recorded in the audit log. All connectors from our library are included in the licence.

Through the interface engine, basebox also reaches the systems that already come together there, such as the HIS, laboratory and radiology. For clinical data, we agree access with you and the vendors; basebox is not a medical device, and the decision is always made by the doctor. All connectors with their status are listed under Connectors.

Not legal advice: Check in the licence text, and if in doubt with your legal department, whether a licence permits your use. The information on Mirth Connect, Open Integration Engine and BridgeLink reflects the state of our research on 15 October 2026 and is based on information from the vendors and projects.