DISEÑO Y DESARROLLO DE UN PACS USANDO UNA LÍBRERIA DE LECTURA Y ESCRITURA DEL FORMATO DICOM FABIO MARTÍNEZ CARRILLO

Transcripción

1 DISEÑO Y DESARROLLO DE UN PACS USANDO UNA LÍBRERIA DE LECTURA Y ESCRITURA DEL FORMATO DICOM FABIO MARTÍNEZ CARRILLO Trabajo de Grado realizado en el Centro de Telemedicina de la Universidad Nacional de Colombia, Facultad de Medicina UNIVERSIDAD DE PAMPLONA FACULTAD DE INGENIERÍAS Y ARQUITECTURA PROGRAMA DE INGENIERÍA MECATRÓNICA PAMPLONA 2006

2 DISEÑO Y DESARROLLO DE UN PACS USANDO UNA LÍBRERIA DE LECTURA Y ESCRITURA DEL FORMATO DICOM FABIO MARTÍNEZ CARRILLO Trabajo de Grado realizado en el Centro de Telemedicina de la Universidad Nacional de Colombia, Facultad de Medicina DIRECTOR: EDUARDO ROMERO CASTRO Ph.D. TUTOR ACADÉMICO: DIEGO JUGO GONZÁLEZ Ph.D. UNIVERSIDAD DE PAMPLONA FACULTAD DE INGENIERÍAS Y ARQUITECTURA PROGRAMA DE INGENIERÍA MECATRÓNICA PAMPLONA 2006

3 Nota de aceptación: Firma del presidente del jurado Firma del jurado Firma del jurado Pamplona, 22 de Mayo 2006

4 Dedico este trabajo a mi PAPÁ (Q.E.P.D) OVIDIO MARTÍNEZ, por ser el motivo de inspiración para desarrollar este proyecto. A mi mamá ISBELIA CARRILLO y mi hermana YUDY MARTÍNEZ, por ser el apoyo y la base fundamental en mi vida; y a mi tío CÁNDIDO ARENALES, quien con su bondad hizo posible que se culminara este sueño. i

5 AGRADECIMIENTOS A DIOS quien me dió la fé, fortaleza, salud y esperanza para terminar este trabajo (decidí dejarlo a pesar de que el profesor Romero piensa que la ciencia y la religión no se mezclan). De manera muy especial al profesor Eduardo Romero por la confianza, apoyo, dedicación y enseñanza que me brindó durante la permanecia de mi pasantía en el Centro de Telemedicina. A mis asesores y amigos en este proyecto Andrea del Pilar Rueda y Juan Carlos Caicedo, por brindarme un apoyo incondicional para la culminación de este trabajo. A mis compañeros y amigos del Centro de Telemedicina, en especial a Javier Rojas, Carlos López, Carlos Vargas, Adriana Maldonado, Gustavo Páramo, Byron Pérez, Gloria Díaz y Francisco Jaramillo, por brindame enseñanza, y ser guías en los trabajos realizados en el Centro de Telemedicina. A mis compañeros y amigos de pregado, en especial a Ingrid Yaneth Angarita, Ireli Patricia Vargas, Leonardo Mejía, Laureano Martínez y Eliécer Ayala por compartir momentos inolvidables en nuestras vidas, y a quienes le guardo gran aprecio. A Yina Paola Uribe por ser mi apoyo y refugio en los momentos difíciles de mi vida, por apoyarme y hacer de mí una mejor persona. A mis familiares y amigos quienes siempre me acompañaron a lo largo de mi carrera universitaria y me brindaron su apoyo y voto de confianza. A la Universidad de Pamplona y sus directivos por brindar una fuente de conocimiento para forjarnos cada día como profesionales de bien. A todas aquellas personas que estuvieron presentes en cada momento y no dudaron en brindarme su apoyo y comprensión. ii

6 Resumen El objetivo de este trabajo de fin de carrera es el de diseñar, implementar y evaluar un sistema mini-pacs (Picture Archiving and Communication System). Estos sistemas se usan corrientemente en los hospitales modernos y su función es optimizar el trabajo de una unidad de imágenes diagnósticas. Estos sistemas, que forman parte integral del sistema de información hospitalaria, intervienen desde la captura de las imágenes, organizan la información y la almacenan de forma eficiente. El médico puede entonces realizar las consultas desde cualquier terminal y el sistema asegura la confiabilidad en la transmisión y en el despliegue de los datos. La implementación realizada en este trabajo se hizo con base en la libreria de código abierto PixelMed que se complementó con una interfase general de usuario (GUI) desarrollada en Java. La evaluación de nuestra aplicación mostró eficiencia, robustez y confiabilidad en el sistema. Nuestro sistema es capaz de recibir hasta 500 consultas simultáneas con un retardo de 1 segundo. iii

7 Abstract The main goal of this work was aimed at devising, designing, implementing and to evaluating a mini-pacs system (Picture Archiving and Communication System). These systems are currently used in modern hospitals and their function is to optimize daily routines in a clinic imaging unit. These systems, which are an integral part of an information hospital system, pick the medical information after it is captured. The system is then charge of organizing it and archiving it in an efficient manner. Doctors can thus consult medical imaging information from any terminal at the hospital and the system ensures reliability in data transmission and display. Implementation herein built was based on the open source library PixelMed, which was complemented by a General User Interfase (GUI) developed in Java. Evaluation showed our system was efficient, robust and reliable. Our system is able to receive up to 500 simultaneous queries with a one second delay. iv

8 Índice general Resumen Abstract iii iv Introducción 1 1. Estándar DICOM Historia Formato de los Archivos DICOM Estructura DICOMDIR Estructura del estándar DICOM PACS (Picture Archiving and Communication Systems) Arquitectura Modelo de comunicaciones Servidores Estaciones de Trabajo Estaciones para la adquisición de imágenes Sistema de interconexión Diseño de un PACS Diseño del software para el SERVIDOR Diseño de la aplicación Diagrama de flujo de la aplicación del servidor Estación de trabajo Características físicas Diseño de las estaciones de trabajo Diagrama de flujo de la aplicación de la estación de trabajo Sistema de conexión v

9 Características físicas Implementación del PACS Evaluación de las diferentes herramientas para la manipulación del PACS Biblioteca ITK Biblioteca VTK Biblioteca JDT Biblioteca DCMTK Toolkit PIXELMED Implementación de la Estación de Trabajo Funcionamiento general de la estación de trabajo Implementación del servidor Funcionamiento general del SERVIDOR Pruebas de Ejecución Soporte de Formatos DICOM Desempeño del Módulo de Comunicaciones Conclusiones y Perspectivas 62 vi

10 Índice de figuras 1.1. Ejemplo de imágenes en formato DICOM Estructura de un archivo DICOM Estructura de los ARCHIVOS DICOM Proceso de construcción de una red de trabajo de acuerdo a la conformación Proceso de construcción para la comunicación de acuerdo a la conformación Definición de los objetos de información de acuerdo a las entidades de información Ejemplo del el objeto de informacion compuesto en una imagén Registro de los elementos de datos de DICOM. Tomada de la parte 6 del estándar DICOM Esquema de un PACS Modelo de un proceso distribuído Ejemplo de una estación de diagnóstico Ejemplo de una estación de consulta Ejemplo de una estación para adquisición de imágenes Esquema del PACS implementado en el proyecto Esquema que representa el diseño de la aplicación del servidor Diagrama de flujo del algoritmo del servidor Diagrama de flujo del servidor opción A Diagrama de flujo del servidor opción B Esquema UML de la estación de trabajo Diagrama de flujo de una estación de trabajo Diagrama de flujo de una estación de trabajo opción A Diagrama de flujo de una estación de trabajo opción B Diagrama de flujo de una estación de trabajo opción C Logo ITK Logo VTK Logo JDT vii

11 4.4. Logo DCMTK Esquema UML de paquetes que conforman el visualizador Esquema UML de clases que conforman el visualizador Esquema UML de clases que conforman el visualizador Estación de trabajo Estación de trabajo Esquema UML de paquetes que conforman el servidor Esquema UML de paquetes que conforman el servidor viii

12 Introducción En la actualidad existen centros de salud que manejan el sistema tradicional de almacenamiento y visualización de imágenes, que consiste en imprimir placas capturadas utlizando máquinas médicas y archivarlas en un cuarto para consultarlas posteriormente ó entregarlas a los pacientes para que se hagan cargo de éstas. Manejar grandes volúmenes de información utlizando este método tradicional presenta numerosos inconvenientes como la lentitud en la consulta de los expedientes, pérdida de archivos, imágenes deficientes que limitan un buen diagnóstico y altos costos de impresión, entre otras. Con la aparición de las imágenes médicas digitales, surge una gran cantidad de formatos los cuales no eran compatibles entre sí. Con el fin de generalizar esta situación se formaliza el estándar DICOM, cuyo objetivo es el de reglamentar y dar un formato único para las imágenes. Los archivos DICOM presentan la característica de contener diferentes datos dentro del archivo de la imagen como el nombre del paciente, máquina de donde fue tomada la imagen, características y modo de envío de los archivos a través de la red. Este estándar también proporciona un protocolo de comunicaciones para la transmisión de archivos médicos que está apoyado por los protocolos TCP/IP, y ISO/OSI. Teniendo como base el estándar DICOM, se han diseñado nuevos sistemas de almacenamiento y comunicación de archivos médicos llamados PACS, estos permiten manejar grandes volúmenes de información médica en un hospital, además que proporcionan ventajas como la comunicación de archivos a través de la red a diferentes hospitales y centros de investigación para desarrollar un mejor diagnóstico, también proporcionan un modo de administración más confiable y seguro. Los PACS son una parte fundamental en los sistemas de información hospitalaria (HIS), los cuales se integran junto con los sistemas RIS, sistemas de información de radiología por medio de estándares médicos que son reglamentados por el HL7 (Health Level 7), para dar un soporte de información robusto en un hospital. 1

