FHIR in Deutschland

FHIR ist in Deutschland der De-facto-Standard für neue Schnittstellen im Gesundheitswesen. Zwischen veröffentlichten Profilen, gesetzlichen Pflichten und tatsächlich genutzten Schnittstellen liegen aber deutliche Unterschiede. Ein Überblick darüber, wer die Vorgaben macht, welche verbindlich sind und was im Versorgungsalltag angekommen ist. Stand Oktober 2026.

Was ein Profil ist

Der internationale FHIR-Standard definiert allgemeine Ressourcen wie Patient, Observation oder MedicationRequest. Ein Profil schränkt eine Ressource für einen bestimmten Zweck ein: welche Felder Pflicht sind, welche Codesysteme gelten, welche deutschen Besonderheiten abgebildet werden. Profile können aufeinander aufbauen: Ein allgemeines Profil legt Grundlegendes fest, ein spezielleres schränkt es für einen konkreten Anwendungsfall weiter ein. So bauen etwa die E-Rezept-Profile der KBV über deren eigene Basisprofile auf den Basisprofilen von HL7 Deutschland auf. Profile werden zu Packages gebündelt und meist auf Simplifier veröffentlicht. Ein Implementation Guide (IG) beschreibt dazu, für welchen Anwendungsfall die Profile gedacht sind und wie sie zusammenspielen.

Wer welche Profile herausgibt

• HL7 Deutschland: die Basisprofile für Identifikatoren wie KVNR, IKNR und LANR, deutsche Adressen und Namen sowie Codesysteme wie ICD-10-GM und OPS. Sie sind selbst nicht verbindlich, bilden aber die Grundlage fast aller anderen deutschen Profile.
• gematik: ISiK für Krankenhäuser, in Stufe 5 mit zehn Modulen vom Basismodul über Dokumentenaustausch, Terminplanung und Medikation bis zur Verlegung zwischen Intensiv- und Normalstation. Dazu ISiP für die Pflege, die FHIR-Schnittstellen der ePA mit dem Medication Service, die Workflow-Profile des E-Rezepts und das FHIR-Verzeichnis des TI-Messengers.
• KBV und mio42: die Medizinischen Informationsobjekte (MIOs) für die ePA, darunter Impfpass, Mutterpass, Kinderuntersuchungsheft, Zahnbonusheft, Patientenkurzakte und Überleitungsbogen. Außerdem die Verordnungsprofile des E-Rezepts und die elektronische Arbeitsunfähigkeitsbescheinigung (eAU).
• Deutsche Gesetzliche Unfallversicherung (DGUV): eigene Basisprofile für Arbeitsunfälle und Berufskrankheiten, etwa für Durchgangsärzte, Unfallereignisse, Unfallbetriebe und Unfallversicherungsträger.
• Medizininformatik-Initiative: der Kerndatensatz für die Forschung an Universitätskliniken, mit jährlichen Releases und Modulen unter anderem für Person, Diagnose, Prozedur, Labor, Medikation und Consent.
• RKI und gematik: DEMIS für Meldungen nach dem Infektionsschutzgesetz, von Laborbefunden bis zur Bettenbelegung.

Die meisten dieser Profile bauen auf den Basisprofilen von HL7 Deutschland auf, aber nicht auf derselben Version. ISiK Stufe 5 setzt Version 1.5.4 voraus, die aktuellen E-Rezept-Profile der KBV noch 1.5.2. Dazu kommen unterschiedliche Release-Zyklen, jährlich bei der MII und in Stufen bei ISiK, und Übergangsphasen, in denen alte und neue Versionen parallel gelten.

Gemeinsame Grundlagen machen die Profile auch nicht automatisch kompatibel. Ein Laborwert unterliegt bei ISiK und im Kerndatensatz der MII jeweils eigenen Profilen, Pflichtfeldern und Terminologievorgaben. Wer Daten zwischen Krankenhausinformationssystem, ePA und Forschungsplattform austauscht, muss diese Unterschiede abbilden und zwischen den Profilen übersetzen.

Wie ein Profil verbindlich wird

Die Veröffentlichung einer Spezifikation macht sie nicht automatisch verbindlich. Verbindlich wird sie in der Regel über § 385 SGB V: Das Kompetenzzentrum für Interoperabilität bei der gematik schlägt sie vor, das Bundesministerium für Gesundheit nimmt sie per Verordnung in Anlage 1 der IOP-Governance-Verordnung auf, mit Frist und betroffenen Systemen. Dort stehen derzeit vier Einträge:

• Elektronische Medikationsliste der ePA, seit 15. Januar 2025
• ePA Medication Service für Praxis-, Krankenhaus- und Apothekensysteme, bis 31. Dezember 2026
• ISiK Stufe 5 für Krankenhausinformationssysteme, bis 31. Mai 2027
• ePA Medication Service für Pflegesysteme, bis 30. September 2027

Drei der vier Einträge betreffen die Medikation. Für ISiK ist die Verordnung nicht die erste Pflicht. Hersteller mussten frühere Stufen bereits umsetzen und bestätigen lassen, Stufe 2 etwa bis 1. Juli 2024. Die Fristen legte bisher die gematik selbst fest. Mit Stufe 5 läuft das erstmals über die Verordnung, gegen den Widerstand der Deutschen Krankenhausgesellschaft (DKG).

