​Technische Use Cases für Medikationsplan lesen (UC_eMed_01)

Dieser technische Use Case beschreibt den lesenden Zugriff berechtigter Akteure auf den Medikationsplan eines ELGA-Teilnehmers.

Für ELGA-Teilnehmer und deren Vertretungen erfolgt der lesende Zugriff über das ELGA-Zugangsportal. Für die übrigen Akteure erfolgt der lesende Zugriff über die e-Medikations-Schnittstelle des jeweiligen GDA-Systems.

Der lesende Zugriff umfasst:

• den Abruf des aktuellen Medikationsplans, der für eine mögliche Bearbeitung aufbereitet ist (Plan-Read),
• ​die Suche und den Abruf historischer Versionen des Medikationsplans (Plan-History-Search),
• ​die Suche und den Abruf einzelner Medikationsplaneinträge bzw. historischer Versionen (Planentry-Search)sowie
• Abruf eines Verzeichnisses historischer Medikationspläne (Plan-History-Directory-Search)

Sub_UC_eMed_01_01 - Aktuellen Medikationsplan lesen (Plan-Read)

Plan-Read dient dem Abruf des aktuellen Medikationsplans in einem für die Bearbeitung durch den GDA aufbereiteten Zustand.

​Hierfür erzeugt die Fachanwendung aus der aktuellen Version der List-Ressource sowie den von ihr referenzierten Ressourcen ein temporäres Medikationsplan-Bundle zur Auslieferung. Der Abruf erfolgt über die Custom Operation $plan-read.

Ablauf

1. ​Der Client führt ein POST $plan-read aus.
2. Die Fachanwendung prüft den Zustand des Medikationsplans und erzeugt ein Medikationsplan-Bundle zur Auslieferung (siehe Prüfung des Planzustands und Erzeugung des Medikationsplan-Bundles).
3. Die Fachanwendung liefert das Medikationsplan-Bundle zurück. Dieses enthält im HTTP-Header den ETag der aktuellen Version der List-Ressource für das Optimistic Locking.

Nachfolgend kann der Medikationsplan vom GDA bearbeitet und mittels Plan-Write gespeichert werden.

Custom Operations

​POST $plan-read

Prüfung des Planzustands und Erzeugung des Medikationsplan-Bundles

Nach Eingang eines $plan-read prüft die Fachanwendung den Zustand des Medikationsplans und führt entsprechende Schritte durch, bevor ein Medikationsplan-Bundles zur Auslieferung erstellt wird (siehe Ablauf).

Die persistierten Ressourcen am Server werden durch die Transformationen für das Auslieferungs-Bundle nicht verändert.

Ablauf

1. Es existiert kein Medikationsplan.
   • Es wird gemäß Sub_UC_eMed_01_03 - Initial erstellter Medikationsplan ein initialer Medikationsplan erstellt (List-Ressource mit List.emptyReason = notstarted).
   • Es erfolgt keine Transformation.
2. Es existiert ein Medikationsplan mit Planeinträgen.
   • Transformationen durchführen (siehe auch Status des List.entry.flags im Medikationsplan):
     • Neue oder geänderte Planeinträge (List.entry.flag = new oder changed) werden auf unchanged gesetzt (siehe Status des List.entry.flags im Medikationsplan).
     • Stornierte und beendete Planeinträge mit List.entry.flag = removed werden aus dem Medikationsplan entfernt.
     • Planeinträge mit abgelaufenem Behandlungszeitraum werden mit List.entry.flag = removed gekennzeichnet und werden mit ausgeliefert, um dem GDA die Möglichkeit zu geben, das Medikament weiterzuverodnen. Anderenfalls nimmt der GDA zur Kenntnis, dass der Planeintrag mit seinem nächsten Schreibvorgang entfernt wird.
   • Sind nach der Transformation keine Planeinträge mehr vorhanden, wird List.emptyReason = nilknown gesetzt.
3. Es existiert ein leerer Medikationsplan (mit einem List.emptyReason).
   • Es erfolgt keine Transformation.
4. Das Medikationsplan-Bundle ist zur Auslieferung bereit. Es enthält:
   • die (ggf. transformierte) List-Ressource,
   • sämtliche von der List referenzierten Ressourcen

Sub_UC_eMed_01_02 - Historische Medikationsplanversion suchen (Plan-History-Search)

Bei der Plan-History-Search rekonstruiert die Fachanwendung historische Versionen des Medikationsplans aus Versionen der List-Ressource sowie den von diesen referenzierten Ressourcenversionen und liefert diese unverändert aus. Alle diese Ressourcen sind Teil des resultierenden Searchset-Bundles.

Beim Plan-History-Search erfolgt keine Änderung der Medikationspläne durch die Fachanwendung. Insbesondere werden keine Inhalte, Statusinformationen oder Kennzeichnungen (Flags) verändert. Der Zugriff dient ausschließlich der Anzeige bzw. Informationsabfrage persistierter Medikationsplanversionen.

Suchparameter

Der Abruf erfolgt mittels GET auf den List-Ressourcen-Endpunkt unter Angabe geeigneter Suchparameter:

