ELGA e-Medikation (R4) DRAFT
0.1.1 - ci-build

​Technische Use Cases für Geplante Abgabe schreiben (UC_eMed_08)

Sub_UC_eMed_08_01 - Geplante Abgabe erfassen

Ein GDA kann basierend auf einem bestehenden Medikationsplaneintrag eine oder mehrere Geplanten Abgaben erstellen. Je verordnetes Medikament muss eine Geplante Abgabe erstellt werden.

Sollte für eine Geplante Abgabe noch kein Medikationsplaneintrag existieren, muss dieser zuerst erstellt werden (siehe Sub_UC_eMed_06_03 - Medikationsplaneintrag in Medikationsplan hinzufügen). Bei Bedarf kann ein bestehender Medikationsplaneintrag angepasst werden (siehe Sub_UC_eMed_06_06 - Medikationsplaneintrag im Medikationsplan ändern).

Ist keine Anpassung des Medikationsplaneintrags erforderlich, führt der GDA ein $plan-read aus und erhält von der Fachanwendung das Auslieferungs-Collection-Bundle, das den Medikationsplan mit allen relevanten Ressourcen enthält.

Basierend auf darin vorhandenen Planeinträgen erstellt der GDA neue Geplante Abgaben wie folgt:

  • Der Status der neuen geplanten Abgabe muss offen sein (active, siehe Status des MedicationRequests in der geplanten Abgabe)
  • Die Rezeptart muss verpflichtend ausgewählt werden (Kassenrezept, Privatrezept oder Substitutionsrezept)
  • Die Medikation soll fachlich jener des Planeintrags entsprechen. Enthält der Planeintrag ausschließlich Wirkstoffe, ist verpflichtend ein entsprechendes Medikament aus der ASP-Liste (inkl. PZN) bzw. eine magistrale Zubereitung zu dokumentieren.
  • Werden mehrere Medikamente gleichzeitig verordnet und sollen demselben e-Rezept zugeordnet werden, muss jede erstellte Geplante Abgabe mit demselben groupIdentifier versehen werden. Mithilfe dieser eindeutigen Kennung ('Rezept-Klammer') können berechtigte Akteure später gezielt nach zusammengehörenden Geplanten Abgaben suchen. Der hierfür verwendete e-Med GroupIdentifier kann über unterschiedliche Varianten bezogen werden (siehe Ablauf und Bezug e-Med GroupIdentifier). In einem Bundle dürfen nur Geplanten Abgaben mit dem gleichen e-Med GroupIdentifier enthalten sein.
  • Dosierangaben können optional angepasst werden.
  • Abhängig von der ausgewählten Rezeptart (siehe Gültigkeit von Geplanten Abgaben basierend auf der Rezeptart) können:
    • der Gültigkeitszeitraum (dispenseRequest.validityPeriod), innerhalb dessen die Geplante Abgabe eingelöst werden kann, sowie
    • die Anzahl möglicher weiterer Einlösungen (dispenseRequest.numberOfRepeatsAllowed) festgelegt werden
  • Die Menge (Anzahl Packungen), die bei jeder Abgabe bereitgestellt werden soll, ist verpflichtend zu dokumentieren (dispenseRequest.quantity).

​Die erstellten Geplanten Abgaben werden in einem Bundle vom Typ Transaction mittels Prescription-Write an die Fachanwendung übermittelt wird.

Ablauf und Bezug e-Med GroupIdentifier

Der Ablauf zur Erstellung von Geplanten Abgaben und der Bezug des e-Med GroupIdentifiers kann unterschiedlich erfolgen. Exemplarisch werden 3 Varianten angeführt.

Variante A: Vorab-Ermittlung des e-Med GroupIdentifiers

​Der e-Med GroupIdentifier ("Rezeptklammer") wird via POST $groupidentifier-create vorab von der Fachanwendung bezogen, in den Geplanten Abgaben ergänzt und zur Erstellung des e-Rezepts an die e-Rezept-Anwendung mitgegeben, um dieses mit den Geplanten Abgaben zu verknüpfen. Der Trigger zu Erstellung des e-Rezepts und Prescription-Write können parallel erfolgen (siehe Normalfall).

Liefert e-Rezept einen Fehler zurück, können mittels POST $prescription-discard bereits in der e-Medikation erstellte Geplante Abgaben verworfen werden (siehe Sub_UC_eMed_08_04 - Geplante Abgabe verwerfen). Liefert die e-Medikation Fachanwendung einen Fehler zurück, kann nach Fehlerkorrektur erneut ein Prescription-Write erfolgen oder ein bereits durch den e-Med groupIdentifer verknüpftes e-Rezept wieder von den Geplanten Abgaben "entkoppelt" werden (siehe Fehlerfall).

