Zum Inhalt

ELGA DICOMWeb - WADO-SF (pIT-access-wado-sf)

Die WADO-SF ist der dezentrale Punkt für Abfragen von DICOM Objekten aus einem Bereich bzw. Archive. Der Endpunkt (URL der WADO-SF) wird vom zentralen QIDOaaS mittels Abfrage über die zentrale QIDO-SF bereitgestellt.

Die WADO Sevice Facade (WADO-SF) ist dezentral als Docker Container installiert und schützt das dahinterliegende Bereichs- bzw. Archive WADO-RS Service. Es werden folgende Prüfungen bzw. Funktionalitäten durchgeführt:

  • Validiert die empfangene SAML Assertion sowie ein WADO-RS spezifisches Instanz URL Pattern.

  • Kontaktiert den zentralen QIDO Cache, um ein access_token und ein cache_token für die Studie mittels Token Exchange abzurufen.

  • Speichert das access_token und cache_token für nachfolgende Anfragen der selben Studie im Memory.

  • Validiert, ob die Studie/Serie/Instanz Kombination im erhaltenen cache_token existiert.

  • Bei erfolgreicher Prüfung wird die Anfrage mit dem access_token (JWT) an das dahinterliegende WADO-RS weitergeleitet. Die Anfrage wird bis auf die BaseURL nicht verändert und wie die Antwort auch unverändert weitergeleitet.

  • Es wird ein Z-LARR Audit an das zentrale BeS gesendet - im Erfolgs- und Fehlerfall.

    • EventID: 92

Derzeit ist die WADO-SF nur aus dem Gesundheitsnetzwerk (VPN) erreichbar.

Da die WADO-SF auch von Endgeräten direkt angesprochen werden kann, wird davon ausgegangen, für diese eingehende Verbindung kein mTLS zu verwenden.

Weiters wird davon ausgegangen, dass eine TLS Terminierung vor der QIDO-SF auf einem Tool des Betreibers erfolgt. Das exakte Setup obliegt jedoch dem Betreiber.

Einschränkungen

  • Über die WADO-SF können nur instanzbezogene Abfragen gemacht werden (Ausnahme: /metadata).

GET http://:8904/pitaccess-wado-sf/facade/studies/1.2.40.0.35.12.3.1.4.1256.1332324757/series/1.2.40.0.35.12.3.1.4.1256.1332324757.1/instances/1.2.40.0.35.12.3.1.4.1256.1332324757.0.35/rendered

Hintergrund: In ELGA werden potentiell Submengen von Studien bzw. Serien registriert und somit auch berechtigt. Ein Abruf von ganzen Studien oder Serien ist somit nicht möglich.

  • In jeder WADO-SF Anfrage muss dieselbe ELGA SAML Assertion, die auch für die QIDO-SF verwendet wurde, im HTTP Authorization Header als Base64 Bearer Token mitgegeben werden.

Hintergrund: die ID der SAML Assertion wird als Teil des Cachekeys verwendet. Wird eine andere SAML Assertion verwendet, wird kein Cacheeintrag gefunden.

Service Endpunkt

GET http://<host>:8904/pitaccess-wado-sf/facade

  • Alle Services sind über dem Port 8904 erreichbar.

  • base-service-path: pineit/pitaccess-wado-sf

  • WADO-SF path: pineit/pitaccess-wado-sf/facade

Pro Instanz können beliebig viele api-routes bereitgestellt werden. Es ist somit möglich, hinter einer WADO-SF mehrere WADO-RS Komponenten bereitzustellen.

URL Pattern

Es sind folgende URL Patterns erlaubt bzw. wird darauf geprüft:

  • <base-service-path>/<api-rout/path>/studies/.*/series/.*/instances/.*

  • Beispiel: http://<host>:8895/pineit/pitaccess-wado-sf/facade/studies/.*/series/.*/instances/.*

  • im Beispiel ist als <api-rout/path> der Wert facade/* konfiguriert

  • Abrufen von Studien bzw. Serien Metadaten

    • //studies/./series/./metadata($|\?.*)

    • //studies/./metadata($|\?.)

Allgemeine Services

  • pIT-Service-Health

GET http://<host:port>/<base-service-path>/healthz/alive

K8s Liveness Check - der Pod wird neu gestartet wenn er nicht alive ist.

GET http://<host:port>/<base-service-path>/healthz/ready

K8s Readiness Check - der Pod empfängt vom Ochestrator keinen Traffic wenn er nicht ready ist.

  • ELGA DICOMWeb pIT-Service-Admin

VERB http://<host:port>/<base-service-path>/admin

Stellt ein Set an administrativen Interaktionen bereit z.B reload.

Für API GW Komponenten steht zusätzlich ein GET http://<host>:8895/pineit/pitaccess-wado-sf/admin/api-gw-stats? zur Verfügung, um temporäre Statistiken abzurufen.

  • ELGA DICOMWeb pIT-Service-ApiGw-Stats

Die Basis der Service Facade stellt die pit-access-apigw Komponenten dar. Dabei handelt es sich um ein flexible Sicherheitskomponente, die auf Basis von Konfiguration eine Vielzahl an Funktionalität unterstützt.

Abrufen von Metadaten

Im Gegensatz zu anderen Aufrufen werden Metadaten Anfragen (/metadata) von der WADO-SF spezifisch behandelt. Die Antwort wird als JSON interpretiert und gegen den vorhandenen QIDO Cache durchgesetzt. Die Antwort muss den content-type application/dicom+json verwenden.

Wandeln von DICOM Attributen

Von der WADO-SF wird in der Antwort das Attribute PixelData(7FE0,0010)/BulkDataURI auf die registrierte URL der jeweiligen WADO-SF gewandelt. Wenn die empfangene BulkDataURI vorhanden ist muss diese dem WADO-RS URI Syntax entsprechen. Weitere DICOM Attribute werden nicht verändert.

Aussortieren von Instanzen

Anfragen nach Metadaten (/metadata) werden von der WADO-SF ins Memory gelesen und anhand des QIDO Cache für die jeweilige Studie aussortiert. Dadurch können Metadaten nicht nur für einzelne Instanzen sondern auch für ganze Studien und Serien abgerufen werden. Alle anderen Anfragen (/rendered, …) müssen auf Ebene Instanz durchgeführt werden.

Alle Instanzen in einer Metadaten Antwort müssen folgende Attribute beinhalten um nicht aussortiert zu werden:

  • StudyInstanceUID (0020,000D)

  • SeriesInstanceUID (0020,000E)

  • SOPInstanceUID (0008,0018)

Alle Kombinationen an UIDs die nicht einem registriertem KOS entsprechen werden aussortiert.