diseño y desarrollo de un pacs usando una libreria de lectura y

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
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
Nota de aceptación:
Firma del presidente del jurado
Firma del jurado
Firma del jurado
Pamplona, 22 de Mayo 2006
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
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
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
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
Índice general
Resumen
iii
Abstract
iv
Introducción
1. Estándar DICOM
1.1. Historia . . . . . . . . . . . . . .
1.2. Formato de los Archivos DICOM
1.3. Estructura DICOMDIR . . . . .
1.4. Estructura del estándar DICOM
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
4
4
7
2. PACS (Picture Archiving and Communication Systems)
2.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Modelo de comunicaciones . . . . . . . . . . . . . . . . . . .
2.2.1. Servidores . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2. Estaciones de Trabajo . . . . . . . . . . . . . . . . .
2.2.3. Estaciones para la adquisición de imágenes . . . . .
2.2.4. Sistema de interconexión . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
18
22
23
24
24
3. Diseño de un PACS
3.1. Diseño del software para el SERVIDOR . . . . . . . . . . . . . . .
3.1.1. Diseño de la aplicación . . . . . . . . . . . . . . . . . . . . .
3.1.2. Diagrama de flujo de la aplicación del servidor . . . . . . .
3.2. Estación de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1. Caracterı́sticas fı́sicas . . . . . . . . . . . . . . . . . . . . .
3.2.2. Diseño de las estaciones de trabajo . . . . . . . . . . . . . .
3.2.3. Diagrama de flujo de la aplicación de la estación de trabajo
3.3. Sistema de conexión . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
29
30
31
34
35
35
37
42
.
.
.
.
.
.
.
.
.
.
.
.
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.3.1. Caracterı́sticas fı́sicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4. Implementación del PACS
4.1. Evaluación de las diferentes herramientas para la manipulación del PACS
4.1.1. Biblioteca ITK . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2. Biblioteca VTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.3. Biblioteca JDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.4. Biblioteca DCMTK . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.5. Toolkit PIXELMED . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2. Implementación de la Estación de Trabajo . . . . . . . . . . . . . . . . . .
4.3. Funcionamiento general de la estación de trabajo . . . . . . . . . . . . . .
4.4. Implementación del servidor . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5. Funcionamiento general del SERVIDOR . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
43
44
44
45
46
47
47
52
53
56
5. Pruebas de Ejecución
58
5.1. Soporte de Formatos DICOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2. Desempeño del Módulo de Comunicaciones . . . . . . . . . . . . . . . . . . . . 58
6. Conclusiones y Perspectivas
62
vi
Índice de figuras
1.1.
1.2.
1.3.
1.4.
1.5.
1.6.
1.7.
1.8.
Ejemplo de imágenes en formato DICOM . . . . . . . . . . . . . . . . . . . . . 3
Estructura de un archivo DICOM . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Estructura de los ARCHIVOS DICOM . . . . . . . . . . . . . . . . . . . . . . . 6
Proceso de construcción de una red de trabajo de acuerdo a la conformación . . 8
Proceso de construcción para la comunicación de acuerdo a la conformación . . 9
Definición de los objetos de información de acuerdo a las entidades de información 10
Ejemplo del el objeto de informacion compuesto en una imagén . . . . . . . . . 10
Registro de los elementos de datos de DICOM. Tomada de la parte 6 del
estándar DICOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.
2.2.
2.3.
2.4.
2.5.
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
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
21
24
25
25
3.1. Esquema del PACS implementado en el proyecto . . . . . . . .
3.2. Esquema que representa el diseño de la aplicación del servidor .
3.3. Diagrama de flujo del algoritmo del servidor . . . . . . . . . . .
3.4. Diagrama de flujo del servidor opción A . . . . . . . . . . . . .
3.5. Diagrama de flujo del servidor opción B . . . . . . . . . . . . .
3.6. Esquema UML de la estación de trabajo . . . . . . . . . . . . .
3.7. Diagrama de flujo de una estación de trabajo . . . . . . . . . .
3.8. Diagrama de flujo de una estación de trabajo opción A . . . . .
3.9. Diagrama de flujo de una estación de trabajo opción B . . . . .
3.10. Diagrama de flujo de una estación de trabajo opción C . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
28
30
32
33
34
36
38
39
40
41
4.1. Logo ITK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2. Logo VTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3. Logo JDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
vii
4.4. Logo DCMTK . . . . . . . . . . . . . . . . . . . . . . . .
4.5. Esquema UML de paquetes que conforman el visualizador
4.6. Esquema UML de clases que conforman el visualizador . .
4.7. Esquema UML de clases que conforman el visualizador . .
4.8. Estación de trabajo . . . . . . . . . . . . . . . . . . . . . .
4.9. Estación de trabajo . . . . . . . . . . . . . . . . . . . . . .
4.10. Esquema UML de paquetes que conforman el servidor . .
4.11. Esquema UML de paquetes que conforman el servidor . .
viii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
48
50
51
53
54
55
56
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
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
2
American College of Radiology
National Electrical Manufacturers Association
2
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. 300-1985 (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. 300-1988 (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 33-1988 de ACR-NEMA.
3
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 DICOM 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.
1.3.
Estructura DICOMDIR
DICOMDIR3 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 20632 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 19838 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
Archivo DICOM
Nombre Paciente: Rabbit Osman
Tipo de Imagen: Original
Cabecera del Archivo DICOM
donde se encuentran los metadatos
del Archivo
Parte Examinada: Heart
Nombre de la institución: UCLA
Marca del equipo: Siemens
Imagen DICOM
Figura 1.2: Estructura de un archivo DICOM
5
DICOMDIR
ARCHIVO
DICOMDIR
ARCHIVO
DICOM_1
ARCHIVO
DICOM_2
ARCHIVO
DICOM_3
ARCHIVO
DICOM_1
ARCHIVO
DICOM_2
CABECERA ARCHIVO
CABECERA ARCHIVO
METADATOS
METADATOS
IMAGEN
IMAGEN
Figura 1.3: Estructura de los ARCHIVOS DICOM
6
ARCHIVO
DICOM_3
CABECERA ARCHIVO
METADATOS
IMAGEN
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
Parte 16
Parte 14
Funcion que
muestra la
escala de grises
Parte 6
Diccionario
de datos
Parte 5
Estructura de
Datos y Semantica
Parte 10
Intercambio de
Mensajes
Parte 12
Perfiles
de seguridad
Recursos para
la busqueda del
contenido
CONFORMACION DEL
ESTANDAR DICOM
MODELO DE
IMPLEMENTACION
Parte 3
Definición de los
objetos de la
información
Parte 4
Especificaciones
con las clases
de servicio
CLASES SOP
TAREAS
SINTAXIS DE
TRANSFERENCIA
PILA DE
COMUNICACION
Parte 11
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
Parte 16
Parte 14
Funcion que
muestra la escala
de grises
Parte 6
Parte 5
Estructura de
Datos y Semantica
Diccionario
de datos
Parte 10
Perfiles en los
medios de
comunicación
Parte 12
Parte 15
Recursos para
la busqueda del
contenido
CONFORMACION DEL
ESTANDAR DICOM
MODELO DE
IMPLEMENTACION
Parte 3
Definición de los
objetos de la
información
PERFILES DE APLICACAION
Parte 4
Especificaciones
con las clases
de servicio
Parte 11
CLASES SOP
TAREAS
SINTAXIS DE
TRANSFERENCIA
Formato de archivos
e intercambio
de datos
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
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
Selección
Entidad de informació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
Nombre
Manufactura
Sexo
Referencia
Estudio
Imagen
Identificación
Numero
Identificación
Numero
de seleccion
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
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
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
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
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
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
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
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.
2.1.
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
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.
2.2.
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
Almacenamiento
Adquisición
Sistema de
interconexión
kldjfkfkfkoghk
kfkfkfgkg363
flglgpgp...
Visualización
Figura 2.1: Esquema de un PACS
19
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
PROCESO DISTRIBUIDO
CLIENTE
Servicio de usuario
Proveedor de
servicio
RELACION
SERVIDOR
REPRESENTACION
FROMATO DE TRANSFERENCIA
Servicio de usuario
Proveedor de
servicio
INTERCAMBIO FISICO
Figura 2.2: Modelo de un proceso distribuı́do
21
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.
2.2.1.
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
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.
2.2.2.
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
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.
2.2.3.
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.
2.2.4.
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
PACS
paciente 1....
paciente 2....
id....123456..
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
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, 1.544 Mbps)
DS-3 (45 Mbps) ATM (155-622 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
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
RED UNIVERSIDAD
NACIONAL
INTERNET
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
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.
3.1.
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
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.
3.1.1.
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
COMUNICACION
MODULO DE
ALMACENAMIENTO
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
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.
3.1.2.
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 SOP1 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 IOD2 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
2
Service Object Provider
Information Object Definition
31
INICIO
1
Dirección de prestación ==4006
No
Direccion de prestacion
existe
solicitud de objetos SOP ?
SI
Mensaje: "El formato de peticion
no es valido"
No
formato de petción
==
contexto de servicio ?
SI
SI
No
Adquirir IOD del servidor
B
A
Figura 3.3: Diagrama de flujo del algoritmo del servidor
32
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 ?
Mensaje: "el IOD no se ha podido almacenar
en ell servidor"
Si
Mensaje: "El IOD ha sido almacenado
correctamente"
1
1
FIN
Figura 3.4: Diagrama de flujo del servidor opción A
33
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
Mensaje: "el servidor no contiene el
IOD solicitado"
Si
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
3.2.1.
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
2. 512 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
2. 256 MB de memoria RAM
3. Disco Duro de 20 GB
3.2.2.
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
COMUNICACION
ALMACENAMIENTO
{}
{}
CONSULTA
VISUALIZACION
interfaz gráfica
de ususario
Figura 3.6: Esquema UML de la estación de trabajo
36
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.
3.2.3.
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 contexto3 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
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
Si
solicitud IOD
del servidor
Si
No
solicitud de IOD
C
A
B
Figura 3.7: Diagrama de flujo de una estación de trabajo
38
A
solicitar servicio al
disco local
No
Si
IOD solicitado existe ?
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
B
enviar IOD
2
No
Respuesta del servidor ?
Si
procesar mensaje del servidor
Si
No
mensaje= "el IOD se a lamacenado
correctamente " ?
mostrar en la GUI:"El archivo ha sido
almacenado correctamente"
mostrar en la GUI:"El archivo no ha sido
almacenado"
1
1
FIN
Figura 3.9: Diagrama de flujo de una estación de trabajo opción B
40
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.
3.3.
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.
3.3.1.
Caracterı́sticas fı́sicas
Cableado estructurado 100 Mbps
Switch Cisco Catalyst 10/100 Mbps
Access Point Cisco Aironet 1130AG Series IEEE 802.11A/B/G, soporta los protocolos
802.11g y 802.11h, 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
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
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.
4.1.
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
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.
4.1.1.
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.
4.1.2.
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
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.
4.1.3.
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
Leer y escribir datos DICOM desde InputStreams/OutputStreams.
Esquema de tipos JAVA a tipos DICOM.
Tolerancias en implementaciones DICOM.
4.1.4.
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:
DCMTK
Logo
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
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.
4.1.5.
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.
4.2.
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
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
ServerConnectionForm
co.edu.unal.telemedicina.visualizacion
MyWindow
+ArbolDeContenido
+contenidoDeAtributos
+Boton anterior
+Boton siguiente
+conectarAlServidor()
+inicializarComponentes()
+ejecutarConsulta()
+cargarImagenDicom()
+AbrirDirectorio()
co.edu.unal.telemedicina.consulta
DicomLoader
+cargarArchivoDicom()
ContenidoDeDirectorio
+vectorDeArchivos
+archivoActual
+directorioValido
+contarArchivos()
+archivoSiguiente()
+validarDirectorio()
Figura 4.5: Esquema UML de paquetes que conforman el visualizador
48
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
swing.JFrame
telemedicina.MyWindow
telemedicina.ServerConnectionForm
telemedicina.ContenidoDirectorio
swing.BufferedImage
utliza
pixelmed.DicomInputStream
telemedicina.DicomLoader
Figura 4.6: Esquema UML de clases que conforman el visualizador
50
pixelmed.AttributeList
swing.JFrame
telemedicina.MyWindow
telemedicina.ServerConnectionForm
pixelmed.ReceivedObjectHandler
pixelmed.DicomInputStream
telemedicina.PrincipalReceivedObjectHandler
pixelmed.QueryTreeBrowser
telemedicina.PrincipalQueryTreeBrowser
pixelmed.AttributeList
pixelmed.QueryTreeModel
pixelmed.QueryInformationModel
pixelmed.StorageSOPClassSCPDispatcher
Figura 4.7: Esquema UML de clases que conforman el visualizador
51
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.
4.3.
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
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
Figura 4.9: Estación de trabajo
54
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
RebuildDatabase
+procesarArchivooDirectorio()
+manejarConsulta()
+enviaryRecibirArchivoDiocm()
+escucharpuerto()
+registrarServicio()
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
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.NetworkConfiguration
pixelmed.AttributeList
pixelmed.DicomOutputStream
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
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
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.
5.2.
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
UID
1.2.840.10008.1.2.5
1.2.840.10008.1.2.5
1.2.840.10008.1.2.5
1.2.840.10008.1.2.5
1.2.840.10008.1.2.5
1.2.840.10008.5.1.4.1.1.1
1.2.840.10008.5.1.4.1.1.2
1.2.840.10008.5.1.4.1.1.7
NOMBRE DEL FORMATO
Implicit VR Little Endian: Default Transfer
Syntax for DICOM
Explicit VR Little Endian
JPEG Baseline (Process 1): Default Transfer
Syntax for Lossy JPEG 8 Bit Image Compression
RLE Lossless
Explicit VR Big Endian
Computed Radiography Image Storage
CT Image Storage
Secondary Capture Image Storage
SOPORTADO
SI
SI
SI
SI
SI
NO
NO
NO
Cuadro 5.1: Cuadro de evaluación de los formatos DICOM en el NUKAKPACS
Estaciones Concurrentes
UNA
DOS
TRES
CUATRO
CINCO
Tiempo Promedio de Respuesta (ms)
8529
8928
8892
9153
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
Sistema operativo
WINDOWS XP
LINUX
Tiempo Promedio de Respuesta (ms)
21366
5272
Cuadro 5.3: Tiempos de respuesta de los sistemas operativos
60
de respuesta es por cada estación de trabajo es de 277.25 ms en promedio, 1.97 % cada vez
que aumenta el número de peticiones realizadas de forma simultánea. Esto significa que la
cantidad de consultas concurrentes no afecta notablemente el desempeño en los tiempos de
respuesta.
Por otro lado, los tiempos de respuesta obtenidos para los diferentes sistemas operativos,
presentados en el cuadro 5.3, revelan algún tipo de anomalı́a al utlizar estaciones de trabajo
con el sistema operativo WINDOWS XP. Estos problemas podrı́an localizarse probablemente
en alguno de los componentes externos que interactúan directamente con el sistema operativo, como la máquina virtual de Java , o la biblioteca utilizada para el manejo de archivos
DICOM. Un análisis más profundo de este problema podrı́a sugerir estrategias para mejorar
el rendimiento bajo el sistema operativo WINDOWS, sin embargo esta evaluación está fuera
del alcance de los propósitos de este proyecto.
61
Capı́tulo 6
Conclusiones y Perspectivas
Los sistemas tradicionales de almacenamiento y visualización de imágenes son costosos,
debido a la impresión de imágenes en placas, y la adquisición y mantenimiento del
sistema de almacenamiento. Los PACS mediante su sistema de almacenamiento logran
disminir estos costos en mas de un 99 % y optimizar el sistema de comunicación y
administración de archivos dentro de los hospitales.
En Colombia la mayorı́a de los hospitales manejan el sistema tradicional; debido a la
creciente expansión de los servicios médicos, es necesario implementar PACS para poder
brindar un mejor servicio a médicos, pacientes y familiares, con información que pueda
ser administrada de manera segura, la visulización de imágenes sea eficiente y módulos
que puedan ser fácilmente adaptables a los sistemas HIS.
En el proceso de implementación de la aplicación CENTELPACS, se evaluó un conjunto
de bibliotecas para el manejo de archivos DICOM. De acuerdo a los criterios de evaluación propuestos, las bibliotecas más adecuadas para el proyecto fueron PIXELMED y
DCMTK. Aunque DCMTK presenta inconvenientes de portabilidad y su documentación
no está completa, esta biblioteca tiene un buen soporte para manejar la totalidad del
estándar DICOM; adicionalmente la licencia es de código abierto, lo cual permite su
modificación y configuración. Por otra parte, la biblioteca PIXELMED presenta documentación apropiada, cuenta con las ventajas de portabilidad del lenguaje JAVA, y su
licencia de código abierto permitirá al Centro de Telemedicina modificarla y extenderla
si es necesario, de la misma forma que la biblioteca DCMTK.
El sistema CENTELPACS fue probado con 8 formatos diferentes de DICOM, de los
cuales 5 pudieron ser leı́dos y visualizados correctamente. los tres que no se pudieron
leer correspondı́an a formatos ACR-NEMA que son en este momento obsoletos, del año
97 y han desaparecido del mercado. Se propone para trabajos futuros en el Centro de
62
Telemedicina integrar el soporte lógico multiplataforma Nukak3D, como una estación
de trabajo para la visulización de la mayoria de formatos DICOM, puesto que esta
aplicación permite una visualización óptima de las imágenes, además incorpora funciones
para construir ı́mágenes 3D a partir de las bidimensionales; estas caracterı́sticas facilitan
el diagnóstico.
El estandar DICOM está limitado para que el servidor atienda sólo una petición a la
vez de un archivo DICOM especı́fico. En trabajos futuros el Centro de Telemedicina
tiene como objetivo proponer estrategias para mejorar el modelo de comunicaciones que
define el estándar DICOM.
Conociendo las necesidades hospitalarias para el manejo de la información, y teniendo en
cuenta la disponibilidad de recursos y tecnologı́as en Colombia, el Centro de Telemedicina inicia con este proyecto la exploración de un extenso campo de desarrollo tecnológico
para desarrollar sistemas de informática médica que aprovechen las herramientas computacionales para las prácticas clı́nicas. Uno de los próximos retos en este proyecto
será el diseño de un sistema que pueda soportar conexiones simultáneas a gran escala,
basado en una arquitectura de software extensible y robusta que sirva de plataforma
tecnológica para administrar el conocimiento y los servicios de salud.
63
Bibliografı́a
[1] Dicom. WEB, MARZO 2006. http://www.sph.sc.edu/comd/rorden/dicom.html.
[2] Documnetación kitware, Abril 2006. http://public.kitware.com/.
[3] Vtk, Abril 2006. http://vtk.org//.
[4] P.G.J. Barten. Physical model for the contrast sensitivity of the human eye. -, 0:–, 1992.
[5] David A. Clunie. Dicom standard status. web, Abril 2006. http://www.dclunie.com/
dicom-status/status.html.
[6] David A. Clunie. Pixelmed, Abril 2006. hhttp://www.pixelmed.com/.
[7] Davis A. Clunie. DICOM structured Reporting123. PixelMed Publishing Bangor, Pennsylvania, 2000.
[8] Lydia Ng Josh Cates Luis Ibáñez, Will Schroeder. The ITK Software Guide Updated for
ITK version 2.4. coprygith, November 21, 2005.
[9] Marco Eichelberg; Michael Onken; Jörg Riesmeier; Andreas Thiel. Libraries dcmtk, Abril
2006. http://dicom.offis.de/dcmtk.php.en.
[10] Lisa; MARTIN Kenneth; LAW C. Charles; KING Brad; HOFFMAN William; HENDERSON Amy; GEVECI Berk; WILLIAM, J. Schroeder;AVILA. The Visulization Toolkit
User´s Guide. KITWARE, INC., 2003.
[11] Kenneth M. Martin Willian A.Hoffman C. Charles law William J. Schroeder, Lisa S. Avila. The Visulization Toolkit User’s Guide. kitware, 2001.
64