Mirth Connect ist nicht mehr Open Source: was jetzt?
Wer eine HL7- oder FHIR-Schnittstelle in einer deutschen Klinik betreibt, ist mit hoher Wahrscheinlichkeit auf Mirth Connect gestoßen - es war lange der De-facto-Standard für Healthcare-Datenintegration im DACH-Raum. Seit März 2025 stimmt das nur noch für bestehende Installationen, nicht mehr für neue.
Was im März 2025 passiert ist
NextGen Healthcare hat das Lizenzmodell von Mirth Connect umgestellt: von einer Doppellizenz (MPL 2.0 + kommerziell) auf rein kommerziell und proprietär. Ab Version 4.6 ist der Quellcode nicht mehr öffentlich. Die letzte Version unter der offenen MPL-2.0-Lizenz ist 4.5.2 - diese Lizenz kann rückwirkend nicht entzogen werden, aber diese Version bekommt keine Sicherheitsfixes mehr.
Branchenberichten zufolge betrifft das rund 15.000 Organisationen weltweit. Wer eine Integrationsengine betreibt, über die echte Patientendaten laufen, kann eine eingefrorene Version ohne Sicherheitsfixes auf Dauer nicht verantworten - unabhängig davon, was man von der Lizenzänderung selbst hält.
Zwei Forks, innerhalb weniger Wochen
Aus dem letzten offenen Stand entstanden zwei unabhängige Fortsetzungen, beide weiterhin unter MPL 2.0:
| Fork | Governance | Aktueller Stand |
|---|---|---|
| Open Integration Engine (OIE) | Herstellerneutral, Non-Profit-Steering-Committee mit Maintainern aus mehreren Firmen | 4.6.0 (Java 17, 24 behobene CVEs) - aber kein Container-Image für diese Version, nur eines vom letzten 4.5.2-Stand (August 2025) |
| BridgeLink | Einzelner Hersteller (Innovar Healthcare) | 26.6.0, Container-Images zu jedem Release, tagesaktuell |
OIE hat die bessere Governance - genau die Struktur, die eine Wiederholung des NextGen-Falls verhindern soll. Praktisch scheitert es aktuell an einem Punkt: Es gibt kein aktuelles Container-Image, nur eines vom alten, CVE-belasteten Stand. Ein Image selbst zu bauen ist technisch möglich, aber zusätzlicher Pflegeaufwand, den nicht jeder Betreiber tragen will.
Was das für Linumed heißt
Linumed Base liefert die Integrationsengine als BridgeLink aus - nicht, weil es das bessere Projekt wäre, sondern weil es als einzige Option gleichzeitig quelloffen, aktuell gepatcht und ohne Eigenbau deploybar ist. Wichtig dabei: BridgeLink ist kein Ersatzprodukt, sondern derselbe Codestand unter anderem Namen - gleiches Kanal-Format, gleicher Administrator, gleiche JavaScript-Transformer. Der Serverstart protokolliert das wörtlich:
com.mirth.connect.server.Mirth: BridgeLink 26.6.0 (Built on July 17, 2026)
server successfully started.Sobald OIE ein Container-Image für eine aktuelle Version veröffentlicht, entfällt der einzige Grund, der aktuell gegen OIE spricht - dann gibt die bessere Governance den Ausschlag. Das ist der Punkt, den wir beobachten (OIE-Issue engine#40).
Was das für Sie heißt
Wer heute eine Integrationsengine auswählt oder eine bestehende Mirth-Connect-Installation absichern muss, kommt an dieser Entscheidung nicht vorbei. Der belastbare Ausweg ist Kanal-Portabilität, nicht die Image-Frage: Kanäle, Code-Templates und Transformer lassen sich zwischen allen drei Varianten exportieren und importieren, weil sie denselben Codestand teilen. Eine Entscheidung heute bindet also nicht auf Dauer - die eigentliche Integrationsarbeit bleibt portabel, falls sich die Lage bei OIE ändert.
Mehr dazu: Linumed Base, und die vollständige Begründung mit allen geprüften Optionen in ADR 0001.