Official URL: https://gematik.de/fhir/epa-medication/ImplementationGuide/de.gematik.epa.medication | Version: 1.2.0 | |||
Active as of 2025-09-12 | Computable Name: EPA_Medication | |||
Copyright/Legal: gematik GmbH / Dieser Implementation Guide ist lizenziert unter Apache License, Version 2.0. |
Seiteninhalt:
Die ePA für alle stärkt den digital gestützten Medikationsprozess (dgMP) in dem sie an den Versorgungsschnittstellen Medikationsinformationen für Medikationsanalyse und -management bereitstellt. Dies wird vornehmlich durch
die automatische Befüllung der elektronischen Medikationsliste (eML) mit verordneten und abgegebenen Arzneimitteln,
der Möglichkeit der Dokumentation von geplanten Arzneimittelanwendungen inkl. Dosierinformation,
der Bereitstellung einer Übersicht über aktuelle und zukünftig einzunehmende Arzneimittel auf dem elektronischen Medikationsplan (eMP),
der Bearbeitung von Statuswerten von Medikationen auf dem eMP sowie
das Ändern von Dosierangaben zu verordneten und abgegebenen Arzneimitteln und eMP-Medikationen
erreicht. Der ePA Medication Service (kurz Medication Service) des dgMP unterstützt diese Funktionalitäten über eine HL7 FHIR-basierte Verarbeitung.
Dieser Implementation Guide sollte “von links nach rechts” gelesen werden. Ausgehend von der Fachlichkeit wird anschließend die dazugehörige FHIR-Modellierung über technische Anwendungsfälle beschrieben, die schließlich in FHIR-Ressourcen und -APIs aufgehen:
Fachlichkeit | In einem Überblick werden fachliche Zusammenhänge des dgMP mitsamt den Sichtkonzepten eML und eMP erläutert. Weiterhin werden idealtypische Szenarien des dgMP für verschiedene Sektoren und diesbezügliche fachliche Anwendungsfälle beschrieben. |
---|---|
Technische Umsetzung | Die technische Umsetzung der Prozessunterstützung wird anhand technischer Anwendungsfälle erläutert. Diese sind:
|
Schnittstellen | Die Schnittstellen des Medication Service setzen sich aus Query API, Operation API sowie Render API zusammen. Allgemeingültige und ePA-spezifische Anforderungen an FHIR Data Services als auch Datenschutz- und Datensicherheitsaspekte werden in diesem Abschnitt dargelegt. |
FHIR-Artefakte | Hier findet sich eine tabellarische Übersicht aller in diesem Implementation Guide verwendeten FHIR-Artefakte zu Schnittstellen und Inhaltsdaten für Abruf und Verwaltung von Medikationsdaten. |
Anhänge | Diesem Implementation Guide werden Download-Artefakte (u.a. Paketdatei, Beispiele, Schematron-Dateien, dieser Guide im ZIP-Format), OpenAPI-Spezifikationen, Release Notes sowie Steckbriefe angehängt. |
Der Medication Service ist Teil des FHIR-basierten Datenraums des ePA-Aktensystems. Grundsätzlich sollen die FHIR-Profile größtmöglich wiederverwendet und damit so wenig wie möglich eingeschränkt werden. Anforderungen an eine FHIR-basierte Verarbeitung werden auf unterschiedlichen Ebenen festgehalten:
Hierfür wurden die dedizierten FHIR Implemenation Guides (IGs) TI Common, ePA Basic sowie in diesem Fall Medication Service geschrieben. Die ersten beiden FHIR IGs ermöglichen die Nachnutzung wiederkehrerender Anforderungen auf Ebene anderer, zukünftiger Produkttypen der TI und anderen FHIR Data Services des ePA-Aktensystems, um letztlich ein gleichartiges Verhalten gegenüber Client-Implementierungen, wie Primärsystemen, zu gewährleisten. Übergreifende Terminologien werden separat als FHIR Package Dependency verwaltet.
Die Auswahl geeigneter FHIR-Ressourcen für die Verarbeitung strukturierter Daten und die inhaltlichen Festlegungen der Profile orientieren sich vornehmlich an den Deutschen Basisprofilen von HL7 Deutschland e.V. sowie dem HL7 FHIR-Standard selbst. Aber auch die enge Kombatibilität zum E-Rezept als auch die teilweise inhaltlich verwandten FHIR-Profile von ISiK (Abk. für Informationstechnische Systeme in Krankenhäusern) waren ausschlaggebend für die Profilierung dieser FHIR-Ressourcen. Die Gewährleistung einer clientseitigen Weiterverarbeitung (auch Ableitung) ist ebenso Bestreben bei der FHIR-Profilierung. In der Regel wurden daher Kardinalitäten nicht eingeschränkt, das Must Support-Konzept wo notwendig platziert. Begründungen für die Auswahl und inhaltliche Belegung von FHIR-Elementen erfolgen prosaisch nur in Ausnahmefällen. Hier sei auf die inhaltlichen Beschreibungen und Definition des FHIR-Standards verwiesen. Sämtliche FHIR-Elemente wurden in englischer Sprache, Erklärungen und Kommentare innerhalb eines Profils in deutscher Sprache definiert.
Zu den Prinzipien der integren Datenverarbeitung im Medication Service gehört u.a. die vollständige Kontrolle über die gespeicherten FHIR-Daten. Das bedeutet, dass jedwede übergebene FHIR-Instanz von außen niemals direkt gespeichert wird, sondern lediglich als Data Transfer Object (DTO) dient. Nach entsprechenden Prüfungen in den Geschäftslogiken (Validierung, Einhaltung von Regeln etc.) werden jeweils ausschließlich mit Must Support gekennzeichnete Elemente in eine neu erzeugte oder zu aktualisierende FHIR-Instanz übernommen. Auch Referenzen werden intern erzeugt. Somit obliegt diesem FHIR Data Service auch die Vergabe von Resource.id und Versionsnummer innerhalb einer Transaktion. Die Nachweisbarkeit von Änderungen in Schreibvorgängen wird über intern erzeugte Provenance-Instanzen sichergestellt. Sämtliche Zugriffsaktiviäten werden darüber hinaus über AuditEvent-Instanzen festgehalten, welche dem oder der Versicherten über das ePA-FdV oder über die Ombudsstelle seiner/ihrer Krankenkasse zu Verfügung gestellt werden.
Bestandteil jeder FHIR Data-Service-Spezifikation des ePA-Aktensystems ist das Capability Statement. FHIR-Ressourcentypen und -profile, Interaktionen (CRUD), Suchparameter und Operations werden darüber definiert und können programmatisch weiterverarbeitet werden. Zu den FHIR IGs der ePA gehören zudem beigestellte OpenAPI-Spezifikationen, welche allerdings im Vergleich zu den besagten Statements aufgrund der nicht deckungsgleichen Repräsentation aller FHIR-Konzepte (u.a. Constraints) nicht verbindlich im Sinne einer Zulassung der gematik sind. Ferner stellt ein FHIR IG der ePA Beispiele zum Download zur Verfügung.
IG | Package | FHIR | Comment |
---|---|---|---|
de.gematik.epa.medication#1.2.0 | R4 | ||
hl7.terminology.r4#6.5.0 | R4 | Automatically added as a dependency - all IGs depend on HL7 Terminology | |
hl7.fhir.uv.extensions.r4#5.2.0 | R4 | ||
de.basisprofil.r4#1.5.4 | R4 | ||
de.fhir.medication#1.0.0 | R4 | ||
de.gematik.terminology#1.0.7 | R4 | ||
dvmd.kdl.r4#2025.0.1 | R4 | ||
de.gematik.ti#1.1.1 | R4 | ||
de.gematik.epa#1.2.0 | R4 | ||
de.gematik.fhir.directory#1.0.0 | R4 | ||
hl7.fhir.uv.tools.r4#0.8.0 | R4 | for example references |
Package hl7.fhir.uv.extensions.r4#5.2.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Mon, Feb 10, 2025 21:45+1100+11:00) |
Package de.basisprofil.r4#1.5.4 Projekt Basisprofilierung R4 (HL7 Deutschland e.V.) |
Package dvmd.kdl.r4#2025.0.1 Publikation der Terminologie-Ressourcen für die Nutzung der Klinische Dokumentenklassen-Liste (KDL) des DVMD Version 2025 |
Package de.gematik.terminology#1.0.7 Terminologies for Telematics Infrastructure (TI) |
Package de.gematik.ti#1.1.1 Telematikinfrastruktur (TI) Common |
Package de.gematik.epa#1.2.0 ePA Basisfunktionalitäten |
Package de.gematik.fhir.directory#1.0.0 gematik FHIR Directory: Verzeichnisdienst der Telematikinfrastruktur |
Package hl7.fhir.uv.tools.r4#0.8.0 This IG defines the extensions that the tools use internally. Some of these extensions are content that are being evaluated for elevation into the main spec, and others are tooling concerns (built Tue, Aug 5, 2025 20:09+1000+10:00) |
Zur besseren Lesbarkeit wird in diesem Implementation Guide das generische Maskulinum verwendet. Die hier verwendeten beziehen sich stets auf alle Geschlechter.
Der Begriff “Arzt” wird in diesem Implementation Guide sowohl für Human- als auch für Zahnmediziner verwendet.
Allgemeine Fragen und Kommentare zum Implementation Guide können Sie über das [Anfragenportal] der gematik einreichen. Falls kein Zugang besteht, senden Sie bitte eine E-Mail an “patientteam [ at ] gematik [ dot ] de” mit dem Betreff “Anfragenportal Zugang”.