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 aktuellen Medikationsplan eines ELGA-Teilnehmers bzw. einer ELGA-Teilnehmerin bearbeiten.
Ein:e ELGA-Teilnehmer:in kann über das Zugangsportal
Alle Schreibvorgänge auf dem aktuellen 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 des GDAs 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.
Der GDA kann dem Medikationsplan ein oder mehrere Planeinträge hinzufügen. Dabei muss er dokumentieren, ob dieser von ihm selbst stammt oder er Fremdmedikation (durch einen anderen GDA) bzw. Eigenmedikation des Patienten dokumentiert.
Hierfür führt der GDA ein $plan-read aus und bearbeitet die von der Fachanwendung im Medikationsplan-Searchset-Bundle bereitgestellten Ressourcen:
Das Element List.date wird auf den Zeitpunkt der Änderung aktualisiert.
Im Anschluss übermittelt der GDA mit POST $plan-write den aktualisierten Medikationsplan in einem Transaction Bundle:
AtElgaEmedListMedikationsplan
status: current
mode: working
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
identifier: neue Planeintrag-ID
status: active | on-hold
intent: order // fester Wert
category: "Planeintrag" // fester Wert
reportedBoolean: true | false // true, wenn Fremdmedikation
medicationReference.reference: Medikation mit PZN oder Magistrale Anwendung // 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)
Im Weiteren wird beschrieben, wie Planeinträge bearbeitet werden können. Das Sequenzdiagramm zeigt den allgemeinen Ablauf.
Der GDA kann im Medikationsplan ein oder mehrere Planeinträge ändern.
Die Änderung des Planeintrag kann alle Inhalte umfassen, z.B.: Änderung des Status (pausieren/aktivieren), Änderung des Einnahmezeitraums, der Dosierung oder der Medikation. Bei fehlender fachlicher Kontinuität der Bearbeitung eines Planeintrages (z.B. Änderung des Arzneimittels von Blutdruckmittel auf Antibiotikum) SOLL ein neuer Planeintrag erfasst und kein bestehender Eintrag weiterverwendet werden.
Um Planeinträge zu ändern, führt der GDA ein $plan-read aus und bearbeitet die von der Fachanwendung bereitgestellten Ressourcen:
Der GDA übermittelt (via POST $plan-write) den aktualisierten Medikationsplan in einem Transaction Bundle:
AtElgaEmedListMedikationsplan
status: current
mode: working
date: Datum der Bearbeitung des Medikationsplans
source: Veranwortlicher GDA
entry[0]: // 1. Planeintrag wird geändert
flag: changed
date: Datum der Änderung des Planeintrags // in diesem Fall gleich mit dem Datum der Bearbeitung des Medikationsplans
item: Referenz auf den Planeintrag 1
entry[1]: // 2. Planeintrag bleibt unverändert
flag: unchanged
date: Datum der Aufnahme des Planeintrags // in diesem Fall unterschiedlich mit dem Datum der Bearbeitung des Medikationsplans
item: Referenz auf den Planeintrag 2
AtElgaEmedMedicationRequestPlaneintrag
identifier: Planeintrag-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 Planeintrags
requester: für die Änderung verantwortlicher GDA
dosageInstruction: Änderung betreffend Dosierung + Einnahmezeitraum (ab sofort | in der Zukunft)
priorPrescription: Referenz auf ersetzten Planeintrag
Siehe Allgemeiner Ablauf - Planeinträge bearbeiten.
Der GDA kann ein oder mehrere Planeinträge im Medikationsplan beibehalten und unverändert zur Kennntis nehmen.
Hierfür führt der GDA ein $plan-read aus und bearbeitet die von der Fachanwendung im Medikationsplan-Searchset-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
item: Referenz auf den Planeintrag 1
AtElgaEmedMedicationRequestPlaneintrag
// unverändert (verantwortlicher GDA, Datum, Status bleiben bestehen)
Siehe Allgemeiner Ablauf - Planeinträge bearbeiten.
Ein GDA kann die Therapie eines Patienten vorübergehend unterbrechen (die Wiederaufnahme ist vorgesehen). Eine Freitext-Begründung kann dokumentiert werden.
Hierfür führt der GDA ein $plan-read aus und bearbeitet die von der Fachanwendung im Medikationsplan-Searchset-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 Bundle den Status der Einträge mit 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
identifier: Planeintrag-ID bleibt bestehen
status: on-hold
statusReason.text: Freitextbegrüdung // optional
reportedBoolean: true | false // true, wenn Fremdmedikation
authoredOn: Datum der Pausierung des Planeintrags
requester: für die Pausierung verantwortlicher GDA
priorPrescription: Referenz auf ersetzten Planeintrag
Siehe Allgemeiner Ablauf - Planeinträge bearbeiten.
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:
Der GDA übermittelt ein Medikationsplan-Transaction-Bundle mit:
AtElgaEmedListMedikationsplan
status: current
mode: working
date: Datum der Bearbeitung
source: veranwortlicher GDA
emptyReason: nilknown // Patient nimmt derzeit kein Medikation ein
Siehe Allgemeiner Ablauf - Planeinträge bearbeiten.
Der GDA kann einen oder mehrere Planeinträ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 die von der Fachanwendung im Medikationsplan-Searchset-Bundle bereitgestellten Ressourcen:
Der GDA übermittelt (via POST $plan-write) den aktualisierten Medikationsplan in einem Transaction Bundle:
Relevante Elemente (List)
AtElgaEmedListMedikationsplan
status: current
mode: working
date: Datum der Bearbeitung des Medikationsplans
source: Veranwortlicher GDA
entry[0]: // 1. Planeintrag wird storniert
flag: removed
item: Referenz auf den Planeintrag 1
entry[1]: // 2. Planeintrag bleibt unverändert
flag: unchanged
item: Referenz auf den Planeintrag 2
AtElgaEmedMedicationRequestPlaneintrag
identifier: Planeintrag-ID bleibt bestehen
status: entered-in-error
reportedBoolean: false // Fremdmedikation
authoredOn: Datum der Stornierung des Planeintrags
requester: für die Stornierung verantwortlicher GDA
priorPrescription: Referenz auf ersetzten Planeintrag
Siehe Allgemeiner Ablauf - Planeinträge bearbeiten.
Der GDA kann ein Medikament, welches in einen Planeintrag dokumentiert ist, absetzen. 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 die von der Fachanwendung im Medikationsplan-Searchset-Bundle bereitgestellten Ressourcen:
Der GDA übermittelt (via POST $plan-write) den aktualisierten Medikationsplan in einem Transaction Bundle:
AtElgaEmedListMedikationsplan
status: current
mode: working
date: Datum der Bearbeitung des Medikationsplans
source: Veranwortlicher GDA
entry[0]: // 1. Planeintrag wird abgesetzt
flag: removed
item: Referenz auf den Planeintrag 1 // siehe "Planeintrag ändern"
entry[1]: // 2. Planeintrag bleibt unverändert
flag: unchanged
item: Referenz auf den Planeintrag 2
AtElgaEmedMedicationRequestPlaneintrag
identifier: Planeintrag-ID bleibt bestehen
status: stopped
statusReason.text: Freitextbegrüdung für das Absetzen des Medikaments //verpflichtende Angabe!
reportedBoolean: false // Fremdmedikation
authoredOn: Datum des Absetzens des Planeintrags
requester: für das Absetzen verantwortlicher GDA
priorPrescription: Referenz auf ersetzten Planeintrag
Siehe Allgemeiner Ablauf - Planeinträge bearbeiten.
Der GDA kann die Reihenfolge der Planeinträge ändern. Die Einträge selbst bleiben dabei unverändert.
Hierfür führt der GDA ein $plan-read aus und bearbeitet die von der Fachanwendung im Medikationsplan-Searchset-Bundle bereitgestellten Ressourcen:
Der GDA übermittelt mittels POST $plan-write den aktualisierten Medikationsplan in einem Transaction Bundle:
In folgendem Beispiel wird der ursprünglich 2. Eintrag als 1. gereiht.
AtElgaEmedListMedikationsplan
status: current
mode: working
date: Datum der Änderung der Reihenfolge
source: 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 bestehen)
Siehe Allgemeiner Ablauf - Planeinträge bearbeiten.
Der:die ELGA-Teilnehmer:in kann via Zugangsportal in der aktuellen Version seines:ihres Medikationsplans einzelne oder alle Planeinträge unwiderruflich löschen. Durch das Löschen wird durch die Fachanwendung eine neue Medikationsplanversion erzeugt. Wurden alle Planeinträge gelöscht, erhält die neue Medikationsplanversion das emptyReason nilknown (siehe Sub_UC_eMed_02_02 - Leerer Medikationsplan (keine Medikation einnehmen)).
Hierfür ruft der:die ELGA-Teilnehmer:in zunächst den aktuellen Medikationsplan mittels $plan-read ab und wählt die zu löschenden Planeinträge aus. Das Zugangsportal erstellt anschließend ein Transaction-Bundle und:
Das Transaction Bundle wird mittels POST $plan-write an die Fachanwendung übermittelt. Bei erfolgreicher Prüfung erzeugt und persistiert die Fachanwendung daraus eine neue Medikationsplanversion und führt die DELETE-Requests aus. Die betreffenden MedicationRequest-Ressourcen einschließlich ihrer versionierten Ausprägungen werden dadurch vollständig gelöscht.
Im Unterschied zum Stornieren oder Beenden durch den GDA wird der Planeintrag somit vollständig aus List.entry entfernt und die zugehörige MedicationRequest nicht lediglich als removed gekennzeichnet.
Historische Medikationsplanversionen oder bestehende Geplante bzw. Durchgeführte Abgaben können weiterhin Referenzen auf die gelöschten Planeinträge enthalten. Diese Referenzen sind nach dem vollständigen Löschen der MedicationRequest nicht mehr auflösbar.
Zustand vor dem Löschen des 2. Planeintrags (Ergebnis von $plan-read):
AtElgaEmedListMedikationsplan
status: current
mode: working
date: Datum der vorhergehenden Bearbeitung des Medikationsplans
source: veranwortlicher GDA der vorhergehenden Bearbeitung
entry[0]:
flag: unchanged
item: Referenz auf den Planeintrag 1
entry[1]:
flag: unchanged
item: Referenz auf den Planeintrag 2
Zustand nach dem Löschen des 2. Planeintrags (List-Ressource im Transaction Bundle von $patient-plan-write):
AtElgaEmedListMedikationsplan
status: current
mode: working
date: Datum des Löschens des Medikationsplans durch den:die ELGA-Teilnehmer:in
source: ELGA-Teilnehmer:in
entry[0]: // 1. Planeintrag bleibt unverändert
flag: unchanged
item: Referenz auf den Planeintrag 1
In Arbeit.
Offene Fragen: Gelöschte Planeinträge können von historischen Planversionen oder bestehenden Geplanten bzw. durchgeführten Abgaben referenziert werden. Diese Referenzen sind nach dem Löschen nicht mehr auflösbar. - Mögliche Lösung: Vor dem Löschen prüfen, ob der Planeintrag von anderen Medikationsplanversionen, geplanten oder durchgeführten Abgaben referenziert wird, und gegebenenfalls eine Bestätigung des:der ELGA-Teilnehmers:in einholen.
Der:die ELGA-Teilnehmer:in kann über das Zugangsportal die aktuelle Medikationsplanversion sowie einzelne oder mehrere historische Medikationsplanversionen unwiderruflich löschen.
Hierfür muss der:die ELGA-Teilnehmer:in zunächst mittels Plan-History-Search oder Plan-History-Directory-Search über das Zugangsportal die betreffenden Medikationsplanversionen bzw. deren Identifikatoren ermitteln. Anschließend markiert der:die ELGA-Teilnehmer:in die zu löschenden Medikationsplanversionen und führt über das Zugangsportal ein $plan-delete aus.
Beim Löschen einer Medikationsplanversion wird die betreffende List-Ressource gelöscht, einschließlich auch die von der Medikationsplanversion referenzierten versionierten Planeinträge (MedicationRequest-Ressourcen).
In Arbeit.
Offene Fragen zur Löschlogik: - Sollen beim Löschen einer Medikationsplanversion auch die darin referenzierten Planeinträge gelöscht werden, wenn sie von einer anderen, weiterhin bestehenden Medikationsplanversion oder von Geplanten bzw. Durchgeführten Abgaben referenziert werden? Die Referenz wäre dann nicht mehr auflösbar. Mögliche Lösung: Vor dem Löschen prüfen, ob die referenzierten Planeinträge von anderen Ressourcen referenziert werden, und gegebenenfalls eine Bestätigung des:der ELGA-Teilnehmers:in einholen. - Was geschieht beim Löschen der aktuellen Medikationsplanversion? Wird die zuvor zuletzt gespeicherte Medikationsplanversion wieder zur aktuellen Version oder beginnt der:die ELGA-Teilnehmer:in mit einem leeren Medikationsplan (emptyReason = notstarted)?