Zum Inhalt

Schnittstellen für Source und Consumer

Dieser Abschnitt beschreibt die abweichenden Transaktionen zu den existierenden ELGA Schnittstellen für Source und Consumer Akteure für den Bilddatenaustausch.

Die RAD-68 wird wie eine ITI-41 (Dokument einbringen) behandelt. Das Abrufen von KOS-Objekten wird wie die vorhandene ITI-43 behandelt.

Bei der RAD-69 (Abrufen von Bilddaten) Transaktion wird ein L-ARR ATNA Audit geschrieben.

Einbringen von KOS Dokumenten

Um DICOM Instanzen in ELGA zu registrieren, wird ein KOS Dokument, welches Referenzen auf DICOM Bilddaten enthält, mit einer RAD-68 Transaktion von einer Imaging Document Source über den bestehenden AGW/XDS Endpunkt an ein ELGA-Bereichs-XDS-Repository geschickt. Die RAD-68 Transaktion (=Provide and Register Imaging Document Set) ist bis auf den Dokumenten- und Metadateninhalt identisch mit der bereits existierenden ITI-41 Transaktion (=Provide and Register Document Set).

Es wird der bereits verwendete e-Befund AGW/XDS (wie für ITI-41) Endpunkt auch für die RAD-68 Anfrage weiterverwendet.

Es gelten alle bereits für e-Befund-Dokumente gültigen ELGA Regeln. Die Bereichsvariante C kann KOS Dokumente auch via ITI-57 Association Type "NonVersioningUpdate" Transaktion in ELGA registrieren. Siehe hierzu auch:

ELGA BeS Schnittstellen: 

IHE Referenz:

https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol3.pdf 

  • Kapitel 5.1.1; Tabelle 5.1-1:. Provide and RegisterI maging Document Set – MTOM/XOP

Metadaten:

Die Metadaten, die für die RAD-68 Transaktion zu verwenden sind, können dem ELGA-Dokument "Anbindung von DICOM Ressourcen - Architekturbeschreibung " entnommen werden.

Die veröffentlichten KOS-Objekte (DICOM-Objekt) müssen keinen APPC Code beinhalten, es ist jedoch bei der Registrierung in ELGA die Anreicherung der Metadaten mit APPC verpflichtend.

Die Metadaten des KOS-Objektes müssen zwingend in der DocumentEntry.eventCodeList einen APPC Code Eintrag enthalten (DocumentEntry.eventCodeList mit Schema der Root OID: urn:oid:1.2.40.0.34.5.38). Ist kein APPC Code enthalten, wird ein "XDSRepositoryMetadataError" (ITI-41) oder ein "XDSRegistryMetadataError" (ITI-42) zurückgeliefert. Zusätzlich zum APPC Code können weitere Einträge in der DocumentEntry.eventCodeList vorhanden sein.

Die Definition des APPC Codes in den Metadaten ist dem ELGA Metadatenleitfaden zu entnehmen.

Einbringen von KOS Dokumenten
Abbildung: Einbringen von KOS Dokumenten