13 Capítulo 1 Estándar DICOM DICOM (Digital Imaging and Communications in Medicine) es el estándar industrial para la adquisición de imágenes médicas y comunicación desde diferentes equipos (diagnóstico, terapéuticos y entre sistemas de diferentes fabricantes) y la transferencia de imágenes digitales e información médica entre computadoras. Este estándar permite interconectar sistemas informáticos de diferentes fabricantes. En el estándar DICOM existe una transmisión segura, que permite que la información pueda transportarse por los diferentes departamentos de un hospital e incluso pueda ser enviada a diferentes hospitales y centros de investigación. El estándar DICOM también permite obtener las imágenes digitales de una máquina para su procesamiento y manipulación. Con las diferentes técnicas de procesamiento se busca conseguir un mejoramiento en las imágenes tomadas y corregir por medio del software algunos errores que introducen los sensores de las máquinas al capturar la imagen. Para ello se hace uso de diferentes librerías que permiten manejar y tratar la imagen. En la figura 1.1 se muestran algunas imágenes en formato DICOM 1.1. Historia Con la introducción de la Tomografía Computarizada(TC), aparece una poderosa herramienta para hacer diagnóstico. Además, con el crecimiento del uso de computadoras y sistemas de información en aplicaciones clínicas, la Escuela de Radiología Americana (ACR) 1 y la Asociación Nacional de Fabricantes de Dispositivos Eléctricos(NEMA) 2 establecieron un estándar para la transferencia de imágenes e información asociada entre los diferentes dispositivos. En ese entonces los dispositivos producían una variedad de formatos de imágenes digitales que por lo general eran incompatibles entre sí. 1 American College of Radiology 2 National Electrical Manufacturers Association 2

14 Figura 1.1: Ejemplo de imágenes en formato DICOM ACR-NEMA formaron un comité en 1983 para el desarrollo de un estándar que contara con las siguientes características: Promover la comunicación de imágenes digitales entre los diferentes fabricantes de dispositivos. Facilitar el desarrollo y expansión de archivos de imágenes y sistemas de comunicación (PACS), y de interfaces con otros sistemas de información en los hospitales. Permitir la creación de bases de datos con información de diagnóstico que se pueda llamar desde una variedad de dispositivos distribuídos geográficamente ACR-NEMA publicó el estándar No (versión 1.0.), el cual fue desarrollado con base en los formatos de imágenes médicas que existían hasta el momento. Después publicó el estándar No (versión 2.0.) que extiende la versión 1.0. Esta contiene el material para proporcionar el soporte de comandos para la visualización de los diferentes dispositivos. Además introduce el esquema de identificación de imágenes y adiciona datos para incrementar la especificación descrita de la imagen. Este estándar incluye las especificaciones para las interfaces de hardware, un mínimo conjunto de comandos de software, y un consistente conjunto de formatos de datos. El estándar DICOM nace en el año 1993, a partir de un rediseño completo de la publicación normalizada No de ACR-NEMA. 3

15 1.2. Formato de los Archivos DICOM El formato de archivos DICOM esta conformado por una cabecera que contiene los metadatos y la imagen, como se muestra en la figura 1.2. Los metadatos proporcionan la información de la imagen como por ejemplo su tamaño, dimensiones, modalidad, equipo de captura y la identificación correspondiente al paciente. Ésta es la mayor diferencia con los demás formatos populares, en los cuales hay una gran dificultad para asignar y administrar la información. En los archivos DICOM se comprimen los metadatos y la imagen, con lo cual se permite un menor tamaño y menor riesgo de pérdida de la información. A diferencia de la manera convencional (imágenes impresas en placas), los archivos DI- COM son de gran ventaja pues permiten tener un criterio más amplio en el estudio de casos, basándose en imágenes tomadas anteriormente al mismo paciente. También permite desplegar en la pantalla varias imágenes de diferentes estudios para ser observadas al mismo tiempo, esto permite un control más detallado y preciso. Además, las imágenes pueden ser manipuladas para facilitar su observación Estructura DICOMDIR DICOMDIR 3 define un grupo de archivos que están relacionados por medio de los atributos de los archivos. Esto facilita el acceso a la información de las imágenes contenidas dentro de éste. En este directorio se especifica un archivo DICOMDIR, que contiene la información del conjunto de imágenes y por medio del cual se puede acceder más fácilmente a los demás archivos DICOM, existentes en el DICOMDIR. En la figura 1.3 se ilustra la organización del formato DICOMDIR, y de los archivos contenidos. En esta figura se muestran archivos DICOM junto con su estructura básica: metadatos e imagen. Su versatilidad y adaptabilidad se comprenden más facilmente a través de un ejemplo: supongamos que los archivos mostrados tienen un tamaño cada uno de bytes, los cuales están distribuidos en dos partes: la cabecera (contiene los metadatos), y la imagen. En estos archivos la cabecera ocupa 794 bytes del tamaño total del archivo y la información está organizada en una estructura particular. La imágen ocupa los restantes bytes. El archivo DICOMDIR que se encuentra dentro del directorio DICOM contiene información común de localización relativa dentro del directorio de los archivos DICOM. Este permite organizar los archivos como un árbol permitiendo un rápido acceso a la información. 3 Directorios DICOM 4

16 Archivo DICOM Nombre Paciente: Rabbit Osman Tipo de Imagen: Original Parte Examinada: Heart Cabecera del Archivo DICOM donde se encuentran los metadatos del Archivo Nombre de la institución: UCLA Marca del equipo: Siemens Imagen DICOM Figura 1.2: Estructura de un archivo DICOM 5

17 DICOMDIR ARCHIVO DICOMDIR ARCHIVO DICOM_1 ARCHIVO DICOM_2 ARCHIVO DICOM_3 ARCHIVO DICOM_1 CABECERA ARCHIVO CABECERA ARCHIVO CABECERA ARCHIVO ARCHIVO DICOM_2 METADATOS METADATOS METADATOS ARCHIVO DICOM_3 IMAGEN IMAGEN IMAGEN Figura 1.3: Estructura de los ARCHIVOS DICOM 6

18 1.4. Estructura del estándar DICOM El estándar DICOM se organiza por temas que están organizados para definir una estructura de información y comunicaciones que trata de manera eficiente la información. Dentro del estándar, estos temas se denominan partes. Este modelo permite visualizar mejor el contenido y hace más fácil su interpretación. A continuación se presenta un breve resumen del contenido de cada parte. Parte 1: Introducción y Vista General En esta parte se da una definición del estándar DICOM. También se muestra en manera breve la manera en que están constituídas cada una de sus partes, la historia, y la manera en que ha evolucionado este estándar. Parte 2: Conformación En esta parte se define la forma en la que están conectadas y relacionadas las diferentes partes del estándar. En las figuras 1.4 y 1.5 se representa este proceso por medio del cual obtenemos una conformación robusta del estándar. La manera que tuvieron en cuenta para organizar y concatenar las partes del sistema fueron las siguientes: Sistema de objetos de información que son reconocidos en la puesta en práctica. Sistema de clases de servicios con soporte de implementación. Protocolos de comunicaciones o de medios físicos con soporte a la implementación. Parte 3: Definición del Objeto de Información En esta parte del estándar DICOM se definen los objetos de información y se establecen las funciones que ellos realizan. Éstos objetos son un grupo de información relacionada, la cual está organizada en entidades de información o atributos que proporcionan una definición abstracta de las entidades del mundo real aplicables a la comunicación de las imágenes médicas digitales. Estas entidades pueden ser el nombre del paciente, la imagen, el equipo de adquisición, etc. Cada definición de la clase del objeto de la información consiste en una descripción de su propósito y de las cualidades que la definen. Una clase de objetos de información no incluye los valores para las cualidades que abarcan su definición. La definición de los objetos de información se puede hacer en términos de una entidad única o de un grupo de entidades y se denominan objetos de información normalizados ó compuestos, respectivamente, como se muestra en la figura1.6. En la figura1.7 se muestra un ejemplo de la estructura de un objeto de información compuesto, con el cual están asociados múltiples entidades de información 7

19 Parte 16 CONFORMACION DEL ESTANDAR DICOM Funcion que muestra la escala de grises Parte 14 Recursos para la busqueda del contenido Parte 3 MODELO DE IMPLEMENTACION Diccionario de datos Parte 6 Parte 5 Estructura de Datos y Semantica Definición de los objetos de la información Parte 4 CLASES SOP TAREAS SINTAXIS DE TRANSFERENCIA Intercambio de Mensajes Parte 10 Especificaciones con las clases de servicio Parte 11 PILA DE COMUNICACION Perfiles de seguridad Parte 12 Soporte de comunicaciones de red MEDIDAS DE SEGURIDAD Figura 1.4: Proceso de construcción de una red de trabajo de acuerdo a la conformación 8

20 Parte 14 Funcion que muestra la escala de grises Parte 16 Recursos para la busqueda del contenido Parte 3 CONFORMACION DEL ESTANDAR DICOM MODELO DE IMPLEMENTACION Diccionario de datos Parte 6 Parte 5 Estructura de Datos y Semantica Definición de los objetos de la información Parte 4 PERFILES DE APLICACAION Perfiles en los medios de comunicación Parte 10 Parte 12 Especificaciones con las clases de servicio Parte 11 Formato de archivos e intercambio de datos CLASES SOP TAREAS SINTAXIS DE TRANSFERENCIA Parte 15 Formato de los medios, intecambio fisico,inercambio de datos PILA DE COMUNICACION Perfiles de seguridad MEDIDAS DE SEGURIDAD Figura 1.5: Proceso de construcción para la comunicación de acuerdo a la conformación 9

21 Objeto de información simple Definición de información simple Módulos de Objetos de información Módulos de Objetos de información Definición de los Objetos de información Módulos de Objetos de información Objeto de información compuesto Entidad de información Selección Entidad de información Entidad de información Figura 1.6: Definición de los objetos de información de acuerdo a las entidades de información Paciente Equipo Estudio Imagen Nombre Sexo Identificación Manufactura Referencia Identificación Numero de seleccion Numero Ancho de la ventana Fecha de Nacimiento Fecha de Realización Datos de pixel Figura 1.7: Ejemplo del el objeto de informacion compuesto en una imagén 10

