Warum MedTech-Hersteller und Software-Vendoren mit der modernen Klinikinfrastruktur nicht Schritt halten

HL7, FHIR, IHE-Profile, MIRTH, DICOM — die Schnittstellenlandschaft moderner Kliniken hat sich in wenigen Jahren fundamental verändert. Viele Bestandssysteme wurden für eine Welt gebaut, die es so nicht mehr gibt.

Ein Medizingerätehersteller bringt ein neues Laboranalysesystem auf den Markt. Die Klinik interessiert sich, stellt aber früh die entscheidende Frage: Welche FHIR-Profile unterstützt das System, und wie erfolgt die Anbindung an unseren Integrationsserver? Die Antwort des Herstellers — „wir exportieren HL7 v2.x per Datei" — beendet das Gespräch. Nicht weil das technisch falsch ist. Sondern weil die Klinik längst in einer anderen Infrastrukturwelt angekommen ist.

Dieses Szenario wiederholt sich gerade branchenweit. Und es beschreibt ein strukturelles Problem, das viele MedTech-Hersteller und Software-Vendoren unterschätzen: Ihre Produkte wurden für eine Welt gebaut, in der Datenaustausch bilateral, synchron und proprietär funktionierte. Die Klinik von heute erwartet etwas grundlegend anderes.

Zwei Welten, die auseinanderdriften

HL7 Version 2 — kurz HL7 v2 — ist seit den späten 1980er Jahren der dominierende Standard für den klinischen Datenaustausch. Nachrichten wie ADT (Patientenbewegungen), ORM (Aufträge) oder ORU (Befunde) laufen in deutschen Kliniken noch heute zu großen Teilen über HL7-v2-Segmente. Das Protokoll ist robust, weit verbreitet — und gleichzeitig grundlegend anders konzipiert als die Anforderungen moderner Plattformarchitekturen.

HL7 v2 wurde für punktuelle, bilateral vereinbarte Verbindungen zwischen zwei Systemen entwickelt. Es gibt keine erzwungene Semantik: Zwei Systeme können beide HL7 v2 sprechen und trotzdem nicht miteinander kommunizieren, weil Felder unterschiedlich belegt, Segmente lokal erweitert oder Codes nicht standardisiert sind. Jede Verbindung ist faktisch ein individuelles Integrationsprojekt — und Kliniken, die über Jahrzehnte gewachsen sind, tragen heute ein Netz aus Hunderten solcher Punkt-zu-Punkt-Verbindungen mit sich, von denen niemand mehr alle kennt.

FHIR — Fast Healthcare Interoperability Resources, entwickelt von HL7 International — bricht mit dieser Logik. FHIR definiert Ressourcen (Patient, Observation, DiagnosticReport, MedicationRequest) als standardisierte JSON- oder XML-Objekte, die über RESTful APIs ausgetauscht werden. Das ermöglicht erstmals eine plattformunabhängige, maschinenlesbare Semantik — ein Patient ist ein Patient, unabhängig davon, welches System die Daten sendet. Genau das ist die Grundlage für Plattformansätze wie die Telematikinfrastruktur, das europäische Gesundheitsdatenraum-Vorhaben (EHDS) oder die klinische Datenintegration über SMART on FHIR-Apps.

Integrationsserver als Bindeglied — und als Spiegel des Problems

Zwischen der Welt der Altsysteme und der Welt der FHIR-Plattformen stehen Integrationsserver, die diese Übersetzung übernehmen. Mirth Connect — heute unter dem Namen NextGen Connect weiterentwickelt — ist einer der am weitesten verbreiteten Open-Source-Integrationsserver im Gesundheitswesen. Er kann HL7-v2-Nachrichten empfangen, transformieren, routen und in andere Formate wie HL7 v3, FHIR, DICOM oder proprietäre XML-Strukturen überführen.

