Healthcare’s anatomy:
le protocole DICOM

Introduction


Le premier épisode de cette série consacrée aux protocoles médicaux a mis en lumière le protocole HL7, un moyen de transmission des données de santé primordial pour échanger et regrouper rapidement les données des patients. Cependant, les protocoles spécifiques au secteur médical ne se limitent pas à l’échange de dossiers médicaux. Certains, comme le DICOM, permettent la transmission d’imagerie médicale.

Healthcare’s anatomy: Scan du protocole DICOM


Le DICOM (Digital Imaging and Communications in Medicine) est un protocole standard international reposant sur TCP/IP, utilisant par défaut le port 104, et un format créé en 1985 aux Etats-Unis par l’American College of Radiology. Il facilite la diffusion des données des patients, des examens et des comptes rendus.

Il est utilisé aussi bien en interne dans les établissements de santé qu’entre deux entités médicales distinctes, par exemple, entre un cabinet de radiologie et un hôpital. Du cabinet de dentiste, en passant par les cliniques privées jusqu’au CHU, tous les échanges d’imageries reposent sur DICOM. Cette utilisation conduit malheureusement à la publication de certains serveurs PACS/DICOM sur le net. Un serveur PACS (Picture Archiving and Communication System) est un serveur de stockage d’imagerie médicale, il prend en charge plusieurs standards d’imagerie dont le DICOM.  Pour mettre en exergue cette problématique de publication de service sur le web, il faut comprendre que n’importe quel poste, avec une capacité d’échange en DICOM, pourra converser avec un serveur PACS exposé si ce dernier n’est pas protégé.

Modalité d’imagerie et serveurs PACS : les échanges DICOM dans un système d’information médicale


À la suite de l’introduction de la notion de serveur PACS, il convient d’expliciter les échanges DICOM entre le service de stockage de l’imagerie et les appareils produisant ces images.

Tout comme HL7, DICOM se caractérise par un nombre important de messages normés. Avant de détailler ces messages, il convient de définir les termes “dispositif” et “Service class”.

Un dispositif dans le contexte DICOM correspond à tous les appareils et terminaux qui échangent via ce protocole. Ainsi, un serveur PACS est un dispositif tout comme une station de travail, un scanner ou une imprimante d’imagerie. Une Service class correspond à une action particulière réalisée sur des données d’imagerie médicale.

 Les Services class 

Chaque Service class contient un nombre de messages prédéfinis. On dénombre 13 classes spécifiques :

  • Storage Service class : relative aux actions de stockage des objets DICOM, tels que des images, des rapports structurés, des documents de présentation, etc. Types de messages associés : C-STORE
  • Query/Retrieve Service class : relative aux actions de recherche et de récupération des objets DICOM stockés dans un serveur. Types de messages associés : C-FIND, C-MOVE, C-GET.
  • Worklist Management Service class : relative aux actions de gestion des listes des travaux pour les modalités d’imagerie (scanners, IRM et autres outils d’acquisition), facilitant l’acquisition planifiée d’images. Types de messages associés : C-FIND
  • Modality Performed Procedure Step (MPPS) Service class : relative aux actions de monitoring des états et des résultats des procédures effectuées par les modalités d’imagerie. Types de messages associés : N-CREATE, N-SET
  • Print Management Service class : relative aux actions de gestion d’impression des images sur des imprimantes compatibles DICOM. Types de messages associés : N-CREATE, N-DELETE, N-ACTION, N-EVENT-REPORT
  • Storage Commitment Service class : relative aux actions de confirmation du stockage permanent des objets DICOM sur un serveur PACS. Types de messages associés : N-ACTION, N-EVENT-REPORT
  • Media Storage Service class : relative aux actions de gestion du stockage et à la récupération des objets DICOM sur des supports amovibles (CD, DVD, etc.).
  • Presentation State Service class : relative au stockage et à la récupération des informations sur la présentation des images (comme les annotations, la disposition des fenêtres). Types de messages associés : C-STORE
  • Verification Service class : relative aux actions de vérification de la connectivité entre les dispositifs DICOM. Types de messages : C-ECHO
  • Structured Reporting (SR) Service class : relative aux actions de créations, stockages et récupérations des rapports structurés DICOM. Types de messages : C-STORE
  • Relevant Patient Information Query Service class : relative aux actions de recherche des informations pertinentes sur les patients pour une procédure donnée. Types de messages : C-FIND
  • Unified Procedure Step (UPS) Service class : relative à la gestion et à la coordination des étapes des procédures médicales à travers différents systèmes. Types de messages : N-CREATE, N-SET, N-GET, N-ACTION, N-EVENT-REPORT.
  • Workflow Management Service class : relative à la gestion des flux de travail des procédures médicales. Types de messages : MWL, MPPS, UPS

 

Les types de messages DICOM utilisés dans les Services class 

