DICOMweb erklärt: QIDO-RS, WADO-RS und STOW-RS mit Beispielanfragen

Kurze Antwort: DICOMweb ist die Sammlung von Webservices, die in Teil 18 des DICOM-Standards definiert sind. Es stellt ein DICOM-Archiv über einfaches HTTPS bereit: QIDO-RS (Query based on ID for DICOM Objects) sucht nach Studien, Serien und Instanzen; WADO-RS (Web Access to DICOM Objects) ruft diese ab, als vollständige DICOM-Dateien, als Metadaten in JSON oder als gerenderte JPEG/PNG-Bilder; STOW-RS (Store Over the Web) lädt neue Objekte hoch. Der ältere WADO-URI ruft ein Objekt über Abfrageparameter ab. Browserbasierte Viewer verwenden DICOMweb, da sie kein klassisches DICOM-Networking sprechen können.

Klassisches DICOM vs. DICOMweb

Das klassische DICOM-Netzwerk (Teile 7 und 8 des Standards) verwendet ein Binärprotokoll über TCP mit Diensten wie C-FIND, C-MOVE, C-GET und C-STORE zwischen konfigurierten Knoten. DICOMweb (Teil 18) bildet dieselben Operationen auf HTTP ab: QIDO-RS zum Suchen, WADO-RS zum Abrufen und STOW-RS zum Speichern, was über das Internet und aus Browsern funktioniert.

Klassisches DICOM (Teil 7 und 8) verwendet sein eigenes Binärprotokoll über TCP mit benannten Diensten: C-FIND zum Abfragen, C-MOVE oder C-GET zum Abrufen, C-STORE zum Senden. Es benötigt eine konfigurierte "Assoziation" zwischen zwei bekannten Knoten (AE-Titel, IP-Adressen, Ports), was innerhalb eines Krankenhauses in Ordnung ist und über das Internet schwierig ist. DICOMweb bildet dieselben Ideen auf HTTP ab:

Die Ressourcenhierarchie folgt dem eigenen Modell von DICOM: Eine Studie (ein Besuch im Scanner) enthält Serien (jeweils eine Aufnahme), die Instanzen (einzelne Bilder oder Mehrbildobjekte) enthalten, die jeweils durch eine global eindeutige UID identifiziert werden.

QIDO-RS: Suchen

QIDO-RS ist der Suchdienst von DICOMweb. Ein Client sendet GET /studies, /series oder /instances mit Abfrageparametern wie PatientID, StudyDate oder ModalitiesInStudy und dem Accept-Header application/dicom+json. Das Archiv gibt ein JSON-Array zurück, in dem jedes DICOM-Attribut mit seinem achtstelligen Tag zusammen mit seiner Wertdarstellung und seinen Werten verschlüsselt ist.

GET /dicomweb/studies?PatientID=12345&StudyDate=20260101-20261231&ModalitiesInStudy=CT
Accept: application/dicom+json

Die Antwort ist ein JSON-Array von Studien. Jedes Attribut wird durch seinen Tag (Gruppe und Element als acht Hexadezimalziffern) mit seiner Wertdarstellung und seinen Werten indiziert:

[{
  "00080020": {"vr": "DA", "Value": ["20260314"]},
  "00080060": {"vr": "CS", "Value": ["CT"]},
  "00100010": {"vr": "PN", "Value": [{"Alphabetic": "DOE^JANE"}]},
  "0020000D": {"vr": "UI", "Value": ["1.2.840.113619.2.55.3.2831164356.781.1710415000.1"]},
  "00201206": {"vr": "IS", "Value": [3]},
  "00201208": {"vr": "IS", "Value": [412]}
}]

Hier ist 00201206 die Anzahl der studienbezogenen Serien und 00201208 die Anzahl der studienbezogenen Instanzen. Die Tag-Nummern werden in DICOM-Tags erklärt erläutert.

WADO-RS: Abrufen

WADO-RS ist der Abrufdienst von DICOMweb. GET /studies/{StudyInstanceUID} gibt eine ganze Studie als DICOM-Teil-10-Dateien in einer Multipart-Antwort zurück; der Suffix /metadata gibt Header als JSON ohne Pixeldaten zurück; /frames/{n} gibt die Pixel eines Frames zurück; und /rendered gibt ein vom Server gerendertes JPEG oder PNG mit Fenster-, Ansichtsfenster- und Qualitätsparametern zurück.

• GET /studies/{study} mit Accept: multipart/related; type="application/dicom" gibt jede Instanz als DICOM Part 10-Datei zurück, jeweils ein Teil.
• GET /studies/{study}/metadata gibt die Header aller Instanzen als JSON zurück, ohne Pixeldaten. Viewer rufen dies zuerst auf, um das Layout zu erstellen, und rufen dann die Pixel Frame für Frame ab.
• GET /studies/{study}/series/{series}/instances/{instance}/frames/1 gibt die Pixeldaten eines Frames zurück, optional transkodiert (transfer-syntax-Parameter).
• GET …/instances/{instance}/rendered mit Accept: image/jpeg gibt ein serverseitig gerendertes Bild zurück, mit den Parametern window, viewport und quality. Dies ist es, was ein leichtgewichtiges Patientenportal für eine Vorschau verwendet.

