Réponse courte : DICOMweb est l'ensemble des services web définis dans la partie 18 de la norme DICOM. Il expose une archive DICOM via HTTPS standard : QIDO-RS (Query based on ID for DICOM Objects) recherche des études, des séries et des instances ; WADO-RS (Web Access to DICOM Objects) les récupère, sous forme de fichiers DICOM complets, de métadonnées en JSON, ou d'images rendues JPEG/PNG ; STOW-RS (Store Over the Web) télécharge de nouveaux objets. L'ancien WADO-URI récupère un objet via des paramètres de requête. Les visualiseurs basés sur navigateur utilisent DICOMweb car ils ne peuvent pas utiliser le protocole DICOM classique.
DICOM classique vs DICOMweb
Le réseau DICOM classique (parties 7 et 8 de la norme) utilise un protocole binaire sur TCP avec des services tels que C-FIND, C-MOVE, C-GET et C-STORE entre des nœuds configurés. DICOMweb (partie 18) transpose les mêmes opérations sur HTTP : QIDO-RS pour la recherche, WADO-RS pour la récupération et STOW-RS pour le stockage, ce qui fonctionne sur Internet et depuis les navigateurs.
Le DICOM classique (parties 7 et 8) utilise son propre protocole binaire sur TCP avec des services nommés : C-FIND pour interroger, C-MOVE ou C-GET pour récupérer, C-STORE pour envoyer. Il nécessite une "association" configurée entre deux nœuds connus (titres AE, adresses IP, ports), ce qui est pratique à l'intérieur d'un hôpital et difficile sur Internet. DICOMweb transpose les mêmes idées sur HTTP :
| Tâche | DICOM classique | DICOMweb |
|---|---|---|
| Trouver une étude | C-FIND | QIDO-RS : GET /studies?PatientID=… |
| Récupérer une étude | C-MOVE / C-GET | WADO-RS : GET /studies/{StudyInstanceUID} |
| Lire uniquement les métadonnées | C-FIND au niveau de l'instance | WADO-RS : GET /studies/{uid}/metadata |
| Obtenir une image visualisable | récupérer puis rendre localement | WADO-RS rendu : GET …/instances/{uid}/rendered |
| Envoyer des images à une archive | C-STORE | STOW-RS : POST /studies |
| Gérer les listes de travail | MWL (C-FIND sur une liste de travail) | UPS-RS |
La hiérarchie des ressources suit le modèle propre à DICOM : une étude (une visite au scanner) contient des séries (une acquisition chacune), qui contiennent des instances (images uniques ou objets multi-images), chacune identifiée par un UID unique au niveau mondial.
QIDO-RS : recherche
QIDO-RS est le service de recherche DICOMweb. Un client envoie GET /studies, /series ou /instances avec des paramètres de requête tels que PatientID, StudyDate ou ModalitiesInStudy et l'en-tête Accept application/dicom+json. L'archive renvoie un tableau JSON dans lequel chaque attribut DICOM est indexé par son identifiant à huit chiffres, sa représentation de valeur et ses valeurs.
GET /dicomweb/studies?PatientID=12345&StudyDate=20260101-20261231&ModalitiesInStudy=CT
Accept: application/dicom+json
La réponse est un tableau JSON d'études. Chaque attribut est indexé par son tag (groupe et élément sous forme de huit chiffres hexadécimaux), avec sa représentation de valeur et ses valeurs :
[{
"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]}
}]
Ici, 00201206 est le nombre de séries liées à l'étude et 00201208 est le nombre d'instances liées à l'étude. Les numéros de tag sont expliqués dans Explication des tags DICOM.
WADO-RS : récupération
WADO-RS est le service de récupération DICOMweb. GET /studies/{StudyInstanceUID} renvoie une étude complète sous forme de fichiers DICOM partie 10 dans une réponse multipart ; le suffixe /metadata renvoie les en-têtes au format JSON sans données de pixels ; /frames/{n} renvoie les pixels d'une image ; et /rendered renvoie une image JPEG ou PNG rendue par le serveur avec des paramètres de fenêtre, de vue et de qualité.
GET /studies/{study}avecAccept: multipart/related; type="application/dicom"renvoie chaque instance sous forme de fichier DICOM Part 10, une partie par fichier.GET /studies/{study}/metadatarenvoie les en-têtes de toutes les instances sous forme de JSON, sans les données pixel. Les visualiseurs appellent ceci en premier pour construire la mise en page, puis récupèrent les pixels image par image.GET /studies/{study}/series/{series}/instances/{instance}/frames/1renvoie les données pixel d'une image, éventuellement transcodées (paramètretransfer-syntax).GET …/instances/{instance}/renderedavecAccept: image/jpegrenvoie une image rendue par le serveur, avec les paramètreswindow,viewportetquality. C'est ce qu'un portail patient léger utilise pour afficher un aperçu.
STOW-RS : stockage
STOW-RS est le service de stockage DICOMweb. Un client envoie POST /studies avec un corps multipart/related dans lequel chaque partie est un fichier DICOM. L'archive répond avec une liste des instances acceptées et échouées ainsi que la raison de chaque échec, et vérifie que tout Study Instance UID donné dans l'URL correspond aux fichiers téléchargés.
POST /dicomweb/studies
Content-Type: multipart/related; type="application/dicom"; boundary=abc
Chaque partie est un fichier DICOM. La réponse liste les instances acceptées et celles qui ont échoué avec les raisons (mauvaise classe SOP, UID dupliqué). Les archives valident que l'UID de l'étude dans l'URL, s'il est fourni, correspond aux fichiers.
Sécurité
DICOMweb n'a pas de système de connexion propre ; il s'appuie sur HTTPS et sur ce que le serveur met en place : des jetons porteurs OAuth 2.0 dans la plupart des archives modernes, souvent combinés avec des scopes SMART on FHIR lorsque le visualiseur est lancé depuis un DME. L'enregistrement de qui a récupéré quelle étude est le travail de l'archive, pas du protocole.
Où est-il utilisé
Tous les principaux PACS et archives neutres proposent désormais un point d'accès DICOMweb, et les archives open-source (Orthanc, dcm4chee, Google Cloud Healthcare API, Azure DICOM service) sont d'abord orientées DICOMweb. Les visualiseurs web tels que OHIF sont entièrement construits sur QIDO-RS et WADO-RS. Dans un monde FHIR, une ressource ImagingStudy pointe vers un point d'accès DICOMweb ; les pixels ne transitent jamais par FHIR.
Anpheros ne stocke pas d'images. Le dossier d'un patient peut contenir le compte-rendu de radiologie sous forme de DocumentReference ou DiagnosticReport et, lorsque l'hôpital en fournit un, un lien vers son visualiseur ; les données DICOM elles-mêmes restent dans l'archive de l'hôpital. Pour obtenir vos propres images en tant que patient, consultez Comment obtenir vos images CT ou IRM.
Pages associées
- FHIR ImagingStudy vs DICOMweb
- Explication des tags DICOM
- PACS vs RIS vs VNA
- Comment obtenir vos images CT ou IRM (DICOM)
- Normes d'interopérabilité des soins de santé : la carte
- DICOM vs FHIR pour les développeurs
Sources
- DICOM PS3.18 : Services Web
- DICOM PS3.7 : Échange de messages
- Vue d'ensemble de DICOMweb (Comité des normes DICOM)
- Documentation OHIF Viewer
Questions fréquentes
DICOMweb est-il une norme différente de DICOM ?
Non. C'est la partie 18 de la même norme DICOM. Les objets, les tags et les UIDs sont identiques ; seul le transport passe du protocole DICOM à HTTP.
Quelle est la différence entre WADO-URI et WADO-RS ?
WADO-URI est l'ancien service : un objet par requête, sélectionné avec des paramètres de requête (?requestType=WADO&studyUID=…). WADO-RS est RESTful, peut renvoyer des études ou des séries complètes, des métadonnées en JSON et des images individuelles, et c'est ce que les nouveaux systèmes implémentent.
Puis-je utiliser DICOMweb sans PACS ?
Vous avez besoin d'une archive qui l'implémente. Les serveurs open-source comme Orthanc et dcm4chee fournissent DICOMweb dès le départ et sont couramment utilisés pour le développement et pour les petites cliniques.
FHIR remplace-t-il DICOMweb ?
Non. FHIR décrit l'étude (ImagingStudy) et le compte-rendu (DiagnosticReport) ; DICOMweb livre les images. Un visualiseur utilise les deux : FHIR pour savoir qu'une étude existe, DICOMweb pour l'afficher.
Essayez Anpheros Daily
Conservez vos rapports d'examens et d'analyses en un seul endroit dans Anpheros Daily, prêts à être présentés lors de votre prochaine visite.
Comment ça marche dans l'appli →
Anpheros développe un dossier médical que le patient contrôle et peut partager avec n'importe quelle clinique, sur une plateforme HL7 FHIR R4, basée en UE. Ces guides vous aident à comprendre et organiser votre santé ; ils ne remplacent pas votre médecin.
À propos d'Anpheros →