Der vorherige Artikel behandelt ISiK und die Anforderungen an FHIR-Schnittstellen in Krankenhaussoftware. ISiK betrifft die Bereitstellung von Daten: Welche Form haben sie, wenn sie das Krankenhaus verlassen? Dieser Artikel betrachtet die nächste nationale Ebene, auf der strukturierte Gesundheitsdaten im großen Maßstab praktisch relevant werden.
Seit dem 1. Oktober 2025 ist die elektronische Patientenakte in ihrer Ausprägung „ePA für alle“ Teil des verpflichtenden Versorgungsalltags. Gesetzliche Krankenkassen stellen sie ihren Versicherten grundsätzlich bereit, sofern diese nicht widersprechen. Für die jeweils verpflichteten Leistungserbringer gelten Nutzungs- und Befüllungspflichten für die gesetzlich bestimmten Behandlungsdaten. Die ePA macht FHIR damit in einer landesweiten Infrastruktur relevant.
Nach Jahren in deutschen klinischen Systemen halte ich diesen Wandel für besonders bedeutsam. ISiK hatte FHIR bereits in die Krankenhäuser gebracht. Bei der ePA verändert sich vor allem, welche Art von Daten durch die Systeme fließt und in welchem Maßstab dies geschieht.
Von Dokumenten zu Daten
Die ursprüngliche ePA war praktisch ein Dokumentenspeicher: PDFs und strukturierte Dokumente wurden einer Person zugeordnet und über einen IHE-basierten Dokumentendienst ausgetauscht. Das ist nützlich, aber begrenzt. Ein Dokument öffnet und liest man; seine Inhalte sind nicht automatisch einzeln abfragbar.
Die „ePA für alle“ erweitert diese Architektur. Neben dem dokumentenbasierten Dienst gibt es einen Medication Service. Diese FHIR-Server-Komponente hält Medikationsdaten als strukturierte, einzeln adressierbare FHIR-Ressourcen vor. Abgabedaten fließen aus der E-Rezept-Infrastruktur ein. Der Dienst erzeugt die elektronische Medikationsliste (eML) als strukturierte FHIR-Daten, die ein Praxisverwaltungssystem direkt verarbeiten kann.
Der entscheidende Wandel führt von Dokumenten über Patienten zu strukturierten Patientendaten: abfragbar, vergleichbar und über Systemgrenzen hinweg wiederverwendbar. Genau an diesem Punkt wird Konformität für die Verarbeitung wesentlich.
Die MIO-Ebene
Medizinische Informationsobjekte (MIO) beschreiben strukturierte Inhalte über FHIR-Profile aus dem KBV-/mio42-Umfeld, die in den jeweiligen ePA-Spezifikationen umgesetzt werden. Die MII hat ihre KDS-Profile, die gematik ISiK und die Medikationsarchitektur der ePA ihre über die gematik-Infrastruktur realisierten Inhalte. Diese Profilwelten haben unabhängige Veröffentlichungszyklen.
Im digitalen Medikationsprozess nutzt die eML Verordnungs- und Abgabedaten. Der elektronische Medikationsplan ergänzt strukturierte Medikations- und Sicherheitsinformationen. Für die Implementierung müssen das geltende ePA-Release, der Implementierungsleitfaden und das FHIR-Paket getrennt bestimmt werden.
Quellenstand 24. September 2026: GIGV Anlage 1, Nummern 003 und 004 führt den Medication Service für ePA 3.1.3 mit Implementierungsleitfaden 1.3.0, aufgenommen am 15. September 2026. Nummer 003 nennt den 31. Dezember 2026 für die dort aufgeführten Praxis-, Zahnarztpraxis-, Krankenhaus- und Apothekensysteme. Nummer 004 nennt den 30. September 2027 für Primärsysteme in der Pflege. Das sind unterschiedliche Geltungsbereiche und Fristen, keine einheitliche Frist für alle ePA-Beteiligten.
Datenqualität in einem neuen Maßstab
Nationale FHIR-Programme teilen eine strukturelle Herausforderung: Viele unabhängige Systeme setzen dasselbe Profil auf unterschiedliche Weise um. ISiK betrifft Krankenhausinformationssysteme, die MII ihre Datenintegrationszentren. Bei der ePA kommen Praxen, Apotheken und Krankenhäuser im ganzen Land zusammen – sehr viele Datenquellen mit Software unterschiedlicher Hersteller, die eine gemeinsame Akteninfrastruktur beliefern.
Die Unterschiede verstärken sich über Systemgrenzen hinweg. Eine von einem Praxisverwaltungssystem erzeugte Medikationsressource kann Elemente enthalten, die ein anderes System auslässt. Ein Code, der im Terminologiestand eines Systems gültig ist, kann in einem anderen bereits abgelöst sein. Wer nur den eigenen Output betrachtet, kann deshalb nicht die Konformität sämtlicher Daten in der gemeinsamen Infrastruktur beurteilen.
Bei Medikationsdaten reicht die Bedeutung über eine Qualitätsanzeige hinaus. Eine nicht konforme oder falsch codierte Ressource kann eine Wechselwirkungsprüfung beeinflussen oder in einer Auswertung zur Arzneimitteltherapiesicherheit fehlen. Terminologiefehler können in Forschungsdaten eine Studie verzerren; bei Medikationsdaten, auf deren Grundlage behandelt wird, berühren sie die Patientensicherheit.
Einmal geprüft, fortlaufend im Betrieb
Die Anbindung eines Systems an die ePA wird im einschlägigen Verfahren geprüft. Danach fließen weiter Daten. Die beteiligten Systeme werden nach eigenen Zeitplänen aktualisiert und arbeiten mit versionierten FHIR-Profilen und Terminologien: Pharmazentralnummern (PZN), ATC-Klassifikationen und weiteren Codesystemen für Medikationsinhalte. Eine ePA-Release-Nummer ist nicht zugleich die Version jedes verwendeten MIO oder FHIR-Pakets.
Hier stellt sich dieselbe betriebliche Frage wie bei ISiK: Ein zu einem bestimmten Zeitpunkt erbrachter Konformitätsnachweis muss vom Zustand der tatsächlich verarbeiteten Daten im laufenden Betrieb unterschieden werden. Bei der ePA kommen landesweite Reichweite und die Bedeutung für die Patientensicherheit hinzu. Eine formale Prüfung allein liefert keinen fortlaufenden Nachweis über sämtliche Daten zwischen den Release-Zyklen.
Was das von den liefernden Teams verlangt
Für Hersteller, deren Software Medikationsdaten in die ePA schreibt, kommt zur bestandenen Anbindungsprüfung eine weitere Frage hinzu: Entsprechen die heute erzeugten FHIR-Daten den geltenden Profilen und Terminologien, und würden wir eine Abweichung bemerken?
FHIR-Output gegen Testdaten in der CI zu validieren, bevor ein Release ausgeliefert wird, ist notwendige Arbeit. Der aktuelle Zustand einer konkreten Datenlieferung ist eine zusätzliche Prüfaufgabe. Dafür braucht es eine benannte Auswahl, genaue Profil- und Terminologieversionen sowie nachvollziehbare Befunde und Folgeprüfungen.