22 Parte 4: Especificaciones de las clases de servicio La parte cuarta del estándar DICOM define las clases de servicio. Una clase de servicio asocia unos o más objetos de la información y una o más acciones que deben ser realizadas sobre éstos objetos. Las especificaciones de la clase de servicio indican los requisitos para los elementos que realizan las acciones sobre los objetos y cómo éstas acciones se aplican. En esta parte del estándar DICOM se definen las características compartidas por todas las clases de servicio, y cómo se estructura una declaración de la conformidad a una clase individual de servicio. Esta sección contiene un número de anexos normativos que describen las clases de servicio detalladamente. Los ejemplos de clases de servicio incluyen lo siguiente: Clase de Servicio de Almacenamiento Clase de Servicio de pregunta - respuesta Clases de Servicio básico para la dirección de listas de trabajo Clases de Servicio para la dirección de impresión Parte 5: Estructura de datos y codificación Esta parte define las reglas de codificación necesarias para construir una secuencia de datos que se transportará por la red por medio de un mensaje, según lo especificado por la parte 7 del estándar DICOM. También se define la semántica de un número de funciones genéricas que son comunes a muchos objetos de información. Esta parte define las reglas de codificación para los juegos de caracteres internacionales usados dentro de DICOM. En esta parte del estándar se especifica: a. Valores de codificación. b. Estructura uso del conjunto de datos que se transportan en la red. c. Uso y relaciones de otros elementos de datos. d. Construcción y uso de los datos de la imagen d. Cómo identificar la información Parte 6: Diccionario de datos En esta parte del estándar DICOM se define un registro central que tiene una colección de todos los elementos de datos DICOM disponibles para representar la información, junto 11

23 con los elementos utilizados para los medios que codifican y crean una lista de los artículos identificados de manera únca que son asignados por DICOM. Para cada elemento, la parte 6 especifica: Etiqueta única, que consiste en un grupo y un número del elemento. Nombre. Valor de representación (cadena de caracteres, número entero, etc.). Valor de multiplicidad (cuántos valores por cualidad). La manera como el estándar agrupa y tabula esos valores se muestra en la figura 1.8 que es una parte del registro de los elementos de datos de DICOM, tomada de la parte 6 del estándar Figura 1.8: Registro de los elementos de datos de DICOM. Tomada de la parte 6 del estándar DICOM 12

24 Para cada artículo identificado, la parte 6 especifica: Su valor único, que es numérico con los componentes múltiples separados por comas y limitados a 64 caracteres. Su nombre. Su tipo, clase del objeto de la información, definición de la codificación para la transferencia de datos, o cierto objeto bien conocido de la información. En qué parte del estándar DICOM se define. Parte 7: Intercambio de mensajes La parte 7 del estándar DICOM especifica los servicios y protocolos usados en ambientes médicos, para la proyección de imágenes y el intercambio de mensajes sobre los servicios de ayuda de comunicaciones definidos en la parte 8. Un mensaje se compone de un flujo de acciones definidas en la parte 7 seguido por una secuencia de datos opcionales, según lo definido en la parte 5. En esta parte se especifica: Las operaciones y las notificaciones (servicios DIMSE) que hacen posible mantener las clases definidas en la parte 4. Las reglas para establecer y para terminar asociaciones que proporcionan ayuda a las comunicaciones especificadas en la parte 8. Reglas que gobiernan el intercambio de peticiones y las respuestas a las diferentes acciones. Reglas de codificación necesarias para construir corrientes y mensajes. Parte 8: Soporte de la comunicación por Red para el intercambio de mensajes En esta parte se especifican los servicios de comunicación y los protocolos de capa superior, necesarios para apoyar un ambiente de red y la comunicación entre los usos de DICOM, según lo especificado en la parte 4, 5, 6, y 7. Estos servicios y protocolos aseguran que la comunicación entre los diferentes usos de DICOM se realice de una manera eficiente y coordinada a través de la red. Esta definición de servicio en la capa superior especifica el uso del protocolo de capa superior de DICOM utilizando los protocolos de transporte TCP/IP. El protocolo de comunicación TCP/IP mencionado en la parte 8 es el protocolo de fines generales que no se detalla en el estándar DICOM. 13

25 Parte 9: Soporte de la comunicación punto a punto para el intercambio de mensajes (retirado) Esta parte ha sido retirada del estándar DICOM. Éste especificaba la comunicación punto a punto que utilizaba el conector de 50 contactos tal y como lo definía ACR-NEMA. Ya no hay ninguna necesidad de consultar esta parte excepto por razones históricas, o si se da la circunstancia de encontrar un dispositivo antiguo de los años 80 que aún tenga este tipo de conexión. Parte 10: Medio de almacenamiento y formato de archivos para intercambio de datos En esta parte del estándar se especifica un modelo general para el almacenamiento de la información médica y la proyección de imagen en medios desprendibles. El propósito de esta parte es proporcionar una estructura general, permitiendo el intercambio de los varios tipos de imágenes médicas y de información relacionada en una amplia gama de medios de almacenamiento físico. Esta parte define algunos conceptos de almacenamiento de medios: 1. Método para identificar un sistema de archivos en un solo medio 2. Método para nombrar un archivo de DICOM dentro de un sistema de ficheros específico Parte 11: Perfiles de aplicación para medios de almacenamiento Esta parte del estándar determina los subconjuntos específicos de uso del estándar DICOM al cual la puesta en práctica puede exigir conformidad. Estos subconjuntos específicos de uso serán referidos como perfiles de uso en esta sección. Tal declaración de la conformidad se aplica al intercambio operable de imágenes médicas y de la información relacionada sobre los medios de almacenamiento para las aplicaciones clínicas específicas. Éste se guía por la estructura general que ha sido definida en la parte 10 para el intercambio de varios tipos de información sobre medios de almacenamiento. La estructura DICOM y el diseño del mecanismo del perfil hace que se realice un intercambio directo entre la extensión del objeto de la información, las clases adicionales y los nuevos medios. Parte 12: Formatos y medios físicos para el intercambio de datos En esta parte se facilita el intercambio de la información en los ambientes médicos especificando: 14

26 1. Una estructura para describir la relación entre el modelo del almacenamiento de los medios, los medios físicos específicos y los medios del formato 2. Características físicas específicas de los medios y formatos asociados. Parte 13: Soporte de comunicación punto a punto para gestión de la impresión (retirado) Esta parte se ha retirado del estándar. Especificaba los servicios y los protocolos usados para señalar la comunicación punto a punto de los servicios de la administración de impresión de las imágenes médicas. Parte 14: Éstandar para la función en escala de grises En esta parte se especifica una función estandarizada de la exhibición constante de las imágenes en escala de grises. Esta función proporciona los métodos para calibrar un sistema de visualización particular con el fin de presentar imágenes constantemente en diversos medios de exhibición (por ejemplo, monitores e impresoras). La función de exhibición elegida se basa en la opinión visual humana. La sensibilidad humana del contraste del ojo no es lineal dentro de la gama de luminancia de los dispositivos de exhibición. Este estándar utiliza el modelo de Barten [4] del sistema visual humano. Parte 15: Perfiles de seguridad En esta parte se especifica los perfiles para la administración de seguridad y los sistemas que lo puedan conformar. Los perfiles de administración para la seguridad del sistema son definidos refiriéndose a los protocolos estándares desarrollados, tales como DHCP, LDAP, SSL, TLS e ISCL. Los protocolos de seguridad pueden utilizar técnicas de seguridad como llaves públicas y tarjetas elegantes. El cifrado de datos puede utilizar varios esquemas estandarizados de cifrado de datos. Esta parte no trata de aplicaciones en cuanto a las políticas de seguridad. El estándar proporciona solamente los mecanismos que se pueden utilizar para poner políticas de seguridad en ejecución con respecto al intercambio de los objetos DICOM. Es responsabilidad del administrador local establecer políticas apropiadas de seguridad. Parte 16: Recurso para la búsqueda del contenido Esta parte del estándar DICOM especifica: Las plantillas para la estructura de documentos de los objetos de información DICOM. Los sistemas de términos cifrados para el uso de objetos de información. 15

27 Un léxico de términos que está mantenido y definido por DICOM. Traducciones específicas de términos cifrados para cada país Parte 17: Expansión de la información En esta parte del estándar DICOM se especifican algunos anexos que contienen diferente información y normativos para dar una mayor expansión a la documentación del estándar. Parte 18: Acceso a la Web por objetos persistentes de DICOM Esta parte del estándar DICOM especifica los medios por el que se hace una solicitud a los objetos persistentes de DICOM, se puede expresar como una petición HTTP que incluya un identificador de un objeto persistente específico de DICOM. La petición también especifica el formato del resultado que se devolverá en respuesta a la petición. Los parámetros de consultas URL según lo define el estándar es suficiente para un servidor HTTP, para actuar a la medida de la clase SCU (Clase de Servicio del Usuario) solicita un objeto apropiado SCP (Clase de Servicio del Proveedor). 16

28 Capítulo 2 PACS (Picture Archiving and Communication Systems) Un Sistema de Comunicación y Archivo de Imágenes o PACS (por sus siglas en inglés) es un sistema que almacena, imprime y transfiere imágenes de diferentes equipos médicos (Tomógrafos, resonancias, rayos X, ultrasonidos, etc.) e informes de procedimientos de diagnóstico. También permite la manipulación digital de imágenes, garantizando la calidad de acceso para una mayor efectividad a la hora de hacer diagnóstico. Por medio de esta red de comunicación estos archivos se transmiten hacia los servidores que son los que distribuyen los archivos a estaciones de trabajo donde le permite a los médicos efectuar una revisión. Los PACS se han convertido en una parte esencial en los departamentos de imaginología de un Hospital. entre las ventajas con respecto a la manera tradicional de adquisición y administración de archivos médicos se cuentan: Control de acceso a los archivos médicos, con lo cual un buen número de especialistas pueda evaluar las imágenes con determinadas restricciones sobre éstas. Almacenamiento en una extensa base de datos que permite una mejor administración de los archivos. Asímismo, el procedimiento resulta más económico por el ahorro en las placas de impresión que eran necesarias para visualizar las imágenes Arquitectura La arquitectura de un PACS consiste en un servidor central que contiene una base de datos de imágenes. Este servidor está conectado a uno o más clientes vía LAN o WAN para proporcionar y/o utilizar imágenes. Los clientes de las estaciones de trabajo pueden usar periféricos locales para explorar las imágenes dentro del sistema. En la figura 2.1 se presenta 17