Variante A: Normalfall


Geplante Abgabe für bestehende Medikationsplaneinträge erstellenVariante A: Vorab-Ermittlung des GroupIdentifiers (Normalfall)GDA 1e-Med FAe-Med FAe-RezeptGDA 1e-Med FAe-RezeptGDA 1GDA 1e-Med FAe-Med FAe-Rezepte-RezeptGDA 1e-Med FAe-Med FAe-RezeptMedikationsplan abrufenrefPlan-ReadGDA erhält Medikationsplan(Auslieferungs-Collection-Bundle)Geplante Abgabenvorbereiten und schreiben1POST $groupidentifier-create​e-Med GroupIdentifier für"Rezeptklammer" anfordern2e-Med GroupIdentifier erzeugen3e-Med GroupIdentifierErstellteGeplante Abgabenreferenzierenzugehörige Medikationsplaneinträge undenthalten e-Med GroupIdentifierpar[Erstellung e-Rezept]4Trigger e-Rezept erstellen5OK[gleichzeitige ErstellungGeplante Abgabe]6POST $prescription-writeTransaction Bundle mit GeplantenAbgaben an Fachanwendung übermitteln7OKGeplante Abgabenerstellt


Variante A: Fehlerfall


Geplante Abgabe für bestehende Medikationsplaneinträge erstellenVariante A: Vorab-Ermittlung des GroupIdentifiers (Fehlerfall)GDA 1e-Med FAe-Med FAe-RezeptGDA 1e-Med FAe-RezeptGDA 1GDA 1e-Med FAe-Med FAe-Rezepte-RezeptGDA 1e-Med FAe-Med FAe-RezeptMedikationsplan abrufenrefPlan-ReadGDA erhält Medikationsplan(Auslieferungs-Collection-Bundle)Geplante Abgabenvorbereiten und schreiben1POST $groupidentifier-create​e-Med GroupIdentifier für "Rezeptklammer"anfordern2e-Med GroupIdentifier erzeugen3e-Med GroupIdentifierErstellteGeplante Abgabenreferenzierenzugehörige Medikationsplaneinträge undenthalten e-Med GroupIdentifierpar[Erstellung e-Rezept]4Trigger e-Rezept erstellenErstellung e-Rezept auslösenalt[e-Rezept erstellt]5OK[e-Rezept Fehler]6Fehler7POST $prescription-discard​Siehe Use Case "Geplante Abgabeverwerfen"[gleichzeitige ErstellungGeplante Abgabe]8POST $prescription-writeTransaction Bundle mit GeplantenAbgaben an Fachanwendung übermittelnalt[Geplante Abgabeerstellt]9OKGeplante Abgabe 1 + 2 gespeichert[Geplante AbgabeFehler]10Fehleralt[Geplante Abgabe erneut übermitteln]11POST $prescription-write[Fehler nicht behebbar]12e-Rezept von e-Med GroupIdentifier entkoppeln


Variante B: Sequentielles Erstellen von Geplanter Abgabe und e-Rezept

Alternativ kann der e-Med GroupIdentifier durch die Fachanwendung automatisch ergänzt werden, wenn dieser beim Prescription-Write nicht in den Geplanten Abgaben im Transaction Bundle enthalten ist. Dadurch bleibt das Verhalten konsistent zur bestehenden e-Medikations-Implementierung. Hierfür müssen die Geplanten Abgaben zuerst an die e-Medikation Fachanwendung übermittelt werden. Der Server ergänzt den e-Med GroupIdentifier während der Transaktionsverarbeitung. Die persistierten Ressourcen einschließlich des erzeugten groupIdentifiers werden im Response an den Client zurückgegeben. Im Anschluss kann der Trigger zur Erstellung des e-Rezepts inkl. e-Med GroupIdentifier erfolgen.