Einzelschritte der Abbildung "Einbringen von KOS Dokumenten":

  1. Eine lokale Identity-Assertion wird angefordert
  2. Eine HCP-Assertion wird beim ETS angefordert
  3. Der HCP-Assertion Workflow wird vom ETS durchgeführt, z.B. Prüfen der Rolle
  4. Dem Client wird eine HCP-Assertion ausgehändigt
  5. In der Variante A registriert der Client ein KOS Objekt mit einer RAD-68 Transaktion über die lokale ZGF für ELGA. Im SOAP Security Header wird die HCP-Assertion mitgeführt
  6. Der BeS Treatment Workflow wird durchgeführt
  7. Der Patient wird im Z-PI geprüft
  8. Eine LPID wird vom Z-PI an BeS übergeben
  9. Es werden die ELGA Berechtigungen durchgesetzt
  10. Eine Treatment-Assertion wird an die ZGF zurückgeliefert
  11. In der zweiten Phase der ELGA Berechtigungsprüfung wird ein ELGA-Flag und ELGA-Hash vergeben
  12. Die RAD-68 Transaktion wird an den Bereich weitergeleitet
  13. Die Antwort der RAD-68 Transaktion wird an den Client zurückgeliefert
  14. In der 1. Variante C wird das KOS-Objekt mittels RAD-68 im lokalen ELGA-Bereich gespeichert
  15. Dem Client wird eine Antwort auf die RAD-68 Transaktion zurückgeliefert
  16. Um das KOS-Objekt für ELGA zu registrieren, wird eine ITI-57 mit ELGA "NonVersioningUpdate" Trigger an die lokale ZGF gesendet
  17. Die ZGF fragt beim ETS um eine Treatment-Assertion an
  18. Es wird die Treatment-Assertion vom ETS an die ZGF zurückgeliefert
  19. Von der ZGF werden die bereits gespeicherten KOS-Metadaten mittels ITI-18 Transaktion abgefragt
  20. Die ELGA Berechtigungen werden durchgesetzt, ELGA-Flag und -Hash werden vergeben
  21. Mittels ITI-57 "NonVersioningUpdate" Transaktion wird in der XDS Registry des ELGA-Bereichs ein ELGA-Flag und -Hash an die Metadaten des KOS-Objektes hinzugefügt
  22. In 2. Variante C wird (wie in Variante A) eine RAD-68 Transaktion an die ELGA ZGF gesendet
  23. Die ZGF fragt beim ETS um eine Treatment-Assertion an
  24. Die Treatment-Assertion wird vom ETS an die ZGF zurückgeliefert
  25. In der zweiten Phase der ELGA Berechtigungsprüfung wird ein ELGA-Hash und -Flag vergeben
  26. Die RAD-68 Transkation wird mit ELGA-Hash und -Flag an die Bereichs-Registry weitergeleitet
  27. Der Client empfängt die Antwort für die RAD-68 Transaktion
  28. Der Client / Gateway trifft anhand der Antwort der ZGF die Entscheidung, ob die Antwort (Success oder Fehler) an den tatsächlichen Client zurückgeliefert werden muss, oder ob die Transaktion erneut direkt an die Bereichs-Registry gesendet wird (kein ELGA KOS-Objekt)
  29. Abhängig von der Auswertung der Antwort werden die RAD-68 Metadaten erneut an die Bereichs-Registry gesendet. Bei einer AccesDenied SoapFault ist eine Wiederholung der Transaktion über die ELGA-AGW zu unterlassen.

Suchanfragen für KOS Dokumente

Abgesehen von den Metadaten existieren keine zusätzlichen Anforderungen an/von ELGA BeS für Consumer Akteure bezüglich KOS Dokumenten (ClassCode: 55113-5) und Suchanfragen. Die existierenden getAll und findDocuments XDS ITI-18 Stored Query Anfragen werden weiterverwendet. In der Antwort der Suchanfragen werden bilddatenspezifische Metadaten (siehe Implementierungsleitfaden DICOM-Bilddatenaustausch) zurückgeliefert, die der Consumer verarbeiten können muss. 

ELGA BeS Schnittstellen

Alle in BeS für e-Befunde bereits existierenden Regeln und Fehlermeldungen für Suchanfragen finden auch für KOS-Objekte Anwendung.

Abrufen von KOS Dokumenten

Es gibt keine Anpassungsnotwendigkeit für Consumer Akteure, um KOS Dokumente abzurufen. Die existierende ITI-43 Retrieve Document Set Transaktion kann unverändert weiterverwendet werden.

Der zurückgelieferte Content der ITI-43 Antwort ist ein DICOM KOS Dokument, welches nur mittels einer DICOM Library gelesen werden kann. Alternativ kann mittels HTTP Accept Header ‚application/json‘ der ZGF signalisiert werden, den DICOM KOS Inhalt in eine JSON Representation umzuwandeln (siehe Tabelle Abrufen von KOS Dokumenten).

