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 von ELGA-Teilnehmer:innen lesen.
Ein ELGA-Teilnehmer kann seinen Medikationsplan über das Zugangsportal einsehen.
Die fachlichen Anforderungen werden im UC_eMed_01 Medikationsplan lesen beschrieben.
Für den lesenden Zugriff auf Medikationspläne werden zwei Zugriffsarten unterschieden:
Plan-Read zum Abruf des aktuellen Medikationsplans, der für eine mögliche Bearbeitung aufbereitet ist.
Plan-History-Search zum Abruf historischer Versionen des Medikationsplans.
Sowohl berechtigte GDA als auch ELGA-Teilnehmer können auf einzelne Planeinträge lesend zugreifen und diese durchsuchen (Planentry-Search).
Plan-Read dient dem Abruf des Medikationsplans in einem für die Bearbeitung durch den GDA aufbereiteten Zustand.
Hierfür erzeugt die Fachanwendung aus der aktuellen Version der List-Ressource sowie den von ihr referenzierten Ressourcen ein temporäres Medikationsplan-Searchset-Bundle zur Auslieferung. Der Abruf erfolgt über die Custom Operation $plan-read.
POST $plan-read
Nachfolgend kann der Medikationsplan vom GDA bearbeitet und mittels Plan-Write gespeichert werden.
Offene Punkte:
Fehlercodes sind noch zu definieren.
Nach Eingang eines $plan-read prüft die Fachanwendung den Zustand des Medikationsplans.
Abschließend erzeugt die Fachanwendung aus der aktuellen Version der List-Ressource und den referenzierten Ressourcenversionen das Medikationsplan-Searchset-Bundle zur Auslieferung. Die persistierten Ressourcen am Server werden durch die Anpassungen im Auslieferungs-Bundle nicht verändert.
Dabei werden folgende Fälle unterschieden:
Beim Plan-History-Search rekonstruiert die Fachanwendung historische Versionen des Medikationsplans aus Versionen der List-Ressource sowie den von diesen referenzierten Ressourcenversionen und liefert diese unverändert aus.
Alle diese Ressourcen sind Teil des resultierenden Searchset-Bundles.
Offene Frage:
- Ist Plan-History-Search ein GET mit _include=* oder eine Custom Operation?
- Können bei einem GET _history beliebige Suchparameter definiert werden?
Der Abruf erfolgt mittels GET auf den List-Ressourcen-Endpunkt unter Angabe geeigneter Suchparameter:
Die erzeugten Medikationsplan-Searchset-Bundles dienen ausschließlich der Auslieferung und werden nicht persistiert.
Beim Plan-History-Search erfolgt keine Änderung der Medikationspläne durch die Fachanwendung. Insbesondere werden keine Inhalte, Statusinformationen oder Kennzeichnungen (Flags) verändert.
Der Zugriff dient ausschließlich der Anzeige bzw. Informationsabfrage persistierter Medikationsplanversionen.
In Arbeit.
Offene Punkte:
Erstellung getriggert durch Berechtigungssystem beim ersten Aufruf eines Patienten (nicht mehr Teil von $plan-read?).
Die initiale Erstellung eines Medikationsplans erfolgt ausschließlich durch die e-Medikation-Fachanwendung. Sie wird ausgelöst, wenn im Rahmen eines erstmaligen Aufrufs von $plan-read noch kein Medikationsplan für den ELGA-Teilnehmer existiert.
Der dabei erzeugte initiale Medikationsplan besitzt den Wert List.emptyReason = notstarted. Dieser kennzeichnet ausschließlich den Initialzustand des Medikationsplans und bedeutet, dass bisher noch keine Medikationsplaneinträge erfasst wurden. Er trifft jedoch keine Aussage darüber, ob der Patient Medikamente einnimmt.
Die Initialisierung kann sowohl durch ein GDA-System als auch durch den ELGA-Teilnehmer über das Portal ausgelöst werden, indem erstmals ein Plan-Read durchgeführt wird.
Planentry-Search dient der gezielten Suche nach Medikationsplaneintragsversionen eines ELGA-Teilnehmer. Als Medikationsplaneintrag gilt eine im Medikationsplan referenzierte Version einer MedicationRequest-Ressource mit category = "Planeintrag".
Die Suche ermöglicht berechtigten GDA sowie ELGA-Teilnehmern den Zugriff auf aktuelle und historische Medikationsplaneinträge unabhängig von einer bestimmten Medikationsplanversion.
Der Abruf erfolgt mittels GET unter Angabe geeigneter Suchparameter:
Offene Frage:
- Können bei einem GET _history beliebige Suchparameter definiert werden?
Die Historie ermöglicht die Nachverfolgung von Änderungen an Medikationsplaneinträgen, beispielsweise hinsichtlich Präparat, Dosierung oder Einnahmeanweisung.
Die gefundenen Medikationsplaneinträge können anschließend als Ausgangspunkt für weitere Abfragen verwendet werden, um jene Ressourcen zu ermittelnt, die genau auf diese Planeintragsversion referenzieren:
Offene Punkte:
- Sind die Referenzen in Geplanten und Durchgeführten Abgaben versioniert?
In Arbeit.
In Arbeit.