Risposta breve: DICOMweb è l'insieme di servizi web definiti nella Parte 18 dello standard DICOM. Espone un archivio DICOM tramite HTTPS standard: QIDO-RS (Query based on ID for DICOM Objects) cerca studi, serie e istanze; WADO-RS (Web Access to DICOM Objects) li recupera, come file DICOM completi, come metadati in JSON o come immagini JPEG/PNG renderizzate; STOW-RS (Store Over the Web) carica nuovi oggetti. Il precedente WADO-URI recupera un oggetto tramite parametri di query. I visualizzatori basati su browser utilizzano DICOMweb perché non possono utilizzare il networking DICOM classico.
DICOM classico vs DICOMweb
La rete DICOM classica (Parti 7 e 8 dello standard) utilizza un protocollo binario su TCP con servizi come C-FIND, C-MOVE, C-GET e C-STORE tra nodi configurati. DICOMweb (Parte 18) mappa le stesse operazioni su HTTP: QIDO-RS per la ricerca, WADO-RS per il recupero e STOW-RS per l'archiviazione, che funziona su Internet e dai browser.
Il DICOM classico (Parti 7 e 8) utilizza un proprio protocollo binario su TCP con servizi denominati: C-FIND per interrogare, C-MOVE o C-GET per recuperare, C-STORE per inviare. Richiede un'"associazione" configurata tra due nodi noti (titoli AE, indirizzi IP, porte), il che va bene all'interno di un ospedale e difficile su Internet. DICOMweb mappa le stesse idee su HTTP:
| Attività | DICOM classico | DICOMweb |
|---|---|---|
| Trova uno studio | C-FIND | QIDO-RS: GET /studies?PatientID=… |
| Recupera uno studio | C-MOVE / C-GET | WADO-RS: GET /studies/{StudyInstanceUID} |
| Leggi solo i metadati | C-FIND a livello di istanza | WADO-RS: GET /studies/{uid}/metadata |
| Ottieni un'immagine visualizzabile | recupera e poi renderizza localmente | WADO-RS renderizzato: GET …/instances/{uid}/rendered |
| Invia immagini a un archivio | C-STORE | STOW-RS: POST /studies |
| Gestisci le worklist | MWL (C-FIND su una worklist) | UPS-RS |
La gerarchia delle risorse segue il modello DICOM: uno studio (una visita alla macchina) contiene serie (una acquisizione ciascuna), che contengono istanze (singole immagini o oggetti multiframe), ognuna identificata da un UID univoco a livello globale.
QIDO-RS: ricerca
QIDO-RS è il servizio di ricerca DICOMweb. Un client invia GET /studies, /series o /instances con parametri di query come PatientID, StudyDate o ModalitiesInStudy e l'header Accept application/dicom+json. L'archivio restituisce un array JSON in cui ogni attributo DICOM è identificato dal suo tag di otto cifre insieme alla sua rappresentazione di valore e ai valori.
GET /dicomweb/studies?PatientID=12345&StudyDate=20260101-20261231&ModalitiesInStudy=CT
Accept: application/dicom+json
La risposta è un array JSON di studi. Ogni attributo è indicizzato dal suo tag (gruppo ed elemento come otto cifre esadecimali), con la sua rappresentazione del valore e i valori:
[{
"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]}
}]
Qui 00201206 è il numero di serie correlate allo studio e 00201208 è il numero di istanze correlate allo studio. I numeri dei tag sono spiegati in Spiegazione dei tag DICOM.
WADO-RS: recupero
WADO-RS è il servizio di recupero DICOMweb. GET /studies/{StudyInstanceUID} restituisce uno studio completo come file DICOM Parte 10 in una risposta multipart; il suffisso /metadata restituisce le intestazioni come JSON senza dati pixel; /frames/{n} restituisce i pixel di un singolo frame; e /rendered restituisce un'immagine JPEG o PNG renderizzata dal server con parametri di finestra, viewport e qualità.
GET /studies/{study}conAccept: multipart/related; type="application/dicom"restituisce ogni istanza come file DICOM Parte 10, una parte ciascuna.GET /studies/{study}/metadatarestituisce le intestazioni di tutte le istanze come JSON, senza dati pixel. I visualizzatori chiamano questo per primi per costruire il layout, quindi recuperano i pixel frame per frame.GET /studies/{study}/series/{series}/instances/{instance}/frames/1restituisce i dati pixel di un frame, opzionalmente transcodificati (parametrotransfer-syntax).GET …/instances/{instance}/renderedconAccept: image/jpegrestituisce un'immagine renderizzata dal server, con parametriwindow,viewportequality. Questo è ciò che un portale paziente leggero utilizza per mostrare un'anteprima.
STOW-RS: archiviazione
STOW-RS è il servizio di archiviazione DICOMweb. Un client invia POST /studies con un corpo multipart/related in cui ogni parte è un file DICOM. L'archivio risponde con un elenco di istanze accettate e fallite e il motivo di ogni fallimento, e verifica che qualsiasi Study Instance UID fornito nell'URL corrisponda ai file caricati.
POST /dicomweb/studies
Content-Type: multipart/related; type="application/dicom"; boundary=abc
Ogni parte è un file DICOM. La risposta elenca le istanze accettate e fallite con le ragioni (classe SOP errata, UID duplicato). Gli archivi convalidano che l'UID dello studio nell'URL, se fornito, corrisponda ai file.
Sicurezza
DICOMweb non ha un proprio login; si basa su HTTPS e su ciò che il server mette davanti: token bearer OAuth 2.0 nella maggior parte degli archivi moderni, spesso combinati con ambiti SMART on FHIR quando il visualizzatore viene avviato da un EHR. La registrazione di chi ha recuperato quale studio è compito dell'archivio, non del protocollo.
Dove viene utilizzato
Ogni PACS principale e archivio neutrale per fornitori offre ora un endpoint DICOMweb, e gli archivi open-source (Orthanc, dcm4chee, Google Cloud Healthcare API, Azure DICOM service) sono DICOMweb-first. I visualizzatori web come OHIF sono costruiti interamente su QIDO-RS e WADO-RS. In un mondo FHIR, una risorsa ImagingStudy punta a un endpoint DICOMweb; i pixel non passano mai attraverso FHIR.
Anpheros non archivia immagini. Il referto di un paziente può contenere la refertazione radiologica come DocumentReference o DiagnosticReport e, dove un ospedale ne fornisce uno, un link al suo visualizzatore; i dati DICOM stessi rimangono nell'archivio dell'ospedale. Per ottenere le proprie immagini come paziente, vedere Come ottenere le immagini CT o MRI.
Pagine correlate
- FHIR ImagingStudy vs DICOMweb
- Spiegazione dei tag DICOM
- PACS vs RIS vs VNA
- Come ottenere le immagini CT o MRI (DICOM)
- Standard di interoperabilità sanitaria: la mappa
- DICOM vs FHIR per sviluppatori
Fonti
- DICOM PS3.18: Web Services
- DICOM PS3.7: Message Exchange
- Panoramica DICOMweb (DICOM Standards Committee)
- Documentazione OHIF Viewer
Domande frequenti
DICOMweb è uno standard diverso da DICOM?
No. È la Parte 18 dello stesso standard DICOM. Gli oggetti, i tag e gli UID sono identici; solo il trasporto cambia dal protocollo proprio di DICOM a HTTP.
Qual è la differenza tra WADO-URI e WADO-RS?
WADO-URI è il servizio più vecchio: un oggetto per richiesta, selezionato con parametri di query (?requestType=WADO&studyUID=…). WADO-RS è RESTful, può restituire studi o serie complete, metadati come JSON e singoli frame, ed è ciò che implementano i nuovi sistemi.
Posso usare DICOMweb senza un PACS?
È necessario un archivio che lo implementi. Server open-source come Orthanc e dcm4chee forniscono DICOMweb pronto all'uso e sono comunemente utilizzati per lo sviluppo e per piccole cliniche.
FHIR sostituisce DICOMweb?
No. FHIR descrive lo studio (ImagingStudy) e il referto (DiagnosticReport); DICOMweb fornisce le immagini. Un visualizzatore utilizza entrambi: FHIR per sapere che uno studio esiste, DICOMweb per mostrarlo.
Prova Anpheros Daily
Conserva i referti delle tue ecografie e analisi in un unico posto in Anpheros Daily, pronti da mostrare alla tua prossima visita.
Come funziona nell'app →
Anpheros sviluppa una cartella clinica che il paziente controlla e può condividere con qualsiasi studio medico, su una piattaforma HL7 FHIR R4, con sede in UE. Queste guide ti aiutano a comprendere e organizzare la tua salute; non sostituiscono il tuo medico.
Chi siamo →