Implementation Guide
ePA Medication Service
Version 1.2.0-ballot.2 - draft

## Technische Anwendungsfälle

Die auf dieser Seite dargestellten Inhalte geben den Stand der Version 1.2.0-ballot.1 wieder. Rückmeldungen aus dem laufenden Kommentierungsverfahren sowie daraus resultierende fachliche oder technische Anpassungen sind in dieser Fassung noch nicht oder nur teilweise berücksichtigt.

Der Medication Service hält sämtliche erfasste Medikationsdaten eines Versicherten dauerhaft vor. Schnittstellen und Datenformate basieren auf den Fast Healthcare Interoperability Resources (FHIR) Standard Release R4 (v4.0.1). Die beiden kontextbezogenen Sichten für die Prozessunterstützung des dgMP elektronische Medikationsliste (eML) und elektronischer Medikationsplan (eMP) basieren auf verknüpfte Medikationsdaten im Datenraum des Medication Service. Dieser ist ein FHIR Data Service und damit Teil der Medical Services des ePA-Aktensystems. Er wird in einer vertrauenswürdigen Ausführungsumgebung (VAU) betrieben (vgl. nachstehende Abbildung).

Systemanforderungen an die Implementierung Medication Service innerhalb des ePA-Aktensystems finden sich in der Spezifikation [gemSpec_Aktensystem_ePAfueralle#Medication Service]. Weitere Anforderungen an ePA-Clients wie etwa die Lokalisierung des ePA-Aktensystems, der Aufbau einer sicheren Transportverbindung zum Aktenkonto des Versicherten sind im ePA-Implementierungsleitfaden [gemILF_PS_ePA] sowie [gemSpec_Krypt] einzusehen.

Abbildung: Systemüberblick der Fachanwendung ePA (FMC-Blockdiagramm)

Nachfolgend werden technische Anwendungsfälle des dgMP näher erläutert. Im Medication Service gespeicherte Medikationsdaten werden über die in diesen Anwendungsfällen entstehenden FHIR-Ressourcen verknüpft. In den zugehörigen beschreibenden UML-Diagrammen bedeuten die benannten Kanten die jeweilige Verknüpfung der FHIR-Ressourcen über im FHIR-Standard definierten FHIR-Elemente untereinander. Über die Query API können anhand dieses Modells sämtliche Medikationsdaten vollständig abgefragt werden.

### Grundlagen der eMP-Modellierung

Die Modellierung des elektronischen Medikationsplans basiert auf einem prozessorientierten Ansatz, der sich von einer rein dokumentarischen Sichtweise unterscheidet. Ziel ist es, die Medikationsinformationen nicht als statische Momentaufnahme abzubilden, sondern als Abbild eines Medikationsprozesses, der sich über längere Zeiträume hinweg entwickeln und verändern kann.

#### Die prozessuale Sicht des eMP

In vielen traditionellen Modellen wird der (elektronische) Medikationsplan als eine Art Dokument verstanden, das den aktuellen Stand der verordneten und eingenommenen Medikamente abbildet. Dies führt zu einer statischen Repräsentation (typischerweise einem Dokument), die regelmäßig als vollständige Momentaufnahme neu erstellt werden muss, sobald sich Änderungen ergeben. Der hier gewählte Ansatz verfolgt dagegen den Gedanken eines fortlaufend geführten Medikationsplans, der über längere Zeiträume Bestand hat und dessen Veränderungen nachvollziehbar dokumentiert werden. Anpassungen der Medikation (z.B. Ergänzungen oder das Absetzen von Arzneimitteln) werden direkt im Prozessmodell abgebildet und nicht in einer davon getrennten Dokumentationsschicht festgehalten. Der Plan ist damit nicht als Dokument zu verstehen, sondern als eine Sicht auf einen medizinischen Prozess, der durch Ärzt:innen, Apotheker:innen und weitere an der Versorgung beteiligte Personen beeinflusst wird.

#### MedicationRequest als zentrale Ressource

Die Wahl fiel bewusst auf die FHIR-Ressource MedicationRequest, da sie als Request-Ressource Teil des FHIR-Workflow-Modells ist, eine klare Prozesslogik abbildet und für jede Medikation den Ausgangspunkt eines Therapieprozesses beschreibt. Im Gegensatz zu MedicationStatement, das eine Feststellung über eine Medikation beschreibt (also den Fakt, dass jemand ein Medikament einnimmt oder eingenommen hat), beschreibt MedicationRequest eine Intention, die einen geplanten oder angeordneten medizinischen Vorgang initiiert.

Im Kontext des eMP wird MedicationRequest.intent = plan verwendet, um auszudrücken, dass die Medikation

- als Bestandteil eines längerfristigen Behandlungsplans vorgesehen ist,
- noch nicht zwingend verschrieben wurde (dies geschieht ggf. später durch eine konkrete Verschreibung via E-Rezept),
- den geplanten Medikationsstatus eines Versicherten über einen längeren Zeitraum repräsentiert.

Das bedeutet hierbei nicht, dass jeder MedicationRequest mit intent = plan automatisch zu einer aktiven Verschreibung führt. Vielmehr handelt es sich um den medizinischen Planungsstand, der als Grundlage für zukünftige Verschreibungen oder Änderungen dient. Eine explizite Dokumentation über die Bereitstellung oder Abgabe eines Arzneimittels als Antwort des Service Request erfolgt nicht. Es erfolgt lediglich die Verknüpfung mit einem optionalen Verordnungs- und Abgabegeschehen per E-Rezept.

#### Unterstützung von Langzeitprozessen

Durch diesen Ansatz kann ein MedicationRequest im Kontext des eMP über viele Jahre hinweg Bestand haben und als Referenz für zugehörige Verschreibungs- und Abgabedaten dienen. Die Ressource bildet den Ausgangspunkt für Verschreibungen, Dispensierungen oder Medikationsprotokolle (Nachträge) und kann jederzeit angepasst, erweitert oder beendet werden. Auf diese Weise bildet der eMP nicht nur den aktuellen Stand ab, sondern spiegelt die Entwicklung und Anpassung langfristiger Medikationstherapien wider, die sich über verschiedene Arztkontakte, Fachrichtungen und Versorgungsbereiche hinweg erstrecken.

### Anwendungsfall: Verordnung, Verschreibung und Dispensierung mit dem eMP

Dieser technische Anwendungsfall subsumiert die Schritte Verschreibung und Dispensierung. Zuallererst erfolgt ausgehend von der eMP-basierten Verordnung eines Arzneimittels ein Eintrag im eMP des Medication Service (d.h. Medication-Instanz des Profils EMPMedication und MedicationRequest-Instanz des Profils EMPMedicationRequest). Hierbei werden zusätzlich Dosierungsanweisung, Einnahmezeitraum, die Diagnose (ICD-10-GM) sowie ein möglicher Kommentar angegeben.

Schnittstelle: Operation API: eMP-Eintrag hinzufügen

Anschließend erfolgt die Verschreibung (d.h. Medication-Instanz des Profils EPAMedication und MedicationRequest-Instanz des Profils EPAMedicationRequest) dieses Arzneimittels über das E-Rezept. Hinweis: Eine Folgeverordnung kann aus Nutzersicht analog eMP-basiert erfolgen (z.B. ausgehend vom markierten eMP-Eintrag), bedeutet jedoch primärsystemintern lediglich eine Wiederverschreibung des bereits verknüpften E-Rezepts. Nach der Verschreibung erfolgen die Abgabe des Arzneimittels sowie die Dokumentation der Dispensierung (d.h. MedicationDispense-Instanz des Profils EPAMedicationDispense) im Medication Service.

Automatische Verknüpfungslogik von eML- und eMP-Elementen

Die Verknüpfung eines eMP-Eintrags mit einer Verschreibung erfolgt durch die primärsystemseitige, optionale Übergabe einer Referenz des eMP-Eintrags an das E-Rezept. Der E-Rezept-Fachdienst gibt bei der nachfolgenden Übergabe der Verschreibung an den Medication Service diese optional vorhandene Referenz ebenso mit. Intern erzeugt der Medication Service bei Erhalt der Verschreibung eine Medikationsinformation (d.h. MedicationStatement-Instanz des Profils EPAMedicationStatement) für den entstehenden eML-Eintrag und verknüpft sie über MedicationStatement.derivedFrom. Die Dosierinformation aus der Verschreibung wird in die Medikationsinformation kopiert, da dies die zentrale Stelle für die Aktualisierung und das Auslesen einer strukturierten Dosierinformationen darstellt. Das nun vorhandene eML-Element und das assoziierte eMP-Element werden verbunden (EPAMedicationRequest.activity -> MedicationStatement und MedicationStatement.basedOn -> EPAMedicationRequest). Nach Erhalt der Dispensierinformation wird eine etwaige von der Verschreibung veränderte Dosierungsanweisung ebenso in die Medikationsinformation übernommen. Liegt eine eMP-Verknüpfung vor, wird sie serviceintern ebenso in die eMP-Verordnung (EMPMedicationRequest) übernommen.

Verlaufsinformationen

Sämtliche Veränderungen der Medikationsdaten werden über Änderungseinträge (d.h. Provenance-Instanz des Profils EPAActivityProvenance) erfasst. Die Erzeugung und Aktualisierung von eMP-Einträgen führt zur Fortschreibung eines eMP-Chronologieeintrags (d.h. Provenance-Instanz des Profils EMPChronologyProvenance). Auch hier belegt dies jeweils ein Änderungseintrag.

Am Prozess beteiligte und erfasste Akteure sind:

- Der/die eMP-verordnende Leistungserbringerinstitution (d.h. Organization-Instanz des Profils TIOrganization)
- Der/die verschreibende Leistungserbringer(-in) (d.h. Practitioner-Instanz des Profils PractitionerDirectory) sowie die verschreibende Leistungserbringerinstitution (d.h. Organization-Instanz des Profils OrganizationDirectory) - beide sind über die Rolle PractitionerRole miteinander verbunden
- Die abgebende Apotheke als Leistungserbringerinstitution (d.h. Organization-Instanz des Profils OrganizationDirectory)

Das nachstehende UML-Modell zeigt die entstandenen und verknüpften Daten dieses dgMP-Anwendungsfalls.

Abbildung: Anwendungsfall Verordnung, Verschreibung und Dispensierung mit dem eMP

#### Verschreibung und Dispensierung

Dieser technische Anwendungsfall beschreibt die verknüpften Daten, welche während der Rezeptierung/ Verschreibung eines Arzneimittels sowie Abgabe in der Apotheke und den damit entstehenden Dispensierdatensatz im Medication Service entstehen. Trigger für die Entstehung und Verknüpfung dieser Daten sind die Anwendungsfälle des E-Rezepts [E-Rezept-Anwendungsfälle].

Prozessübergänge bei Übertragung von Verschreibungs- und Dispensierdaten

Bei der Übertragung von Verschreibungs- und Dispensierdaten aus dem E-Rezept-Fachdienst an den Medication Service werden jeweils passende Statuswerte für die beteiligten Ressourcen gesetzt. Diese Statusangaben beschreiben, in welchem fachlichen Zustand sich die einzelnen Ressourcen befinden und ermöglichen eine eindeutige Einordnung der aktuellen Situation im Medikationsprozess. Damit wird nachvollziehbar, welche Schritte im Verschreibungs- und Abgabeprozess bereits erfolgt sind und welche noch ausstehen.

Verschreibungsdaten einstellen

Wenn eine neue Verschreibung an den Medication Service übermittelt wird, erhält die Verschreibung (MedicationRequest) den Status active, was bedeutet, dass sie gültig und für eine Abgabe bereit ist. Das verschriebene Arzneimittel (Medication) wird zunächst mit dem Status inactive geführt, da es noch nicht abgegeben wurde. Die zugehörige Medikationsinformation (MedicationStatement) wird mit dem Status intended gekennzeichnet, da die Einnahme des Arzneimittels geplant, aber noch nicht erfolgt ist.

Dispensierinformationen einstellen

Bei der Übermittlung von Dispensierinformationen wird zunächst die Dispensierung (MedicationDispense) mit dem Status in-progress angelegt. In diesem Zustand kann die Abgabe noch bearbeitet oder korrigiert werden. Erst wenn der Abgabeprozess vollständig abgeschlossen ist und der Dispensierdatensatz den Status completed erhält, wird auch der Status der Verschreibung (MedicationRequest) auf completed gesetzt. Damit wird angezeigt, dass alle mit der Verschreibung verbundenen Maßnahmen abgeschlossen wurden. Das verschriebene Arzneimittel (Medication) wechselt in den Status active, wodurch deutlich wird, dass es dem Patienten zur Verfügung steht. Die Medikationsinformation (MedicationStatement) erhält den Status unknown, da keine Informationen über die tatsächliche Einnahme durch den Patienten vorliegen. Basierend auf dem Ablauf des Prozesses wird jedoch angenommen, dass das Medikament eingenommen wird.

Verschreibungsdaten stornieren

Wird eine Verschreibung storniert, erhalten alle beteiligten Ressourceninstanzen den Status entered-in-error. Damit wird kenntlich gemacht, dass die Verschreibung sowie die damit verbundenen Arzneimittel- und Medikationsinformationen fehlerhaft oder ungültig sind. Das gilt auch dann, wenn bereits einzelne Maßnahmen durchgeführt wurden.

Dispensierung stornieren

Wenn eine Dispensierinformation storniert wird, wird die ursprüngliche Verschreibung wieder auf active gesetzt, sodass sie weiterhin für eine neue Abgabe genutzt werden kann. Die betroffene Dispensierung (MedicationDispense) erhält den Status entered-in-error, um die Stornierung zu dokumentieren. Das Arzneimittel (Medication) wird wieder als inactive geführt, da es dem Patienten nach der Stornierung der Abgabe nicht mehr zur Verfügung steht. Der Status der Medikationsinformation (MedicationStatement) wechselt zurück auf den Wert intended, da die Einnahme weiterhin geplant, aber noch nicht umgesetzt ist.

Abbildung: Statusübergänge bei Verschreibung und Dispensierung

Interne Abläufe zur Verknüpfung der Medikationsdaten

Wie weiter oben beschrieben werden Daten der Verschreibung (EPAMedicationRequest) und Abgabe (EPAMedicationDispense) in einem durchgängigen Prozess miteinander verknüpft. Die folgenden Aktionen werden bei Empfang der Verschreibung durchgeführt:

- Speichern der Verschreibung (EPAMedicationRequest)
- Setzen der logischen Referenz in MedicationRequest.subject auf Instanz des Profils EPAPatient
- Erzeugen einer MedicationStatement-Instanz des Profils EPAMedicationStatement
- Setzen der logischen Referenz in MedicationStatement.subject auf Instanz des Profils EPAPatient
- Setzen der Referenz in MedicationStatement.derivedFrom auf MedicationRequest-Instanz
- Setzen der Referenz in MedicationStatement.medicationReference auf Medication-Instanz
- Setzen von MedicationStatement.dateAsserted mit dem Wert aus MedicationRequest.authoredOn
- Setzen von MedicationStatement.dosage mit dem Wert aus MedicationRequest.dosageInstruction
- Setzen von MedicationStatement.status mit dem Wert intended
- Setzen von MedicationStatement.effective[x].start mit dem Wert aus MedicationRequest.authoredOn
- Erzeugen einer Provenance-Instanz des Profils EPAActivityProvenance mit Referenz Provenance.target auf MedicationStatement
- Setzen von Provenance.activity mit dem Wert CREATE
- Falls eine eMP-Verknüpfung vorliegt:
  - Setzen der Referenz in EMPMedicationRequest.activity mit der MedicationStatement-Instanz des Profils EPAMedicationStatement
  - Setzen der Referenz in MedicationStatement.basedOn mit der MedicationRequest-Instanz des Profils EMPMedicationRequest

Das nachstehende UML-Sequenzdiagramm verdeutlicht die Ausstellung des E-Rezepts durch ein verordnendes Praxisverwaltungssystem (PVS) oder Krankenhausinformationssystem (KIS) mit anschließender Übertragung in den Medication Service.

Abbildung: Anwendungsfall Verschreibungsdaten einstellen

Schnittstelle: Operation API: Verschreibungsdaten einstellen

Die folgenden Aktionen werden bei Empfang der Dispensierinformationen durchgeführt:

- Speichern der Dispensierung (MedicationDispense)
- Setzen der logischen Referenz in MedicationDispense.subject auf Instanz des Profils EPAPatient
- Setzen der Referenz in MedicationDispense.authorizingPrescription auf MedicationRequest-Instanz
- Setzen der Referenz in MedicationStatement.derivedFrom auf MedicationDispense-Instanz (das MedicationStatement ist über die verknüpfte MedicationRequest-Instanz identifizierbar)
- Falls MedicationDispense.dosageInstruction gesetzt, Setzen von MedicationStatement.dosage mit dem Wert aus MedicationDispense.dosageInstruction
- Falls MedicationDispense.dosageInstruction gesetzt sowie eine eMP-Verknüpfung vorliegt:
  - Setzen von EMPMedicationRequest.dosageInstruction mit dem Wert aus EPAMedicationDispense.dosageInstruction
  - Aktualisieren der neuen Version EMPMedicationRequest in EMPChronologyProvenance
  - Erzeugen einer Instanz von EPAActivityProvenance für das systeminterne Aktualisieren des EMPMedicationRequest und Setzen von EPAActivityProvenance.activity mit dem Wert UPDATE

Das nachstehende UML-Sequenzdiagramm verdeutlicht den Übertrag von Dispensierinformationen des E-Rezepts durch eine abgebende Apotheke über ein Apothekenverwaltungssystem (AVS) mit anschließender Übertragung in den Medication Service.

Abbildung: Anwendungsfall Dispensierinformationen einstellen

Schnittstelle: Operation API: Dispensierinformationen einstellen

##### Substitution eines Arzneimittels bei Abgabe

Im Fall einer Substitution wird das ursprünglich verschriebene Arzneimittel bei der Abgabe in der Apotheke durch ein oder mehrere Arzneimittel ersetzt. Aufbauend auf das zuvor gezeigte Informationsmodell wird diese Änderung wie folgt abgebildet:

Abbildung: Anwendungsfall Substitution eines Arzneimittels

Substitution im Modell

Die folgenden Änderungen entstehen beim Verschreibungs- und Abgabedatensatz im Falle der Substitution:

- Die Verschreibung (d.h. MedicationRequest) bleibt unverändert und verweist weiterhin auf das ursprünglich verschriebene Arzneimittel (medicationReference).
- Bei der Abgabe (d.h. MedicationDispense) wird das substituierte Arzneimittel angegeben. Dieses ersetzt das ursprünglich verschriebene Arzneimittel.
- Zusätzlich gibt es ein Attribut substitution.wasSubstituted, das auf true gesetzt wird, um festzuhalten, dass eine Substitution stattgefunden hat.
- Die Verbindung zur ursprünglichen Verschreibung bleibt über das Feld authorizingPrescription bestehen.
- Die Apotheke (d.h. Organization-Instanz des Profils OrganizationDirectory), die die Abgabe durchgeführt hat, wird über performer.actor dokumentiert.
- Ersetzen der Referenz in MedicationStatement.medicationReference auf das substituierte Arzneimittel

Insgesamt ergibt sich:

- Verschreibung: Die Ressource MedicationRequest enthält die Details zum Arzneimittel, das verschrieben wurde, sowie Informationen zur verschreibenden Person (PractitionerDirectory-Profil) und Organisation (OrganizationDirectory-Profil).
- Abgabe mit Substitution: Wenn ein anderes Arzneimittel abgegeben wird, beschreibt MedicationDispense das substituierte Arzneimittel. Die ursprüngliche Verschreibung wird über authorizingPrescription referenziert. Das Feld wasSubstituted zeigt an, dass es sich nicht um das ursprünglich verschriebene Arzneimittel handelt.

##### Stornieren einer Verschreibung oder Dispensierung

Dem Anwendungsfall “Stornieren einer Verschreibung” geht das Löschen einer Verschreibung bzw. des E-Rezepts im E-Rezept-Fachdienst voraus. Das nachstehende UML-Modell zeigt das Aktualisieren der Medikationsdaten innerhalb dieses dgMP-Anwendungsfalls.

Abbildung: Anwendungsfall Verschreibung stornieren

Die folgenden Änderungen entstehen im Falle der Stornierung einer Verschreibung:

- Identifizieren des eML-Eintrags bzw. der Verschreibung mittels E-Rezept-ID (d.h. RxPrescriptionProcessIdentifier-Extension)
- Setzen von MedicationRequest.status mit dem Wert cancelled
- Setzen von MedicationStatement.status mit dem Wert entered-in-error
- Erzeugen einer Provenance-Instanz des Profils EPAActivityProvenance für das systeminterne Aktualisieren der MedicationStatement-Instanz des Profils EPAMedicationStatement und Setzen von Provenance.activity mit dem Wert UPDATE

Dem Anwendungsfall “Stornieren einer Dispensierung” geht das Löschen einer Dispensierung im E-Rezept-Fachdienst voraus. Das nachstehende UML-Modell zeigt das Aktualisieren der Medikationsdaten innerhalb dieses dgMP-Anwendungsfalls.

Abbildung: Anwendungsfall Dispensierung stornieren

Schnittstelle: Operation API: Verschreibungsdaten stornieren</i>

Die folgenden Änderungen entstehen im Falle der Stornierung einer Dispensierinformation:

- Identifizieren des eML-Eintrags bzw. der Dispensierinformation mittels E-Rezept-ID (d.h. RxPrescriptionProcessIdentifier-Extension)
- Setzen von MedicationDispense.status mit dem Wert cancelled
- Setzen von MedicationRequest.status mit dem Wert active
- Setzen von MedicationStatement.status mit dem Wert entered-in-error
- Erzeugen einer Provenance-Instanz des Profils EPAActivityProvenance für das systeminterne Aktualisieren der MedicationStatement-Instanz des Profils EPAMedicationStatement und Setzen von Provenance.activity mit dem Wert UPDATE

Schnittstelle: Operation API: Dispensierinformationen stornieren

### Anwendungsfall: Nachtrag in der eML

Bei diesen Anwendungsfall werden bei manuellem Hinzufügen eines eingenommen Arzneimittels mitsamt Dosierung und optionalen Einnahmezeitraum als Medikationsinformation ein eML-Eintrag mit dem Status “unbekannt” im Medication Service registriert. Das nachstehende UML-Modell zeigt das Aktualisieren der Medikationsdaten innerhalb dieses dgMP-Anwendungsfalls.

Abbildung: Anwendungsfall Nachtrag in der eML

Die folgenden Änderungen entstehen im Falle der Registrierung eines Nachtrags:

- Speichern des Arzneimittels (d.h. Medication-Instanz des Profils EPAMedication)
- Speichern der Medikationsinformation (d.h. MedicationStatement-Instanz des Profils EPAMedicationStatement)
- Setzen der logischen Referenz in MedicationStatement.subject auf Instanz des Profils EPAPatient
- Setzen von MedicationStatement.status mit dem Wert unknown
- Erzeugen einer Provenance-Instanz des Profils EPAActivityProvenance für das systeminterne Anlegen der MedicationStatement-Instanz des Profils EPAMedicationStatement und Setzen von Provenance.activity mit dem Wert CREATE

Schnittstelle: Operation API: eML-Eintrag hinzufügen

### Anwendungsfall: Stornierung eines eML-Eintrags

Dieser Anwendungsfall berücksichtigt die Art des zu stornierenden eML-Eintrags. Eine Stornierung ist ausschließlich für manuell hinzugefügte eML-Nachträge zulässig. In diesem Fall wird die entsprechende MedicationStatement-Instanz sowie die zugehörige Medication-Instanz auf den Status “inkorrekt” (entered-in-error) gesetzt und durch eine Provenance-Instanz dokumentiert. eML-Einträge aus dem Verschreibungs- oder Abgabeprozess können mit dieser Operation nicht storniert werden.

Schnittstelle: Operation API: eML-Eintrag stornieren

### Anwendungsfall: Nachtrag im eMP

Dieser technische Anwendungsfall orchestriert die bestehenden Anwendungsfälle Nachtrag in der eML, Nachtrag im eMP sowie das Hinzufügen einer eML-eMP-Verknüpfung. Erklärtes Ziel ist, dass Nachträge im eMP auch in der eML sichtbar und eine Beziehung zueinander erkennbar sein sollen. Nach der Registrierung eines eML-Eintrags (siehe oben) werden vom Primärsystem ein planungsmäßiges Arzneimittel (d.h. Medication-Instanz des Profils EMPMedication) zusammen mit der Medikationsinformation (d.h. Einnahmezeitraum, Dosierung, Status, Indikation sowie Kommentar) an den Medication Service zur Registrierung übergeben. Anschließend kann mit Kenntnis von eML-Eintrags-ID und eMP-Eintrags-ID eine Verknüpfung erfolgen. Das nachstehende UML-Modell zeigt das Aktualisieren der Medikationsdaten innerhalb dieses dgMP-Anwendungsfalls nach Abschluss der besagten Verknüpfung.

Abbildung: Anwendungsfall Nachtrag im eMP

Die folgenden Änderungen entstehen im Falle der Registrierung eines Nachtrags:

- Speichern des Arzneimittels (d.h. Medication-Instanz des Profils EMPMedication)
- Speichern der Medikationsinformation / eMP-Verordnung (d.h. MedicationRequest-Instanz des Profils EMPMedicationRequest)
- Setzen der logischen Referenz in MedicationRequest.subject auf Instanz des Profils EPAPatient
- Erzeugen einer Provenance-Instanz des Profils EPAActivityProvenance für das systeminterne Anlegen der MedicationRequest-Instanz des Profils EMPMedicationRequest und Setzen von Provenance.activity mit dem Wert CREATE

Schnittstelle: Operation API: eMP-Eintrag hinzufügen

### Anwendungsfall: Aktualisierung eines eMP-Eintrags

Um Einnahmezeitraum, Dosierung, Status, Indikation oder Kommentar anzupassen, wird dieser Anwendungsfall ausgeführt. Das Statusmodell eines eMP-Eintrags mit den Werten “aktiv” (active), “beendet” (completed), “inkorrekt” (entered-in-error), “abgebrochen” (stopped) sowie “pausiert” (on-hold) erlaubt es, den kompletten Lebenszyklus des eMP-Eintrags durch eine Aktualisierung zu verwalten. Der Medication Service erhält vom Primärsystem die Medikationsinformation mit den aktuellen Daten.

Die folgenden Änderungen entstehen im Falle der Registrierung eines Nachtrags:

- Speichern der neuen Version zur Medikationsinformation / eMP-Verordnung (d.h. MedicationRequest-Instanz des Profils EMPMedicationRequest)
- Aktualisieren der neuen Version EMPMedicationRequest in EMPChronologyProvenance
- Falls eine eMP-Verknüpfung sowie Dosierungsänderung vorliegt:
  - Identifizierung der letzten eML-Verknüpfung
  - Setzen von EPAMedicationStatement.dosage mit dem Wert aus EMPMedicationRequest.dosageInstruction
  - Erzeugen einer Provenance-Instanz des Profils EPAActivityProvenance für die systeminterne Aktualisierung der MedicationStatement-Instanz des Profils EPAMedicationStatement und Setzen von Provenance.activity mit dem Wert UPDATE
- Erzeugen einer Provenance-Instanz des Profils EPAActivityProvenance für die systeminterne Aktualisierung der MedicationRequest-Instanz des Profils EMPMedicationRequest und Setzen von Provenance.activity mit dem Wert UPDATE

Schnittstelle: Operation API: eMP-Eintrag aktualisieren

### Anwendungsfall: Hinzufügen und Entfernen einer eML-eMP-Verknüpfung

Im Regelfall sollte die Verknüpfung in der oben beschriebenen Verknüpfungslogik automatisiert durch die primärsystemseitige Übergabe der Referenz eines eMP-Eintrags an das E-Rezept erfolgen. Soll dies jedoch nachträglich manuell durch den Nutzer - z.B. nach Registrierung von Nachträgen in eML und eMP - erfolgen, kann durch Übermittlung beider Eintrags-IDs eine Verknüpfung hergestellt werden.

Die folgenden Änderungen entstehen im Falle des Hinzufügens einer eML-eMP-Verknüpfung:

- Setzen der Verknüpfung in MedicationRequest.activity des Profils EMPMedicationRequest auf das zugehörige EPAMedicationStatement
- Setzen der inversen Verknüpfung in MedicationStatement.basedOn des Profils EPAMedicationStatement auf den EMPMedicationRequest
- Aktualisieren der neuen Version EMPMedicationRequest in EMPChronologyProvenance

Das Entfernen einer Verknüpfung ist nur bei eMP-Einträgen möglich, welche nicht im Status “inkorrekt” (entered-in-error) vorliegen. Ist dem so, erfolgen die Änderungen analog zum Hinzufügen einer eML-eMP-Verknüpfung jedoch mit einer entfernten Verknüpfung in MedicationRequest.activity der neuen Version der Instanz des Profils EMPMedicationRequest. Zur Identifizierung der Verknüpfung ist lediglich die Übergabe der eMP-Eintrags-ID erforderlich.

Schnittstellen:

- Operation API: Hinzufügen einer eML-eMP-Verknüpfung
- Operation API: Entfernen einer eML-eMP-Verknüpfung

### Lesezugriffe

Neben der Nutzung der Query API für den gezielten Abruf einzelner Medikationsdaten bietet der Medication Service standardisierte Abrufmöglichkeiten für die kontextbezogenen Sichten eML und eMP.

Abruf der eML

Über die eML kann durch optionale Eingabe eines Datumsbereichs eine verlaufsbasierte Einsicht auf Medikationsdaten vorgenommen werden. Basis für die eML sind primär Arzneimittelverordnungsdaten (oder Verschreibungsdaten) sowie Dispensierinformationen, welche ein Apothekenverwaltungssystem (AVS) dem E-Rezept-Fachdienst zur Verfügung stellt. Weiterhin werden Nachträge zu aktuellen Einnahmen von Arzneimitteln aus der eML berücksichtigt. Stornierte Daten werden ignoriert.

Die genannten Medikationsdaten der eML werden über eine Operation vom Medication Service zusammengestellt und als FHIR searchSet-Bundle zurückgegeben. Zusätzlich wird die zugehörige Versicherteninformation (Patient-Instanz) aus dem Patient Service beigefügt.

Schnittstelle: Operation API: Medikationsliste abrufen (eML)

Abruf des eMP

Diese Operation ermöglicht den gezielten Abruf des eMP. Er besteht aus einer Sammlung relevanter Ressourceninstanzen, die zu einem bestimmten Zeitpunkt gemeinsam gültig waren, sowie die zugehörige Versicherteninformation (Patient-Instanz) aus dem Patient Service. Der Zeitpunkt wird über einen eMP-Chronologieeintrag festgehalten, welcher als FHIR Provenance umgesetzt ist. Optional kann durch eine Provenance-Referenz.id der Abruf des eMP somit zeitgesteuert erfolgen. Ohne Provenance-Indikator, gibt die Operation den aktuellsten Stand des Medikationsplans zurück - also die derzeit gültige Kombination aus aktiven, vorgesehenen und pausierten Medikationsdaten. Das Ergebnis ist ein Bundle vom Typ collection, das alle zugehörigen Ressourcendaten enthält.

Schnittstelle: Operation API: Medikationsplan abrufen (eMP)

Abruf von eMP-Chronologieeinträgen

Jede Änderung am eMP wird über einen eMP-Chronologieeintrag festgehalten, welcher eine versionierte Referenz zum eMP-Eintrag speichert. Über die entsprechende Operation (oder der Query API) kann gezielt nach Provenance-Instanzen über bestimmte Zeiträume gesucht werden. Mit einer gegebenen Provenance-Instanz kann anschließend gezielt ein eMP-Abruf erfolgen.

Schnittstelle: Operation API: eMP-Chronologie abrufen