29 el esquema general de un PACS, el cual está estructurado de acuerdo a su función en los siguientes componentes: Visualización Este componente del PACS tiene un grupo de equipos, que presentan la información al usuario. De acuerdo a la información que manejan los equipos, éstos se pueden dividir en: a. Visualización de imágenes. Esta parte cuenta con equipos especializados de visualización de imágenes, que cumplen características específicas para mejorar su evaluación, y facilitar un mejor diagnóstico. Los equipos de visualización son de alta resolución, deben contar con software especializado para el tratamiento y manipulación de las imágenes, y dar un espacio para poder guardar las evaluaciones y análisis dados por los médicos. El PACS, a su vez, debe ser capaz de transmitir con facilidad las imágenes a múltiples monitores para su manejo y control b. Administración. Este módulo comprende los computadores con software especializado para el control y administración de los diferentes departamentos que hacen uso del PACS. Adquisición El módulo de adquisición esta compuesto de un dispositivo fisico que realiza la adquisición y un computador que maneja todo el proceso. Este componente tiene interconectados los diferentes equipos de adquisición de imágenes con el servidor. Almacenamiento Este módulo integra los componentes tanto de software como de hardware, que permiten archivar los archivos DICOM. Para ello tienen una buena capacidad de almacenamiento y buen desempeño para administración de archivos DICOM. Infraestructura de interconexión Este componente conecta las partes mencionadas anteriormente proporcionando una eficaz comunicación entre ellas Modelo de comunicaciones Para la comunicación en red, el estándar DICOM, por medio de su arquitectura de capas permite la interconexión de computadores con diferentes sistemas operativos, utilizando protocolos de comunicación. Cada capa cumple con una función específica que permite manejar tareas como la comunicación entre máquinas-máquinas y máquinas-computadores. Para iniciar una comunicación, los diferentes dispositivos deben utilizar el mismo protocolo en cada 18

30 kldjfkfkfkoghk kfkfkfgkg363 flglgpgp... Adquisición Almacenamiento Sistema de interconexión Visualización Figura 2.1: Esquema de un PACS 19

31 capa, y garantizar que su relación con los demás equipos sea válida. DICOM utiliza para la comunicación en red los protocolos TCP/IP (Transmisión Control Protocol/Internet Protocol) y los propuestos por ISO/OSI (Internacional Standard Organización/Open Systems Interconnection), permitiendo al PACS utilizarlos en las capas inferiores de manera transparente, y en las capas superiores definir sus propios protocolos para realizar el transporte de archivos DICOM de forma eficiente. La estructura de DICOM para las comunicaciones funciona como un proceso distribuído. Un sistema distribuído está formado por dos o más procesos que comparten información. Un conjunto de procesos distribuídos actuando juntos proporcionan servicios para diferentes entornos. Antes de que las partes inicien la comunicación y transmisión de archivos, se deben definir y establecer unas reglas para cada componente de la comunicación. Éstos tienen que estar de acuerdo en el papel (rol) que cada uno desempeñará, tener una visión de la información que se manejará y seleccionar las operaciones que cada parte realizará. En la arquitectura cliente-servidor de DICOM, el papel de cada parte debe ser definido como cliente o como servidor, las cuales se describirán más adelante en más detalle. La relación define qué parte y bajo qué condición toma la iniciativa el proceso. En muchos casos los clientes inician el proceso, pero a veces lo hace el servidor. Tanto el cliente como el servidor tienen que ser capaces de emitir peticiones a los servicios de menor nivel. Los servicios de menor nivel tienen como función llevar el intercambio entre las partes y están ocultos para el dominio de la aplicación del cliente o del servidor. La parte que solicita los servicios es el usuario del servicio (service user). La contraparte corresponde al proveedor del servicio (service provider). Ambas partes pueden tener distintas implementaciones, pero comparten el mismo conocimiento sobre cómo se intercambian los datos (protocolo) y tienen la misma interfaz lógica (formato de petición) entre sí. Ambas partes deben determinar cómo viene representada la información en el formato de bit/byte. El servidor es el que determina en qué formato se transfiere la información y la convierte a la representación esperada por el dominio de la aplicación. Después del intercambio, la información presentada a los procesos que la utilizan es igual en ambas partes, independientemente de cómo fuera intercambiada. El intercambio físico entre los proveedores del servicio se realiza vía red. Cada mecanismo tiene su propia forma de manejar el conocimiento de la representación. La figura 2.2 presenta el esquema general de un proceso distribuído con los conceptos evaluados anteriormente. Teniendo en cuenta que el estándar DICOM tiene la limitación de que en el proceso de compartir archivos, el servidor sólo puede recibir la petición de un cliente a la vez, se hace uso de diferentes protocolos de comunicación, que unidos con el estándar DICOM logran aliviar esta limitación. En el caso de ISO/OSI, DICOM utiliza los servicios de las primeras 6 capas, además de los elementos de servicio OSI para la manipulación de asociaciones (ACSE).Para el caso TCP/IP, especifica un protocolo de capa superior DUL (DUL: DICOM Upper Layer). DICOM especifica 20

32 PROCESO DISTRIBUIDO CLIENTE RELACION SERVIDOR Servicio de usuario REPRESENTACION Servicio de usuario Proveedor de servicio FROMATO DE TRANSFERENCIA Proveedor de servicio INTERCAMBIO FISICO Figura 2.2: Modelo de un proceso distribuído 21

33 la forma de comunicación a través de asociaciones, estableciendo un ambiente cooperativo entre varias entidades en donde algunas juegan un papel de cliente, otras de servidor y otras de ambos, definiendo así un esquema Cliente/Servidor. Las normas que se deben seguir para cliente y servidor, se desarrollan con las especificaciones del servicio deseado, para el nivel de compatibilidad de uso. DICOM establece dos tipos de servicios básicos: Clase de Servicio de Usuario (Servicie Class User: SCU) que cumple con las funciones de cliente, y la Clase de Servicio de Proveedor (Servicie Class Provider: SCP) el cual cumple con las funciones de servidor. En ambos casos se definen las reglas que cada uno tendrá cuando se hace la asociación Servidores Una parte fundamental en un PACS son los servidores como sistemas de software y hardware, que presentan la característica de trabajar permanentemente esperando solicitudes de los clientes que están conectados a él. Estos sistemas por lo general son implementados en poderosos computadores con gran capacidad de almacenamiento, y con una alta capacidad de procesamiento, para poder atender las solicitudes y organizar la información que le llega. El servidor cumple con las funciones específicas dentro del PACS que se presentadan a continuación: Almacenar, clasificar y exportar los diferentes archivos DICOM. Establecer conexiones con las estaciones de trabajo. Permitir que los médicos accedan a una gran cantidad de datos médicos desde cualquier estación de trabajo para la consulta y evaluación de éstos. Para el diseño de los servidores hay que tener en cuenta ciertas características comunes que podrán ser implementadas de acuerdo a las necesidades del usuario. Entre las principales características que debe tener un servidor son: Software del Servidor establece el algoritmo de control y administración de los archivos DICOM. Aquí se define la manera de clasificar los archivos para que los clientes pueden localizarlos fácilmente, esto se puede hacer por medio de las características comunes de los archivos DICOM, como por ejemplo el ID del paciente. Hardware del Servidor En esta característica se evalúa la capacidad de los componentes físicos serán administrados por el software del servidor. Este análisis se efectúa de acuerdo a las propiedades del PACS, como por ejemplo la cantidad de imágenes que contendrá, los diferentes clientes que se conectarán a éste, la velocidad de transferencia que se requiere, y los servicios adicionales que se desean en el PACS. 22

34 Requerimientos de red Esta característica se establece de acuerdo a la aplicación final del PACS, en el cual se tendrá en cuenta si será de uso local o tendrá enlaces a servidores WEB, o estaciones de trabajo que estén ubicadas fuera del espacio físico donde se implementará el PACS. También en esta característica se tiene en cuenta la velocidad de transferencia de los diferentes archivos, y el diseño de la arquitectura de la red. Seguridad Se establece definiendo diferentes tipos de usuarios, los cuales tendrán jerarquía sobre la forma de consultar los archivos DICOM y su manipulación, esto con el fin de mantener ciertos datos anónimos del paciente y la administración de los archivos Estaciones de Trabajo Otra parte fundamental en los PACS son las estaciones de trabajo, por medio de las cuales los médicos interactúan directamente con los PACS, y pueden utilizar las múltiples ventajas de las estaciones para hacer un trabajo más productivo. Las estaciones de trabajo de acuerdo a la función que realizan dentro del PACS se pueden dividir en tres tipos, que son descritos a continuación. Estaciones de diagnóstico Las estaciones de diagnóstico están conformadas por equipos especializados en los cuales está instalado un software que permite ver de una manera clara las imágenes DICOM junto con los datos asociados a ésta. Estas estaciones de diagnóstico fueron desarrolladas con el fin de reemplazar las consolas de los equipos de adquisición de imágenes, que no permitían hacer una evaluación de la imagen. Por medio de las estaciones de trabajo se cuentan con diferentes herramientas que permiten la manipulación y tratamiento de la imagen. De acuerdo con las necesidades y el campo de operación de las estaciones de diagnóstico, se pueden desarrollar estaciones con un grado de complejidad mayor, que permitan reconstruir imágenes en 3D a partir de un grupo de imágenes de cortes axiales. También en estas estaciones de trabajo los médicos pueden elaborar su diagnóstico y adjuntarlo a la imagen como uno de los datos asociados del archivo DICOM. Algunas estaciones de diagnóstico vienen integradas con sistemas de impresión de las imágenes en placas. Las estaciones de diagnóstico también presentan una gran ventaja a la hora de evaluar la imagen, pues los médicos pueden relacionar ésta con diferentes imágenes que le hayan sido tomadas al paciente y reconstruir su historial. Estaciones de consulta Las estaciones de consulta incluyen software que ha sido instalado para la administración de horarios, equipos, etc. Estas estaciones ayudan de una manera apropiada a distribuir las citas en un hospital, y asignar los diferentes equipos y médicos. Estas estaciones por lo general 23

35 Figura 2.3: Ejemplo de una estación de diagnóstico están conectadas con los sistemas HIS (Sistema de Información de un Hospital), permitiendo también administrar los permisos en el PACS y dando la posibilidad de mantenerlo integrado con los otros sistemas del hospital Estaciones para la adquisición de imágenes Son estaciones que integran las diferentes máquinas de captura con el PACS por medio de computadores especializados en la adquisición de los archivos DICOM, mediante una interfaz para la transmisión. En algunos equipos médicos es necesario que los computadores contengan tarjetas de adquisición especiales, que permiten acomodarse a los requerimientos de transmisión de las máquinas. Las estaciones de adquisición de imágenes también son las encargadas de recopilar las imágenes que toman los diferentes equipos y transportarlos al servidor del PACS, recibiendo una respuesta del servidor después de la transmisión donde establezca que fue realizada con éxito o no, para tomar decisiones sobre la misma Sistema de interconexión Finalmente, este módulo Conecta las diferentes partes del PACS para su correcto funcionamiento; de acuerdo a las necesidades físicas de conexión entre las partes, se diseña la red apropiada para que soporte el transporte de los diferentes archivos DICOM. Aquí se define la necesidad de que el PACS tenga comunicación fuera del centro hospitalario, con otros centros 24