HTTP Accept Header zurückgeliefertes Format
application/json JSON
application/dicom DICOM
application/dicom, application/json JSON
wenn keine Angabe DICOM

Tabelle: Abrufen von KOS Dokumenten

Der Inhalt des abgerufenen KOS Dokuments wird vom Client verwendet, um nachfolgend Bilddaten abrufen zu können. Der Inhalt des abgerufenen KOS Dokuments wird von BeS (der ZGF als PEP) verwendet, um die Zugriffskontrolle/Autorisierung bei Bilddatenzugriffen durchzusetzen.

ELGA BeS Schnittstellen

Alle in BeS für e-Befunde bereits existierenden Regeln und Fehlermeldungen für das Abrufen von Dokumenten (ITI-43) finden auch für KOS-Objekte Anwendung. Es werden die bereits vorhandenen Z-L-ARR, L-ARR und A-ARR Protokolleinträge erstellt.

Natives DICOM KOS

Beispiel eines DICOM KOS (kos-NA2019.dcm)

Beispiel eines DICOM KOS in String Representation

DICOM KOS als JSON

Beispiel eines DICOM KOS in JSON um auf ‚application/json‘ zu antworten

Abrufen von Bilddaten

Um eine RAD-69 Retrieve Imaging Document Set Anfrage starten zu können, müssen aus dem zuvor abgerufenen KOS Dokument Studien-, Serien- und SOP-Instanzidentifier extrahiert werden und in die RAD-69 Anfrage übernommen werden. Auch die retrieveLocationUid muss aus dem KOS in die RAD-69-Anfrage als RepositoryUniqueID übernommen werden.

Wie auch beim Abrufen von e-Befund-Dokumenten, muss auch beim Abrufen von Bilddaten die Home Community ID verpflichtend angegeben werden.

Auf der ZGF wird der bereits eingesetzte e-Befunde ZGF/XCA (wie für ITI-43) Endpunkt auch für die RAD-69 Anfrage weiterverwendet. Für die AGW muss jedoch aus Gründen der Skalierbarkeit (Routingwege) für die RAD-69 Transaktion ein eigener Endpunkt vorgesehen werden. Die Asynchrone WS Option wird derzeit nicht unterstützt.

Für das Abrufen von Bilddaten werden L-ARR und Z-L-ARR (Issue Token "21") Auditeinträge erstellt, es wird kein A-ARR Audit erzeugt.

Abrufen von Bilddaten
Abbildung: Abrufen von Bilddaten

