ELGA e-Medikation (R4) DRAFT
0.1.1 - ci-build

Zugriffsarten auf den Medikationsplan

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

Read-only-Zugriff

Beim Read-only-Zugriff stellt die Fachanwendung die aktuelle oder historische Versionen des Medikationsplans (persistierte Collection Bundles inkl. aller referenzierten Ressourcen) unverändert bereit.

Ablauf

  1. Der GDA führt ein GET 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 ein leeres Ergebnis zurückgegeben.
  4. Ist ein Medikationsplan vorhanden, wird das zuletzt gespeicherte 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 Read-only-Zugriff 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 Read-only-Zugriff


 GDA 1 e-Med Fachanwendung GDA 2 PatientGDA 1e-Med FAGDA 1e-Med FAGDA 2PatientGDA 1GDA 1e-Med FAe-Med FAGDA 2GDA 2PatientPatientGDA 1e-Med FARead1GET CollectionBundle2Prüfung auf bestehendenMedikationsplanalt[kein Medikationsplan vorhanden]3leeres Ergebnis[Medikationsplan vorhanden]4CollectionBundle (Medikationsplan + Ressourcen) (unverändert)Fachanwendung liefert Medikationsplan oder leeres Ergebnis zurück.Read-only-Zugriff


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 (TODO query prüfen)

Read-to-Write-Zugriff

Der Read-to-Write-Zugriff dient dem Abruf des Medikationsplans und der Vorbereitung einer nachfolgenden Änderung.

Ablauf

  1. Der GDA führt ein POST $readtowrite 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 Collection Bundle persistiert), wird von der Fachanwendung aus diesem ein Collection Bundle zur Auslieferung bereitgestellt:
    • mit einem neuen oder bereits temporär gespeicherten List.identifier (wird von der Fachanwendung zur späteren Integritätsprüfung beim Schreibvorgang verwaltet)
    • 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 Collection Bundle an den GDA:
    • inkl. List und aller referenzierten Ressourcen (inline)
    • ergänzt um den List.identifier
    • 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).

Der temporär gespeicherte List.identifier für die Integritätsprüfung beim Schreibvorgang wird von der Fachanwendung separat von den FHIR Ressourcen verwaltet.

Custom Operations

$readtowrite

Sequenzdiagramm Read-to-Write-Zugriff


 GDA 1 e-Med Fachanwendung GDA 2 PatientGDA 1e-Med FAGDA 1e-Med FAGDA 2PatientGDA 1GDA 1e-Med FAe-Med FAGDA 2GDA 2PatientPatientGDA 1e-Med FARead-to-Write1POST $readtowriteMedikationsplan abrufen,mit der Intention zu schreiben2Prüfung auf bestehendenMedikationsplanalt[kein Medikationsplan vorhanden]3Kein Plan vorhanden:Fachanwendung erzeugt leeren Medikationsplanmit emptyReason = "notstarted"4Leerer Medikationsplan[Medikationsplan vorhanden]5Plan vorhanden:stellt Collection Bundle zur Auslieferung bereit:(inkl. neuem temporär gespeicherten List.identifier)Bedingung für Read-to-Write Collection Bundle:- new|changed → unchanged- removed → entfernen6Collection Bundle + List.identifier7Einträge hinzufügen/ändern/entfernenMedikationsplan bearbeiten.Nach Fertigstellung kann ein Write-Zugriff erfolgen.Read-to-Write-Zugriff


Write-Zugriff

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

Ablauf

  1. Der GDA übermittelt via POST $write den aktualisierten Medikationsplan als Transaction Bundle:
    • 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 übermittelte List.identifier mit dem List.identifier der temporär gespeicherten Medikationsplanversion übereinstimmt (d.h. es wurde zwischenzeitlich kein anderer Schreibvorgang durchgeführt).
  3. Stimmt der List.identifier nicht überein, lehnt die Fachanwendung das Speichern des Medikationsplans ab. Es muss erneut ein Read-to-Write 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 Collection Bundle, das als neuer Medikationsplan persistiert wird.
  6. Der GDA erhält eine Meldung, dass der Medikationsplan erfolgreich aktualisiert wurde.

Custom Operations

$write

Sequenzdiagramm Write-Zugriff


 GDA 1 e-Med Fachanwendung GDA 2 PatientGDA 1e-Med FAGDA 1e-Med FAGDA 2PatientGDA 1GDA 1e-Med FAe-Med FAGDA 2GDA 2PatientPatientGDA 1e-Med FAVorbedingung: Nach einem Read-to-Writewurde der Medikationsplan bearbeitWrite1POST $write (Transaction Bundle + List.identifier)2List.identifier im TransactionBundle ==temporär gespeicherter List.identifier?alt[ungültig]3Validierung des neuen Plans(keine unzulässigen Zustandsübergänge)4Fehler[gültig]5Persistiert neue Version desMedikationsplansNeuer Medikationsplan gespeichert6OKWrite-Zugriff


