DICOM: lo standard per l'imaging diagnostico e l'ecosistema open source

AIHealth

Piattaforma clinica on-premise con LLM locali, RAG su dati FHIR/DICOM, supporto alla diagnosi, follow-up remoto. Architettura progettata per il percorso MDR.

Scopri AIHealth →

Digital Health

Sviluppo di software medicale conforme agli standard normativi CE e MDR. Sistemi di supporto alle decisioni cliniche, integrazione AI nei flussi di lavoro clinici.

Scopri →

Genesi

DICOM — Digital Imaging and Communications in Medicine — è lo standard di riferimento per la rappresentazione, l’archiviazione e la trasmissione delle immagini mediche e dei dati clinici associati. Nasce come lavoro congiunto tra ACR (American College of Radiology) e NEMA (National Electrical Manufacturers Association): le prime versioni ACR-NEMA risalgono al 1985 e 1988, mentre la versione 3.0 — la prima davvero interoperabile su rete TCP/IP e tuttora identificata come DICOM 3.0 — è pubblicata nel 1993. Lo standard è mantenuto dal DICOM Standards Committee e aggiornato in modo continuo attraverso Supplements e Change Proposals.

Dal punto di vista formale, lo standard è pubblicato come NEMA PS3, articolato in parti (PS3.1 Introduction and Overview, PS3.3 Information Object Definitions, PS3.4 Service Class Specifications, PS3.5 Data Structures and Encoding, PS3.6 Data Dictionary, PS3.7 Message Exchange, PS3.8 Network Communication Support, PS3.10 Media Storage and File Format, PS3.14 Grayscale Standard Display Function, PS3.15 Security and System Management Profiles, PS3.18 Web Services, PS3.20 Imaging Reports) e oltre. Ogni parte ha una funzione distinta e può essere aggiornata indipendentemente.

Il modello informativo

Il cuore di DICOM è l’Information Object Definition (IOD): una struttura che descrive un oggetto del mondo reale — un’immagine TC, una RM, un referto strutturato — come collezione di attributi raggruppati in moduli. Gli attributi sono identificati da una coppia (Group, Element) in formato esadecimale: (0010,0010) Patient’s Name, (0010,0020) Patient ID, (0020,000D) Study Instance UID, (0020,000E) Series Instance UID, (0008,0016) SOP Class UID, (7FE0,0010) Pixel Data.

I riferimenti univoci sono costruiti come UID (Unique Identifier) nel formato OID ISO (1.2.840.10008.x.y.z per gli UID DICOM-registered). Ogni studio, serie, istanza e classe SOP ha un proprio UID.

Un SOP Class (Service-Object Pair) combina un IOD con un insieme di servizi: CT Image Storage (UID 1.2.840.10008.5.1.4.1.1.2), MR Image Storage, Ultrasound Image Storage, Basic Text SR Storage, Encapsulated PDF Storage, e decine di altri. La negoziazione tra due nodi DICOM riguarda quali SOP Class e quali Transfer Syntax essi supportano.

Le Transfer Syntax

Una Transfer Syntax specifica come gli attributi DICOM sono serializzati e se i Pixel Data sono compressi. Le più diffuse:

• Implicit VR Little Endian (1.2.840.10008.1.2) — default, VR dedotta dal Data Dictionary
• Explicit VR Little Endian (1.2.840.10008.1.2.1) — VR codificata esplicitamente nel datastream
• JPEG Baseline (1.2.840.10008.1.2.4.50) — compressione JPEG con perdita
• JPEG Lossless (1.2.840.10008.1.2.4.70) — JPEG senza perdita
• JPEG 2000 (1.2.840.10008.1.2.4.90 e .91) — senza e con perdita
• RLE Lossless (1.2.840.10008.1.2.5) — compressione a lunghezza variabile
• Deflate Explicit VR Little Endian (1.2.840.10008.1.2.1.99)

Ogni nodo dichiara, in Association Establishment, quali syntax accetta per ogni SOP Class.

I servizi DIMSE

I servizi di messaggistica DICOM sono noti come DIMSE (DICOM Message Service Elements):

• C-STORE — invio di un’istanza da un nodo a un altro (tipicamente dalla modalità al PACS)
• C-FIND — ricerca di studi/serie/istanze su un nodo (Query, usato dalla worklist o dal browser del PACS)
• C-MOVE — richiesta che un nodo invii a un terzo nodo una serie di istanze (retrieve indiretto)
• C-GET — retrieve diretto (meno usato in ambienti reali per limiti di negoziazione)
• C-ECHO — verifica di connettività (l’equivalente di ping applicativo DICOM)
• N-SET, N-ACTION, N-EVENT-REPORT — servizi normalized usati per esempio da MPPS (Modality Performed Procedure Step)

