Transaktionen

Im Folgenden werden standardisierte Interaktionen für den lesenden und schreibenden Zugriff auf die e-Medikation eines Patienten bzw. einer Patientin erläutert, die für alle technischen Use Cases relevant sind.

Medikationsplan

Plan-History-Read

Beim Plan-History-Read stellt die Fachanwendung die aktuelle oder historische Version(en) des Medikationsplans (persistiertes Medikationsplan-Collection-Bundle inkl. aller referenzierten Ressourcen) unverändert bereit.

Ablauf

1. Der GDA führt ein GET auf das persistierte Medikationsplan-Collection-Bundle aus, das den Medikationsplan mit allen zugehörigen relevanten Ressourcen enthält.
2. Die Fachanwendung prüft, ob ein Medikationsplan für den/die Patient:in existiert.
3. Ist kein Medikationsplan vorhanden, wird ein leeres Ergebnis zurückgegeben.
4. Ist ein Medikationsplan vorhanden, wird das zuletzt persistierte Medikationsplan-Collection-Bundle zurückgeliefert.
   Das Collection Bundle enthält:
   
   • die List-Ressource des Medikationsplans
     
   • alle referenzierten Ressourcen (z. B. MedicationRequest, Patient, Practitioner) vollständig (inline)

Beim Plan-History-Read erfolgt keine Veränderung von Flags, Status oder Inhalten durch die Fachanwendung.
Der Zugriff dient ausschließlich der Anzeige bzw. Informationsabfrage von aktuellen bzw. historischen Planversionen.

Sequenzdiagramm Plan-History-Read

Beispiele für Zugriffe mittels Suchparameter:

• 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 gespeichert wurden und Plan-Einträge enthalten, die als storniert, beendet oder abgesetzt gekennzeichnet sind: GET [base]/Bundle?type=collection&_sort=-timestamp&timestamp=ge2025-01-01&list.subject={bPK-GH}&list.entry.flag=removed

Plan-Read

Plan-Read dient dem Abruf des Medikationsplans und der Vorbereitung einer nachfolgenden Änderung.

Ablauf

1. ​Der GDA führt ein POST $plan-read auf das Collection Bundle aus, das den Medikationsplan mit allen zugehörigen relevanten Ressourcen enthält.
2. Die Fachanwendung prüft, ob ein Medikationsplan für den/die Patient:in existiert.
3. ​Ist kein Medikationsplan vorhanden, wird dieser erstellt (siehe Sub_UC_06_01 - Initial erstellter Medikationsplan) und
4. ein leerer Medikationsplan mit dem emptyReason notstarted wird zurückgeliefert.
5. Existiert bereits ein Medikationsplan (d.h. es wurde bereits ein Medikationsplan-Collection-Bundle persistiert), wird von der Fachanwendung aus diesem ein Collection Bundle zur Auslieferung bereitgestellt. Die Inhalte werden von der Fachanwendung wie folgt aufbereitet:
   
   • Falls der vorherige GDA neue Medikationsplaneinträge hinzugefügt oder bestehende geändert hat (List.entry.flag haben den Wert new oder changed), werden diese auf unchanged gesetzt.
     
   • Falls der vorherige GDA Medikationsplaneinträge beendet hat (deren List.entry.flag haben den Wert removed), werden diese Einträge aus der Liste entfernt.
     
   • Falls der vorherige GDA alle vorhandenen Einträge mit removed gekennzeichnet hat, wird List.emptyReason mit nilknown zurückgeliefert, um nachfolgenden GDA zu signalisieren, dass der Patient zum Zeitpunkt des letzten Schreibens keine Medikamente eingenommen hat bzw. einnehmen sollte.
     
   • Einträge mit abgelaufenem Behandlungszeitraum bleiben erhalten.
     
6. Die Fachanwendung liefert das Auslieferungs-Medikationsplan-Collection-Bundle an den GDA:
   
   • inkl. ETag für Optimistic Locking
   • inkl. List und aller referenzierten Ressourcen (inline)
     
   • Ziel ist ein neutraler, weiterbearbeitbarer Zustand für den abrufenden GDA
     
7. Der GDA bearbeitet den Medikationsplan (er fügt Einträge hinzu, ändert bestehende oder entfernt diese).

