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
Im folgenden Kapitel werden die fachlichen Anwendungsfälle in Form technischer Use Cases beschrieben. Die zugehörigen Sequenzdiagramme veranschaulichen die beteiligten Akteure sowie die jeweiligen Abläufe.
Für jeden Use Case werden in den Kapiteln Relevante Elemente die wichtigsten Elemente der verwendeten Profile beschrieben. Dies ermöglicht eine kompakte Übersicht über die erforderlichen Anpassungen der Ressourcen im Kontext des jeweiligen Anwendungsfalls.
Die initiale Erstellung des Medikationsplans erfolgt durch die e-Medikation-Fachanwendung.
Ruft ein GDA den Medikationsplan eines Patienten zum Zweck der Bearbeitung ab ($readtowrite), prüft die Fachanwendung, ob bereits ein Medikationsplan vorhanden ist: existiert noch kein Plan, wird dieser im Hintergrund automatisch initial angelegt (siehe Read-to-Write-Zugriff).
Der GDA erhält in diesem Fall ein Collection Bundle mit einem leeren Medikationsplan (List) mit emptyReason notstarted zurück. Der enthaltene list.identifer dient der zur späteren Integritätsprüfung beim Schreibvorgang.
Dieser Status emptyReason kennzeichnet ausschließlich den Initialzustand (keine Einträge im Medikationsplan) und trifft keine Aussage darüber, ob der Patient Medikamente einnimmt.
Auch der Patient kann die Erstellung eines Medikationsplans auslösen, indem er diesen über das ELGA Portal aufruft (siehe auch Read-to-Write-Zugriff).
AtEmedListMedikationsplan
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
Ein leerer Medikationsplan mit dem Wert emptyReason nilknown bedeutet, dass der Patient derzeit keine Medikamente einnehmen soll. Der Medikatonsplan erhält diesen Status, wenn:
Dient der Unterscheidung von Medikationsplänen, die noch nie befüllt wurden, und solchen, die explizit dokumentieren, dass der Patient keine Medikamente einnehmen soll.
AtEmedListMedikationsplan
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 $readtowrite aus und bearbeitet das von der Fachanwendung übermittelte Collection Bundle:
Im Anschluss übermittelt der GDA (via POST $write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Anmerkung: Beim nächsten Read-to-Write ändert die Fachanwendung im zur Auslieferung bereitgestellten Collection Bundle den Status der Einträge mit new automatisch auf unchanged.
Siehe Read-to-Write-Zugriff und Write-Zugriff.
AtEmedListMedikationsplan
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"
AtEmedMRPlaneintrag
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 $readtowrite 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 $write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Siehe Read-to-Write-Zugriff und Write-Zugriff.
AtEmedListMedikationsplan
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
AtEmedMRPlaneintrag
// 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 $readtowrite aus und bearbeitet das von der Fachanwendung übermittelte Collection Bundle:
Im Anschluss übermittelt der GDA (via POST $write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Anmerkung: Beim nächsten Read-to-Write ändert die Fachanwendung im zur Auslieferung bereitgestellten Collection Bundle den Status der Einträge mit changed automatisch auf unchanged.
Siehe Read-to-Write-Zugriff und Write-Zugriff.
AtEmedListMedikationsplan
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
AtEmedMRPlaneintrag
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 $readtowrite aus und bearbeitet das von der Fachanwendung übermittelte Collection Bundle:
Der GDA übermittelt (via POST $write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Anmerkung: Beim nächsten Read-to-Write ändert die Fachanwendung im zur Auslieferung bereitgestellten Collection Bundle den Status der Einträge mit changed automatisch auf unchanged.
Siehe Read-to-Write-Zugriff und Write-Zugriff.
AtEmedListMedikationsplan
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
AtEmedMRPlaneintrag
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 Read-to-Write-Zugriff nicht mehr im Medikationsplan enthalten.
Hierfür führt der GDA ein $readtowrite aus und bearbeitet das von der Fachanwendung übermittelte Collection Bundle:
Der GDA übermittelt (via POST $write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Siehe Read-to-Write-Zugriff und Write-Zugriff.
Relevante Elemente (List)
AtEmedListMedikationsplan
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
AtEmedMRPlaneintrag
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 Read-to-Write-Zugriff nicht mehr im Medikationsplan enthalten.
Hierfür führt der GDA ein $readtowrite aus und bearbeitet das von der Fachanwendung übermittelte Collection Bundle:
Der GDA übermittelt (via POST $write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Siehe Read-to-Write-Zugriff und Write-Zugriff.
AtEmedListMedikationsplan
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
AtEmedMRPlaneintrag
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 Read-to-Write-Zugriff 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 Read-to-Write-Zugriff nicht mehr im Medikationsplan enthalten.
Um Planeinträge zu beenden bearbeitet der GDA nach einem $readtowrite das von der Fachanwendung übermittelte Collection Bundle wie folgt:
Der GDA übermittelt (via POST $write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Siehe Read-to-Write-Zugriff und Write-Zugriff.
AtEmedListMedikationsplan
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
AtEmedMRPlaneintrag
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 $readtowrite aus und bearbeitet das von der Fachanwendung übermittelte Collection Bundle:
Der GDA übermittelt (via POST $write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Siehe Read-to-Write-Zugriff und Write-Zugriff.
In folgendem Beispiel wird der ursprünglich 2. Eintrag als 1. gereiht.
AtEmedListMedikationsplan
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
AtEmedMRPlaneintrag
// 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 $readtowrite 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 Read-to-Write-Zugriff und Patient-Write-Zugriff.
Zustand vor dem Löschen des 2. Planeintrags (Ergebnis von $readtowrite):
AtEmedListMedikationsplan
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):
AtEmedListMedikationsplan
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.