36 PACS paciente 1... paciente 2... id numero de cita Figura 2.4: Ejemplo de una estación de consulta Figura 2.5: Ejemplo de una estación para adquisición de imágenes 25

37 o con otras entidades como institutos de investigación. Algunas características en las redes de conexión de un PACS son: 1. LAN (RED DE AREA LOCAL) Ethernet 10Mbps Fast Ethernet 100Mbps Gigabit Ethernet 1Gbps 2. itemizewanred DE AREA AMPLIA DS-0 (56 Kbps) DS-1 (T1, Mbps) DS-3 (45 Mbps) ATM ( Mbps) Estas redes físicamente pueden ser implementadas por medio de cable blindado, fibra óptica, ADSL, red inalámbrica de alta velocidad u otras. 26

38 Capítulo 3 Diseño de un PACS En el diseño de un PACS se debe tener en cuenta ciertos requisitos que son necesarios para cumplir con las características generales de éste, como definir los componentes principales (servidor, cliente) y hacer que éstos cumplan con las funciones mínimas para poder obtener un sistema de visualización y transporte de archivos médicos. El diseño del PACS que se llevará a cabo en este proyecto pretende dar solución a la problemática de la visualización y transporte de archivos médicos en el Centro de Telemedicina de la Universidad Nacional que cuenta con una cantidad considerable de estos archivos. También se cuenta con diferentes equipos e infraestructura de red, los cuales serán utilizados para el soporte del PACS, tal como se muestra en la figura. Aunque en este proyecto se diseñará un modelo bajo la estructura física que existe actualmente en el Centro de Telemedicina, cabe aclarar que éste es un diseño facilmente adaptable, específicamente en los departamentos de imagenología hospitalarios, sin tener necesidad de realizar cambios mayores. En la figura 3.1, se muestran los diferentes dispositivos y la arquitectura de red sobre la que se diseñará el PACS. En esta figura se presenta una arquitectura dividida en partes de acuerdo a su funcionamiento. Firewall Un firewall es un dispositivo en el cual está implementado un software especializado de seguridad que permite proteger la red interna de la Universidad de accesos no autorizados que provengan de redes externas. En el caso especifico del PACS, el firewall permite mantener protegida la información alojada en el servidor para que no sea vista desde las redes externas a la Universidad. 27

39 INTERNET RED UNIVERSIDAD NACIONAL SERVIDOR (1) FIREWALL SWITCH ACCESS POINT ESTACIONES DE TRABAJO (2) ESTACIONES DE TRABAJO (4) Figura 3.1: Esquema del PACS implementado en el proyecto 28

40 Switch Son dispositivos que permiten la interconexión de diferentes redes, para el caso del PACS, existe un switch que permite la comunicación de los equipos del Centro de Telemedicina con la red general de la Universidad Nacional. También existe un switch que es el encargado de interconectar las estaciones del trabajo de escritorio con los demás dispositivos de la red general del PACS, garantizando principalmente la comunicación con el servidor. Access Point Este dispositivo cumple con funciones similares a las del switch, pero provee acceso a los equipos por medio de tecnología inalámbrica; en el PACS es el encargado de comunicar aquellas estaciones de trabajo que cuentan con tarjetas inalámbricas para la comunicación remota con el servidor, en el caso del Centro de Telemedicina las estaciones que cuentan con estas tarjetas son los equipos portátiles. Servidor Es un computador en el cual está instalada una aplicación que permite almacenar y administrar los diferentes archivos médicos al conjunto de equipos que los soliciten. En el Centro de Telemedicina existen computadores con gran capacidad de almacenamiento en las cuales se instalará el software del servidor para que administre los diferentes archivos médicos. Las características del servidor utilizado en el PACS son: 1. Servidor Sun Microsystems SunFire V20z, con 2. dos procesadores AMD Opteron de 64 bits, a 2.4 Ghz 3. 4GB de memoria RAM 4. Disco duro de 80 GB 5. Storage Sun Microsystems StorEdge 3511, que cuenta con 12 discos duros de 250 GB con velocidad de procesamiento de 7500 rpm para un total de 3.0 TB y transmite por un puerto dual a una velocidad serial ATA de 1.5 GB/s. Estaciones de trabajo Las estaciones de trabajo son computadores en los cuales se encuentra instalada una aplicación que permite visualizar la información contenida en los archivos médicos que pueden estar localizados en el disco local de la estación o en el servidor, por medio de las estaciones de trabajo se pueden evaluar los archivos para luego transferirlos al servidor para que sean almacenados. Dependiendo de las tarjetas de comunicación con las que cuenta cada estación de trabajo, éstas pueden estar conectadas al servidor por medio de un switch, o del access point Diseño del software para el SERVIDOR En el diseño del servidor para la construcción del PACS, se tendrán en cuenta los equipos con los que cuenta el Centro de Telemedicina, con la característica de poder almacenar una 29

41 gran cantidad de archivos, y cuya comunicación es eficiente con las demás entidades. Para la implementación de la aplicación se desarrollarán diferentes esquemas y diagramas que ayudan a entender el funcionamiento del servidor Diseño de la aplicación Para el diseño de la aplicación se ha desarrollado un diagrama de paquetes UML que se muestra en la figura, el cual permite por medio de la definición de módulos visualizar la estructura del servidor y cómo se desarrolla la aplicación de una manera lógica. A continuación se describen los diferentes módulos que conforman el diagrama de paquetes del servidor y la función que cada uno de estos desempeñan. MODULO DE RECUPERACION ALMACENAMIENTO FISICO MODULO DE ALMACENAMIENTO MODULO DE COMUNICACION RED Figura 3.2: Esquema que representa el diseño de la aplicación del servidor Módulo de comunicación Este módulo es el encargado de establecer la comunicación del servidor con la Red general del PACS. Por medio de este módulo se transmiten los archivos DICOM hacia las estaciones de trabajo para ser visualizadas, o en el caso contrario se pueden transmitir archivos desde las estaciones hacia el servidor donde se podrán almacenar y administrar. En el caso de este proyecto la dirección de prestación estará dada por el puerto 4006, pues es el más utilizado en la transmisión de archivos DICOM. También cabe aclarar que para la implementación en una infraestructura donde este puerto esté ocupado, se podrá utilizar un puerto diferente sin que esto cambie el diseño original del PACS. 30

42 En este módulo se da la característica de los paquetes IOD que son transportados a través de la red y como serán codificados para ser enviados a las estaciones de trabajo que han generado la comunicación. Módulo de recuperación Este módulo está encargado de interconectar los módulos de comunicaciones y almacenamiento. En este módulo verifica que la petición que viene a través de la red sea de una estación de trabajo, y la definición de contexto especificada en la comunicación para que ésta pueda ser procesada. Por medio del módulo de recuperación los archivos son transmitidos desde el servidor a la estación para su posterior visualización, así como también se da acceso para que los archivos DICOM provenientes de la estación puedan ser almacenados y administrados por el servidor. Por medio de este módulo se garantiza que las comunicaciones sean transparentes y que para cada petición que llegue al servidor se genere una respuesta determinada. Módulo de almacenamiento Este módulo es el encargado de administrar los diferentes archivos DICOM contenidos en el servidor. Por medio del módulo de recuperación son transportados los archivos DICOM provenientes de las estaciones de trabajo para el módulo de almacenamiento, y éste a su vez tiene la capacidad de administrar y almacenar estos archivos. Este módulo también es el encargado de buscar los diferentes archivos DICOM que sean solicitados por los usuarios y entregarlos al modulo de comunicación, o generar un mensaje en el caso de que el archivo no exista dentro del servidor Diagrama de flujo de la aplicación del servidor En la figura se muestra el diagrama de flujo utilizado para la elaboración del algoritmo que funcionará en el servidor del PACS. En primera instancia se tiene definido la dirección de prestación como el puerto 4006, el cual se verificará por medio de un ciclo indefinido hasta que se genere una solicitud de objetos SOP 1 por cualquier usuario. En el momento en que ocurre una petición desde las estaciones de trabajo, se entra a un nuevo ciclo en el cual se presenta un argumento que evalúa el formato de petición en el que viene dada la solicitud de clase SOP, en este caso si el formato de petición coincide con el contexto de servicio que se ha especificado por la comunicación se procede al siguiente paso, de manera contraria se genera un mensaje en el cual informa que el mensaje de petición no es válido. En el siguiente paso se evalúa si la petición que ha llegado hasta este punto desea obtener un IOD 2 del servidor o desea almacenarlo en el servidor. Para ello puede tomar la opción A ó la B como se muestra en la figura. 1 Service Object Provider 2 Information Object Definition 31

43 INICIO 1 Dirección de prestación ==4006 No Direccion de prestacion existe solicitud de objetos SOP? Mensaje: "El formato de peticion no es valido" SI No formato de petción == contexto de servicio? SI No Adquirir IOD del servidor SI A B Figura 3.3: Diagrama de flujo del algoritmo del servidor 32

44 Cuando el contexto de servicio viene definido para seguir la opción A se sigue el diagrama de flujo presentado en la figura en el cual la petición viene definida para almacenar un IOD en el servidor para que éste lo contenga y lo pueda administrar. Procede a almacenar estos IOD en el servidor y espera un mensaje que se indique que el IOD pudo ser almacenado o generó problemas en su almacenamiento y no se pudo hacer efectiva esta tarea. Después de que genera los mensajes retorna al inicio del algoritmo donde entra de nuevo al ciclo en espera de solicitud desde las estaciones. A almacenar IOD del l servidor No almacenamiento IOD fue correcto? Si Mensaje: "el IOD no se ha podido almacenar en ell servidor" Mensaje: "El IOD ha sido almacenado correctamente" 1 1 FIN Figura 3.4: Diagrama de flujo del servidor opción A 33

45 Si el contexto de servicio tiene definido una estructura en la cual se quiera adquirir un IOD que contenga el servidor para ser enviado a través de la red, se sigue el diagrama de flujo representado por la opción B y mostrado en la figura en el cual se encuentra un ciclo de búsqueda del archivo IOD solicitado dentro del servidor, para lo cual si lo encuentra lo envía a la estación de servicio que lo solicita, en caso contrario genera un mensaje en el que indica que el IOD solicitado no se encuentra en la base de datos del servidor. B No IOD solicitado existe en el servidor Si Mensaje: "el servidor no contiene el IOD solicitado" Transfiera IOD al cliente que la solicita 1 1 FIN Figura 3.5: Diagrama de flujo del servidor opción B 3.2. Estación de trabajo Las estaciones de trabajo contienen una aplicación que permite visualizar los diferentes archivos DICOM, así como también tienen la capacidad de enviar archivos al servidor. Para el diseño de esta aplicación se plantea un esquema de paquetes UML, y un diagrama de flujo muestra los pasos que sigue la aplicación, de acuerdo al evento que sea generado. 34

