Il protocollo DICOM è alla base del medical imaging da decenni. Modalità diagnostiche, PACS, workstation e sistemi di archiviazione utilizzano lo standard per scambiare immagini e informazioni cliniche in modo interoperabile.
Nel frattempo, però, il mondo del software è cambiato profondamente.
Oggi molte applicazioni vengono eseguite direttamente nel browser, i sistemi sono sempre più distribuiti, le architetture cloud sono diventate comuni e servizi differenti devono comunicare attraverso API facilmente integrabili.
Anche il medical imaging si è quindi trovato davanti a una nuova esigenza: rendere immagini e studi DICOM accessibili alle applicazioni web senza rinunciare alla struttura e all’interoperabilità dello standard originale.
È proprio per rispondere a questa esigenza che nasce DICOMweb.
DICOMweb porta alcuni dei principali workflow DICOM all’interno del paradigma HTTP e REST, permettendo a viewer web, piattaforme di telemedicina, sistemi cloud e pipeline di intelligenza artificiale di dialogare con PACS e archivi medicali utilizzando tecnologie familiari al moderno sviluppo software.
Non significa sostituire DICOM.
Significa estenderlo al web.
Perché DICOMweb è diventato così importante
Il DICOM tradizionale è stato progettato in un periodo in cui i sistemi medicali comunicavano principalmente all’interno di reti ospedaliere dedicate.
Una modalità CT può inviare uno studio a un PACS utilizzando C-STORE. Una workstation può interrogare un archivio tramite C-FIND e recuperare immagini attraverso C-MOVE o C-GET.
Questi meccanismi continuano a essere estremamente importanti e vengono ancora utilizzati ogni giorno in migliaia di infrastrutture sanitarie.
Il problema nasce quando il client non è più una workstation DICOM tradizionale.
Pensiamo a un viewer che gira interamente nel browser, a una piattaforma di telemedicina, a un’applicazione SaaS oppure a un servizio AI eseguito in cloud.
Questi sistemi sono normalmente progettati intorno a HTTP, HTTPS, API REST, autenticazione web e infrastrutture distribuite.
Integrare direttamente i protocolli DICOM DIMSE all’interno di queste architetture è possibile, ma introduce spesso un livello di complessità che il resto dello stack applicativo non utilizza.
DICOMweb crea un ponte tra questi due mondi.
Il dato continua a essere DICOM, ma diventa accessibile attraverso servizi web standardizzati.
Questo permette agli sviluppatori di lavorare con tecnologie web mantenendo allo stesso tempo la semantica e la struttura del medical imaging.
Cos’è DICOMweb
DICOMweb è la parte dello standard DICOM dedicata ai servizi web.
Le sue API sono definite all’interno di DICOM PS3.18 e permettono di cercare, recuperare e memorizzare oggetti DICOM utilizzando HTTP o HTTPS.
I tre servizi che si incontrano più frequentemente sono QIDO-RS, WADO-RS e STOW-RS.
I nomi possono sembrare poco intuitivi all’inizio, ma descrivono tre operazioni molto semplici.
QIDO-RS viene utilizzato per cercare studi, serie e immagini.
WADO-RS permette di recuperare immagini e relativi metadati.
STOW-RS permette invece di inviare nuovi oggetti DICOM verso un archivio.
Insieme costituiscono la base di moltissime architetture moderne di medical imaging.
QIDO-RS: trovare gli studi senza scaricare le immagini
La prima necessità di un’applicazione di imaging è quasi sempre individuare i dati disponibili.
Un viewer, per esempio, potrebbe dover mostrare tutti gli esami CT di un determinato paziente oppure tutte le serie appartenenti a uno specifico studio.
QIDO-RS permette di effettuare queste interrogazioni attraverso richieste HTTP.
Il risultato non è necessariamente l’immagine stessa. L’applicazione può recuperare prima i metadati dello studio e decidere successivamente quali contenuti siano realmente necessari.
Questo aspetto è particolarmente importante per le applicazioni web.
Un esame CT può essere composto da centinaia o migliaia di immagini. Scaricare l’intero studio prima ancora di conoscere il suo contenuto sarebbe inefficiente e renderebbe l’esperienza utente molto lenta.
Con QIDO-RS, il client può esplorare la struttura dell’archivio, identificare studi e serie rilevanti e richiedere soltanto ciò che serve.
Dal punto di vista dell’architettura, cambia molto.
Il viewer non deve avere una conoscenza completa dell’archivio né mantenere una propria copia del database PACS. Può interrogare direttamente il repository attraverso un’interfaccia standardizzata.
WADO-RS: recuperare immagini e metadati nel browser
Una volta individuato lo studio, bisogna visualizzarlo.
È qui che entra in gioco WADO-RS.
WADO significa Web Access to DICOM Objects e consente di recuperare oggetti DICOM, immagini, frame e metadati attraverso HTTP.
Per un viewer web questo è un elemento fondamentale.
Il browser può richiedere le immagini progressivamente, caricando inizialmente soltanto ciò che deve essere visualizzato e recuperando il resto mentre l’utente naviga nello studio.
Questa modalità di accesso è molto diversa dal concetto tradizionale di scaricare l’intero esame prima di iniziare la visualizzazione.
Quando il dataset è voluminoso, come accade frequentemente con CT e MR, lo streaming progressivo può avere un impatto importante sull’esperienza dell’utente.
La velocità percepita non dipende infatti soltanto dalla banda disponibile, ma anche da come viene organizzato il caricamento dei dati.
Un viewer può dare priorità alle immagini immediatamente visibili, anticipare il caricamento delle slice successive e recuperare in background altre informazioni necessarie per ricostruzioni MPR o visualizzazioni tridimensionali.
DICOMweb diventa quindi non soltanto un’interfaccia di comunicazione, ma uno degli elementi su cui costruire la strategia di caricamento del viewer.
STOW-RS: quando l’applicazione deve scrivere nel PACS
Una piattaforma moderna di medical imaging non si limita necessariamente a leggere immagini.
Può anche produrre nuovi dati.
Un medico potrebbe creare una nuova serie derivata. Un sistema potrebbe generare una Secondary Capture. Un algoritmo AI potrebbe produrre una segmentazione o uno Structured Report.
Questi oggetti possono essere inviati nuovamente all’archivio attraverso STOW-RS.
È un aspetto particolarmente interessante perché trasforma DICOMweb da semplice meccanismo di visualizzazione a vero elemento di integrazione.
Pensiamo, ad esempio, a una pipeline AI.
Il sistema recupera uno studio dal PACS, esegue l’inferenza e genera una segmentazione. Se il risultato viene trasformato in un oggetto DICOM SEG, può essere reinserito nell’infrastruttura e associato allo studio originale.
Quando il medico riapre l’esame, può quindi trovare anche il risultato prodotto dall’algoritmo.
Lo stesso principio può essere applicato a misure strutturate, report, immagini derivate o altri output generati durante il workflow.
L’AI non rimane quindi un sistema esterno che produce semplicemente un file.
Il risultato può rientrare nel normale ecosistema del medical imaging.
DICOMweb non sostituisce DIMSE
Quando viene introdotta una tecnologia più recente, è facile descriverla come il sostituto di quella precedente.
Nel caso di DICOMweb, questa lettura sarebbe però troppo semplicistica.
I servizi DICOM tradizionali continuano a essere molto efficaci per numerosi workflow.
Una modalità diagnostica può continuare a utilizzare C-STORE per inviare gli studi al PACS. Una workstation presente nella rete ospedaliera può utilizzare C-FIND e C-MOVE. Storage Commitment può continuare a garantire che un archivio abbia preso correttamente in carico le immagini.
Allo stesso tempo, un viewer web può utilizzare QIDO-RS e WADO-RS per accedere agli stessi studi.
Le due tecnologie possono quindi convivere all’interno della stessa infrastruttura.
Ed è probabilmente questo lo scenario più comune nel mondo reale.
La parte più vicina ai dispositivi e alle modalità continua spesso a utilizzare DIMSE, mentre applicazioni web, servizi cloud e software più recenti accedono agli stessi dati tramite DICOMweb.
Non si tratta quindi necessariamente di scegliere tra DICOM tradizionale oppure DICOMweb.
La vera domanda è quale interfaccia sia più adatta a ogni componente del sistema.
Perché DICOMweb è particolarmente adatto ai viewer web
La visualizzazione medicale nel browser è uno dei casi in cui DICOMweb mostra maggiormente i propri vantaggi.
Un moderno viewer può essere sviluppato utilizzando JavaScript e WebGL ed eseguito senza installazione direttamente all’interno del browser.
Questo permette di integrare il medical imaging in portali clinici, piattaforme di telemedicina e software verticali senza richiedere all’utente una workstation separata.
Ma il viewer deve comunque accedere alle immagini.
DICOMweb rende questa integrazione molto più naturale perché utilizza lo stesso modello di comunicazione già adottato dal resto dell’applicazione.
Autenticazione, autorizzazione, API gateway e infrastrutture cloud possono essere integrate nel normale stack web.
Anche l’esperienza utente può beneficiarne.
Un’applicazione può presentare subito le informazioni dello studio, caricare progressivamente le immagini necessarie e attivare funzionalità più avanzate soltanto quando richiesto.
Visualizzazione 2D, MPR, volume rendering e segmentazione possono quindi essere costruite sopra un’infrastruttura in cui il dato viene recuperato dinamicamente.
È proprio in questo tipo di architettura che tecnologie come DICOM Vision e il nostro imaging engine Lumen possono essere utilizzate per realizzare esperienze di visualizzazione completamente web-based.
DICOMweb e cloud medical imaging
L’altro scenario naturale è il cloud.
Portare immagini medicali in infrastrutture cloud non significa semplicemente spostare un PACS su una macchina remota.
Il cloud favorisce architetture in cui servizi differenti comunicano attraverso API.
Un componente può occuparsi dell’archiviazione, un altro della visualizzazione, un altro dell’analisi AI e un altro ancora dell’integrazione con il sistema clinico.
DICOMweb permette a questi servizi di accedere allo stesso repository mantenendo un’interfaccia standard.
Questo rende più semplice separare le responsabilità.
Il viewer non deve conoscere il funzionamento interno dell’algoritmo AI. Il servizio AI non deve conoscere l’interfaccia del viewer. Entrambi devono soltanto sapere come accedere correttamente agli studi e come restituire gli oggetti prodotti.
È uno dei motivi per cui DICOMweb si presta bene ad architetture modulari e a microservizi.
Naturalmente, utilizzare HTTP non rende automaticamente l’infrastruttura sicura.
Autenticazione, autorizzazione, cifratura, gestione delle identità e audit devono essere progettati come parte dell’architettura complessiva.
Ma DICOMweb rende possibile integrarli utilizzando pattern tecnologici già comuni nel mondo web.
DICOMweb e FHIR: due standard complementari
DICOMweb viene spesso nominato insieme a FHIR.
Anche in questo caso non si tratta di tecnologie alternative.
Gestiscono aspetti differenti.
DICOM continua a essere estremamente ricco nella rappresentazione delle immagini e degli oggetti derivati dal medical imaging.
FHIR permette invece di rappresentare e scambiare informazioni appartenenti al contesto clinico più ampio.
Un’applicazione potrebbe quindi utilizzare FHIR per recuperare informazioni sul paziente, sull’ordine o sul referto e DICOMweb per accedere alle immagini dello studio corrispondente.
L’utente vede un unico workflow, anche se dietro l’interfaccia collaborano standard differenti.
È proprio questa complementarità a rendere interessante l’integrazione.
Il medical imaging smette di essere un’isola separata e diventa una parte del più ampio ecosistema informativo sanitario.
DICOMweb come infrastruttura per l’intelligenza artificiale
Anche le pipeline AI possono beneficiare dello stesso approccio.
Un algoritmo di medical imaging deve prima di tutto accedere ai dati.
In un sistema tradizionale questo può significare costruire un client DICOM capace di interrogare il PACS e recuperare gli studi attraverso i protocolli DIMSE.
Con DICOMweb, la pipeline può invece interrogare l’archivio attraverso API HTTP, recuperare le serie necessarie e inviare successivamente i risultati.
Questo approccio è particolarmente interessante quando i modelli vengono eseguiti come servizi containerizzati o all’interno di infrastrutture cloud.
Il modello può rimanere indipendente dal PACS specifico utilizzato dall’ospedale.
L’integrazione viene gestita da un livello intermedio che si occupa di autenticazione, interrogazione degli studi, conversione dei dati e gestione dei risultati.
L’algoritmo può così concentrarsi sul proprio compito.
DICOMweb diventa quindi uno degli elementi che permettono di trasformare una pipeline sperimentale in un componente realmente integrabile.
È lo stesso principio che abbiamo affrontato parlando di industrializzazione dell’AI nel medical imaging: il modello rappresenta soltanto una parte del sistema.
Cosa cambia per chi sviluppa software medicale
Per una software house o un produttore di dispositivi, il vantaggio più evidente di DICOMweb non è semplicemente poter utilizzare HTTP.
È la possibilità di separare meglio il livello di imaging dal resto dell’applicazione.
Il software può interrogare un archivio attraverso un’interfaccia standard senza dipendere necessariamente dall’implementazione specifica del PACS.
Un viewer può essere distribuito come applicazione web.
Una piattaforma di telemedicina può integrare direttamente la visualizzazione dello studio.
Un servizio AI può recuperare immagini ed eventualmente restituire nuovi oggetti.
Un portale clinico può mostrare informazioni provenienti da FHIR e aprire contemporaneamente lo studio DICOM corrispondente.
Tutti questi scenari diventano più semplici quando il medical imaging può partecipare allo stesso modello architetturale utilizzato dal resto del software.
Naturalmente, lo standard non elimina tutta la complessità.
Bisogna comunque gestire compatibilità tra implementazioni, performance, transfer syntax, autenticazione, caching, caricamento progressivo e grandi volumi di dati.
Ma evita di dover reinventare l’interfaccia tra applicazione e archivio.
Ed è precisamente questo il valore dell’interoperabilità.
Dal PACS all’applicazione web
Negli ultimi anni il medical imaging si è progressivamente allontanato dal modello in cui ogni funzionalità viveva all’interno di una workstation dedicata.
Le immagini vengono sempre più spesso utilizzate da applicazioni differenti: viewer browser-based, sistemi di telemedicina, strumenti di collaborazione, piattaforme AI e software verticali.
DICOMweb rende possibile questa evoluzione senza abbandonare DICOM.
La modalità può continuare a produrre immagini attraverso il workflow tradizionale. Il PACS può continuare a essere il repository centrale. Allo stesso tempo, nuovi servizi possono accedere agli stessi dati attraverso interfacce web standardizzate.
È una trasformazione importante perché permette di costruire software medicale più modulare e più facilmente integrabile.
Il punto non è portare semplicemente DICOM nel browser.
È permettere alle immagini medicali di diventare una componente naturale delle moderne architetture software.
DICOMweb in D/Vision Lab
In D/Vision Lab lavoriamo con DICOM e medical imaging sia a livello di connettività sia a livello di visualizzazione e applicazioni.
Utilizziamo DICOMweb per integrare archivi e PACS con viewer web, piattaforme medicali e servizi di elaborazione, mantenendo allo stesso tempo compatibilità con i workflow DICOM tradizionali quando necessario.
Con DICOM Vision affrontiamo il livello applicativo e di visualizzazione, mentre tecnologie come Lumen permettono di costruire esperienze avanzate di imaging 2D e 3D direttamente sul web.
Con DICOM Pulse, invece, gestiamo il livello di connettività DICOM più vicino a software, dispositivi e infrastrutture medicali.
L’obiettivo non è scegliere una singola tecnologia per ogni scenario.
È costruire l’architettura più adatta al workflow reale, utilizzando standard e componenti differenti dove portano effettivamente valore.
Perché l’interoperabilità funziona davvero quando la tecnologia rimane sullo sfondo e permette semplicemente ai sistemi di comunicare.