Diagramm Read-to-Write- und Write-Logik


diagram

Abgelehnter Write-Zugriff

Ablauf

  1. GDA 1 möchte den Medikationsplan seiner Patientin bearbeiten und führt ein POST $readtowrite auf das Collection Bundle des Medikationsplans aus.
  2. Die Fachanwendung prüft, ob ein Medikationsplan für den/die Patient:in existiert (siehe Read-to-Write-Zugriff). Annahme: Es ist bereits ein Medikationsplan vorhanden.
  3. Die Fachanwendung erstellt ein Collection Bundle zur Auslieferung (siehe Read-to-Write-Zugriff) mit dem temporären List.identifier "123"
  4. Die Fachanwendung liefert das Collection Bundle an den GDA 1.
  5. GDA 1 bearbeitet den Medikationsplan.
  6. GDA 2 führt ein POST $readtowrite auf den Medikationsplan aus, während GDA 1 das von der Fachanwendung übermittelte Collection Bundle bearbeitet.
  7. Die Fachanwendung prüft erfolgreich, ob ein Medikationsplan für den/die Patient:in existiert.
  8. Die Fachanwendung erstellt, genau wie für GDA 1, ein Collection Bundle zur Auslieferung (siehe Read-to-Write-Zugriff) mit dem temporären List.identifier "123"
  9. Die Fachanwendung liefert das Collection Bundle an den GDA 2.
  10. GDA 2 bearbeitet zeitgleich mit GDA 1 den Medikationsplan.
  11. GDA 2 sendet zuerst mittels POST $write ein Transaction Bundle mit dem aktualisierten Medikationsplan.
  12. Die Fachanwendung prüft, ob der temporär in der Fachanwendung vorgehaltene List.identifier mit dem im Transaction Bundle verwendeten List.identifier übereinstimmt. Beide haben den Wert "123".
  13. Die Fachanwendung validert den neuen Plan (keine unzulässigen Zustandsübergänge)
  14. Die Prüfung verläuft erfolgreich, der neue Medikationsplan mit List.identifier "123" wird persistiert.
  15. Die Fachanwendung löscht den temporären List.identifier "123".
  16. GDA 2 erhält eine Meldung, dass der Medikationsplan erfolgreich aktualisiert wurde.
  17. GDA 1 sendet mittels POST $write ein Transaction Bundle mit dem aktualisierten Medikationsplan mit List.identifier "123".
  18. Die Prüfung auf Übereinstimmung des von GDA 1 verwendeten List.identifier und dem von der der Fachanwendung vorgehaltenen temporären identifer schlägt fehl.
  19. Die Fachanwendung lehnt das Speichern ab.
  20. GDA 1 erhält eine Fehlermeldung und muss ein erneutes Read-to-Write ausführen, welches das Generieren eines zur Auslieferung bereitgestellten temporären Collection Bundles inkl. neuem List.identifiers auslöst.

Sequenzdiagramm Abgelehnter Write-Zugriff


 GDA 1 e-Med Fachanwendung GDA 2 PatientGDA 1e-Med FAe-Med FAe-Med FAe-Med FAGDA 2GDA 1e-Med FAGDA 2PatientGDA 1GDA 1e-Med FAe-Med FAGDA 2GDA 2PatientPatientGDA 1e-Med FAe-Med FAe-Med FAe-Med FAGDA 2Read-to-Write durch GDA 11POST $readtowrite2Annahme: Prüfung auf bestehendenMedikationsplan erfolgreich3Collection Bundle zur Auslieferung erstellt(inkl. temporärem List.identifier "123")4Collection Bundle + List.identifier "123"5Einträge hinzufügen/ändern/entfernenGDA 1 bearbeitet MedikationsplanRead-to-Write durch GDA 26POST $readtowrite7Annahme: Prüfung auf bestehendenMedikationsplan erfolgreich8Collection Bundle zur Auslieferung erstellt(inkl. temporärem List.identifier "123")9Collection Bundle + List.identifier "123"10Einträge hinzufügen/ändern/entfernenGDA 2 bearbeitet MedikationsplanWrite durch GDA 211POST $write (Transaction Bundle + List.identifier "123")12List.identifier "123" im Transaction Bundle ==temporär gespeicherter List.identifier "123"13Validierung des neuen Plans(keine unzulässigen Zustandsübergänge)14Persistiert neue Version desMedikationsplans mit List.identifier "123"15Löscht temporären List.identifier "123"16OKMedikationsplan wurde durch GDA 2 aktualisiert.Write-Error für GDA 117POST $write (Transaction Bundle + List.identifier "123")18List.identifier "123" im TransactionBundle stimmt nichtmit temporär gespeicherten List.identifier überein(kein Eintrag vorhanden)19Fachanwendung lehnt Speichern ab20Fehler (Konflikt)Speichern des Medikationsplans wurde abgelehnt, der GDA 1 muss ein neues Read-to-Write ausführen.Write-Error