Introduzione allo standard Dicom 3.0 DICOM (Digital Imaging and Communications in Medicine) nasce da una collaborazione tra la NEMA (National Electrical Manufacturer Association) e l'ACR (American College of Radiology) finalizzata verso la ricerca di uno standard in grado di superare le incompatibilità esistenti fra le apparecchiature medicali fornite da vari costruttori. Lo standard, rilasciato ufficialmente nel 1993, si è evoluto dalle precedenti versioni 1.0 (1985) e 2.0 (1988) sviluppate da ACR e NEMA ed è in continuo sviluppo. Attualmente DICOM è il protocollo standard adottato da tutte le case costruttrici di apparecchiature diagnostiche di visualizzazione e di comunicazionedi ultima generazione. Concetti DICOM In DICOM l'informazione da rappresentare è detta IOD (Information Object Definition);a ciascun oggetto (IOD) sono associate operazioni (DIMSE service group) secondo il modello object-oriented. Una sintassi di trasferimento (transfer syntax) definisce il tipo di codifica dell'informazione nell'ambito dei trasferimenti su reti di calcolatori che implementano il DICOM. Struttura La figura 1.1 mostra le relazioni tra le maggiori strutture del DICOM secondo il modello entità-relazione. Figura 1.1: relazioni del modello informativo DICOM Definizione degli Information Object (IOD) Un IOD è una collezione di pezzi d'informazioni correlate, raggruppate in entità informative (information entity). Ciascuna entità contiene informazioni su un singolo oggetto es. su un paziente, su un'immagine, sulla modalità di acquisizione. Le entità informative contengono gli attributi, ciascuno dei quali descrive una singola informazione; ad esempio l'entità informativa "Paziente" contiene come attributi: il nome del paziente, la data di nascita, il sesso, il peso, ... Gli attributi che hanno una certa correlazione sono raggruppati in moduli (information object modules o IOM) che possono essere utilizzati in più di uno IOD. La figura 1.2 mostra un esempio di IOD. Figura 1.2: Image IOD SOP Class Una Service-Object Pair (SOP) Class, identificata da un SOP Class UID, è definita dall'unione di un IOD ed un DIMSE Service Group (DSG), che consiste in una o più operazioni applicabili ad un IOD. Service Class Una Service Class definisce un gruppo di una o più SOP Class correlate ad una specifica operazione (es. l'invio di immagini) che viene eseguita tra applicazioni in fase di comunicazione.Due SOP Classes definite da una singola definizione di Service Class possono differire per lo IOD, il DSG o entrambi. Due IOD differenti non potranno, comunque, far parte della stessa SOP Class. La figura 1.3 mostra le relazioni tra Service Classes, IOD, DSG e SOP Classes. Figura 1.3: relazioni tra Service Class, IOD, DSG e SOP Classes Esempio: la Service Class Storage La service class Storage definisce una classe di servizi a livello applicativo che permette il trasferimento di immagini, consentendo ad una applicazione, detta Application Entity o AE , di inviare immagini ad un' altra applicazione. In particolare una AE opererà nel ruolo SCU (client), l'altra in quello SCP (server). Le Storage SOP Class sono utilizzate per trasferire immagini da un'apparecchiatura (es. TC,MR,PET) verso workstation o archivi di file DICOM. Il data set DICOM Due applicazioni, in comunicazione secondo il protocollo DICOM, si accordano sulle SOP Classes supportate e su come dividere i ruoli SCU (client) ed SCP (server). Durante questa comunicazione l'informazione è codificata nel data set DICOM, che rappresenta un insieme di dati (data element); ciascun data element contiene la codifica dei valori degli attributi dell'oggetto, del quale il data set rappresenta un'istanza. Un data element è univocamente identificato da un data element tag rappresentato come una coppia ordinata di numeri tipo (gggg,eeee), ove gggg è il group number, eeee è l'element number appartenente al group; i data element appartenenti ad un certo data set sono ordinati in base al numero di gruppo; nell'ambito di un certo gruppo gli elementi hanno ordinamento crescente per element number e non possono avere più di un'occorrenza all'interno del data set. In dettaglio un data element si articola in quattro campi: - data element tag: una coppia ordinata di interi senza segno a 16 bit rappresentanti il Group Number seguito dall' Element Number. - value representation (VR): campo opzionale dipendente dalla transfer syntax; è composto da una stringa di due caratteri (2 byte) contenente la rappresentazione del valore dell'elemento. La VR di un certo data element tag è definita nel Data Dictionary come specificato nella parte 6 dello standard DICOM. - value length: è il numero di byte necessari a rappresentare il successivo campo valore (value field). - value field: contiene il valore del data element. Segue un esempio di codifica: Name Tag VR Value Field SOP Class UID (0008,0016) UI [1.2.840.10008.5.1.4.1...] SOP Instance UID (0008,0018) UI [1.2.999999.9.1.6.2] Study Date (0008,0020) DA [1996.10.29] Study Time (0008,0030) TM [15:18:59] Modality (0008,0060) CS [MR] Patient's Name (0010,0010) PN [Anonymized] Series Number (0020,0011) IS [1 ] Instance Number (0020,0013) IS [1 ] Rows (0028,0010) US [512] Columns (0028,0011) US [512] Nella parte 5 della documentazione sullo standard DICOM c'è il significato degli acronimi,ad esempio CS sta per Code String ossia una stringa di caratteri (2 byte) usata nell'esempio per rappresentare la modalità di acquisizione, IS sta per Integer String ossia un intero utilizzato nell'esempio per rappresentare il numero della serie e della istanza, US sta per Unsigned Short ossia un valore per rappresentare un intero senza segno, utilizzato nell'esempio per rappresentare il numero di righe e colonne della matrice d'acquisizione. Giuseppe Massa: ultimo aggiornamento: 20/09/2003