46 Características físicas En este PACS se consideran dos tipos de estaciones que se diferencian en su modo de comunicación con el servidor, a pesar de ello estas cumplen con las mismas funciones. La comunicación de cada estación de trabajo esta regida de acuerdo a la tarjeta de red que contenga cada equipo. Las estaciones presentan las siguientes características: Estaciones de trabajo con conexión al PACS por medio del switch 1. Procesador Pentium IV a 2.4 GHz MB de memoria RAM 3. Disco Duro de 40 GB Estaciones de trabajo con conexión al PACS por medio del Access Point 1. Procesador Pentium III mobile a 467 MHz MB de memoria RAM 3. Disco Duro de 20 GB Diseño de las estaciones de trabajo El diseño de la aplicación que se encuentra en las estaciones de trabajo puede ser representada por el esquema de paquetes UML mostrado en la figura, el cual contiene diferentes módulos de acuerdo a su función y están interconectados de una manera lógica, para cumplir con la funciones de visualizar archivos según lo especifique el usuario a través de la interfaz gráfica (GUI), ó para transmitir archivos al servidor para que éste los almacene. Módulo de visualización Este módulo es el encargado de transmitir las respuestas por medio de la interfaz gráfica de usuario (GUI) de las solicitudes o eventos generados por el usuario. Este módulo evalúa los eventos que se generan y los ubica en el paso que deben seguir. Módulo de consulta En este módulo se reciben las solicitudes que han sido procesadas por el modo de visualización y se evalúan que contengan el formato de contexto establecido en la comunicación. Si el formato de contexto no cumple las especificaciones con el contexto de servicio se generan mensajes de error, de caso contrario se evalúa para saber si éste desea adquirir una imagen desde el servidor, desde el disco local, ó desea enviar una imagen a través de la red al servidor. 35

47 COMUNICACION ALMACENAMIENTO {} {} CONSULTA VISUALIZACION interfaz gráfica de ususario Figura 3.6: Esquema UML de la estación de trabajo 36

48 Módulo de comunicación Se sigue al módulo de comunicación cuando la solicitud requiere mantener una comunicación con el servidor. Según lo definido en el contexto de servicio se decide en este módulo si la comunicación que se desea iniciar es para adquirir un archivo del servidor, o se hace para enviar un archivo. Este módulo también devuelve al módulo de consulta un resultado de acuerdo a la tarea que haya realizado, pueden ser mensajes que permiten verificar el estado del archivo que se transmitió, así como también puede contener el archivo que va a ser visualizado en la interfaz gráfica, o un mensaje en el que se especifica que el archivo no fue encontrado. Módulo de almacenamiento El módulo de almacenamiento se ejecuta cuando la solicitud que hace el usuario es adquirir una archivo del disco local para ser visualizado en la interfaz gráfica. En este módulo también se envía un mensaje que especifica que el archivo no existe en el disco local, ó se transfiere la imagen solicitada al módulo de visualización Diagrama de flujo de la aplicación de la estación de trabajo En la figura se muestra el diagrama de flujo del algoritmo que pertenece a la estación de trabajo, por medio de éste definimos los pasos lógicos que seguirá esta aplicación. Primero se tiene un ciclo indefinido hasta que ocurra un evento de comunicación por parte del usuario, cuando se genera este evento se pasa a comprobar si el formato de contexto de la solicitud que se produjo en el evento coincide con el formato de contexto establecido para la comunicación, de caso contrario se genera un mensaje en el cual se especifica que esta solicitud no coincide con el formato de contexto. Cuando se cumple con la condición del formato de contexto, se sigue con un ciclo de condición en el cual se evalúa el contexto de servicio para saber a dónde está dirigida la solicitud, si al servidor o al disco local, si la solicitud está dirigida al servidor se evalúa si ésta tiene como fin enviar un archivo o adquirirlo del servidor. Cuando el formato de contexto 3 está dirigido hacia el disco local (figura ) va directamente al disco para la adquisición del archivo y se entra en un ciclo de espera de un resultado para ser comunicado al usuario a través de la interfaz gráfica (GUI). Cuando se encuentra el archivo en el disco local se transfiere a la GUI para ser mostrado, en caso contrario se envía un mensaje en el que se especifica que el archivo no ha sido encontrado. Cuando el formato de contexto contiene la información para el envío de un archivo al servidor (figura ), se entra en un ciclo de espera para verificar que la acción haya sido realizada. Si el archivo fue almacenado en el servidor éste envía un mensaje de acción realizada, en modo contrario se muestra un mensaje en el que se especifica que el archivo no pudo ser almacenado en el servidor. Estos mensajes también son mostrados al usuario por medio de la GUI. 3 la petición que el cliente hace al servidor de acuerdo a DICOM 37

49 INICIO 1 esperando solicitud del usuario No se genera evento de comunicacion en la GUI? Si Mensaje: "Formateo de contexto incorrecto" No formato de peticion == formato de contexto? Si No solicitud IOD del servidor Si No solicitud de IOD Si A B C Figura 3.7: Diagrama de flujo de una estación de trabajo 38

50 A solicitar servicio al disco local No IOD solicitado existe? Si mostrar en la GUI:"archivo no encontrado" visulizar IOD en la GUI 1 1 FIN Figura 3.8: Diagrama de flujo de una estación de trabajo opción A 39

51 B enviar IOD 2 No Respuesta del servidor? Si procesar mensaje del servidor No mensaje= "el IOD se a lamacenado correctamente "? Si mostrar en la GUI:"El archivo no ha sido almacenado" mostrar en la GUI:"El archivo ha sido almacenado correctamente" 1 1 FIN Figura 3.9: Diagrama de flujo de una estación de trabajo opción B 40

52 En el caso en que se quiera adquirir una imagen que se encuentra en el servidor (figura ), se procede a enviar la solicitud al servidor para que recupere y transfiera el archivo solicitado y se entra en un modo de espera de una respuesta. Si el archivo fue encontrado se transfiere a la estación de trabajo para que sea visualizado en la GUI, en caso contrario se envía un mensaje en el que se especifica que el archivo no existe en el servidor Sistema de conexión El sistema de conexión usado para el diseño e implementación del PACS, es el que se encuentra actualmente en funcionamiento en el Centro de Telemedicina, del cual podemos mencionar las siguiente características físicas Características físicas Cableado estructurado 100 Mbps Switch Cisco Catalyst 10/100 Mbps Access Point Cisco Aironet 1130AG Series IEEE A/B/G, soporta los protocolos g y h, cuenta con una velocidad de transmisión máxima de 54 Mbps, en un radio de cobertura que va de los 30 a los 122 metros dependiendo de la velocidad de transmisión 41

53 C solicitar servicio al servidor 2 No Respuesta del servidor? Si procesar mensaje del servidor No mensaje= "el servidor no contiene IOD especificado"? Si visulizar IOD en la GUI mostrar en la GUI:"archivo no encontrado" 1 1 FIN Figura 3.10: Diagrama de flujo de una estación de trabajo opción C 42

54 Capítulo 4 Implementación del PACS El producto de software desarrollado hará parte de un grupo de aplicaciones que el Centro de Telemedicina viene elaborando para la tratamiento y procesamiento de imágenes medicas. este sistema recibira el nombre de CENTELPACS 1 con el cual esta registrado a nombre del Centro de Telemedicina quien se reserva todos los derechos de uso, utlización, distribución y copia. Para la implementación de CENTELPACS se tuvo en cuenta el diseño anteriormente expuesto, y mediante el estudio de diferentes librerías se pudo llegar al desarrollo del sistema. En este capítulo se muestra la manera como se desarrolló la aplicación iniciando con la evaluación de las librerías que dan soporte al estandar DICOM y después se muestra cómo se constituye el servidor y el visor del PACS Evaluación de las diferentes herramientas para la manipulación del PACS En la actualidad existen diversas herramientas con funciones específicas para la manipulación de archivos DICOM, entre ellas podemos destacar según su función las bibliotecas de visualización, de comunicación y aquellas que integran estas dos funciones. Las herramientas de visualización son bibliotecas que permiten mostrar al usuario el contenido de los archivos DICOM, tanto los metadatos como la imagen que viene contenida en éste, estas bibliotecas se implementan en las estaciones de trabajo en la cual la interacción con el usuario se hace de una manera directa. También existen bibliotecas que están diseñadas con base en el protocolo de comunicaciones DICOM, y se especializan en el transporte de acuerdo a los atributos que especifique el cliente, estas bibliotecas cumplen con la función en el PACS de interconectar las diferentes partes que lo componen (servidor, estaciones de trabajo). En la actualidad existen 1 PACS Centro de Telemedicina 43

55 herramientas que permiten manejar el módulo de comunicación y de visualización de una manera integrada. Podemos encontrar un gran número de herramientas para el manejo de archivos DICOM, debido a esto se hizo una selección de las bibliotecas más apropiadas para el desarrollo del sistema, para esto se definieron unos criterios de selección que permiten dar una mejor visión a la hora de escoger la más apropiada. Portabilidad portabilidad en los sistemas operativos Microsoft Windows XP, Linux, Mac OS X. Documentación Tipo de licencia la herramienta a evaluar debe ser de código abierto. Formatos DICOM que soporta A continuación se describen las herramientas que fueron evaluadas y analizadas en el desarrollo del PACS; estas herramientas presentan diversas funciones que sirven para visualizar, transportar, recopilar y tratar los diferentes archivos DICOM Biblioteca ITK ITK (Segmentation & registration ToolKit) es una biblioteca de código libre, utilizada principalmente para la ejecución del registro y segmentación en las imágenes. ITK está implementado en C++, y usa la herramienta CMAKE para manejar el proceso de compilación. Además presenta un proceso envolvente que permite interpretar los lenguajes de programación como Tcl, Java, Python. Figura 4.1: Logo ITK ITK implementa una biblioteca llamada GDCM. Esta biblioteca de código abierto fue desarrollada por CREATIS Tim, y se distribuye con licencia LPGL. La librería GDCM sólo implementa la parte 5 del estándar DICOM, lo cual hace que ITK sea limitado y no acepte ningún formato comprimido de DICOM; entre sus principales aplicaciones están las de leer y escribir imágenes DICOM sin compresión, de manera individual y por series. Esta librería cuenta con una amplia documentación que permite un buen análisis de ésta Biblioteca VTK Esta herramienta es de uso libre y puede ser utilizada en diferentes sistemas operativos, también cuenta con la documentación necesaria para el desarrollo de aplicaciones. Aunque 44

