Comprendre et utiliser DICOM, la norme d'échange de données pour l'imagerie biomédicale – Serveur d’impression

Abstrait

L'imagerie numérique et les communications en médecine (DICOM)
 Standard spécifie un protocole d’échange de données non-propriétaire, image numérique
 format et la structure des fichiers pour les images biomédicales et les images associées.
 information. Les concepts fondamentaux du protocole de message DICOM, des services,
 et les objets d’information sont passés en revue pour servir de base à une discussion détaillée
 de la fonctionnalité de DICOM; les innovations et les limites du
 La norme; et impact de diverses fonctionnalités de DICOM sur le système d'information
 utilisateurs. DICOM aborde cinq domaines d'application généraux: (1) image réseau
 gestion, (2) gestion de l'interprétation des images en réseau, (3) impression en réseau
 gestion, (4) gestion des procédures d’imagerie, (5) supports de stockage hors ligne
 la gestion. DICOM est une spécification complète des éléments requis pour
 atteindre un niveau pratique d'interopérabilité automatique entre le biomédical
 systèmes informatiques d'imagerie — de la couche application au codage en flux binaire.
 La norme est étendue et élargie de manière modulaire pour prendre en charge de nouvelles
 applications et incorporer de nouvelles technologies. Une interface avec d'autres informations
 Les systèmes permettent une gestion partagée du patient, de la procédure et des résultats
 informations relatives aux images. Un modèle de déclaration de conformité permet à un
 utilisateur averti afin de déterminer si l’interopérabilité entre deux
 les implémentations sont possibles. Connaissance des avantages de DICOM et réaliste
 compréhension de ses limites permet d’utiliser efficacement la norme en tant que
 la base d'une stratégie de mise en œuvre à long terme pour la gestion de l'image et
 systèmes de communication.

Que faut-il savoir à propos de DICOM à des fins pratiques?

Présentation de la norme DICOM

DICOM fournit des informations techniques détaillées pouvant être utilisées dans
 spécifications d'interface pour permettre la connectivité réseau entre une variété de
 produits des vendeurs. La norme décrit comment formater et échanger des informations médicales
 images et informations associées, à la fois à l'intérieur et à l'extérieur de l'hôpital
 l'hôpital (par exemple, la téléradiologie, la télémédecine). Les interfaces DICOM sont
 disponible pour la connexion de toute combinaison des catégories suivantes de
 dispositifs d’imagerie numérique: (a) équipement d’acquisition d’images (par exemple, calcul
 tomographie, imagerie par résonance magnétique, radiographie informatisée, échographie,
 et scanners de médecine nucléaire); (b) archives d'images; (c) traitement d'image
 dispositifs et postes d'affichage d'images; (d) des périphériques de sortie papier (par exemple,
 transparents photographiques pour film et papier).

DICOM est une norme de message (c’est-à-dire une spécification pour l’échange de
 informations entre systèmes informatiques). DICOM est une spécification complète
 contenu, la structure, le codage et les protocoles de communication de l'information
 échange électronique d'images diagnostiques et thérapeutiques et d'images associées
 information. D’autres normes d’échange de données sur les soins de santé spécifient uniquement
 sous-ensemble des propriétés ayant un impact sur l'interopérabilité. Le niveau de santé sept
 (HL7) Standard2
spécifie un modèle de message, mais ne fournit qu'une spécification abrégée pour
 communications réseau. Le CEN / TC 251 / PT3-033 (Norme européenne de normalisation)
 Comité: Comité technique des soins de santé, équipe de projet 22) Demande et
 Signaler des messages pour le service de diagnostic
 Départements"3
document spécifie un modèle de données sémantique et des règles de composition basées sur un modèle
 pour les messages, mais seulement des directives partielles pour l'échange électronique de documents.
 Ainsi, les spécifications HL7 et CEN / TC 251 laissent de gros problèmes de communication
 non résolu. Les développeurs dépendent de la négociation bilatérale entre informations
 les fournisseurs de systèmes pour déterminer les paramètres des détails non spécifiés. DICOM est un
 spécification complète «de haut en bas» des éléments
 nécessaire pour atteindre un niveau pratique d’interopération automatique.

Protocole, services et objets DICOM

DICOM spécifie un protocole pour l'échange de messages
 () Le message DICOM
 Le protocole fournit le cadre de communication pour les services DICOM. Le DICOM
 protocole est compatible avec le protocole de contrôle de transmission et Internet
 Protocole. Cela permet aux entités d’application DICOM de communiquer via le
 L'Internet.

Un fichier externe contenant une image, une illustration, etc.
Le nom de l'objet est 0003f01.jpg

Cette figure illustre trois implémentations différentes du protocole DICOM.
 schème. Une connexion réseau DICOM existe entre le logiciel d'application
 programmes (entités d’application DICOM homologues) d’appareils d’imagerie. Dans
 configuration 1 le logiciel d'application génère la demande de commande DICOM
 (RQ) et les messages de réponse aux commandes (RSP) qui circulent d’un périphérique à un autre.
 Dans la configuration 2, un protocole DIMSE (DICOM Message Service Element) distinct
 La machine génère les messages de commande pour le compte du logiciel d'application.
 La machine à protocole DIMSE est le fournisseur de service DICOM (DSP). le
 le logiciel d'application est l'utilisateur du service DICOM (DSU). Configuration 3 utilise
 modules séparés pour toutes les fonctions de communication et d'application. Une seconde
 couche de messages DICOM est utilisée dans chaque périphérique. Ce sont les DIMSE
 primitives de service: la primitive de demande (REQP), la primitive d'indication (INDP),
 Primitive de réponse (RSPP) et primitive de confirmation (CFMP). Un autoportant
 Le module DSU génère les primitives de service DIMSE pour le compte de l'application
 Logiciel. Même si la machine protocole et le module utilisateur du service DICOM peuvent
 être mis en œuvre de différentes manières, les messages de commande externes sont identiques
 pour toutes les configurations.

Les services DICOM se divisent en deux groupes: composite et normalisé. le
 services composites ont été conçus pour être compatibles avec les versions précédentes de
 la norme ACR-NEMA. Ils étaient à l'origine destinés au stockage (C-STORE),
 interrogation (C-FIND), récupération (C-GET) et transfert (C-MOVE) d’images. cependant,
 les services composites sont également utiles pour d’autres types d’informations, tels que
 rapports d'interprétation. Notez que le groupe composite n'inclut pas de
 Service de «mise à jour». Cette omission est intentionnelle. Les architectes de
 la norme ACR-NEMA originale a choisi d’omettre «update» pour réduire
 la possibilité de modifier un enregistrement d'image. Ainsi, les services composites sont
 optimisé pour l'échange d'images. Cependant, cette optimisation limite la
 utilité des services composites pour d'autres domaines. Données d'interprétation
 L'échange est un domaine dans lequel les services composites sont utiles. Puisque
 la modification des dossiers médicaux est bien entendu interdite, les modifications de l'original
 les rapports d'interprétation sont généralement publiés en tant que nouveaux documents. Cette affaire
 modèle se traduit précisément dans le paradigme des services composites.

Les services normalisés ont été conçus pour fournir une information plus large
 fonctionnalité de gestion. Notez que le nom «normalisé» ne signifie pas
 concernent la normalisation des bases de données. Les services normalisés ont été
 envisagé pour une utilisation avec des enregistrements représentant les propriétés d'un seul
 entité du monde réel, alors que les services composites étaient initialement utilisés
 avec des documents (images) contenant des informations provenant de plusieurs
 Entité du monde réel (par exemple, données de pixels, équipement et identification du patient
 nombre). Les services normalisés prennent en charge la gestion de base des informations
 opérations: créer (N-CREATE), supprimer (N-DELETE), mettre à jour (N-SET) et récupérer
 (N-GET). De plus, des opérations spécifiques à un domaine (N-ACTION) telles que
 «Imprimer une feuille de film» peut être défini. Un service de notification
 (N-EVENT_NOTIFY) est également spécifié dans le groupe normalisé.

