FHIR ist keine moderne Schnittstelle — es ist eine Architekturentscheidung
Warum „wir brauchen auch eine FHIR-API“ selten Fortschritt bedeutet — und was die Architekturentscheidung von der Formatentscheidung unterscheidet.
Viele Interoperabilitätsprojekte beginnen mit einem einzigen Satz: „Wir brauchen auch eine FHIR-API.“ Das klingt nach Fortschritt. Meistens ist es keiner.
Was dann passiert
Der typische Ablauf ist gut eingeübt. HL7 v2 wird nach FHIR transformiert, ein REST-Layer kommt vor das Legacy-System, profiliert wird projektspezifisch — genau so weit, wie der aktuelle Use Case verlangt. Die Terminologie-Frage wird vertagt.
Technisch ist daran wenig auszusetzen. Die Mappings funktionieren, die Konformanztests laufen grün, die API liefert. Und strategisch ändert sich trotzdem nichts. Wer FHIR als zusätzliches Austauschformat einführt, hat sein Haus nicht modernisiert — er hat eine weitere Schnittstelle gebaut.
Der Denkfehler
Der Fehler steckt schon in der Einstiegsfrage. „Brauchen wir eine FHIR-API?“ behandelt FHIR als Format. Eine Schnittstelle verbindet zwei Systeme. Eine Architektur legt fest, auf welcher gemeinsamen Grundlage alle Systeme über dieselben Daten sprechen. Das eine ist ein Projekt mit Anfang und Ende. Das andere ist eine Festlegung, an der sich künftige Entscheidungen messen lassen müssen.
Was die Entscheidung bedeutet
Wer FHIR als Architektur ernst nimmt, baut nicht die nächste Punkt-zu-Punkt-Verbindung, sondern eine kanonische Datenebene, auf die sich alle anbindenden Systeme beziehen:
- Eine gemeinsame, kanonische Datenbasis statt projektweise nachgezogener Insellösungen.
- Standardisierte Semantik, verbindlich definiert — nicht implizit im jeweiligen Mapping vergraben.
- Event-basiert, sodass Veränderungen am Patientenkontext propagieren, statt in Batch-Exporten zu verschwinden.
- Herstellerunabhängig, damit die Datenhoheit beim Haus bleibt und nicht beim Anbieter.
- Als Basis für ein App- und KI-Ökosystem, das erst tragfähig wird, wenn die Grundlage stabil ist.
Erst wenn diese Grundlage steht, wird Integration zum technischen Detail. Vorher bleibt jede neue Anbindung die nächste Komplexitätsschicht über einer ungeklärten Basis.
Die 60 Prozent, über die niemand spricht
FHIR-Projekte werden als Technikprojekte verkauft. In der Praxis sind sie es zu höchstens 40 Prozent. Die übrigen 60 Prozent sind Organisation und Architektur: Wer verantwortet das Datenmodell? Wer entscheidet über Profile? Wer pflegt die Terminologie — und wer darf sie ändern?
Diese Fragen lassen sich nicht durch eine sauberere API beantworten. Sie sind organisatorisch, und sie brauchen Namen, keine Rollen. Solange sie offen bleiben, produziert auch das technisch beste FHIR-Projekt nur formale Konformität — und formale Konformität ist nicht dasselbe wie semantische Interpretierbarkeit.
Worauf das hinausläuft
FHIR macht semantische Unterschiede sichtbar. Es löst sie nicht. Die Frage ist nicht, ob ein Haus eine FHIR-API hat. Die Frage ist, ob FHIR Teil seiner Zielarchitektur ist — oder nur ein weiteres Format in der Sammlung.
Wir begleiten Krankenhäuser und ihre IT bei genau dieser Architekturarbeit — Profil-Governance, Terminologie-Bindung und die formale Beschreibung dessen, was die ausgetauschten Daten eigentlich sind. Wenn Sie FHIR als Zielarchitektur statt als Austauschformat denken wollen: Kontakt aufnehmen.
Die formale Grundlage dieser Arbeit — das Modell AION und die Referenzimplementierung CAIRN — ist unter aion-clinical.eu dokumentiert.