Der vorherige Artikel beschreibt Terminologie-Drift: FHIR-Daten verlieren ihre Konformität, weil sich externe Codesysteme ändern, unabhängig von Änderungen am eigenen System. Das betrifft jedes FHIR-System. In Märkten mit mehreren parallelen FHIR-Initiativen vervielfacht sich das Problem. Deutschland hat eine besonders dichte Landschaft solcher Initiativen.
Als ich an der Uniklinik Köln die Formulare eines klinischen Dokumentationssystems auf FHIR abbildete, wurde schnell deutlich: Es gibt keinen einzelnen „deutschen FHIR-Standard“. Es gibt mehrere. Sie verwenden dieselbe Basistechnologie, teilen manche Terminologiebindungen und überschneiden sich teilweise in ihren Definitionen. Dennoch werden sie von unterschiedlichen Organisationen gepflegt, verfolgen unterschiedliche Zwecke und haben unterschiedliche Konformitätsanforderungen.
Für Entwickler ist die Orientierung anspruchsvoll. Ein großes deutsches Universitätsklinikum muss möglicherweise mehrere dieser Anforderungen gleichzeitig erfüllen, teilweise für dieselben klinischen Daten und Ressourcenfamilien.
Dieser Artikel gibt einen Überblick. Er ist nicht vollständig, zeigt aber, warum FHIR-Validierung in Deutschland mehrere unabhängige Anforderungskontexte berücksichtigen muss.
gematik: eine zentrale Rolle
Die gematik nimmt eine zentrale Rolle bei der Digitalisierung des deutschen Gesundheitswesens ein. Für Krankenhaus-IT und KIS-Hersteller ist sie besonders relevant, weil sie Anforderungen festlegt, die im jeweiligen gesetzlichen Rahmen verbindlich werden.
Sie ist für die Telematikinfrastruktur (TI), das nationale Gesundheitsnetz, und für ISiK zuständig, den auf § 373 SGB V beruhenden Standard für Krankenhausinteroperabilität. Für die formale Bestätigung eines einschlägigen KIS-Produkts durchläuft der Hersteller das Bestätigungsverfahren der gematik.
ISiK: Anforderungen an Krankenhaussoftware
ISiK steht für „Informationstechnische Systeme im Krankenhaus“. Die technischen Anforderungen betreffen die einschlägigen Krankenhausinformationssysteme im Rahmen von § 373 SGB V.
ISiK definiert unterstützte FHIR-Ressourcen, Profilvorgaben und Terminologiebindungen für die jeweiligen Module. Das Programm ist in Stufen gegliedert; Stufe 5 ist veröffentlicht, Stufe 4 wurde eingestellt. Quellenstand 9. September 2026: GIGV Anlage 1, Nummer 002 nennt den 31. Mai 2027 als Umsetzungsfrist für den dort aufgeführten Leitfaden der Stufe 5 für Krankenhausinformationssysteme. Die veröffentlichten Implementierungsleitfäden sind über das ISiK-Spezifikationsrepository und den Leitfaden-Index der gematik erreichbar.
Das Krankenhauszukunftsgesetz (KHZG) und sein Fördervolumen von 4,3 Milliarden Euro für die Krankenhausdigitalisierung beschleunigten die Einführung von ISiK. Geförderte Krankenhäuser investierten in neue klinische Systeme, bei denen ISiK-Konformität häufig eine zentrale Anforderung war. Das KHZG definierte die technischen Standards nicht selbst, schuf aber den finanziellen Anreiz für ihre Umsetzung.
Für KIS-Hersteller und Krankenhaus-IT ist ISiK damit ein zentrales Anforderungsprogramm: rechtlich verankert, mit formaler Bestätigung und von der gematik veröffentlichten und gepflegten Profilen.
Daneben betreut die gematik ISiP, die „Informationstechnischen Systeme in der Pflege“. ISiP ist ein eigener Umsetzungspfad. Es überträgt ein ähnliches Muster auf die Pflege: FHIR-basierte Schnittstellen, ein formales Bestätigungsverfahren und Profilanforderungen, deren Entwicklung Primärsystemhersteller verfolgen müssen.
MII: ein paralleler Standard für die Forschung
Die Medizininformatik-Initiative (MII) ist ein eigenständiges, vom Bundesministerium für Bildung und Forschung gefördertes Programm. Ihr Ziel ist ein anderes: Klinische Forschung soll unterstützt werden, indem Krankenhausdaten einrichtungsübergreifend abfragbar und vergleichbar werden.
Die MII hat Datenintegrationszentren (DIZ) in der deutschen Universitätsmedizin und bei ausgewählten außeruniversitären Partnern aufgebaut. Diese implementieren den Kerndatensatz (KDS) als FHIR-R4-Profile in Modulen wie Person, Fall, Diagnose, Prozedur, Laborbefund, Medikation, Biobank und Bildgebung.
Der KDS ist selbst versioniert und entwickelt sich weiter. Die MII veröffentlicht bereits eine 2026er Generation des KDS-Basisleitfadens. Schon deshalb ist MII-Konformität keine einmalige Mapping-Aufgabe.
Hier entsteht die Überschneidung: Die MII-Profile betreffen viele derselben Ressourcentypen wie ISiK – Patientendaten, Behandlungsfälle, Diagnosen und Laborbeobachtungen. Es sind jedoch nicht dieselben Profile.
Die Überschneidung an einem konkreten Beispiel
Sowohl ISiK als auch MII definieren Profile für die Patient-Ressource. Das ISiK-Patient-Profil konzentriert sich auf die klinische Identifikation. Dazu gehören spezifische deutsche Identifier-Typen wie die krankenhausinterne Patientennummer und die von der gematik vorgesehenen Angaben zur GKV- beziehungsweise PKV-Versicherung. Diese Identifier braucht ein klinisches System für den Betrieb.
Das MII-Modul Person setzt andere Schwerpunkte. Es umfasst Darstellungen für die Forschungsdateninfrastruktur, darunter pseudonymisierte Patientendaten. Identifier und Verknüpfungen richten sich hier nach Anforderungen aus Forschung, Datenschutz und föderierter Verarbeitung, nicht allein nach der Identifikation im Krankenhausbetrieb.
Eine Patient-Ressource, die die klinischen Identifier-Anforderungen von ISiK erfüllt, erfüllt deshalb nicht zwangsläufig die Forschungs- und Pseudonymisierungsanforderungen der MII. Eine für die Forschung optimierte MII-Person-Darstellung enthält möglicherweise nicht die Identifier, die ISiK im klinischen Betrieb verlangt. Beide können gültiges FHIR sein und dieselbe klinische Realität beschreiben. Ohne Transformation sind sie trotzdem nicht austauschbar.
Dieses Muster findet sich in mehreren überlappenden Modulen: gleicher Ressourcentyp, unterschiedliche Vorgaben, anderer Umgang mit Terminologie und andere Must-Support-Anforderungen – gepflegt von unterschiedlichen Gremien mit unabhängigen Veröffentlichungszyklen.
Ein Universitätsklinikum mit DIZ muss beide Anforderungskontexte berücksichtigen. Die ISiK-Bestätigung betrifft die Interoperabilität des KIS im festgelegten Umfang. Die MII-Implementierung ermöglicht die Verwendung der Daten für föderierte Forschungsabfragen. Keiner dieser Nachweise ersetzt den anderen.
DiGA: ein weiterer Kontext
Die Regelung zu Digitalen Gesundheitsanwendungen (DiGA) in § 139e SGB V hat einen Verordnungsweg für digitale Gesundheitsanwendungen geschaffen, deren Kosten die gesetzlichen Krankenkassen übernehmen. DiGA folgen einem anderen Verfahren als ISiK oder MII. Sie sind hier relevant, weil Anforderungen an Interoperabilität im deutschen Gesundheitswesen zunehmend über FHIR-basierte Mechanismen und Validierungsprüfungen formuliert werden.
Das BfArM veröffentlicht außerdem FHIR-Implementierungsleitfäden für Daten in den DiGA-, DiPA- und HIIS-Verzeichnissen. Für Krankenhaus-IT und KIS-Hersteller ist dies weniger unmittelbar relevant als ISiK. Mit der engeren Verbindung von Patientenanwendungen, Pflegeanwendungen, Geräteverzeichnissen und klinischer Infrastruktur lohnt es sich dennoch, diese Entwicklung zu verfolgen.
Was das für die Validierung bedeutet
Die deutsche FHIR-Landschaft hat keinen einzelnen Endpunkt. Dieselben klinischen Daten müssen möglicherweise für verschiedene Empfänger nach unterschiedlichen Profilsätzen dargestellt und validiert werden. Diese Profile werden von unterschiedlichen Organisationen gepflegt.
Eine Patient-Ressource zu validieren und als konform zu bezeichnen reicht daher nicht aus. Die Fragen lauten: Konform zu welchem Profil? Für welchen Empfänger? Zu welchem Zeitpunkt?
Eine reine ISiK-Prüfung sagt nichts Verlässliches über die MII-Konformität eines Krankenhauses aus. Eine reine MII-Prüfung im DIZ zeigt umgekehrt nicht, wie sich die Daten in einer ISiK-Integration verhalten würden. Beide Profilwelten entwickeln sich unabhängig weiter. Ein Datensatz, der heute beide erfüllt, kann nach einem Profil-Update nur noch einer davon entsprechen.
Mehrere Standards, unterschiedliche zuständige Stellen, teilweise Überschneidungen und unabhängige Entwicklung prägen diese Validierungsaufgabe. Ein CI-Test gegen einen einzelnen Profilsatz deckt sie nicht vollständig ab. Wiederkehrende Prüfungen des gewählten Datenumfangs gegen die jeweils relevanten, versionierten Profile ergänzen diesen Nachweis.
Der nächste Artikel behandelt ISiK genauer: den geltenden Anforderungsumfang, die Aussage des Bestätigungsverfahrens und die Prüfungen im Betrieb.
