---
{
"title": "FHIR in Deutschland: Wegweiser durch ISiK, MII und EHDS",
"description": "Gemeinsamer Leitfaden von Health Samurai und Gefyra zur FHIR-Landschaft in Deutschland: Institutionen, Gesetze, Profilfamilien, sektorspezifische Pflichten und die Folgen des EHDS.",
"date": "2026-07-21",
"author": "Valeria Fursa, Patrick Werner",
"manual-translation": true,
"reading-time": "15 min read",
"tags": ["FHIR Standard", "FHIR Profiling", "Compliance"],
"tldr": "In Deutschland ist FHIR-Adoption vor allem eine Compliance-Frage. ISiK von der gematik, KBV und die MIOs, der MII-Kerndatensatz und nun auch der europäische EHDS legen jeweils eigene Anforderungen über FHIR R4. Dieser gemeinsame Leitfaden von Health Samurai und Gefyra kartiert die Institutionen, Gesetze und Profilfamilien — und zeigt, was sie für die zugrunde liegende Infrastruktur bedeuten.",
"utm-campaign": "fhir_expert",
"utm-content": "fhir-germany"
}
---
> For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt).
> Use it to discover all available pages before guessing URLs.
---
Ein gemeinsamer Leitfaden von Health Samurai und Gefyra GmbH
This guide is also available in English
Full English edition — ISiK, MII, EHDS, and the complete profile stack.
Deutschland ist einer der bedeutendsten FHIR-Märkte Europas. Nicht, weil der Standard hier unbekannt wäre, sondern weil die nationale Infrastruktur FHIR in gesetzlich regulierte Abläufe einbettet. FHIR R4 zu unterstützen ist der Ausgangspunkt — nicht das Ziel.
Dieser Beitrag kartiert die Institutionen, Gesetze, Profile und sektorspezifischen Pflichten, die darüber entscheiden, was FHIR-Adoption in Deutschland heute konkret bedeutet. Wir haben ihn für Entscheiderinnen und Entscheider geschrieben, die Interoperabilitätsprojekte für Krankenhäuser, Anbieter von Praxis- und Apothekensoftware, digitale Gesundheitsanwendungen und Forschungsdatenplattformen planen.
## Die institutionelle Landschaft
Mehrere eng verzahnte Institutionen steuern die digitale Gesundheitsinfrastruktur in Deutschland. Jede prägt einen eigenen Teil des FHIR-Ökosystems.
Die [gematik GmbH](https://www.gematik.de/) ist die nationale Agentur für die Telematikinfrastruktur. Ihr Zuständigkeitsbereich umfasst die elektronische Patientenakte (ePA) — Deutschlands bundesweite, patientengeführte Gesundheitsakte —, das elektronische Rezept (E-Rezept), die elektronische Arbeitsunfähigkeitsbescheinigung (eAU), sichere Kommunikationsdienste im Gesundheitswesen sowie [ISiK](https://www.gematik.de/anwendungen/isik), das Interoperabilitätsrahmenwerk für Krankenhäuser. Die gematik veröffentlicht [technische Spezifikationen](https://gemspec.gematik.de/); aktuelle Interoperabilitätsspezifikationen werden in der Regel als FHIR-Implementierungsleitfäden umgesetzt.
[HL7 Deutschland e.V.](https://www.hl7.de) pflegt die [deutschen Basisprofile](https://simplifier.net/packages/de.basisprofil.r4) (de.basisprofil.r4). Sie liefern die grundlegenden Bausteine für nationale FHIR-Implementierungen, indem sie das internationale FHIR R4 für die Nutzung in Deutschland einschränken. Die Basisprofile definieren wiederverwendbare Muster für zentrale Ressourcen, Datentypen wie Identifikatoren oder Adressstrukturen sowie Terminologie-Bindings, die von den zuständigen Spezifikationsorganisationen wie gematik, KBV oder der Medizininformatik-Initiative in ihren domänenspezifischen Implementierungsleitfäden übernommen und erweitert werden.
Die [Kassenärztliche Bundesvereinigung (KBV)](https://www.kbv.de/) ist die Selbstverwaltungskörperschaft der Vertragsärzteschaft und Psychotherapeutenschaft in der gesetzlichen Krankenversicherung und definiert die Interoperabilitätsanforderungen für die ambulante Versorgung. Ihre Tochtergesellschaft [Mio42 GmbH](https://mio42.de/) entwickelt die Medizinischen Informationsobjekte (MIOs): standardisierte FHIR-basierte Spezifikationen für strukturierte medizinische Dokumente und patientenzentrierte Aufzeichnungen, darunter der Impfpass, der Mutterpass und das Kinderuntersuchungsheft.
Das [Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM)](https://www.bfarm.de/) spielt eine zentrale Rolle in der deutschen Digital-Health- und Interoperabilitätslandschaft. Neben dem Verzeichnis für digitale Gesundheitsanwendungen (DiGA) verantwortet das BfArM die nationalen Terminologie- und Klassifikationssysteme, darunter SNOMED CT, ICD-10-GM, OPS und die LOINC-bezogene Infrastruktur. Es beherbergt außerdem das Forschungsdatenzentrum Gesundheit (FDZ Gesundheit), die Bundesinfrastruktur für die Sekundärnutzung von Abrechnungsdaten der gesetzlichen Krankenversicherung.
Das [Robert Koch-Institut (RKI)](https://www.rki.de/) betreibt DEMIS, das nationale Meldesystem für Infektionskrankheiten, das für die interoperable Meldung an den öffentlichen Gesundheitsdienst auf FHIR-basierte Schnittstellen setzt.
Die [Medizininformatik-Initiative (MII)](https://www.medizininformatik-initiative.de/), gefördert vom Bundesministerium für Bildung und Forschung (BMBF), koordiniert den Kerndatensatz — einen nationalen Kerndatensatz für die interoperable, einrichtungsübergreifende klinische Forschung. Der Standard ist in den Datenintegrationszentren aller deutschen Universitätskliniken implementiert und definiert harmonisierte FHIR-basierte Datenstrukturen, gegliedert in domänenspezifische Module wie Diagnosen, Labordaten, Medikation, Consent und Genomik.
Die Deutsche Rentenversicherung (DRV) betreibt Berichtsprozesse in der Rehabilitation, die von Jahr zu Jahr stärker auf FHIR setzen. Über Versorgung, Abrechnung, öffentliche Gesundheit und Forschung hinweg sind es diese Institutionen, die festlegen, wie FHIR in der Praxis angewendet wird.
## Die EU-Ebene: EHDS
Die Verordnung über den Europäischen Gesundheitsdatenraum (European Health Data Space, [EHDS](https://eur-lex.europa.eu/eli/reg/2025/327/oj)) ist im März 2025 in Kraft getreten und legt eine neue europäische Interoperabilitätsebene über die bestehenden nationalen Rahmenwerke. Deutsche FHIR-basierte Initiativen wie ePA, ISiK, MIOs und der MII-Kerndatensatz werden sich zunehmend an den entstehenden EU-Anforderungen für grenzüberschreitenden Datenaustausch, semantische Interoperabilität und die Sekundärnutzung von Gesundheitsdaten ausrichten müssen.
Der EHDS ruht auf zwei Säulen. Der Rahmen für die Primärnutzung ermöglicht den grenzüberschreitenden Zugriff auf Gesundheitsdaten für die Versorgung sowie den Bürgerzugang über MyHealth@EU. Der Rahmen für die Sekundärnutzung regelt den Zugang zu Gesundheitsdaten für Forschung, Innovation, Politikgestaltung und regulatorische Zwecke über HealthData@EU und eine benannte Zugangsstelle für Gesundheitsdaten (Health Data Access Body) in jedem Mitgliedstaat. Über die Interoperabilität hinaus zielt der EHDS darauf ab, einen harmonisierten europäischen Rahmen und Binnenmarkt für elektronische Patientenaktensysteme und digitale Gesundheitsdienste zu schaffen.
Das technische Fundament der Interoperabilität ist das European Electronic Health Record Exchange Format (EEHRxF), ein FHIR-basiertes Rahmenwerk, das Spezifikationen wie die [International Patient Summary](https://hl7.org/fhir/uv/ips/) (IPS) einbezieht. Die regulatorischen Pflichten greifen schrittweise entlang eines gestaffelten Zeitplans:
* **März 2027**: Frist für die Europäische Kommission, die zentralen Durchführungsrechtsakte zu erlassen, die die operativen und technischen Details des EHDS-Rahmens festlegen.
* **März 2029**: Die erste Prioritätsgruppe (Patientenkurzakten, E-Verordnungen, E-Dispensierungen) muss zwischen den Mitgliedstaaten austauschbar sein. Auch die meisten Regeln zur Sekundärnutzung beginnen zu gelten.
* **März 2031**: Die zweite Prioritätsgruppe (bildgebende Untersuchungen und Befunde, Laborergebnisse, Entlassberichte) folgt.
Parallel dazu werden EHR-Systeme, die auf dem EU-Markt in Verkehr gebracht werden, einem neuen Konformitätsbewertungsrahmen unter dem EHDS unterliegen. In der Praxis entsteht damit ein regulatorisches Interoperabilitäts- und Compliance-Regime, das im Geist der CE-Kennzeichnung für Medizinprodukte vergleichbar ist.
Für Deutschland ist die institutionelle Zuordnung bereits erkennbar. Der nationale EHDS-Knoten wird gemeinsam von der gematik, dem BfArM und der DVKA beim GKV-Spitzenverband (Deutsche Verbindungsstelle Krankenversicherung Ausland) aufgebaut. Die gematik verantwortet die telematikseitige technische Infrastruktur, die das deutsche ePA-Ökosystem mit den europäischen Diensten für den grenzüberschreitenden Austausch verbindet.
Mit fortschreitender EHDS-Umsetzung wird die ePA zunehmend Teil eines breiteren europäischen Interoperabilitätsnetzwerks und nicht mehr nur eine rein nationale Infrastruktur. Auf der Seite der Sekundärnutzung ist das Forschungsdatenzentrum Gesundheit (FDZ Gesundheit) beim BfArM — eingerichtet unter dem Gesundheitsdatennutzungsgesetz (GDNG) — gut positioniert, um Deutschlands künftige Aufgaben als Zugangsstelle für Gesundheitsdaten unter dem EHDS zu übernehmen.
Für Implementierer bedeutet das Konformität auf zwei Ebenen. Deutsche Basisprofile, ISiK, KBV/MIO-Spezifikationen, ePA und MII-Kerndatensatz müssen mit dem EEHRxF und den entstehenden europäischen Kernprofilen in Einklang gebracht werden. Diese Angleichungsarbeit ist bereits sichtbar: Der KIG, das Interoperabilitätsgremium der gematik, hat EHDS-Kompatibilität als explizites Ziel für die geplanten neuen deutschen Kernprofile benannt. Gelingt das, könnten diese Profile eine gemeinsame nationale Grundlage schaffen, die projektspezifische Mapping-Arbeit zwischen deutschen und europäischen Spezifikationen reduziert. Parallel dazu werden zentrale nationale Spezifikationen — darunter das ISiK-Rahmenwerk der gematik, der MII-Kerndatensatz und die KBV/MIO-Spezifikationen — zunehmend an europäischen Anforderungen gemessen und darauf ausgerichtet. Für Patientenkurzakten-Szenarien bedeutet das auch die Angleichung an IPS-basierte Datenmodelle. Ein Teil dieses Mappings ist unkompliziert: Der MII-Kerndatensatz basiert bereits auf R4 und liegt vergleichsweise nah an internationalen klinischen Austauschmustern. Andere Teile erfordern explizite Übersetzungsarbeit, insbesondere deutschlandspezifische Identifikatoren, Adressstrukturen, Extensions und nationale ValueSets. Für Anbieter von EHR- und Krankenhausinformationssystemen dürfte die Fähigkeit, beide Compliance-Ebenen — die nationale und die europäische — zu beherrschen, ein zunehmend wichtiger Faktor für Produktdesign, Zertifizierung und Beschaffung werden.
## Der rechtliche Rahmen, der FHIR zur Kaufentscheidung macht
Die oben beschriebenen Institutionen agieren nicht im luftleeren Raum. Ihre Autorität und Marktwirkung beruhen auf konkreten gesetzlichen Aufträgen. Die deutsche nationale Ebene stützt sich auf mehrere zentrale Gesetze.
Das [Fünfte Buch Sozialgesetzbuch (SGB V)](https://www.gesetze-im-internet.de/sgb_5) ist das Fundament der gesetzlichen Krankenversicherung — und die Quelle vieler Pflichten rund um die digitale Infrastruktur. Zwei Paragrafen sind besonders tragend:
* [§301 SGB V](https://www.gesetze-im-internet.de/sgb_5/__301.html) regelt die strukturierte Abrechnung und Berichterstattung der Krankenhäuser gegenüber den gesetzlichen Krankenkassen.
* [§373 SGB V](https://www.gesetze-im-internet.de/sgb_5/__373.html) liefert die Rechtsgrundlage für ISiK, das verpflichtende Interoperabilitätsrahmenwerk der gematik für Krankenhäuser.
Das Digital-Gesetz (DigiG), 2024 verabschiedet, hat die Digitalisierung des gesetzlichen Systems beschleunigt. Seine sichtbarste Folge: das Opt-out-Modell für die elektronische Patientenakte. Jede gesetzlich versicherte Person erhält nun automatisch eine ePA, sofern sie nicht aktiv widerspricht. Die ePA ist damit keine technisch verfügbare Option mehr, sondern ein Standardkanal für klinische Daten.
Das Gesundheitsdatennutzungsgesetz (GDNG), ebenfalls 2024 verabschiedet, regelt die Sekundärnutzung von Gesundheitsdaten. Es stärkt die Rechtsgrundlage des Forschungsdatenzentrums Gesundheit (FDZ Gesundheit) beim BfArM und schafft einen regulierten Weg für Forschung, Qualitätssicherung und weitere Sekundärnutzungen von Gesundheitsdaten — einschließlich der Abrechnungsdaten der gesetzlichen Krankenversicherung und, unter definierten Bedingungen, ePA-basierter Daten.
Das [Krankenhauszukunftsgesetz (KHZG)](https://www.bundesgesundheitsministerium.de/krankenhauszukunftsgesetz) war das große Förderinstrument für die Digitalisierung der Krankenhäuser in Deutschland. Über den Krankenhauszukunftsfonds schuf es einen Förderrahmen von 4,3 Milliarden Euro für die Krankenhausdigitalisierung — für Bereiche wie Patientenportale, digitale Dokumentation, Medikationsmanagement, klinische Entscheidungsunterstützung, Informationssicherheit und Interoperabilität. Die Hauptförderperiode ist zwar vorbei, doch das KHZG prägt die IT-Investitionen der Krankenhäuser weiterhin — über Umsetzungsanforderungen, Berichtspflichten und Abschläge für Häuser, die geforderte digitale Dienste nicht bereitstellen und nutzen. Auf der Krankenhausseite bleibt das KHZG damit ein wichtiger Umsetzungs- und Compliance-Treiber für interoperable, FHIR-fähige Infrastruktur.
### Konsolidierter Zeitplan
* 1\. Januar 2024: Das E-Rezept wird für vertragsärztliche Verordnungen und die Abgabe in Apotheken verpflichtend.
* 2024: DigiG und GDNG werden verabschiedet und liefern das rechtliche Gerüst für die *ePA für alle* und die Sekundärnutzung von Gesundheitsdaten.
* 15\. Januar 2025: Der Opt-out-Rollout der ePA beginnt mit der automatischen Anlage für nicht widersprechende Versicherte; die bundesweite Verfügbarkeit für Leistungserbringer folgte am 29. April.
* 2025/2026: Die KHZG-Digitalisierungsabschläge werden anhand der geforderten digitalen Dienste festgelegt und wirken sich auf die Vergütung nicht konformer Krankenhäuser aus.
* Fortlaufend: Die gematik veröffentlicht weiterhin aufeinanderfolgende ISiK-Stufen und Modulversionen.
## Der Profilstack
Die meiste Unklarheit in der deutschen FHIR-Landschaft entsteht durch die Schichtung der Profile. Die praktische Frage lautet: Welche Profilfamilie gilt in welchem Kontext, und welche nationalen Einschränkungen haben Vorrang?
**Die [deutschen Basisprofile](https://simplifier.net/packages/de.basisprofil.r4)**, gepflegt von HL7 Deutschland, liegen am nächsten an der Basisspezifikation. Sie liefern wiederverwendbare nationale Bausteine für Ressourcen und Datentypen, darunter Identifikatoren wie KVNR, BSNR und LANR, Adressstrukturen und Terminologie-Bindings. Nahezu jede nachgelagerte Profilfamilie baut auf ihnen auf.
**Die [ISiK-Profile](https://www.gematik.de/anwendungen/isik)**, veröffentlicht von der gematik, definieren die verpflichtenden Krankenhausschnittstellen nach §373 SGB V. Sie bauen auf den deutschen Basisprofilen auf und ergänzen krankenhausspezifische Einschränkungen für Bereiche wie Patientenverwaltung, Encounter, Diagnosen, Prozeduren und Medikation.
**Die KBV** ist zentral für die vertragsärztliche Versorgung und die berufsrechtlichen Regeln rund um das ambulante Verordnen, einschließlich des ambulanten Workflow-Kontexts des E-Rezepts. In Praxisverwaltungssystemen sind KBV-bezogene Anforderungen eine dominierende Konformitätsfamilie. Die technische E-Rezept-Infrastruktur und die FHIR-basierten Austauschspezifikationen werden jedoch innerhalb der gematik-/TI-Spezifikationslandschaft definiert.
**Die [ePA](https://www.gematik.de/anwendungen/epa)- und [E-Rezept](https://www.gematik.de/anwendungen/e-rezept)-Profile** definieren Datenflüsse und APIs innerhalb der Telematikinfrastruktur. Beim E-Rezept ist der Profilstack geteilt: Die KBV definiert die Verordnungsdatenprofile für die elektronische Arzneimittelverordnung, die gematik den E-Rezept-Workflow, die TI-Infrastruktur und die FHIR-basierten Austauschspezifikationen. Zusammen decken sie Verordnungsdatenobjekte, den Austausch von ePA-Dokumenten und -Metadaten, medikationsbezogene Daten und weitere TI-spezifische Dienste ab. Verwandte TI-Anwendungen und -Artefakte sind der elektronische Medikationsplan (eMP), der Notfalldatensatz (NFD) und die elektronische Arbeitsunfähigkeitsbescheinigung (eAU) — sie sollten allerdings nicht pauschal als eine einzige Profilfamilie behandelt werden.
**Die [MIOs](https://mio.kbv.de/)**, entwickelt von Mio42 im Auftrag der KBV, sind standardisierte FHIR-basierte Spezifikationen für strukturierte medizinische Dokumente im ePA-Kontext. Sie folgen den deutschen nationalen Profilierungskonventionen, einschließlich der deutschen Basisprofile, und definieren patientenzentrierte Akteninhalte wie Impf-, Mutterschafts-, Zahnbonus- und Kinderuntersuchungsdokumentation.
**Der [MII-Kerndatensatz](https://www.medizininformatik-initiative.de/de/der-kerndatensatz-der-medizininformatik-initiative)** definiert die FHIR-Profile, die von den Datenintegrationszentren der deutschen Universitätskliniken für Forschung und Sekundärnutzung verwendet werden. Er ist ein zentrales Konformitätsziel für den Austausch akademischer klinischer Forschungsdaten in Deutschland.
**[RKI DEMIS](https://www.rki.de/DE/Themen/Infektionskrankheiten/Meldewesen/DEMIS/demis-node.html)** definiert die FHIR-Profile für die Meldung von Infektionskrankheiten nach dem Infektionsschutzgesetz (IfSG) und ermöglicht die standardisierte elektronische Meldung an die Gesundheitsbehörden.
## Pflichten nach Sektoren
Die folgende Tabelle fasst zusammen, wie sich institutionelle, rechtliche und Profilebenen je Sektor stapeln. Sie ist nicht abschließend (die meisten Produktivsysteme berühren mehrere Zeilen), erfasst aber den dominierenden Compliance-Vektor je Käufergruppe.
| Sektor | Primäre Profilfamilien | Rechtsgrundlage | Primärer Treiber |
| :---- | :---- | :---- | :---- |
| Krankenhäuser | Deutsche Basisprofile, ISiK, MII (forschungsaktive Standorte), §301-konforme Berichterstattung | §373 SGB V, §301 SGB V, KHZG | TI-Teilnahme, KHZG-Umsetzungsanforderungen und Abschlagsrisiko bei der Vergütung |
| Ambulante Praxen | Deutsche Basisprofile, KBV, ePA, E-Rezept | SGB V, DigiG | Teilnahme an der GKV, E-Rezept-Pflicht, ePA-Integration |
| Apotheken | Deutsche Basisprofile, E-Rezept, TI-bezogene Spezifikationen | SGB V | Rezeptabgabe, TI-Teilnahme |
| DiGA-Hersteller | Deutsche Basisprofile, ePA-konformer Datenexport | §33a SGB V, DiGAV | BfArM-Listungsanforderungen |
| Öffentliche Gesundheit & Labore | RKI-DEMIS-Profile | IfSG | Gesetzliche Meldepflicht |
| Universitätskliniken & Forschung | MII-Kerndatensatz | GDNG, BMBF-Förderung, MII-Governance | Föderierte Forschung, Sekundärnutzung, FDZ-Zugang |
## Krankenhäuser: die KHZG-geprägte Dekade
Für Krankenhäuser wird die FHIR-Adoption weniger durch ein einzelnes Mandat geprägt als durch überlappende Kräfte: KHZG-geförderte Digitalisierungsprojekte, TI-/ePA-Integration, Forschungsanforderungen, Hersteller-Roadmaps und das entstehende ISiK-Konformitätsrahmenwerk. Die KHZG-geförderten Dienste — darunter Patientenportale, elektronisches Medikationsmanagement, klinische Entscheidungsunterstützung, strukturierte Dokumentation, Informationssicherheit und Interoperabilität — haben einen starken Investitionsschub für strukturierte Krankenhaus-IT ausgelöst. Nicht jede KHZG-Anforderung lässt sich direkt auf FHIR oder ISiK abbilden, aber viele daraus resultierende Beschaffungs- und Integrationsentscheidungen begünstigen Systeme, die strukturierte, interoperable und zunehmend FHIR-fähige Datenflüsse unterstützen.
ISiK ist in aufeinanderfolgenden Stufen und Modulen aufgebaut, nicht als einzelnes statisches Profilset. Es ist das FHIR-basierte Spezifikationsrahmenwerk der gematik für offene, standardisierte Krankenhausschnittstellen nach §373 SGB V und deckt Bereiche wie Patientenverwaltung, klinische Dokumentation, Medikation, Diagnostik, Formulare und weitere versorgungsnahe Abläufe ab. Die genaue Anwendbarkeit hängt vom jeweiligen ISiK-Modul, der Softwarekategorie und den Bestätigungsanforderungen ab.
§301 SGB V fügt eine separate administrative Abrechnungs- und Berichtsebene hinzu. Er ist kein FHIR-Mandat, prägt aber die Datenmodelle und Integrationsanforderungen der Krankenhäuser über standardisierte Abrechnungs-, Fachabteilungs- und kassenseitige Berichtsstrukturen. In der Praxis müssen Krankenhäuser diese administrativen Strukturen häufig mit ISiK-basierten klinischen Schnittstellen und internen Systemmodellen in Einklang bringen.
Krankenhäuser, die an Forschung teilnehmen, tragen eine zusätzliche Ebene. Ihre Datenintegrationszentren müssen in der Regel den MII-Kerndatensatz für die einrichtungsübergreifende Forschung und Sekundärnutzung unterstützen. Forschungs- und versorgungsseitige Datenflüsse teilen sich nicht automatisch dieselbe Infrastruktur oder dieselben Konformitätsziele — Universitätskliniken verwalten daher oft überlappende FHIR-Zuständigkeiten zwischen Versorgung und Forschung.
## Ambulante Versorgung und Apotheken
Für niedergelassene Ärztinnen und Ärzte ergeben sich die operativen Pflichten aus der Teilnahme an der gesetzlichen Krankenversicherung. Die E-Rezept-Pflicht, in Kraft seit Januar 2024, verlangt strukturierte elektronische Verordnungsabläufe. Der zugehörige FHIR-Profilstack verteilt sich auf mehrere Akteure: Die KBV definiert die Verordnungsdatenprofile für das ambulante Verordnen, die gematik den E-Rezept-Workflow, die TI-Infrastruktur und die FHIR-basierten Austauschspezifikationen. Praxisverwaltungssysteme werden daher von KBV-Anforderungen, E-Rezept-Workflow-Integration und gematik-/TI-Konformität geprägt.
Die ePA fügt eine zweite Ebene hinzu. Medikationsbezogene ePA-Dienste, einschließlich des Kontexts des elektronischen Medikationsplans, werden über FHIR-basierte Spezifikationen umgesetzt und beeinflussen, wie Ärzteschaft und Apotheken mit strukturierten Medikationsinformationen arbeiten. MIOs definieren standardisierte FHIR-basierte Dokumentstrukturen für bestimmte ePA-Anwendungsfälle. Je nachdem, welche MIOs ein Praxissystem unterstützt, können über E-Rezept und ePA-Kernintegration hinaus weitere Profilanforderungen hinzukommen.
Apotheken stehen am Abgabeendpunkt des E-Rezepts. Sie müssen die relevanten E-Rezept- und TI-Spezifikationen unterstützen: Rezepte abrufen, einlösen, Medikamente abgeben, gegebenenfalls Substitution handhaben und die erforderlichen Abgabe- und abrechnungsbezogenen Datenflüsse erzeugen.
## DiGA: digitale Gesundheitsanwendungen
Digitale Gesundheitsanwendungen, die [vom BfArM](https://diga.bfarm.de/de) nach §33a SGB V gelistet sind, werden von der gesetzlichen Krankenversicherung erstattet. Sie müssen definierte Interoperabilitätsanforderungen erfüllen, einschließlich maschinenlesbarem Datenexport und, wo einschlägig, ePA-bezogener Datenübertragung. Übersetzt heißt das: DiGA-Hersteller brauchen strukturierte Exportfähigkeiten, zunehmend ausgerichtet an FHIR-basierten Spezifikationen wie dem DiGA/MIO-Toolkit, damit App-generierte Daten im ePA-Kontext oder von behandelnden Leistungserbringern weiterverwendet werden können.
## Öffentliche Gesundheit, Rehabilitation und sektorübergreifende Versorgung
Die Meldung von Infektionskrankheiten läuft über RKI DEMIS mit FHIR-Profilen für die standardisierte elektronische Meldung nach dem Infektionsschutzgesetz (IfSG). Leistungserbringer und Labore, die meldepflichtige Erkrankungen übermitteln, müssen die relevanten DEMIS-Profile einhalten.
Versorgung endet nicht an Sektorgrenzen. Übergänge zwischen Krankenhäusern, ambulanten Praxen, Rehabilitation und häuslicher Pflege erfordern Interoperabilität zwischen Systemen mit unterschiedlichen rechtlichen, organisatorischen und technischen Rahmenbedingungen. Wo FHIR eingesetzt wird, bieten gemeinsame nationale Profilierungskonventionen wie die deutschen Basisprofile eine gemeinsame Grundlage — kontextspezifische Spezifikationen oder Extensions sind aber meist trotzdem nötig.
## Forschung und Sekundärnutzung
Die Medizininformatik-Initiative definiert den Kerndatensatz, einen zwischen den deutschen Universitätskliniken abgestimmten nationalen Kerndatensatz, der über FHIR-Profile für einrichtungsübergreifende Forschung und Sekundärnutzung implementiert wird. Die Datenintegrationszentren der Universitätsmedizin transformieren und harmonisieren klinische Routinedaten gemäß den MII-Spezifikationen und stellen sie für föderierte Machbarkeitsanfragen und den Forschungsdatenzugang über das Forschungsdatenportal Gesundheit (FDPG) bereit — im Rahmen der geltenden Governance- und Consent-Regelungen.
Das GDNG und das FDZ Gesundheit beim BfArM erweitern das Sekundärnutzungsmodell über die akademische Medizin hinaus auf GKV-Abrechnungsdaten und, unter definierten Bedingungen, ePA-basierte Daten. Sie eröffnen strukturierte Wege für Forschung und andere Nutzungen im öffentlichen Interesse. Liest man MII und GDNG nebeneinander, ist die Richtung klar: FHIR ist zum zentralen Interoperabilitätssubstrat der akademischen medizinischen Forschung in Deutschland geworden, während die Sekundärnutzungsinfrastruktur in den gesetzlichen und nationalen Gesundheitsdatenbereich hineinwächst. Für Universitätskliniken und MII-angebundene Forschungsstandorte entsteht damit eine zusätzliche FHIR-Konformitätsebene neben versorgungsseitigen Pflichten wie ISiK.
## Terminologie: eine unterschätzte Randbedingung
Terminologie-Bindings gehören zu den häufigsten Ursachen für späte Konformitätsprobleme in deutschen FHIR-Projekten. Zu den relevanten Kodiersystemen zählen:
* ICD-10-GM und OPS, die deutschen Modifikationen der ICD-10 und der Prozedurenklassifikation, gepflegt vom BfArM.
* ATC (anatomisch-therapeutisch-chemisch) und PZN (Pharmazentralnummer) für die pharmazeutische Klassifikation und Produktidentifikation.
* LOINC, vor allem für Laborergebnisse und strukturierte klinische Daten, einschließlich der Kodierung von Dokumentabschnitten.
* SNOMED CT, seit 2021 unter der nationalen Lizenz Deutschlands verfügbar und über das BfArM als National Release Center verwaltet; es wird in MII und anderen semantisch reichhaltigen Profilen zunehmend verpflichtend.
* ZTS (Zentraler Terminologieserver), der FHIR-Terminologieressourcen für deutsche Implementierungsleitfäden bereitstellt — ValueSets, CodeSystems, ICD-10-GM, OPS und weitere Terminologieartefakte, die von nationalen Terminologieverantwortlichen wie dem BfArM herausgegeben werden.
Wer Infrastruktur ohne eine ernsthafte Antwort auf Terminologiedienste wählt (ValueSet-Expansion, Code-Validierung, Code-Übersetzung, Versionsmanagement), für den wird Nacharbeit im Projekt zur verlässlichsten Prognose in diesem Markt.
## Übergreifende Compliance: Hosting, Sicherheit und Anbindung
Bei deutschen Gesundheitsdaten ist die technische Konformitätsfrage untrennbar mit der Compliance-Aufstellung verbunden. Drei Randbedingungen tauchen in nahezu jeder Beschaffung auf:
* BSI IT-Grundschutz und das BSI-C5-Testat (Cloud Computing Compliance Criteria Catalogue), insbesondere für Cloud-Infrastruktur. Nach [§393 SGB V](https://www.gesetze-im-internet.de/sgb_5/__393.html) benötigen Cloud-Dienste im Gesundheitswesen ein C5-Testat oder eine vergleichbare Zertifizierung.
* EU-Anforderungen an Datenverarbeitung und Hosting, mit je nach Anwendungsfall strengeren Vorgaben zu Deutschland-Hosting oder Souveränität — insbesondere für ePA- oder TI-nahe Datenflüsse.
* Die DSGVO, im Gesundheitswesen angewendet mit sektorspezifischen Leitlinien der oder des Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI) und der Landesdatenschutzbehörden.
Die Anbindung an die Telematikinfrastruktur bringt zusätzliche Abhängigkeiten mit sich: Konnektor oder TI-Gateway, eHBA (elektronischer Heilberufsausweis), SMC-B (Institutionskarte) sowie die KIM- und TI-Messenger-Familien für sichere Kommunikation. FHIR-Systeme in regulierten Abläufen werden in der Regel neben, manchmal hinter diesen Komponenten betrieben.
## Was das für die Implementierungsinfrastruktur bedeutet
Betrachtet man die deutsche Landschaft im Zusammenhang, ergeben sich einige strukturelle Anforderungen an das FHIR-Backend hinter jedem System, das diesen Markt bedient. Das sind keine abstrakten Präferenzen. Es sind die Fehlerbilder, die in der Produktion auftreten, wenn Teams unterschätzen, wie viel des deutschen Marktes in regulierten Abläufen steckt.
* Erstklassige Unterstützung für geschichtete Profilvalidierung. Ein Krankenhaussystem muss ähnliche klinische Daten je nach Workflow gegen unterschiedliche Profilfamilien validieren können — etwa ISiK für versorgungsseitige Schnittstellen und MII für den forschungsseitigen Austausch —, mit den deutschen Basisprofilen im Abhängigkeitsbaum. Die Validierung muss deterministisch und performant sein, auch mit Hunderten gleichzeitig geladener Profile.
* EEHRxF- und EHDS-Interoperabilitätskomponenten für die Konformität auf zwei Ebenen. Der EHDS ist nicht nur eine Anforderung an den grenzüberschreitenden Austausch. EHR-Systeme auf dem EU-Markt müssen die europäischen Interoperabilitäts- und Logging-Komponenten unterstützen, die der EHDS-Rahmen verlangt. Für deutsche Implementierungen heißt das: Nationale Profilfamilien wie ISiK, ePA, KBV/MIO und MII müssen mit einem Pfad Richtung EEHRxF und den entstehenden europäischen Kernprofilen entworfen werden. Für Patientenkurzakten-Szenarien bedeutet das die Angleichung an die europäische Patient Summary und ihr IPS-basiertes Datenmodell.
* Verwaltung von Profilpaketen und Version-Pinning. Deutsche FHIR-Profilpakete werden über die verschiedenen Spezifikationsfamilien hinweg häufig aktualisiert. Produktivsysteme müssen bestimmte Paketversionen laden, sie je Mandant oder Workflow umschalten und historische Validierungen auf Abruf reproduzieren können.
* Native Terminologiedienste für deutsche Kodiersysteme. ICD-10-GM, OPS, SNOMED CT unter der nationalen Lizenz, LOINC, ATC und die über den ZTS bereitgestellten Terminologieressourcen müssen abfragbar, expandierbar, versioniert und für die Validierungspipeline verfügbar sein.
* Mandantenfähige Architektur für Anbieter, die Dienste für mehrere Praxen, Krankenhäuser oder DiGA-Kundenumgebungen unter einem gemeinsamen Betriebsmodell betreiben.
* Compliance-taugliches Hosting in Deutschland oder der EU, mit Betriebspraktiken entlang von C5 und BSI IT-Grundschutz.
* Audit-Logging, Consent-Repräsentation und SMART-on-FHIR-Unterstützung, einschließlich reproduzierbarer Zugriffprotokolle, maschinenlesbarer Consent-Zustände und standardbasiertem Zugriff für Dritt-Apps, wo einschlägig.
* Ein klarer Weg zur Anbindung an die Telematikinfrastruktur und zum Betrieb neben ihren Komponenten, wenn der Workflow es verlangt.
## Fazit
Deutschland belohnt Teams, die FHIR nicht nur als Technologieebene begreifen, sondern als Teil des Compliance-Fundaments. Die hier beschriebenen Institutionen, Gesetze und Profilfamilien sind keine getrennten Themen. Sie sind dasselbe Problem, aus verschiedenen Blickwinkeln betrachtet. Die Reife der zugrunde liegenden Infrastruktur entscheidet, wie viel dieser Komplexität bei den Anwendungsteams ankommt — und wie viel des Budgets in die nutzerseitige Arbeit fließen kann, die ein Produkt tatsächlich differenziert.
Bei Gefyra arbeiten wir direkt in der deutschen und europäischen FHIR-Spezifikationslandschaft. Unser Team hat an nationalen Spezifikationen mitgewirkt und dazu beraten — darunter ISiK, weitere gematik-Spezifikationen, die deutschen Basisprofile, KBV/Mio42-Spezifikationen und der MII-Kerndatensatz. Wir sind zudem tief im europäischen Interoperabilitätskontext engagiert, einschließlich der Moderation von Implementierungsleitfäden und der Standardisierungsarbeit in HL7-Europe-Arbeitsgruppen. Diese Perspektive erlaubt es uns, FHIR-Infrastruktur unabhängig von einem einzelnen Hersteller-Stack zu bewerten.
Bei Health Samurai entwickeln und betreiben wir [Aidbox](https://www.health-samurai.io/fhir-server), die FHIR-Plattform hinter einer Reihe regulierter Gesundheitsworkloads in Europa und weltweit. Sie planen FHIR-Infrastruktur für den deutschen Markt — für ein Krankenhaus, einen Anbieter von Praxisverwaltungs- oder Apothekensoftware, eine DiGA oder eine Forschungsdatenplattform? Sprechen Sie mit [Health Samurai zur Aidbox-Infrastruktur](https://www.health-samurai.io/contacts) oder mit [Gefyra](mailto:sh@gefyra.de) für unabhängige Beratung zu Spezifikationen, Profilierung und deutscher/europäischer Interoperabilität. Wir gehen gern gemeinsam Profilabdeckung, Terminologieunterstützung, Hosting-Optionen und Referenzarchitekturen durch.
