Seiteninhalt:
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.
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.
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.
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.
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
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.
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.
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. Der Status dieses eMP-Eintrags hat zunächst den Wert “geplant” (draft).
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 -> EMPMedicationRequest). 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. Gleichfalls bei vorliegender eMP-Verknüpfung wird der Status des eMP-Eintrags von “geplant” (draft) in “aktiv” (active) aktualisiert.
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:
Das nachstehende UML-Modell zeigt die entstandenen und verknüpften Daten dieses dgMP-Anwendungsfalls.
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.
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:
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.
Schnittstelle: Operation API: Verschreibungsdaten einstellen
Die folgenden Aktionen werden bei Empfang der Dispensierinformationen durchgeführt:
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.
Schnittstelle:Operation API: Dispensierinformationen einstellen
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:
Substitution im Modell
Die folgenden Änderungen entstehen beim Verschreibungs- und Abgabedatensatz im Falle der Substitution:
Insgesamt ergibt sich:
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.
Die folgenden Änderungen entstehen im Falle der Stornierung einer Verschreibung:
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.
Schnittstelle: Operation API: Verschreibungsdaten stornieren</i>
Die folgenden Änderungen entstehen im Falle der Stornierung einer Dispensierinformation:
Schnittstelle: Operation API: Dispensierinformationen stornieren
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.
Die folgenden Änderungen entstehen im Falle der Registrierung eines Nachtrags:
Schnittstelle: Operation API: eML-Eintrag hinzufügen
Dieser Anwendungsfall berücksichtigt die Art des zu aktualisierenden eML-Eintrags. Handelt es sich um einen eML-Eintrag aus dem Verschreibungs- und Abgabeprozess (d.h. keine Belegung in MedicationStatement.derivedFrom), ist ausschließlich die Dosierung in der Medikationsinformation änderbar. Im Falle eines manuell hinzugefügten eML-Eintrags können der Status auf “inkorrekt” (entered-in-error) gesetzt, oder die Dosierung und Einnahmezeitraum geändert werden.
Die folgenden Änderungen entstehen im Falle der Registrierung eines Nachtrags:
Schnittstelle: Operation API: eML-Eintrag aktualisieren
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.
Die folgenden Änderungen entstehen im Falle der Registrierung eines Nachtrags:
Schnittstelle: Operation API: eMP-Eintrag hinzufügen
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), “geplant” (draft), “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:
Schnittstelle: Operation API: eMP-Eintrag aktualisieren
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:
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:
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