dimanche 1 juillet 2018

Les données en DICOM

1. Les éléments DICOM


1.1 Le dictionnaire de données


Dans la partie « Généralités sur le standard DICOM », il a été dit que pour éviter des erreurs et assurer un certain degré de traçabilité, il fallait lier une image à son contexte (pour qui, par qui, pourquoi, comment, etc.).
Afin de réaliser cela, DICOM définit une liste de données contenant les éléments pouvant être utiles dans le milieu de la médecine numérique. Cette liste est exposée dans un dictionnaire de données représenté par la partie PS3.6 du standard. Dans ce dictionnaire, on peut trouver des éléments comme le nom du patient, sa date de naissance, son identifiant local, la date d'un examen d'imagerie, le type de machine ayant produit l'imagerie, son modèle, le nom du prescripteur de l'examen, le nom de la personne ayant réalisé l'examen, etc.
Le dictionnaire de données DICOM définit ainsi plus de 2000 éléments en tout genre. Chacun de ces éléments dispose d'un nom descriptif appelé « Name ».
Pour mettre de l'ordre dans une telle quantité d'éléments, DICOM a classé ces derniers par groupes. Par exemple, des éléments comme le nom du patient, sa date de naissance, son genre, son poids, sa taille, etc. ont en commun qu'ils concernent tous le patient. DICOM a donc crée un groupe « patient ». D'autres éléments comme la dimension d'une image, ses pixels, le fait qu'elle soit en couleur ou non, ont en commun qu'il s'agit de caractéristiques d'une image. DICOM a donc crée un groupe « image ». Ainsi, tous les éléments appartiennent à un groupe.
Pour continuer dans sa démarche, DICOM a attribué à chaque groupe un numéro unique. Par exemple, le groupe « patient » a le numéro 0010, le groupe « image » a le numéro 0028.
Enfin, pour identifier les éléments appartenant à un groupe, DICOM a également attribué un identifiant unique à chaque élément d'un groupe.
Ainsi, chaque élément du dictionnaire DICOM se voit attribué un identifiant unique appelé tag, qui prend la forme d'un couple (groupe-élément). Chacune des composantes de ce couple est un entier de 4 chiffres en hexadécimal (de 0 à F).
Exemples:
  • le tag (0010, 0010) correspond à l'élément dont le nom est « Patient Name » ;
  • le tag (0010, 0020) représente l'élément dont le nom est « Patient ID » ;
  • le tag (0010, 0030) indique l'élément dont le nom est « Patient's Birth Date » ;
  • le tag (0028, 0010) symbolise l'élément dont le nom est « Rows » en pixel ;
  • le tag (0028, 0011) correspond à l'élément dont le nom est « Column » en pixel ;
  • le tag (7FE0, 0010) est l'identifiant de l'élément dont le nom est « Pixel Data ».

Remarque : La composante représentant le groupe dans le dictionnaire de données DICOM est toujours un nombre pair. Les nombres impairs étant réservés aux tags propriétaires, c'est-à-dire non répertoriés par le standard et spécifiques à un constructeur ou un éditeur.

Remarque : Le groupe FFFF est réservé pour le standard et ne peut donc pas être utilisé par un éditeur ou constructeur.

Remarque : On peut se référer à un élément par son nom descriptif ou son identifiant de manière équivalente. L'identifiant (tag) étant plus court, de taille fixe et avec un format hexadécimal strict, toutes les applications l'utilisent pour se référer à un élément DICOM.

1.2 Le type de données dans DICOM (aka VR)


De par la multiplicité d'éléments que l'on peut trouver dans le dictionnaire de données, il est évident que tous ne sont pas du même type. En effet, on peut trouver :
  • des données qui expriment une distance, dont l'unité de mesure est le millimètre ;
  • des données qui représentent une durée, dont l'unité est la seconde ;
  • des données qui indiquent un point dans le temps, dont l'unité est une date ;
  • des données comme le nom du patient exprimé par une chaîne de caractères alphanumérique ;
  • etc.
Afin de représenter ces différentes catégories d'informations, le standard définit 31 types de données de base tels que:
  • le type DA pour une date: chaîne de 8 caractères sous la forme YYYYMMDD; ou YYYY correspond à une année, MM correspond à un mois de l'année (de 01 à 12) et DD correspond à un jour dans le mois (de 01 à 31). Exemple : 19930822 correspond au 22 août 1993 ;
  • le type UI pour les identifiants : chaîne de 64 caractères maximum composée uniquement de chiffres (0 à 9) et du caractère « . ». Exemple : 1.2.840.10008.1.2 ;
  • le type PN pour un nom de personne: chaîne de 64 caractères maximum sous la forme nomFamille^PremierPrénom^SecondPrénom^Prefix^Suffix, où le caractère « ^ » est le séparateur des 5 composantes du nom. Chacune des composantes peut être vide ;
  • ou encore le type OB pour indiquer un flux d'octets.
