Technische Use Cases für Medikationsplan lesen (UC_eMed_05)
ELGA e-Medikation (R4) DRAFT - Local Development build (v0.1.1) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Technische Use Cases für Medikationsplan lesen (UC_eMed_05)
Ein berechtigter GDA kann den Medikationsplan eines ELGA-Teilnehmers lesen.
Ein ELGA-Teilnehmer kann seinen Medikationsplan über das Zugangsportal einsehen.
Für den lesenden Zugriff werden zwei Zugriffsarten unterschieden:
Plan-Read zum Abruf des aktuellen Medikationsplans. Hierfür wird aus dem persistierten Medikationsplan ein temporäres Auslieferungs-Medikationsplan-Collection-Bundle erzeugt, das für eine mögliche Bearbeitung aufbereitet ist. Der Abruf erfolgt mit der Custom Operation $plan-read.
Plan-History-Read zum Abruf historischer, unveränderlicher Versionen eines persistierten Medikationsplans.
Plan-Read dient dem Abruf des Medikationsplans in einem für die Bearbeitung durch den GDA aufbereiteten Zustand.
Hierfür erzeugt die Fachanwendung aus dem zuletzt persistierten Medikationsplan ein Auslieferungs-Medikationsplan-Collection-Bundle. Der Abruf erfolgt über die Custom Operation $plan-read.
Die Fachanwendung prüft, ob bereits ein Medikationsplan für den Patienten existiert.
Existiert dieser (persistiertes Medikationsplan-Collection-Bundle) und ist nicht leer (nicht mit einem emptyReason gekennzeichnet), wird daraus ein Auslieferungs-Medikationsplan-Collection-Bundle erzeugt. Dabei werden folgende Transformationen durchgeführt:
List.entry.flag = new und changed werden auf unchanged gesetzt.
Einträge mit List.entry.flag = removed werden aus der List.entry und aus dem Bundle entfernt.
Einträge mit abgelaufenem Behandlungszeitraum bleiben erhalten.
Das persistierte Medikationsplan-Collection-Bundle bleibt unverändert.
Die Fachanwendung prüft, ob nach dem Entfernen aller mit removed gekennzeichneten Listeneinträge noch Planeinträge vorhanden sind.
im HTTP-Header den ETag der zugrunde liegenden persistierten Version für Optimistic Locking
die List-Ressource
sämtliche in der List-Ressource referenzierten Ressourcen
Wurden sämtliche Einträge entfernt, wird List.emptyReason = nilknown gesetzt und dasAuslieferungs-Medikationsplan-Collection-Bundle mit einer leeren Liste List.emptyReason = nilknown zurückgeliefert.
Existieren ein oder mehrere Medikationsplan-Collection-Bundles, werden diese als Bundle (type=searchset) zurückgeliefert.
Jedes Medikationsplan-Collection-Bundle enthält:
die List-Ressource des Medikationsplans
alle referenzierten Ressourcen vollständig (inline).
Existiert kein Medikationsplan-Collection-Bundle, wird ein leeres Bundle (type=searchset) zurückgegeben.
Im Fehlerfall erfolgt eine entsprechende Meldung an den Client.
Beim Plan-History-Read 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.
Custom Operations
$plan-history-read: in Arbeit.
Sequenzdiagramm
Beispiele für Zugriffe
In Arbeit
<!–TODO: wenn plan-history-read eine Operation bleibt stimmt dieser Teil nicht mehr -> dann würden Operation IN Parameter zum Einsatz kommen
Aktuelle Planversion mit dem Suchparameter Patient abrufen: GET [base]/Bundle?type=collection&_count=1&_sort=-timestamp&list.subject={bPK-GH}
Alle Planversionen mit dem Suchparameter Patient abrufen: GET [base]/Bundle?type=collection&_sort=-timestamp&list.subject={bPK-GH}
Abfrage aller historischen Medikationsplan-Versionen eines Patienten, die nach dem angegebenen Datum persistiert wurden und Plan-Einträge enthalten, die als storniert, beendet oder abgesetzt gekennzeichnet sind: GET [base]/Bundle?type=collection&_sort=-timestamp×tamp=ge2025-01-01&list.subject={bPK-GH}&list.entry.flag=removed
–>
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. Er bedeutet, dass bisher noch keine Medikationsplaneinträge erfasst wurden, 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 Portal ausgelöst werden, indem erstmals ein $plan-read aufgerufen wird.
Ablauf
Ein Client führt für einen ELGA-Teilnehmer erstmalig ein POST$plan-read aus.
Die Fachanwendung prüft, ob bereits ein Medikationsplan für den Patienten existiert.
Existiert noch kein persistierter Medikationsplan, erstellt die Fachanwendung ein persistiertes Medikationsplan-Collection-Bundle mit:
einer List Ressource, welche den Wert emptyReason = notstarted besitzt und keine List.entry Einträge enthält
einer Patient Ressource
Das erzeugte Medikationsplan-Collection-Bundle wird als initialer Medikationsplan persistiert.
Für das Plan-Read erzeugt die Fachanwendung daraus ein Auslieferungs-Medikationsplan-Collection-Bundle.
Dieses wird mit demselben List.emptyReason = notstarted sowie dem zugehörigen ETag an den Client zurückgeliefert.
Sequenzdiagramm
Relevante Elemente (List)
AtElgaEmedListMedikationsplan
identifier: von der Fachanwendung übermittelt (Integritätsprüfung)
status: current
mode: working
date: Datum der Erstellung durch die Fachanwendung
source: Intitiale Erstellung durch die Fachanwendung
emptyReason: notstarted // noch keine Medikationsplaneinträge erfasst
