Schnittstellen-Strategie: Pragmatik vor Architektur-Idealismus

Eine IT-Leitung in einem 250-Betten-Akutkrankenhaus betreibt ein Krankenhaus-Informationssystem (KIS) aus dem Jahr 2008. Es spricht Health Level Seven Version 2 (HL7-V2) über eine Schnittstellen-Engine, hat einen partiellen Adapter zur elektronischen Patientenakte (ePA) der gematik und sonst keine Health Level Seven Fast Healthcare Interoperability Resources (HL7-FHIR)-Schicht. Ein KI-Anbieter zeigt eine elegante FHIR-R4-API-Demo. In dieser Konstellation wird die Demo nicht ohne sechsstellige Schnittstellen-Investition produktiv. Die naheliegende Frage lautet: Warum hat das KIS noch keine vollständige FHIR-Schicht? Die Antwort ist trivial: weil seine Architektur aus einer Zeit vor dem FHIR-Standard stammt. Die nicht naheliegende Frage lautet: Welche zwei oder drei Schnittstellen-Muster erlauben heute einen produktiven KI-Aufsatz, ohne die KIS-Architektur durch eine Vollumstellung zu blockieren? Die Antwort darauf entscheidet darüber, was in den nächsten 18 bis 36 Monaten in deutschen Kliniken überhaupt mit KI-Aufsatz produktiv wird — und sie entscheidet sich auf einer Achse, die die FHIR-Idealismus-Frage gar nicht stellt.

Was die FHIR-Vision verspricht — und was die deutsche KIS-Realität liefert

Die FHIR-Spezifikation Release 4 (R4) ist 2019 als normativ markiert worden. Sie definiert ressourcen-orientierte Datenstrukturen — Patient, Observation, Condition, MedicationRequest und rund 140 weitere — mit einer REST-basierten Programmier-Schnittstelle und JSON / XML als Serialisierung. Bender und Sartipi (2013) beschreiben die Konzeption früh: FHIR sollte die in HL7-V3 (Clinical Document Architecture, CDA) angelegte Komplexität reduzieren und die V2-Vielfalt strukturell ablösen — über eine agile Spezifikations-Methodik mit Fokus auf 80-Prozent-Anwendungsfälle. Das ist die Vision. Die deutsche Realität ist davon entfernt: Die meisten produktiven KIS-Schnittstellen sprechen weiterhin V2.x, ergänzt durch herstellerspezifische Eigenheiten in Schnittstellen-Engines wie Mirth Connect oder vergleichbaren Produkten. Eine Schnittstelle, die FHIR-Sticker trägt, ist heute typischerweise ein partieller Adapter für eine spezifische Anwendung — ePA-Befüllung, ein einzelnes Medizinisches Informationsobjekt (MIO) — kein semantisch durchgängiges Daten-Modell.

Die Bitkom-Krankenhausstudie 2024 — Selbst-Auskunft von 200 Geschäftsführer:innen und IT-Leitungen — bewertet die Interoperabilität deutscher Klinik-IT-Systeme zu 90 Prozent als „eher schlecht“ oder „sehr schlecht“; etwa 60 Prozent nutzen weiterhin V2.x als primären Schnittstellen-Standard; FHIR-Adoption beschränkt sich überwiegend auf ePA und ausgewählte MIOs. Die Mehrheit der Häuser plant in den nächsten fünf Jahren keine FHIR-Vollumstellung. Bitkom-Studien sind branchen-finanziert, die Stichprobe geneigt auf Mitglieds-Häuser, die Selbst-Auskunft subjektiv. Die strukturelle Beobachtung ist trotzdem konvergent mit anderen Quellen: Beiträge im Bundesgesundheitsblatt (2020 bis 2025) dokumentieren, dass deutsche Krankenhäuser unter dem Krankenhauszukunftsgesetz (KHZG) Interoperabilitäts-Investitionen vorgezogen haben — mehrheitlich auf der V2-Schicht und in spezifischen FHIR-Anwendungen. Eine flächendeckende FHIR-Vollumstellung wurde unter KHZG nicht gefördert und ist in der KIS-Landschaft nicht erkennbar. Die operative Lese ist also nicht „FHIR kommt bald flächendeckend“, sondern „FHIR entsteht anwendungs-bezogen“.

Drei Schnittstellen-Muster, die heute in der deutschen Klinik-IT real funktionieren

