You are on page 1of 18

Conectividad DICOM: lo que el radiólogo debe saber

Poster no.: S-1072


Congreso: SERAM 2012
Tipo del póster: Presentación Electrónica Educativa
Autores: S. González Ortega, J. C. Rayón-Aledo, B. Bandres Carballo,
D. Tagarro Ferrero, M. Cigüenza Sancho, M. Aragonés García;
Madrid/ES
Palabras clave: Aplicaciones informáticas-General, PACS, Aplicaciones
informáticas
DOI: 10.1594/seram2012/S-1072

Cualquier información contenida en este archivo PDF se genera automáticamente


a partir del material digital presentado a EPOS por parte de terceros en forma de
presentaciones científicas. Referencias a nombres, marcas, productos o servicios de
terceros o enlaces de hipertexto a sitios de terceros o información se proveen solo
como una conveniencia a usted y no constituye o implica respaldo por parte de SERAM,
patrocinio o recomendación del tercero, la información, el producto o servicio. SERAM no
se hace responsable por el contenido de estas páginas y no hace ninguna representación
con respecto al contenido o exactitud del material en este archivo. De acuerdo con las
regulaciones de derechos de autor, cualquier uso no autorizado del material o partes
del mismo, así como la reproducción o la distribución múltiple con cualquier método
de reproducción/publicación tradicional o electrónico es estrictamente prohibido. Usted
acepta defender, indemnizar y mantener indemne SERAM de y contra cualquier y todo
reclamo, daños, costos y gastos, incluyendo honorarios de abogados, que surja de o
es relacionada con su uso de estas páginas. Tenga en cuenta: Los enlaces a películas,
presentaciones ppt y cualquier otros archivos multimedia no están disponibles en la
versión en PDF de las presentaciones.

Página 1 de 18
Objetivo docente

- Explicar cómo se produce la comunicación entre 2 dispositivos según la especificación


DICOM (Digital Imaging and Comunication in Medicine)

- Explicar los parámetros que son necesarios para establecer la conectividad entre dos
dispositivos DICOM

- Demostrar la importancia del conocimiento de la conectividad DICOM en el entorno


hospitalario.

Revisión del tema

Dispositivos DICOM. Diseño de una red DICOM

Múltiples dispositivos médicos (Fig.1) son compatibles con la especificación DICOM. La


unión entre estos dispositivos debe de realizarse configurando una red, más o menos
compleja en función del número y tipo de estos dispositivos. Entre estos dispositivos
cabe mencionar:

Página 2 de 18
Fig. 1: Ejemplos de dispositivos DICOM
Referencias: S. González Ortega; Radiodiagnóstico, H. U. La Princesa, Madrid,
SPAIN

1.- Todos los equipos actuales de generación de imágenes médicas, especialmente del
servicio de radiología (TACs, RM, Radiografía digital directa -DX- e indirecta -CR-, US...)
aunque en la actualidad múltiples dispositivos de otros campos de la medicina disponen
de dicha especificación (EKG, endoscopia, etc...)

2.- El PACS como elemento que guarda todas las imágenes en una base de datos y
las distribuye por la red. Este es el punto de encuentro de la mayoría de los dispositivos
DICOM y representa el elemento más importante de la red. Puede estar configurado
como uno o varios nodos, dependiendo de la configuración realizada por la casa
comercial y la complejidad del sistema. El RIS también forma parte de la red (p.ej. para
el servicio Modality Worklist)

3.- Impresoras DICOM para imprimir en diferentes formatos las imágenes.

4.- Digitalizadores de imágenes.

5.- Estaciones de trabajo y software específico (p.ej Osirix), programas CAD, etc...

El diseño de la red DICOM debe de estar coordinado por los diferentes servicios del
hospital, siendo de vital importancia el servicio de Radiología, al ser en este servicio
donde más equipos DICOM existen.

Se pueden representar las redes mediante diagramas como el ejemplo de la Fig 2.

Página 3 de 18
Fig. 2: Diagrama de red DICOM típica.
Referencias: S. González Ortega; Radiodiagnóstico, H. U. La Princesa, Madrid,
SPAIN

Formación de nodos en una red DICOM. Tabla de conectividad

Cada elemento de la red se denomina nodo.

Cada nodo de esta red debe de tener definidos con qué otros nodos puede comunicarse.
Esto se configura mediante una tabla de conectividad. Esta tabla contiene los datos de
los otros nodos con los que puede conectarse y su mantenimiento debe de ser continuo,
p.ej. cada vez que se introduce un nuevo dispositivo en PACS, hay que cambiar dicha
tabla para aceptarlo.

Página 4 de 18
Fig. 3: Ejemplo de tabla de conectividad DICOM. Programa Osirix.
Referencias: S. González Ortega; Radiodiagnóstico, H. U. La Princesa, Madrid,
SPAIN