56 VTK (Visualization ToolKit) es un conjunto de librerías que se utilizan para la visualización y el procesamiento de imágenes, también se usan para la generación de objetos gráficos 2D y 3D. La biblioteca VTK consta de código abierto y software orientado a objetos. A pesar de ser muy extensas y complejas, las librerías se han diseñado de forma que puedan ser usadas por cualquier lenguaje de programación orientado a objetos. VTK proporciona un sistema de visualización por software que nos permite, además de poder visualizar geometría, soportar una amplia variedad de algoritmos de visualización y modelado. Figura 4.2: Logo VTK en las últimas versiones se han incluido clases que permitan la visualización de archivos DICOM, sólo permite la visualización de las imágenes, y no soporta los formatos comprimidos DICOM,; aún así esta biblioteca se puede usar junto con otras herramientas para suplir todas las necesidades de los archivos DICOM Biblioteca JDT JDT (Java Dicom Toolkit) es una biblioteca de desarrollo para archivos DICOM que está implementada totalmente en JAVA. Con esto, los desarrolladores DICOM pueden beneficiarse de las numerosas ventajas del lenguaje de programación JAVA y desplegarla en applets DICOM, aplicaciones independientes JAVA y en software del servidor. JDT viene con una API bien documentada que ha sido diseñada para hacer que la estructura compleja del estándar DICOM sea más accesible para los desarrolladores. JDT funciona sobre JDK 1.1.X y JAVA 2. JDT no es un producto gratuito, pero cuenta con la ventaja de abrir cualquier tipo de formato DICOM. Figura 4.3: Logo JDT Esta biblioteca presenta las siguientes características: Soporte de la parte 10 del estándar DICOM. Soporte de red DICOM. Soporte para todas las sintaxis de transferencia no comprimidas y conversiones. Soporte para formatos RLE y JPEG. 45

57 Leer y escribir datos DICOM desde InputStreams/OutputStreams. Esquema de tipos JAVA a tipos DICOM. Tolerancias en implementaciones DICOM Biblioteca DCMTK DCMTK es una biblioteca que implementa todas las partes del estándar DICOM para la comunicación y visualización de archivos. Esto incluye clases para el examen, la construcción y la conversión de archivos de imágenes DICOM, el manejo de medios de comunicación autónomos y el envío de imágenes de encubrimiento sobre una conexión de red. DCMTK incluye el código fuente completo y está escrito en una mezcla de C ANSI y C++. Figura 4.4: Logo DCMTK DCMTK ha sido usado en numerosas demostraciones DICOM como: almacenamiento de imágenes y servidores worklist. Es usado por hospitales y empresas en todo el mundo para una amplia variedad de propósitos, desde ser una herramienta para pruebas de productos, a ser un componente básico para proyectos de investigación, prototipos y productos comerciales. El software DCMTK puede ser usado bajo Windows o una amplia gama de sistemas operativos Unix que incluyen Linux, Solaris, OSF/1, IRIX, FreeBSD y Mac OS X. Todo lo necesario para la configuración del workspace y los makefiles son suministrados. Esta biblioteca tiene diferentes funciones basadas en el estándar DICOM. Las funciones son agrupadas en carpetas dependiendo de la función que desempeñen. A continuación se describe brevemente el contenido de los diferentes directorios. Config: Incluye los archivos.h necesarios para la configuración de DCMTK. Dcmdata: Contiene funciones para el tratamiento de los datos de los archivos DICOM y Data Sets. Dcmimage: Funciones para el tratamiento de los datos de los pixeles de una imagen. Sólo para imágenes DICOM sin comprimir. Dcmimgle: Sirven para el tratamiento de la luminosidad de las imágenes. Dcmjpeg: Son funciones para la compresión/descompresión de imágenes DICOM a JPEG. Dcmnet: Funciones para el transporte de los archivos DICOM a través de la Red. 46

58 Dcmpstat: Funciones para el tratamiento de escalas de grises y estados de presentación. Dcmsing: Para la creación o supresión de una firma digital para un archivo DICOM y su verificación. Dcmsr: Para la conversión de documentos DICOM SR (Structured Reporting) a HTML, XML. Dcmtls: Para la transmisión segura de archivos DICOM por la Red. Imagectn: Para el registro de archivos en una base de datos. Wlistctn: Para implementar un SCP como una Base de Datos Toolkit PIXELMED PIXELMED es un herramienta para el manejo de archivos DICOM que está implementada en Java, ésta es de distribución libre; cuenta con diferentes funciones para la manipulación de archivos DICOM como: la lectura y creación de datos, redes, creación y soporte de base de datos, exhibición de directorios, imágenes, informes, y validación de los objetos. Una cualidad importante de esta herramienta es que no depende de ninguna otra herramienta para su funcionamiento normal, y se pueden adherir algunas bibliotecas adicionales para elevar sus funciones, como herramientas libres disponibles de Java para la compresión, XML y la gestión de base de datos. Esta herramienta cuenta con una documentación necesaria, para el desarrollo de aplicaciones que contengan las diferentes funciones de esta librería. Además presenta la ventaja de trabajar con la mayoría de formatos DICOM, incluyendo aquellos que se encuentran de manera comprimida Implementación de la Estación de Trabajo En la implementación del visualizador se tuvo en cuenta el análisis de las diferentes herramientas para obtener las librerías mas apropiadas que se ajustarán a las necesidades específicas de este proyecto. De esta forma las dos librerías que mejor se acomodaban a los requerimientos del PACS fueron DCMTK y PIXELMED. 47

59 Con la biblioteca DCMTK se desarrollaron diferentes pruebas y se obtuvieron algoritmos para la captura de diferentes atributos de los archivos DICOM, pero a la hora de la integración con otras librerías para la visualización surgieron algunos problemas. Estos problemas no descartan esta librería y serán tratados en trabajos futuros por el Centro de Telemedicina para componer un visualizador que pueda contar con la velocidad de procesamiento de C++. La estación de trabajo final fue implementada con la biblioteca PIXELMED, la cual proporciona diferentes clases para la visualización de los metadatos y la imagen contenidas en los archivos DICOM. Este sistema se representa en el esquema de paquetes que se muestra en la figura 4.8, en esta se muestra como se ha desarrollado un paquete llamado co.edu.unal. telemedicina del cual se desprenden otros paquetes que se describen a continuación, junto con las clases que contienen. co.edu.unal.telemedicina co.edu.unal.telemedicina.comunicacion co.edu.unal.telemedicina.visualizacion co.edu.unal.telemedicina.consulta ServerConnectionForm MyWindow DicomLoader ContenidoDeDirectorio +ArbolDeContenido +contenidodeatributos +conectaralservidor() +inicializarcomponentes() +ejecutarconsulta() +Boton anterior +Boton siguiente +cargarimagendicom() +AbrirDirectorio() +cargararchivodicom() +vectordearchivos +archivoactual +directoriovalido +contararchivos() +archivosiguiente() +validardirectorio() Figura 4.5: Esquema UML de paquetes que conforman el visualizador 48

60 El paquete co.edu.unal.telemedicina.consulta encapsula la clase DicomLoader la cual cumple con la función de cargar los archivos DICOM, desde el disco local o el servidor, y estructurar los diferentes atributos, para ello utiliza el método cargararchivodicom(). Este paquete también contiene la clase ContenidoDeDirectorio por medio del cual evalúa el contenido de un directorio DICOM y muestra toda la información contenida en éste. El paquete co.edu.unal.telemedicina.visualizacion encapsula la clase Mywindow, por medio de la cual permite visualizar los diferentes atributos del archivo DICOM seleccionado. Para la ejecución de su función la clase MyWindow presenta atributos como botón anterior, botón siguiente, los cuales son utilizados en el momento de visualizar el estudio de un paciente. También presenta métodos para ejecutar diferentes funciones como son: cargarimagendicom(), abrirdirectorio(). El paquete co.edu.unal.telemedicina.comunicacion encapsula la clase ServerConnectionForm, por medio de ésta la estación de trabajo puede conectarse con el servidor del PACS, para poder descargar y visualizar imágenes contenidas en éste. Para que esta clase cumpla con esta función posee los atributos como: arboldecontenido, y contenidodeatributos. En esta clase también se manejan los siguientes métodos: conectaralservidor(), inicializarcomponentes(), ejecutarconsulta(). A continuación se describe de una manera más detallada el funcionamiento de las clases que contiene el visualizador y la conexión que hay entre cada una de ellas como se muestra en las figuras 4.9, y 4.7 En el diagrama de la figura 4.8 se muestra como la clase telemedicina.mywindow extiende de la clase JFrame, lo cual hace que herede todos sus métodos y por medio de ésta podemos visualizar y manejar los archivos DICOM, este paquete lo componen las siguientes clases: telemedicina.serverconnectionform Esta clase le permite al visualizador conectarse con el servidor, como se muestra en la figura 4.7, esta clase hereda de swing.jframe y está compuesta por telemedicina.principalquerytreebrowser que hereda de pixelmed.querytreebrowser, cumple con la función de visualizar la respuesta del servidor en una jerarquía mostrando los directorios de los pacientes y los diferentes estudios que están contenidos en éste. También esta compuesta por pixelmed.attributelist por medio de la cual puedo acceder a los atributos de los archivos DICOM, para hacer la consulta al servidor. Por último está compuesta por pixelmed.queryinformationmodel, que permite estructurar el mensaje de comunicación en los IODs apropiados para hacer la transmisión del archivo DICOM debido a que maneja todos los protocolos de comunicación establecidos. Esta clase además utiliza la clase telemedicina.principalreceivedobjecthandler, la cual hereda a su vez de pixelmed.receivedobjecthandler, está compuesta por pixelmed. DicomInputStream y utiliza la clase pixelmed.storagesopclassscpdispatcher. Esta clase permite recibir los estudios que han sido consultados en el servidor, para después ser visualizados en la estación de trabajo. 49

61 swing.jframe telemedicina.mywindow telemedicina.serverconnectionform swing.bufferedimage telemedicina.contenidodirectorio pixelmed.attributelist utliza pixelmed.dicominputstream telemedicina.dicomloader Figura 4.6: Esquema UML de clases que conforman el visualizador 50