Erstens: HL7-V2.x über eine Schnittstellen-Engine. Die V2-Nachrichten-Familie (ADT für Aufnahme-Entlassung-Verlegung, ORM für Aufträge, ORU für Befunde) wird seit den 1990er Jahren produktiv betrieben und trägt heute die Mehrheit der KIS-zu-KIS-Verbindungen in deutschen Häusern. Eine Schnittstellen-Engine wie Mirth Connect oder ein vergleichbares Produkt nimmt eine V2-Nachricht entgegen, transformiert sie in das Format einer nachgelagerten Anwendung — auch in JSON für eine moderne API — und routet sie. Eigenheit: V2 ist konfigurations-gebunden, nicht standard-portabel. Die Bedeutungs-Auslegung jeder Nachricht ist häufig haus-bezogen konfiguriert (Custom Z-Segments, lokale Mappings). Eine V2-Schnittstelle ist also keine semantisch interoperable Schnittstelle — aber sie ist eine, die heute funktioniert. Für viele KI-Aufsätze, die Aufnahme-Daten, Diagnose-Codes oder Befund-Texte als Eingabe brauchen, ist V2 über eine Schnittstellen-Engine der schnellste Weg zu einem produktiven Eingang. Die Bedingungs-Frage lautet nicht „Ist V2 modern?“, sondern „Liefert V2 die fachlich nötigen Datenpunkte mit einer prüfbaren Latenz und einem dokumentierten Fehler-Pfad?“. Wenn ja, ist die Schnittstellen-Engine die richtige erste Schicht.

Zweitens: IHE-Profile für Dokumenten-zentrierten Austausch. Integrating the Healthcare Enterprise (IHE) ist eine Profile-Sammlung über HL7- und DICOM-Basis. Cross-Enterprise Document Sharing (XDS) — als XDS.b über SOAP oder als Mobile Access to Health Documents (MHD) über FHIR — adressiert den Austausch fertiger Dokumente zwischen Einrichtungen; Patient Identifier Cross-Referencing (PIX) adressiert die Patient:innen-Identifikation über mehrere Systeme. IHE Deutschland adaptiert die internationalen Profile an deutsche Anforderungen — Affinity-Domain-Definitionen für regionale Gesundheits-Netzwerke, Implementation-Guides für nationale Anwendungen. Die Profile sind nicht bindend; sie sind getestet, iteriert über Connectathons, und funktionieren in der Versorgungs-Realität. Der pragmatische Punkt ist: Für KI-Aufsätze, die fertige Dokumente verarbeiten — Entlassbriefe, Befund-Texte, Operations-Berichte — ist IHE-XDS oder MHD ein produktives Muster, ohne dass das KIS in seiner Tiefe FHIR-konform werden muss. Die Adoption hängt von der regionalen Netzwerk-Struktur ab; eine bundesweite XDS-Domäne existiert nicht. Aber dort, wo regionale Strukturen tragen, ist IHE der saubere Mittelweg.

Drittens: FHIR R4 für strukturierte Datenpunkte in eng definierten Anwendungen. Die elektronische Patientenakte (ePA) für alle der gematik — bundesweit ausgerollt seit April 2025, Befüllungs-Pflicht seit Oktober 2025 — ist FHIR-basiert und zwingt KIS-Hersteller zu einer FHIR-Mindest-Schicht. Die Medizinischen Informationsobjekte (MIO) der KBV ergänzen mit FHIR R4-Profilen für Mutterpass, eImpfpass, Patientenkurzakte, eAU. Mandel und Kolleg:innen (JAMIA 2016) beschreiben mit SMART on FHIR die operative Plattform-Spezifikation — FHIR plus OAuth 2.0-Autorisierung plus App-Launch-Mechanik —, die modulare klinische Anwendungen gegen ein FHIR-konformes KIS betreiben lässt, ohne in den KIS-Quellcode einzugreifen. Die Voraussetzung ist die FHIR-Schicht im KIS; in deutschen Häusern ist diese Voraussetzung in vielen Fällen nicht erfüllt, in einigen Häusern auf ePA und ausgewählte MIOs reduziert. Wo die FHIR-Schicht aber trägt, ist sie der saubere Muster für strukturierte Datenpunkte mit klaren Ressourcen-Definitionen. Die Pragmatik bedeutet hier: Welche Ressourcen braucht der KI-Aufsatz wirklich, und lassen sich diese über die ePA-FHIR-Schicht oder über ein MIO-Muster ziehen? Wenn ja, ist FHIR R4 das richtige Muster. Wenn nein — etwa weil die nötigen Strukturen nur in haus-bezogener V2-Konfiguration vorliegen — ist die Schnittstellen-Engine die ehrlichere Schicht.

