[intro | Notions de Bases | Agencement de l'information | Applet Dicom | EViewBox ! | Conclusions | Résumé | Références | Glossaire | Idées Reçues ]

La norme DICOM en Imagerie médicale

Base élémentaire :

Une norme orientée objet , un langage spécifique souvent difficile à comprendre... :

La norme DICOM est orientée objet , cela signifie que chaque objet DICOM ( le plus souvent une image ) contient à la fois les informations(le nom du patient, les pixels de l'image...) et les méthodes (ou fonctions ) que doit subir cette information .

Exemple :

• information : une image IRM ou scanner ... , en langage DICOM: Information Object..
• méthodes : à imprimer et/ou à sauvegarder , en DICOM un Service.

Le traitement DICOM d'une information consiste à apparier un objet DICOM( par exemple une image) à une fonction spécifique ou Service à appliquer à cet objet ( imprimer, sauvegarder , etc..) .

Ainsi la combinaison d'un " Information Object " (par ex une image ) avec un "Service" (par exemple l'impression de cette image ) est appelée : Service/Object Pair ou SOP.

Information Object + Service Class = Service /Object Pair ou SOP ou encore , par exemple :

Une Image + Son Impression = Un service DICOM

Cette parité Information/Service est l'élément principale de la conformité à la norme. Une machine en conformité à la norme doit gérer au minimum une classe de parité Service/Objet et pas seulement émettre ou recueillir des fichiers d'images à la norme DICOM.

Pour se conformer à une Classe de Parité Objet/Service (SOP Class) une machine (ou toute entité applicative DICOM, Application Entity AE ) doit pouvoir gérer un type particulier d'image et réaliser un type spécifique de traitement (ou service) correspondant à la définition de cette Classe de Parité , DICOM définit toutes les classes de parités possibles.

Par ailleurs la Classe de Parité Objet/Service doit spécifier si le service DICOM est employé en tant qu'utilisateur ( Service Class User ou SCU ) ou en tant que fournisseur (Service Class Provider SCP) . Exemple : Un scannerutilise le service que lui fournit le reprographe , le scanner est alors doté d'une Classe de Service Utilisateur SCU pour reprographe, le reprographe de son côté est doté d'une Classe de Service Fournisseur , SCP pour le scanner.

Un autre exemple :

Réalisation pratique de la connection de 2 machines :

Lorsqu'une entité applicative ( un scanner ) possède un Objet DICOM (une image à reproduire ) , si elle est en conformité DICOM pour utiliser classe de service d'impression (Service Class User of Printer), alors elle s'adresse à une Entité Applicative (le reprographe) qui fournit une classe de service d'impression correspondante (Service Class Provider for CT ).

Il en résulte alors une phase de négociation pendant laquelle les machines se mettent d'accord sur le type de données à échanger et la façon dont elle vont les échanger ( par exemple, pour un mot de deux octets, elles se mettent d'accord pour transmettre l'octet le plus significatif en premier ). Ce phase permet d'établir le "Presentation Context " , la façon dont est echangée l'information (la syntaxe de transfert ) est appelé Value Representation (VR ) , si l'octet le plus significatif est transmis en premier , il s'agit d'une VR Little Endian dans le cas inverse on parle de VR big endian.

Les différentes syntaxes de transfert proposées par les Entitées DICOM sont répertoriées dans les Documents de Conformité .

Classes de Service actuellement disponibles dans la norme :

Classes de Service :	Type de Service :
Verification (Verification Service Class)	Utilisé pour les tests , permet de savoir si les machines "s'entendent" mutuellement, cette classe n'est pas associée à un objet DICOM , elle renvoie l'information sous la forme d'un écho. (C-ECHO)
Storage(Storage Service Class) Media Storage Service Class	Permet le transfert et la sauvegarde des images entre deux entités DICOM. (CR,CT,MR Storage Service Class ) Il existe une variante : Media Storage Service Class qui spécifie les échanges entre 2 machines par l'intermédiaire d'un média (CD rom , disquettes etc...)
Query/Retrieve	Implémente des commandes types : FIND, MOVE, GET . FIND permet de demander une liste d'image, MOVE et GET permettent d'initier un transfert , qui sera en réalisé effectué via la classe "Storage Service Class"
Study Contents Notification	Utilisée pour notifier l'arrivée d'une nouvelle image ou série d'images, peut être utilisée pour initier un transfert ou vérifier si le transfert d'une série d'image est complet.
Print Management	Permet la connection avec un reprographe, spécifie le type d'image , (Couleurs, niveaux de gris etc.. )
Patient Management	Permet d'interfacer la machine au réseau hospitalier PACS ou HIS/RIS (Hospital Information Service/ Radiological Information Service ) Gestion des données des patients, démographie, admission et sortie des patients
Study Management	Création , gestion de rendez-vous, suivi des examens.
Result Management	Permet la gestion des résultats des examens.

Que signifie "Full Dicom" ?

Il s'agit d'une expression non définie dans la norme , il semble que "Full Dicom" signifie que la machine implémente la totalité des Classes de Service énumérées ci-dessus.