Dès lors, après avoir défini le terme de “Service class” et mis en perspective les différents messages possibles au sein de ces dernières, il convient de détailler les types de messages en DICOM. Voici la description des différents types d’opérations possibles en Dicom :

  • A-ASSOCIATE (Verification Service class) : permet d’établir une association entre deux entités DICOM. Une association DICOM est une connexion réseau qui permet aux entités de communiquer et d’échanger des données DICOM.
  • C-STORE (Composite Storage Service class) : il permet d’envoyer des objets DICOM (images, rapports, etc.) sur un serveur PACS.
  • C-FIND (Query/Retrieve Service class) : il permet de rechercher des informations dans une base de données DICOM.
  • C-MOVE (Query/Retrieve Service class) et C-GET (Query/Retrieve Service class) : ils permettent de déplacer des objets DICOM d’un dispositif à un autre. La différence réside dans le cas d’usage. On utilisera un C-Move pour déplacer un objet entre un serveur de stockage et une station de travail. Quant au C-get il sera utilisé pour extraire la donnée brute d’un serveur de stockage ou d’une station de travail.
  • C-ECHO (Verification Service class) : il permet de valider la communication entre les dispositifs DICOM.
  • N-EVENT-REPORT (Notification Service class) : il permet à un dispositif d’informer un autre dispositif d’un événement particulier. Par exemple, la fin d’une tâche ou la réception d’une nouvelle image.
  • N-GET (Normalized Service class) : il permet de récupérer les attributs d’un objet DICOM spécifique.
  • N-SET (Normalized Service class) : il permet de modifier les attributs d’un objet DICOM.
  • N-CREATE (Normalized Service class) : il permet de créer un nouvel objet DICOM sur un serveur.
  • N-DELETE (Normalized Service class) : il permet de supprimer un objet DICOM existant.
  • Modality Worklist (MWL) : il permet aux modalités (appareils d’imagerie) de récupérer une liste de travaux programmés.
  • Modality Performed Procedure Step (MPPS) : il permet de communiquer l’état d’avancement des procédures réalisées par les modalités.

Exemples de workflows


Pour mieux appréhender ces notions, voici deux cas concrets illustrant des workflows. Le premier exemple porte sur l’association entre deux appareils DICOM. Le second décrit les échanges réalisés lors d’un examen.

 

Association entre deux appareils DICOM :

Avant de décrire les étapes d’associations, il faut définir le terme AE-title. Un AE-title (Application Entity Title) est un identifiant unique utilisé dans les communications DICOM pour identifier de manière distincte une application ou un dispositif (comme un scanner, une station de travail, ou un serveur PACS) sur un réseau.

Lab Dicom Image1 Schéma De L’association Entre Un Scanner Et Un Serveur Pacs
Image 1 :  Schéma De L’association Entre Un Scanner Et Un Serveur PACS

 

Dans ce schéma, le scanner IRM envoie une requête d’association au serveur PACS, qui répond pour accepter ou rejeter cette requête. Une fois acceptée, les appareils communiquent via des commandes DICOM standard telles que C-ECHO (vérification), C-STORE (stockage d’images), et C-FIND/C-MOVE/C-GET (recherche/récupération). Après la communication, le scanner envoie une requête de libération d’association, confirmée par le serveur, terminant ainsi l’échange. Voici un exemple concret de ce type d’échange :

Lab Dicom Image2 Exemple D’un échange Complet Utilisant Des C Find Avec Un Serveur Pacs
Image 2 : Exemple D’un échange Complet Utilisant Des C Find Avec Un Serveur PACS

 

Echange lors d’un examen  

Dans le deuxième exemple, les étapes réalisées sont les suivantes : acquisition, stockage et récupération des informations liées à une radiographie. A chaque phase d’échange (une requête/une réponse), le serveur PACS, la modalité d’imagerie et la station de travail initient une phase d’association avant d’envoyer les commandes à réaliser et terminent par un message de type ‘release’ après avoir reçu les données.

Lab Dicom Image3 Workflow De L’acquisition D’images D’un Serveur Pacs
Image 3 : Workflow De L’acquisition D’images D’un Serveur PACS

 

Tout commence par l’acquisition des images, suivie par la requête de la liste des travaux programmés au serveur Worklist. Ensuite les images sont envoyées au PACS pour stockage, avec confirmation de réception. La modalité informe ensuite le PACS de la fin de l’acquisition. La station de travail interroge ensuite le PACS pour obtenir des images spécifiques, les récupère et les affiche après leur transfert depuis le PACS.

Conclusion


Tout au long de cet article, les différents éléments constituant le protocole DICOM ont été décrits. Pour mieux comprendre le fonctionnement et l’utilisation de ce protocole, deux cas pratiques ont été présentés : l’association entre deux appareils et les échanges lors d’un examen. Cependant, les risques associés à ce protocole n’ont pas encore été évoqués. Dans le prochain article, les risques et les attaques possibles liés au protocole DICOM seront examinés.

 

 

Auteurs : Gatewatcher et 0xSeeker