Anwendungsfälle¶
Allgemeine Vorbedingungen¶
Alle Interaktionen mit der ELGA-Anwendung für digitale Bilddaten erfolgen ausschließlich über die bestehende ELGA Infrastruktur. Alle in den Anwendungsfällen angeführten Akteure haben keine direkte Zugriffsmöglichkeit auf Bilddaten, sondern ausschließlich über das ELGA BeS.
Die Identität der Akteure muss identisch mit den bereits heute genützten Verfahren durch eine vertrauenswürdige Identity-Assertion (IDA) gewährleistet sein.
Bilddatenteilnehmer sind ELGA-Bereiche bzw. Communities (z.B. ROZ, EBP), welche explizit über eine Konfiguration freigeschaltet wurden.
Unter Gesundheitsdiensteanbieter ("GDA") sind alle Rollen zu verstehen, welche für ELGA zugriffsberechtigt sind. GDA müssen im GDA-I eingetragen sein und deren Rolle muss dort unter ‚elgaRoles‘ gelistet sein.
Unter "Bürger" sind die Rollen ELGA-Teilnehmer, ELGA-Vollmachtnehmende Person und ELGA-Ombudsstelle zu verstehen, welche über das ELGA-Bürgerportal zugreifen können.
Für alle Patienten bezogenen Anwendungsfälle erfolgt die Identifizierung des Patienten, wie in ELGA üblich, über den Z-PI.
Die Kontaktbestätigungen für den Zugriff (lesend/schreibend) müssen im KBS vorhanden sein. Für Bürger wird jedoch keine Kontaktbestätigung benötigt.
Der Patient hat durch Vergabe individueller Berechtigungen nicht widersprochen (der GDA ist nicht gesperrt und es wurde kein e-Befund/generelles Opt-Out durchgeführt).
Der initiierende ELGA-Bereich muss ein Bilddaten-Teilnehmer sein.
Es werden hier nur Anwendungsfälle beschrieben, die über die bestehenden ELGA Anwendungsfälle hinausgehen. Es gelten die Anwendungsfälle wie für e-Befunde.
Allgemeine Nachbedingungen¶
Wird ein Anwendungsfall nicht korrekt ausgeführt, werden dem Akteur Fehlermeldungen retourniert. Die Fehlermeldungen müssen dem Akteur ermöglichen eine erneute Anfrage korrekt zu stellen. Die Fehlermeldungen müssen dem Akteur die Möglichkeit geben den/die Fehler gegenüber der Service Line eindeutig zu identifizieren.
Anwendungsfall 1: KOS-Objektliste eines Patienten anfordern¶
Akteure
GDA, Bürger
Vorbedingungen
Die allgemeinen Vorbedingungen müssen erfüllt sein. Eine gültige ELGA Login-Assertion muss vorliegen.
Ablauf / Beschreibung
Der Akteur fordert mit der entsprechenden ELGA Login-Assertion und ITI-18 FindDocuments mit dem Parameter XDSDocumentEntryClassCode = "55113-5" eine Liste der KOS-Objekte des Patienten an. Alternativ können alle Dokumente mit getAll abgerufen werden.
Dem Akteur wird eine Liste der KOS-Objekte retourniert, welche die KOS-Objekte des Patienten aus 0…n ELGA-Bereichen beinhaltet.
Nachbedingungen
Im Positivfall wurde eine Liste der KOS-Objekte mit 0…n Einträgen retourniert.
Anwendungsfall 2: KOS-Objekt eines Patienten abrufen¶
Anwendungsfall GDA.3.10.i des Leistungsverzeichnisses.
Akteure
GDA, Bürger
Vorbedingungen
Die allgemeinen Vorbedingungen müssen erfüllt sein. Eine gültige ELGA Login-Assertion und eine Liste der KOS-Objekte einer vorhergehenden ITI-18 Abfrage, welche nicht älter als 30 Minuten ist (30 Minuten Cache), müssen vorliegen.
Ablauf / Beschreibung
Der Akteur fordert mit der entsprechenden ELGA Login-Assertion und ITI-43 ein KOS-Objekt aus der Liste der KOS-Objekte (ITI-18) an.
Dem Akteur wird das angeforderte KOS-Objekt retourniert.
Nachbedingungen
Im Positivfall wurde 1…1 KOS-Objekt retourniert.
Anwendungsfall 3: Bilddaten eines Patienten abrufen¶
Anwendungsfall GDA.3.14.i des Leistungsverzeichnisses.
Akteure
GDA, Bürger
Vorbedingungen
Die allgemeinen Vorbedingungen müssen erfüllt sein. Eine gültige ELGA Login-Assertion und ein KOS-Objekt müssen vorliegen.
Ablauf / Beschreibung
Der Akteur fordert mit der entsprechenden ELGA Login-Assertion und
RAD-69 die Bilddaten eines KOS-Objekts an.
Es müssen unterschiedliche Selektionskriterien vordefiniert und getestet
werden, inklusive der möglichen Rückgabeformate (JPEG oder DICOM) und
Auflösungen.
Es dürfen nur jene DICOM-Instanzen angefordert werden, welche im KOS gelistet/referenziert sind. Sollte ein Akteur andere Instanzen aufrufen, wird BeS diese Anfrage mit der Fehlermeldung "XDSMissingPatientContext" blockieren.
Dem Akteur werden die angeforderten Bilddaten retourniert.
Nachbedingungen
Im Positivfall wurden 1…n Bilddaten (Einzelbilder, Studien, Serien) von 1…1 KOS-Objekt retourniert.
Anwendungsfall 4a: KOS-Objekt mit einem Befund eines Patienten verbinden¶
Anwendungsfall GDA.3.15.i des Leistungsverzeichnisses.
Akteure
GDA
Vorbedingungen
Die allgemeinen Vorbedingungen müssen erfüllt sein. Eine gültige HCP-Assertion, 1…n KOS-Objekte und 1…n Befunde müssen vorliegen.
Ablauf / Beschreibung
Der Akteur sendet mit einer HCP-Assertion eine neue Version des KOS-Objektes, das eine neue Metadata "referenceIdList" beinhaltet. Diese zeigt auf die "setId" des im Zusammenhang stehenden Befundes (entsprechend dem definierten Datentyp CXi). Um den Unterschied zur Versionierung verwendeten setID zu ermöglichen wird das Format mit dem Datentyp uniqueId wie folgt eingeführt:
Vom BeS wird die referenceIdList mit "urn:ihe:iti:xds:2013:uniqueId" nicht überprüft.
Die Referenz der KOS-Objekte auf den Befund wird gespeichert.
Dem Akteur wird eine Status Benachrichtigung retourniert.
Nachbedingungen
Im Positivfall wurde die KOS-Befund-Referenz registriert und eine Antwort mit "SUCCESS"-Status retourniert.
Anwendungsfall 4b: Befund mit einem KOS-Objekt eines Patienten verbinden¶
Anwendungsfall GDA.3.15.i des Leistungsverzeichnisses.
Akteure
GDA
Vorbedingungen
Die allgemeinen Vorbedingungen müssen erfüllt sein. Eine gültige HCP-Assertion, 1…n KOS-Objekte und 1…n Befunde müssen vorliegen.
Ablauf / Beschreibung
Der Akteur sendet mit einer HCP-Assertion eine neue Version des Befundes, der eine neue Metadata "referenceIdList" beinhaltet. Diese zeigt auf die "setId" des im Zusammenhang stehenden Befundes (entsprechend dem definierten Datentyp CXi). Um den Unterschied zur Versionierung verwendeten setID zu ermöglichen wird das Format mit dem Datentyp uniqueId wie folgt eingeführt:
Es ist jedoch empfehlenswert, statt die uniqueId eher die AccessionNumber für die Referenzierung anzuführen (oder eben beides):
Vom BeS wird die referenceIdList mit urn:ihe:iti:xds:2013:uniqueId bzw. urn:ihe:iti:xds:2013:accession nicht überprüft.
Die Referenz des Befundes auf das KOS-Objekt wird via ITI-41 gespeichert.
Dem Akteur wird eine Status Benachrichtigung retourniert.
Nachbedingungen
Im Positivfall wurde die Befund-KOS-Referenz registriert und eine Antwort mit "SUCCESS"-Status retourniert.
Anwendungsfall 5: KOS-Objekt eines Patienten registrieren¶
Anwendungsfall GDA.3.16.i des Leistungsverzeichnisses.
Akteure
GDA
Vorbedingungen
Die allgemeinen Vorbedingungen müssen erfüllt sein. Eine gültige HCP-Assertion und ein KOS-Objekt müssen vorliegen.
Ablauf / Beschreibung
Der Akteur sendet mit HCP-Assertion und RAD-68 ein KOS-Objekt in das Repository. In den Metadaten referenceIdList muss die entsprechende AccessionNumber angeführt werden, und zwar im folgenden Format:
Vom BeS wird die referenceIdList mit urn:ihe:iti:xds:2013:accession nicht überprüft.
Darüber hinaus enthält eine weitere referenceIdList wie in gewohnter Form (wie bei den e-Befunden) die setId zur Versionierung. Da die setId nicht vom KOS entnommen werden kann, muss der Imaging Document Source Akteur die setId generieren.
<rim:Value>
Set_ID^^^&1.2.40.0.34.99.222.1.1&ISO^urn:elga:iti:xds:2014:OwnDocument_setId^&1.2.40.0.34.99.999&ISO
</rim:Value>
Das KOS-Objekt wird im Repository gespeichert und in der Registry registriert. Dem Akteur wird ein Status Benachrichtigung retourniert.
Nachbedingungen
Im Positivfall wurde 1…1 KOS-Objekt registriert und eine Antwort mit "SUCCESS"-Status retourniert.
Anwendungsfall 6: KOS-Objekt eines Patienten ersetzen¶
Anwendungsfall GDA.3.17.i des Leistungsverzeichnisses
Akteure
GDA
Vorbedingungen
Die allgemeinen Vorbedingungen müssen erfüllt sein. Eine gültige HCP-Assertion und ein KOS-Objekt müssen vorliegen. Eine Vorversion des KOS-Objekts ist in einem ELGA-Bereich gespeichert.
Ablauf / Beschreibung
Der Akteur sendet mit HCP-Assertion und RAD-68 ein neues KOS-Objekt, um es zu aktualisieren.
Das KOS-Objekt wird im Repository gespeichert, in der Registry registriert und ersetzt die Vorversion. Dem Akteur wird eine Status Benachrichtigung retourniert.
Nachbedingungen
Im Positivfall wurde exakt 1…1 KOS-Objekt gespeichert und eine Antwort mit "SUCCESS"-Status retourniert. Die Vorversion des KOS-Objekts wurde als "DEPRECATED" gekennzeichnet.
Anwendungsfall 7: KOS-Objekt eines Patienten stornieren¶
Anwendungsfall GDA.3.18.i des Leistungsverzeichnisses
Akteure
GDA
Vorbedingungen
Die allgemeinen Vorbedingungen müssen erfüllt sein. Eine gültige HCP-Assertion und ein KOS-Objekt müssen vorliegen.
Ablauf / Beschreibung
Der Akteur sendet mit HCP-Assertion und ITI-57 einen Stornoauftrag für ein KOS-Objekt.
Das KOS-Objekt (und alle möglichen Vorversionen) werden storniert. Dem Akteur wird eine Status Benachrichtigung retourniert.
Nachbedingungen
Im Positivfall wurde 1…1 KOS-Objekt (und vorhandene Vorversionen) storniert (DEPRECATED) und ein "SUCCESS"-Status retourniert. Allfällige weitere KOS-Objekte desselben Patienten waren davon unberührt.