Custom Operations

​$plan-read

Sequenzdiagramm Plan-Read

Plan-Write

Plan-Write ist eine eigenständige Operation, die ausschließlich im Kontext eines zuvor ausgeführten Plan-Read erfolgen darf.

Ablauf

1. ​Der GDA übermittelt via POST $plan-write den aktualisierten Medikationsplan als Medikationsplan-Transaction-Bundle inkl. ETag für Optimistic Locking:
   • alle neuen und geänderten und zu entfernenden Ressourcen sind inline im Bundle enthalten,
   • alle unveränderten Ressourcen werden nur referenziert.
2. Die Fachanwendung prüft, ob der im Header übermittelte ETag mit dem ETag der Fachanwendung übereinstimmt (d.h. es wurde zwischenzeitlich kein Medikationsplan gespeichert).
3. Stimmt der ETag nicht überein, lehnt die Fachanwendung das Speichern des Medikationsplans ab. Es muss erneut ein Plan-Read ausgeführt werden und die Aktualisierungen übernommen werden bzw. Fehler behoben werden, bevor ein neuerlicher Speicherversuch vorgenommen werden kann.
4. Wenn kein Fehler auftritt, validiert die Fachanwendung den neuen Plan und stellt sicher, dass keine unzulässigen Zustandsübergänge vorgenommen wurden.
5. Bei erfolgreicher Prüfung:
   • werden die übermittelten Änderungen in die Ressourcen übernommen.
   • Auf Basis der aktualisierten Ressourcen erstellt die Fachanwendung ein neues Medikationsplan-Collection-Bundle, das als neuer Medikationsplan persistiert wird.
6. Der GDA erhält eine Meldung, dass der Medikationsplan erfolgreich aktualisiert wurde.

Custom Operations

​$plan-write

Sequenzdiagramm Plan-Write

Diagramm Plan-Read- und Write-Logik

Abgelehntes Plan-Write

Ablauf

1. ​GDA 1 möchte den Medikationsplan seiner Patientin bearbeiten und führt ein POST $plan-read auf das Collection Bundle des Medikationsplans aus.
2. Die Fachanwendung erstellt ein Auslieferungs-Medikationsplan-Collection-Bundle (siehe Plan-Read) inkl. ETag "123" und liefert es an den GDA 1. GDA 1 bearbeitet den Medikationsplan.
3. ​GDA 2 führt ein POST $plan-read auf den Medikationsplan aus, während GDA 1 das von der Fachanwendung übermittelte Collection Bundle bearbeitet.
4. Die Fachanwendung erstellt ein Auslieferungs-Medikationsplan-Collection-Bundle (siehe Plan-Read) inkl. ETag "123" und liefert es an den GDA 2. GDA 2 bearbeitet zeitgleich mit GDA 1 den Medikationsplan.
5. ​GDA 2 sendet zuerst mittels POST $plan-write ein Medikationsplan-Transaction-Bundle mit dem aktualisierten Medikationsplan und übermittelt den ETag "123".
6. Die Fachanwendung prüft, ob der im Header übermittelte ETag mit dem ETag der Fachanwendung übereinstimmt. Beide haben den Wert "123", der neue Medikationsplan wird persistiert.
7. GDA 2 erhält eine Meldung, dass der Medikationsplan erfolgreich aktualisiert wurde.
8. ​GDA 1 sendet mittels POST $plan-write ein Medikationsplan-Transaction-Bundle mit dem aktualisierten Medikationsplan und übermittelt den ETag "123".
9. Die Prüfung auf Übereinstimmung der ETags von GDA 1 mit dem der Fachanwendung schlägt fehl, da dieser ETag bereits zum Schreiben verwendet wurde. Die Fachanwendung lehnt das Speichern ab.
10. GDA 1 erhält eine Fehlermeldung und muss ein erneutes Plan-Read ausführen, welches das Generieren eines neuen Auslieferungs-Medikationsplan-Collection-Bundle auslöst und mit dem aktuellen ETag übermittelt wird.

Sequenzdiagramm Abgelehntes Plan-Write

Groupidentifier-Create

siehe "Ablauf - Bezug e-Med GroupIdentifier".

Prescription-Search

In Arbeit.