En dépit de sa flexibilité, le groupe de services normalisés a quelques problèmes
 limites. Le service de mise à jour (N-SET) a une utilité limitée pour la
 Type de «séquence d'éléments». N-SET doit mettre à jour une séquence entière
 plutôt qu'un élément de données individuel dans une séquence. Le groupe normalisé
 manque également un service de requête. Cette omission flagrante est le résultat du manque de
 consensus de l'industrie sur les protocoles de requête réseau au moment où la norme était
 écrit. Pour l’interface ISIS (Information System-Imaging System), cette
 la limitation est améliorée par la paire objet de service liste de travail de modalité de base
 Classe (SOP) (voir la définition de la classe SOP dans le paragraphe suivant). le
 Classe SOP de la classe de travail de modalité spécifie un service de requête composite pour la récupération
 des informations démographiques et de planification par les dispositifs d'imagerie.

Entités du monde réel (images, procédures ou rapports d'interprétation, par exemple)
 sont représentés dans le modèle de données sémantique DICOM par des modèles d'attributs.
 Les spécifications formelles de ces modèles sont documentées dans le DICOM
 descriptions d'objets d'information (IOD). Une IOD est une description abstraite d'un
 classe d'entités. Un ensemble ordonné de valeurs représentant les propriétés d'un
 membre d'une classe peut être opéré par un ou plusieurs composites DICOM ou
 services normalisés. Une classe de paires objet de service (SOP) DICOM spécifie la
 combinaison d’une IOD et de l’ensemble des services (groupe de services DIMSE)
 utile pour un but donné. Classes SOP (telles que la réserve de travail de modalité de base
 SOP Class) sont spécifiés dans les classes de service en fonction de leur objectif.
 Les classes de SOP qui utilisent des services composites sont des classes de SOP composites. Normalisé
 Les SOP Classes utilisent des services normalisés. Une instance d’une classe SOP est connue sous le nom de
 instance service paire (SOP). Objets composites et objets normalisés
 sont des synonymes pour les instances de SOP composites et normalisées.

La terminologie des objets DICOM est éclectique, mais elle est également précise. Pour
 brièveté, les classes DICOM SOP sont souvent appelées objets ou informations
 objets. Notez cependant que les objets DICOM sont des objets «statiques».
 Ce sont des structures d’information passives pouvant être exploitées par des tiers.
 méthodes. Ce ne sont pas des composants logiciels autonomes capables de
 polymorphisme, encapsulation et héritage. Leur conception convient à leur
 objectif. Les classes (et les instances) SOP DICOM sont des abstractions utiles pour les données
 échange. Ce ne sont pas des composants d’application en tant que tels. La structure de données
 des classes de SOP DICOM correspondent bien aux structures de données des composants logiciels
 et les groupes de services DIMSE correspondent aux méthodes objet.

Les transactions de message utilisant DICOM commencent par l'établissement de l'association. UNE
 L'association DICOM est une session de communication impliquant une paire de pairs
 DIMSE-service-users (voir). En d’autres termes, une association DICOM est un canal ouvert pour
 échange de messages entre deux périphériques utilisant la machine à protocole DIMSE
 (logiciel) pour générer et recevoir des messages DICOM. Pendant l'association
 processus d’établissement, les deux appareils parviennent à une compréhension commune du
 structures d’information qui seront échangées et les services qui seront fournis
 invoqué (c'est-à-dire la syntaxe abstraite). Paramètres supplémentaires essentiels à
 l'interopérabilité, tels que l'ordre des octets et la méthode de compression des données sont également
 négocié (c'est-à-dire la syntaxe de transfert). Les associations sont gérées par un logiciel
 processus connu sous le nom d'élément de service de contrôle d'association (ACSE). Le DICOM
 protocole spécifie la coordination des fonctionnalités ACSE et DIMSE.

Les classes de services DICOM prennent en charge cinq domaines d'application généraux. Chacun sera
 décrits séparément dans les sections qui suivent. Les classes de service
 activer:

  • Gestion des images en réseau

  • Interprétation d'image en réseau
     la gestion4,16

  • Gestion d'impression en réseau

  • Gestion de procédure d'imagerie

  • Gestion des supports de stockage hors ligne

Gestion d'image de réseau

La gestion d'images réseau DICOM prend en charge deux contextes généraux d'interaction
 entre les périphériques d'imagerie: mode Push et mode Pull. Le service de base est
 Mode «push», dans lequel un périphérique envoie simplement des images à un autre
 appareil sur un réseau informatique (). Le «mode Pull» est un processus plus élaboré en deux étapes.
 qui permet à l'utilisateur d'abord d'interroger un périphérique distant, puis de récupérer
 images sélectionnées ().

Un fichier externe contenant une image, une illustration, etc.
Le nom de l'objet est 0003f02.jpg

Transfert d'image. Le scanner initie des transferts d’images de routine. DICOM fait
 ne pas spécifier le comportement du scanner; le scanner peut commencer à envoyer
 images quand il est prêt. Ceci peut être fait automatiquement comme individu
 les images sont terminées au cours d'une procédure de numérisation, ou peuvent être effectuées ultérieurement
 temps après l'acquisition de toutes les images d'une procédure et le scanner
 L’opérateur a initié le transfert en activant un «envoi d’images»
 touche sur la console du scanner. Lorsque le scanner est prêt à envoyer, il envoie des images.
 un par un au poste de travail. Le scanner initie une communication DICOM
 session (appelée «association») avec le poste de travail pour le
 transfert de chaque image. Différents détails sont négociés lors de l'association
 établissement, de sorte que le poste de travail puisse se préparer à traiter l'image qu'il
 est sur le point de recevoir.

Un fichier externe contenant une image, une illustration, etc.
Le nom de l'objet est 0003f03.jpg

Requête et récupération d'images. Agir sur une requête spécifique entrée par l'utilisateur
 Dans la console du poste de travail, le logiciel du poste de travail fournit au scanner une
 message de requête d'interrogation, demandant des enregistrements d'image dont les valeurs correspondent à un
 ensemble de clés de requête. Le scanner renvoie une liste d'images correspondantes. Maintenant, ayant
 connaître les numéros d'identification des images, l'utilisateur du poste de travail
 sélectionne les images pertinentes dans la liste affichée et entre un
 “Récupérer des images” commande au clavier. Le poste de travail
 Le logiciel envoie ensuite un message au scanner, en indiquant l’identification de l’image.
 numéros et en demandant au scanner d’envoyer les images. Le scanner envoie le
 demandé une à une les images sur le poste de travail, à l’aide du système de stockage DICOM
 Service, comme illustré dans.

La gestion des images réseau DICOM fournit deux fonctions opérationnelles importantes.
 capacités qui manquent dans les systèmes qui utilisent le transfert de fichier générique
 protocoles. Ces capacités sont activées par la sémantique explicite de DICOM.
 La sémantique explicite signifie «compréhension partagée entre le client et le serveur».
 de la structure d’information des objets »ainsi qu’un partage
 compréhension des méthodes (fonctions ou services). Avoir un modèle standard
 (description de l'objet d'information) des propriétés de chaque type d'image
 (comprenant un petit échantillon de données démographiques et liées à la procédure associées
 informations), le dispositif de réception est conscient de la structure d’information de
 l'image avant de la recevoir. Cette compréhension partagée permet le stockage et
 récupération d'ensembles d'images à l'aide d'un système d'indexation pertinent sur le plan clinique
 sur les attributs de l'image plutôt que sur un nom de fichier seul. Avec DICOM c'est
 possible pour un appareil de rechercher des images en utilisant une clé de requête significative telle que
 comme le nom du patient. Une fois reçue, l'image peut être stockée dans le contexte
 d'autres qui s'y rapportent. La sémantique explicite active également les processus logiciels
 affecter les ressources appropriées à la gestion de chaque classe de DICOM
 objet.

Cinq services de gestion d’images de réseau DICOM (types de transaction) sont
 spécifié dans le service de stockage, d'interrogation / récupération et d'engagement de stockage
 Des classes. Les services spécifiés dans ces classes de services sont définis uniquement pour
 Objets composites DICOM. La classe de service de stockage spécifie le C-STORE
 un service. C-STORE permet à un client de transférer (pousser) un objet DICOM vers un
 serveur pour le stockage. Dans la négociation qui se produit entre le client et le serveur
 processus lors de la création d’une association DICOM C-STORE (session), le
 le client informe le serveur de la classe d'objet qu'il propose de transférer
 et le serveur confirme qu'il prend en charge cette classe d'objets informationnels. UNE
 identificateur de classe de service unique, l’UID de classe de SOP (stockage), est défini pour
 stockage de chaque classe d'objet d'information afin que le serveur puisse allouer
 ressources appropriées.

La classe de service de requête / récupération spécifie les fonctions C-FIND, C-MOVE et C-GET
 services et le modèle d'interrogation / récupération DICOM. Le C-FIND, C-MOVE,
 et les services C-GET sont spécifiés dans le contexte d’une vue spécifique de la
 modèle de requête / récupération d'informations qui définit la sémantique des requêtes et
 contraint l'ensemble des clés. La vue souhaitée de la requête / récupérer des informations
 le modèle est sélectionné en envoyant l’UID de classe SOP (interroger / récupérer) approprié dans
 le message de requête

Le service C-FIND permet à un client d’interroger un serveur sur des correspondances avec un
 modèle de valeurs clés. C-FIND permet également au serveur de renvoyer l'objet
 identificateurs d'instance de tout enregistrement correspondant au client. Le service C-MOVE
 permet à un tiers d’entamer le transfert d’objets DICOM entre deux
 Emplacements. Par exemple, un poste de travail d'imagerie peut utiliser C-MOVE pour appeler le
 transfert d'objets image DICOM d'un scanner vers une archive. Le C-GET
 le service est essentiellement un C-STORE inverse. Un processus d'application utilise C-GET
 récupérer (tirer) des objets qui correspondent à un ensemble de valeurs de clé.

Depuis 1995, toutes les principales modalités d’imagerie diagnostique ont été
 normalisé. Cette liste comprend la tomodensitométrie (TDM), la résonance magnétique
 imagerie (IRM), radiographie informatisée, échographie, médecine nucléaire,
 radiofluoroscopie, angiographie à rayons X et capture secondaire (pour numérisation
 vidéo). La spécification d'image DICOM Visible Light (VL) (pour l'endoscopie,
 microscopie et photographie) a été placé sous contrôle de révision et est
 disponible pour le procès
 la mise en oeuvre.17
La gestion des images réseau est le service DICOM le plus largement implémenté.
 Les produits conformes à la gestion des images réseau DICOM sont disponibles dans de nombreux
 vendeurs.

La classe de service d'engagement de stockage spécifie le cinquième réseau DICOM.
 service de gestion d'images. Storage Commitment active une source d’image (la plupart des
 souvent un dispositif d'acquisition) pour obtenir un engagement d'un stockage d'images
 appareil que les images ont été stockées de manière fiable
 () Typiquement, deux types
 des périphériques fournissent ce service: périphériques de stockage à long terme et à court terme.
 Les périphériques de stockage à long terme (archives d'images) s'engagent à stocker les images de manière permanente.
 Les périphériques de stockage à court terme s'engagent à ne conserver les images que pendant un temps limité.
 Par exemple, un hôpital de soins de courte durée peut utiliser un débit élevé,
 périphérique de stockage de capacité moyenne en tant que centre de distribution d'images pour minimiser
 temps d'attente pour des images de patients hospitalisés. Le stockage intermédiaire
 peut transférer plus tard les images vers des applications à faible débit et grande capacité
 support de stockage optique pour archivage permanent après la sortie du patient
 hôpital. Les périphériques de stockage à court et à long terme s’engagent tous deux à
 stockage des images de manière fiable. Cependant, ils s’engagent pour différentes valeurs de stockage
 durée, temps de récupération (délai) et capacité de stockage. De l'utilisateur
 perspective, il est essentiel que les dispositifs prétendant fournir un stockage fiable
 effectivement le faire. Pour se conformer à la norme DICOM Storage Commitment Standard, les périphériques
 doit stocker de manière fiable les images et les informations associées pendant au moins une période spécifiée.
 durée minimale et doit respecter ou dépasser les autres paramètres de performance indiqués
 dans une déclaration de conformité DICOM (voir Spécification DICOM ci-dessous).

Un fichier externe contenant une image, une illustration, etc.
Le nom de l'objet est 0003f04.jpg

Stockage fiable. Storage Commitment est une extension du DICOM de base.
 Service de stockage illustré dans. Après avoir envoyé un ensemble d’images à un périphérique d’archivage, le scanner
 L’opérateur envoie un message de demande d’engagement de stockage à l’archive. le
 Le but du message est double. Tout d'abord, le message demande l'archive
 appareil pour vérifier que toutes les images souhaitées ont été reçues. Seconde,
 le message demande que le dispositif d'archivage assume la responsabilité de la
 conservation des images afin que le scanneur puisse, par exemple, supprimer ses
 copies locales des images. Si tout va bien, l'archive renvoie un
 message de confirmation au scanner. S'il y a un problème avec un ou plusieurs
 images ou avec l’ensemble de l’opération, le dispositif d’archivage renvoie un
 message d'erreur approprié à l'opérateur du scanner.

Gestion d'interprétation d'images réseau

Le supplément 23 de la norme DICOM définit une interprétation d'image de réseau.
 objet (classe d'interprétation structurée) et un objet correspondant.
 service de stockage d'interprétation. Au moment d'écrire ces lignes, la spécification
 est sous une procédure de contrôle de révision formelle et il sera gelé pour le procès
 la mise en oeuvre.

La spécification de classe SOP d’informations d’interprétation structurée utilise
 le groupe de services composite. Par conséquent, le même ensemble de services défini pour
 les images sont utilisées pour les objets d'interprétation structurée. Un structuré
 Une instance de SOP d'interprétation transmet des observations qui constituent une partie de
 les résultats d'une procédure d'imagerie. Le supplément 23 illustre l’ensemble des
 classes d'observation définies pour le rapport d'observation dans DICOM
 () Les observations peuvent être
 liées à d'autres observations via des relations du type de relation spécifié.
 Le supplément 23 introduit la possibilité de lier du texte, du code et des mesures.
 concepts à des ensembles de coordonnées (c'est-à-dire, lier les observations aux caractéristiques de l'image
 évoquant les jugements des observateurs). Cette capacité dépasse la capture
 d'observations. Il permet de documenter les connaissances des observateurs.

Tableau 1

Classes d'observation DICOM

Classe d'observation

La description

Texte Texte libre ou texte catégorique
Code Code catégorique ou terminologie contrôlée
La mesure Enregistrement de mesure codé sous forme structurée. (Remarque: essentiellement un surensemble
 de la classe d'observation CODE. Un réseau de diagnostic pré-coordonné
 concepts de mesure pris en charge par HL7 et / ou connus pour être
 cliniquement utile, tel que Nom de la mesure (c'est-à-dire, Méthode), Méthode de mesure
 Modificateur, valeur, unités de mesure et précision).
Les coordonnées Coordonnées spatiales dans un système de coordonnées DICOM
Dictée audio Dictée audio numérisée d’observation (s). (Remarque: bien que la dictée audio
 SON numérisé, la dictée audio se distingue en tant que classe distincte
 parce que les données représentent la langue parlée qui véhicule l'observation
 informations produites directement par un observateur. Ainsi, AUDIO_DICTATION est
 essentiellement un sur-ensemble de classes d’observation véhiculées par la langue, telles que TEXT,
 CODE et MESURE.)
Image Représentation binaire d'une image.
Du son Représentation binaire d'un son. (Remarque: bien que les données sonores numérisées aient
 la dépendance temporelle, son importance et l'ensemble particulier d'informations contextuelles
 nécessaires pour le justifier suffisent à justifier la catégorisation en tant que
 Classe d'observation distincte de WAVEFORM.)
Forme d'onde Représentation binaire des données en fonction du temps.
Courbe Représentation binaire de données vectorielles. (Remarque: La DICOM Curve IOD spécifie un
 représentation vectorielle de données à n dimensions, et unités associées. Ainsi, un
 L’instance SOP de la courbe DICOM peut être utilisée pour transmettre une représentation statique de
 données WAVEFORM ou SOUND dépendantes du temps. Cependant, la courbe IOD n’est qu’un
 spécification minimale.)
Recouvrir Représentation binaire des données de superposition d'image.
HC_presentation Représentation binaire des données de présentation pour la mise en page ou le formatage sur papier
 d'une image, d'une courbe, d'une superposition ou d'une forme d'onde. Voir la section C.6.7.1.2.1 du
 Standard pour plus de définition.
SC_presentation Représentation binaire des données de présentation pour la mise en page ou le formatage en copie logicielle
 d'une image, d'une courbe, d'une superposition ou d'une forme d'onde. Voir la section C.6.7.1.2.2 du
 Standard pour plus de définition.
Transposé Un espace réservé qui doit indiquer, dans le contexte spécifié par (flags), le
 Concept décrit par (UID d'observation référencé.)
Document_image Représentation numérique du document (Remarque: Bien qu'un DOCUMENT_IMAGE soit un
 IMAGE numérique, DOCUMENT_IMAGE se distingue en tant que classe distincte car le
 les données peuvent représenter un langage écrit véhiculant des informations d'observation
 produit directement par un observateur. Ainsi, DOCUMENT_IMAGE est essentiellement un
 super ensemble de classes d’observation véhiculées par la langue, telles que TEXT, CODE et
 LA MESURE. DOCUMENT_IMAGE peut contenir du texte écrit ou imprimé, des graphiques,
 ou d'autres formes d'informations.)

Autre

Données binaires de type non restreint.

L'objet d'interprétation structurée est un message générique hautement adaptatif.
 modèle qui peut être spécialisé pour diverses applications en référençant le
 SNOMED DICOM Microglossary (Nomenclature Systématisée des Ressources Humaines et Vétérinaires)
 Médecine, Collège des pathologistes américains, Northfield,
 IL).18,20
L'objet de rapport structuré peut être adapté à différents contextes de spécialité
 par substitution de listes de termes appropriés en tant que domaines de données d'entrée codées
 éléments. Pour ajouter un nouveau type de rapport (par exemple, une endoscopie gastro-intestinale ou
 rapport de cathétérisme cardiaque) à DICOM, pas de ré-enregistrement du test structuré.
 L'objet d'interprétation est nécessaire. Les mises à jour nécessaires sont effectuées en faisant
 ajouts appropriés à la base de données SNOMED DICOM Microglossary.

L'objet d'interprétation structurée introduit le concept d'observation
 sujet (). Chaque
 L’observation faite par un observateur est marquée avec un UID d’observation (Observation
 Identifiant unique) et attribué à un et un seul sujet d'observation. Ce
 le formalisme permet d'agréger toutes les observations pour une observation donnée
 assujettir. Le sujet d’observation est particulièrement utile en obstétrique
 échographie, où il est souvent nécessaire de lever la ambiguïté des observations
 de la mère à partir des observations du fœtus. Permis sujet d'observation
 les observateurs de récupérer séparément les observations du jumeau A ou du jumeau B enregistrées
 tout au long de la grossesse dans une série d'examens échographiques et autres
 procédures.

Tableau 2

Classes de sujets d'observation

Valeur énumérée

Description du sujet d'observation

Non contraint Aucune contrainte contextuelle des observations à un sujet d'observation
Procédure Contexte administratif de la procédure d'imagerie et de la procédure interprétative
La personne Une personne vivante existant en tant qu'entité indépendante
Fœtus Un bébé à naître porté chez une mère vivante
Spécimen UN ÉCHANTILLON dérivé de la substance physique d'une personne ou d'un foetus
Les données Données binaires. Les instances d’observation de la classe d’objets d’observation DATA doivent
 Décrire uniquement les facteurs techniques intrinsèques au processus d’acquisition des données.
 Des exemples de facteurs techniques incluent la description de: La qualité d’exposition des
 une radiographie numérique; positionnement d'un sujet d'imagerie; décalage statique d'un
 forme d'onde dynamique; atténuation sélective du son dans les hautes fréquences; ou magnétique
 artefacts d 'inhomogénéité de champ dans une image de résonance magnétique. Une remarque
 ayant une classe de sujet d'observation (0040, A403) = "DONNEES" ne doit pas
 décrivent les propriétés intrinsèques d’une personne, d’un fœtus, d’un échantillon ou de
 AUTRE sujet d'observation. Observations ayant une classe de sujet d'observation =
 Les “DONNÉES” peuvent cependant être liées via la séquence de relations
 (0040, A731) à des instances de toute autre classe d'observations (définies pour toute
 classe de sujet d'observation).

Autre

Toutes les autres classes de sujets d'observation

La spécification d'interprétation structurée a été adoptée en décembre 1996 par
 l'industrie des ultrasons de la National Electrical Manufacturers Association (NEMA)
 groupe pour la mise en œuvre d'essai. À partir de janvier 1997, mise en œuvre des essais
 des projets sont prévus en radiologie, pathologie, endoscopie gastro-intestinale,
 dentisterie et ophtalmologie.

Gestion d'impression en réseau

DICOM Network Print Management permet aux périphériques d’acquisition d’images et
 postes de travail pour partager une imprimante sur un réseau DICOM
 (), semblable au chemin
 que les ordinateurs personnels partagent une imprimante laser en réseau. Annexe H du PS 3.4
 spécifie le service de gestion d'impression
 Classe.21 Le DICOM
 La spécification de gestion d’impression définit un ensemble de base de fonctions obligatoires et
 certaines extensions optionnelles. Quatre classes de méta SOP (ensembles d’interdépendants
 objets conçus pour être utilisés de manière coordonnée) sont spécifiés pour
 applications d'impression de base. Les classes de méta SOP obligatoires prennent en charge (1) basic
 l’impression en niveaux de gris, (2) l’impression couleur de base, (3) l’impression en niveaux de gris avec
 amélioration de la table de consultation et impression (4) en couleur avec table de consultation
 renforcement. Au moins une des quatre classes de méta SOP obligatoires doit être
 mis en œuvre afin de prétendre à la conformité à la norme. Toute combinaison de
 Des classes SOP facultatives peuvent également être utilisées. Les classes de SOP facultatives permettent filmer
 annotations, superpositions d'images et création de rapports améliorés sur l'exécution des travaux d'impression
 statut.

Un fichier externe contenant une image, une illustration, etc.
Le nom de l'objet est 0003f05.jpg

Impression en réseau. En préparation à l'impression, le poste de travail en premier
 établit une session de communication avec l’imprimante (un logiciel de gestion de l’impression
 Association, créée de la même manière que l'Image Storage Association
 illustré dans). À
 établissement d'association, divers détails sont négociés. Puis le
 poste de travail informe l’imprimante de la disposition souhaitée de la sortie imprimée afin
 l’imprimante peut préparer le format approprié pour recevoir les images. le
 Le poste de travail envoie ensuite les images une par une à l’imprimante. L'imprimante
 renvoie des notifications d'état au poste de travail afin que l'utilisateur puisse surveiller la
 progression du travail d'impression.

La classe Méta SOP de gestion d’impression en niveaux de gris de base est décrite plus
 des détails pour illustrer le besoin d’un groupe coordonné de classes de SOP imprimées.
 La classe SOP de la gestion d'impression de base en niveaux de gris comprend le film de base
 Classe SOP de session, classe SOP de la boîte de film de base, boîte d’image de base en niveaux de gris
 SOP Class et la SOP imprimante
 Classe.21 Depuis film
 les sessions peuvent contenir de nombreux films et les films peuvent contenir de nombreuses images, la SOP
 les classes qui les représentent doivent prendre en charge des relations similaires. Par conséquent, un
 L'instance SOP Basic Film Session fait référence à une ou plusieurs SOP Basic Film Box.
 Instances et une instance SOP Basic Film Box référence un ou plusieurs éléments de base
 Instances SOP de la boîte à images en niveaux de gris. Instances SOP de la boîte d’images de base en niveaux de gris
 transmettre les données de pixels réels. En outre, les films peuvent faire référence à des annotations textuelles
 des objets et des images peuvent être associés à
 superpositions.21
Les services N-ACTION sont définis pour l’impression d’un seul film ou de la totalité
 session.

La classe SOP imprimante représente le périphérique imprimante. État de l'imprimante
 les notifications sont prises en charge par le service N-EVENT_REPORT.

Au moment d'écrire ces lignes, une classe de service d'impression PostScript DICOM, une
 classe SOP de file d'attente d'impression révisée et une classe SOP de stockage d'impression sont en cours de finalisation.
 phases de développement. L'objet Stockage d'impression permettra le stockage de
 imprimer les paramètres de présentation afin que les images en double identiques à la
 les originaux peuvent être produits ultérieurement à partir des copies électroniques.

Gestion de procédure d'imagerie

Classe SOP de gestion de l'étude et classe SOP de gestion des composants d'étude
 fournir une capacité complète de gestion des procédures d'imagerie. SOP d'étude
 mappe d'instances aux procédures demandées, et étudie la mappe d'instances de composant SOP
 effectuer les étapes de la procédure. Ce sont des classes normalisées SOP. En tant que tels, ils
 prendre en charge les services N-SET et N-EVENT_REPORT et assurer la gestion de l'état et
 installations de notification d'événements. Supplément 17, Étape de procédure effectuée
 gestion, est presque terminé au moment d'écrire ces lignes. Ce projet
 supplément fournit un petit nombre de nouveaux attributs pour la description de
 procédures d'imagerie et permet un meilleur couplage de la composante d'étude
 (étape de procédure exécutée) avec la nouvelle classe de procédures opératoires standard des listes de tâches de modalité DICOM (voir
 ci-dessous pour une description plus détaillée).

Le modèle de requête et de récupération composite DICOM (voir ci-dessus) fournit un mécanisme
 pour construire une base de données hiérarchique des patients, des études, des séries et des images.
 Ce modèle d'image a été largement utilisé comme base pour la procédure d'imagerie
 bases de données de gestion, en particulier lorsque les dispositifs d’acquisition d’images ne sont pas compatibles.
 lié à un système d'information externe (SI). Dans ce scénario non-IS,
 des identificateurs de procédure peuvent être attribués par l'équipement d'imagerie. Cela mène à
 nécessité de réconcilier les identifiants de procédure avec un autre système, post facto.

Gestion des procédures d'imagerie composite et normalisée DICOM
 Les paradigmes se croisent dans l’élément de données UID de la Instance d’étude (balise DICOM:
 0020,000D). This is a mandatory data element that is defined in all composite
 image SOP classes and in the normalized study management SOP Class. Thus, it
 is possible to map between the composite and normalized perspectives via the
 Study Instance UID.

The basic modality worklist SOP Class utilizes a new query-retrieve model
 that is designed to improve access to demographic and scheduling information
 residing on non-DICOM information systems. DICOM does not have a procedure
 scheduling facility. However, a DICOM scheduling system is not necessary in
 environments where a scheduling system already exists. An imaging device can
 obtain the necessary information by querying the external system. The external
 system can either implement a DICOM service-class-provider process for
 modality worklist, or it can communicate with the imaging system through a
 gateway. The modality worklist SOP class includes only a query model.
 Therefore, there it does not provide a way to notify the information system of
 state changes in the scheduled procedure (such as “canceled” or
 “completed”). This capability being added performed procedure step
 (revised study component) SOP Class ().

An external file that holds a picture, illustration, etc.
Object name is 0003f06.jpg

Obtain a worklist. The modality worklist is an itemized list of imaging
 procedures that are scheduled to be performed on a particular scanner or on
 any scanner of the specified imaging modality type. The original requests for
 imaging procedures are first received and processed by an information system.
 The order entry and/or scheduling application of the information system
 schedules procedures and prepares worklists for the appropriate imaging
 équipement. At periodic intervals (determined by department policy) the scanner
 polls the information system for an updated worklist. Upon receiving a
 worklist request, the information system sends the current worklist to the
 scanner. The DICOM Worklist Management service class does not specify how the
 information system is notified that a worklist item is complete. This is done
 by another DICOM service that manages Performed Procedure Steps.

Joint work with Health Level Seven (HL7), Inc., on a standard mapping of
 the DICOM modality worklist information object definition to the HL7 Standard
 is underway at the time of this writing. The goals of this work are to achieve
 a good mapping of common attributes to facilitate gateway design in the short
 term and to work toward a common HL7 and DICOM understanding of the
 Information System-Imaging System interface. In spite of the usefulness of the
 new modality worklist query model, there is still need for improvement in
 DICOM query facilities. A structured query language (SQL) approach is
 desirable, but consensus on the messaging protocol for “DICOM SQL”
 has not been reached.

Off-line Storage Media Management

DICOM Off-line Storage Media Management enables users to manually exchange
 DICOM files on removable storage media. There is a DICOM file format for
 3.5-inch diskettes, compact disk read-only memory (CD-ROM) disks, and optical
 disks. A DICOM file can include not only images but also the related
 information that distinguishes one image from another (e.g., pertinent details
 of the performed procedure, interpretation text, or the format settings for
 printing). The possibility of sending image-related information is one of the
 most important features that distinguish DICOM from the many image file
 standards that are limited to image data alone. DICOM defines a file format
 and a file directory for images and related information. Users can specify
 preferred types of physical media to transport DICOM files for a particular
 clinical imaging context (e.g., coronary angiography, general diagnostic
 ultrasonography, gastrointestinal endoscopy). For example, the Cardiology
 community in the United States has specified the storage of Coronary
 angiograms and cardiac catheterization images on compact disk read-only media
 using Joint Photographic Experts Group lossless compression. Other possible
 applications of DICOM Off-line Storage Media Management are transport of
 diagnostic images from a portable imaging unit to a consulting department or
 from a diagnostic workstation to a clinical conference room.

Clinical Scope of DICOM

The immediate predecessor of the DICOM Standard was the ACR-NEMA Digital
 Imaging and Communications
 Standard.5 The basic
 principles of this Standard have been refined and generalized in DICOM to be
 capable of handling diagnostic and therapeutic images of any type. le
 multimodality and multispecialty capability of DICOM has attracted interest
 from all specialties that perform biomedical diagnostic or therapeutic imaging
 (including dentistry and veterinary
 medicine).13,19
In 1996, the DICOM Standard supported the following diagnostic imaging
 modalities: x-ray angiography, computed radiography, computed tomography,
 magnetic resonance imaging, nuclear medicine, radiofluoroscopy, and
 ultrasonography. The x-ray angiography specification also fully supports
 angiography (general arteriography, lymphography, and venography; cardiac
 catheterization and coronary angiography; carotid and cerebral angiography);
 fluoroscopy (such as arthrography, gastrointestinal barium examinations,
 myelography); and interventional procedures. At the time of this writing,
 major new supplements to the DICOM Standard are being prepared for ballot,
 including positron emission tomography, radiation oncology, visible light
 imaging, and structured reporting. The Visible Light Image Supplement has been
 introduced to support diagnostic imaging devices (endoscopes, microscopes, and
 cameras) that produce reflection or transmission color photographic images.
 The Visible Light Supplement also specifies a new anatomic frame of
 référence
for imaging modalities that do not use a patient-based
 coordinate system, but describe orientation in terms of anatomic
 landmarks.17 le
 imaging procedures supported by the DICOM Visible Light specification
 include:

  • Fiber-optic and rigid-scope endoscopy (e.g., angioscopy, arthroscopy,
     bronchoscopy, colposcopy, cystoscopy, fetoscopy, hysteroscopy,
     gastrointestinal endoscopy, laparoscopy, nasopharyngoscopy, sinoscopy)

  • Light microscopy for anatomic pathology (e.g., transmission light
     microscopy and reflection light microscopy for cytology and histology)

  • Surgical microscopy (e.g., images produced by operating microscopes used in
     cardiothoracic surgery, general surgery, neurologic surgery, obstetrics and
     gynecology, ophthalmologic surgery, oral and maxillofacial surgery, orthopedic
     surgery, otorhinolaryngology, pediatric surgery, plastic surgery, urologic
     surgery and vascular surgery)

  • General anatomic photography (e.g., anatomic pathology, biostructure,
     dermatology, dentistry, forensic pathology, ophthalmology, and general medical
     and surgical applications)

How Does DICOM Affect Daily Work?

Strategy for Filmless Image Management

Since the 1970s, there has been a growing expectation that all medical
 images soon would be managed neatly and efficiently in digital form. The term
 “Picture Archiving and Communications System” was coined in the
 Radiology literature to describe a departmental digital image management
 système. In the 1990s, great strides have been made toward achieving a filmless
 Radiology
 department.6,7,8,9,dix,11
The DICOM Standard and the earlier versions of the American College of
 Radiology, National Electrical Manufacturers' Association Standards have
 contributed substantially to this progress. While filmless Radiology
 departments are being tested in a few major hospitals, the typical hospital or
 imaging center first uses DICOM to support various subsets of imaging instead
 of linking up a complete department at once. This is a practical approach.
 DICOM provides the user with the flexibility to develop an image management
 system in manageable steps. Designing a system around DICOM can prevent a
 department from being “trapped” by a single vendor and limited to
 a proprietary family of products. Naive implementation of DICOM does not
 guarantee this flexibility, however. It is necessary to understand precisely
 what can be expected from the Standard.

Realistic Expectations

Grouping images having similar properties into various different types of
 manageable “information objects” allows software to manage diverse
 things in a sensible manner. “Management” of information over
 computer networks implies the coordination of work across multiple computers.
 As is typical in the general computing industry today, DICOM uses the concept
 of “client-server computing” as the organizational model for
 specifying what functions devices and software agents must perform. DICOM was
 written in terms of service-class-users (clients) and service-class-providers
 (servers). Options for the composition of a DICOM message are specified
 explicitly right down to the lowest levels, such as determining whether, for
 example, data is represented with the most significant byte first or last.

One of the reasons that DICOM has been successful in a wide variety of
 clinical imaging contexts is that the Standard specifies a Conformance
 Statement that improves the communication of software specifications for
 imaging equipment. The Conformance Statement includes all of the details
 introduced in the preceding paragraph and many more (see Specifying DICOM,
 au dessous de). The DICOM Conformance Statement provides a means by which a customer
 can evaluate in detail whether a certain product provides the image management
 functions that are desired and a vendor can specify the precise description of
 the DICOM image management functions provided by equipment offered for sale.
 With all of the material that manufacturers must provide to support their
 claims of conformance to DICOM, it would seem that the specification of DICOM
 would ensure a “plug and play” image management system. Autant que
 those who worked on DICOM would like this to be true, there are very few
 applications for which this will be the case.

Here is an important caveat for the reader. One must keep in mind that a
 simple advertisement stating that a piece of equipment “conforms to
 DICOM” does not alone guarantee the manufacturer has adhered to the
 Standard. One must ensure that the manufacturer provides equipment that
 operates precisely in the manner specified in the Conformance Statement. Ce
 means that, for many of us, expert consultation may be required for proper
 specification of a purchase contract for imaging equipment. A health care
 professional with no expertise in digital imaging systems should not expect to
 find the complete guide to “plug and play” image network
 specifications in the DICOM Standard. While this may be seen by some as a
 shortcoming of DICOM, it is actually a reflection of the complexity of
 diagnostic imaging per se. The many modules and user-configurable options
 provided by DICOM support an enormous variety of clinical imaging practice
 contexts. The Standard provides a means for a knowledgeable expert to specify
 systematically the image management features of a particular system.

DICOM and the User

The user of DICOM-based systems can reasonably expect to gain a much
 simplified way of interfacing imaging equipment and having it interoperate. Dans
 some instances, interfacing can be very nearly a “plug and play”
 expérience. At the hardware levels, connection is straightforward. Things like
 setting the network addresses and some of the DICOM options that are set at
 installation must be configured by an engineer. The end result is a reliable
 communications interface.

At the level of image display, the user can expect that images will be
 displayable at the spatial and contrast resolution values at which they were
 acquired. Also, the patient demographic information and information about the
 manner in which the image was acquired will be accessible. For imaging that
 uses sequences of images (ultrasound, nuclear medicine, angiography,
 endoscopy, and microscopy) cine-type displays can be supported. If the display
 systems support it, color images (pseudo-color for ultrasound or nuclear
 medicine and direct visualization color for photographic applications such as
 endoscopy and microscopy) are also displayable.

At the level of data entry, DICOM influences the task of the user. le
 information associated with each image has been prioritized into three
 categories. Very few mandatory elements are specified. These are typically
 identification numbers of images and similar units of information that are
 automatically entered by the computer (without disturbing the user's train of
 thought). A second class of information is that which is judged to be of
 special clinical importance. Fields such as Patient Name and Patient
 Identification Number are of clinical significance; however, if the
 information in unknown, a null entry may be given. Such “clinical
 priority” fields are created parsimoniously, since they do place a
 burden on the user. The final category of DICOM information elements are the
 user-optional fields. Ideally, upon the advice and approval of the users at
 each site, a manufacturer may implement any number of the optional DICOM data
 entry fields. A wide variety of optional descriptive fields is available. Un
 must settle on a reasonable compromise and select a user interface according
 to well-known design principles and individual preferences.

For a number of data fields, DICOM provides either “Enumerated
 Values” or “Defined Terms.” For example, for a few
 attributes, such as “laterality of a paired body part,” DICOM
 defines a mandatory set of enumerated values. Enumerated values are defined by
 the standards committee and may be changed only by re-balloting the Standard.
 For example, the following choice is mandatory for laterality:
 “right” and “left.” In order to conform to DICOM, a
 system must present these and only these two options to the user. However, for
 other attributes, the standards committee offers a set of typical selections
 that can be refined by the users to carry out local requirements. For example,
 the DICOM field for “film cassette size” offers a series of
 typical dimensions. This list can be extended or replaced by a list that suits
 the local environment.

The trend in computer-based record systems is to increase the proportion of
 clinical information that is recorded in a structured format rather than in
 freetext format. Since structured data entry places an additional burden on
 the user, DICOM provides both free-text and coded-entry options. Où
 structured encoding is needed, the fields are available. Where simple free
 text may suffice, the option is present. For complex concepts, such as
 anatomy, morphology, and physiologic function, DICOM simplifies the task of
 structured encoding by offering subsets of terms that are appropriate for data
 entry. For example, the anatomic reference points that identify the location
 of direct visualization color images may be selected by the user from a short
 pick-list rather than from an unabridged list comprising literally thousands
 of anatomic sites. Appropriate pick-lists of anatomic structures and spaces
 can be specified for any clinical context.

Multi-specialty imaging terminology for DICOM coded entry data elements is
 available in the SNOMED DICOM
 Microglossary.18,20
Terminology covers a variety of concepts, such as anatomic structures, spaces,
 and regions; morphology; function; physical agents; chemical and biologic
 products; living organisms; and geometric and spatial terms. With technical
 assistance from the College of American Pathologists, medical professional
 specialty societies are jointly developing content for the SNOMED DICOM
 Microglossary. As of January 1997, basic term lists have been completed for
 the coded entry data fields of the DICOM X-ray Angiography, Nuclear Medicine,
 and Ultrasound Standards. The American and European Societies for
 Gastrointestinal Endoscopy, the American Academy of Ophthalmology, the
 American College of Chest Physicians, the American Urological Association, the
 American College of Cardiology, the American Society for Echocardiography, and
 other organizations have provided terminology that adapts the trial-use DICOM
 Visible Light and Structured Reporting standards to their clinical contexts.
 In summary, the structured encoding of complex information is an area where
 DICOM can have a major impact on the working environment of the user. DICOM is
 designed to allow users to benefit immediately from technologic advances that
 increase the efficiency and precision of structured encoding and enhance
 information retrieval.

Connecting Imaging Equipment to Existing Information Systems

DICOM allows imaging modality equipment operators to receive worklists
 (lists of imaging procedures that are scheduled to be done on their
 equipment). This worklist capability reduces duplicate data entry at the
 modality console. The DICOM modality worklist interface also allows the user
 to query another information system about additional details of a requested
 procedure or about a patient. Development of this modality worklist component
 of the DICOM Standard was initiated by a working group of the European
 Standardization Committee. This portion of DICOM is now a Standard or
 Pre-Standard in Europe, Japan, and the United States. In June 1996, products
 implementing the DICOM Modality Worklist standard were demonstrated at the
 Computer Applications in Radiology (CAR) Congress in Paris. The DICOM modality
 worklist specifications are being mapped to the Health Level Seven (HL7)
 general information system Standard (Health Level Seven, Inc., Ann Arbor, MI).
 Users of DICOM systems will benefit from this HL7-DICOM mapping work, since
 the majority of hospital information system vendors already provide HL7
 interfaces for their scheduling and patient demographics management
 systems.

A joint committee of HL7 and DICOM, the HL7-DICOM Image Management Group,
 is developing a standard approach to HL7-DICOM interconnection that will
 simplify installations and may reduce interface development cost for
 individual sites. The interface is known as the “HL7-DICOM Information
 system-Imaging System interface.” (This name is abbreviated variously as
 the “HL7-DICOM ISIS interface,” the “HL7-DICOM
 interface,” or the “ISIS interface” between HL7 and DICOM.)
 Since work on the HL7-DICOM interface is progressing rapidly at the time of
 this writing, we suggest that interested persons obtain the latest information
 via the WWW. All documents are available on a server provided by Duke
 University Medical Center. The Universal Resource Locator address of the
 HL7-DICOM Image Management Group is
 http://dumccss.mc.duke.edu/standards/HL7/committees/image-management/im-home.html.

It is important for the user to understand that DICOM enables these
 capabilities to users but that the implementation is still dependent on
 manufacturers and institutions. The standardized nature of these services and
 information, though, means that the development time and availability of such
 capability will be much improved. It should also mean a wider availability of
 such functions.

DICOM Evolution

The expansion of DICOM into more complex image management scenarios,
 information system interfacing and structured encoding of interpretations are
 areas where DICOM will have a direct impact on users. The refinements that are
 constantly being introduced in the “back-end” mechanisms of DICOM
 in terms of hardware interfacing, image communications, concept representation
 and image display will enable steady improvements in the
 “front-end” application software that is visible to the user.
 DICOM development has already extended across multiple specialties and
 national boundaries, and the expansion into the information management
 environment is rapidly
 progressing.13 Pour
 users, this will mean that their DICOM-supported image management systems can
 be integrated into healthcare enterprise information systems.

How Can One Take Advantage of the Benefits of DICOM?

Specifying DICOM

The DICOM Standard exists primarily to address the long-standing
 requirement for communication interoperability among medical imaging devices.
 Equipment vendors are required by the Standard to provide Conformance
 Statements that accurately describe their DICOM implementation. Conformance in
 this context means compliance to the requirements of the Standard. Plus
 concretely, the capabilities and behaviors of an implementation must match
 both the conformance requirements of the Standard and a vendor's conformance
 claims.

A Conformance Statement is a document that a vendor must provide to
 customers in order to clearly describe what parts of the DICOM Standard are
 supported by a particular piece of equipment. DICOM includes a broad selection
 of services (e.g., storage, query/retrieve, print) and a variety of options
 within each. Any implementation will logically include only a subset of
 functions and optional elements. In order to know whether system A can
 communicate with system B, it is necessary to have a complete and precise
 description of the capabilities of each system. The purpose of a Conformance
 Statement is to provide a meaningful and comparable list of capabilities of
 each system.

The goal set forth by the drafters of the DICOM Standard is to allow a
 knowledgeable user to determine if interoperability between two
 implementations is possible by comparing their Conformance
 Statements.14 Il est
 important to note that, if the Conformance Statements are complementary and
 the vendor's implementations are adequately and accurately described by these
 statements, the probability of interoperability is greatly increased, but it
 is not ensured. It is not possible to prove interoperability by examining
 Conformance Statements alone. It is possible, however, to prove the
 impossibility of interoperability.

What is perhaps more important, however, the Conformance Statement may be
 viewed as a set of testable claims that the vendor makes concerning the
 behavior of a specific system. Vendors are required to conduct thorough
 conformance testing to ensure that their implementation correctly and fully
 matches the claims made in the Conformance Statement. Thus, the Conformance
 Statement serves as a testing guideline for the vendor long before it is
 distributed to users.

A Conformance Statement is a highly structured document designed to make
 the key attributes on an implementation readily apparent. A DICOM Conformance
 Statement comprises four main sections: Problem Statement, Application Entity
 Specifications, Communication Profiles, and Specializations. The initial
 segment of a Conformance Statement must identify the domain of application of
 the implementation: e.g., “transferring images from an MR scanner to a
 storage device.” The Conformance Statement must indicate how this
 implementation is designed to interact with the real-world. This initial
 Problem Statement sets the scope of the document.

It is assumed that a DICOM implementation will consist of one or more
 packages of hardware and software. These packages or Application Entities are
 identified in the second section of the Conformance Statement and given names.
 The bulk of a Conformance Statement is given over to completely specifying the
 functionality and constituent components of these packages. Each software
 process will implement one or more DICOM services and will be defined either
 as a user or a provider of that service. Each software process will encode
 information in at least one but possibly several different ways. Finally, each
 software process will have rules governing when it will accept or initiate
 connections to other DICOM systems. Taken together this information yields the
 section of the Conformance Statement known as the “Application Entity
 Specification.”

DICOM is a communication standard. Logically, one would expect that a
 detailed engineering specification of the communication software or protocol
 to be a part of a Conformance
 Statement.15 UNE
 description of these components is required in section three of the DICOM
 Conformance Statement. The Conformance Statement must identify which of the
 available communication protocol options is used. It also must provide
 necessary implementation details such as which Media Access protocols (e.g.,
 FDDI, Ethernet, ISDN) and which physical media (e.g., fiber, coaxial cable,
 twisted pair) are supported.

The DICOM Standard is defined to be extensible. An implementer may include
 additional optional attributes in a standard object, such as an image, and
 really not impact another implementation's ability to utilize that object. Si,
 however, a vendor chooses to add attributes that are essential for the
 interpretation of the object, or to define totally new objects not currently
 covered by DICOM, it is important that this fact be clearly communicated in
 the Conformance Statement. The goal of DICOM as implemented in Conformance
 Statements is to eliminate surprises when two systems are interconnected. le
 use of private attributes and objects should be discouraged by the user
 community since this greatly limits the possibilities for interoperability.
 However, if private attributes and objects are utilized the final section of
 the Conformance Statement must contain a complete description so that other
 vendors might have a possibility of adapting to them.

The first requirement that a vendor must meet when claiming DICOM
 conformance is the availability of a proper Conformance Statement. Given that
 the vendor meets this requirement, what is the next step? What does a user or
 system integrator do with these statements? Let us assume two hypothetical
 systems: A and B that we wish to interconnect via DICOM, If we examine the
 Conformance Statement for these systems there are several obvious areas where
 incompatibility may arise. For example, if both systems support DICOM storage
 but A only supports MR images and B only CT images, then the two systems will
 not be able to communicate. Similarly, if A uses DICOM over TCP/IP on an
 Ethernet and B uses DICOM over an ISO protocol stack on an FDDI, communication
 is impossible. More subtle differences are equally significant. For example,
 if both systems support CT image storage using the same communication stack,
 it would seem that they could talk; however, if both indicate that they can
 only play the role of service user (both are clients), communication is in
 fact impossible.

By analyzing the DICOM Conformance Statements of potentially interconnected
 equipment is is possible to rule out some configurations without going to the
 expense of actually buying the systems and connecting them. If two systems
 seem compatible based on Conformance Statement analysis, it is still
 necessary, unfortunately, to test whether or not they can actually
 communicate. Experience has shown, however, that the probability of
 communication is high if the Conformance Statements match.

Caveat Emptor

Because DICOM supports a broad range of options in the categories of
 communications, structure of the data, and functions to be performed by image
 management devices, simply calling for “DICOM conformance” may not
 be enough to ensure that devices will work together appropriately. If a system
 that supports DICOM is already in place and a user is seeking equipment that
 can interface to it, the user should review the Conformance Statement of the
 existing equipment to determine what it supports. These choices can then be
 included as requirements for DICOM conformance on the part of new
 équipement.

If a completely new environment is being developed, and DICOM is
 anticipated as the interface standard to use, the specification problem is
 more difficult because the user does not have an established base from which
 to work. If there is sufficient in-house experience, local engineering
 personnel can review the Conformance Statements of various vendors and
 determine with some degree of certainty whether or not two devices will work
 ensemble. Without such engineering expertise, the user may have to rely on
 manufacturers or a consulting engineer. One way to help avoid problems is to
 require all equipment vendors to review their Conformance Statements together
 in a meeting with the user (and any necessary technical consultants). Ce
 puts the burden of determining and guaranteeing interoperability on the
 manufacturers supplying the equipment.

Références

1. Digital Imaging and Communications in Medicine
 (DICOM)
. NEMA Publications PS 3.1-PS 3.12. The National Electrical
 Manufacturers Association. Rosslyn, VA, 1992, 1993, 1994,
 1995.

2 Health Level Seven. An Application Protocol for Electronic
 Data Exchange In Healthcare Environments
. Version 2.2. Health Level
 Seven, Inc., Ann Arbor, MI, 1994.

3 Request and report messages for diagnostic service
 départements
. Medical Informatics CEN/TC 251/N95-027 Draft First
 Working Document (Red Cover Procedure) CEN/TC 251/PT3-022 BC-IT-M-021 v. 1.1,
 1995-08-18.

4 Bidgood WD, Jr. Documenting the information content of images.
JAMIA, in press. [PMC free article] [PubMed]

5 American College of Radiology, National Electrical Manufacturers
 Association (ACR-NEMA) Standards Publication number 300-1988: Digital
 Imaging and Communications
. Washington, DC: National Electrical
 Manufacturers Association, 1989:
 iii.

6 Irie G. Clinical experience: 16 months of HU-PACS. In: Huang HK,
 Ratib O, Bakker AR (eds.): Picture Archiving and Communication Systems
 (PACS) in Medicine
. NATO ASI Series F, V. 74. Berlin, FRG,
 Springer-Verlag, 1991:
 183-8.

7. Allison DJ, Martin NJ, Reynolds RA, Strickland NH. Clinical Aspects
 of PACS. Proceedings of the 18th International Congress of
 Radiology
. 1994:
 813-9.

8 Siegel EL. Filmless radiology department: VA Baltimore experience
 (abstract). Radiology 189(P) Supplement. 1993:
 93.

9 Mosser H, Partan G, Hruby W. Clinical routine operation of a
 filmless radiology department: three years' experience. Proc SPIE v.
 2435; PACS Design and Evaluation
; 1995.
 321-7.

dix. Smith DV, Smith S, Bender GN, et al. Lessons learned and two years'
 clinical experience in implementing the medical diagnostic imaging support
 (MDIS) system at Madigan Army Medical Center. Proc SPIE v. 2165:
 Medical Imaging
1994.
 538-55.

11 Choi HS, Ro DW. Clinical implementation of the Samsung
 Medical Center PACS
(abstract). IMAC '95 Abstracts; August 20,
 1995. Oahu, HI.

12 McCray AT. Personal communication. March 18,
 1996.

13 Bidgood WD Jr, Horii SC. Extension of the DICOM Standard to new
 imaging modalities and services. J Digit Imaging.
 1996;9:
 67-77. [PubMed] [Google Scholar]

14 Digital Imaging and Communications in Medicine (DICOM):
 Conformance
. Washington, DC: NEMA Publication PS 3.2-1993.
 1993.

15 Malmud C. Stacks, Interoperability in Today's Computer
 Networks
. Englewood-Cliffs, NJ: Prentice-Hall,
 1992.

16 Digital Imaging and Communications in Medicine (DICOM). NEMA
 PS 3. Supplement 23: Structured Reporting. Working Draft, Version
 1.11
. The National Electrical Manufacturers Association. Rosslyn, VA,
 1996.

17 Digital Imaging and Communications in Medicine
 (DICOM)
. NEMA PS 3. Supplement 15: Visible Light Image and Anatomic
 Frame of Reference for Endoscopy, Microscopy, and Photography. Draft for
 Public Review. The National Electrical Manufacturers' Association. Rosslyn,
 VA, 1996.

18 Bidgood WD, Jr. SDM/TeRMS Documentation: Version
 1.0
. Minutes of the SNOMED Editorial Board, February 2-4, 1996.
 College of American Pathologists. Northfield, IL,
 1996.

19 Benn DK, Bidgood WD, Jr, Pettigrew JC, Jr. An imaging standard for
 dentistry: extension of the radiology DICOM standard. Oral Surg, Oral
 Med, Oral Pathol
. 1993;76:
 262-5. [PubMed] [Google Scholar]

20 Coté RA, Rothwell DJ, Palotay JL,
 Beckett RS, Brochu L, eds. The Systematized Nomenclature of Human and
 Veterinary Medicine
. Northfield, IL: College of American Pathologists,
 1993.

21 Digital Imaging and Communications in Medicine
 (DICOM)
. NEMA Publications PS 3.4-1993. Service Class Specifications.
 The National Electrical Manufacturers' Association. Rosslyn, VA,
 1994.

Comprendre et utiliser DICOM, la norme d'échange de données pour l'imagerie biomédicale – Serveur d’impression
4.9 (98%) 32 votes