ELGA e-Diagnose R4 (Draft)
0.1.0 - ci-build

Lesen

UC-01-Lesen

Dieses Kapitel beschreibt die lesenden Zugriffe auf Listen sowie auf die Einzelressourcen Diagnosen, Prozeduren oder Allergien und Intoleranzen. Je nach Anwendungsfall stehen unterschiedliche Interaktionen zur Verfügung.

Sub_UC_eDiag_01_01 - Vergangene Versionen einer Liste abrufen (List-History-Read)

Der History Read dient ausschließlich der Anzeige historischer Versionen einer Liste. Die Fachanwendung stellt bereits persistierte historische Search-Bundles unverändert bereit. Der Zugriff erfolgt lesend und ermöglicht keine nachfolgende Bearbeitung der Liste.

Ablauf

  1. Der GDA fürht ein GET (Suche) auf den List-Typ aus.
  2. Die Fachanwendung prüft, ob Listen entsprechend der Suchparameter vorhanden sind.
  3. Werden keine Listen gebunden, wird ein leeres Ergebnis zurückgeliefert.
  4. Wird zumindest eine 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 Listversionen.

Sequenzdiagramm


Vergangene Versionen einer Liste abrufenGDA 1?html-link?e-Diagnose Fachanwendung?html-link?GDA 1e-Diagnose FachanwendungGDA 1e-Diagnose Fachanwendung1GET /List?_include=List:patient&_include=List:source&_include:iterate=List:item&criteria...2Auf bestehendeListe(n) prüfenalt: Liste(n) gefunden?[Liste(n) entsprechend der Suchparametern vorhanden][keine Liste entsprechend der Suchparameter vorhanden][Fehler]Die Fachanwendung liefert die gespeicherte Liste(unverändert, inkl. aller referenzierten Ressourcen) zurück.3Bundle (type=searchset) mit zumindest einer Liste4leeres Bundle (type=searchset)5OperationOutcome


Beispiele für Zugriffe mittels Suchparameter:

  • Aktuelle Listenversion der relevanten Diagnosen (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 Listenversionen der relevanten Operationen (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

Sub_UC_eDiag_01_02 - Liste und zugehörige Ressourcen abrufen (List-Read)

List Read dient dem Abruf der Liste und der Vorbereitung einer nachfolgenden Änderung.

Ablauf

  1. Der GDA führt einen POST $list-read aus.
  2. Die Fachanwendung prüft auf Existenz der Liste/n für die angegebene Patientin bzw. den angegebenen Patienten.
  3. Ist keine Liste vorhanden, wird dieser erstellt und eine leere Liste mit dem emptyReason notstarted wird zurückgeliefert.
  4. Existiert bereits eine Liste, wird von der Fachanwendung aus diesem ein Search-Bundle zur Auslieferung bereitgestellt. Die Inhalte werden von der Fachanwendung wie folgt aufbereitet:
    • Falls der vorherige GDA neue Listeneinträge hinzugefügt hat (List.entry.flag hat den Wert new), werden diese auf unchanged gesetzt.
    • ​Falls der vorherige GDA Listenneinträ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 Einträge mit removed gekennzeichnet hat, wird List.emptyReason mit nilknown zurückgeliefert, um nachfolgenden GDA zu signalisieren, dass der Patient zum Zeitpunkt des letzten Schreibens keine Einträge hatte.
  5. Die Fachanwendung liefert an den GDA die Liste inkl. ETag für Optimistic Locking und alle referenzierten Ressourcen.
  6. Ziel ist ein neutraler, weiterbearbeitbarer Zustand für den abrufenden GDA.

Sequenzdiagramm


Liste und zugehörige Ressourcen abrufen ($list-read)GDA 1GDA 1e-Diagnose Fachanwendunge-Diagnose Fachanwendung1POST /[Condition|Procedure|AllergyIntolerance]/$list-read2Auf bestehende Liste(n) prüfenalt: Liste(n) vorhanden?[Liste(n) vorhanden]3Liste mit aktuellem List.date ermitteln4Prüfen, ob List.emptyReason vorhanden istalt: List.emptyReason vorhanden?[nein]5Flags der Listeneinträge aufbereitennew|changed → unchangedremoved → entfernen6Zählen der Listeneinträgealt: Anzahl Einträge?[zumindest ein Eintrag]7Collection-Bundle (List mit Einträgen) +ETag für Optimistic Locking[Liste leer]8List.emptyReason = nilknown setzen9Collection-Bundle (List ohne Einträge) +ETag für Optimistic Locking[ja]10Collection-Bundle (List ohne Einträge) +ETag für Optimistic Locking[Keine Liste vorhanden]11Leere Liste mit List.emptyReason = notstarted erzeugen12Collection-Bundle (List ohne Einträge) +ETag für Optimistic Locking


Sub_UC:eDiag_01_03 - Diagnosen, Prozeduren sowie Allergien und Intoleranzen als Einzelressource lesen und suchen (Read/Search)

Read/Search ermöglicht den gezielten lesenden Zugriff auf Diagnosen, Prozeduren sowie Allergien und Intoleranzen eines Patienten. Über die Interaktion können sowohl alle vorhandenen Ressourcen eines Ressourcentyps als auch durch Angabe von Suchparametern eingeschränkte Ergebnismengen abgerufen werden.

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.

Anwendungsbeispiele

Die Read/Search-Interaktion kann beispielsweise für folgende Szenarien verwendet werden:

  • Gesamtansicht: Abruf aller vorhandenen Diagnosen, Prozeduren oder Allergien und Intoleranzen eines Patienten.
  • Gezielte Suche: Einschränkung der Ergebnismenge durch Suchparameter, z. B. Suche nach bestimmten Diagnosen oder Ressourcen mit bestimmten Merkmalen.
    • Mit der gezielten Suche kann auch der Verlauf einer Krankheit dargestellt werden, indem nach allen Ressourcen (eines Typs) gesucht wird, die denselben Business-Identifier haben.
  • Auswahl für Folgeoperationen: Ermittlung einzelner Ressourcen, die anschließend gelöscht ($delete) oder storniert ($storno) werden sollen.

Ablauf

  1. Der GDA oder ELGA-Teilnehmer wählt den gewünschten Ressourcentyp (Condition, Procedure oder AllergyIntolerance) aus.
  2. ​Der GDA oder ELGA-Teilnehmer führt ein GET auf /Patient/[id]/Condition/, /Patient/[id]/Procedure/ und/oder /Patient/[id]/AllergyIntolerance/ aus, siehe Transaktionen.
  3. Optional können Suchparameter angegeben werden, um die Treffermenge einzuschränken.
  4. Die Fachanwendung führt die Suche anhand der angegebenen Kriterien durch.
  5. Die Fachanwendung liefert ein Search-Bundle mit den gefundenen Ressourcen zurück.
  6. Sind keine Ressourcen vorhanden bzw. entsprechen keine Ressourcen den Suchkriterien, wird ein Search-Bundle ohne Einträge zurückgeliefert.