Integration

Schnittstellen-Engines erklärt: Was Mirth, Rhapsody und ihre Kollegen wirklich tun und wann Sie eine brauchen

Schnittstellen-Engine: Empfängt, wandelt & liefert Nachrichten. Mit Warteschlangen, Wiederholungsversuchen, Überwachung & Audit. Bausteine (Kanäle, Listener, Transformer, Ziele), HL7 v2-Routing, FHIR-Facades, Auswahl & Betrieb. Wann keine nötig ist.

von Veröffentlicht 6 Min. Lesezeit

Kurze Antwort: Eine Schnittstellen-Engine (Integrations-Engine) ist eine Middleware, die für den Austausch von Gesundheitsdaten entwickelt wurde. Sie lauscht auf vielen Protokollen (MLLP für HL7 v2, HTTP für FHIR und SOAP, Dateien, Datenbanken, Warteschlangen), transformiert Nachrichten (Feldzuordnung, Codeübersetzung, Formatkonvertierung wie HL7 v2 zu FHIR), leitet sie mit Filtern an ein oder mehrere Ziele weiter und unterhält Warteschlangen, Wiederholungsversuche, Protokolle und Dashboards, damit keine Nachricht verloren geht und jeder Fehler sichtbar ist. Krankenhäuser nutzen eine solche Engine, damit jedes System nur einmal mit der Engine verbunden werden muss, anstatt mit jedem anderen System einzeln. Bekannte Produkte sind Mirth Connect (NextGen Connect, historisch Open Source), Rhapsody, InterSystems HealthShare / IRIS for Health, Infor Cloverleaf, Qvera QIE, Orion und eine lange Liste weiterer; Cloud-Anbieter bieten verwaltete Äquivalente an.

Die Bausteine

Die Bausteine einer Schnittstellen-Engine sind Kanäle (ein Datenfluss von einer Quelle zu ihren Zielen), Quell-Konnektoren oder Listener wie MLLP und HTTP, Filter, die entscheiden, ob eine Nachricht weitergeleitet wird, Transformer, die Felder und Codes zuordnen, Ziel-Konnektoren, Warteschlangen mit Wiederholungsversuchen, Überwachung mit Alarmen und eine Audit-Spur von Kanaländerungen und Nachrichtenverlauf.

Jede Engine, unabhängig von der Terminologie, hat die gleichen Teile:

  • Kanal (Schnittstelle): Ein Fluss von einer Quelle zu einem oder mehreren Zielen mit eigenen Einstellungen und Statistiken.
  • Quell-Konnektor / Listener: MLLP (TCP mit Framing für HL7 v2), HTTP(S)-Endpunkte, SFTP und Datei-Polling, Datenbankabfragen, JMS oder andere Warteschlangen, DICOM in einigen Produkten.
  • Filter: Eine Regel, die entscheidet, ob eine Nachricht weitergeleitet wird (nur ADT^A01 für diese Patientengruppe).
  • Transformer: Skripte oder Mappings, die die Nachricht ändern: Felder umbenennen, lokale Codes über eine Nachschlagetabelle in LOINC übersetzen, eine FHIR Observation aus einem OBX-Segment erstellen, ein Z-Segment hinzufügen, das ein Altsystem erwartet.
  • Ziel-Konnektor: Wohin das Ergebnis geht, mit eigenem Protokoll und Fehlerbehandlung.
  • Warteschlange und Wiederholungsversuch: Nachrichten werden bis zur Bestätigung gespeichert; Fehler werden mit exponentiellem Backoff wiederholt; "vergiftete" Nachrichten landen in einer Fehlerwarteschlange für Menschen.
  • Überwachung und Alarmierung: Zähler pro Kanal, Latenz, Fehlerraten, Alarme, wenn ein Kanal verstummt (der nützlichste Alarm in der Gesundheitsintegration).
  • Audit: Wer welchen Kanal geändert hat und die Nachrichtenverlauf zur Fehlerbehebung, mit Aufbewahrungsfristen und Zugriffskontrollen, da es sich um Patientendaten handelt.

Typische Aufgaben