Wo die Pragmatik an ihre Grenzen kommt

Pragmatik bedeutet nicht, die FHIR-Vision zu kassieren. Sie bedeutet, sie nicht als Bedingungs-Variable für die nächste KI-Beschaffung zu missverstehen. Drei Grenzen sind real. Erstens: Semantische Interoperabilität. Eine V2-Engine löst keinen semantischen Datenmodell-Konflikt zwischen Häusern; sie transportiert Nachrichten, deren Bedeutungs-Auslegung haus-bezogen konfiguriert ist. Mandl und Kohane (NEJM 2012) beschrieben früh die Architektur-These: Die Trennung zwischen Daten-Schicht (das KIS) und Anwendungs-Schicht (das Modul, der Aufsatz) muss über offene Schnittstellen erfolgen, damit Anwendungs-Innovation nicht von KIS-Vollumstellung abhängt. Diese Trennung ist heute über IHE und partielles FHIR möglich; semantisch belastbar wird sie erst mit FHIR-Tiefe. Zweitens: Dauerhaftigkeit der Heterogenität. Reisman (2017) dokumentiert für die US-Landschaft, dass trotz dreißigjähriger Bestrebungen die strukturelle Schnittstellen-Heterogenität ein dauerhafter Befund bleibt — auch dort, wo die EHR-Adoption höher ist als in Deutschland. Die strukturelle Lese-Übertragung auf Deutschland ist nicht eins-zu-eins; sie deutet aber an, dass die Pragmatik kein Übergangs-Zustand ist, sondern die Normal-Konstellation der nächsten Jahrzehnte. Drittens: Latenz und Konsistenz unter Last. Eine V2-Engine, die heute zwei Nachrichten pro Sekunde routet, ist eine andere Architektur-Frage als eine, die zweihundert pro Sekunde unter strukturellen Spitzen verarbeiten muss. Die Muster-Wahl wird bei steigender Last enger; an einem bestimmten Punkt rechtfertigt sich die FHIR-Investition.

Was eine Schnittstellen-Strategie an der Pragmatik-Stelle leisten muss

Drei Disziplinen unterscheiden eine pragmatische Schnittstellen-Strategie von einer FHIR-Bekenntnis-Strategie. Erstens: eine Daten-Bedarfs-Karte pro KI-Anwendung. Welche Eingangs-Datenpunkte sind klinisch zwingend, in welcher Granularität, mit welcher Latenz, in welchem Fehler-Modus? Die Karte entsteht im Anwendungs-Kontext, nicht in der Schnittstellen-Engine. Zweitens: eine Muster-Zuordnung pro Datenpunkt. Welcher der drei Muster (V2 / IHE / FHIR R4) liefert den Datenpunkt heute? Wo erzwingt der Datenbedarf eine neue Schnittstelle — als lokale V2-Custom-Segment-Erweiterung, als regionale IHE-Profile-Anpassung oder als strategischer FHIR-Schicht-Ausbau? Drittens: ein Architektur-Fahrplan mit anwendungs-bezogenen Etappen. Eine FHIR-Vollumstellung ist nicht das nächste Beschaffungs-Projekt; aber jede neue klinische Anwendung kann die FHIR-Schicht ein Stück weit ausbauen — wenn die Muster-Wahl mit dieser Etappen-Logik abgestimmt ist. Wo diese drei Disziplinen nicht zusammenkommen, wird die Schnittstellen-Investition entweder zu früh (eine FHIR-Schicht ohne hinreichenden Anwendungs-Bezug verbrennt) oder zu spät (eine Anhäufung von V2-Custom-Segmenten verhärtet die haus-bezogene Eigenheit). Die Pragmatik ist die Architektur-Disziplin, die diese beiden Fehler vermeidet.

Die Pragmatik-Position ist keine Resignation gegenüber dem FHIR-Idealismus. Sie ist seine operative Übersetzung in eine Klinik-IT-Realität, in der drei Schnittstellen-Muster parallel tragen und drei Disziplinen die Muster-Wahl strukturieren. Wer die FHIR-Schicht ohne Anwendungs-Bezug fordert, verschiebt die Investition zu früh. Wer die V2-Engine als Endzustand begreift, verschiebt sie zu spät. Die Schnittstellen-Strategie entscheidet sich an der Stelle, an der die Daten-Bedarfs-Karte einer konkreten klinischen Anwendung auf den heutigen Muster-Bestand des Hauses trifft — und nicht in einem Architektur-Bekenntnis, das den Bestand ignoriert.