Parámetros que definen un nodo DICOM.

Cada nodo DICOM se define por 3 parámetros que deben de ser utilizados en la tabla
de conectividad.

a) Título de Aplicación. (AE_TITLE). Es el nombre que define al nodo mediante formato


alfanumérico.

b) Dirección IP (Internet Protocol) que dicho nodo utiliza dentro de la red. Al ser DICOM
un protocolo necesariamente basado en el estándar IP, lo que la hace compatible tanto
con Intranet en red de área local (LAN) como en Internet. En general este parámetro
es fijo, es decir, las redes DICOM deben de estar configurados con IP estáticas. Esto
debe de ser tenido en cuenta a la hora de introducir cualquier elemento en la red. P.ej.
si se introduce un ordenador Mac con software Osirix, es necesario configurarlo con IP
estática y ello debe de ser comunicado al servicio de informática antes de ponerlo en red.

c) Puerto de comunicaciones. Puede ser cualquiera. El más utilizado es el 104 reservado


por la entidad IANA (Internet Assigned Numbers Authority). No debe interferir con otros
servicios.

Página 5 de 18
Sesión DICOM. Asociación DICOM

El protocolo DICOM está basado en redes cliente-servidor. Cada vez que se produce un
intercambio de información DICOM entre 2 nodos uno de ellos actúa como servidor o
SCP (service class provider) y otro como usuario o SCU (service class user).

El usuario (SCU) inicia una sesión mediante la petición de comunicación con el servidor
(SCP).

Fig. 4: Modelo cliente servidor


Referencias: http://administracionderedesequipo1.blogspot.com.es/2011/04/modelo-
cliente-servidor.html

Se inicia un "diálogo informático" o proceso de negociación que incluye entre otras


cosas:

1. Comprobación por parte del servidor (SCP) que el usuario se encuentra en


su tabla de conectividad. Esto se produce de forma genérica aunque ciertos
servidores aceptan el "modo promiscuo", es decir, no miran en la tabla de
conectividad y aceptan cualquier petición válida.

Página 6 de 18
2. Presentación del contexto (Presentation context) que define cómo trabaja el
dispositivo en la parte no negociable (Abstract Syntax) y la parte negociable
(Transfer Syntax). Los 2 dispositivos deben de estar de acuerdo en esta
sintáxis (Abstract+Transfer) que viene a ser algo así como el lenguaje que
van a utilizar los dispositivos para la sesión.

El resultado de esta negociación puede ser

1- Asociación denegada: puede generar un mensaje que puede ser diferente según
el fabricante y software. Muchos sistemas son poco "amigables" con escasez de
información de la razón de la denegación del servicio.

2.- Asociación aceptada. Se realiza el proceso entre el SCP y el SCU. Una vez terminada
la sesión ésta finaliza con un mensaje de fin de asociación como confirmación de sesión
realizada.

Página 7 de 18
Fig. 5: Negociación aceptada
Referencias: Internet

Como ejemplo, y realizado en un lenguaje "traducido" al lenguaje coloquial el siguiente


ejemplo demuestra la secuencia que se produce cuando un equipo como la Resonancia
requiere del servidor de almacenamiento:

Página 8 de 18
Fig. 6: Primera parte del proceso de negociación.
Referencias: O.S. Pianykh. DICOM: A practical introduction and Survival Guide.
Springer 2008

Fig. 7: Segunda fase del proceso: inicio de la asociación.


Referencias: O.S. Pianykh. DICOM: A practical introduction and Survival Guide.
Springer 2008

Página 9 de 18
Fig. 8: Tercera parte del proceso: terminación de la asociación.
Referencias: O.S. Pianykh. DICOM: A practical introduction and Survival Guide.
Springer 2008

Es habitual que los dispositivos dispongan de métodos de grabación de sesiones


(ficheros log o similares), de forma que los técnicos puedan averiguar los mensajes de
asociaciones denegadas y aceptadas, y poder actuar sobre diferentes problemas del
dispositivo.

Fig. 9: Ejemplo de fichero log del programa Osirix


Referencias: S. González Ortega; Radiodiagnóstico, H. U. La Princesa, Madrid,
SPAIN

"Conformance Statement". Definición e importancia.

El "Conformance Statement" es un documento no obligatorio aunque sí recomendado,


que debe de tener cualquier dispositivo DICOM. Suelen ser de acceso libre en Internet
y hace referencia a nivel técnico de cómo se adapta al DICOM estándar.

Página 10 de 18
Es un documento estructurado según las directrices publicadas en el libro 2 de dicho
estándar, que demuestra un ejemplo genérico.

