ELGA e-Medikation (R4) DRAFT
0.1.0 - ci-build
ELGA e-Medikation (R4) DRAFT
0.1.0 - ci-build
ELGA e-Medikation (R4) DRAFT, published by ELGA GmbH. This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7Austria/ELGA-e-Medikation-R4/ and changes regularly. See the Directory of published versions
Dieser technische Use Case beschreibt den schreibenden Zugriff berechtigter Akteure auf den Medikationsplan eines ELGA-Teilnehmers.
Für ELGA-Teilnehmer (bzw. deren Vertretungen) erfolgt der schreibende Zugriff im Rahmen der Ausübung von Teilnehmerrechten ausschließlich über das ELGA-Zugangsportal. Für GDA erfolgt der schreibende Zugriff über die e-Medikation-Schnittstelle des jeweiligen GDA-Systems.
Der schreibende Zugriff umfasst folgende Bearbeitungen der aktuellen Version des Medikationsplans:
Jede Änderung am Medikationsplan führt zur Erstellung einer neuen Medikationsplanversion. Für GDA gilt zusätzich:
Für jeden Schreibvorgang auf dem aktuellen Medikationsplan MUSS der folgende technische Ablauf eingehalten werden:
Die nachfolgenden technischen Use Cases beschreiben die für den jeweiligen Anwendungsfall erforderlichen Änderungen an den Ressourcen sowie die Struktur und Inhalte des Medikationsplan-Transaction-Bundles.
Alle vom GDA ausgeführten, schreibenden Zugriffe auf den Medikationsplan erfolgen über die Custom Operation $plan-write. Die Fachanwendung verwendet den im Request übermittelten ETag zur Integritätsprüfung (Optimistic Locking), um konkurrierende Änderungen am Medikationsplan zu erkennen.
Offene Frage:
- Liefert die Fachanwendung mit der HTTP 200 OK Response im Body auch die Ressourcen, so wie sie persistiert wurden, wieder zurück? Bei neu angelegten Ressourcen ist erst dadurch für den Client die id ersichtlich (wird vom Server vergeben).
Offener Punkt:
- OperationOutcome defnieren
Der GDA kann dem Medikationsplan ein oder mehrere Planeinträge hinzufügen (neu einzunehmende, verordnete Medikation). Dabei muss er dokumentieren, ob dieser von ihm selbst stammt oder nicht (Fremdmedikation durch einen anderen GDA bzw. Eigenmedikation des Patienten).
Der GDA führt ein POST $plan-read aus und bearbeitet die von der Fachanwendung im Medikationsplan-Bundle bereitgestellten Ressourcen:
Im Anschluss übermittelt der GDA mit POST $plan-write den aktualisierten Medikationsplan in einem Transaction Bundle:
Anmerkung: Beim nächsten $plan-read ändert die Fachanwendung im zur Auslieferung bereitgestellten Medikationsplan-Bundle den Status der List.entry.flags von new automatisch auf unchanged.
AtElgaEmedListMedikationsplan
date: Datum der aktuellen Bearbeitung des Medikationsplans
source: für die Bearbeitung veranwortlicher GDA
entry[0]: // 1. Planeintrag wird hinzufgefügt
flag: new
item: Referenz auf den Planeintrag 1 // siehe "Relevante Elemente (MedicationRequest - Planeintrag 1)"
entry[1]: // 2. Planeintrag wird hinzufgefügt
flag: new
item: Referenz auf den Planeintrag 2 // analog zu "Relevante Elemente (MedicationRequest - Planeintrag 1)"
AtElgaEmedMedicationRequestPlaneintrag
status: active | on-hold
category: "Planeintrag" // fester Wert
reportedBoolean: false | true // false, wenn vom Ersteller des Planeintrags
medicationReference.reference: Medikation mit PZN oder Magistrale Zubereitung // Contained Medication
authoredOn: Datum der Erstellung des Planeintrags
requester: veranwortlicher GDA // wird auf Übereinstimmung mit List.source geprüft
courseOfTherapyType: continuous | acute
dosageInstruction: Dosierung + Einnahmezeitraum (ab sofort | in der Zukunft)
Der GDA kann im Medikationsplan ein oder mehrere Planeinträge ändern. Dazu wird eine neue Version des Planeintrags erstellt.
Die Änderung des Planeintrags kann alle Inhalte umfassen, z.B.: Änderung des Status (pausieren/aktivieren), Änderung des Einnahmezeitraums, der Medikation oder der Dosierung. Bei fehlender fachlicher Kontinuität der Bearbeitung eines Planeintrages (z.B. Änderung des Arzneimittels von Blutdruckmittel auf Antibiotikum) muss ein neuer Planeintrag erfasst werden.
Der GDA führt ein POST $plan-read aus und bearbeitet die von der Fachanwendung im Medikationsplan-Bundle bereitgestellten Ressourcen:
Der GDA übermittelt mit POST $plan-write den aktualisierten Medikationsplan in einem Transaction Bundle:
Anmerkung: Beim nächsten $plan-read ändert die Fachanwendung im zur Auslieferung bereitgestellten Medikationsplan-Bundle den Status der List.entry.flags von changed automatisch auf unchanged.
AtElgaEmedListMedikationsplan
date: Datum der aktuellen Bearbeitung des Medikationsplans
source: für die Bearbeitung veranwortlicher GDA
entry[0]: // 1. Planeintrag wird geändert
flag: changed
item: Referenz auf den Planeintrag 1 // siehe "Relevante Elemente (MedicationRequest) Planeintrag 1"
entry[1]: // 2. Planeintrag bleibt unverändert
flag: unchanged
item: Referenz auf den Planeintrag 2
AtElgaEmedMedicationRequestPlaneintrag
status: active | on-hold
statusReason.coding: Grund der Änderung // optional
[...]
authoredOn: Datum der Änderung des Planeintrags
requester: für die Änderung verantwortlicher GDA
[...]
priorPrescription: Referenz auf ersetzte Planeintragsversion
Der GDA kann ein oder mehrere Planeinträge im Medikationsplan beibehalten und unverändert zur Kennntis nehmen. Bedingung dafür ist, dass der Einnahmezeitraum des im Planeintrag dokumentierten Arzneimittels noch nicht abgelaufen ist (siehe Sub_UC_eMed_02_09 - Abgelaufenen Planeintrag weiterverordnen oder beenden).
Der GDA führt ein POST $plan-read aus und bearbeitet die von der Fachanwendung im Medikationsplan-Bundle bereitgestellten Ressourcen:
Der GDA übermittelt mit POST $plan-write den aktualisierten Medikationsplan in einem Transaction Bundle:
AtElgaEmedListMedikationsplan
date: Datum der aktuellen Bearbeitung des Medikationsplans
source: für die Bearbeitung veranwortlicher GDA
entry[0]: // 1. Planeintrag bleibt unverändert
flag: unchanged // von der Fachanwendung gesetzt Wert bleibt unverändert
item: Referenz auf den Planeintrag 1 // Ressource wird im Transaction Bundle nicht übermittelt
AtElgaEmedMedicationRequestPlaneintrag
// unverändert (verantwortlicher GDA, Datum, Status der vorhergehenden Bearbeitung bleiben unverändert)
Ein GDA kann die Therapie eines Patienten vorübergehend unterbrechen, wenn eine Wiederaufnahme vorgesehen ist. Eine Begründung kann dokumentiert werden. Eine zukünftige geplante Unterbrechung kann nicht über den Status des list.entry.flags dokumentiert werden.
Der GDA führt ein POST $plan-read aus und bearbeitet die von der Fachanwendung im Medikationsplan-Bundle bereitgestellten Ressourcen:
Der GDA übermittelt mit POST $plan-write den aktualisierten Medikationsplan in einem Transaction Bundle:
Anmerkung: Beim nächsten $plan-read ändert die Fachanwendung im zur Auslieferung bereitgestellten Medikationsplan-Bundle den Status der List.entry.flags von changed automatisch auf unchanged.
AtElgaEmedListMedikationsplan
date: Datum der aktuellen Bearbeitung des Medikationsplans
source: für die Bearbeitung veranwortlicher GDA
entry[0]: // 1. Planeintrag wird pausiert
flag: changed
item: Referenz auf den Planeintrag 1
entry[1]: // 2. Planeintrag bleibt unverändert
flag: unchanged
item: Referenz auf den Planeintrag 2
AtElgaEmedMedicationRequestPlaneintrag
status: Pausierung: on-hold | Aktivierung: active
statusReason.coding: Grund der Pausierung (verplfichtend), Grund für Aktivierung (optional)
[...]
authoredOn: Datum der Änderung des Planeintrags
requester: für die Änderung verantwortlicher GDA
[...]
priorPrescription: Referenz auf ersetzte Planeintragsversion
Ein GDA kann explizit dokumentieren, dass für den Patienten derzeit keine Medikation vorgesehen ist.
Der GDA führt ein POST $plan-read aus und bearbeitet die von der Fachanwendung im Medikationsplan-Bundle bereitgestellten Ressourcen:
Die Vorgehensweise unterscheidet sich je nach Inhalt des Medikationspans:
sämtliche Planeinträge. Beim nächsten $plan-read erkennt die Fachanwendung diesen Zustand und liefert den Medikationsplan mit List.emptyReason = unavailable aus. Optional kann der GDA nun explizit einen leeren Plan dokumentieren (siehe 1.B).
AtElgaEmedListMedikationsplan
date: Datum der aktuellen Bearbeitung des Medikationsplans
source: für die Bearbeitung veranwortlicher GDA
emptyReason: nilknown // Patient soll keine Medikation einnehmen
Der GDA kann einen oder mehrere Planeinträge aufgrund einer falschen Eingabe stornieren. Ein Grund ist verpflichtend anzugeben.
Der GDA führt ein POST $plan-read aus und bearbeitet die von der Fachanwendung im Medikationsplan-Bundle bereitgestellten Ressourcen:
Der GDA übermittelt mit POST $plan-write den aktualisierten Medikationsplan in einem Transaction Bundle:
Anmerkung: Beim nächsten $plan-read entfernt die Fachanwendung im zur Auslieferung bereitgestellten Medikationsplan-Bundle die mit removed gekennzeichneten Einträge automatisch aus dem Mediaktionsplan.
AtElgaEmedListMedikationsplan
date: Datum der aktuellen Bearbeitung des Medikationsplans
source: für die Bearbeitung veranwortlicher GDA
entry[0]: // 1. Planeintrag wird storniert
flag: removed
item: Referenz auf den Planeintrag 1 // siehe "Relevante Elemente (MedicationRequest - Planeintrag 1)"
entry[1]: // 2. Planeintrag bleibt unverändert
flag: unchanged
item: Referenz auf den Planeintrag 2
AtElgaEmedMedicationRequestPlaneintrag
status: entered-in-error
statusReason.coding: Grund für die Stornierung // verpflichtend
[...]
authoredOn: Datum der Stornierung
requester: für die Stornierung verantwortlicher GDA
[...]
priorPrescription: Referenz auf ersetzte Planeintragsversion
Der GDA kann eine Medikation, welche in einen Planeintrag dokumentiert ist, beenden. Es wird keine Unterscheidung getroffen, ob die Medikation regulär abgeschlossen oder vorzeitig beendet wird. Ein Grund ist verpflichtend anzugeben.
Der GDA führt ein POST $plan-read aus und bearbeitet die von der Fachanwendung im Medikationsplan-Bundle bereitgestellten Ressourcen:
Der GDA übermittelt mit POST $plan-write den aktualisierten Medikationsplan in einem Transaction Bundle:
Anmerkung: Beim nächsten $plan-read entfernt die Fachanwendung im zur Auslieferung bereitgestellten Medikationsplan-Bundle die mit removed gekennzeichneten Einträge automatisch aus dem Mediaktionsplan.
AtElgaEmedListMedikationsplan
date: Datum der aktuellen Bearbeitung des Medikationsplans
source: für die Bearbeitung veranwortlicher GDA
entry[0]: // 1. Planeintrag wird beendet
flag: removed
item: Referenz auf den Planeintrag 1 // siehe "Relevante Elemente (MedicationRequest - Planeintrag 1)"
entry[1]: // 2. Planeintrag bleibt unverändert
flag: unchanged
item: Referenz auf den Planeintrag 2
AtElgaEmedMedicationRequestPlaneintrag
status: stopped
statusReason.coding: Grund für das Beenden // verpflichtend
[...]
authoredOn: Datum der Beendigung
requester: für die Beendigung verantwortlicher GDA
[...]
priorPrescription: Referenz auf ersetzte Planeintragsversion
Planeinträge mit abgelaufenem Einnahmezeitraum (überschrittenes Enddatum in extension:effectiveDosePeriod) werden im von der Fachanwendung ausgelieferten Medikationsplan-Bundle automatisch mit List.entry.flag = removed und MedicationRequest.status = stopped markiert.
1.A Möchte der GDA die Einnahme weiterverordnen, muss er entsprechende Anpassungen vornehmen (siehe Sub_UC_eMed_02_03 - Planeintrag im Medikationsplan ändern).
1.B Soll die Einnahme nicht weiterverordnet werden, nimmt der GDA keine Änderung am List.entry.flag und dem abgelaufenen Planeintrag vor (auch kein Beendigungsgrund und keine Aktualisierung des GDAs im Planeintrag).
Er übermittelt mit POST $plan-write den aktualisierten Medikationsplan in einem Transaction Bundle:
Beim nächsten $plan-read entfernt die Fachanwendung im zur Auslieferung bereitgestellten Medikationsplan-Bundle die mit removed gekennzeichneten Einträge automatisch aus dem Mediaktionsplan.
AtElgaEmedListMedikationsplan
date: Datum der aktuellen Bearbeitung des Medikationsplans
source: für die Bearbeitung veranwortlicher GDA
entry[0]: // 1. Planeintrag wird entfernt
flag: removed
item: Referenz auf den Planeintrag 1 // siehe "Relevante Elemente (MedicationRequest - Planeintrag 1)"
entry[1]: // 2. Planeintrag bleibt unverändert
flag: unchanged
item: Referenz auf den Planeintrag 2
AtElgaEmedMedicationRequestPlaneintrag
extension:effectiveDosePeriod: liegt in der Vergangenheit // bleibt unverändert
status: stopped // von Fachanwendung gesetzt, bleibt unverändert
statusReason.coding: Grund für die vorhergehende Statunsänderung // bleibt unverändert
[...]
authoredOn: Datum der vorhergehenden Bearbeitung // bleibt unverändert
requester: für die vorhergehende Bearbeitung verantwortlicher GDA // bleibt unverändert
[...]
priorPrescription: Referenz auf ersetzte Planeintragsversion
Der GDA kann die Reihenfolge der Planeinträge ändern. Die Einträge selbst bleiben dabei unverändert. Der Einnahmezeitraum der im Planeintrag dokumentierten Arzneimittel darf noch nicht abgelaufen sein (siehe Sub_UC_eMed_02_09 - Abgelaufenen Planeintrag weiterverordnen oder beenden).
Der GDA führt ein POST $plan-read aus und bearbeitet die von der Fachanwendung im Medikationsplan-Bundle bereitgestellten Ressourcen:
Der GDA übermittelt mit POST $plan-write den aktualisierten Medikationsplan in einem Transaction Bundle:
In folgendem Beispiel wird der ursprünglich 2. Eintrag als 1. gereiht. Beider Planeinträge wurden nicht geändert.
AtElgaEmedListMedikationsplan
date: Datum der aktuellen Bearbeitung des Medikationsplans
source: für die Bearbeitung veranwortlicher GDA
entry[0]: // 2. Planeintrag
flag: unchanged
item: Referenz auf den Planeintrag 2
entry[1]: // 1. Planeintrag
flag: unchanged
item: Referenz auf den Planeintrag 1
AtElgaEmedMedicationRequestPlaneintrag
// unverändert (verantwortlicher GDA, Datum, Status bleiben unverändert)
Offene Fragen: Ausüben der Teilnehmerrechte in Arbeit.
Offene Fragen: Ausüben der Teilnehmerrechte in Arbeit.