
Comprendre et utiliser DICOM, la norme d'échange de données pour l'imagerie biomédicale – Serveur d’impression
Sommaire
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.
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.
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.
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.
Commentaires
Laisser un commentaire