ELGA e-Diagnose R4 (Draft) - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Dieses Kapitel beschreibt die lesenden Zugriffe der e-Diagnose-Fachanwendung auf Listen, Gesamtansicht sowie auf die Einträge in den Einzelressourcen. Je nach Anwendungsfall stehen unterschiedliche Interaktionen zur Verfügung.
Interaktionen auf Einzelressourcen
Einträge als Einzelressource abrufen
Sub:UC_01_03
Dieser Use-Case ermöglicht den lesenden Zugriff auf alle Einträge von Diagnosen, Prozeduren sowie Allergien und Intoleranzen eines Patienten jeweils als Gesamtansicht.
Die Interaktion liefert standardmäßig die letzten 30 Einträge, absteigend nach Datum sortiert zurück. Die Fachanwendung stellt die vorhandenen Ressourcen des gewählten Ressourcentyps als Search-Bundle bereit. Der Zugriff erfolgt ausschließlich lesend; Änderungen an Status, Inhalten oder Listenzuordnungen werden durch diese Interaktion nicht durchgeführt.
Ablauf
Der GDA oder ELGA-Teilnehmer wählt den gewünschten Ressourcentyp (Condition, Procedure oder AllergyIntolerance) aus.
Der GDA oder ELGA-Teilnehmer führt ein GET auf /Patient/[id]/Condition/, /Patient/[id]/Procedure/ und/oder /Patient/[id]/AllergyIntolerance/ aus, siehe Transaktionen.
Optional kann der Abfrageparameter _count angegeben werden um die Treffermenge einzustellen. Standarmäßig werden die letzten 30 Einträge, absteigend nach Datum sortiert zurück gegebenen.
Die Fachanwendung liefert ein Search-Bundle mit den gefundenen Einträgen zurück.
Sind keine Ressourcen vorhanden bzw. entsprechen keine Ressourcen den Suchkriterien, wird ein Search-Bundle ohne Einträge zurückgeliefert.
Interaktionen auf Listenressourcen
Vergangene Versionen einer Summary-Liste abrufen (List-History-Read)
Sub:UC_01_01
History Read dient ausschließlich der Anzeige historischer Versionen der Summary-Liste. Die Fachanwendung stellt bereits persistierte historische Search-Bundles unverändert bereit. Der Zugriff erfolgt lesend und ermöglicht keine nachfolgende Bearbeitung der Summary-Liste.
Vorversionen der Summary-Listen können in chronologischer Reihenfolge dargestellt werden – absteigend nach Erstellungsdatum, d.h. die jüngste Version zuerst.
Ablauf
Der GDA fürht ein GET (Suche) auf den List-Typ aus.
Die Fachanwendung führt die Suche anhand der angegebenen Suchparameter durch.
Werden keine Summary-Listen gefunden, wird ein leeres Ergebnis zurückgeliefert.
Wird zumindest eine Summary-Liste gefunden, liefert die Fachanwendung ein Search-Bundle zurück.
Dieses Search-Bundle enthält:
die List-Ressource
alle referenzierten Ressourcen (Patient, Practitioner, Condition, Procedure, AllergyIntolerance)
Beim List History Read erfolgt keine Veränderung von Flags, Status oder Inhalten durch die Fachanwendung.
Der Zugriff dient ausschließlich der Anzeige bzw. Informationsabfrage von aktueller oder historischer Summary-Listversionen.
Sequenzdiagramm
Beispiele für Zugriffe mittels Suchparameter:
Aktuelle Summary-Listenversion der Summary-Einträge (Conditions) mit dem Suchparameter Patient abrufen: GET [base]/Patient/[id]/List?_include=List:patient&_include=List:source&_include:iterate=List:item&_count=1&_sort=-date&code=http://loinc.org|11450-4
Alle Summary-Listenversionen der Summary-Einträge (Procedures) mit dem Suchparameter Patient abrufen: GET [base]/Patient/[id]/List?_include=List:patient&_include=List:source&_include:iterate=List:item&_sort=-date&code=http://loinc.org|47519-4
Summary-Liste und zugehörige Ressourcen abrufen (List-Read)
Sub:UC_01_02
List Read dient dem Abruf der Summary-Liste und der Vorbereitung einer nachfolgenden Änderung.
Ablauf
Der GDA führt einen POST $list-read aus.
Die Fachanwendung prüft auf Existenz der Summary-Liste/n.
Ist keine Summary-Liste vorhanden, wird dieser erstellt und eine leere Summary-Liste mit dem emptyReason notstarted wird zurückgeliefert.
Existiert bereits eine Summary-Liste, stellt die Fachanwendung ein Search-Bundle einschließlich aller referenzierten Ressourcen zur Auslieferung bereit.
Falls der vorherige GDA neue Summary-Einträge hinzugefügt hat (List.entry.flag hat den Wert new), werden diese auf unchanged gesetzt.
Falls der vorherige GDA Summary-Einträge beendet hat (deren List.entry.flag haben den Wert removed), werden diese Einträge aus der Liste entfernt, siehe Workflowmanagement.
Falls der vorherige GDA alle vorhandenen Summary-Einträge mit removed gekennzeichnet hat, wird List.emptyReason mit nilknown zurückgeliefert, um nachfolgenden GDA zu signalisieren, dass die Person zum Zeitpunkt des letzten Schreibens keine Einträge hatte.
Die Fachanwendung liefert an den GDA die Summary-Liste inkl. ETag für Optimistic Locking und alle referenzierten Ressourcen.
Die zurückgelieferte Summary-Liste bildet die Grundlage für nachfolgende Änderungsoperationen.
