Conectividad DICOM: lo que el radiólogo debe saber

Transcripción

1 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: /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

2 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

3 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

4 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

5 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

6 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: 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

7 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

8 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

9 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

10 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

11 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

12 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

13 Fig. 2: Diagrama de red DICOM típica. Fig. 3: Ejemplo de tabla de conectividad DICOM. Programa Osirix. Página 13 de 18

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

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

16 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

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

18 Conclusiones Para poder realizar una sesión DICOM entre 2 dispositivos, éstos deben previamente ser declarados (tabla de conectividad) y estar conformes (conformance statement). 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. 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