L’interoperabilità tra apparecchiature di imaging di marche diverse dipende meno dal formato del file .dcm e più dalla semantica dei servizi di rete che DICOM definisce: un file scambiato male tra due nodi che negoziano transfer syntax incompatibili è inutilizzabile quanto un’immagine che non c’è. Chiunque colleghi una modalità a un archivio lo scopre prima di ogni altra cosa.

DICOM — Digital Imaging and Communications in Medicine — è lo standard che NEMA pubblica come serie PS3, frutto del lavoro congiunto avviato negli anni Ottanta da ACR (American College of Radiology) e NEMA (National Electrical Manufacturers Association). Le edizioni ACR-NEMA del 1985 e 1988 precedono la versione 3.0 del 1993, prima a definire il trasporto su TCP/IP e tuttora indicata come DICOM 3.0. Lo standard non ha un numero di versione unico: è un insieme di parti che vengono aggiornate in modo indipendente tramite Supplements e Change Proposals approvati dal DICOM Standards Committee.

Contesto: un modello a oggetti, non un formato immagine

Leggere DICOM come “un JPEG con metadati clinici” è l’errore più frequente. Al centro c’è un modello informativo. Una Information Object Definition (IOD) descrive un’entità del mondo reale — un’immagine TC, una risonanza, un referto strutturato — come insieme di attributi raggruppati in moduli.

Ogni attributo è identificato da una coppia (Group,Element) esadecimale: (0010,0010) Patient’s Name, (0020,000D) Study Instance UID, (0008,0016) SOP Class UID, (7FE0,0010) Pixel Data. Gli identificatori univoci sono UID costruiti come OID ISO; quelli che DICOM assegna hanno radice 1.2.840.10008. Studio, serie, istanza e classe hanno ciascuno il proprio UID, ed è su questi che poggia ogni operazione di query e retrieve.

Una SOP Class (Service-Object Pair) lega un IOD a un insieme di servizi. CT Image Storage è 1.2.840.10008.5.1.4.1.1.2; esistono classi analoghe per RM, ecografia, referti testuali strutturati (Basic Text SR), PDF incapsulato. Quando due nodi si parlano, negoziano esattamente quali SOP Class e quali serializzazioni accettano.

Architettura: DIMSE e transfer syntax

I servizi di messaggistica sono i DIMSE (DICOM Message Service Elements). Quelli che si incontrano ogni giorno:

  • C-STORE — invio di un’istanza da un nodo a un altro, di solito dalla modalità all’archivio
  • C-FIND — interrogazione di studi, serie o istanze su un nodo
  • C-MOVE — richiesta a un nodo di inviare a un terzo nodo un insieme di istanze (retrieve indiretto)
  • C-GET — retrieve diretto, raro nei deployment reali per i vincoli di negoziazione che impone
  • C-ECHO — verifica di connettività applicativa
  • N-SET, N-ACTION, N-EVENT-REPORT — servizi normalized, alla base per esempio di MPPS (Modality Performed Procedure Step)

Il livello di rete (PS3.8) definisce un Upper Layer su TCP, porta IANA 104; nella pratica si incontra spesso la 11112. L’associazione tra due nodi negozia Application Entity Title, Presentation Context e Transfer Syntax.

La Transfer Syntax è il punto in cui l’interoperabilità si rompe più spesso. Stabilisce come gli attributi vengono serializzati e se i Pixel Data sono compressi. Le più ricorrenti:

  • 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 scritta nel datastream
  • JPEG Baseline (1.2.840.10008.1.2.4.50) — compressione con perdita
  • JPEG Lossless (1.2.840.10008.1.2.4.70)
  • JPEG 2000 (1.2.840.10008.1.2.4.90 e .91)
  • RLE Lossless (1.2.840.10008.1.2.5)

Un nodo che riceve istanze in JPEG 2000 ma non lo dichiara tra i propri presentation context rifiuta la transfer syntax in fase di associazione: il C-STORE fallisce prima ancora di toccare i pixel. Per diagnosticare questi rifiuti si legge il log dell’associazione, non il file.

Il file e i suoi limiti (PS3.10)