Geplante Abgabe für bestehende Medikationsplaneinträge erstellenVariante B: Sequentielles Erstellen von Geplanter Abgabe und e-RezeptGDA 1e-Med FAe-RezeptGDA 1e-Med FAe-RezeptGDA 1GDA 1e-Med FAe-Med FAe-Rezepte-RezeptGDA 1e-Med FAe-RezeptMedikationsplan abrufenrefPlan-ReadGDA erhält Medikationsplan(Auslieferungs-Collection-Bundle)Geplante Abgaben vorbereiten und schreibenErstellteGeplante Abgabenreferenzierenzugehörige Medikationsplaneinträge;groupIdentifier für "Rezeptklammer"bleibt leer1POST Transaction Bundle GeplAbgabealt[Geplante Abgaben erstellt]2e-Med GroupIdentifier erzeugen+ in geplanten Abgaben ergänzenGeplante Abgabe 1 + 2 gespeichert3OK (Ressourcen inkl. e-Med GroupIdentifier)[Geplante Abgaben Fehler]4Fehler5Trigger e-Rezept erstellen (inkl. e-Med GroupIdentifier)Erstellung e-Rezept inkl.e-Med GroupIdentifier auslösenalt[e-Rezept erstellt]6OK[e-Rezept Fehler]7Fehler8Geplante Abgabeverwerfen ($discard)Siehe Use Case "Geplante Abgabeverwerfen"


Variante C: Nachträgliche Verknüpfung des e-Rezepts mit dem e-Med GroupIdentifier

​Der Trigger zu Erstellung des e-Rezepts und Prescription-Write können parallel erfolgen (Variante A), allerdings noch ohne e-Med GroupIdentifier. Die e-Medikation Fachanwendung ergänzt diesen und liefert ihn an den Client zurück (wie in Variante B), der Client führt im Anschluss eine nachträgliche Verknüfung des bereits erstellten e-Rezepts mit den geplanten Abgaben mittels e-Med GroupIdentifier durch.


Geplante Abgabe für bestehende Medikationsplaneinträge erstellenVariante C: Nachträgliche Verknüpfung des e-Rezepts mit dem e-Med GroupIdentifierGDA 1e-Med FAe-Rezepte-RezeptGDA 1e-Med FAe-RezeptGDA 1GDA 1e-Med FAe-Med FAe-Rezepte-RezeptGDA 1e-Med FAe-Rezepte-RezeptMedikationsplan abrufenrefPlan-ReadGDA erhält Medikationsplan(Auslieferungs-Collection-Bundle)Geplante Abgabenvorbereiten und schreibenErstellteGeplante Abgabenreferenzierenzugehörige Medikationsplaneinträge;groupIdentifier für "Rezeptklammer"bleibt leerpar[Erstellung e-Rezept]1Trigger e-Rezept erstellenErstellung e-Rezept auslösen,ohne e-Med GroupIdentifieralt[e-Rezept erstellt]2OK[e-Rezept Fehler]3Fehler[gleichzeitige ErstellungGeplante Abgabe]4POST Transaction Bundle GeplAbgabeTransaction Bundle mit GeplantenAbgaben an Fachanwendung übermittelnalt[Geplante Abgaben erstellt]5e-Med GroupIdentifier erzeugen+ geplanten Abgaben hinzufügenGeplante Abgabe 1 + 2gespeichert6OK (Ressourcen inkl. e-Med GroupIdentifier)[Geplante Abgabe Fehler]7Fehler8e-Rezept mit e-Med GroupIdentifier verknüpfen9e-Med GroupIdentifierergänzenBestehendes e-Rezept mite-Med GroupIdentifier verknüpft10OK


Relevante Elemente (MedicationRequest)

AtElgaEmedMedicationRequestGeplanteAbgabe
    status: active 
    category[mrcategory]: 2 "Geplante Abgabe"               //Kategorie zur Unterscheidung der MedicationRequests
    category[recipetype]: KASSEN | PRIVAT | SUBST          // Verpflichtende Angabe der Rezeptart
    intent: order                                           // Fester Wert
    medicationReference.reference: Medikation gemäß zugehörigem Planeintrag // Contained Medication
    authoredOn: Datum der Erstellung der Geplanten Abgabe
    requester: veranwortlicher GDA für die Geplante Abgabe  // wird auf Übereinstimmung mit List.source geprüft
    basedOn: id des zugehörigen Medikationsplaneintrags     // referenziert aktuelle Version 
    groupIdentifier: e-Med GroupIdentifier                  // optionale Rezeptklammer 
    dosageInstruction: Dosierung + Einnahmezeitraum (ab sofort | in der Zukunft) 
    dispenseRequest.validityPeriod: Gültigkeitszeitraum     // abhängig von Rezeptart bzw. verkürzt durch GDA
    dispenseRequest.numberOfRepeatsAllowed: Anzahl weiterer Einlösungen // abhängig von Rezeptart bzw. verkürzt durch GDA
    dispenseRequest.quantity: Abzugebende Menge (Packungen) je Abgabe

