ELGA e-Medikation (R4) DRAFT
0.1.1 - ci-build
ELGA e-Medikation (R4) DRAFT
0.1.1 - ci-build
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
Ein berechtigter GDA kann den Medikationsplan eines ELGA-Teilnehmers bearbeiten.
Ein ELGA-Teilnehmer kann Medikationsplaneinträge bzw. Medikationspläne über das Zugangsportal unwiderruflich löschen.
Alle Schreibvorgänge auf einem Medikationsplan folgen demselben technischen Grundablauf:
Die nachfolgenden technischen Use Cases beschreiben die jeweils erforderlichen Änderungen an den Ressourcen sowie die Inhalte des Medikationsplan-Transaction-Bundles. Der technische Ablauf von $plan-write einschließlich der Integritätsprüfung mittels ETag ist für alle Schreiboperationen identisch und wird im folgenden Abschnitt beschrieben.
Alle Schreiboperationen 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.
Ein Medikationsplan mit List.emptyReason = nilknown dokumentiert, dass für den Patienten derzeit keine Medikation vorgesehen ist.
Der Wert nilknown dient der Unterscheidung zwischen einem noch nie befüllten Medikationsplan (notstarted) und einem Medikationsplan, für den bewusst keine Medikation dokumentiert ist (nilknown).
Der Medikationsplan erhält den Status List.emptyReason = nilknown in folgenden Fällen:
AtElgaEmedListMedikationsplan
identifier: von der Fachanwendung übermittelt (Integritätsprüfung)
status: current
mode: working
date: Datum der Bearbeitung
source: veranwortlicher GDA
emptyReason: nilknown // Patient nimmt derzeit kein Medikation ein
Der GDA kann dem Medikationsplan ein oder mehrere Medikationsplaneinträge hinzufügen. Dabei muss er dokumentieren, ob es sich bei dem Eintrag um Fremdmedikation handelt (d.h. ein anderer Arzt hat das Medikament ursprünglich verordnet).
Hierfür führt der GDA ein $plan-read aus und bearbeitet das von der Fachanwendung übermittelte Collection Bundle:
Im Anschluss übermittelt der GDA (via POST $plan-write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Anmerkung: Beim nächsten Plan-Read ändert die Fachanwendung im zur Auslieferung bereitgestellten Collection Bundle den Status der Einträge mit new automatisch auf unchanged.
AtElgaEmedListMedikationsplan
identifier: von der Fachanwendung übermittelt (Integritätsprüfung)
status: current
mode: working
date: Datum der Bearbeitung des Medikationsplans
source: veranwortlicher GDA
entry[0]: // 1. Medikationsplaneintrag wird hinzufgefügt
flag: new
date: Datum der Aufnahme des Medikationsplaneintrags // in diesem Fall gleich mit dem Datum der Bearbeitung des Medikationsplans
item: Referenz auf den Planeintrag 1 // siehe "Relevante Elemente (MedicationRequest) Planeintrag 1"
entry[1]: // 2. Medikationsplaneintrag wird hinzufgefügt
flag: new
date: Datum der Aufnahme des Medikationsplaneintrags // in diesem Fall gleich mit dem Datum der Bearbeitung des Medikationsplans
item: Referenz auf den Planeintrag 2 // analog zu "Relevante Elemente (MedicationRequest) Planeintrag 1"
AtElgaEmedMedicationRequestPlaneintrag
identifier: neue Medikationsplaneintrag-ID
status: active | on-hold
reportedBoolean: true | false // true, wenn Fremdmedikation
medicationReference.reference: Medikation mit PZN oder Magistrale Anwendung // Contained Medication
authoredOn: Datum der Erstellung des Medikationsplaneintrags
requester: veranwortlicher GDA // wird auf Übereinstimmung mit List.source geprüft
dosageInstruction: Dosierung + Einnahmezeitraum (ab sofort | in der Zukunft)
Siehe Auswirkung der Zugriffsart auf List.entry.flags und Bundle-Inhalte.
Der GDA kann im Medikationsplan ein oder mehrere Medikationsplaneinträge beibehalten und unverändert zur Kennntis nehmen.
Hierfür führt der GDA ein $plan-read aus und lässt die entsprechenen Medikationsplaneinträge (MedicationRequests) des von der Fachanwendung übermittelten Collection Bundles unverändert (im Status active oder on-hold). Ist der Behandlungszeitraum der Medikationsplaneinträge abgelaufen, muss dieser angepasst werden (siehe Sub_UC_eMed_06_05 - Medikationsplaneintrag im Medikationsplan ändern).
Im Element List.source wird mit dem aktuellen GDA, das Datum in date aktualisiert.
Der GDA übermittelt (via POST $plan-write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Siehe Plan-Read und Plan-Write.
AtElgaEmedListMedikationsplan
identifier: von der Fachanwendung übermittelt (Integritätsprüfung)
status: current
mode: working
date: Datum der Bearbeitung des Medikationsplans
source: Veranwortlicher GDA
entry[0]: // 1. Medikationsplaneintrag bleibt unverändert
flag: unchanged
date: Datum der Aufnahme des Medikationsplaneintrags // in diesem Fall unterschiedlich mit dem Datum der Bearbeitung des Medikationsplans
item: Referenz auf den Planeintrag 1
AtElgaEmedMedicationRequestPlaneintrag
// unverändert (verantwortlicher GDA, Datum, Status bleiben bestehen)
Siehe Auswirkung der Zugriffsart auf List.entry.flags und Bundle-Inhalte.
Ein GDA kann die Therapie eines Patienten vorübergehend unterbrechen (die Wiederaufnahme ist vorgesehen).
Hierfür führt der GDA ein $plan-read aus und bearbeitet das von der Fachanwendung übermittelte Collection Bundle:
Im Anschluss übermittelt der GDA (via POST $plan-write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Anmerkung: Beim nächsten Plan-Read ändert die Fachanwendung im zur Auslieferung bereitgestellten Collection Bundle den Status der Einträge mit changed automatisch auf unchanged.
Siehe Plan-Read und Plan-Write.
AtElgaEmedListMedikationsplan
identifier: von der Fachanwendung übermittelt (Integritätsprüfung)
status: current
mode: working
date: Datum der Bearbeitung des Medikationsplans
source: Veranwortlicher GDA
entry[0]: // 1. Medikationsplaneintrag wird pausiert
flag: changed
date: Datum der Änderung des Medikationsplaneintrags // in diesem Fall gleich mit dem Datum der Bearbeitung des Medikationsplans
item: Referenz auf den Planeintrag 1
entry[1]: // 2. Medikationsplaneintrag bleibt unverändert
flag: unchanged
date: Datum der Aufnahme des Medikationsplaneintrags // in diesem Fall unterschiedlich mit dem Datum der Bearbeitung des Medikationsplans
item: Referenz auf den Planeintrag 2
AtElgaEmedMedicationRequestPlaneintrag
identifier: Medikationsplaneintrag-ID bleibt bestehen
status: on-hold
statusReason.text: Freitextbegrüdung
reportedBoolean: false // Fremdmedikation
authoredOn: Datum der Pausierung des Medikationsplaneintrags
requester: für die Pausierung verantwortlicher GDA
priorPrescription: Referenz auf ersetzten Medikationsplaneintrag
Siehe Auswirkung der Zugriffsart auf List.entry.flags und Bundle-Inhalte.
Der GDA kann im Medikationsplan ein oder mehrere Medikationsplaneinträge ändern.
Die Änderung des Medikationsplaneintrag kann alle Inhalte umfassen, z.B.: Änderung des Status (von pausiert zu aktiv u.u.), Änderung des Behandlungszeitraums, der Dosierung oder der Medikation. Wird die Medikationsplaneintrag-ID (identifier) geändert, kann über diese kein Bezug mehr zu vorherehenden Planeinträgen hergestellt werden. Bei fehlender fachlicher Kontinuität der Bearbeitung eines Medikationsplaneintrages (z.B. Änderung PZN; Blutdruckmittel auf Antibiotikum) soll ein neuer Medikationsplaneintrag erfasst und kein bestehender Eintrag weiterverwendet werden.
Hierfür führt der GDA ein $plan-read aus und bearbeitet das von der Fachanwendung übermittelte Collection Bundle:
Der GDA übermittelt (via POST $plan-write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Anmerkung: Beim nächsten Plan-Read ändert die Fachanwendung im zur Auslieferung bereitgestellten Collection Bundle den Status der Einträge mit changed automatisch auf unchanged.
Siehe Plan-Read und Plan-Write.
AtElgaEmedListMedikationsplan
identifier: von der Fachanwendung übermittelt (Integritätsprüfung)
status: current
mode: working
date: Datum der Bearbeitung des Medikationsplans
source: Veranwortlicher GDA
entry[0]: // 1. Medikationsplaneintrag wird geändert
flag: changed
date: Datum der Änderung des Medikationsplaneintrags // in diesem Fall gleich mit dem Datum der Bearbeitung des Medikationsplans
item: Referenz auf den Planeintrag 1
entry[1]: // 2. Medikationsplaneintrag bleibt unverändert
flag: unchanged
date: Datum der Aufnahme des Medikationsplaneintrags // in diesem Fall unterschiedlich mit dem Datum der Bearbeitung des Medikationsplans
item: Referenz auf den Planeintrag 2
AtElgaEmedMedicationRequestPlaneintrag
identifier: Medikationsplaneintrag-ID bleibt bestehen // sofern der Bezug erhalten bleiben soll
status: active | on-hold
statusReason.text: Freitextbegrüdung für die Änderung
reportedBoolean: false // Fremdmedikation
medicationReference.reference: Änderungen betreffend der Medikation // Contained Medication
authoredOn: Datum der Änderung des Medikationsplaneintrags
requester: für die Änderung verantwortlicher GDA
dosageInstruction: Änderung betreffend Dosierung + Einnahmezeitraum (ab sofort | in der Zukunft)
priorPrescription: Referenz auf ersetzten Medikationsplaneintrag
Siehe Auswirkung der Zugriffsart auf List.entry.flags und Bundle-Inhalte.
Der GDA kann einen oder mehrere Medikationsplaneinträge aufgrund einer falschen Eingabe stornieren. Diese sind beim nächsten Plan-Read nicht mehr im Medikationsplan enthalten.
Hierfür führt der GDA ein $plan-read aus und bearbeitet das von der Fachanwendung übermittelte Collection Bundle:
Der GDA übermittelt (via POST $plan-write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Siehe Plan-Read und Plan-Write.
Relevante Elemente (List)
AtElgaEmedListMedikationsplan
identifier: von der Fachanwendung übermittelt (Integritätsprüfung)
status: current
mode: working
date: Datum der Bearbeitung des Medikationsplans
source: Veranwortlicher GDA
entry[0]: // 1. Medikationsplaneintrag wird storniert
flag: removed
date: Datum der Stornierung des Medikationsplaneintrags // in diesem Fall gleich mit dem Datum der Bearbeitung des Medikationsplans
item: Referenz auf den Planeintrag 1
entry[1]: // 2. Medikationsplaneintrag bleibt unverändert
flag: unchanged
date: Datum der Aufnahme / Änderung des Medikationsplaneintrags // in diesem Fall unterschiedlich mit dem Datum der Bearbeitung des Medikationsplans
item: Referenz auf den Planeintrag 2
AtElgaEmedMedicationRequestPlaneintrag
identifier: Medikationsplaneintrag-ID bleibt bestehen
status: entered-in-error
statusReason.text: Freitextbegrüdung für die Stornierung
reportedBoolean: false // Fremdmedikation
authoredOn: Datum der Stornierung des Medikationsplaneintrags
requester: für die Stornierung verantwortlicher GDA
priorPrescription: Referenz auf ersetzten Medikationsplaneintrag
Siehe Auswirkung der Zugriffsart auf List.entry.flags und Bundle-Inhalte.
Der GDA möchte das Medikament (welches in einen Medikationsplaneintrag dokumentiert ist) absetzen, bevor alle geplanten Einnahmen oder Verabreichungen durchgeführt wurden. Der betreffende Planeintrag ist beim nächsten Plan-Read nicht mehr im Medikationsplan enthalten.
Hierfür führt der GDA ein $plan-read aus und bearbeitet das von der Fachanwendung übermittelte Collection Bundle:
Der GDA übermittelt (via POST $plan-write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Siehe Plan-Read und Plan-Write.
AtElgaEmedListMedikationsplan
identifier: von der Fachanwendung übermittelt (Integritätsprüfung)
status: current
mode: working
date: Datum der Bearbeitung des Medikationsplans
source: Veranwortlicher GDA
entry[0]: // 1. Medikationsplaneintrag wird abgesetzt
flag: removed
date: Datum der Absetzung des Medikationsplaneintrags // in diesem Fall gleich mit dem Datum der Bearbeitung des Medikationsplans
item: Referenz auf den Planeintrag 1 // siehe "Medikationsplaneintrag ändern"
entry[1]: // 2. Medikationsplaneintrag bleibt unverändert
flag: unchanged
date: Datum der Aufnahme / Änderung des Medikationsplaneintrags // in diesem Fall unterschiedlich mit dem Datum der Bearbeitung des Medikationsplans
item: Referenz auf den Planeintrag 2
AtElgaEmedMedicationRequestPlaneintrag
identifier: Medikationsplaneintrag-ID bleibt bestehen
status: stopped
statusReason.text: Freitextbegrüdung für das Absetzen des Medikaments
reportedBoolean: false // Fremdmedikation
authoredOn: Datum des Absetzens des Medikationsplaneintrags
requester: für das Absetzen verantwortlicher GDA
priorPrescription: Referenz auf ersetzten Medikationsplaneintrag
Siehe Auswirkung der Zugriffsart auf List.entry.flags und Bundle-Inhalte.
Erhält ein GDA nach einem Plan-Read Medikationsplaneinträge, deren Behandlungszeitraum (effectiveDosePeriod.end) abgelaufen ist, muss der GDA diese Einträge beenden oder bearbeiten (zumindest den Behandlungszeitraum anpassen) bevor ein erneutes Speichern des Medikationsplans zulässig ist (siehe Sub_UC_eMed_06_05 - Medikationsplaneintrag im Medikationsplan ändern). Beendete Planeinträge sind beim nächsten Plan-Read nicht mehr im Medikationsplan enthalten.
Um Planeinträge zu beenden bearbeitet der GDA nach einem $plan-read das von der Fachanwendung übermittelte Collection Bundle wie folgt:
Der GDA übermittelt (via POST $plan-write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Siehe Plan-Read und Plan-Write.
AtElgaEmedListMedikationsplan
identifier: von der Fachanwendung übermittelt (Integritätsprüfung)
status: current
mode: working
date: Datum der Bearbeitung des Medikationsplans
source: Veranwortlicher GDA
entry[0]: // 1. Medikationsplaneintrag wird beendet
flag: removed
date: Datum der Stornierung des Medikationsplaneintrags // in diesem Fall gleich mit dem Datum der Bearbeitung des Medikationsplans
item: Referenz auf den Planeintrag 1
entry[1]: // 2. Medikationsplaneintrag bleibt unverändert
flag: Unchanged
date: Datum der Aufnahme / Änderung des Medikationsplaneintrags // in diesem Fall unterschiedlich mit dem Datum der Bearbeitung des Medikationsplans
item: Referenz auf den Planeintrag 2
AtElgaEmedMedicationRequestPlaneintrag
identifier: Medikationsplaneintrag-ID bleibt bestehen
status: completed
statusReason.text: Freitextbegrüdung
reportedBoolean: false // Fremdmedikation
authoredOn: Datum der Beendigung des Medikationsplaneintrags
requester: für die Beendigung verantwortlicher GDA
priorPrescription: Referenz auf ersetzten Medikationsplaneintrag
Siehe Auswirkung der Zugriffsart auf List.entry.flags und Bundle-Inhalte.
Der GDA kann die Reihenfolge der Medikationsplaneinträge ändern. Die Einträge selbst bleiben dabei unverändert.
Hierfür führt der GDA ein $plan-read aus und bearbeitet das von der Fachanwendung übermittelte Collection Bundle:
Der GDA übermittelt (via POST $plan-write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Siehe Plan-Read und Plan-Write.
In folgendem Beispiel wird der ursprünglich 2. Eintrag als 1. gereiht.
AtElgaEmedListMedikationsplan
identifier: von der Fachanwendung übermittelt (Integritätsprüfung)
status: current
mode: working
date: Datum der Änderung der Reihenfolge
source: Veranwortlicher GDA
entry[0]: // 2. Medikationsplaneintrag
flag: Unchanged
date: Datum der Aufnahme / Änderung des Medikationsplaneintrags
item: Referenz auf den Planeintrag 2
entry[1]: // 1. Medikationsplaneintrag
flag: Unchanged
date: Datum der Aufnahme / Änderung des Medikationsplaneintrags
item: Referenz auf den Planeintrag 1
AtElgaEmedMedicationRequestPlaneintrag
// unverändert (verantwortlicher GDA, Datum, Status bleiben bestehen)
Siehe Auswirkung der Zugriffsart auf List.entry.flags und Bundle-Inhalte.
Der ELGA-Teilnehmer kann via ELGA-Portal einzelne oder alle Medikationsplaneinträge unwiderruflich löschen, wodurch eine neue Medikationsplanversion entsteht. Wurden durch den ELGA-Teilnehmer alle Planeinträge gelöscht, erhält der von der Fachanwendung erstellte, neue Medikationsplan das emptyReason nilknown (siehe Sub_UC_eMed_06_02 - Leerer Medikationsplan (keine Medikation einnehmen)).
Im Unterschied zu einem Entfernen von Einträgen mittels stornieren, absetzen und beenden durch den GDA, wird beim Löschen durch den ELGA-Teilnehmer der betreffende Medikationsplaneintrag aus dem List.Entry entfernt und der betroffene Planeintrag (MedicationRequest) gelöscht (und nicht nur als removed gekennzeichnet).
Hierfür führt der Patient über das Portal ein $plan-read aus und markiert die zu löschenden Medikationsplaneinträge. Die Fachanwendung bearbeitet das Collection Bundle wie folgt:
Im Anschluss übermittelt der Patient über das Portal (via POST $patient-write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Anmerkung: Im persistierten Collection Bundle sind die gelöschten Medikationsplaneiträge nicht mehr enthalten.
Siehe Plan-Read und Patient-Plan-Write.
Zustand vor dem Löschen des 2. Planeintrags (Ergebnis von $plan-read):
AtElgaEmedListMedikationsplan
identifier: von der Fachanwendung übermittelt (Integritätsprüfung)
status: current
mode: working
date: Datum der vorhergehenden Bearbeitung des Medikationsplans
source: veranwortlicher GDA, der vorhergehenden Bearbeitung
entry[0]:
flag: unchanged
date: Datum der Aufnahme des Medikationsplaneintrags
item: Referenz auf den Planeintrag 1
entry[1]:
flag: unchanged
date: Datum der Aufnahme des Medikationsplaneintrags
item: Referenz auf den Planeintrag 2
Zustand nach dem Löschen des 2. Planeintrags (List-Ressource im Transaction Bundle von $patient-write):
AtElgaEmedListMedikationsplan
identifier: von der Fachanwendung übermittelt (Integritätsprüfung)
status: current
mode: working
date: Datum des Löschens des Medikationsplans durch den Patienten
source: Patient
entry[0]: // 1. Medikationsplaneintrag bleibt gleich
flag: unchanged
date: Datum der Aufnahme des Medikationsplaneintrags
item: Referenz auf den Planeintrag 1
Der ELGA-Teilnehmer kann via ELGA-Portal den aktuellen, einzelne oder alle historischen Medikationsplanversionen unwiderruflich löschen.
Hierfür markiert der Patient die zu löschenden Medikationspläne und führt über das Portal ein $plan-delete aus, mit dem Resultat, dass alle betreffenden Collection Bundles durch die Fachanwendung gelöscht werden.