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
Der GDA (Apotheke bzw. Arzt mit Hausapotheke) dokumentiert die Abgabe eines Arzneimittels für einen ELGA-Teilnehmer in einer Durchgeführten Abgabe:
Die unterschiedlichen Arten der Abgabe und deren Abfolge sind dargestellt unter Durchgeführte Abgabe - Varianten der (Teil-)Abgabe).
Eine vollständige Einzelabgabe liegt vor, wenn die in der Geplanten Abgabe verordneten Arzneimenge vollständig abgegeben wird (existiert keine zugehörige Geplante Abgabe gilt Sub_UC_eMed_09_01_05 - Durchgeführte Abgabe ohne Bezug zu einer Geplanten Abgabe erfassen).
Bei einer vollständigen Einzelabgabe MUSS eine Durchgeführte Abgabe wie folgt erstellt werden:
Existiert eine zugehörige Geplante Abgabe prüft die Fachanwendung anhand MedicationRequest.numberOfRepeatsAllowed ob weitere Einlösungen erlaubt sind (z.B. bei einem Privatrezept). Ist nur eine einmalige Einlösung möglich (z.B. Kassenrezept), setzt die Fachanwendung die Geplanten Abgabe auf den Status completed.
Ermöglicht die Geplante Abgabe mehrere Einlösungen (MedicationRequest.numberOfRepeatsAllowed > 0), wird je Einlösung eine Durchgeführte Abgabe erstellt. Der Status der Geplanten Abgabe bleibt solange active, bis die letztmögliche Einlösung erfolgt ist (sieheSub_UC_eMed_08_02 - Geplante Abgabe beenden (durch Fachanwendung)).
AtElgaEmedMedicationDispenseDurchgefuehrteAbgabe
recorded: Datum der Erstellung der Durchgeführten Abgabe
status: completed
medicationReference.reference: Tatsächlich abgegebenes Medikament // Contained Medication
subject: Patient
performer: veranwortlicher GDA (Apotheke) für die Durchgeführte Abgabe
authorizingPrescription[geplanteabgabe]: Verpflichtende Referenz auf zugehörige Geplante Abgabe
authorizingPrescription[planeintrag]: Verpflichtende Referenz auf Planeintrag
type: FFC (First Fill - Complete) // Art der Abgabe
quantity: Abgegebene Packungen // Packungen je Einlösung
whenHandedOver: Zeitpunkt der Arzneimittelaushändigung
dosageInstruction: optional Dosierung + Einnahmezeitraum (ab sofort | in der Zukunft) // angepasst an abgegebene Medikation
Eine Teilabgabe liegt vor, wenn die in der Geplanten Abgabe verordneten Arzneimenge nicht vollständig abgegeben wird, weil nur ein Teil der verordneten Arzneimenge eingelöst werden soll oder kann.
Sonderfälle von Teilabgaben sind Besorgerprozess (siehe Sub_UC_eMed_09_01_03 - Besorgerprozess) und Leerabgabe (siehe Sub_UC_eMed_09_01_05 Leerabgabe erfassen).
Für jede Teilabgabe MUSS eine Durchgeführte Abgabe erstellt werden. Dabei gelten folgende Regeln:
Die Gültigkeit einer Geplanten Abgabe verlängert sich im Zuge von Teilabgaben (siehe Gültigkeit von Geplanten Abgaben basierend auf der Rezeptart).
Sobald eine Teilabgabe durchgeführt wurde (Part Fill), ist die Einlösung einer weiteren Teilabgabe in einer anderen Apotheke nicht mehr möglich, d.h. die Apotheke MUSS die Teilabgaben mit einem complete abschließen.
Vor dem Speichern einer neuen Durchgeführten Abgabe MUSS die Fachanwendung prüfen,
Der Status der Geplanten Abgabe bleibt active, solange weitere Einlösungen zulässig sind. Sind keine weiteren Einlösungen mehr möglich, setzt die Fachanwendung den Status der Geplanten Abgabe auf completed.
Um die durch MedicationDispense.type definierte Sequenz FFP → RFP → RFC konsistent zu halten, darf immer nur die zuletzt gespeicherte Durchgeführte Abgabe verworfen werden. Mehrere Durchgeführte Abgaben können nur sequenziell in umgekehrter Reihenfolge ihrer Erstellung verworfen werden.
AtElgaEmedMedicationDispenseDurchgefuehrteAbgabe
recorded: Datum der Erstellung der Durchgeführten Abgabe
status: completed
medicationReference.reference: Tatsächlich abgegebenes Medikament // Contained Medication
subject: Patient
performer: veranwortlicher GDA (Apotheke) für die Durchgeführte Abgabe
authorizingPrescription[geplanteabgabe]: Verpflichtende Referenz auf zugehörige Geplante Abgabe
authorizingPrescription[planeintrag]: Verpflichtende Referenz auf Planeintrag
type: FFC (First Fill - Complete) | (Refill - Part Fill) // 1. Teilabgabe, weitere Teilabgabe bestellen
quantity: Abgegebene Packungen // je Teilabgabe
whenHandedOver: Der Zeitpunkt, zu dem das abgegebene Produkt ausgehändigt wurde
dosageInstruction: optional Dosierung + Einnahmezeitraum (ab sofort | in der Zukunft) // angepasst an abgegebene Medikation
Ein Besorgerprozess liegt vor, wenn das in der Geplanten Abgabe verordnete Arzneimittel bestellt oder zubereitet werden muss (es findet noch keine Abgabe statt). Die Geplanten Abgabe kann daraufhin nicht mehr in einer anderen Apotheke eingelöst werden.
Entsprechend den Regeln für Teilabgaben MUSS eine Durchgeführte Abgabe wie folgt erstellt werden:
Wird das bestellte/zubereitete Arzneimittel ausgehändigt, wird dies in Form einer Teilabgabe mit der abgegebenen Menge dokumentiert, siehe Sub_UC_eMed_09_01_02 - Teilabgaben erfassen. Die MedicationDispense.type-Sequenz FFP → RFP → RFC muss dabei konsistent gehalten werden.
Im Fall einer Bestellung mit gleichzeitiger Teilabgabe wird nur die Teilabgabe dokumentert.
Der Status der Geplanten Abgabe bleibt während des Besorgerprozesses active.
Mit einer Leerabgabe dokumentiert der GDA (Apotheker bzw. Arzt mit Hausapotheke), dass der Patient ein Arzneimittel einer Geplanten Abgabe nicht benötigt. Hierfür erstellt er eine Durchgeführte Abgabe wie folgt:
Die Anzahl der möglichen Einlösungen einer Geplanten Abgabe reduziert sich nach einer Leerabgabe, d.h. sie bleibt weiterhin active bis die restlichen möglichen Einlösungen erfolgt sind oder sie zeitlich abläuft. Nur wenn alle möglichen Einlösungen mit cancelled gespeichert wurden, wird die zugehörige Geplante Abgabe automatisch auf cancelled gesetzt, sonst auf completed.
In folgenden Fällen liegt bei der Erfassung einer Durchgeführten Abgabe keine zugehörige Geplante Abgabe vor:
Analog zu Sub_UC_eMed_09_01_01 - Vollständige Einzelabgabe erfassen gilt bei der Erstellung der Durchgeführten Abgabe:
Sofern für die Durchgeführten Abgabe im nachhinein ein Planeintrag erstellt wird, KANN mit $reference-plan der Planeintrag (in MedicationDispense.authorizingPrescription[planeintrag]) referenziert werden.
Bei der Nacherfassung bereits abgegebener Arzneimittel (z.B. wenn eine Speicherung zum Zeitpunkt der Abgabe aus technischen Gründen nicht möglich war oder bei Arzneimittelbezug aus dem Ausland), wird als Erfassungsdatum der Zeitpunkt der Nacherfassung gesetzt, während als Abgabedatum das tatsächliche Datum der Abgabe in der Vergangenheit eingetragen wird.
Alle weiteren Elemente sind entsprechend der Abgabeart zu befüllen.
AtElgaEmedMedicationDispenseDurchgefuehrteAbgabe
recorded: Datum der Nacherfassung
whenHandedOver: Der Zeitpunkt, zu dem das abgegebene Produkt ausgehändigt wurde
Eine Substitution eines Arzneimittels ist nur implizit ersichtich, durch die Referenz auf die zugehörige Geplante Abgabe bzw. den Planeintrag.
Ein GDA (Apotheke) kann von ihm erstellte Durchgeführte Abgaben, die sich im Status completed oder cancelled befinden, aufgrund eines Fehlers verwerfen.
Um eine Durchgeführte Abgabe zu verwerfen, ruft der GDA diese mittels GET MedicationDispense ab und bearbeitet diese wie folgt:
Eine verworfene Durchgeführte Abgabe kann nicht mehr bearbeitet werden und ist nur noch aber über die Historie einsehbar. Wenn eine verworfene Durchgeführte Abgabe Teil eines e-Rezepts mit weiteren Geplanten Abgaben ist (gleicher e-Med GroupIdentifier), wirkt sich dies nicht auf den Status der anderen Geplanten Abgaben aus.
Der ELGA-Teilnehmer kann eine Durchgeführte Abgabe endgültig löschen.
Die Löschung der Durchgeführten Abgabe umfasst:
Zum Löschen einer Durchgeführte Abgabe ruft der ELGA-Teilnehmer die betreffende Durchgeführte Abgabe im ELGA-Portal auf. Dieses führt zunächst eine Leseoperation auf die betreffende MedicationDispense-Ressource aus (GET MedicationDispense/[id]) und löscht anschließend die betreffende Geplante Abgabe mittels DELETE (DELETE [base]/MedicationDispense/[id]).
Die Ressource einschließlich aller historischen Versionen darf nach erfolgreicher Löschung weder über reguläre FHIR-Interaktionen noch über administrative Schnittstellen abrufbar sein.