Einzelschritte der Abbildung "Abrufen von Bilddaten":

  1. Eine lokale Identity-Assertion wird angefordert
  2. Eine ELGA HCP-Assertion wird vom ETS angefordert
  3. Eine in ELGA übliche ITI-18 Suchanfrage wird gestartet
  4. Die Suchanfrage wird von der initiierenden ZGF verarbeitet (Treatment-Assertion etc.)
  5. Die Anfrage wird an die antwortenden ELGA-Bereiche / ZGF weitergeleitet
  6. Die Suchanfrage wird von der antwortenden ZGF verarbeitet
  7. Kommt die Suchanfrage aus einem ELGA-Bereich, der nicht an Bilddaten teilnimmt, werden KOS-Objekte aus der Antwort entfernt, bevor diese an den initiierenden ELGA-Bereich zurückgeliefert wird
  8. Die Metadaten der Suchanfrage werden von der antwortenden an die initiierende ZGF zurückgegeben
  9. Die Suchanfrage wird an den Client zurückliefert
  10. KOS-Objekte werden analog zu anderen ELGA Dokumenten mittels ITI-43 Transaktion geladen
  11. Die Anfrage wird von der initiierenden ZGF verarbeitet (Treatment-Assertion etc.)
  12. Die Anfrage wird an die antwortenden ELGA-Bereiche / ZGF weitergeleitet
  13. Die Anfrage wird von der antwortenden ZGF verarbeitet
  14. Das KOS-Objekt wird an die initiierenden ZGF zurückgegeben
  15. Von der initiierenden ZGF wird eine spezielle Imaging Treatment-Assertion vom ETS beantragt. Es wird ein SHA 256 Hash vom KOS errechnet und in der WS Trust Anfrage mitgegeben. Der Hash wird nachfolgend vom ETS in die Imaging Treatment-Assertion eingefügt.
  16. Die Imaging Treatment-Assertion wird von der ZGF zwischengespeichert und bei nachfolgenden Bilddatenabrufen wiederverwendet
  17. Das KOS-Objekt wird an den Client ausgeliefert
  18. Mittels RAD-69 Transaktion werden Bilddaten von der initiierenden ZGF abgefragt
  19. Die ZGF ermittelt die zwischengespeicherte und korrelierende Imaging Treatment-Assertion zu der RAD-69 Anfrage. Es wird geprüft ob der aktuelle Hash des KOS der der Treatment-Assertion entspricht.
  20. Die RAD-69 Anfrage wird mittels RAD-75 und Imaging Treatment-Assertion an die antwortenden ZGF weitergeleitet
  21. Die Imaging Treatment-Assertion wird von der antwortenden ZGF geprüft
  22. Die RAD-75 Anfrage wird auf eine RAD-69 übersetzt und an den Bereichsadapter weitergegeben
  23. Der Bereichsadapter ist für die Bereitstellung der Bilddaten von den an den ELGA-Bereich angeschlossenen PACS Systemen verantwortlich und liefert diese in der RAD-69 Anfrage zurück
  24. Die Bilddaten werden mittels RAD-69 Antwort an die antwortende ZGF zurückgegeben
  25. Von der antwortenden ZGF werden die Bilddaten mittels RAD-75 Antwort an die initiierenden ZGF geliefert
  26. Die initiierenden ZGF übermittelt die Bilddaten mittels RAD-69 Antwort an den anfragenden Client

RAD-69 Spezifika

Da die ZGF aus Performancegründen und bei der Berechtigungsprüfung die Zuordnung von DICOM SOP Instance UIDs zu einem Patienten- und GDA-HCP-Kontext speichert, können Bilddaten mittels einer RAD-69 nur innerhalb eines Zeitraums von 30 Minuten, nachdem ein KOS Dokument abgerufen wurde, angefordert werden. Grundsätzlich ist die Größe des KOS Objektes von der Anzahl der Bilder abhängig.

Beispiel einer RAD-69 Anfrage Expand source.

Mittels RAD-69 können keine reinen JPEG Bilder (kein DICOM Header) geladen werden.

IHE Referenz: 

https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol3.pdf 

  • Kapitel 5.1.1; Tabelle 5.1-2 Retrieve Imaging Document Set

Natives DICOM Image

Beispiel eines DICOM Images (kos_sandstrand.dcm).

Bilddatenzugriff mittels "deprecated" KOS

Im Gegensatz zu gültigen (approved) KOS Objekten wird beim Abruf (Retrieve) von nicht mehr gültigen (deprecated) KOS Objekten keine Imaging Treatment Assertion beantragt und auch nicht zwischengespeichert. Dadurch ist kein Bilddatenabruf (RAD-69) möglich. Wird dennoch versucht Bilddaten zu einem KOS Objekt abzurufen, das zum Zeitpunkt des Queries deprecated war, wird der Fehler "XDSMissingPatientContext" zurückgegeben. Der KOS-Dokumentenstatus (approved vs. deprecated) wird über den ZGF Cache ermittelt.

Es bestehen für ITI-18 (Query) und ITI-43 (Retrieve) keine Einschränkungen bezüglich nicht mehr gültigen (deprecated) KOS Objekten. Deprecated KOS Objekte werden bei einem Query normal zurückgegeben und können nachfolgend auch abgerufen werden.