Nous allons parler dans cet article d'une partie du standard DICOM qui a pour but de faciliter la configuration DICOM.
Certes, cette partie n'est pas la solution parfaite mais si tous les constructeurs et éditeurs se conformaient à cette partie du standard, il serait plus facile de configurer les applications (même logique du système de configuration sur chaque application et administration simplifiée).
Généralement, la mise en service d'un nouvel applicatif DICOM nécessite:
Il est donc préférable pour la structure de disposer d'une liste des différents AE Title composant le réseau DICOM.
De plus, l'ajout ou la mise-à-jour d'un nœud DICOM (changement d'IP, d'AE Title, etc.), demande, en général, la modification de tous les autres nœuds qui communique avec celui ci (la plupart des applications DICOM communiquent en C-MOVE et non en C-GET.).
La configuration et la gestion d'un réseau DICOM peuvent donc vite devenir assez lourdes lorsque qu'une structure ou un hôpital dispose de plusieurs dizaine d’entités applicatives DICOM.
Constatant toutes ces difficultés, le Work Group 6 a travaillé sur un moyen de simplifier l'installation, la mise-à-jour, le retrait, ou de manière générale, la gestion des différents nœuds d'un réseau DICOM.
Le résultat de ce travail a donné lieu au supplément 67 qui a été intégré au standard DICOM en 2003/2004, principalement dans la partie PS3.15.
Ce supplément propose trois profils complémentaires :
Le but de ce profil est de faciliter au maximum la gestion des adresses IP des nœuds d'un réseau DICOM.
Pour ce faire, ce profil se base sur les protocoles DHCP et DNS.
DHCP (Dynamic Host Configuration Protocol) permet d'obtenir et gérer les paramètres IP des machines.
DNS (Domain Name System) permet d'associer un nom à une adresse IP (il est en général plus facile de se souvenir d'un nom comme « Scanner01 » plutôt que d'une adresse IP du genre « 192.168.1.36 » ou « 2001:0db8:0000:85a3:0000:0000:ac1f:8001 »).
DHCP et DNS sont généralement gérés par le système d'exploitation accueillant le service ou l'application DICOM. Ce n'est donc pas à l'application ou au service DICOM de prendre en charge les acteurs « DHCP Client » et « DNS Client » décrits dans le standard.
Pour qu'une application DICOM soit conforme à ce profil (cf. PS3.15 - tableau F.1-1), il faut que le système d'exploitation sur lequel l'application DICOM tourne soit :
Pour comprendre un peu plus le fonctionnement du protocole DHCP, voici un petit descriptif du fonctionnement :
Cela permet à toutes les machines du réseau d'être automatiquement à jour sur les adresses IP des autres machines.
Ce profil permet à l'application DICOM de ne pas se soucier de l'attribution et de la gestion de l'adresse IP. De plus, si une mise-à-jour d'adresse IP est nécessaire, tout est centralisé sur le serveur DHCP. L'administrateur du réseau DICOM n'a également pas à se soucier de l'accès à chacune des machines pour modifier une adresse IP.
Il est possible que la communication entre le client et le serveur DHCP soit instable ou interrompue. Le renouvellement du bail peut ne pas se faire de manière optimale, voire dans le pire des cas ne pas être effectué.
Le serveur et le client DHCP ne pouvant plus communiquer entre eux, chacun d'eux connait la date de début et la durée du bail. Mais pour que le client et le serveur puissent être en phase sur l'arrêt de l'utilisation de l'adresse IP, il faut que ces derniers soient synchronisés. C'est là que le profil de synchronisation du temps entre en jeu.
Le but de ce profil est de synchroniser les horloges internes des machines (date et heure) faisant partie d'un réseau. Cela est très utile pour les logs ou encore pour permettre le bon fonctionnement de différents services (DHCP par exemple).
Pour ce faire, ce profil utilise le protocole NTP qui permet de synchroniser en continu l’heure de tous les ordinateurs d'un réseau avec une horloge de référence.
Nous n'allons pas entrer dans les détails du protocole NTP qui peut être compliqué. Mais globalement, le fonctionnement est le suivant :
Pour qu'une application DICOM soit conforme à ce profil (cf. PS3.15 - tableau G.1-1), le système d'exploitation sur lequel tourne l'application DICOM doit pouvoir :
Le but de ce profil est d'automatiser la synchronisation de la date et de l'heure des différents nœuds DICOM composant le réseau.
Une des solutions pour simplifier un peu plus la configuration est d'utiliser l'option NTP d'un serveur DHCP pour que ce dernier fournisse une liste de serveurs NTP sur lesquels une machine peut se synchroniser. Ainsi, il n'est pas nécessaire de configurer sur le système d'exploitation une liste de serveurs NTP ni d'intervenir dessus si la liste change.
Le but de ce profil est de faciliter la configuration DICOM (le paramétrage) d'un service en standardisant la configuration. Pour ce faire, ce profil utilise le protocole LDAP, qui est un service d’annuaire avec une structure arborescente. Puisque qu'un annuaire LDAP est utilisé, DICOM définit un modèle de données standard qui va pouvoir être utilisé sur cet annuaire.
Voici le modèle de données qui représente la configuration d'une application DICOM:
Un Device est un ensemble de composants pour réaliser une tâche.
Un Device simple peut être une station d'interprétation. Dans ce cas, à un modèle de données « Device » est associé un seul composant physique (la machine).
Un Device plus complexe peut être un PACS qui est constitué de plusieurs serveurs physiques. Dans ce cas, à un modèle de données « Device » est associé plusieurs composants physiques.
DICOM définit pour un Device un certain nombre d'attributs (des propriétés) dont certains sont obligatoires et d'autres optionnels.
Pour un Device les propriétés obligatoires sont :
La liste des attributs est disponible dans le tableau H.1-2 de la partie PS3.15 du standard.
Un Device dispose nécessairement d'au moins 2 fils :
Une Network Application Entity représente un composant fonctionnel de l'application qui peut être utilisateur (SCU) et/ou fournisseur (SCP) d'un ou plusieurs services DICOM.
Chaque Network AE utilise un identifiant unique appelé AE Title qui l'identifie.
Les capacités fonctionnelles d'un Network AE ne dépendent pas d'une connexion particulière. Par exemple, il est tout à fait possible :
Comme pour le Device, le standard DICOM définit une liste d'attributs pour les Network AE. Parmi ceux proposés par le standard, les attributs suivants sont obligatoires :
La liste des attributs disponibles pour un Network AE se trouve dans le tableau H.1-4 de la partie PS3.15 du standard.
Une Network Connection décrit les caractéristiques d'une connexion TCP. On y retrouve notamment l'adresse IP et le port caractérisant une connexion TCP.
Une Network Connection est toujours associée à un Network AE (lié via l'attribut Network Connection Reference d'un Network AE). Le Network AE représentant un service réseau, il faut donc l'associer à une ou des connexions réseau spécifiques.
Le standard DICOM définit une liste d'attributs pour les Network Connection. Parmi ceux proposés par le standard, seul l'attribut Hostname est obligatoire. Ce dernier permet de spécifier l'adresse de la connexion.
Le standard autorise l'ajout d'attributs propriétaires supplémentaires si nécessaire.
La liste des attributs disponibles pour une Network Connection se trouve dans le tableau H.1-6 de la partie PS3.15 du standard.
Chaque Network AE dispose d'une ou plusieurs Transfer Capabilities. Chacune d'elles spécifie la classe SOP que le Network AE peut supporter, le mode qu'il peut utiliser (SCP ou SCU) ainsi que les syntaxes de transfert prisent en compte par le Network AE.
Le standard DICOM définit une liste d'attributs pour les Transfer Capabilities. Parmi ceux proposés par le standard, les attributs suivants sont obligatoires :
La liste des attributs disponibles pour une Transfer Capabilities se trouve dans le tableau H.1-7 de la partie PS3.15 du standard.
Le standard DICOM autorise l'ajout d'extensions (de nouveaux objets LDAP) pour les besoins des applications. Ces extensions étant généralement propriétaires, elles ne seront pas interprétées par les applications ne les connaissant pas. Le standard précise tout de même que la présence d'un attribut ou objet propriétaire ne doit pas être considérée comme une erreur, mais ignorée par les applications ne pouvant l'interpréter.
Nous allons voir dans cette section un exemple de configuration via le modèle de données que nous venons de décrire.
Supposons que l'on dispose d'une station d'interprétation qui ne peut interpréter que des Mammographies. Cette station doit avoir pour AE Title « MAMMO_01 » et peut émettre et recevoir des echo DICOM en plus des mammographies. L'exercice est de faire la configuration suivant le modèle décrit plus haut de cette station d'interprétation.
Supposons maintenant que l'on dispose d'un PACS. Ce PACS propose un service de Query/Retrieve sur le port 5000 et un service de Storage sur le port 4000. Ce PACS a pour AE Title « PACS_QUERY_SCP » pour le service de Query/Retrieve et « PACS_STORE_SCP » pour le service de Storage. Ce PACS est particulier car il ne peut stocker que des mammographies. L'exercice est de faire la configuration de ce PACS.
Le modèle vu précédemment permet la configuration d'une application. Mais il peut être intéressant de centraliser les différentes configurations des Devices en un seul et même endroit, et de permettre aux différentes applications de rechercher une configuration particulière pour la prendre en compte dans l'application.
Prenons un exemple, supposons que notre station d'interprétation de l'exemple ci-dessus (MAMMO_1) désire utiliser le service Query/Retrieve du PACS (PACS_QUERY_SCP). Si nous disposons d'un catalogue des différents Devices, nous pouvons y rechercher le PACS et l'importer directement dans le LDAP local de l'application (station d'interprétation). Ainsi, la déclaration d'une nouvelle modalité peut se faire très rapidement car l'AET, l'adresse IP et le port sont déjà spécifiés dans le Device importé.
DICOM prévoit ce type de scénario en proposant le modèle de données hiérarchique ci-dessous.
Ce modèle est constitué d'une racine appelée « DICOM Configuration Root ».
Cette racine contient deux attributs :
et dispose obligatoirement de deux fils:
Ce nœud permet de stocker tous les Device qui constituent le réseau DICOM. Il contiendra par exemple, la configuration de la station d'interprétation décrite plus haut, le PACS de Mammographie et d'autres modalités.
Le « Device Root » contient deux attributs et n fils de type Device. Les deux attributs sont :
Les applications peuvent ainsi chercher ce nœud pour avoir les différents Device du réseau (Recherche du nœud « cn=Devices, cn=DICOM Configuration, o=Hôpital Truc »).
Ce nœud permet de stocker la liste des AE Title définis dans les différents Device (plus spécifiquement dans les Network AE des différents Device).
Le but de cette liste est de permettre l'allocation dynamique d'AE Title.
Prenons un exemple :
Une modalité (un scanner) dispose d'une routine pour générer automatiquement son AE Title lors de l'installation. Elle peut requêter cette liste sur le serveur LDAP, afin de s'assurer que l'AE Title généré ne soit pas déjà utilisé.
La modalité nouvellement installée pourra par la suite mettre à jour la liste « Unique AE Titles Registry Root » en ajoutant l'AE Title choisi.
Le standard ne décrit pas une implémentation particulière que les applications doivent gérer pour requêter un serveur LDAP, il donne en revanche des pistes sur la stratégie d'implémentation (PS3.15 section H1.6). Cette dernière restant à la discrétion de l'éditeur ou du constructeur.
Le réseau a été conçu en avance et la configuration a été préparée avant l'installation de la machine.
Dans cet exemple :
Remarque: Cet article fait référence à des notions de réseaux (TCP/IP, DHCP, DNS et NTP) et aux annuaires LDAP. Il est donc préférable que le lecteur ait des connaissances dans ce domaine et les protocoles utilisés par ces réseaux IP pour bien comprendre la suite de cet article.
Les tutoriaux suivant introduisent les différents concepts abordés dans cet article:
Les tutoriaux suivant introduisent les différents concepts abordés dans cet article:
1. Introduction
Généralement, la mise en service d'un nouvel applicatif DICOM nécessite:
- d'installer la ou les nouvelle(s) machine(s) ;
- de gérer la configuration réseau (attribution d'une IP, ouverture de flux, etc.) ;
- de gérer la configuration liée à l'application DICOM.
Il est donc préférable pour la structure de disposer d'une liste des différents AE Title composant le réseau DICOM.
De plus, l'ajout ou la mise-à-jour d'un nœud DICOM (changement d'IP, d'AE Title, etc.), demande, en général, la modification de tous les autres nœuds qui communique avec celui ci (la plupart des applications DICOM communiquent en C-MOVE et non en C-GET.).
Note: Un très bon article de David Clunie discutant de l'utilisation du C-GET et du C-MOVE est disponible ici : To C-MOVE is human; to C-GET, divine.
La configuration et la gestion d'un réseau DICOM peuvent donc vite devenir assez lourdes lorsque qu'une structure ou un hôpital dispose de plusieurs dizaine d’entités applicatives DICOM.
Constatant toutes ces difficultés, le Work Group 6 a travaillé sur un moyen de simplifier l'installation, la mise-à-jour, le retrait, ou de manière générale, la gestion des différents nœuds d'un réseau DICOM.
Le résultat de ce travail a donné lieu au supplément 67 qui a été intégré au standard DICOM en 2003/2004, principalement dans la partie PS3.15.
Ce supplément propose trois profils complémentaires :
- Le profil de gestion des adresses réseaux (Network Address Management Profiles);
- Le profil de synchronisation du temps (Time Synchronisation profiles);
- Le profile de gestion de la configuration des applications (Application Configuration Management Profiles).
2. Le profil de gestion des adresses réseaux
Le but de ce profil est de faciliter au maximum la gestion des adresses IP des nœuds d'un réseau DICOM.
Pour ce faire, ce profil se base sur les protocoles DHCP et DNS.
DHCP (Dynamic Host Configuration Protocol) permet d'obtenir et gérer les paramètres IP des machines.
DNS (Domain Name System) permet d'associer un nom à une adresse IP (il est en général plus facile de se souvenir d'un nom comme « Scanner01 » plutôt que d'une adresse IP du genre « 192.168.1.36 » ou « 2001:0db8:0000:85a3:0000:0000:ac1f:8001 »).
DHCP et DNS sont généralement gérés par le système d'exploitation accueillant le service ou l'application DICOM. Ce n'est donc pas à l'application ou au service DICOM de prendre en charge les acteurs « DHCP Client » et « DNS Client » décrits dans le standard.
Pour qu'une application DICOM soit conforme à ce profil (cf. PS3.15 - tableau F.1-1), il faut que le système d'exploitation sur lequel l'application DICOM tourne soit :
- configuré pour trouver et interroger un serveur DHCP - transaction « Find and Use DHCP Server » ;
- capable de gérer le renouvellement du bail (durée de l'attribution de l'adresse IP) - transaction « Maintain Lease » ;
- capable d'interroger un serveur DNS - transaction « Resolve Hostname ».
Remarque: Puisque c'est le système d'exploitation qui gère les clients DHCP et DNS, on retrouve souvent dans les DICOM Conformante Statement des phrases du genre : « Application XXXX supports the Basic Network Address Management Profile as DHCP Client and DNS Client actor utilizing network configuration options of the underlying operating system ».
Pour comprendre un peu plus le fonctionnement du protocole DHCP, voici un petit descriptif du fonctionnement :
- Lors du démarrage de la machine, cette dernière n'a pas d'adresse IP. Elle envoie donc un message spécial (appelé DHCPDISCOVER) sur tout le réseau (adresse de broadcast FF:FF:FF:FF:FF:FF) pour demander une adresse IP.
- Lorsqu'un serveur DHCP reçoit le message DHCPDISCOVER, il répond en émettant un message DHCPOFFER contenant une proposition d'adresse IP. Le message DHCPOFFER est également diffusé sur tout le réseau.
- Sur réception d'un ou plusieurs messages DHCPOFFER (le client pouvant recevoir plusieurs offres d'IP si plusieurs serveurs DHCP sont disponibles sur le réseau), le client sélectionne une des offres et diffuse un message DHCPREQUEST sur tout le réseau avec l'adresse IP choisie et le serveur DHCP qui à proposé l'adresse. Cette diffusion sur tout le réseau permet aux serveurs non sélectionnés de recevoir également le message et de libérer l'adresse IP proposée.
- Le serveur DHCP sélectionné répond au message DHCPREQUEST avec un message DHCPACK contenant l'adresse IP proposée dans le message DHCPDISCOVER pour confirmation de l'attribution et la durée du bail (durée de l'attribution de l'adresse IP). Le message DHCPACK est également diffusé sur tout le réseau car l'IP attribué n'est pas encore active. Elle le sera une fois que le client à reçu le message DHCPACK.
Cela permet à toutes les machines du réseau d'être automatiquement à jour sur les adresses IP des autres machines.
Ce profil permet à l'application DICOM de ne pas se soucier de l'attribution et de la gestion de l'adresse IP. De plus, si une mise-à-jour d'adresse IP est nécessaire, tout est centralisé sur le serveur DHCP. L'administrateur du réseau DICOM n'a également pas à se soucier de l'accès à chacune des machines pour modifier une adresse IP.
Remarque: Ce profil n'est pas non plus exempt de problèmes. Par exemple, le changement de l'adresse IP de machine peut mettre du temps à être effectif (temps du bail avant renouvellement, diffusion au DNS, redémarrage de la machine, etc.).
Il est possible que la communication entre le client et le serveur DHCP soit instable ou interrompue. Le renouvellement du bail peut ne pas se faire de manière optimale, voire dans le pire des cas ne pas être effectué.
Le serveur et le client DHCP ne pouvant plus communiquer entre eux, chacun d'eux connait la date de début et la durée du bail. Mais pour que le client et le serveur puissent être en phase sur l'arrêt de l'utilisation de l'adresse IP, il faut que ces derniers soient synchronisés. C'est là que le profil de synchronisation du temps entre en jeu.
3. Le profil de synchronisation du temps
Le but de ce profil est de synchroniser les horloges internes des machines (date et heure) faisant partie d'un réseau. Cela est très utile pour les logs ou encore pour permettre le bon fonctionnement de différents services (DHCP par exemple).
Remarque: Ce profil a le même but que le profil IHE CT.
Pour ce faire, ce profil utilise le protocole NTP qui permet de synchroniser en continu l’heure de tous les ordinateurs d'un réseau avec une horloge de référence.
Nous n'allons pas entrer dans les détails du protocole NTP qui peut être compliqué. Mais globalement, le fonctionnement est le suivant :
Un jeu de ping-pong entre le client et le serveur se met en place. Le client envoie un message au serveur qui lui répond avec l'heure dont il dispose. Le client estime son heure à partir de l'heure du serveur et du temps que sa demande a mis avant d'avoir une réponse (temps de l'aller-retour).
Pour plus de détails, lire les RFC-1305 et RFC-2030 qui traitent des problèmes de perte de messages, de formule d'estimation de l'heure, etc.
Une fois que le client et le serveur sont synchronisés, le jeu de ping-pong continue mais à un intervalle de temps moins fréquent.
Il faut simplement savoir que comme pour les protocoles DHCP et DNS, ce service est généralement géré par le système d'exploitation accueillant le service ou l'application DICOM.Pour plus de détails, lire les RFC-1305 et RFC-2030 qui traitent des problèmes de perte de messages, de formule d'estimation de l'heure, etc.
Une fois que le client et le serveur sont synchronisés, le jeu de ping-pong continue mais à un intervalle de temps moins fréquent.
Pour qu'une application DICOM soit conforme à ce profil (cf. PS3.15 - tableau G.1-1), le système d'exploitation sur lequel tourne l'application DICOM doit pouvoir :
- communiquer avec un serveur NTP afin de maintenir la synchronisation du temps avec une horloge de référence - transactions « Maintain Time » ;
- et optionnellement, interroger un serveur DHCP pour récupérer la liste des serveurs d'horloge de référence - transactions « Find NTP Servers ».
Remarque: C'est pourquoi on retrouve souvent, dans les DICOM Conformante Statement qui gèrent ce profil, des phrases du genre : « Application XXXX supports the Basic Time Synchronization Profile as NTP Client actor utilizing network configuration options of the underlying operating system ».
Le but de ce profil est d'automatiser la synchronisation de la date et de l'heure des différents nœuds DICOM composant le réseau.
Une des solutions pour simplifier un peu plus la configuration est d'utiliser l'option NTP d'un serveur DHCP pour que ce dernier fournisse une liste de serveurs NTP sur lesquels une machine peut se synchroniser. Ainsi, il n'est pas nécessaire de configurer sur le système d'exploitation une liste de serveurs NTP ni d'intervenir dessus si la liste change.
4. Le profil de gestion de la configuration des applications
Le but de ce profil est de faciliter la configuration DICOM (le paramétrage) d'un service en standardisant la configuration. Pour ce faire, ce profil utilise le protocole LDAP, qui est un service d’annuaire avec une structure arborescente. Puisque qu'un annuaire LDAP est utilisé, DICOM définit un modèle de données standard qui va pouvoir être utilisé sur cet annuaire.
4.1. Modèle de données de configuration d'une application
DICOM définit un modèle de données pour la configuration d'application appelé « Application Configuration Data Model ». Ce dernier étant générique, il est probable que les éditeurs ou constructeurs devront ajouter des attributs pour que leur configuration s'adapte mieux aux spécificités de leur produit.Voici le modèle de données qui représente la configuration d'une application DICOM:
4.1.1 Le Device
Un Device est un ensemble de composants pour réaliser une tâche.
Un Device simple peut être une station d'interprétation. Dans ce cas, à un modèle de données « Device » est associé un seul composant physique (la machine).
Un Device plus complexe peut être un PACS qui est constitué de plusieurs serveurs physiques. Dans ce cas, à un modèle de données « Device » est associé plusieurs composants physiques.
DICOM définit pour un Device un certain nombre d'attributs (des propriétés) dont certains sont obligatoires et d'autres optionnels.
Pour un Device les propriétés obligatoires sont :
- l'attribut Device Name, représentant le nom du Device
- et l'attribut Installed, qui indique si le Device est déjà présent (déjà installé physiquement) sur le réseau. Cet attribut peut être utilisé lors d'une phase de pré-configuration. Par exemple, la configuration DICOM peut déjà avoir été faite en amont mais la machine n'est pas encore physiquement installée.
La liste des attributs est disponible dans le tableau H.1-2 de la partie PS3.15 du standard.
Un Device dispose nécessairement d'au moins 2 fils :
- un fils Network Application Entity ;
- et un fils Network Connection.
4.1.2 Network Application Entity
Une Network Application Entity représente un composant fonctionnel de l'application qui peut être utilisateur (SCU) et/ou fournisseur (SCP) d'un ou plusieurs services DICOM.
Chaque Network AE utilise un identifiant unique appelé AE Title qui l'identifie.
Les capacités fonctionnelles d'un Network AE ne dépendent pas d'une connexion particulière. Par exemple, il est tout à fait possible :
- de créer un Network AE pour faire du Storage et du Query/Retrieve basé sur une connexion (un port TCP particulier qui propose le service Storage et Query/Retrieve).
- ou de créer deux Network AE, un pour le service de Storage sur une connexion particulière et un autre pour le service de Query/Retrieve sur une autre connexion.
Comme pour le Device, le standard DICOM définit une liste d'attributs pour les Network AE. Parmi ceux proposés par le standard, les attributs suivants sont obligatoires :
- AE Title : identifiant unique du Network AE (limité à 16 caractères)
- Association Acceptor : indique si le Network AE est un fournisseur de service (accepte des associations) ;
- Association Initiator : indique si le Network AE est un utilisateur de service (peut initier des associations) ;
- Network Connection Reference : indique le ou les connexions utilisées par le Network AE. Cet attribut est un lien vers un objet LDAP Network Connexion.
La liste des attributs disponibles pour un Network AE se trouve dans le tableau H.1-4 de la partie PS3.15 du standard.
4.1.3 Network Connection
Une Network Connection décrit les caractéristiques d'une connexion TCP. On y retrouve notamment l'adresse IP et le port caractérisant une connexion TCP.
Une Network Connection est toujours associée à un Network AE (lié via l'attribut Network Connection Reference d'un Network AE). Le Network AE représentant un service réseau, il faut donc l'associer à une ou des connexions réseau spécifiques.
Le standard DICOM définit une liste d'attributs pour les Network Connection. Parmi ceux proposés par le standard, seul l'attribut Hostname est obligatoire. Ce dernier permet de spécifier l'adresse de la connexion.
Le standard autorise l'ajout d'attributs propriétaires supplémentaires si nécessaire.
La liste des attributs disponibles pour une Network Connection se trouve dans le tableau H.1-6 de la partie PS3.15 du standard.
4.1.4 Transfer Capabilities
Chaque Network AE dispose d'une ou plusieurs Transfer Capabilities. Chacune d'elles spécifie la classe SOP que le Network AE peut supporter, le mode qu'il peut utiliser (SCP ou SCU) ainsi que les syntaxes de transfert prisent en compte par le Network AE.
Le standard DICOM définit une liste d'attributs pour les Transfer Capabilities. Parmi ceux proposés par le standard, les attributs suivants sont obligatoires :
- SOP Class : L'identifiant (UID) de la classe SOP ;
- Role : SCP ou SCU ;
- Transfer Syntax : Les syntaxes de transfert (UID) qui peuvent être fournies (en mode SCU) ou proposées (en mode SCP).
La liste des attributs disponibles pour une Transfer Capabilities se trouve dans le tableau H.1-7 de la partie PS3.15 du standard.
4.1.5 Extensions
Le standard DICOM autorise l'ajout d'extensions (de nouveaux objets LDAP) pour les besoins des applications. Ces extensions étant généralement propriétaires, elles ne seront pas interprétées par les applications ne les connaissant pas. Le standard précise tout de même que la présence d'un attribut ou objet propriétaire ne doit pas être considérée comme une erreur, mais ignorée par les applications ne pouvant l'interpréter.
Standard DICOM PS3.15 - section H.1.1: LDAP permits extensions to schema to support local needs (i.e., an object may implement a single structural and multiple auxiliary LDAP classes). DICOM does not mandate client support for such extensions. Servers may support such extensions for local purposes. DICOM Clients may accept or ignore extensions and shall not consider their presence an error.
4.2. Exemples
Nous allons voir dans cette section un exemple de configuration via le modèle de données que nous venons de décrire.
Supposons que l'on dispose d'une station d'interprétation qui ne peut interpréter que des Mammographies. Cette station doit avoir pour AE Title « MAMMO_01 » et peut émettre et recevoir des echo DICOM en plus des mammographies. L'exercice est de faire la configuration suivant le modèle décrit plus haut de cette station d'interprétation.
|
Attribut |
Valeur |
|---|---|
| Device | |
| Device Name | Station Interprétation Mammo 1 |
| Description | Ceci est un exemple de configuration de device |
| Primary Device Type | WSD |
| Installed | true |
| Network AE | |
| AE Title | MAMMO_01 |
| Association Acceptor | true |
| Association Initiator | true |
| Network Connection Reference | cn=dicom-connection,dicomDeviceName=Station Interprétation Mammo 1,cn=Devices,cn=DICOM Configuration,dc=MyApplication,dc=org |
| Network Connection | |
| Common Name | dicom-connection |
| Hostname | mammo.host.name |
| Port | 104 |
| Installed | true |
| Transfer Capabilities | |
| Common Name | Digital Mammography X-Ray Image Storage - For Presentation - SCP |
| SOP Class | 1.2.840.10008.5.1.4.1.1.1.2 |
| Role | SCP |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Transfer Syntax | 1.2.840.10008.1.2.4.90 |
| Transfer Capabilities | |
| Common Name | Digital Mammography X-Ray Image Storage - For Processing - SCP |
| SOP Class | 1.2.840.10008.5.1.4.1.1.1.2.1 |
| Role | SCP |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Transfer Syntax | 1.2.840.10008.1.2.4.90 |
| Transfer Capabilities | |
| Common Name | Digital Mammography X-Ray Image Storage - For Presentation - SCU |
| SOP Class | 1.2.840.10008.5.1.4.1.1.1.2 |
| Role | SCU |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Transfer Syntax | 1.2.840.10008.1.2.4.90 |
| Transfer Capabilities | |
| Common Name | Digital Mammography X-Ray Image Storage - For Processing - SCU |
| SOP Class | 1.2.840.10008.5.1.4.1.1.1.2.1 |
| Role | SCU |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Transfer Syntax | 1.2.840.10008.1.2.4.90 |
| Transfer Capabilities | |
| Common Name | Verification SOP Class - SCP |
| SOP Class | 1.2.840.10008.1.1 |
| Role | SCP |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Transfer Capabilities | |
| Common Name | Verification SOP Class - SCU |
| SOP Class | 1.2.840.10008.1.1 |
| Role | SCU |
| Transfer Syntax | 1.2.840.10008.1.2 |
Supposons maintenant que l'on dispose d'un PACS. Ce PACS propose un service de Query/Retrieve sur le port 5000 et un service de Storage sur le port 4000. Ce PACS a pour AE Title « PACS_QUERY_SCP » pour le service de Query/Retrieve et « PACS_STORE_SCP » pour le service de Storage. Ce PACS est particulier car il ne peut stocker que des mammographies. L'exercice est de faire la configuration de ce PACS.
|
Attribut |
Valeur |
|---|---|
| Device | |
| Device Name | PACS Mammo Q/R |
| Description | Ceci est un exemple de configuration de device pour le PACS Mammo |
| Primary Device Type | ARCHIVE |
| Installed | true |
| Network AE | |
| AE Title | PACS_QUERY_SCP |
| Association Acceptor | true |
| Association Initiator | true |
| Network Connection Reference | cn=dicom-qr-connection,dicomDeviceName=PACS Mammo Q/R,cn=Devices,cn=DICOM Configuration,dc=MyPACS,dc=org |
| Network Connection | |
| Common Name | dicom-qr-connection |
| Hostname | pacs.host.name |
| Port | 5000 |
| Installed | true |
| Transfer Capabilities | |
| Common Name | Patient Root Query/Retrieve Information Model - FIND - SCP |
| SOP Class | 1.2.840.10008.5.1.4.1.2.1.1 |
| Role | SCP |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Transfer Capabilities | |
| Common Name | Patient Root Query/Retrieve Information Model - MOVE - SCP |
| SOP Class | 1.2.840.10008.5.1.4.1.2.1.2 |
| Role | SCP |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Transfer Capabilities | |
| Common Name | Patient Root Query/Retrieve Information Model - GET - SCP |
| SOP Class | 1.2.840.10008.5.1.4.1.2.1.3 |
| Role | SCP |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Transfer Capabilities | |
| Common Name | Study Root Query/Retrieve Information Model - FIND - SCP |
| SOP Class | 1.2.840.10008.5.1.4.1.2.2.1 |
| Role | SCP |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Transfer Capabilities | |
| Common Name | Study Root Query/Retrieve Information Model - MOVE - SCP |
| SOP Class | 1.2.840.10008.5.1.4.1.2.2.2 |
| Role | SCP |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Transfer Capabilities | |
| Common Name | Study Root Query/Retrieve Information Model - GET - SCP |
| SOP Class | 1.2.840.10008.5.1.4.1.2.2.3 |
| Role | SCP |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Transfer Capabilities | |
| Common Name | Verification SOP Class - SCP |
| SOP Class | 1.2.840.10008.1.1 |
| Role | SCP |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Transfer Capabilities | |
| Common Name | Verification SOP Class - SCU |
| SOP Class | 1.2.840.10008.1.1 |
| Role | SCU |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Network AE | |
| AE Title | PACS_STORE_SCP |
| Association Acceptor | true |
| Association Initiator | true |
| Network Connection Reference | cn=dicom-storage-connection,dicomDeviceName=PACS Mammo Q/R,cn=Devices,cn=DICOM Configuration,dc=MyPACS,dc=org |
| Network Connection | |
| Common Name | dicom-storage-connection |
| Hostname | pacs.host.name |
| Port | 4000 |
| Installed | true |
| Transfer Capabilities | |
| Common Name | Digital Mammography X-Ray Image Storage - For Presentation - SCP |
| SOP Class | 1.2.840.10008.5.1.4.1.1.1.2 |
| Role | SCP |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Transfer Syntax | 1.2.840.10008.1.2.4.90 |
| Transfer Capabilities | |
| Common Name | Digital Mammography X-Ray Image Storage - For Processing - SCP |
| SOP Class | 1.2.840.10008.5.1.4.1.1.1.2.1 |
| Role | SCP |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Transfer Syntax | 1.2.840.10008.1.2.4.90 |
| Transfer Capabilities | |
| Common Name | Digital Mammography X-Ray Image Storage - For Presentation - SCU |
| SOP Class | 1.2.840.10008.5.1.4.1.1.1.2 |
| Role | SCU |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Transfer Syntax | 1.2.840.10008.1.2.4.90 |
| Transfer Capabilities | |
| Common Name | Digital Mammography X-Ray Image Storage - For Processing - SCU |
| SOP Class | 1.2.840.10008.5.1.4.1.1.1.2.1 |
| Role | SCU |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Transfer Syntax | 1.2.840.10008.1.2.4.90 |
| Transfer Capabilities | |
| Common Name | Verification SOP Class - SCP |
| SOP Class | 1.2.840.10008.1.1 |
| Role | SCP |
| Transfer Syntax | 1.2.840.10008.1.2 |
| Transfer Capabilities | |
| Common Name | Verification SOP Class - SCU |
| SOP Class | 1.2.840.10008.1.1 |
| Role | SCU |
| Transfer Syntax | 1.2.840.10008.1.2 |
4.3. Modèle de données hiérarchique
Le modèle vu précédemment permet la configuration d'une application. Mais il peut être intéressant de centraliser les différentes configurations des Devices en un seul et même endroit, et de permettre aux différentes applications de rechercher une configuration particulière pour la prendre en compte dans l'application.
Prenons un exemple, supposons que notre station d'interprétation de l'exemple ci-dessus (MAMMO_1) désire utiliser le service Query/Retrieve du PACS (PACS_QUERY_SCP). Si nous disposons d'un catalogue des différents Devices, nous pouvons y rechercher le PACS et l'importer directement dans le LDAP local de l'application (station d'interprétation). Ainsi, la déclaration d'une nouvelle modalité peut se faire très rapidement car l'AET, l'adresse IP et le port sont déjà spécifiés dans le Device importé.
DICOM prévoit ce type de scénario en proposant le modèle de données hiérarchique ci-dessous.
Ce modèle est constitué d'une racine appelée « DICOM Configuration Root ».
Cette racine contient deux attributs :
- Common Name : représente le nom de la racine et doit avoir pour valeur « DICOM Configuration » ;
- Description : chaîne de caractères décrivant la racine. Par exemple, « Configuration réseau DICOM - Hôpital Truc » ;
et dispose obligatoirement de deux fils:
- Devices Root : contient tous les Device (cf. section 4.3.1) ;
- Unique AE Titles Registry Root : contient la liste des AE Title qui existent dans les différents Devices (cf. section 4.3.2).
4.3.1 Device Root
Ce nœud permet de stocker tous les Device qui constituent le réseau DICOM. Il contiendra par exemple, la configuration de la station d'interprétation décrite plus haut, le PACS de Mammographie et d'autres modalités.
Le « Device Root » contient deux attributs et n fils de type Device. Les deux attributs sont :
- Common Name : représente le nom de la racine des Device et doit avoir pour valeur « Devices » ;
- Description : chaîne de caractères décrivant la racine. Par exemple, « Modalités du réseau DICOM »
Les applications peuvent ainsi chercher ce nœud pour avoir les différents Device du réseau (Recherche du nœud « cn=Devices, cn=DICOM Configuration, o=Hôpital Truc »).
4.3.2 Unique AE Titles Registry Root
Ce nœud permet de stocker la liste des AE Title définis dans les différents Device (plus spécifiquement dans les Network AE des différents Device).
Le but de cette liste est de permettre l'allocation dynamique d'AE Title.
Prenons un exemple :
Une modalité (un scanner) dispose d'une routine pour générer automatiquement son AE Title lors de l'installation. Elle peut requêter cette liste sur le serveur LDAP, afin de s'assurer que l'AE Title généré ne soit pas déjà utilisé.
La modalité nouvellement installée pourra par la suite mettre à jour la liste « Unique AE Titles Registry Root » en ajoutant l'AE Title choisi.
Le standard ne décrit pas une implémentation particulière que les applications doivent gérer pour requêter un serveur LDAP, il donne en revanche des pistes sur la stratégie d'implémentation (PS3.15 section H1.6). Cette dernière restant à la discrétion de l'éditeur ou du constructeur.
5. Exemples d'utilisation
5.1. Pré-configuration
Le réseau a été conçu en avance et la configuration a été préparée avant l'installation de la machine.
- La configuration de l'application est faite avant même l'installation de la machine. Cette configuration est ensuite déposée sur le serveur LDAP pour une utilisation future. A cette étape, l'attribut « Installed » du Device est positionné à « false » pour indiquer que la machine n'est pas encore disponible sur le réseau.
- La machine est physiquement installée. Un administrateur se connecte au serveur de gestion des configurations (serveur LDAP) et positionne l'attribut « Installed » du Device à « true ». Cela indique aux autres applications que la nouvelle machine est disponible.
- Lorsque la machine démarre, elle interroge un serveur DHCP pour récupérer ses paramètres réseaux. Elle récupère également l'adresse d'un serveur NTP pour synchroniser son horloge interne par rapport à une horloge de référence.
- Lorsque l'application DICOM se lance, elle se connecte au serveur de gestion des configurations et demande sa propre configuration. Cette dernière est alors chargée et l'application est prête à fonctionner.
5.2. Configuration après installation
- La machine est physiquement installée.
- Lorsque la machine démarre, elle interroge un serveur DHCP pour récupérer ses paramètres réseaux. Elle récupère également l'adresse d'un serveur NTP pour synchroniser son horloge interne par rapport à une horloge de référence.
- Lorsque l'application DICOM se lance, elle se connecte au serveur de gestion des configurations et demande sa propre configuration. Aucune configuration n'est trouvée.
- Un administrateur effectue la configuration de l'application et envoie cette dernière sur le serveur LDAP. La configuration est maintenant disponible sur le serveur de gestion des configurations.