Mirth ist dabei nicht die Lösung des Problems — es ist die Sichtbarmachung des Problems. Jede Transformation, die ein Integrationsserver vornimmt, ist ein Hinweis darauf, dass zwei Systeme nicht nativ miteinander sprechen können. Je mehr Transformationsstrecken eine Klinik betreibt, desto fragiler wird die Gesamtarchitektur: Jede neue Softwareversion eines angebundenen Systems kann eine bestehende Mirth-Channel-Konfiguration brechen. Jede Änderung am Datenmodell eines Quellsystems zieht eine Anpassung nach sich, die irgendwo in einer Transformationsregel versteckt ist, die vor Jahren jemand gebaut hat und die heute niemand mehr ohne Mühe liest.

Neben Mirth gibt es weitere Integrationsplattformen, die im Klinikumfeld eingesetzt werden: Rhapsody (heute Teil von Corepoint Health), Enovacom, InterSystems HealthShare und proprietäre Integrationsmodule großer KIS-Anbieter. Gemeinsam ist ihnen, dass sie Komplexität nicht auflösen, sondern kapseln. Das ist kurzfristig wertvoll und langfristig riskant.

IHE-Profile: Der Versuch, Semantik zu erzwingen

Integrating the Healthcare Enterprise — kurz IHE — ist eine Initiative, die versucht, die Schwäche von HL7 v2 zu adressieren: die fehlende erzwungene Semantik. IHE-Profile definieren, wie bestehende Standards wie HL7, DICOM oder FHIR in konkreten Anwendungsszenarien verwendet werden sollen. PDQ (Patient Demographics Query), PIX (Patient Identifier Cross-referencing) oder XDS (Cross-Enterprise Document Sharing) sind solche Profile — sie schreiben vor, welche Felder belegt sein müssen, welche Codes zu verwenden sind und in welcher Reihenfolge Nachrichten ausgetauscht werden.

Für MedTech-Hersteller und Software-Vendoren bedeutet das: IHE-Konformität ist keine Frage des guten Willens, sondern eine Marktzugangsbedingung. Ausschreibungen von Universitätskliniken und großen Krankenhausverbünden setzen IHE-Profile inzwischen voraus. Wer sie nicht erfüllt, scheidet aus — unabhängig von der medizinischen Qualität des Produkts.

Das Problem: IHE-Konformität nachzurüsten ist aufwendig. Es reicht nicht, einen neuen Endpunkt zu implementieren. Das gesamte Datenmodell muss auf Kompatibilität mit den Profilen geprüft, interne Bezeichner müssen auf standardisierte Code-Systeme wie LOINC, SNOMED CT oder ICD gemappt und die Kommunikationslogik muss grundlegend angepasst werden. Für ein Produkt, das über Jahre auf proprietärer Logik aufgebaut wurde, ist das kein Anpassungsprojekt — das ist eine Architekturentscheidung.

Warum Bestandssoftware strukturell im Nachteil ist

Die Schwierigkeiten von MedTech-Herstellern und Software-Vendoren, ihre Produkte für moderne Klinikinfrastrukturen aktuell zu halten, haben selten einen einzelnen Grund. Es ist ein Zusammenspiel aus technischer Schuld, organisatorischer Trägheit und einem Markt, der sich schneller verändert hat, als die meisten Produktbudgets erlauben nachzuziehen.

Viele Bestandssysteme wurden in einer Zeit entwickelt, in der Interoperabilität optional war. Die Datenbank war proprietär, die Schnittstellen waren bilateral verhandelt, der Integrationsbedarf war überschaubar. Das Produkt funktionierte — und solange es funktionierte, gab es keinen wirtschaftlichen Druck, die Architektur zu öffnen. Entwicklungskapazitäten flossen in klinische Features, nicht in Infrastruktur. Die technische Schuld wuchs still.