Die typischen Aufgaben einer Schnittstellen-Engine im Gesundheitswesen sind ADT-Fan-out vom KIS an Abteilungen, Weiterleitung von Laborergebnissen an mehrere Empfänger, Übersetzung lokaler Codes in LOINC, ATC und UCUM, Überbrückung von HL7 v2, FHIR, CDA und CSV-Formaten, Bereitstellung einer FHIR-Fassade über eine Legacy-Datenbank, Normalisierung von Gerätedaten und Anpassung von MLLP intern an HTTPS extern.

  1. ADT Fan-out: Aufnahmen vom KIS empfangen, nach Abteilung filtern und übersetzen, an Labor, Radiologie, Apotheke, Bettenmanagement und das Patientenportal liefern.
  2. Ergebnis-Routing: ORU vom LIS an die elektronische Patientenakte (ePA), an das System des behandelnden Arztes, an die regionale Akte, an die FHIR-Akte des Patienten, jeweils mit einer anderen Teilmenge und einem anderen Format.
  3. Code-Übersetzung: Lokale Testcodes in LOINC, lokale Medikamentencodes in ATC, Freitext-Einheiten in UCUM, über gepflegte Nachschlagetabellen (Laborcodes in LOINC abbilden).
  4. Format-Brücke: HL7 v2 zu FHIR und zurück, CDA zu FHIR, CSV von einem alten System zu beliebigem Format.
  5. Eine FHIR-Fassade: Die Engine stellt FHIR-Endpunkte bereit und beantwortet diese durch Abfragen der Altdatenbank oder Senden von v2-Abfragen, sodass Apps einen FHIR-Server sehen, wo keiner existiert.
  6. Geräteintegration: Proprietäre Monitor-Feeds normalisiert zu IHE PCD Observations.
  7. Protokollanpassung: MLLP innerhalb des Gebäudes, HTTPS mit OAuth nach außen.

Auswahl einer Engine

Die Auswahl einer Schnittstellen-Engine hängt von sechs Kriterien ab: Nachrichtenvolumen und wie kritisch Latenz und Ausfälle sind, die sofort unterstützten Protokolle und Standards (HL7 v2, FHIR R4, DICOM, nationale Formate), die Entwicklererfahrung, Betriebsfunktionen wie Clustering und Failover, Lizenzbedingungen, die sich für einige Produkte im Jahr 2025 geändert haben, und die verfügbaren Fähigkeiten zur Wartung von Kanälen.

  • Volumen und Kritikalität: Nachrichten pro Tag, akzeptable Latenz und ob ein zweiminütiger Ausfall relevant ist (für ADT und Ergebnisse ist er das).
  • Protokolle und Standards out-of-the-box: HL7 v2-Versionen und Parser, FHIR R4-Unterstützung mit Validierung, DICOM, X12 in den USA, nationale Formate.
  • Entwicklererfahrung: Skriptsprache (JavaScript in Mirth, proprietär in anderen), Versionskontrolle von Kanaldefinitionen, Testwerkzeuge, Bereitstellung in mehreren Umgebungen.
  • Betrieb: Clustering, Failover, Überwachungsintegrationen, Upgrade-Pfad, Support-Modell.
  • Lizenzierung: Open Source oder Community-Editionen, Abonnement pro Kanal oder pro Kern, verwaltete Cloud-Angebote; die Lizenzierung einiger historisch offener Produkte änderte sich 2025, prüfen Sie daher die aktuellen Bedingungen.
  • Verfügbare Fähigkeiten: Die Engine ist nur so gut wie die Personen, die die Kanäle warten.

Sichere Ausführung einer Engine

Die sichere Ausführung einer Schnittstellen-Engine bedeutet, Kanaldefinitionen als Code unter Versionskontrolle zu behandeln, mit synthetischen Nachrichten vor der Produktion zu testen, Code-Lookup-Tabellen mit benannten Eigentümern zu verwalten, bei Stille eines Kanals Alarme auszulösen, den Nachrichtenverlauf einzuschränken und zu löschen, da es sich um Patientendaten handelt, den Zweck jedes Kanals zu dokumentieren und niemals zuzulassen, dass die Engine zum System der Aufzeichnung wird.

Behandeln Sie Kanaldefinitionen als Code: in der Versionskontrolle, überprüft, bereitgestellt über Test- und Staging-Umgebungen mit synthetischen Nachrichten. Halten Sie Nachschlagetabellen (Code-Maps) unter Governance mit Eigentümern. Richten Sie Alarme bei Stille ein, nicht nur bei Fehlern. Beschränken Sie den Zugriff auf den Nachrichtenverlauf, der Patientendaten enthält, und löschen Sie ihn nach einem Zeitplan. Dokumentieren Sie den Zweck und den Eigentümer jedes Kanals; der undokumentierte Kanal ist derjenige, der eine Abteilung zum Stillstand bringt, wenn sein Autor geht. Und lassen Sie die Engine niemals zum System der Aufzeichnung werden: Sie bewegt und transformiert Daten, sie besitzt sie nicht.

