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.

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 ().

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.

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).

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.

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 ().

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.

Click to rate this post! [Total: 0 Average: 0]