Il livello di rete (PS3.8) definisce il protocollo Upper Layer for TCP con porta IANA 104, ma nei deployment reali si usa comunemente la porta 11112. L’associazione tra due nodi negozia Application Entity Title, Presentation Context e Transfer Syntax.

Il file DICOM (PS3.10)

Un file DICOM (estensione .dcm, anche se l’estensione non è normativamente obbligatoria) ha un preambolo di 128 byte seguito dal magic DICM e da un File Meta Information Header in Explicit VR Little Endian, a cui segue il Dataset vero e proprio nella Transfer Syntax dichiarata. Il formato DICOMDIR descrive invece la struttura di un set di file su media rimovibile (tipicamente CD/DVD), utile nell’interscambio paziente-a-paziente e tra strutture.

Oltre i DIMSE: DICOMweb

Il lavoro su DICOMweb — servizi web RESTful che riprendono la semantica DICOM — è iniziato nei primi anni 2000 con WADO (Web Access to DICOM Objects, PS3.18, prima versione 2003) e si è evoluto verso un’interfaccia più moderna. I Supplements che introducono QIDO-RS (query), WADO-RS (retrieve) e STOW-RS (store) sono stati approvati nel 2011–2013, portando DICOM nel dominio delle API HTTP e preparando il terreno per l’integrazione con tecnologie web contemporanee.

IHE Radiology

Le specifiche DICOM da sole non bastano a garantire interoperabilità pratica tra sistemi di vendor diversi. Il framework IHE (Integrating the Healthcare Enterprise) ne estende l’uso con profili che descrivono flussi di lavoro completi. I principali in ambito radiologico:

• SWF (Scheduled Workflow) — orchestra HIS → RIS → modalità → PACS → refertazione
• PIR (Patient Information Reconciliation) — allineamento dei dati anagrafici dopo esecuzione
• PGP (Presentation of Grouped Procedures) — gestione di studi multi-procedura
• XDS-I.b — condivisione di immagini tra domini tramite XDS (integrazione con mondo documentale)
• IRWF.b (Import Reconciliation Workflow) — importazione di studi da CD/DVD esterni

In Italia i profili IHE sono alla base dei capitolati regionali per PACS e degli scambi tra strutture.

L’ecosistema open source

Intorno a DICOM esiste una pila open source solida e matura:

• DCMTK (OFFIS, Oldenburg) — toolkit C++ disponibile dagli anni ‘90, copre la quasi totalità dei servizi DIMSE, con tool a riga di comando (storescu, storescp, findscu, movescu, dcmdump, img2dcm). Licenza BSD-style
• dcm4che — toolkit Java con server di archiviazione dcm4chee Archive. La versione 3.x è la generazione attuale. Licenza MPL/LGPL
• GDCM (Grassroots DICOM) — libreria C++ di Mathieu Malaterre, BSD, utilizzata come backend DICOM di ITK e di progetti imaging più ampi
• Orthanc — server DICOM leggero in C++ di Sébastien Jodogne (CHU Liège), API REST integrata, disponibile come binario standalone multipiattaforma. Prima release pubblica 2012. GPL
• PixelMed — libreria Java di David Clunie, utilizzata in numerosi strumenti accademici e di validazione

Su questi toolkit si innestano viewer (OsiriX/Horos, Ginkgo CADx), archivi aziendali e strumenti di elaborazione. Nella pratica reale, un laboratorio o un piccolo reparto può costruire un nodo di test DICOM completo — ricezione, query/retrieve, visualizzazione, conversione — senza componenti commerciali.

Lo scenario italiano

L’adozione di DICOM negli ospedali italiani è ormai pervasiva: tutte le modalità (TC, RM, ecografia, mammografia, radiologia digitale, medicina nucleare) producono e scambiano immagini in DICOM. I PACS regionali e aziendali dialogano tra loro tramite DICOM e IHE XDS-I, con sempre maggiore integrazione verso il FSE per la pubblicazione dei referti e delle immagini diagnostiche.

Le sfide aperte non sono nello standard in sé, ma nella sua applicazione: Pixel Data privati e metadata vendor-specific complicano l’elaborazione, le strategie di de-identificazione per uso secondario richiedono attenzione (il Supplement 142 sulla Clinical Trial De-identification Profiles e la lista dei tag PS3.15 Annex E sono riferimenti obbligati), e la gestione dei volumi — un singolo studio TC multidetettore è nell’ordine delle centinaia di MB — impone scelte di compressione e storage consapevoli.

Riferimenti: DICOM Standard PS3.1–PS3.20, NEMA/MITA. DCMTK (OFFIS). dcm4che. GDCM. Orthanc (CHU Liège). IHE Radiology Technical Framework.