STOW-RS: Speichern

STOW-RS ist der Speicherdienst von DICOMweb. Ein Client sendet POST /studies mit einem multipart/related-Body, in dem jeder Teil eine DICOM-Datei ist. Das Archiv antwortet mit einer Liste der akzeptierten und fehlgeschlagenen Instanzen und dem Grund für jeden Fehler und prüft, ob eine in der URL angegebene Study Instance UID mit den hochgeladenen Dateien übereinstimmt.

POST /dicomweb/studies
Content-Type: multipart/related; type="application/dicom"; boundary=abc

Jeder Teil ist eine DICOM-Datei. Die Antwort listet akzeptierte und fehlgeschlagene Instanzen mit Gründen auf (falsche SOP-Klasse, doppelte UID). Archive validieren, dass die Study Instance UID in der URL, falls vorhanden, mit den Dateien übereinstimmt.

Sicherheit

DICOMweb hat keine eigene Anmeldung; es stützt sich auf HTTPS und das, was der Server davor setzt: OAuth 2.0 Bearer-Tokens in den meisten modernen Archiven, oft kombiniert mit SMART on FHIR-Scopes, wenn der Viewer aus einem EHR gestartet wird. Die Protokollierung, wer welche Studie abgerufen hat, ist Aufgabe des Archivs, nicht des Protokolls.

Wo es verwendet wird

Jeder große PACS und jede herstellerneutrale Archivierung bietet jetzt einen DICOMweb-Endpunkt an, und Open-Source-Archive (Orthanc, dcm4chee, Google Cloud Healthcare API, Azure DICOM-Dienst) sind DICOMweb-first. Web-Viewer wie OHIF sind vollständig auf QIDO-RS und WADO-RS aufgebaut. In einer FHIR-Welt verweist eine ImagingStudy-Ressource auf einen DICOMweb-Endpunkt; die Pixel werden niemals über FHIR übertragen.

Anpheros speichert keine Bilder. Die Akte eines Patienten kann den radiologischen Bericht als DocumentReference oder DiagnosticReport enthalten und, wo ein Krankenhaus einen anbietet, einen Link zu seinem Viewer; die DICOM-Daten selbst bleiben im Archiv des Krankenhauses. Um Ihre eigenen Bilder als Patient zu erhalten, siehe Wie Sie Ihre CT- oder MRT-Bilder erhalten.

Verwandte Seiten

• FHIR ImagingStudy vs. DICOMweb
• DICOM-Tags erklärt
• PACS vs. RIS vs. VNA
• Wie Sie Ihre CT- oder MRT-Bilder erhalten (DICOM)
• Standards für die Interoperabilität im Gesundheitswesen: die Karte
• DICOM vs. FHIR für Entwickler

Quellen

• DICOM PS3.18: Web Services
• DICOM PS3.7: Message Exchange
• DICOMweb-Übersicht (DICOM Standards Committee)
• OHIF Viewer Dokumentation

Häufige Fragen

Ist DICOMweb ein anderer Standard als DICOM?

Nein. Es ist Teil 18 desselben DICOM-Standards. Die Objekte, Tags und UIDs sind identisch; nur der Transport ändert sich vom eigenen Protokoll von DICOM zu HTTP.

Was ist der Unterschied zwischen WADO-URI und WADO-RS?

WADO-URI ist der ältere Dienst: ein Objekt pro Anfrage, ausgewählt mit Abfrageparametern (?requestType=WADO&studyUID=…). WADO-RS ist RESTful, kann ganze Studien oder Serien, Metadaten als JSON und einzelne Frames zurückgeben und ist das, was neue Systeme implementieren.

Kann ich DICOMweb ohne PACS verwenden?

Sie benötigen ein Archiv, das es implementiert. Open-Source-Server wie Orthanc und dcm4chee bieten DICOMweb "out of the box" an und werden häufig für die Entwicklung und für kleine Kliniken verwendet.

Ersetzt FHIR DICOMweb?

Nein. FHIR beschreibt die Studie (ImagingStudy) und den Bericht (DiagnosticReport); DICOMweb liefert die Bilder. Ein Viewer verwendet beides: FHIR, um zu erfahren, dass eine Studie existiert, DICOMweb, um sie anzuzeigen.

Anpheros Daily

Anpheros Daily ausprobieren

Bewahren Sie Ihre Befunde von Scans und Tests an einem Ort in Anpheros Daily auf, bereit für Ihren nächsten Arztbesuch.

So funktioniert es in der App →

iPhone & MacAndroidIm Browser öffnen →

Erstellt von

Das Anpheros-Team

Anpheros entwickelt eine Patientenakte, die der Patient kontrolliert und mit jeder Klinik teilen kann, auf einer HL7 FHIR R4-Plattform mit Sitz in der EU. Diese Anleitungen helfen Ihnen, Ihre Gesundheit zu verstehen und zu organisieren; sie ersetzen nicht Ihren Arzt.

Über Anpheros →