• Zeitraum der Erfassung von Medikationsplanversionen
• Medikation (PZN, Arzneimittelname oder Wirkstoff)
• Einnahmezeitraum einer Medikation
• Planeintragsid ohne Version: Abrufen aller Medikationsplanversionen, die diesen Planeintrag enthalten
• Planeintragsid mit Version: Abrufen der Medikationsplanversionen, die genau diese Planeintragsversion enthalten.
• StatusReason eines im Plan einthaltenen Planeintrags: Abrufen aller Planversionen, mit Planeinträgen mit bestimmtem statusReason.

Ablauf

1. Der Client führt ein GET auf [base]/List/_history mit den passenden Suchparametern aus.
2. Die Fachanwendung ermittelt anhand dieser die historischen Versionen der List-Ressource. Für jede gefundene List-Version rekonstruiert die Fachanwendung den historischen Medikationsplan, indem sie die zugehörigen historischen Versionen der referenzierten Ressourcen ermittelt und diese im Medikationsplan-Bundle ergänzt.
3. Die Fachanwendung liefert die den Suchparametern entsprechenden historischen Medikationspläne als Medikationsplan-Bundles in einem Bundle vom Typ searchset zurück.
4. Werden keine passenden historischen Medikationsplanversionen gefunden, enthält das zurückgelieferte searchset keine Einträge.
5. Im Fehlerfall wird ein entsprechender OperationOutcome zurückgegeben.

Beispiele für Suchanfragen

Sub_UC_eMed_01_03 - Initial erstellter Medikationsplan

Die initiale Erstellung eines Medikationsplans erfolgt ausschließlich durch die e-Medikation-Fachanwendung. Sie wird ausgelöst, wenn im Rahmen eines erstmaligen Aufrufs von $plan-read noch kein Medikationsplan für den ELGA-Teilnehmer existiert.

Der dabei erzeugte initiale Medikationsplan besitzt den Wert List.emptyReason = notstarted. Dieser kennzeichnet ausschließlich den Initialzustand des Medikationsplans und bedeutet, dass bisher noch keine Medikationsplaneinträge erfasst wurden. Er trifft jedoch keine Aussage darüber, ob der Patient Medikamente einnimmt.

Die Initialisierung kann sowohl durch ein GDA-System als auch durch den ELGA-Teilnehmer über das Zugangsportal ausgelöst werden.

Ablauf

1. ​Ein Client führt ein POST $plan-read aus.
2. Die Fachanwendung prüft, ob bereits ein Medikationsplan xistiert.
3. Existiert noch kein Medikationsplan, erstellt die Fachanwendung initial eine List-Ressource mit emptyReason = notstarted.
4. Die List-Ressource wird als erste Version persistiert.
5. Für das Plan-Read erzeugt die Fachanwendung daraus ein temporäres Medikationsplan-Bundle zur Auslieferung.
6. Dieses wird mit List.emptyReason = notstarted sowie dem zugehörigen ETag zurückgeliefert.

Sub_UC_eMed_01_04 - Medikationsplaneinträge suchen (Planentry-Search)

Planentry-Search dient der gezielten Suche nach Medikationsplaneinträgen, unabhängig von dereren referenzierenden Medikationsplanversion. Als Medikationsplaneintrag gilt eine in einer Medikationsplanversion referenzierte MedicationRequest-Ressource mit category = "Planeintrag".

Planentry-Search ermöglicht den Zugriff auf aktuelle und historische Versionen von Medikationsplaneinträge und somit die Nachverfolgung von Änderungen an Medikationsplaneinträgen, beispielsweise hinsichtlich Präparat, Dosierung oder Einnahmeanweisung.

Suchparameter

Die Suche nach Medikationsplaneinträgen erfolgt mittels GET unter Angabe geeigneter Suchparameter:

• Medikation (PZN, Arzneimittelname oder Wirkstoff)
• Einnahmezeitraum
• Erstellungszeitpunkt
• Status: Value Set
• StatusReason: Value Set
• Historisch oder aktuell (_history)

Die gefundenen Medikationsplaneinträge können als Ausgangspunkt für weitere Abfragen verwendet werden, um jene Ressourcen zu ermittelnt, die genau auf diese Planeintragsversion referenzieren:

• die zugehörigen Medikationsplanversionen (Plan-History-Search)
• Geplante Abgaben (Prescription-Search)
• Durchgeführte Abgaben (Dispense-Search)

Ablauf

1. Der Client führt ein GET auf den Planentry-Search-Endpunkt mit den gewünschten Suchparametern aus (MedicationRequest mit category = "Planeintrag").
2. Die Fachanwendung ermittelt anhand der Suchparameter die passenden Medikationsplaneinträge.
3. Die Fachanwendung liefert die Suchergebnisse als Bundle vom Typ searchset zurück.
4. Werden keine passenden Medikationsplaneinträge gefunden, enthält das zurückgelieferte Searchset Bundle keine Einträge.
5. Im Fehlerfall wird ein entsprechender OperationOutcome zurückgegeben.

Beispiele für Suchanfragen

Sub_UC_eMed_01_05 - Verzeichnis historischer Medikationspläne lesen (Plan-History-Directory-Search)