Implementation Guide
ePA Medication Service
Version 1.3.2 - release

## Home

Official URL: https://gematik.de/fhir/epa-medication/ImplementationGuide/de.gematik.epa.medication | Version: 1.3.2
Active as of 2026-03-20 | Computable Name: gemIG_ePA_Medication
Copyright/Legal: gematik GmbH / Dieser Implementation Guide ist lizenziert unter Apache License, Version 2.0.

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,

- die Möglichkeit der Dokumentation von geplanten Arzneimittelanwendungen inkl. Dosierinformation,

- die Bereitstellung einer Übersicht über aktuelle und zukünftig einzunehmende Arzneimittel auf dem elektronischen Medikationsplan (eMP),

- die Bearbeitung von Statuswerten zu geplanten Arzneimittelanwendungen auf dem eMP sowie

- das Ändern von Dosierangaben zu eMP-Medikationen

erreicht. Der ePA Medication Service (kurz Medication Service) des dgMP unterstützt diese Funktionalitäten über eine HL7 FHIR-basierte Verarbeitung.

### Organisation dieses Implementation Guide

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: Verordnung, Verschreibung und Dispensierung (inkl. Arzneimittelsubstitution bei Abgabe) mit dem eMP Nachtrag in der eML Nachtrag im eMP Aktualisierung eines eMP-Eintrags Hinzufügen und Entfernen einer eML-eMP-Verknüpfung Lesezugriffe für eML und eMP Diesen Beschreibungen schließen sich Verarbeitungsregeln zum FHIR-basierten Auslesen und der folgenden Anzeige in Benutzungsoberflächen für die eML als auch den eMP an. Zuletzt wird die Datenmigration beschrieben, die beim Aktualisieren des Medication Service auf eine neue Version durchgeführt werden müssen.
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.

Tabelle: Organisation dieses Implementation Guide

### Vorgehensweise bei FHIR-Profil-Spezifikation

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:

- auf Ebene der Telematikinfrastruktur (TI),
- auf Ebene des Datenraums des ePA-Aktensystems sowie
- auf Ebene des spezifischen Dienstes zur Unterstütztung einer Funktionalität oder eines Versorgungsprozesses.

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.

### Abhängigkeiten

IG | Package | FHIR | Comment
--- | --- | --- | ---
Implementation Guide ePA Medication Service | de.gematik.epa.medication#1.3.2 | R4 |
HL7 Terminology (THO) | hl7.terminology.r4#7.1.0 | R4 | Automatically added as a dependency - all IGs depend on HL7 Terminology
FHIR Extensions Pack | hl7.fhir.uv.extensions.r4#5.2.0 | R4 |
de.basisprofil.r4 | de.basisprofil.r4#1.5.4 | R4 |
Medication IG DE | de.fhir.medication#1.0.4 | R4 |
TI Terminology | de.gematik.terminology#1.0.9 | R4 |
dvmd.kdl.r4 | dvmd.kdl.r4#2025.0.1 | R4 |
Implementation Guide TI Common | de.gematik.ti#1.3.1 | R4 |
Implementation Guide ePA Basisfunktionalitäten | de.gematik.epa#1.3.1 | R4 |
Implementation Guide TI Common | de.gematik.ti#1.3.0 | R4 |
de.gematik.fhir.directory | de.gematik.fhir.directory#1.0.1 | R4 |
Implementation Guide Telematikinfrastruktur (TI) Common | de.gematik.ti#1.2.0 | R4 |
HL7 Terminology (THO) | hl7.terminology.r4#7.0.1 | R4 |
TI Terminology | de.gematik.terminology#1.0.8 | R4 |
FHIR Tooling Extensions IG | hl7.fhir.uv.tools.r4#1.1.2 | 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.9 Terminologies for Telematics Infrastructure (TI)

Package de.gematik.ti#1.3.1 Telematikinfrastruktur (TI) Common

Package de.gematik.ti#1.3.0 Telematikinfrastruktur (TI) Common

Package de.gematik.epa#1.3.1 ePA Basisfunktionalitäten

Package de.gematik.terminology#1.0.8 Terminologies for Telematics Infrastructure (TI)

Package de.gematik.ti#1.2.0 Telematikinfrastruktur (TI) Common

Package de.gematik.fhir.directory#1.0.1 gematik FHIR Directory: Verzeichnisdienst der Telematikinfrastruktur

Package hl7.fhir.uv.tools.r4#1.1.2 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, Mar 24, 2026 11:13+1100+11:00)

### Sprachliche Konventionen

- Zur besseren Lesbarkeit wird in diesem Implementation Guide das generische Maskulinum verwendet. Die hier verwendeten Personenbezeichnungen beziehen sich stets auf alle Geschlechter.

- Der Begriff “Arzt” wird in diesem Implementation Guide sowohl für Human- als auch für Zahnmediziner verwendet.

### Weitere Hinweise

- Bitte die Ausführungen des Medication IG DE bezüglich des defekten Constraints tim-9 beachten!

### Kontakt

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”.