Ob ein Produkt die Vorgaben erfüllt, prüft eine Konformitätsbewertung nach § 387 SGB V. Die Folgen unterscheiden sich je nach Sektor. Arztpraxen dürfen nur mit konformitätsbewerteten Systemen gegenüber der Kassenärztlichen Vereinigung abrechnen (§ 372). Krankenhäuser dürfen für die von § 373 erfassten Systeme nur konformitätsbewertete Produkte einsetzen, eine vergleichbar direkte Kopplung an die Vergütung fehlt aber. Einige Anwendungen haben eigene Rechtsgrundlagen, etwa das E-Rezept in § 360 SGB V oder DEMIS im Infektionsschutzgesetz.

Was tatsächlich produktiv läuft

In der Breite produktiv sind vor allem Anwendungen mit einer Pflicht für alle Beteiligten und einfachem Ablauf. Laut ABDA wurden 2025 rund 582 Millionen E-Rezepte eingelöst. Auch eAU, DEMIS-Labormeldungen und die Medikationsliste der ePA laufen im Alltag. Der Kerndatensatz der MII ist an den Datenintegrationszentren der Universitätskliniken im Einsatz. Über das Forschungsdatenportal für Gesundheit (FDPG) stellen Forschende darauf standortübergreifende Machbarkeitsanfragen und beantragen Daten und Bioproben.

Anders sieht es bei vielen anderen Profilen aus. Mehrere MIOs sind festgelegt, werden in der ePA aber noch nicht strukturiert genutzt, einen festen Zeitplan gibt es nach Aussage der gematik nicht. Bei ISiK stellte ein Arbeitskreis des Interop Councils Anfang 2024 fest, dass kaum eine Verwendung in Produktivumgebungen erfolgt, obwohl alle Hersteller bestätigungsrelevanter Systeme zertifiziert waren. Unter den befragten Krankenhäusern meldete nur eines eine Nutzung. Als Gründe nennt das Papier unter anderem, dass unklar sei, ob Krankenhäuser ISiK nutzen müssen, und dass ein Business Case fehle. Repräsentativ ist die Befragung nach Angabe der Autoren nicht. Die elektronische Verordnung von DiGA ist bis auf Weiteres freiwillig.

Das Muster ist deutlich: Ein Profil allein verändert wenig. Interoperabilität entsteht erst, wenn mindestens zwei Seiten Daten austauschen wollen oder müssen. Beim E-Rezept sind Praxis, Fachdienst, Apotheke und Krankenkasse gleichzeitig verpflichtet, und der Ablauf funktioniert nur über den Austausch. Bei ISiK muss vor allem die bereitstellende Seite die Schnittstelle nachweisen, abrufen muss sie niemand. Die DKG spricht selbst von einer "sich wechselseitig verstärkenden Angebots- und Nachfrageschwäche".

Was als Nächstes kommt

• Der Europäische Gesundheitsdatenraum verlangt den grenzüberschreitenden Austausch von Patientenkurzakten und E-Rezepten ab März 2029, von Laborbefunden, Entlassbriefen und Bildgebung ab März 2031. Für Hersteller zählt vor allem: Systeme mit elektronischen Patientendaten, also auch Krankenhaus- und Praxissysteme, brauchen dann eine Komponente für das europäische Austauschformat und eine CE-Kennzeichnung. Der Entwurf von ISiK Stufe 6 gleicht bereits einzelne Profile an europäische an. Die deutsche Umsetzung regelt das Gesetz für Daten und digitale Innovation im Gesundheitswesen (GeDIG), über das der Bundestag voraussichtlich im November abschließend berät.
• Gegen die Zersplitterung arbeitet das Kompetenzzentrum für Interoperabilität an Kernprofilen als gemeinsamer, verbindlicher Basis für alle deutschen FHIR-Spezifikationen. Die Grundlagenanalyse fordert unter anderem, Release-Zyklen mit den Umsetzungsfristen verbindlicher Spezifikationen abzustimmen. Ein Governance-Whitepaper ist vom 19. Oktober bis 16. November 2026 zur Kommentierung offen.
• Alle national relevanten Spezifikationen basieren heute auf FHIR R4. R5 haben die großen Herausgeber 2024 bewusst übersprungen. Als mögliche nächste führende Version gilt FHIR R6, das frühestens Ende 2027 erscheinen soll. Eine gemeinsame Migrationsstrategie gibt es noch nicht, neue Spezifikationen sollen aber schon jetzt mit R6 abgeglichen werden.

Ein veröffentlichtes Profil schafft noch keinen interoperablen Datenaustausch. Entscheidend sind verbindliche Vorgaben, ihre Umsetzung in den Primärsystemen und die tatsächliche Nutzung der Schnittstellen. Wer heute eine FHIR-Schnittstelle plant, sollte deshalb früh klären, welche Profile und Versionen tatsächlich gefordert sind, und die Übersetzung zwischen ihnen von Anfang an einplanen. Wie sich das auf die interne Datenhaltung auswirkt, beschreibt unser Artikel zum passenden Datenmodell für Gesundheitsdaten.