Sub_UC_eMed_08_04 - Geplante Abgabe verwerfen

Ein GDA kann von ihm erstellte Geplante Abgaben aufgrund eines Fehlers verwerfen, solange noch keine Abgaben durchgeführt wurden. Die verworfene Geplante Abgabe wird damit abgeschlossen, kann aber über die Historie der Geplanten Abgaben eingesehen werden.

​Um eine Geplante Abgabe zu verwerfen, führt der GDA die Operation $prescription-discard​ aus:

Relevante Elemente (MedicationRequest)

AtElgaEmedMedicationRequestGeplanteAbgabe
    status: entered-in-error 
    authoredOn: Datum des Verwerfens der Geplanten Abgabe
    requester: veranwortlicher GDA für das Verwerfen der Geplanten Abgabe

Sub_UC_eMed_08_02 - Geplante Abgabe beenden (durch Fachanwendung)

Wurden alle möglichen Einlösungen einer Geplanten Abgabe planmäßig durchgeführt (siehe Sub_UC_eMed_09_01 - Durchgeführte Abgabe erfassen), setzt die Fachanwendung die Geplante Abgabe automatisch auf den Status completed (siehe Status des MedicationRequests in der geplanten Abgabe). Die Geplante Abgabe ist damit abgeschlossen.

Sonderfall: Wenn die letzte durchgeführte Abgabe danach verworfen wird (Status entered-in-error), wird der Status der Geplanten Abgabe durch die Fachanwendung wieder auf active gesetzt.

Relevante Elemente (MedicationRequest)

AtElgaEmedMedicationRequestGeplanteAbgabe
    status: completed
    authoredOn: Datum der Erstellung der geplanten Abgabe  // bleibt unverändert
    requester: Ursprünglicher Ersteller                    // bleibt unverändert

Sub_UC_eMed_08_03 - Geplante Abgabe abgelaufen (durch Fachanwendung)

Ist der Einlösezeitraum der Geplanten Abgabe gemäß der ausgewählten Rezeptart (category:recipetype) oder den Einschränkungen des GDAs überschritten, setzt die Fachanwendung die Geplante Abgabe automatisch auf den Status stopped (siehe Status des MedicationRequests in der geplanten Abgabe). Die Geplante Abgabe ist damit abgeschlossen.

Relevante Elemente (MedicationRequest)

AtElgaEmedMedicationRequestGeplanteAbgabe
    status: stopped
    authoredOn: Datum der Erstellung der geplanten Abgabe  // bleibt unverändert
    requester: Ursprünglicher Ersteller                    // bleibt unverändert

Sub_UC_eMed_08_03 - Geplante Abgabe gecancelt (durch Fachanwendung)

Eine Geplante Abgabe erhält automatisch den Status cancelled (siehe Status des MedicationRequests in der geplanten Abgabe), wenn alle Durchgeführten Abgaben (jede Einlösung) den Status cancelled erhalten haben ("Leerabgabe", d.h. keine Abgabe durchgeführt). Die Geplanten Abgabe ist damit abgeschlossen.

Sonderfall: Wenn die letzte Durchgeführte Abgabe danach verworfen wird (Status entered-in-error), wird der Status der Geplanten Abgabe durch die Fachanwendung wieder auf active gesetzt.

Relevante Elemente (MedicationRequest)

AtElgaEmedMedicationRequestGeplanteAbgabe
    status: cancelled
    authoredOn: Datum der Erstellung der geplanten Abgabe  // bleibt unverändert
    requester: Ursprünglicher Ersteller                    // bleibt unverändert

Sub_UC_eMed_08_05 - Geplante Abgabe löschen (durch ELGA-Teilnehmer)

Der ELGA-Teilnehmer kann eine Geplante Abgabe endgültig löschen. Bereits dokumentierte zugehörige Durchgeführte Abgaben sowie bestehende Planeinträge bleiben davon unberührt.

Die Löschung der Geplanten Abgabe umfasst:

  • die fachliche Entfernung der betreffenden MedicationRequest-Ressource sowie
  • die Entfernung aller zugehörigen historischen Ressourcen-Versionen (_history).

Zum Löschen einer Geplanten Abgabe ruft der ELGA-Teilnehmer diese im ELGA-Portal auf. Dieses führt zunächst eine Leseoperation auf die betreffende MedicationRequest-Ressource aus (GET MedicationRequest/[id]) und löscht anschließend die betreffende Geplante Abgabe mittels DELETE (DELETE [base]/MedicationRequest/[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.