En concreto según este documento se puede saber qué objetos DICOM utiliza un
dispositivo, p.ej. si es capaz de manejar las imágenes PET o no, y qué funciones tiene,
es decir, aquello en lo que puede actuar como servidor (SCP) y como cliente (SCU).

En general es un documento bastante técnico, de utilidad fundamentalmente para los


ingenieros-técnicos de las máquinas y debe de formar parte de la documentación del
dispositivo, además del manual de uso, propio del dispositivo.

El otro documento que además debe de incluirse es el IHE Integration Statement.


Este segundo documento se refiere a cómo el dispositivo actúa dentro de una red con
respecto a otros dispositivos, a nivel de integración. No se refiere a las capacidades de
SCP y SCU dentro de DICOM sino más bien a los perfiles a los que se adapta dentro de
la IHE y qué papel o rol cumple dentro de este perfil.

A diferencia de DICOM, IHE ofrece un certificado de integración y publica sus resultados


en Internet.

Papel del radiólogo en el entorno de la conectividad DICOM.

Desde el Servicio de Radiología hay que tener una actitud activa en el diseño de
la red. Es habitual que muchas redes estén diseñadas por las casas comerciales,
que habitualmente sólo ponen en servicio aquellos servicios mínimos y considerados
obligatorios. Esta pasividad puede llevar a perder funcionalidades. Ejemplos de esto
puede ser la introducción en un servicio de radiología de ordenadores Mac con
software Osirix, otro tipo de software OpenSource, etc... Además en el propio diseño
de un Servicio de Radiología todo el "workflow" debe de ser dirigido desde el propio
servicio. Entre estas funcionalidades p.ej. se encuentra la posibilidad de hacer copias de
seguridad, el envío desde ciertas modalidades hacia ciertas estaciones de trabajo, etc...

La posibilidad de poder manejar la tabla de conectividad es variable. En el software "open


source" está libre. En el software comercial es muy habitual la "mala" costumbre de
impedir que el usuario, que por otro lado es dueño de lo que ha comprado, pueda realizar
dicho proceso. Además es habitual que dichas casas comerciales devengan honorarios,
la mayoría de las veces no justificados, por hacer dichos cambios. Deberíamos de
luchar desde nuestras modestas opciones para que las casas comerciales liberen la
posibilidad de manejar a nuestro antojo la tabla de conectividad de todos los dispositivos

Página 11 de 18
que dependen de nosotros. Además es un proceso muy fácil, que no requiere ni
siquiera unos segundos. La posibilidad de que investiguemos con dicho proceso es
nuestra responsabilidad, que las casas comerciales no deberían en ninguno de los casos
cercenar.

Dado lo importante del Servicio de Radiología en la red DICOM de un hospital, lo habitual


es que el Administrador del PACS sea un radiólogo, o al menos un radiólogo haga de
puente en dicho proceso. No debería darse nunca el caso de que en PACS exista un
nodo "desconocido", así como en el resto de la red DICOM

Por otro lado DICOM es un proyecto abierto, no es sólo de la radiología, sino de


la medicina como las propias siglas indican. Debemos de estar abiertos a introducir
cualquier elemento DICOM que cumpla una función, para así potenciar todas las
posibilidades que dicho estándar puede producir por nosotros. P.ej. se debe de fomentar
que en PACS figuren modalidades no radiológicas como la cardiología, la endoscopia,
etc...

Images for this section:

Fig. 1: Ejemplos de dispositivos DICOM

Página 12 de 18
Fig. 2: Diagrama de red DICOM típica.

Fig. 3: Ejemplo de tabla de conectividad DICOM. Programa Osirix.

Página 13 de 18
Fig. 4: Modelo cliente servidor

Página 14 de 18
Fig. 5: Negociación aceptada

Página 15 de 18
Fig. 6: Primera parte del proceso de negociación.

Fig. 7: Segunda fase del proceso: inicio de la asociación.

Fig. 8: Tercera parte del proceso: terminación de la asociación.

Página 16 de 18
Fig. 9: Ejemplo de fichero log del programa Osirix

Página 17 de 18
Conclusiones

1. Para poder realizar una sesión DICOM entre 2 dispositivos, éstos deben
previamente ser declarados (tabla de conectividad) y estar conformes
(conformance statement).
2. Desde el Servicio de Radiología debe de existir una participación en el
planteamiento de cualquier red DICOM, aunque éste es un proyecto abierto
de la medicina.
3. El radiólogo debe de conocer lo básico de la conectividad DICOM para
poder participar en el proceso de gestión de la red DICOM.

Bibliografía:

DICOM - A Practical Introduction and Survival Guide.Oleg S. Pianykh. Springer 2008

PACS - A Guide to de Digital Revolution. Keith J. Dreyer, David S. Hirschorn, James J


Thrall, Amith Metha. Springer 2006

Página oficial NEMA

Página 18 de 18

You might also like