Ces types sont connus sous le nom Value Representation (VR).

Remarque : Chaque VR est désignée par un nom à 2 lettres (ex. AE, CS, DA, TM).

De manière grossière, les 31 types peuvent être répartis en 7 catégories:
  • les VR de format texte : AE, CS, LO, LT, SH, ST, UC, UI, UR, UT ;
  • les VR de format date/heure : DA, DT, TM, AS ;
  • les VR de format nombre texte : IS, DS ;
  • les VR de format binaire : FL, FD, OB, OD, OF, OL, OW, SL, SS, UL, UN, US ;
  • une VR pour les noms de personnes : PN ;
  • une VR pour les séquences : SQ ;
  • une VR pour les tags  : AT ;

1.3 La Value Multiplicity (VM)


Parmi tous les éléments du dictionnaire, certains peuvent avoir une seule valeur (un patient ne peut avoir qu'une date de naissance par exemple) ; tandis que d'autres peuvent en avoir plusieurs - un patient peut porter différents noms (un nom de naissance et un nom d'usage par exemple). Pour cette raison, DICOM a introduit la notion de Value Multiplicity (VM). Cette VM peut posséder une valeur stricte ou un plage de valeurs. Chaque élément DICOM a donc une VR qui indique si un élément peut disposer ou non de plusieurs valeurs.
Exemple :
  • le tag (0028, 0030) Pixel Spacing a une VM de 2 (une valeur pour la distance horizontale et une pour la distance verticale) ;
  • le tag (0010, 0030) Patient's Birth Date a une VM de 1 ;
  • le tag (0010, 1001) OtherPatientNames a une VM de 1-n (plusieurs noms sont possibles).
Pour résumer : DICOM définit une liste d'éléments typés (VR), identifiés (tag) de manière unique et ayant un nombre de valeurs spécifié (VM). Ces éléments sont appelés tag ou attribut ou encore DICOM element.

Extrait de quelques éléments du dictionnaire de données
Tag Name Keyword VR VM
 (0010,0020)  Patient ID Patient​ID LO 1
 (0010,0021)  Issuer of Patient ID Issuer​Of​Patient​ID LO 1
(0010,0022) Type of Patient ID Type​Of​Patient​ID CS 1
(0010,0024) Issuer of Patient ID Qualifiers Sequence Issuer​Of​Patient​ID​Qualifiers​Sequence SQ 1
(0010,0026) Source Patient Group Identification Sequence Source​Patient​Group​Identification​Sequence SQ 1
(0010,0027) Group of Patients Identification Sequence Group​Of​Patients​Identification​Sequence SQ 1
(0010,0028) Subject Relative Position in Image Subject​Relative​Position​In​Image US 3
(0010,0030) Patient's Birth Date Patient​Birth​Date DA 1
(0010,0032) Patient's Birth Time Patient​Birth​Time TM 1
(0010,0033) Patient's Birth Date in Alternative Calendar Patient​Birth​Date​In​Alternative​Calendar LO 1
(0010,0034) Patient's Death Date in Alternative Calendar Patient​Death​Date​In​Alternative​Calendar LO 1
(0010,0035) Patient's Alternative Calendar Patient​Alternative​Calendar CS 1
(0010,0040) Patient's Sex Patient​Sex CS 1

Remarque : la colonne Keyword a récemment été ajoutée au standard. Cette donnée d'un seul mot est très similaire au nom descriptif et fournit une alternative à l'identifiant (tag) pour être utilisée en XML ou HTTP.

2. Les objets DICOM


Un objet DICOM (appelé Information Object) est un ensemble d'éléments DICOM (ensemble de tags). Ces objets sont la pierre angulaire du standard DICOM.
Objet DICOM
Un objet DICOM n'est pas toujours un enchaînement linéaire d'éléments DICOM. En effet, parmi tous les types (les VR) définis par le standard, il en existe un qui est particulier. Ce type s'appelle SQ (pour SeQuence). Il permet de contenir un ou plusieurs autres objets DICOM (une séquence d'éléments DICOM) qui peuvent également être des séquences, et donc contenir à leur tour d'autres éléments DICOM.
Objet DICOM imbriqué
On obtient donc une structure imbriquée qui peut vite devenir complexe.

Remarque : Dans un objet DICOM, les éléments doivent être organisés par ordre croissant des tags (cf. PS 3.5 - section 3.10 définition de DataSet).

La définition des objets DICOM (aka IOD)


Un objet est un ensemble d'éléments DICOM. Mais avec plus de 2000 tags dans le dictionnaire de données, comment structurer tout cela ?
Il ne servirait à rien de mettre l'intégralité des éléments définis dans le dictionnaire DICOM dans un même objet, de ne remplir que ceux qui nous intéressent et de laisser les autres vides. Cela prendrait trop de place.
De plus, mélanger des éléments spécifiques à une IRM, tel que (0018, 0087) magnetic field strength, avec des éléments ne concernant que le scanner (comme le kVp dans l'élément (0018, 0060)) ne semble pas très judicieux.
Pour résoudre ce problème, DICOM définit des Information Object Definition (IOD) qui représentent la structure d'un objet DICOM (les éléments à mettre dedans).
Ces IOD sont décrits dans la partie PS3.3 du standard DICOM. Il en existe environ quatre-vingt qui permettent de spécifier :
  • les éléments DICOM à inclure dans un objet ;
  • si ces éléments sont obligatoires ou optionnels ;
  • et la valeur que ces objets peuvent prendre (au travers des VR, d'énumération de valeurs possibles ou de jeux de valeurs).

Par exemple il existe un objet :
Remarque : De manière plus strict, DICOM utilise un système un peu plus hiérarchisé pour définir des objets. Il regroupe des briques de base que sont les DICOM elements en des paquets appelés Modules. Les Modules sont eux même combinés pour former des Informations Entities (IE). Enfin, les IE sont assemblés pour former les Informations Object Définition (IOD) qui sont nos objets DICOM finaux. Il n'en reste pas moins qu'un objet DICOM est au final, un ensemble d'attributs DICOM.



3. Le Modèle hiérarchique DICOM


Que savons-nous de l'organisation des données en DICOM jusqu'à présent ?
DICOM organise les éléments de son dictionnaire en les regroupant, les identifiant et en les typant. Il spécifie également des assemblages d'éléments définis dans des IOD. Mais il reste à refléter un aspect important.
Prenons un exemple :
Un patient se rend dans un hôpital pour subir un examen d'imagerie (disons un PET-SCAN). Cet examen est composé de deux séries d'images, un PET et un SCAN. Chacune de ces séries est elle-même constituée de plusieurs images. Ce même patient, peut très bien revenir quelques temps après et faire une IRM.
Ainsi, un patient peut avoir plusieurs examens d'imagerie. Chacun de ces examens peut être composé d'une ou plusieurs séries ; qui elles-mêmes peuvent être composées d'une ou plusieurs images.
Une hiérarchie Patient-Examen-Série-Image est donc nécessaire.
Afin de représenter ce modèle hiérarchique, DICOM assigne à chacun des 4 niveaux un identifiant unique. Pour le niveau Patient, c'est l'élément « (0010,0020) Patient ID », pour le niveau Examen c'est l'élément « (0020,000D) Study Instance UID », au niveau série, l'identifiant est l'élément « (0020,000E) Series Instance UID », enfin le niveau Image a pour identifiant l'élément « (0008,0018) Series Instance UID ». Quel que soit l'objet DICOM, ces 4 identifiants sont obligatoires.

Remarque : Ce modèle hiérarchique est le point central d'un modèle DICOM plus complexe appelé Model of the Real World décrit dans la partie PS3.3 - section 7.

2.2. Exemple

Voici un exemple (non complet) d'objet DICOM. L'utilitaire dcmdump de l'API dcm4che a été utilisé pour afficher cet exemple.
(0008,0016) UI #26 [1.2.840.10008.5.1.4.1.1.7] SOPClassUID
(0008,0018) UI #10 [1.2.3.4.5] SOPInstanceUID
(0008,0020) DA #8 [20161202] StudyDate
(0008,0021) DA #8 [20161202] SeriesDate
(0008,0050) SH #10 [1002394744] AccessionNumber
(0008,0060) CS #2 [CT] Modality
(0010,0010) PN #14 [John^SMith] PatientName
(0010,0020) LO #8 [2579437] PatientID
(0010,0030) DA #8 [19331013] PatientBirthDate
(0010,0040) CS #2 [M] PatientSex
(0020,000D) UI #9 [1.2.5.6.9] StudyInstanceUID
(0020,000E) UI #11 [1.9.8.7.6.5] SeriesInstanceUID
(0028,0002) US #2 [1] SamplesPerPixel
(0028,0004) CS #12 [MONOCHROME2] PhotometricInterpretation
(0028,0010) US #2 [512] Rows
(0028,0011) US #2 [512] Columns
(0028,0100) US #2 [16] BitsAllocated
(0028,0101) US #2 [12] BitsStored
(0028,0102) US #2 [11] HighBit
(0028,0103) US #2 [0] PixelRepresentation
(7FE0,0010) OB #-1 PixelData
(FFFE,E000) #4 [0\0\0\0] Item
(FFFE,E000) #32836 [-1\-40\-1\-32\0\...
(FFFE,E0DD) #0 SequenceDelimitationItem

    Tag
    VR
    Longueur
    Valeur

Aucun commentaire:

Enregistrer un commentaire