62 swing.jframe telemedicina.mywindow pixelmed.receivedobjecthandler pixelmed.dicominputstream telemedicina.serverconnectionform telemedicina.principalreceivedobjecthandler pixelmed.querytreebrowser telemedicina.principalquerytreebrowser pixelmed.attributelist pixelmed.queryinformationmodel pixelmed.querytreemodel pixelmed.storagesopclassscpdispatcher Figura 4.7: Esquema UML de clases que conforman el visualizador 51

63 telemedicina.contenidodirectorio Esta clase puede leer el directorio que ha solicitado el usuario, para después convertirlo en paquetes IODs, para realizar su búsqueda dentro del disco local de la estación de trabajo. Esta clase después de que hace la búsqueda y ha identificado los paquetes correspondientes que debe devolver, pasa estos IODs a la clase telemedicina.dicomloader. telemedicina.dicomloader Esta clase recibe los IODs encontrados por la clase telemedicina.contenidodirectorio, y los estructura de acuerdo a los atributos que ha solicitado el usuario, hace una conversión de estos datos que están en formato DICOM, a un formato que pueda ser manipulado por la clase swing.bufferedimage, para esto se apoya en la clase pixelmed.dicominputstream. swing.bufferedimage Esta clase es la encargada de visualizar los datos que han sido recuperados por la clase DicomLoader, así como también distingue entre la imagen y los demás atributos para ser mostrados en el panel de la estación de trabajo Funcionamiento general de la estación de trabajo La aplicación que se obtuvo para la estación de trabajo se muestra en la figura 4.8, la cual se encuentra estructurada en diferentes elementos que cumplen funciones similares; a continuación se describen cada uno de estos grupos Un grupo de botones para la configuración de la imagen y para la visualización de un estudio en la cual podemos abrir un directorio desde el disco local, y ver todas las imágenes del estudio de un paciente. Presenta una área de texto donde permita visualizar los diferentes datos que vienen asociados con la imagen. Presenta un grupo de botones que me permiten conectar con el servidor, para visualizar un archivo dado. Tiene un panel que me permite visualizar las diferentes imágenes de un estudio. 52

64 En la figura 4.9 se muestra como la estación de trabajo muestra una imagen DICOM, así como los datos que esta tiene asociados. La estación de trabajo fue desarrollada en la plataforma Java, con la máquina virtual 1.5, y usando el entorno de desarrollo NETBEANS IDE 5.0. Opciones Para la Imegeny el Estudio Panel para Visualización de la imagen Muestra los metadatos de cada imagen Opciones para conexión con el servidor Abrir Estudio Figura 4.8: Estación de trabajo 4.4. Implementación del servidor El servidor fue desarrollado con base en la librería de PIXELMED, la cual cuenta con clases que estructuran de manera adecuada según lo especificado en el protocolo DICOM de comunicaciones. En la figura 4.7 se muestra un diagrama de paquetes que muestra como están organizadas las clases que componen esta aplicación. En esta figura se muestra que la aplicación del servidor está contenida en el paquete co.edu.unal.telemedicina.servidor, el cual a su vez encapsula dos clases: StorageServer Esta clase tiene la función de inspeccionar de manera recurrente la dirección de prestación, que para este caso será la 4006, y procesar la información de solicitud de una estación de trabajo. También hace la búsqueda dentro de la base de datos y envía los datos a la clase RebuildDatabase. 53

65 Figura 4.9: Estación de trabajo 54

66 RebuildDatabase Esta clase reconstruye los IODS, para enviarlos a través de la red a la estación de servicio que los ha solicitado, para ello cuenta con el método procesararchivoodirectorio(). co.edu.unal.telemedicina co.edu.unal.telemedicina.servidor StorageServer +tituloentidadaplicacion +puerto +directorioprincipal +manejarconsulta() +enviaryrecibirarchivodiocm() +escucharpuerto() +registrarservicio() RebuildDatabase +procesararchivoodirectorio() Figura 4.10: Esquema UML de paquetes que conforman el servidor En la figura 4.11 se muestra de una manera más detallada como las clases que componen el servidor están relacionadas entre sí. Podemos ver que telemedicina.storageserver está compuesta por las clases que se muestran a continuación, las cuales proporcionan funciones para que la aplicación funcione de manera eficiente. pixelmed.databaseinformationmodel Esta clase permite manejar un modelo de base de datos para almacenar los archivos DICOM. pixelmed.attributelist Esta clase permite manipular los archivos de acuerdo a los atributos que hayan sido solicitados para su búsqueda, pixelmed.dicomoutputstream por medio de la cual entrega los archivos DICOM a través de la red empaquetados en forma de IODs pixelmed.networkconfiguration Esta clase configura la red general teniendo como base el modelo de comunicaciones DICOM. 55

67 pixelmed.storagesopclassscpdispatcher Esta clase permite asociar la clase SOP con la clase SCP para que el servidor pueda transferir los archivos DICOM. telemedicina.storageserver pixelmed.databaseinformationmodel pixelmed.attributelist pixelmed.dicomoutputstream pixelmed.networkconfiguration pixelmed.storagesopclassscpdispatcher Figura 4.11: Esquema UML de paquetes que conforman el servidor 4.5. Funcionamiento general del SERVIDOR la aplicación del servidor de CENTELPACS debe trabajar para atender las solicitudes de las estaciones de trabajo.las estaciones de trabajo funcionan en promedio entre 1 y 2 horas a cargo de los especialistas en imagenes medicas, el software del servidor debe trabajar todo el dia. No se implementó una interfaz de usuario para la administración de los procesos del servidor, pero de todos modos cuenta con parametros configurables en un archivo de texto que edita el administrador del sistema colocando los valores apropiados segun el entorno de red donde debe funcionar el PACS. En el archivo se configura los siguienets parametros Un directorio para conservar los atributos de las imagenes almacenadas. 56

68 Un directorio en donde se encuentran las imagenes fisicamente. La dirección de prestacion por donde se atenderan las solicitudes Título de entidad de aplicación Listado de otras entidades de aplicación remotas que pueden intercambiar información con este servidor. El primer paso para iniciar el servidor es preparar la ruta en el disco donde estarán almacenados todos los estudios que se pondran en servicio para la red. Luego se ejecuta un programa para analizar los directorios de archivos DICOM y extraer los datos que estaran disponibles para el modelo de consulta basados en los atributos del paciente que son incluidos a nivel del estudio. Debido a que el servidor no cuenta con una interfaz de usuario, se inicia como una aplicacion para línea de comando que permanecera en ejecucion como un oproceso del sistema que tiene interacción con otros procesos mas no con el usuario directamente. 57

69 Capítulo 5 Pruebas de Ejecución 5.1. Soporte de Formatos DICOM Esta prueba permite comprobar qué tipos de formatos DICOM soporta el NUKAKPACS, evaluando un grupo de 7200 imágenes del Centro de Telemedicina y otros archivos publicados en internet, que presentan una diversidad de formatos, estructuras, tamaños y dispositivos de captura. Estas pruebas se realizaron en el software de la estación de trabajo, para evaluar el soporte de visualización de la imagen y la extracción de los metadatos. Tanto en el software de la estación, como en el servidor se utilizó el mismo módulo para la lectura de los archivos DICOM, por esta razón las pruebas que se realizaron en la estación de trabajo tienen los mismos resultados que las pruebas realizadas en el servidor. La prueba en la estación de trabajo consistió en cargar diferentes directorios DICOM para evaluar el despliegue de los atributos y la visulización de la imagen en la interfaz de usuario, con previo conocimiento del formato de la imagen, el cual puede ser reconocido por el UID. La verificación del soporte de archivos DICOM en el servidor se realizó en forma paralela con el proceso de análisis de los directorios desplegando una alerta para aquellos archivos que no podían ser reconocidos durante el procesamiento en lote de los archivos. Este proceso es requerido para extraer los atributos mediante los cuales el servidor prestará el servicio de consulta. En el cuadro 5.1, se muestran los diferentes formatos DICOM que fueron evaluados y los resultados obtenidos en el proceso de lectura Desempeño del Módulo de Comunicaciones En esta prueba se tuvieron en cuenta parámetros para la evaluación de la comunicación entre el servidor y la estación de trabajo, midiendo el tiempo de respuesta del servidor después 58

70 UID NOMBRE DEL FORMATO SOPORTADO Implicit VR Little Endian: Default Transfer SI Syntax for DICOM Explicit VR Little Endian SI JPEG Baseline (Process 1): Default Transfer SI Syntax for Lossy JPEG 8 Bit Image Compression RLE Lossless SI Explicit VR Big Endian SI Computed Radiography Image Storage NO CT Image Storage NO Secondary Capture Image Storage NO Cuadro 5.1: Cuadro de evaluación de los formatos DICOM en el NUKAKPACS Estaciones Concurrentes Tiempo Promedio de Respuesta (ms) UNA 8529 DOS 8928 TRES 8892 CUATRO 9153 CINCO 9242 Cuadro 5.2: Tiempos de respuesta con varias estaciones concurrentes de que una estación hace una consulta. Esta consulta fue diseñada para cargar los atributos de 90 pacientes para poder consultar sus estudios. Se utilizaron 7 estaciones de trabajo para hacer pruebas de consultas concurrentes hacia el servidor, 3 de ellas con sistema operativo WINDOWS XP, y las demás con sistema operativo LINUX. En las siguientes tablas se reflejan los resultados de las pruebas operacionales con respecto al tiempo. las estaciones de trabajo tiene las caracteristicas fisicas mostradas en el capitulos de Diseño de un PACS?? Durante la ejecución de las pruebas se observó que las estaciones de trabajo con sistema operativo WINDOWS XP presentaban tiempos de respuesta superiores a los obtenidos en el sistema operativo LINUX, de esta forma se procesió a comparar los tiempos de respuesta según el sistema operativo que hace la petición obteniendo los resultados plasmados en el cuadro 5.3 En el cuadro 5.2 se muestran los resultados obtenidos en las pruebas de concurrencia, las cuales indican que a medida que se incrementa el número de estaciones en una, también aumenta el retraso en la respuesta. Sin embargo puede notarse que el incremento en el tiempo 59

71 Sistema operativo Tiempo Promedio de Respuesta (ms) WINDOWS XP LINUX 5272 Cuadro 5.3: Tiempos de respuesta de los sistemas operativos 60