Gleichzeitig hat sich der Erwartungshorizont der Kunden fundamental verschoben. Die Telematikinfrastruktur, das KHZG, die MDR-Anforderungen an Software als Medizinprodukt und der kommende European Health Data Space haben die Messlatte innerhalb weniger Jahre neu gesetzt. Interoperabilität ist heute keine Zusatzanforderung mehr. Sie ist Voraussetzung für Zulassung, Erstattung und Marktfähigkeit.

Das Ergebnis ist ein struktureller Rückstand, den viele Hersteller nicht offen kommunizieren — aber der in jedem Klinikprojekt sichtbar wird, wenn die Integrationsfrage konkret auf den Tisch kommt. Die Lücke zwischen dem, was das Produkt beherrscht, und dem, was die Klinikinfrastruktur erwartet, wird dann durch Workarounds überbrückt: Exportdateien statt API-Calls, nächtliche Batch-Läufe statt Echtzeit-Ereignisse, Mirth-Transformationen statt nativer FHIR-Ressourcen. Das funktioniert — bis es nicht mehr funktioniert.

Was das für Hersteller konkret bedeutet

Eine FHIR-Fassade vor ein bestehendes System zu setzen ist technisch möglich und taktisch verständlich. Sie löst aber nicht das Grundproblem: ein Datenmodell, das nicht für standardisierte Semantik konzipiert wurde, lässt sich nicht einfach auf FHIR-Ressourcen mappen, ohne Informationsverluste oder Mehrdeutigkeiten in Kauf zu nehmen. Kliniken, die tiefer in die Integration einsteigen, bemerken das spätestens beim ersten Praxisprojekt.

Langfristig führt kein Weg daran vorbei, das Datenmodell selbst auf Interoperabilität hin zu überprüfen und dort, wo nötig, grundlegend umzubauen. Das ist ein mehrjähriges Vorhaben — und es beginnt damit, den Ist-Zustand ehrlich zu beschreiben: Welche Schnittstellen existieren, was transportieren sie, wo sind die Felder proprietär, und was wäre der Aufwand, auf LOINC- oder SNOMED-kodierte Ressourcen umzustellen? Für viele Hersteller ist diese Bestandsaufnahme der erste Schritt, den sie noch nicht gemacht haben.

Wer diesen Schritt aufschiebt, verliert nicht sofort Marktanteile. Aber er verliert sukzessive die Fähigkeit, in modernen Klinikinfrastrukturen als nativer Partner zu agieren — und wird stattdessen zum System, das man zwar noch betreibt, aber nicht mehr wirklich integriert.

Von Andreas Hepfner, CEO VIALUTIONS

Über VIALUTIONS 

VIALUTIONS consult GmbH, Berlin, unterstützt MedTech-Hersteller und Software-Vendoren bei der strukturierten Analyse und Modernisierung von Bestandssoftware — von der Schnittstellenbewertung über Reverse Engineering der Businesslogik bis zur schrittweisen Migrationsplanung. Kontakt: hepfner@vialutions.com · www.vialutions.com

HINTERGRUND & STANDARDS

HL7 International — HL7 Version 2 Product Suite & HL7 FHIR R4/R5 Spezifikation · www.hl7.org

IHE International — Integration Profiles (PDQ, PIX, XDS, MHD u.a.) · www.ihe.net

NextGen Connect (Mirth Connect) — Open-Source-Integrationsplattform für das Gesundheitswesen · www.nextgen.com/solutions/mirth-connect

DICOM Standard — Digital Imaging and Communications in Medicine · www.dicomstandard.org

gematik — Telematikinfrastruktur & FHIR-Basisprofile für Deutschland · www.gematik.de

Europäische Kommission — European Health Data Space (EHDS), Verordnungsentwurf 2022

EU-Verordnung MDR 2017/745 — Medizinprodukteverordnung, Anhang I & Klassifizierungsregeln für Software als Medizinprodukt

KHZG — Krankenhauszukunftsgesetz, Fördertatbestände Interoperabilität & Digitalisierung