Wenn Sie keine benötigen

Eine Schnittstellen-Engine wird nicht benötigt, wenn alle Partner eines Greenfield-Systems FHIR sprechen, in diesem Fall decken ein FHIR-Server mit Subscriptions und ein API-Gateway Routing und Authentifizierung ab, oder wenn eine einzelne HL7 v2-Schnittstelle von einer Bibliothek wie HAPI HL7v2 oder hl7apy gehandhabt werden kann. Die Engine verdient ihren Platz bei vielen Systemen und Formaten.

Ein Greenfield-System, dessen Partner alle FHIR sprechen, kann einen FHIR-Server mit Subscriptions und ein API-Gateway für Authentifizierung, Ratenbegrenzung und Routing verwenden, mit Transformationen in normalen Diensten. Eine einzelne HL7 v2-Schnittstelle kann von einer kleinen Bibliothek (HAPI HL7v2 in Java, hl7apy oder python-hl7 in Python) innerhalb der Anwendung gehandhabt werden. Die Engine verdient ihren Platz, wenn es viele Systeme, viele Formate und die Notwendigkeit einer Betriebskonsole gibt, die Nicht-Entwickler beobachten können.

In Anpheros

Die Anpheros Platform befindet sich auf der FHIR-Seite der Engine: Krankenhäuser leiten die zu teilenden Datenflüsse (Ergebnisse, Dokumente, Begegnungen) über ihre Engine oder über den Labor-Konnektor dorthin und lesen über FHIR-APIs und Webhooks zurück. Die Entwickler-Website zeigt das HL7 v2 zu FHIR Mapping, das der Konnektor anwendet.

Verwandte Seiten

Quellen

Häufige Fragen

Ist eine Schnittstellen-Engine dasselbe wie eine ESB oder eine iPaaS?

Gleiche Familie, spezialisiert: Eine Schnittstellen-Engine wird mit HL7 v2, DICOM, CDA und FHIR-Unterstützung, MLLP, gesundheitsspezifischer Überwachung und der Vokabularintegration, die Teams verwenden, geliefert. Allgemeine ESBs und iPaaS-Produkte können die Aufgabe mit mehr Aufwand erledigen.

Kann die Engine HL7 v2 automatisch in FHIR konvertieren?

Mehrere Engines enthalten Mappings, die auf dem HL7 v2-zu-FHIR-Leitfaden basieren, und sie verarbeiten die gängigen Segmente. Lokale Konventionen, Z-Segmente und Code-Mappings erfordern immer Projektarbeit.

Speichert die Engine Patientendaten?

Sie speichert Nachrichten während der Übertragung und hält den Nachrichtenverlauf zur Fehlerbehebung vor, was Patientendaten sind und geschützt und gelöscht werden müssen. Sie sollte nicht als Langzeitspeicher oder System der Aufzeichnung verwendet werden.

Open Source oder kommerziell?

Beides ist in großen Krankenhäusern im Einsatz. Die Entscheidung hängt in der Regel von Support, Fähigkeiten, Clustering-Anforderungen und den aktuellen Lizenzbedingungen ab, die sich für einige Produkte geändert haben; prüfen Sie dies vor der Verpflichtung.

Anpheros Platform

Kostenlos in der Sandbox testen

Ihr erster FHIR-Aufruf in 5 Minuten. Eine HL7 FHIR R4 API mit der Zustimmung des Patienten: probieren Sie sie in der Sandbox aus und verbinden Sie dann Ihre eigene App oder Ihr Kliniksystem.

Kostenlos · 30 synthetische Patienten · keine Karte

Dieser Ratgeber dient der Information und ersetzt keine ärztliche Beratung. Sprechen Sie bei Entscheidungen über Ihre Gesundheit mit Ihrem Arzt oder Ihrer Ärztin. Im Notfall rufen Sie die örtliche Notrufnummer an (112 in Europa).
Erstellt von
Das Anpheros-Team

Anpheros entwickelt eine Patientenakte, die der Patient kontrolliert und mit jeder Klinik teilen kann, auf einer HL7 FHIR R4-Plattform mit Sitz in der EU. Diese Anleitungen helfen Ihnen, Ihre Gesundheit zu verstehen und zu organisieren; sie ersetzen nicht Ihren Arzt.

Über Anpheros →