Un file conforme a PS3.10 ha un preambolo di 128 byte, il magic DICM, un File Meta Information Header in Explicit VR Little Endian e poi il Dataset nella transfer syntax dichiarata in testa. L’estensione .dcm è una convenzione, non un obbligo normativo. Il DICOMDIR descrive un set di file su media rimovibile, formato pensato per l’interscambio su CD/DVD ancora diffuso tra le strutture.

Il trasporto su file si scontra con la propria granularità: un singolo studio TC multidetettore arriva alle centinaia di MB distribuite su migliaia di istanze. Spostare quello stato tra sistemi via media fisico, o anche via C-MOVE, mal si presta alle integrazioni web, dove una risorsa la si indirizza con un URL.

Punto critico: il passaggio ai servizi REST

Da circa un decennio DICOM espone i propri oggetti anche via HTTP. Il primo passo è WADO (Web Access to DICOM Persistent Objects, PS3.18), che recupera un’istanza nota tramite una richiesta HTTP con i suoi UID come parametri. È un servizio di sola lettura, per istanza singola, pensato per l’inclusione nelle pagine cliniche.

Il lavoro più recente porta la semantica DIMSE su un’interfaccia RESTful coerente, approvato come Supplements nel 2011:

  • WADO-RS (Supplement 161) — retrieve di studi, serie o istanze e dei loro metadati
  • STOW-RS (Supplement 163) — Store Over the Web, l’equivalente di C-STORE su HTTP
  • QIDO-RS (Supplement 166) — Query based on ID for DICOM Objects, l’equivalente di C-FIND

La differenza rispetto ai DIMSE non è solo di trasporto. Una query QIDO-RS è un GET con parametri nell’URL e risposta in JSON o XML; un retrieve WADO-RS indirizza /studies/{uid}/series/{uid}/instances/{uid} come una qualsiasi risorsa web. A quel punto un archivio di immagini lo interroga anche codice che non sa nulla dell’associazione DICOM, delle sue transfer syntax o della porta 11112 — al prezzo, oggi, di un supporto ancora disomogeneo tra i vendor e di parti dello standard che cambiano in fretta.

Cosa si costruisce con i toolkit Open Source

La pila Open Source attorno a DICOM è ormai matura: un nodo di test completo lo si mette in piedi senza un solo componente commerciale.

Gli strumenti che uso:

  • DCMTK (OFFIS, Oldenburg) — toolkit C++ con strumenti a riga di comando (storescu, storescp, findscu, movescu, dcmdump, img2dcm), licenza BSD-style
  • dcm4che — toolkit Java, generazione 3.x, con l’archivio dcm4chee; licenza MPL/LGPL
  • GDCM (Grassroots DICOM) di Mathieu Malaterre — libreria C++ BSD, backend DICOM di ITK
  • Orthanc di Sébastien Jodogne (CHU Liège) — server leggero in C++ con API REST integrata, binario standalone multipiattaforma, prima release pubblica nel luglio 2012, licenza GPL
  • PixelMed di David Clunie — libreria Java usata in molti strumenti di validazione

Su questi si appoggiano viewer come OsiriX e Ginkgo CADx. Con DCMTK e Orthanc su una sola macchina si ricostruisce l’intero ciclo: ricezione via C-STORE, query/retrieve, esposizione REST, ispezione del dataset con dcmdump.

Limiti

Lo standard descrive la sintassi; l’interoperabilità reale richiede di concordare il flusso. È il compito dei profili IHE (Integrating the Healthcare Enterprise) — Scheduled Workflow, Patient Information Reconciliation, XDS-I.b per la condivisione tra domini — che fissano come i servizi DICOM si compongono in un percorso clinico. Restano fuori dallo standard, e quindi a carico dell’integratore, i Pixel Data privati e i metadati specifici del vendor, e le strategie di de-identificazione per uso secondario, per cui i riferimenti sono il Supplement 142 e la lista di attributi in PS3.15 Annex E. Il software cita gli UID; chi integra deve verificare che i due lati negozino davvero gli stessi.

Immagine di copertina: Griglia di 34 sezioni assiali in scala di grigi di una tomografia computerizzata del cervello, dalla base del cranio alla volta — foto di Department of Radiology, Uppsala University Hospital, CC0 — https://commons.wikimedia.org/wiki/File:Computed_tomography_of_human_brain_-_large.png