Proyecto Fin de Carrera
Escuela Superior de Ingenieros
Universidad de Sevilla
Departamento de Ingeniería de Sistemas y Automática
Área de Ingeniería Telemática
Servicio Web para la
Gestión de Imágenes Médicas
Autor: Sergio Rivas Rivas
Tutora: Isabel Román Martínez
Sevilla, Julio 2009
A mis padres, mi novia y mi hermana
que siempre estuvieron ahí para apoyarme.
Agradecimientos
En primer lugar quiero dar las gracias a mi Tutora Isabel Román Martínez por su
dirección y guía en el trabajo realizado, y a su disponibilidad y diligencia en todo
momento para cualquier duda que apareciera, aspectos, los cuales han permitido que
este proyecto fin de carrera haya visto su final.
En segundo lugar, quiero agradecer la ayuda recibida, las rápidas contestaciones a
preguntas y las fructíferas discusiones a los miembros del Grupo de Ingeniería
Biomédica de la Escuela Superior de Ingenieros de la Universidad de Sevilla, y
especialmente a Jorge Calvillo Arbizu.
Finalmente quiero mostrar mi más profundo agradecimiento a mi familia, ya que
siempre ha estado ahí.
Servicio Web para la Gestión de Imágenes Médicas Índice de Contenidos
4
Índice de Contenidos
Capítulo 1: Introducción............................................................................................................. 18
1. Motivación del Proyecto..................................................................................................... 18
2. Objetivos del Proyecto ........................................................................................................ 19
3. Plan de Trabajo..................................................................................................................... 21
4. Medios Materiales................................................................................................................ 21
5. Organización de la Memoria.............................................................................................. 22
Capítulo 2: Estado del Arte........................................................................................................ 24
1. Introducción .......................................................................................................................... 24
2. Servicios Web........................................................................................................................ 24
2.1. Estándares Empleados ................................................................................................ 26
2.2. Ventajas e Inconvenientes del uso de Servicios Web........................................... 27
2.3. Plataformas .................................................................................................................... 28
3. Estándar DICOM................................................................................................................. 29
3.1. Formato de Datos DICOM........................................................................................ 31
3.2. Servicios DICOM......................................................................................................... 31
3.3. Metadatos de la cabecera DICOM ........................................................................... 34
3.4. Implementaciones Software DICOM: Librería DCM4CHE.............................. 36
3.4.1. Paquete de Librerías dcm4che ........................................................................ 36
Servicio Web para la Gestión de Imágenes Médicas Índice de Contenidos
5
3.4.2. Desarrollo de Aplicaciones Utilizando Dcm4che2..................................... 37
3.4.3. Utilidades Stand-Alone..................................................................................... 38
4. Especificación CIAS............................................................................................................. 39
4.1. ClinicalImageAccessComponent Interface ............................................................. 39
4.2. ImageAccess Interface................................................................................................. 40
4.2.1. get_observation_by_qualified_code ( ).......................................................... 42
4.2.2. get_images () ....................................................................................................... 43
4.2.3. get_overlays ( ) ................................................................................................... 44
4.2.4. get_graphs ( ) ...................................................................................................... 45
4.2.5. get_raw_images ( )............................................................................................. 45
4.3. ObservationLoader Interface..................................................................................... 46
Capítulo 3: Servicio Web para la Gestión de Imágenes Médicas...................................... 48
1. Introducción .......................................................................................................................... 48
2. Base de Datos ........................................................................................................................ 49
2.1. Diagrama Entidad-Relación....................................................................................... 51
2.2. Diagrama UML de Clases .......................................................................................... 52
3. Servicio ClinicalImageService ........................................................................................... 52
3.1. Interfaz ClinicalImageService ................................................................................... 55
3.2. Interfaz ObservationLoader....................................................................................... 56
3.2.1. load_images() ...................................................................................................... 57
Servicio Web para la Gestión de Imágenes Médicas Índice de Contenidos
6
3.3. Interfaz ImageAcces .................................................................................................... 58
3.3.1. get_observation_by_qualified_code()............................................................ 59
3.3.2. get_images() ........................................................................................................ 62
3.4. Interfaz ClinicalImageDB........................................................................................... 65
3.4.1. CheckUser ( )....................................................................................................... 66
3.4.2. InsertUser( )........................................................................................................ 67
3.4.3. UpdateUser()....................................................................................................... 68
3.4.4. ContNumberOfUser( ) ...................................................................................... 69
3.4.5. GetRowOfUser( ) ............................................................................................... 70
3.4.6. InsertPatient( ) ................................................................................................... 70
3.4.7. GetRowOfPatient( )........................................................................................... 71
3.4.8. ViewPatientByID( ) ........................................................................................... 72
3.4.9. ContNumberOfPatient( ).................................................................................. 73
3.4.10. UpdatePatient( ) ................................................................................................. 73
3.4.11. SearchTestByID() .............................................................................................. 74
3.4.12. SearchTestByTUID() ....................................................................................... 75
3.4.13. SearchSequenceByTUID()............................................................................... 76
3.4.14. SearchSequenceBySUID()................................................................................ 77
3.4.15. SearchDiagnosticByTUID()............................................................................ 77
3.4.16. InsertDiagnostic().............................................................................................. 78
Servicio Web para la Gestión de Imágenes Médicas Índice de Contenidos
7
3.4.17. SearchRemarksByTUID()................................................................................ 79
3.4.18. InsertRemarks().................................................................................................. 80
3.4.19. SearchFilesBySUID()........................................................................................ 81
3.4.20. SearchFilesByName()........................................................................................ 82
3.5. CGI´s ............................................................................................................................... 83
3.5.1. CGI: call.pl........................................................................................................... 84
3.5.2. CGI: dcm2jpg.cgi ............................................................................................... 85
3.5.3. CGI: dcmecg2png.cgi........................................................................................ 86
3.5.4. CGI: DicomFile.dcm ......................................................................................... 86
3.5.5. CGI: cogefichero.cgi .......................................................................................... 87
3.5.6. CGI: header.pl..................................................................................................... 87
4. Cliente del Servicio .............................................................................................................. 88
4.1. Clases del Cliente del Servicio................................................................................... 89
4.1.1. CPaginaWeb ....................................................................................................... 89
4.1.2. Clase CPaciente .................................................................................................. 90
4.1.3. Clase CPrueba..................................................................................................... 91
4.1.4. Clase CSerie......................................................................................................... 92
4.1.5. Clase CFichero.................................................................................................... 93
4.1.6. Clase CListado .................................................................................................... 94
4.1.7. Clase CUser ......................................................................................................... 94
Servicio Web para la Gestión de Imágenes Médicas Índice de Contenidos
8
4.2. Configuración del Cliente del Servicio .................................................................... 95
4.3. Herramientas Auxiliares: jpg2dcm........................................................................... 96
Capítulo 4: Instalación y Configuración del Servicio........................................................... 98
1. Introducción .......................................................................................................................... 98
2. Paquetes Necesarios............................................................................................................. 98
3. Instalación en Linux ..........................................................................................................100
3.1. Entorno Java................................................................................................................101
3.2. Apache Tomcat ...........................................................................................................101
3.3. Xampp para Linux (Lampp).....................................................................................103
3.4. PostgreSQL .................................................................................................................105
3.5. Axis2..............................................................................................................................106
3.6. Servicio Web ClinicalImageService .......................................................................107
3.7. CGI´s .............................................................................................................................108
3.8. Cliente Web .................................................................................................................109
4. Instalación en Windows ...................................................................................................109
4.1. Entorno Java................................................................................................................109
4.2. Apache Tomcat ...........................................................................................................110
4.3. Xampp para Windows (Xampp) .............................................................................111
4.4. PostgreSQL .................................................................................................................112
4.5. Axis2..............................................................................................................................113
Servicio Web para la Gestión de Imágenes Médicas Índice de Contenidos
9
4.6. Servicio Web ClinicalImageService .......................................................................114
4.7. CGI´s .............................................................................................................................114
4.8. Cliente Web .................................................................................................................114
5. Configuración del Sistema................................................................................................114
5.1. Configuración de Apache-Tomcat ..........................................................................115
5.2. Configuración de PostgreSQL.................................................................................116
5.3. Configuración de Axis2.............................................................................................118
5.4. Configuración del Cliente Web...............................................................................119
6. Instalación y Configuración de dcm4che ......................................................................119
6.1.1. dcm4che en Axis2 ............................................................................................119
6.1.2. dcm4che en el Cliente Web ...........................................................................120
Capitulo 5: Guía de Usuario.....................................................................................................121
1. Introducción ........................................................................................................................121
2. Acceso a la Aplicación .......................................................................................................121
3. Página Principal..................................................................................................................123
4. Página de Paciente .............................................................................................................125
5. Página de la Prueba............................................................................................................127
6. Página del Fichero .............................................................................................................129
7. Página para Insertar Pacientes........................................................................................131
8. Página para Listar Pacientes ...........................................................................................133
Servicio Web para la Gestión de Imágenes Médicas Índice de Contenidos
10
9. Página para la Administración del Sistema..................................................................133
Capítulo 6: Conclusiones y Trabajo Futuro.........................................................................136
1. Conclusiones tras la Realización del Proyecto ............................................................136
2. Trabajo Futuro ...................................................................................................................138
Capítulo 7: Referencias Bibliográficas ...................................................................................140
1. Referencias ...........................................................................................................................140
Servicio Web para la Gestión de Imágenes Médicas Índice de Figuras
11
Índice de Figuras
Figura 1.1: Esquema con los elementos intervinientes en este proyecto ......................... 20
Figura 2.1: Ejemplo de Funcionamiento de los Servicios Web.......................................... 25
Figura 2.2: IRM de una Rodilla ................................................................................................. 30
Figura 2.3: Formato de un Fichero DICOM .......................................................................... 31
Figura 2.4: DICOM y Modelo de Referencia OSI ................................................................. 32
Figura 2.5: Esquemático Kit de Desarrollo dcm4che ........................................................... 37
Figura 3.1: Escenario Propuesto para el Servicio .................................................................. 48
Figura 3.2: Diagrama Entidad-Relación de la Base de Datos............................................. 51
Figura 3.3: Diagrama de Clases UML de la Base de Datos................................................. 52
Figura 3.4: Página Principal de Axis2...................................................................................... 53
Figura 3.5: Listado de Servicios desplegados en Axis2........................................................ 53
Figura 3.6: Proceso de Conversión de Imagen Digital a Imagen DICOM...................... 97
Figura 4.2: Apache Tomcat Corriendo en Ubuntu 8.04.....................................................103
Figura 4.3: Xampp for Linux Corriendo en Ubuntu 8.04..................................................105
Figura 4.4: Página Principal de Axis2 corriendo en Ubuntu 8.04...................................107
Figura 4.5: Apache Tomcat Corriendo en Windows Xp ...................................................111
Figura 4.6: Xampp for Windows Corriendo en Windows Xp..........................................112
Figura 4.7: Xampp for Windows Corriendo en Windows Xp..........................................113
Servicio Web para la Gestión de Imágenes Médicas Índice de Figuras
12
Figura 4.8: Añadir Servidor de Base de Datos en pgAdmin III .......................................116
Figura 4.9: Añadir un Nuevo Rol de Login en pgAdmin III ............................................117
Figura 4.10: Añadir una Nueva Base de Datos en pgAdmin III ......................................118
Figura 5.1: Cliente Web - Página de Acceso al Sistema.....................................................122
Figura 5.2: Cliente Web - Error de Acceso al Sistema.......................................................122
Figura 5.3: Cliente Web - Sección Principal del Sistema: Listar Pacientes...................123
Figura 5.4: Cliente Web - Sección Principal del Sistema: Insertar Pacientes. ..............124
Figura 5.5: Cliente Web - Sección Principal del Sistema: Buscar Paciente. ..................124
Figura 5.6: Cliente Web - Página de Paciente: Información General.............................125
Figura 5.7: Cliente Web - Página de Paciente: Información General – Editar Ficha .126
Figura 5.8: Cliente Web – Página de Paciente: Pruebas Realizadas ...............................126
Figura 5.9: Cliente Web - Página de la Prueba de un Paciente: Información General.
.........................................................................................................................................................127
Figura 5.10: Cliente Web - Página de la Prueba de un Paciente: Series. .......................128
Figura 5.11: Cliente Web - Página de la Prueba de un Paciente: Opciones de
Visualización.................................................................................................................................128
Figura 5.12: Cliente Web - Página de la Prueba de un Paciente: Diagnósticos ...........129
Figura 5.13: Cliente Web - Página de la Prueba de un Paciente: Observaciones.........129
Figura 5.14: Cliente Web - Página para la visualización de las Imágenes.....................130
Figura 5.15: Cliente Web - Página Visualización de Cabecera de Imágenes DICOM.
.........................................................................................................................................................130
Servicio Web para la Gestión de Imágenes Médicas Índice de Figuras
13
Figura 5.16: Cliente Web - Página para la Inserción de Ficheros DICOM. .................132
Figura 5.17: Cliente Web - Página para la Inserción de Fichas de Pacientes...............132
Figura 5.18: Cliente Web - Página Inserción de Pacientes mediante Imágenes
Digitales ........................................................................................................................................132
Figura 5.19: Cliente Web - Página con el Listado de Pacientes.......................................133
Figura 5.20: Cliente Web - Sección de Administración del Sistema: Listar Usuarios 134
Figura 5.21: Cliente Web - Sección de Administración del Sistema: Insertar Usuarios
.........................................................................................................................................................134
Figura 5.22: Cliente Web - Sección de Administración del Sistema - Listado de
Usuarios.........................................................................................................................................135
Servicio Web para la Gestión de Imágenes Médicas Índice de Tablas
14
Índice de Tablas
Tabla 2.1: Campos Dicom Relacionados con el Estudio Realizado. .................................. 34
Tabla 2.2: Campos Dicom Relacionados con el Paciente. .................................................... 35
Tabla 2.3: Campos Dicom Relacionados con las características técnicas del Estudio
Realizado. ........................................................................................................................................ 35
Tabla 2.4: Campos Dicom Relacionados con las características técnicas del Estudio
Realizado. ........................................................................................................................................ 36
Tabla 2.5: Atributos de la interfaz ClinicalImageAccessComponent................................ 40
Tabla 2.6: Argumentos de la Invocación del método
get_observation_by_qualified_code( ) ..................................................................................... 42
Tabla 2.7: Argumentos de la Invocación del método
get_observation_by_qualified_code( ) ..................................................................................... 43
Tabla 2.8: Argumentos de la Invocación del método get_images( ). ................................ 43
Tabla 2.9: Valores de code dentro del métdo get_image( ). ................................................ 44
Tabla 2.10: Valores tipicos de qualifier dentro del métdo get_image( ). .......................... 44
Tabla 2.11: Conjunto de argumentos del método get_overlays ( ). ................................... 44
Tabla 2.12: Conjunto de argumentos del método get_graphs ( )....................................... 45
Tabla 2.14: Valores Típicos del argumento qualifiers dentro del método get_graphs ( ).
........................................................................................................................................................... 45
Tabla 2.15: Conjunto de argumentos del método get_raw_images ( ). ............................ 46
Tabla 2.16: Valores Típicos del argmuento qualifiers dentro del método
get_raw_images ( )........................................................................................................................ 46
Servicio Web para la Gestión de Imágenes Médicas Índice de Tablas
15
Tabla 2.17: Atributos de la Interfaz ObservationLoader según CIAS.............................. 47
Tabla 3.1: Atributos del método load_image() del Servicio ClinicalImageService. ....... 58
Tabla 3.2: Valores de los parámetros code y qualifier del método
get_observation_by_qualified_code() del Servicio ClnicaImageService . ....................... 60
Tabla 3.3: Valores del parámetro politicies según CIAS en el Servicio
ClinicalImageService. ................................................................................................................... 61
Tabla 3.4: Atributos del método get_observation_by_qualified_code() del Servicio
ClinicalImageService. ................................................................................................................... 62
Tabla 3.5: Valores de los parámetros code del método get_image() del Servicio
ClnicaImageService . .................................................................................................................... 63
Tabla 3.6: Valores de los campos del parámetro qualifier del método get_image() del
Servicio ClnicaImageService . .................................................................................................... 63
Tabla 3.7: Atributos del método get_image() del Servicio ClinicalImageService.......... 65
Tabla 3.8: Atributos del método CheckUser()del Servicio ClinicalImageService. ......... 67
Tabla 3.9: Atributos del método InsertUser() del Servicio ClinicalImageService. ........ 68
Tabla 3.10: Atributos del método UpdatetUser() del Servicio ClinicalImageService... 69
Tabla 3.11: Atributos del método ContNumberOfUser() del Servicio
ClinicalImageService. ................................................................................................................... 69
Tabla 3.12: Atributos del método GetRowOfUser() del Servicio ClinicalImageService.
........................................................................................................................................................... 70
Tabla 3.13: Atributos del método InsertPatient() del Servicio ClinicalImageService. . 71
Tabla 3.14: Atributos del método GetRowOfPatient() del Servicio
ClinicalImageService. ................................................................................................................... 72
Servicio Web para la Gestión de Imágenes Médicas Índice de Tablas
16
Tabla 3.15: Atributos del método ViewPatientByID() del Servicio
ClinicalImageService. ................................................................................................................... 73
Tabla 3.16: Atributos del método ContNumberOfPatient() del Servicio
ClinicalImageService. ................................................................................................................... 73
Tabla 3.17: Atributos del método UpdatetPatient() del Servicio ClinicalImageService.
........................................................................................................................................................... 74
Tabla 3.18: Atributos del método ShearchTestByID() del Servicio
ClinicalImageService. ................................................................................................................... 75
Tabla 3.19: Atributos del método ShearchTestByTUID() del Servicio
ClinicalImageService. ................................................................................................................... 76
Tabla 3.20: Atributos del método ShearchSequenceByTUID() del Servicio
ClinicalImageService. ................................................................................................................... 76
Tabla 3.21: Atributos del método ShearchSequenceBySUID() del Servicio
ClinicalImageService. ................................................................................................................... 77
Tabla 3.22: Atributos del método SearchDiagnosticByTUID() del Servicio
ClinicalImageService. ................................................................................................................... 78
Tabla 3.23: Atributos del método InsertDiagnostic() del Servicio ClinicalImageService.
........................................................................................................................................................... 79
Tabla 3.24: Atributos del método SearchDiagnosticByTUID() del Servicio
ClinicalImageService. ................................................................................................................... 80
Tabla 3.25: Atributos del método InsertRemarks() del Servicio ClinicalImageService.
........................................................................................................................................................... 81
Tabla 3.26: Atributos del método SearchFilesBySUID() del Servicio
ClinicalImageService. ................................................................................................................... 82
Servicio Web para la Gestión de Imágenes Médicas Índice de Tablas
17
Tabla 3.27: Atributos del método SearchFilesByName() del Servicio
ClinicalImageService. ................................................................................................................... 82
Tabla 4. 1: Conjunto de CGI´s Utilizados por ClincalImageService ..............................108
Servicio Web para la Gestión de Imágenes Médicas Capítulo 1
18
Capítulo 1:
Introducción
1. Motivación del Proyecto
En este primer punto se intentará dar una visión general de la problemática existente
en temas relacionados con imágenes médicas, en definitiva se trata de mostrar cómo
surge la idea de este proyecto.
Actualmente en los centros hospitalarios existe infinidad de maquinaria de adquisición
de imágenes, ejemplos de las cuales pueden ser máquinas de radiografías
computerizadas (RC), resonancias magnéticas (RM), tomografías, gammagrafías, etc.
Todas estas máquinas de adquisición de imágenes clínicas suelen implementar el
estándar DICOM e incorporar un software instalado en un computador que permite la
administración de los diferentes estudios realizados a pacientes. El problema de todo
esto es que normalmente tanto software como “maquinaria” son propietarios, con lo
que estos sistemas presentan serios problemas de escalabilidad e interoperatividad, es
decir, cada “máquina” viene con su software.
Por otro lado este escenario, normalmente es totalmente centralizado, es decir, cada
máquina de adquisición de imágenes médicas, por ejemplo una máquina de resonancia
o un PET, suele venir acompañada por un computador de gran capacidad (tanto de
almacenamiento como de procesado) el cuál será el encargado de recibir las capturas
tomadas por dicha maquinaria, esto podría plantear serios problemas a largo plazo ya
que aunque se trate de un computador de gran capacidad como se ha dicho, éste tendrá
una capacidad de almacenamiento finita por ello pueden surgir serios problemas
cuando el número de estudios realizados sea muy elevado.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 1
19
Otro problema es que en algunos servicios o departamentos se utilizan soluciones de
diagnóstico por imagen que no siguen un protocolo ni están estandarizadas. Estos
servicios o departamentos usualmente no tienen una maquinaria específica de captura
de imágenes para apoyarse en ellas a la hora de realizar un diagnóstico por ello se
apoyan en otras técnicas no estandarizadas como pueden ser capturas de imágenes
tomadas con una cámara digital.
En este proyecto se implementa un servicio con una interfaz abierta para poder
incluirlo en un esquema de computación distribuida y que además de gestionar y
administrar imágenes DICOM generadas por una maquinaria específica de adquisición
de imagen clínica, pueda generar ficheros DICOM a partir de imágenes digitales.
2. Objetivos del Proyecto
El objetivo de este Proyecto es el diseño e implementación de un Sistema de Gestión
de Imágenes Médicas con una interfaz abierta que permita la incorporación a n sistema
distribuido, para ello se partirá en un proyecto anterior [1] que consistía en el diseño e
implementación de un Servidor de Imágenes siguiendo el Estándar DICOM [2]
(Digital Imaging and Communications in Medicine) para el tratamiento y
almacenamiento de imágenes médicas, abriendo la interfaz del mismo para su posible
utilización en un marco de computación distribuida. Dentro del ámbito de la
computación distribuida la opción adoptada ha sido la implementación del Servicio
como un Servicio Web [3]. Además del diseño e implementación del servicio como
servicio Web se diseñará un cliente con interfaz de usuario basada en página Web.
Para el desarrollo de este proyecto se considerarán dos partes bien diferenciadas. Por
un lado el desarrollo del Servicio propiamente dicho y por otro lado el desarrollo de un
cliente con interfaz de usuario (GUI) que permitirá acceder y gestionar la información
recogida por el Servicio.
El objetivo del estándar DICOM es facilitar la interoperatividad de los equipos de
imágenes médicas especificando para ello un conjunto de protocolos que deben seguir
Servicio Web para la Gestión de Imágenes Médicas Capítulo 1
20
los equipos, junto con la sintaxis y semántica de los comandos e información asociada
que puede ser intercambiada mediante estos protocolos.
Por otra parte, el servicio, como ya se ha comentado será implementado como un
Servicio Web [3]. Para ello se codificará una Clase Java [9] que implemente cada uno
de los métodos que compondrán el servicio (en el capítulo correspondiente se entrará
en los detalles de cada uno de los métodos). Esta clase Java será desplegada como
Servicio Web dentro de Axis 2 [4], de modo que toda la parte correspondiente al
Servicio quede corriendo sobre el servidor de aplicaciones Apache Tomcat [5].
Respecto al cliente, se van a diseñar una serie de páginas WEB, utilizando el lenguaje
de script PHP [10] (PHP: Hypertext Preprocessor), que nos van a permitir acceder a
toda la información recogida por el sistema como; fichas de pacientes, pruebas
realizadas, y las distintas imágenes médicas obtenidas. Esta interfaz WEB tendrá a su
vez una interfaz SOAP [3] para poder comunicarnos con el Servicio, esto se
conseguirá haciendo uso de unas librerías que proporcionan una interfaz SOAP a
aplicaciones Web, esta librería es NuSOAP [11]. Por lo tanto se trata de un cliente
web con interfaz SOAP.
Aunque ambas partes están bien diferenciadas entre sí es necesario un nexo común
entre ambas, ya que es necesario que puedan comunicarse entre ellas y compartir la
información disponible. De esto se encarga el Sistema de Base de Datos. Para este
Proyecto se ha optado por el gestor PostgreSQL [8], dadas las buenas características
que presenta. Se podrían haber utilizado otros gestores, como MySQL o similar.
A continuación se muestra un esquema con los elementos involucrados en este
proyecto:
Figura 1.1: Esquema con los elementos intervinientes en este proyecto
Tomcat
Axis2
Internet/
LAN Aplicación
Cliente
BD
ClinicalImageService
Servicio Web para la Gestión de Imágenes Médicas Capítulo 1
21
3. Plan de Trabajo
Para el desarrollo de este Proyecto se siguió el siguiente proceso:
� Análisis y elección de estándares y recomendaciones relacionados con el tema
del trabajo.
� Estudio y elección de las tecnologías involucradas en la realización del servicio.
� Definición de las interfaces del servicio.
� Aprendizaje de Sistemas de Bases de Datos. Estudio de los distintos modelos y
sistemas.
� Codificación del servidor.
� Aprendizaje de HTML [3] y PHP para el desarrollo de la interfaz WEB del
sistema con los usuarios.
� Desarrollo del cliente
� Verificación y prueba del sistema.
� Redacción de la memoria del proyecto.
4. Medios Materiales
Para el desarrollo de este proyecto se ha contado con los siguientes medios:
� PC compatible con sistemas operativos Windows XP Professional y Linux.
� Servidores Apache-Tomcat [6] y Xampp (Win32) [7] o Lampp (Linux) [7].
� Máquina Virtual Java [9].
� Entorno Perl
� Acceso a Internet.
� Diversa documentación sobre DICOM, Bases de Datos, HTML, PHP, Java, etc.
� Diverso material fungible.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 1
22
5. Organización de la Memoria
A continuación se especifica brevemente como se ha estructurado la Memoria de este
Proyecto.
En el Capítulo 1 se presenta la introducción al Proyecto, donde se exponen la
motivación del mismo, los objetivos, el plan de trabajo que se ha seguido para llevarlo a
cabo y los recursos que han sido necesarios para ello.
En el Capítulo 2, se expone el estado del arte de las diferentes tecnologías, estándares y
recomendaciones utilizadas para cumplir los requisitos que define el proyecto. Así, en
este capítulo se tratan temas relacionados con los servicios web, qué plataformas se han
elegido, qué estándares se han utilizado en las comunicaciones, etc. Y por otro lado se
habla del estándar DICOM en general y qué aspectos se han utilizado del mismo en
este proyecto. Por último se realizará un repaso de la recomendación CIAS para
CORBA, que describe cómo debe ser accedida una imagen médica de forma remota en
una plataforma CORBA. Aunque en este proyecto no se puede aplicar esta
especificación tal cual lo dice la norma si se adaptará lo más posible.
En tercer lugar, en el Capítulo 3, se describe el Servicio Web para la Gestión de
Imágenes Médicas implementado, esto es, se detalla el conjunto de métodos y
operaciones que se definen en el mismo y cómo deben ser invocados. Por otro lado
también se habla de la aplicación web cliente de pruebas, de cómo mediante las librerías
NuSOAP se consigue comunicar con el servicio implementado. También se describirán
el conjunto de clases implementadas en PHP para dar funcionalidad al cliente.
Una vez explicado el servicio, el Capítulo 4 sirve como guía de instalación y
configuración del mismo. Se describen todos los paquetes necesarios para que el
servicio funcione correctamente, además de indicar cómo deben ser instalados y
configurados.
En el siguiente capítulo, el Capítulo 5, se muestra una guía de usuario de la aplicación
web cliente. En este capítulo ya no se tratarán temas tan técnicos como en el capítulo 3
sino que será una guía paso a paso del uso del cliente.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 1
23
A continuación, el Capítulo 6 muestra las conclusiones y algunas cuestiones
relacionadas con posibles líneas futuras en el ámbito de este proyecto.
Por último, el Capítulo 7, contendrá la bibliografía empleada para la elaboración de
este proyecto.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
24
Capítulo 2:
Estado del Arte
1. Introducción
En este capítulo se va realizar una introducción a todas las tecnologías, estándares y
recomendaciones involucradas en el desarrollo de este proyecto.
En primer lugar se hablará sobre los Servicios Web (Web Services). Se intentará
explicar qué son y cómo funcionan y por otro lado se intentará justificar el uso de los
mismos en este proyecto frente a otras tecnologías existentes.
Una vez concluida la revisión de los servicios web, se dará paso a una revisión de los
diferentes estándares que se han tenido en cuenta en este proyecto. Por un lado el
estándar DICOM para imágenes médicas y por otro lado la recomendación CIAS para
el acceso a imagen médica de forma remota. Y, al igual que con los servicios web, se
intentará justificar el uso de estos estándares y recomendaciones frente a otros que
puedan existir.
2. Servicios Web
La tecnología de servicios web (en inglés Web Services) proporciona un conjunto de
protocolos y estándares que sirven para intercambiar datos entre aplicaciones
siguiendo el modelo cliente/servidor. Tanto clientes como servidores pueden estar
desarrollados en lenguajes de programación diferentes, y ser ejecutados sobre
cualquier plataforma. La interoperatividad se consigue mediante la adopción de
estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
25
la arquitectura y reglamentación de los servicios Web. Para mejorar la
interoperatividad entre las distintas plataformas de servicios Web se ha creado el
organismo WS-I, encargado de desarrollar diversos perfiles para definir de manera
más exhaustiva estos estándares.
Figura 2.1: Ejemplo de Funcionamiento de los Servicios Web
La principal razón para usar servicios Web es que se basan en HTTP sobre TCP
(Transmission Control Protocol) usualmente en el puerto 80. Dado que las
organizaciones protegen sus redes mediante firewalls que filtran y bloquean gran parte
del tráfico de Internet, cierran casi todos los puertos TCP salvo el 80, que es,
precisamente, el que usan los navegadores. Los servicios Web suelen utilizar este
puerto, por la simple razón de que no resultan bloqueados. Aunque cualquier otro
puerto es configurable.
Otra razón es que, antes de que existiera SOAP, no había buenas interfaces para
acceder a las prestaciones o funcionalidades ofrecidas por otros ordenadores o equipos
en red. Las que había eran ad-hoc y poco conocidas, tales como EDI (Electronic Data
Interchange), RPC (Remote Procedure Call), u otras.
Una tercera razón por la que los servicios Web son muy prácticos es que pueden
aportar gran independencia entre la aplicación que usa el servicio Web y el propio
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
26
servicio siempre y cuando se respete la interfaz. De esta forma, los cambios a lo largo
del tiempo en uno no deben afectar al otro. Esta flexibilidad será cada vez más
importante, dado que la tendencia a construir grandes aplicaciones a partir de
componentes distribuidos más pequeños es cada día mayor.
Se espera que para los próximos años mejoren la calidad y cantidad de servicios
ofrecidos basados estos estándares.
2.1. Estándares Empleados
Tal y como se ha indicado anteriormente los servicios web involucran una serie de
estándares abiertos que permiten el correcto funcionamiento de los mismos. A
continuación se recogen algunos de los más importantes:
• Web Services Protocol Stack: Así se denomina al conjunto de servicios y
protocolos de los servicios Web.
• XML (Extensible Markup Language): Es el formato estándar para los datos
que se vayan a intercambiar.
• SOAP (Simple Object Access Protocol) o XML-RPC (XML Remote Procedure
Call): Protocolos sobre los que se establece el intercambio de datos. Pero
además los datos en XML también pueden enviarse de una aplicación a otra
sobre otros protocolos usuales en el mundo de Internet como son HTTP
(Hypertext Transfer Protocol), FTP (File Transfer Protocol), o SMTP (Simple
Mail Transfer Protocol).
• WSDL (Web Services Description Languages): Es el lenguaje de descripción
del Servicios Web. Es una descripción basada en XML de los requisitos
funcionales necesarios para establecer una comunicación con un Servicio Web.
• UDDI (Universal Description, Discovery and Integration): Protocolo para
publicar la información de los servicios Web. Permite publicar y comprobar qué
servicios web están disponibles.
• WS-Security (Web Service Security): Protocolo de seguridad aceptado como
estándar por OASIS (Organization for the Advancement of Structured
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
27
Information Standards). Garantiza la autenticación de los actores y la
confidencialidad de los mensajes enviados.
2.2. Ventajas e Inconvenientes del uso de Servicios Web
En el caso que nos ocupa, el uso de servicios web, se tienen una serie de ventajas e
inconvenientes que a continuación se detalla.
En relación con las ventajas podemos decir que:
• Aportan interoperatividad entre aplicaciones de software independientemente
de sus propiedades o de las plataformas sobre las que se instalen.
• Los servicios Web fomentan los estándares y protocolos basados en texto, que
hacen más fácil acceder a su contenido y entender su funcionamiento.
• Al apoyarse en HTTP, los mensajes pueden atravesar los sistemas de seguridad
firewall sin necesidad de cambiar las reglas de filtrado.
• Permiten que servicios y software de diferentes compañías ubicadas en
diferentes lugares geográficos puedan ser combinados fácilmente para proveer
servicios integrados.
• Permiten la interoperatividad entre plataformas de distintos fabricantes por
medio de protocolos estándar y abiertos. Las especificaciones son gestionadas
por una organización abierta, la W3C, por tanto no hay secretismos por
intereses particulares de fabricantes concretos y se garantiza la plena
interoperatividad entre aplicaciones.
Pero, como no podía ser de otra forma, el uso de servicios web también tienen una serie
de inconvenientes que es preciso conocer y tener en cuenta a la hora de plantearse el
uso de los mismos:
• Para realizar transacciones no pueden compararse en su grado de desarrollo
con otros estándares abiertos de computación distribuida como CORBA
(Common Object Request Broker Architecture).
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
28
• Su rendimiento es bajo si se compara con otros modelos de computación
distribuida, tales como RMI (Remote Method Invocation), CORBA, o DCOM
(Distributed Component Object Model). Es uno de los inconvenientes
derivados de adoptar un formato basado en texto.
• Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en
firewall cuyas reglas tratan de bloquear o auditar la comunicación entre
programas a ambos lados de la barrera.
Por tanto, dependiendo de la finalidad será conveniente el uso de servicios web o bien
será más conveniente pensar en otra tecnología.
2.3. Plataformas
Como ya se dijo en la introducción de esta sección, el uso de los servicios web permite
que distintas aplicaciones de software desarrolladas en lenguajes de programación
diferentes, y ejecutadas sobre cualquier plataforma, puedan utilizar los servicios web
para intercambiar datos en redes de ordenadores como Internet. Ya se ha comentando
como se consigue esto, pero todavía no se ha dicho nada a cerca de en qué plataformas
se puede hacer uso de los servicios web. Por ello, a continuación se muestra una lista
con las plataformas que actualmente hacen las labores de servidores de aplicaciones
para servicios web:
• JBoss servidor de aplicaciones J2EE Open Source de Red Hat inc.
• Oracle Fusion Middleware
• IBM Lotus Domino a partir de la versión 7.0
• Axis y el servidor Jakarta Tomcat (de Apache)
• ColdFusion MX de Macromedia
• Java Web Services Development Pack (JWSDP) de Sun Microsystems (basado
en Jakarta Tomcat) y JOnAS (parte de ObjectWeb una iniciativa de código
abierto)
• Microsoft .NET
• Novell exteNd (basado en la plataforma J2EE)
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
29
• WebLogic
• WebSphere
• Zope es un servidor de aplicaciones Web orientado a objetos desarrollado en el
lenguaje de programación Python
• VERASTREAM de AttachmateWRQ para modernizar o integrar aplicaciones
host IBM y VT
• NuSOAP
Como se puede observar existen gran cantidad de plataformas que permiten el uso de
servicios web. En el caso que ocupa a este proyecto se ha elegido la plataforma Axis2
sobre el servidor de aplicaciones Apache Tomcat como servidor y como cliente, un
cliente web basado en PHP y las librerías NuSOAP.
La elección de las plataformas anteriores no ha sido al azar si no que se han elegido en
base a una serie de criterios de funcionalidad, eficiencia y compatibilidad. En el caso del
cliente de pruebas, se ha elegido un cliente que no se basara también en las librerías de
Axis2, para demostrar la interoperatividad basada en servicios web, además se ha
elegido un cliente web para lograr la independencia del sistema operativo en el que se
ejecute el cliente. En relación al servidor, se puede decir que Axis2 es un motor básico
para Servicios Web que tiene implementaciones disponibles en Java y C, además no
sólo ofrece la capacidad de agregar interfaces de servicios Web a aplicaciones web, si
no que también puede funcionar como una aplicación servidor. Esto último, y que está
disponible en Java, son algunas de las características más importantes por las cuales se
ha elegido esa plataforma para el servidor y no otra. De todas formas, en capítulos
posteriores, se podrá comprobar mejor que esas características son las que mejor se
adaptan a las necesidades de este proyecto.
3. Estándar DICOM
DICOM (Digital Imaging and Communication in Medicine) es el estándar reconocido
mundialmente para el intercambio de imágenes médicas, pensado para el manejo,
almacenamiento, impresión y transmisión de imágenes médicas. Incluye la definición
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
30
de un formato de fichero y de un protocolo de comunicación de red. El protocolo de
comunicación es un protocolo de aplicación que usa TCP/IP para la comunicación
entre sistemas. Los ficheros DICOM pueden intercambiarse entre dos entidades que
tengan capacidad de recibir imágenes y datos en formato DICOM.
DICOM permite la integración de escáneres, servidores, estaciones de trabajo,
impresoras y hardware de red de múltiples proveedores dentro de un sistema de
almacenamiento y comunicación de imágenes. Las diferentes máquinas, servidores y
estaciones de trabajo tienen una declaración de conformidad DICOM (conformance
statements) que establece claramente las clases DICOM que soportan. DICOM ha sido
adoptado ampliamente por hospitales y está haciendo incursión en pequeñas
aplicaciones de consultas de dentistas y de diversas especialidades médicas.
El primer estándar DICOM importante es la versión 3.0, que fue desarrollado en 1993.
Detalles de la especificación DICOM están disponibles en la web del National
Electrical Manufacturers Association (NEMA), y existen muchas implementaciones de
código abierto y de dominio público. Un ejemplo de imagen dicom se muestra en la
siguiente figura:
Figura 2.2: IRM de una Rodilla
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
31
3.1. Formato de Datos DICOM
Independientemente del uso, siempre se utiliza el mismo formato. Un fichero DICOM
se diferencia de otros ficheros de datos en que agrupa la información (imagen y datos
asociados a ella) dentro de un conjunto normalizado de datos. De manera que la
imagen no puede ser separada por error de su información asociada.
Figura 2.3: Formato de un Fichero DICOM
Los ficheros DICOM consisten en una cabecera con campos estandarizados y un
cuerpo con datos de imagen. Un objeto DICOM simple puede contener solamente una
imagen, pero esta imagen puede tener múltiples "fotogramas" (frames), permitiendo el
almacenamiento de escenas de cine o cualquier otro fichero con varios fotogramas. Los
datos de imagen pueden estar comprimidos usando gran variedad de estándares,
incluidos JPEG, JPEG Lossless, JPEG 2000, LZW y Run-length encoding (RLE).
3.2. Servicios DICOM
DICOM tiene un conjunto muy amplio de servicios, la mayoría de los cuales implica
transmisión de datos sobre la red, y el formato de fichero en que se sustenta es en
realidad una ampliación posterior y de menor importancia del estándar.
Instancia
SOP
Registro de
Datos
Meta
Info.
Registro de
Datos
Codificación
Encapsulación
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
32
El esquema que define DICOM, en el ámbito del modelo OSI, es el que se muestra en
la siguiente figura:
Figura 2.4: DICOM y Modelo de Referencia OSI
Una vez mostrada la torre de “protocolos” que define DICOM, se pueden ver y
comprender mejor algunos de los servicios existentes:
• Dicom Store: El servicio DICOM Store es usado para mandar imágenes u otros
objetos persistentes (informes estructurados, etc.) a un PACS (Picture
Archiving and Comunication System) o a una estación de trabajo (Store SCU).
• Storage Commitment: El servicio DICOM storage commitment es usado para
confirmar que una imagen ha sido almacenada permanentemente por un
dispositivo. El usuario de la clase de servicio (modalidad, estación de trabajo,
etc.) utiliza la confirmación de la clase de servicio proveedor (estación de
almacenamiento) para asegurarse de que puede borrar la imagen localmente.
• Query/Retrieve: Permite a una estación de trabajo hacer búsquedas de
imágenes en un PACS y recuperarlas.
• Dicom Worklist: Permite a un equipo de imagen que incluya esta funcionalidad
leer la "Lista de Pacientes citados", obtener detalles de los pacientes y
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
33
exámenes médicos solicitados electrónicamente, evitando la necesidad de
introducir esa información varias veces y sus consiguientes errores.
• Modality Performed Procedure Step: Un servicio complementario al DICOM
Worklist, que permite mandar un informe sobre los exámenes médicos
realizados incluyendo datos sobre las imágenes adquiridas, las dosis
dispensadas, etc. Consta de tres estados:
� En progreso: significa que la realización del estudio ha comenzado.
� Terminado: significa que la realización del estudio fue terminada
satisfactoriamente.
� Descontinuado: significa que la realización del estudio fue cancelada o no pudo
ser terminada.
• DicomPrint: Este servicio es usado para mandar imágenes a una impresora
DICOM, normalmente para imprimir una placa de rayos-x. Hay una calibración
estándar (definida en la parte 14 de DICOM) para ayudar a asegurar la
consistencia entre distintos dispositivos de pantalla.
• Ficheros DICOM: Los ficheros DICOM corresponden a la parte 10 del
estándar DICOM. Describe cómo almacenar información de imágenes médicas
en un medio extraíble. Generalmente es obligatorio incluir también los
metadatos de la imagen. DICOM restringe los nombre de los ficheros a
nombres de 8 caracteres (mucha gente utiliza erróneamente 8.3, pero esto no es
legal). Del nombre del fichero no debe de extraerse ninguna información. Ésta
es una fuente común de problemas con contenidos creados por desarrolladores
que no han leído la especificación cuidadosamente. Éste es un requisito
histórico para mantener compatibilidad con antiguos sistemas existentes.
También es obligatoria la presencia de un directorio de contenido, el fichero
DICOMDIR, que proporciona un índice e información de resumen para cada
uno de los ficheros DICOM. La información del DICOMDIR proporciona
substancialmente más información sobre cada fichero que los nombres de los
mismos, de manera que hay menos necesidad de nombres de fichero con
significado.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
34
Como vemos DICOM tiene gran cantidad de servicios mediante los cuales se pueden
realizar numerosas operaciones. Pero en el caso que ocupa a este proyecto no se usarán
estos servicios para enviar imágenes, recibirlas o almacenarlas. Lo que se hará será
implementar las interfaces de CIAS usando, tal y como se dijo en el punto dos de este
capitulo, los servicios web, es decir usar el protocolo de comunicaciones SOAP para
transportar los datos, en los cuales también se pueden incluir ficheros. Una vez
recibido el fichero DICOM se extraer la información que contiene para poder
desplegarla en la base de datos, y a continuación almacenar también el fichero. Por lo
que del estándar DICOM solo se usará la estructura de la cabecera de los ficheros.
3.3. Metadatos de la cabecera DICOM
Este punto pretende servir de resumen de los campos de información que existen en la
cabecera de un fichero DICOM, aunque no es obligatorio que existan todos en un
mismo fichero.
A continuación se muestran algunos de los grupos de códigos DICOM en los cuales se
señalan algunos de los códigos que se han usado en este proyecto:
• Grupo del 0008,0001 al 0008,9460: Este grupo recoge información relativa al
estudio que se ha realizado. Algunos de esos campos son:
Código Descripción 0008,0020 Fecha del Estudio 0008,0022 Fecha de Adquisición 0008,0030 Hora del Estudio 0008,0032 Hora de Adquisición 0008,0080 Nombre de la Institución 0008,0090 Nombre del Médico 0008,1030 Descripción del Estudio 0008,1080 Descripción del Diagnostico 0008,0060 Modalidad de Adquisición
Etc..
Tabla 2.1: Campos Dicom Relacionados con el Estudio Realizado.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
35
• Grupo del 0010,0010 al 0010,9431: Este grupo de campos contienen
información relativa al paciente. A continuación se muestran algunos de esos
campos:
Código Descripción 0010,0010 Nombre del Paciente 0010,0020 Identificador del Paciente 0010,0030 Fecha de Nacimiento del Paciente 0010,0040 Sexo del Paciente 0010,1010 Edad del Paciente 0010,2000 Alertas Médicas 0010,2110 Alergias 0010,21B0 Historia Médica Adicional del Paciente 0010,4000 Comentarios del Paciente.
Etc..
Tabla 2.2: Campos Dicom Relacionados con el Paciente.
• Grupo del 0020,000D al 0020,9536: Este grupo de códigos contienen
información relacionada también con el estudio, aunque no como en el caso
anterior, sino con las características técnicas del estudio realizado.
Código Descripción 0020,000D Identificador de la Instancia del Estudio 0020,0010 Identificador del Estudio 0020,0011 Número de Series
Etc..
Tabla 2.3: Campos Dicom Relacionados con las características técnicas del Estudio Realizado.
• Grupo del 0028,0002 al 0028,9537: Este grupo de códigos contienen
información relacionada con las características de la imagen. A continuación se
muestran algunos de los que se han usado en este proyecto:
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
36
Código Descripción 0028,0008 Numero de Frames 0028,0010 Alto de la imagen en Pixeles 0028,0011 Ancho de la imagen en Pixeles
Etc..
Tabla 2.4: Campos Dicom Relacionados con las características técnicas del Estudio Realizado.
Existen muchos grupos y campos más, aunque no se han listado todos, ya que con los
expuestos ha sido suficiente para cubrir las necesidades del proyecto. Si se quiere más
información se puede consulta la bibliografía donde existe una referencia a un
documento en el cual se listan la totalidad de campos que pueden existir en un fichero
DICOM [2].
3.4. Implementaciones Software DICOM: Librería DCM4CHE
Esta sección se dedicará a explicar el funcionamiento de una de las herramientas más
importantes utilizadas en este proyecto, las librerías dcm4che. Por otro lado también se
comentarán los aspectos de configuración de las mismas para conseguir el correcto
funcionamiento, dentro de este proyecto.
3.4.1. Paquete de Librerías dcm4che
El kit de desarrollo dcm4che es una colección de aplicaciones y utilidades de código
abierto para trabajar con el estándar DICOM. Estas aplicaciones se han desarrollado
en el lenguaje de programación Java, lo cual proporciona importantes beneficios, sobre
todo de portabilidad. Estas librerías se apoyan sobre JDK 1.4 o superior.
El núcleo del proyecto dcm4che es una sólida aplicación de la norma DICOM. La
librería de desarrollo dcm4che-1.x se ha utilizado en gran cantidad aplicaciones
relacionadas con DICOM en todo el mundo en los últimos años, además la versión
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
37
actual (2.x) fue un rediseño de la versión 1.x para conseguir un mejor rendimiento y
una mayor flexibilidad.
Por otro lado dentro del proyecto dcm4che también se puede encontrar la librería
dcm4chee (la “e” extra proviene de empresa en inglés). Las librerías dcm4chee
proporcionan capacidades de administrador de Imágenes o archivo de imágenes de
acuerdo con el IHE. Dicha librería proporciona las interfaces de servicios que se
requieren para proporcionar el almacenamiento, la recuperación, y el flujo de trabajo a
un entorno sanitario. El paquete dcm4chee es pre-empaquetado y debe ser instalado en
un servidor de aplicaciones JBoss lo cual proporciona beneficios extras a las
aplicaciones en relación a la robustez y la escalabilidad.
3.4.2. Desarrollo de Aplicaciones Utilizando Dcm4che2
A continuación se muestra un esquema que servirá de ilustración para mostrar el
abanico de posibilidades que ofrece este paquete de desarrollo:
Figura 2.5: Esquemático Kit de Desarrollo dcm4che
Como se muestra en la figura este paquete de desarrollo permite una gran variedad de
posibilidades a la hora de trabajar con imágenes DICOM, por todo ello ha sido elegida
Kit de Desarrollo
DICOM
Trabajo con Ficheros
DICOM
Operaciones de Red
DICOM
Leer
Ficheros
Escribir Ficheros
Manipular
Cabeceras
Transformar
Ficheros
Todo el estándar
DICOM
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
38
como una de las herramientas que incorpora este proyecto, ya que como se comprueba
se adapta fácilmente a los requisitos planteados.
3.4.3. Utilidades Stand-Alone
Como ya se había comentado anteriormente dcm4che2 contiene una serie de utilidades
o aplicaciones de ejemplo que pueden utilizarse para operar con objetos (ficheros)
DICOM de forma independiente. Estas utilidades son funcionales por sí mismas, y el
código fuente de las mismas puede ser muy útil si se está interesado en escribir
aplicaciones DICOM. El conjunto de herramientas incluidas en la versión 2.x de Kit de
desarrollo dcm4che son:
• dcm2txt - Convierte un Objeto DICOM a texto
• dcm2xml- Convierte un Objeto DICOM a XML
• dcmdir - Manipula un directorio DICOM
• dcmecho - Inicia un comando C-ECHO como un SCU (Service Class User)
• dcmgpwl - Consulta de propósito general Worklist SCP (Service Class
Provider)
• dcmmwl - Modalidad de una consulta Worklist SCP
• dcmof - Simular una solicitud de Orden de relleno
• dcmqr - Realizar operaciones C-FIND y C-MOVE como una SCU
• dcmrcv – Receptor DICOM (C-STORE SCP)
• dcmsnd – Realizar la operación C-STORE como un SCU
• dcmwado – Inicia una petición DICOM WADO
• jpg2dcm – Convierte una imagen JPEG a DICOM
• logger – Pasa de Log files a un destino Syslog
• mkelmdic – Crear el Diccionario de serie dcm4che2 DICOM
• mkuiddic – Crea el diccionario UID dcm4che2
• mkvrmap – Crea el mapeado VR dcm4che2
• pdf2dcm – Convierte un documento PDF a DICOM
• rgb2ybr – Convierte los datos de píxeles YBR a formato RGB
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
39
• txt2dcmsr - Convierte texto en un Informe estructurado DICOM
• xml2dcm – Convierte de XML a DICOM
Se comprueba pues que este kit de desarrollo contiene herramientas que son en su
mayoría útiles en el ámbito de aplicación de este proyecto. Lo cual se convierte en otra
razón por la cual se justifica el uso de este kit de desarrollo.
4. Especificación CIAS
El presente punto de este capítulo pretende mostrar el conjunto de interfaces de acceso
a imágenes médicas que se definen en la especificación de CIAS (Clinical Image Access
Service Specification) para CORBA. Se mostrarán las diferentes interfaces de acceso y el
conjunto de parámetros que definen cada una de ellas. En este proyecto no se aplicará
esta recomendación tal cual, por motivos de incompatibilidad entre tecnologías, pero se
intentara adaptar las interfaces que en ella se definen, aunque no todas, ya que algunas
de ellas se salen de la funcionalidad que se pretende dar al servicio.
En CIAS se distinguen 3 interfaces:
• ClinicalImageAccessComponent Interface.
• ImageAccess Interface.
• ObservationLoader Interface.
En lo que sigue entraremos en detalle en cada una de ellas.
4.1. ClinicalImageAccessComponent Interface
A continuación se muestra la definición de esta interfaz:
interface ClinicalImageAccessComponent { readonly attribute string XML_enabled; readonly attribute boolean is_corba_messaging_suppo rted;
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
40
readonly attribute ConsumerAccess consumer_access; readonly attribute SupplierAccess supplier_access; readonly attribute ImageAccess image_access; readonly attribute ObservationLoader observation_lo ader;
};
ClinicalImageAccessComponent es la superclase de todos los componentes.
Permite el descubrimiento de los servicios que un determinado componente puede
utilizar, en forma de referencias para los servicios pertinentes. Los atributos pueden ser
nulos, lo que indica que o bien no son soportados o son de origen desconocido.
A continuación mostramos una breve explicación de cada uno de los atributos que se
incluyen dentro de esta interfaz.
Atributo Descripción
XML_enabled
Indica que el servidor puede manejar XML codificando el valor del atributo dentro de una estructura ObservationDataStruct . La cadena debe ser "verdadera” o “falsa", seguido de la versión XML.
is_corba_messaging _supported
Indica si el servidor soporta el servicio de mensajería CORBA. Su valor puede ser "verdadero" o "falso".
consumer_access Referencia al servicio ConsumerAccess si se implementan en el servidor.
image_access Referencia al servicio ImageAccess si se implementan en el servidor.
observation_loader Referencia al servicio ObservationLoader si se implementan en el servidor.
supplier_access Referencia al servicio SupplierAccess si se implementan en el servidor.
Tabla 2.5: Atributos de la interfaz ClinicalImageAccessComponent.
4.2. ImageAccess Interface
A continuación se muestra la definición de esta interfaz que define el acceso a la
imagen propiamente dicha.
interface ImageAccess:ClinicalImageAccessComponent, QueryAccess{ ObservationDataStructSeq get_observation_by_qualifi ed_code(
in QualifiedCodeStr code, in ObservationQualifierSeq qualifiers, in QueryPolicySeq policies,
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
41
in unsigned long max_sequence, out ObservationDataIterator the_rest) raises (DsObservationAccess::InvalidCodes,
DsObservationAccess::InvalidIds, DsObservationAccess::InvalidPolicies, DsObservationAccess::InvalidQualifiers, InvalidParameterCombination);
ImageSeq get_images(in QualifiedCodeStr code, in ObservationQualifierSeq qualifiers, in QueryPolicySeq policies, in unsigned long max_sequence, out ImageIterator the_rest) raises (DsObservationAccess::InvalidCodes,
DsObservationAccess::InvalidIds, DsObservationAccess::InvalidQualifiers, DsObservationAccess::InvalidPolicies, InvalidParameterCombination, InvalidCompression, InvalidAspectRatio, OutOfRange);
OverlaySeq get_overlays(in QualifiedCodeStr code, in ObservationQualifierSeq qualifiers, in unsigned long max_sequence, out ImageIterator the_rest) raises (DsObservationAccess::InvalidCodes,
DsObservationAccess::InvalidQualifiers, DsObservationAccess::InvalidIds, InvalidParameterCombination, InvalidCompression, InvalidAspectRatio, OutOfRange);
GraphSeq get_graphs(in QualifiedCodeStr code, in ObservationQualifierSeq qualifiers, in unsigned long max_sequence, out ObservationDataIterator the_rest) raises (DsObservationAccess::InvalidIds,
DsObservationAccess::InvalidCodes, DsObservationAccess::InvalidQualifiers, InvalidParameterCombination, OutOfRange);
RawImageSeq get_raw_images(in QualifiedCodeStr code , in ObservationQualifierSeq qualifiers, in unsigned long max_sequence, out RawImageIterator the_rest) raises (DsObservationAccess::InvalidIds,
DsObservationAccess::InvalidCodes, DsObservationAccess::InvalidQualifiers, InvalidParameterCombination, OutOfRange);
};
Esta interfaz es el componente básico del servicio de acceso a imágenes. A continuación
se detallarán cada uno de los “atributos” que componen esta interfaz. Como se puede
ver en su definición la interfaz está compuesta por una serie de métodos que realizarán
una operación determinada, a continuación se explicará cada uno de ellos.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
42
4.2.1. get_observation_by_qualified_code ( )
Esta operación se utiliza para obtener los metadatos asociados a las imágenes o
información relacionada con ella. El valor de retorno es de tipo
ObservationDataStruct , su valor depende de la codificación de los parámetros
de entrada. Esta operación es invocada con los siguientes argumentos:
Argumento Descripción
code Código del tipo de solicitud. Los valores posibles se muestran en la Tabla 2.7.
qualifiers Una secuencia de ObservationDataStructs para los detalles de la petición de información. Los valores típicos se muestran en la Tabla 2.7.
policies
Una secuencia de pares <nombre valor> de las políticas de la solicitud. Por ejemplo, el usuario puede especificar el nivel de el valor devuelto utilizando: {code = ReturnValuePolicy; STUDY_LEVEL_ONLY;}
max_sequence
Un número entero que indica el número máximo de elementos que pueden ser devueltos dentro de la ObservationDataStructSeq . El cliente puede optar por recibir muchos o pocos elementos devueltos a través de la ObservationDataStructSeq de get_observation_by_qualified_code () .
the_rest
Un elemento de tipo ObservationDataIterator . Guarda el resto de los items devueltos si el servidor determina que más de max_sequence observaciones cumplen los criterios para el retorno.
Tabla 2.6: Argumentos de la Invocación del método get_observation_by_qualified_code( ) .
A continuación mostramos los diferentes valores que pueden tomar code y
qualifiers dentro del método
get_observation_by_qualified_code() :
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
43
Code Qualifiers Propósito
PATIENT_STUDY {code = PATIENT_ID; …; value = “ …”;}
Obtener el Id de un Estudio (studyIds).
STUDY {code = STUDY_ID; …; value = “… ”;}
Obtener los metadatos de un estudio.
IMAGE_SET {code = IMAGESET_ID; …; value = “…”;} Obtener (ImageSet)
IMAGE_HEADER {code = IMAGE_ID; …; value = “…”;} Obtener una Imagen
Tabla 2.7: Argumentos de la Invocación del método get_observation_by_qualified_code( ) .
4.2.2. get_images ()
Esta operación se utiliza para obtener imágenes de un estudio específico. El valor de
retorno es una secuencia de imágenes. Esta operación es invocada con los siguientes
argumentos:
Argumento Descripción
code Código del tipo de solicitud. Los valores posibles se muestran en la Tabla 2.9.
qualifiers Una secuencia de ObservationDataStructs para los detalles de la petición de información. Los valores típicos se muestran en la Tabla 2.10.
policies
Una secuencia de pares <nombre valor> de las políticas de la solicitud. Por ejemplo, el usuario puede especificar el nivel del valor devuelto utilizando: {code = ReturnValuePolicy; value = THUMBNAILS;}
max_sequence
Un número entero que indica el número máximo a ser devueltos dentro de la ImageSeq. El cliente puede optar por recibir muchos o pocos elementos devueltos a través de la ImageSeq de get_images() .
the_rest Un elemento de tipo ImageIterator . Guarda el resto de los items devueltos si el servidor determina que más de max_sequence imágenes cumplen los criterios para el retorno.
Tabla 2.8: Argumentos de la Invocación del método get_images( ).
A continuación mostramos los valores que pueden tomar code y qualifiers
dentro de este método.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
44
Code Propósito STUDY_IMAGES Obtener Imágenes en Secuencia
IMAGESET_IMAGES Obtener Imágenes en Secuencia LIST_OF_IMAGES Obtener Imágenes Aleatoricamente
IMAGE Obtener una Imagen
Tabla 2.9: Valores de code dentro del métdo get_image( ).
code Valor Propósito
OBJECT_ID ObjectIdSeq Especifica un Identificador de Objeto
ImageEncoding JPEG, GIF, etc. Especifica el tipo de codificación de la Imagen
ImageCompression ZIP, WAVELET, etc.
Especifica el método de compresión de la Imagen
ImageProcessing FLIP, ROATATE, etc.
Especifica las opciones de procesado de la Imagen
DESTINATION_SIZE ImageGeometry Especifica el tamaño de destino
SOURCE_GEOMETRY ImageGeometry Especifique la parte deseada de la Imagen
Tabla 2.10: Valores tipicos de qualifier dentro del métdo get_image( ).
4.2.3. get_overlays ( )
Esta operación se utiliza para obtener imágenes superpuestas. El valor de retorno es
un conjunto de superposición de objetos. Esta operación es invocada con los siguientes
argumentos:
Argumento Descripción
code Código del tipo de solicitud. Aquí el valor es OVERLAYS
qualifiers Una secuencia de ObservationDataStructs con los detalles para solicitar información. Los valores posibles se describen en la operación get_images() .
max_sequence
Un número entero que indica el número máximo de elementos devueltos dentro de la ImageSeq . El cliente puede optar por recibir muchos o pocos elementos devueltos a través de la ImageSeq de get_overlays () .
the_rest
Un elemento de tipo ImageIterator . Almacena el resto de los elementos devueltos si el servidor determina que más de max_sequence superposiciones cumplen los criterios para el retorno.
Tabla 2.11: Conjunto de argumentos del método get_overlays ( ).
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
45
4.2.4. get_graphs ( )
Esta operación se utiliza para obtener gráficos. El valor de retorno es un conjunto de
objetos Graph . Esta operación es invocada con los siguientes argumentos:
Argumento Descripción
code Código del tipo de solicitud. Aquí el valor es GRAPHS
qualifiers Una secuencia de ObservationDataStructs con los detalles para solicitar información. Los valores típicos se recogen en la Tabla 3.4.2.
max_sequence
Un número entero que indica el número máximo de elementos a ser devueltos dentro de la ObservationDataStructSeq . El cliente puede optar por recibir muchos o pocos elementos devueltos a través de la ObservationDataStructSeq de get_graphs () .
the_rest
Un elemento de tipo ObservationDataIterator . Almacena los elementos no devueltos en ObservationDataStructSeq si el servidor determina que más de max_sequence gráficos cumplen los criterios para el retorno.
Tabla 2.12: Conjunto de argumentos del método get_graphs ( ).
A continuación se muestran los valores típicos que toma el argumento qualifiers
dentro de este método.
code Valor Propósito
OBJECT_ID ObjectIdSeq Especifica un Identificador de Objeto
DESTINATION_SIZE ImageGeometry Especifica el tamaño de destino
SOURCE_GEOMETRY ImageGeometry Especifique la parte deseada de la Imagen
Tabla 2.14: Valores Típicos del argumento qualifiers dentro del método get_graphs ( ).
4.2.5. get_raw_images ( )
Esta operación se utiliza para obtener la cabecera de la imagen sin ser tratada, la
imagen sin tratar los pixeles de la misma o ambas cosas. Esta operación es invocada
con los siguientes argumentos:
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
46
Argumento Descripción
code
Código del tipo de solicitud. Sus posibles valores pueden ser RAW_IMAGE para toda la imagen, RAW_IMAGE_HEADER de cabecera de la imagen, y RAW_IMAGE_PIXEL de píxeles.
qualifiers Una secuencia de ObservationDataStructs con los detalles para solicitar información. Los valores típicos se recogen en la Tabla 2.16.
max_sequence
Un número entero que indica el número máximo a ser devueltos dentro de la RawImageSeq. El cliente puede optar por recibir muchos o pocos elementos a través de la RawImageSeq de get_raw_images () .
the_rest
Un elemento de tipo RawImageIterator. Almacena los ítems no devueltos si el servidor determina que más de max_sequence imágenes sin tratar cumplen los criterios para el retorno.
Tabla 2.15: Conjunto de argumentos del método get_raw_images ( ).
A continuación se recogen los valores típicos del argumento qualifiers cuando se
usa el método get_raw_images() .
code Valor Propósito OBJECT_ID ObjectIdSeq: [ ] Especifica un Identificador de Objeto OFFSET long: … Especifica donde empezar
AMOUNT_TO_GET long: … Especifia el número de bytes a coger.
Tabla 2.16: Valores Típicos del argmuento qualifiers dentro del método get_raw_images ( ).
4.3. ObservationLoader Interface
Al igual que se hizo con las anteriores interfaces, se muestra la definición de esta nueva
interfaz según la especificación CIAS.
interface ObservationLoader : ClinicalImageAccessCo mponent, COASObservationLoader{
void load_images(in QualifiedCodeStr code, in any result);
};
Servicio Web para la Gestión de Imágenes Médicas Capítulo 2
47
Esta interfaz hereda la DsObservationAccess::ObservationLoader de
COAS. La idea es heredar el método load_observations() utilizado para cargar
los metadatos de la imagen en un servidor CIAS. A continuación se muestra el
funcionamiento de load_images() .
Atributo Descripción
Load_image()
Cargar imágenes en un servidor CIAS. La operación es invocada con los siguientes argumentos:
Code: código del tipo de solicitud. Sus posibles valores pueden
ser STUDY_IMAGES, IMAGESET_IMAGES,
LIST_OF_IMAGES, o IMAGE.
Result: Una secuencia de imágenes
Tabla 2.17: Atributos de la Interfaz ObservationLoader según CIAS.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
48
Capítulo 3:
Servicio Web para la Gestión de Imágenes
Médicas
1. Introducción
En este capítulo e presenta la especificación y desarrollo del Sistema de Gestión de
Imágenes Médicas (SGIM) basado en SW.
En primer lugar se hablará del servicio propiamente dicho, es decir, del conjunto de
métodos que se han desplegado en Axis2. Se verá cómo sería la invocación de estos
métodos para el correcto funcionamiento del sistema.
Por último se hablará del núcleo del cliente de pruebas, aplicación la cuál es la interfaz
de usuario del mismo, se verán las diferentes clases implementadas que dan la
funcionalidad al cliente de pruebas, otorgando a éste una interfaz de comunicación
SOAP con el servidor y que a su vez permite probar el servicio.
Antes de ver los detalles sobre implementación se muestra un esquema en el cual se
pueden observar todos los elementos del sistema:
Figura 3.1: Escenario Propuesto para el Servicio
Tomcat
Axis2
Internet/
LAN Aplicación
Cliente
BD
ClinicalImageService
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
49
Antes de comenzar, se analiza un poco cada uno de los elementos que forman el
sistema completo:
En el lado del servidor se encuentra la Base de Datos que servirá para almacenar toda
la información relacionada con pacientes, pruebas y usuarios. Por encima de la Base de
Datos, se sitúa Apache-Tomcat con Axis2 en el cual se despliega el Servicio Web
implementado, ClinicalImageService, con una Interfaz SOAP.
En el lado del cliente hay un Servidor Xampp (Apache, PHP5, MySQL, etc.)
conteniendo la aplicación cliente de pruebas de nuestro servicio. Dicha aplicación tiene
una Interfaz SOAP que se comunicará con la interfaz SOAP del Servicio.
A continuación se presenta cada uno de los elementos involucrados en la figura 3.1 por
separado.
2. Base de Datos
En este punto del capítulo se va a analizar la base de datos que se ha utilizado en el
proyecto. Se pretende recoger toda la estructura de la base de datos indicando nombre
de las tablas, nombre de los diferentes campos que las componen y tipos de datos de
los diferentes campos.
Para ello se mostrarán a continuación dos diagramas que pretenden recoger todas las
características recogidas en el párrafo anterior. Estos diagramas son el diagrama
Entidad-Relación, en el que se verá la relación entre las diferentes entidades y los
atributos de las mismas, y el diagrama de clases UML en el que también se podrán ver
los tipos de datos de los diferentes atributos de una entidad.
Pero antes de empezar a ver los diagramas comentados en el párrafo anterior se realiza
una introducción al conjunto de tablas que forman la base de datos y los diferentes
campos de las mismas, explicando su funcionalidad en este proyecto.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
50
La base de datos está compuesta por un total de 7 tablas. Éstas son las siguientes:
paciente , prueba , serie , fichero , observacion , diagnostico y
usuarios .
La tabla paciente es la tabla principal de la base de datos, es decir, si no existe un
paciente no tiene sentido que existan las demás tablas. Esta tabla contendrá como su
nombre indica, información sobre los pacientes, organizada según: identificador de
paciente, nombre, apellidos, sexo, fecha de nacimiento, domicilio y teléfono.
La tabla prueba será la encargada de recoger toda la información de pruebas
realizadas a pacientes. La información contenida en ella será: identificador de la prueba,
fecha y hora de la misma, médico que la ha realizado y una descripción.
La tabla serie será la encargada de concretar aún más la información de una prueba,
ya que ésta puede estar formada por varias series. La información de esta tabla es:
identificador de la serie, tipo, fecha, hora y descripción de la misma.
La tabla fichero es la encargada de recoger la información relacionada con los
ficheros dicom almacenados en el sistema. Esta tabla contendrá: nombre del fichero,
tipo de fichero, ancho de la imagen, alto de la imagen y numero de imágenes que
contiene.
Las tablas observacion y diagnostico son muy similares y su función es la de
almacenar posibles observaciones o diagnósticos relativos a una prueba en concreto.
Los campos de información que recogen son: médico, fecha, hora y descripción.
Por último la tabla de usuarios , que es la encargada de recoger toda la información
relacionada con los usuarios del sistema, que en el caso de este proyecto son: nombre
de usuario, apellidos, alias de usuario, contraseña de usuario (MD5 de la contraseña) y
rol del mismo.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
51
2.1. Diagrama Entidad-Relación
El diagrama entidad Relación de la Base de datos utilizada es el que se muestra en la
figura siguiente:
Figura 3.2: Diagrama Entidad-Relación de la Base de Datos
Paciente
id nombre domicilio sexo fecnac dni
telefono
prueba
puid fecha medico descripcion hora
apellidos
serie
suid tipo hora descripcion fecha
fichero
observación
medico fecha texto hora
diagnóstico
medico fecha texto hora
Tiene
Tiene
Tiene
Tiene nombre tipo ancho alto frames
Tiene
usuarios
id nombre apellidos usuario pass rol
1
N
N
1
1
1
N
1
1
N
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
52
2.2. Diagrama UML de Clases
Este apartado pretende mostrar el diagrama UML de clases que describe la base de
datos y las relaciones entre las diferentes clases (entidades en el diagrama Entidad-
Relación), incluyendo los tipos de datos de los diferentes atributos.
Figura 3.3: Diagrama de Clases UML de la Base de Datos
3. Servicio ClinicalImageService
A continuación se mostrarán los aspectos relacionados con el servicio web que se ha
implementado bajo Axis2, ClinicalImageService. En primer lugar se verá el correcto
despliegue del servicio en Axis2 y el conjunto de métodos que lo forman.
Para acceder a la página de Axis2 en el equipo servidor, se hace mediante la siguiente
dirección:
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
53
http://localhost:8080/axis2/
Figura 3.4: Página Principal de Axis2
Figura 3.5: Listado de Servicios desplegados en Axis2.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
54
En la figura 2.1 (b) se pueden observar el conjunto de métodos que forman el servicio
ClinicalImageService, y aunque bajo Axis2 se muestran la totalidad de métodos que
forman el servicio, éste realmente está compuesto por 3 interfaces:
• Interfaz ObservationLoader: Esta Interfaz controla la carga de nuevos estudios
de pacientes en el Sistema.
• Interfaz AccesImage: Esta interfaz contiene los métodos necesarios para el
acceso remoto a imágenes médicas
• Interfaz ClinicalImageDB: Esta interfaz contiene los métodos que permiten
realizar operaciones directamente sobre la base de datos.
A continuación se muestran el conjunto de Interfaces y métodos que componen las
mismas:
interface ClinicalImageService { } interface ObservationLoader extends ClinicalImageService {
public void load_images(String code, String result);
} interface ImageAcces extends ClinicalImageService {
public String get_observation_by_qualified_code(String co de, String[] qualifiers, String[] policies, int max_sequence); public String get_images(String code, String[] qualifiers , String[] policies, int max_sequence);
} interface ClinicalImageDB extends ClinicalImageService {
public String InsertPatient (String ID, String Nombre, St ring Apellidos, char Sex, String FecNac, String DNI, String Domicilio, String Telefono); public String[] ViewPatientByID (String ID); public String UpdatePatient (String ID, Stri ng Nombre, String Apellidos, char Sex, String FecNac, String DNI, String Domicilio, String Telefono); public String[] CheckUser (String User, String Pass);
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
55
public int ContNumberOfPatient (); public String[] GetRowOfPatient ( int NumFile, String Order, String Direction); public String InsertUser (String Nombre, String Apellidos , String Usuario, String Pass, String Rol); public String UpdateUser (String Nombre, String Apellidos , String Usuario, String Pass, String Rol); public int ContNumberOfUser (); public String[] GetRowOfUser ( int NumFile, String Order, String Direction); public String[] SearchTestByID (String ID); public String[] SearchTestByTUID (String UID); public String[] SearchSequenceByTUID (String UID); public String[] SearchSequenceBySUID (String UID); public String[] SearchDiagnosticByTUID (String UID); public String InsertDiagnostic (String medico, String fecha, String hora, String texto, String puid); public String[] SearchRemarksByTUID (String UID); public String InsertRemarks (S tring medico, String fecha, String hora, String texto, String puid); public String[] SearchFilesBySUID (String UID); public String[] SearchFilesByName (String Nombre);
}
A continuación se verán cada una de las interfaces por separado.
3.1. Interfaz ClinicalImageService
Esta es la interfaz global del servicio, y de ella cuelgan el resto de interfaces que en
definitiva definirán el servicio.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
56
interface ClinicalImageService { }
Tal como se puede observar arriba, la interfaz ClinicalImageServices aparece vacía,
esto es, no contiene ningún método, lo cuál se debe a que el servicio no tiene ningún
método propio sino que consta de tres interfaces diferentes que serán las que
contendrán los métodos que darán cuerpo al servicio.
En los puntos siguientes se verá en detalle ese conjunto de interfaces que extienden a
la interfaz ClinicalImageService y que definen el funcionamiento del Servicio tal como
se ha descrito anteriormente.
3.2. Interfaz ObservationLoader
A continuación se muestra la interfaz de carga del servicio ClinicalImageService. Esta
interfaz define el método load_images() el cuál será el encargado de recibir un
estudio de paciente en formato DICOM y almacenarlo en la base de datos.
interface ObservationLoader extends ClinicalImageService {
public void load_images(String code, String result);
}
Como se puede observar arriba, esta interfaz es muy similar a la interfaz de carga
definida en CIAS (Ver Capítulo 2), se dice que es similar porque ha sido necesario
adaptar la interfaz que definía CIAS a las especificaciones de la tecnología empleada, es
decir, lenguaje de programación Java y uso de Servicios Web, aunque se ha intentado
mantener la integridad de la interfaz haciendo que ésta reciba los mismos campos que
en CIAS e intentado mantener los tipos de datos.
A continuación se muestra en detalle el funcionamiento del método load_image()
perteneciente al Servicio ClinicalImageService.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
57
3.2.1. load_images()
La Interfaz del método load_images() es la siguiente:
public void load_images (String code, String result );
El funcionamiento del método load_images() es el siguiente; como se puede
observar en el recuadro de arriba el método load_images() recibe como
parámetros dos variables de tipo String, una para identificar el código de la operación
que se va realizar (Ver Tabla 3.1) y otra para identificar el fichero adjunto. Una vez
recibidos los dos parámetros el método comprueba que el valor de la variable code sea
alguno de los valores posibles (ver tabla 3.1), y aunque el servicio implementado sólo
permite operaciones con el código STUDY_IMAGE se comprueba que sea alguno de
los posibles para no permitir operaciones no contempladas por CIAS.
Una vez comprobado el código, y verificado el mismo, se procede a recibir el fichero
adjunto, para lo cual se hace uso del parámetro result , que contendrá el identificador
del fichero adjunto que se va a recibir. Una vez se ha recibido correctamente el fichero
éste es procesado tomando de la cabecera algunos campos (todos los necesarios para
completar la base de datos), es decir, toma los campos necesarios para rellenar la tabla
paciente de la base de datos, la tabla prueba, la tabla serie, y la tabla fichero. También
se comprueba que no existan entradas iguales a las que se van a insertar en dichas
tablas, para evitar duplicados.
Un detalle que merece la pena mencionar es que puesto que para el correcto
funcionamiento de este método necesitamos adjuntar un fichero a la petición, ha sido
necesaria la utilización de SOAP with Attachemt (SwA), aunque ya se hablará de esto
cuando se vean los aspectos de implementación del cliente.
A continuación se muestra una tabla que recoge el conjunto de parámetros tanto de
entrada como de salida del método load_image() :
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
58
Nombre Tipo Descripción
code String
Este parámetro sirve para identificar tipo de solicitud. Sus posibles valores pueden ser: STUDY_IMAGES, IMAGESET_IMAGES, LIST_OF_IMAGES, o IMAGE. Parámetros
de Entrada
result String Es un parámetro que servirá al cliente para identificar al fichero adjunto que se va a enviar.
Parámetros de Salida
void void El método no devuelve nada, al igual que el método definido en CIAS.
Tabla 3.1: Atributos del método load_image() del Servicio ClinicalImageService.
3.3. Interfaz ImageAcces
En este punto se presenta la interfaz de acceso remoto a imagen clínica del servicio
ClinicalImageService. Esta interfaz, al igual que la anterior, pretende adaptarse a las
interfaces definidas en CIAS para operaciones remotas sobre imágenes clínicas. Al
igual que ocurría con la interfaz anterior se ha intentado mantener la integridad de la
interfaz haciendo que ésta reciba los mismos campos que en CIAS e intentado
mantener los tipos de datos, aunque esto último no ha sido del todo posible puesto que
en Java como es sabido no es posible crear nuevos, tipos de datos. Otra alternativa es
crear una clase nueva por cada tipo de datos pero esto puede plantear problemas de
incompatibilidad de tipos de datos en las transferencias ya que el servicio según CIAS
espera un tipo de dato que realmente es de tipo String y recibe un objeto de otra
clase, por este motivo esta última opción se ha descartado y se ha optado por la
primera.
A continuación se muestra la interfaz ImageAcces utilizada en el servicio
ClinicalImageService:
interface ImageAcces extends ClinicalImageService {
public Str ing get_observation_by_qualified_code(String code, String[] qualifiers, String[] policies, int max_sequence); public String get_images(String code, String[] qualifiers , String[] policies, int max_sequence);
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
59
}
Como se puede observar en el recuadro anterior no se han implementado todos los
métodos que se definían en CIAS (Ver Capítulo 2), ya que no formaba parte de los
objetivos obtener la funcionalidad completa definida en la recomendación por ello sólo
se han implementado dos; el método
get_observation_by_qualified_code() , que será utilizado para obtener los
datos de la cabecera del fichero DICOM, y el método get_images() , el cuál será
utilizado para obtener las imágenes propiamente dichas.
A continuación se mostrarán los detalles de los métodos implementados para el
servicio que ocupa esta sección.
3.3.1. get_observation_by_qualified_code()
A continuación se muestra la interfaz de llamada para este método:
public String get_observation_by_qualified_code(String co de, String[] qualifiers, String[] policies, int max_sequence);
Este es otro de los métodos que se definían en CIAS pero al igual que pasaba con el
método anterior, load_images(), no ha podido ser implementado tal cual lo define
CIAS. En el ámbito de este proyecto este método será utilizado únicamente para
mostrar el contenido de la cabecera de un fichero DICOM.
El funcionamiento de este método es muy similar al descrito en CIAS, al igual que en
la recomendación se recibe un parámetro denominado code de tipo String que servirá
para indicar el tipo de operación que se quiere realizar, los valores que puede tomar
este parámetro se pueden ver en la tabla 3.2, aunque en este proyecto tan solo se ha
implementado la funcionalidad necesaria par poder obtener los datos de la cabecera de
un fichero DICOM, es decir, code= ‘IMAGE_HEADER’, el resto de parámetros son
comprobados para no permitir códigos de operación no permitidos en CIAS.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
60
El segundo parámetro es un String[], denominado qualifiers , los valores que
puede tomar éste parámetro según CIAS, son los mismos que code , aunque éste puede
contener varios de ellos, por ser un array , por simplicidad se ha decidido que este
parámetro sólo tome un valor e indique lo mismo que el parámetro code , aunque sea
redundante, pero de esta forma se cumple con la interfaz definida en CIAS.
Code Qualifiers Propósito
PATIENT_STUDY {code = PATIENT_ID; …; value = “ …”;}
Obtener el Id de un Estudio (studyIds).
STUDY {code = STUDY_ID; …; value = “… ”;}
Obtener los metadatos de un estudio.
IMAGE_SET {code = IMAGESET_ID; …; value = “…”;} Obtener (ImageSet)
IMAGE_HEADER {code = IMAGE_ID; …; value = “…”;} Obtener una Imagen
Tabla 3.2: Valores de los parámetros code y qualifier del método get_observation_by_qualified_code() del Servicio ClnicaImageService .
El tercero de los parámetros el parámetro String[] policies , este parámetro servirá
para indicar las diferentes políticas de acceso a los datos almacenados. Estas políticas
son definidas según CIAS y sirven para todos los métodos descritos en la
recomendación, excepto para el método de carga, load_images() . Por tanto
dependiendo de la operación que se desee realizar se usará un valor para este
parámetro u otro. A continuación se muestra el conjunto de valores para el parámetro
policies , descrito en CIAS:
Code Descripción
THUMBNAIL Este valor indica que la imagen debe ser reducida a thumnail y transmitida sin overlays ni gráficos.
STUDY_LEVEL_ONLY Este valor sirve para indicar que la información del estudio sea enviada sin la información del ImageSet
IMAGES_ONLY Este valor sirve para indicar que las estructuras de imágenes sean enviadas sin overlays ni gráficos
OVERLAYS_ONLY Este valor sirve para indicar que sólo los overlays serán transmitidos
GRAPHS_ONLY
Este valor sirve para indica que sólo los gráficos de una imagen sean enviados
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
61
BURNED_IN
Este valor sirve para indicar que se fuerza que todos los overlays y gráficos sean grabados en la matriz de píxeles. Las estructuras de imagen son transmitidas sin separar overlays y gráficos.
Tabla 3.3: Valores del parámetro politicies según CIAS en el Servicio ClinicalImageService.
Para el método get_observation_by_qualified_code(), se ha utilizado el valor de
STUDY_LEVEL_ONLY, puesto que lo que se pretende con este método es la
obtención de la cabecera del fichero DICOM que se esté viendo en un momento
determinado.
Por último se tiene el parámetro max_sequence , que sirve para indicar el número
máximo de estudios que se desea, en este caso se ha limitado a 1 puesto que es la
funcionalidad que se va a implementar en el cliente, además no tiene sentido realizar la
petición de obtención de más de una cabecera DICOM a la vez, ya que dicha cabecera
se refiere a un solo fichero.
Por último, queda describir qué es lo que devuelve este método. Pues bien tal como se
muestra en la interfaz de la llamada al método, devuelve un parámetro de tipo
String , el cuál contendrá un mensaje de error, si fuera el caso, o la ruta del CGI
encargado de procesar el fichero DICOM requerido, para obtener como resultado
todos los datos de la cabecera del fichero. Cuando se hable de los CGI´s que contiene el
servicio en una sección posterior, se hablará más en detalle de cómo se realiza el
procesamiento de los fichero DICOM para obtener los datos de la cabecera, la imagen,
etc.
A continuación, al igual que con los métodos anteriores, se presenta una tabla resumen
de los parámetros de entrada/salida de este método.
Nombre Tipo Descripción
Parámetros de Entrada
code String
Este parámetro sirve para identificar el tipo de solicitud. Los posibles valores que puede tomar se pueden ver en la tabla 3.2.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
62
qualifier String[]
Es un parámetro como se dijo anteriormente sirve para calificar el tipo de operación, en nuestro caso toma el mismo valor que code.
politices String[]
Este parámetro sirve como se dijo antes, para indicar las políticas de acceso a los datos. Los valores se pueden ver en la tabla 3.3.
max_sequence int
Este campo es de tipo entero sirve para indicar el número de imágenes a devolver o tratar. En esta operación es 1.
Parámetros de Salida
return String
Este parámetro es el único parámetro de salida de este método y servirá para indicar si se ha producido error durante la operación o para contener la ruta del CGI que dará como resultado el contenido de la cabecera del fichero DICOM tras su procesado
Tabla 3.4: Atributos del método get_observation_by_qualified_code() del Servicio ClinicalImageService.
3.3.2. get_images()
A continuación se muestra la interfaz de llamada para este método:
public String get_images(String code, String[] qualifiers , Strin g[] policies, int max_sequence);
Este método es muy similar al anterior, al menos en cuanto a parámetros de entrada y
salida, aunque su finalidad es bien diferente. En el ámbito de este proyecto se utilizará
para pedir una imagen al servicio, esto es rescatar una imagen digital de un fichero
DICOM. A continuación se analizan en detalle los parámetros de entrada salida de este
método
El funcionamiento de este método es muy similar al descrito es CIAS, al igual que en la
recomendación se recibe un parámetro de tipo String denominado code que servirá
para indicar el tipo de operación que se quiere realizar, los valores que puede tomar
este parámetro se pueden ver en la Tabla 3.5, aunque en este proyecto tan solo se ha
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
63
implementado la funcionalidad necesaria para poder obtener una imagen JPEG de un
fichero DICOM, es decir, code = ‘IMAGE’, el resto de parámetros son comprobado
para no permitir códigos de operación no permitidos en CIAS.
Code Propósito STUDY_IMAGES Obtener Imágenes en Secuencia
IMAGESET_IMAGES Obtener Imágenes en Secuencia LIST_OF_IMAGES Obtener Imágenes Aleatoricamente
IMAGE Obtener una Imagen
Tabla 3.5: Valores de los parámetros code del método get_image() del Servicio ClnicaImageService .
El segundo parámetro es un String[], denominado qualifiers , los campos y
valores posibles para este parámetro se muestran en la siguiente tabla.
code Valor Propósito
OBJECT_ID ObjectIdSeq Especifica un Identificador de Objeto
ImageEncoding JPEG, GIF, etc. Especifica el tipo de codificación de la Imagen
ImageCompression ZIP, WAVELET, etc.
Especifica el metodo de compresión de la Imagen
ImageProcessing FLIP, ROATATE, etc.
Especifica las opciones de procesado de la Imagen
DESTINATION_SIZE ImageGeometry Especifica el tamaño de destino
SOURCE_GEOMETRY ImageGeometry Especifique la parte deseada de la Imagen
Tabla 3.6: Valores de los campos del parámetro qualifier del método get_image() del Servicio ClnicaImageService .
El tercero de los parámetros el parámetro String[] policies , este parámetro servirá
para indicar las diferentes políticas de acceso a los datos almacenados. Estas políticas
son definidas según CIAS y sirven para todos los métodos descritos en la
recomendación, excepto para el método de carga, load_images() . Por tanto
dependiendo de la operación que se desee realizar se usará un valor para este
parámetro u otro. Los valores posibles para el campo policies , se mostraron en el
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
64
anterior método, Tabla 3.3. Para el correcto uso de este método el valor de este
parámetro debe ser ‘IMAGES_ONLY’, ya que lo se desea aquí es la obtención de una
imagen DICOM en formato JPG, es decir, sólo la imagen.
Por último se tiene el parámetro max_sequence , que sirve para indicar el número
máximo de estudios que se desea.
Queda describir qué es lo que devuelve este método. Pues bien, tal como se muestra en
la interfaz de la llamada al método, devuelve un parámetro de tipo String, el cuál
contendrá un mensaje de error, si fuera el caso, o la ruta del CGI encargado de
procesar el fichero DICOM requerido, para obtener como resultado una imagen JPG
de la imagen DICOM correspondiente. Cuando se hable de los CGI´s que contienen el
servicio en una sección posterior, se hablará más en detalle de cómo se realiza el
procesamiento de los fichero DICOM para obtener los datos de la cabecera, la imagen,
etc.
A continuación, al igual que con los métodos anteriores, se muestra una tabla resumen
de los parámetros de entrada salida de este método.
Nombre Tipo Descripción
code String
Este parámetro sirve para identificar tipo de solicitud. Los posibles valores que puede tomar se pueden ver en la tabla 3.5.
qualifier String[]
Es un parámetro que como se dijo anteriormente sirve para calificar el tipo de operación, la estructura de este parámetro se muestra en la tabla 3.6.
politices String[]
Este parámetro sirve como se dijo antes, para indicar las políticas de acceso a los datos. Los valores se pueden ver en la tabla 3.3
Parámetros de Entrada
max_sequence int
Este campo de tipo entero sirve para indicar el número máximo de imágenes a devolver o tratar.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
65
Parámetros de Salida
return String
Este parámetro es el único parámetro de salida de este método y servirá para indicar si se ha producido error durante la operación o para contener la ruta del CGI que dará como resultado una imagen JPG fichero DICOM tras su procesado.
Tabla 3.7: Atributos del método get_image() del Servicio ClinicalImageService.
3.4. Interfaz ClinicalImageDB
Esta interfaz se encarga de realizar diversas operaciones directamente sobre la base de
datos del sistema. Contienen métodos que no se definen en la recomendación CIAS y
que facilitan la ejecución de operaciones sobre la base de datos.
interface ClinicalImageDB extends ClinicalImageService {
public String InsertPatient (String ID, String Nombre, St ring Apellidos, char Sex, String FecNac, String DNI, String Domicilio, String Telefono); public String[] ViewPatientByID (String ID); public String UpdatePatient (String ID, String Nombre, St ring Apellidos, char Sex, String FecNac, String DNI, String Domicilio, String Telefono); public String[] CheckUser (String User, String Pass); public int ContNumberOfPatient (); public String[] GetRowOfPatient ( int NumFile, String Order, String Direction); public String InsertUser (String Nombre, String Apellidos , String Usuario, String Pass, String Rol); public String UpdateUser (String Nombre, String Apellidos , String Usuario, String Pass, String Rol); public int ContNumberOfUser (); public String[] GetRowOfUser ( int NumFile, String Order, String Direction); public String[] SearchTestByID (String ID);
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
66
public String[] SearchTestByTUID (String UID); public String[] SearchSequenceByTUID (String UID); public String[] SearchSequenceBySUID (String UID); public String[] SearchDiagnosticByTUID (String UID); public String InsertDiagnostic (String medico, String fecha, String hora, String texto, String puid); public String[] SearchRemarksByTUID (String UID); public String InsertRemarks (String medico, String fecha, String hora, String texto, String puid); public String[] SearchFilesBySUID (String UID); public String[] SearchFilesByName (String Nombre);
}
Se han implementado métodos que realizan operaciones implicadas en la validación, la
gestión y administración de usuarios, la gestión y administración de pacientes y por
supuesto la gestión y administración de pruebas realizadas a pacientes.
A continuación se detalla el conjunto de operaciones que se pueden invocar en el
servicio.
3.4.1. CheckUser ( )
La Interfaz del método CheckUser es la siguiente:
public String[] CheckUser (String User, String Pass );
La funcionalidad básica de este método es comprobar que un usuario tiene permisos
para poder entrar en el sistema, recibe como parámetros un nombre de usuario y un
password, a continuación se comprueba que dicho usuario existe en la base de datos,
para lo cual se accede a la tabla usuarios de la base de datos y se comprueba si los
parámetros recibidos, user y pass, se corresponden con alguno de los existentes en
dicha tabla, y si es así devuelve un array con algunos de los parámetros
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
67
identificativos del usuario; como nombre, apellidos, etc. Si el usuario no existe devuelve
error y el usuario deberá volver a identificarse.
A continuación se muestra una tabla con los parámetros de invocación del método
CheckUser():
Nombre Tipo Descripción
User String Este atributo sirve para que el cliente indique su nombre de usuario al sistema.
Parámetros de Entrada
Pass String Este atributo debe contener el md5 (Algoritmo de Resumen del Mensaje 5) de la contraseña de usuario.
Parámetros de Salida
return String[]
Este parámetro de salida contendrá una serie de datos relacionados con el usuario que se ha identificado si todo ha ido bien o un mensaje de error indicando la causa si fuera el caso.
Tabla 3.8: Atributos del método CheckUser()del Servicio ClinicalImageService.
3.4.2. InsertUser( )
La interfaz para este método es la siguiente:
public String InsertUser (String Nombre, String Apellidos, String Usuario, String Pass, String Rol);
Este método se utiliza cuando se quiere añadir un nuevo usuario en el Sistema. Recibe
5 parámetros, que son: el nombre del usuario, los apellidos, un alias de usuario, el
password y el rol que va a tener dentro del sistema (Se han distinguido 2 roles:
usuarios y administradores, ya se hablará de ellos con detalle cuando se estudie el
cliente de pruebas). Como resultado proporciona una cadena de caracteres indicando si
la operación ha ido bien o ha ocurrido algún error mientras se ejecutaba la operación.
En la siguiente tabla se recoge la totalidad de parámetros necesarios para la invocación
de este método, teniendo en cuenta que todos los parámetros involucrados, tanto de
entrada como de salida, son de tipo String.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
68
Nombre Tipo Descripción
Nombre String Este atributo sirve para que el cliente indique el nombre del usuario que se va a insertar en el sistema.
Apellidos String Este parámetro indicará los apellidos del usuario que se quiere insertar en el sistema
Usuario String Este parámetro servirá para indicar el alias del usuario que se pedirá al entrar en el sistema
Pass String Este atributo debe contener el md5 de la contraseña de usuario que se quiere insertar.
Parámetros de Entrada
Rol String Este parámetro se utilizará para indicar el rol de usuario que se va a insertar (usuario o administradores).
Parámetros de Salida
return String
Este parámetro de salida contendrá si todo ha ido bien o el resultado de la operación o un mensaje de error si algo ha ido mal en el transcurso de la operación
Tabla 3.9: Atributos del método InsertUser() del Servicio ClinicalImageService.
3.4.3. UpdateUser()
La interfaz para este método es la siguiente:
public String UpdateUser (String ID, String Nombre, String Apellidos, String Usuario, String Pass, String Rol) ;
Este método se utiliza cuando se quiere modificar algún dato de un usuario existente
en el Sistema. Recibe como parámetros el ID del usuario, el nombre del usuario, los
apellidos, el alias del mismo, la contraseña, y el rol, y proporciona como resultado una
cadena indicando si la operación se ha completado correctamente o se ha producido
algún error.
A continuación se muestra la tabla resumen con los parámetros de entrada salida para
este método, aunque son iguales a los del método UpdateUser():
Nombre Tipo Descripción
Parámetros de Entrada
ID String
Este parámetro sirve para identificar a un usuario de entre todos los que hay en el sistema, es un identificador único.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
69
Nombre String Este atributo sirve para que el cliente indique el nombre del usuario que se va a actualizar en el sistema.
Apellidos String Este parámetro indicará los apellidos del usuario que se quiere actualizar en el sistema
Usuario String Este parámetro servirá para actualizar el nombre del usuario que se pedirá al entrar en el sistema
Pass String Este atributo debe contener el md5 de la contraseña de usuario que se quiere actualizar.
Rol String Este parámetro se utilizará para indicar el rol de usuario que se va a actualizar, hay dos: usuario o administrador.
Parámetros de Salida
return String
Este parámetro de salida contendrá un mensaje indicando si todo ha ido bien o indicado el resultado de la operación o si algo ha ido mal en el transcurso de la operación.
Tabla 3.10: Atributos del método UpdatetUser() del Servicio ClinicalImageService.
3.4.4. ContNumberOfUser( )
La interfaz en este caso es la siguiente:
public int ContNumberOfUser ();
Este método es muy simple, y su funcionalidad es contar el número total de usuarios
existentes en el sistema. Devuelve dicho valor (>=0) si no ha habido error o -1 si se ha
producido algún error. Al igual que en métodos anteriores se muestra a continuación
una tabla que recoge los parámetros de entrada y salida de este método:
Nombre Tipo Descripción
Parámetros de Entrada
void void Este método no recibe ningún parámetro de entrada
Parámetros de Salida
return int
Este parámetro de salida es de tipo entero y contendrá el número de usuarios que hay en la base de datos del sistema si todo ha ido bien o un -1 si ha ocurrido algún error durante su ejecución.
Tabla 3.11: Atributos del método ContNumberOfUser() del Servicio ClinicalImageService.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
70
3.4.5. GetRowOfUser( )
Veamos al igual que en los métodos anteriores la interfaz de dicho método:
public String[] GetRowOfUser (int NumFile, String Order, String Direction);
Este método como su nombre indica, se encarga de tomar los datos de una “fila” de la
tabla usuarios de la base de datos (una fila de esta tabla contendrá todos los datos
relacionados con un mismo usuario). El método recibe como parámetros el número de
fila, el parámetro según el cual se va a ordenar la tabla y la dirección (ascendente o
descendente) en la que queremos tener los datos. Como resultados devuelve los datos
contenidos en las columnas de dicha tabla: nombre, apellidos, user, pass, etc.
A continuación se muestra una tabla resumen con los parámetros de entrada y salida
de este método:
Nombre Tipo Descripción
NumFile int
Este parámetro de tipo entero indica el número de la fila que se va a tomar de la tabla usuarios en la base de datos. Puede variar desde 1 al total de usuarios en el sistema dependiendo de cómo se organicen los resultados.
Order String Este parámetro es de tipo String e indica el parámetro por el cual se va a ordenar la tabla: DNI, Nombre, Apellidos …
Parámetros de Entrada
Direction int
Este parámetro también es de tipo entero y se utilizará para indicar si queremos que los datos se muestren en orden ascendente o descendente.
Parámetros de Salida
return String[] Este parámetro es de tipo String[] y contendrá los datos leído de una fila de la base de datos
Tabla 3.12: Atributos del método GetRowOfUser() del Servicio ClinicalImageService.
3.4.6. InsertPatient( )
La interfaz para este método es la siguiente:
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
71
public String InsertPatient (String ID, String Nombre, String Apellidos, char Sex, String FecNac, String DNI, Str ing Domicilio, String Telefono);
Este método se utiliza cuando se quiere añadir un nuevo paciente en el Sistema. Recibe
como parámetros el ID del paciente, el nombre del paciente, los apellidos, el sexo, la
fecha de nacimiento, el DNI, el domicilio y el teléfono de contacto, y proporciona como
resultado una cadena indicando si la operación se ha completado correctamente o si se
ha producido algún error.
A continuación, una tabla resumen con los parámetros de entrada y salida de este
método, todos de tipo String:
Nombre Tipo Descripción
ID String Este parámetro es el identificador de paciente y debe ser único en el sistema para cada paciente.
Nombre String Este parámetro se utilizará para indicar el Nombre del paciente a insertar.
Apellidos String Este parámetro se utilizará para indicar los Apellidos del paciente a insertar.
Sex char Este parámetro indicará el Sexo del paciente: M (Masculino), F(Femenino) o U (Indeterminado)
FecNac string Este parámetro servirá para indicar la fecha de nacimiento del paciente.
DNI String Este parámetro servirá para indicar el DNI del paciente.
Domicilio String Este parámetro servirá para indicar el Domicilio del paciente.
Parámetros de Entrada
Teléfono String Este parámetro servirá para indicar número de teléfono de contacto del paciente
Parámetros de Salida
return String
Este parámetro de salida será un mensaje indicado el estado de la operación, es decir, si se ha completado o no con éxito.
Tabla 3.13: Atributos del método InsertPatient() del Servicio ClinicalImageService.
3.4.7. GetRowOfPatient( )
La interfaz de este método:
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
72
public String[] GetRowOfPatient (int NumFile, String Order, String Direction);
Este método proporciona la misma funcionalidad que el método equivalente para los
usuarios del sistema, GetRowOfUser, proporcionará la funcionalidad para la
información de pacientes por lo que no se añade nada más para describir este método,
tan solo la tabla resumen con los parámetros de entrada y de salida del mismo:
Nombre Tipo Descripción
NumFile int
Este parámetro de tipo entero indica el número de la fila que se va a tomar de la tabla paciente en la base de datos. Puede variar dependiendo de cómo se quieran organizar los resultados
Order String Este parámetro es de tipo String e indica el parámetro por el cual se va a ordenar la tabla: DNI, Nombre, Apellidos …
Parámetros de Entrada
Direction int
Este parámetro también es de tipo entero y se utilizará para indicar si queremos que los datos se muestren en orden ascendente o descendente.
Parámetros de Salida
return String[] Este parámetro es de tipo String[] y contendrá los datos leídos de una fila de la base de datos
Tabla 3.14: Atributos del método GetRowOfPatient() del Servicio ClinicalImageService.
3.4.8. ViewPatientByID( )
Veamos la interfaz de este método:
public String[] ViewPatientByID (String ID);
Este método normalmente se usará para seleccionar un paciente determinado usando
su identificador de paciente. Como parámetros recibirá dicho identificador y como
resultado devolverá los datos correspondientes al paciente en cuestión o error si lo
hubiera.
Un resumen de los parámetros de entrada y salida se muestran en la siguiente tabla:
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
73
Nombre Tipo Descripción
Parámetros de Entrada
ID String Este parámetro es el identificador de paciente y debe ser único en el sistema para cada paciente.
Parámetros de Salida
return String
Este parámetro de salida será un mensaje indicado el estado de la operación, es decir, si se ha completado o no con éxito.
Tabla 3.15: Atributos del método ViewPatientByID() del Servicio ClinicalImageService.
3.4.9. ContNumberOfPatient( )
La interfaz en este caso es la siguiente:
public int ContNumberOfPatient();
Este método, al igual que su equivalente para los usuarios del sistema, es muy simple, y
su funcionalidad es contar el número total de pacientes existentes en el sistema.
Devuelve dicho valor (>=0) si no ha habido error o -1 si se ha producido algún error.
Nombre Tipo Descripción
Parámetros de Entrada
void void Este método no recibe ningún parámetro de entrada
Parámetros de Salida
return int
Este parámetro de salida es de tipo entero (int) y contendrá el número de usuarios que hay en la base de datos del sistema, si todo ha ido bien, o un -1 si ha ocurrido algún error durante su ejecución.
Tabla 3.16: Atributos del método ContNumberOfPatient() del Servicio ClinicalImageService.
3.4.10. UpdatePatient( )
La interfaz para este método es la siguiente:
public String UpdatePatien (String ID, String Nombr e, String Apellidos, char Sex, String FecNac, String DNI, Str ing Domicilio, String Telefono);
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
74
Este método se utiliza cuando se quiere modificar algún dato de un paciente existente
en el Sistema. Recibe como parámetros el ID del paciente, el nombre del paciente, los
apellidos, el sexo, la fecha de nacimiento, el DNI, el domicilio y el teléfono de contacto
y proporciona como resultado una cadena indicando si la operación se ha completado
correctamente o si se ha producido algún error.
A continuación se muestra la tabla resumen con los parámetros de entrada salida para
este método, puede comprobarse que son iguales a los del método InsertPatient():
Nombre Tipo Descripción
ID String Este parámetro es el identificador de paciente y debe ser único en el sistema para cada paciente.
Nombre String Este parámetro se utilizará para indicar el Nombre del paciente a actualizar.
Apellidos String Este parámetro se utilizará para indicar los Apellidos del paciente a actualizar.
Sex char Este parámetro indicará el Sexo del paciente: M (Masculino), F(Femenino) o U (Indeterminado)
FecNac String Este parámetro servirá para indicar la fecha de nacimiento del paciente.
DNI String Este parámetro servirá para indicar el DNI del paciente.
Domicilio String Este parámetro servirá para indicar el Domicilio del paciente.
Parámetros de Entrada
Telefono String Este parámetro servirá para indicar número de teléfono de contacto del paciente
Parámetros de Salida
return String Este parámetro de salida será un mensaje indicado el estado de la operación, es decir, si se ha completado o no con éxito.
Tabla 3.17: Atributos del método UpdatetPatient() del Servicio ClinicalImageService.
3.4.11. SearchTestByID()
A continuación se muestra la interfaz de llamada para este método, que será el
encargado de encontrar las pruebas relativas ha un paciente:
public String[] SearchTestByID (String ID);
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
75
Como se ha introducido antes, este método es utilizado para encontrar todas las
pruebas relativas a un paciente, esto es; a través del identificador de paciente pasado
como parámetro en la invocación, el método devuelve un array con todos los
identificadores de pruebas realizadas relacionadas con dicho paciente. A continuación
se muestra, al igual que se hizo con métodos anteriores, una tabla resumen de los
parámetros de entrada salida de este método:
Nombre Tipo Descripción
Parámetros de Entrada
ID String Este parámetro es el identificador de paciente y debe se único en el sistema para cada paciente.
Parámetros de Salida
return String[]
Este parámetro de salida será una tabla indicando todos los identificadores de pruebas existentes para el paciente en la base de datos o un mensaje de error indicando la causa del mismo.
Tabla 3.18: Atributos del método ShearchTestByID() del Servicio ClinicalImageService.
3.4.12. SearchTestByTUID()
Este método es muy similar al anterior, la interfaz de invocación del mismo se muestra
a continuación:
public String[] SearchTestByTUID (String UID);
Este método se utiliza para recuperar todos los datos relacionados con una prueba en
concreto mediante el identificador de la prueba que se quiere examinar. Los datos que
se pueden recuperar son los datos contenidos en las columnas de la tabla pruebas, es
decir, identificador de la prueba (es el parámetro necesario en la invocación del
método), fecha de la prueba, hora de la prueba, médico que realizó la prueba,
descripción de la prueba e identificador de paciente a quién pertenece. Si la operación
resulta exitosa el método devuelve una tabla con todos los datos mencionados antes
pero en caso de error devolverá un mensaje de error. A continuación se muestra un
resumen de los parámetros de entrada salida de éste método:
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
76
Nombre Tipo Descripción
Parámetros de Entrada
UID String Este parámetro es el identificador de prueba y debe se único en el sistema para cada prueba.
Parámetros de Salida
return String[]
Este parámetro de salida será una tabla indicando todos los valores existentes en la base de datos relacionados con la prueba buscada. En caso de error devuelve un mensaje indicando la causa.
Tabla 3.19: Atributos del método ShearchTestByTUID() del Servicio ClinicalImageService.
3.4.13. SearchSequenceByTUID()
Este método es muy similar al método SearchTestByID(). El modelo que sigue un
fichero Dicom es el siguiente, una prueba puede estar compuesta por N series, a su vez
una serie puede estar compuesto por N ficheros y un fichero está compuesto por una
imagen. Por tanto, este método devuelve todos los identificadores de series asociados a
una prueba, recordemos que el método SearchTestByID realizaba una operación
similar pero devolviendo todos los indentificadores de pruebas asociado a un paciente.
Por lo que no hace falta añadir más para describir el funcionamiento de este método. A
continuación se muestra la interfaz de invocación para el método y una tabla resumen
con los parámetros de entrada/salida de este método:
public String[] SearchSequenceByTUID (String UID);
Una vez mostrada la interfaz de invocación se muestra una tabla resumen con los
parámetros de entrada salida, al igual que con los métodos anteriores:
Nombre Tipo Descripción
Parámetros de Entrada
UID String Este parámetro es el identificador de prueba y debe ser único en el sistema para cada prueba.
Parámetros de Salida
return String[]
Este parámetro de salida será una tabla indicando todos los identificadores de series existentes para la prueba en la base de datos o un mensaje de error indicando la causa del mismo.
Tabla 3.20: Atributos del método ShearchSequenceByTUID() del Servicio ClinicalImageService.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
77
3.4.14. SearchSequenceBySUID()
Este método es muy similar a otro método descrito anteriormente, al método
SearchTestByTUID(), en este caso, este método devuelve todos los parámetros
existentes en la base de datos para una serie en concreto. Los parámetros que se
pueden recuperar son: identificador de serie, tipo de serie, fecha y hora de la misma y
una descripción, además del identificador de prueba a la que pertenece la serie.
A continuación se muestra la interfaz de invocación para el método:
public String[] SearchSequenceBySUID (String UID);
Una vez mostrada la interfaz de invocación se muestra una tabla resumen con los
parámetros de entrada y salida:
Nombre Tipo Descripción
Parámetros de Entrada
UID String Este parámetro es el identificador de prueba y debe se único en el sistema para cada prueba.
Parámetros de Salida
return String[]
Este parámetro de salida será una tabla indicando todos los valores existentes en la base de datos relacionados con la serie buscada. En caso de error devuelve un mensaje indicando la causa.
Tabla 3.21: Atributos del método ShearchSequenceBySUID() del Servicio ClinicalImageService.
3.4.15. SearchDiagnosticByTUID()
Antes de ver que es lo qué hace este método, aunque sea más o menos intuitivo una vez
visto su nombre, se muestra la interfaz de invocación para dicho método:
public String[] SearchDiagnosticByTUID (String UID) ;
Este método permite buscar posibles diagnósticos para una prueba realizada a un
paciente, como criterio de búsqueda utiliza el identificador de prueba, el cual será
pasado como parámetro en la invocación del método, como resultado devuelve un array
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
78
con el contenido de la tabla diagnostico de la base de datos en relación a la prueba
buscada, esto es: médico, fecha, hora y descripción del diagnostico.
A continuación se muestra una tabla resumen con los parámetros de entrada/salida
para este método:
Nombre Tipo Descripción
Parámetros de Entrada
UID String Este parámetro es el identificador de prueba y debe ser único en el sistema para cada prueba.
Parámetros de Salida
return String[]
Este parámetro de salida será una tabla indicando todos los valores existentes en la base de datos, tabla diagnostico , relacionados con la prueba buscada. En caso de error devuelve un mensaje indicando la causa.
Tabla 3.22: Atributos del método SearchDiagnosticByTUID() del Servicio ClinicalImageService.
3.4.16. InsertDiagnostic()
Este método servirá para insertar diagnósticos en la base de datos, siempre en relación
a una prueba.
A continuación se muestra la interfaz de invocación para este método:
public String InsertDiagnostic (String medico, String fecha, String hora, String texto, String puid);
Este método recibe los parámetros: médico, fecha, hora, texto y puid en relación al
diagnóstico que se va a realizar (asociado a una prueba), a continuación los inserta en la
base de datos, en la tabla correspondiente, y devuelve un mensaje indicado el resultado
de la operación.
A continuación se muestra una tabla resumen con todos los parámetros de entrada y
salida:
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
79
Nombre Tipo Descripción
medico String
Indicará el nombre del médico que está realizando el diagnóstico. Forma parte de la clave primaria de la tabla diagnostico por lo que es un parámetro que debe ser distinto de null.
fecha String
Este parámetro servirá para indicar la fecha en la que se realizó el diagnostico, de forma que se pueda ver toda la evolución del proceso diagnóstico. Al igual que el anterior forma parte de la clave primaria de la tabla diagnostico
hora String
Este parámetro servirá para indicar la hora en la que se realizó el diagnóstico. Al igual que los dos anteriores este atributo también forma parte de la clave primaria de la tabla diagnostico.
texto String Este parámetro será una cadena de caracteres que servirá para indicar la descripción del diagnóstico.
Parámetros de Entrada
puid String Este parámetro será el identificador de la prueba a la cual se desea asignar diagnóstico, como sabemos es único para cada prueba.
Parámetros de Salida
return String Este parámetro indica el resultado de la operación de inserción. En caso de error devuelve un mensaje indicando la causa.
Tabla 3.23: Atributos del método InsertDiagnostic() del Servicio ClinicalImageService.
3.4.17. SearchRemarksByTUID()
Este método es muy similar al de búsqueda de diagnósticos, pero esta vez son
observaciones. Se muestra la interfaz de invocación para dicho método:
public String[] SearchRemarksByTUID (String UID);
Este método permite buscar posibles observaciones para una prueba realizada a un
paciente, como criterio de búsqueda utiliza el identificador de prueba, el cual será
pasado como parámetro en la invocación del método, como resultado devuelve un
array con el contenido de la tabla observaciones de la base de datos en relación a la
prueba buscada, esto es: médico, fecha, hora y descripción de la observación realizada.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
80
A continuación se muestra una tabla resumen con los parámetros de entrada salida
para este método:
Nombre Tipo Descripción
Parámetros de Entrada
UID String Este parámetro es el identificador de prueba y debe ser único en el sistema para cada prueba.
Parámetros de Salida
return String[]
Será una tabla indicando todos los valores existentes en la base de datos, tabla observaciones, relacionados con la prueba buscada. En caso de error devuelve un mensaje indicando la causa.
Tabla 3.24: Atributos del método SearchDiagnosticByTUID() del Servicio ClinicalImageService.
3.4.18. InsertRemarks()
Este método servirá para insertar observaciones en la base de datos, siempre en
relación a una prueba.
A continuación se muestra la interfaz de invocación para este método:
public String InsertRemarks (String medico, String fecha, String hora, String texto, String puid);
Este método recoge los parámetros: médico, fecha, hora, texto y puid en relación a la
observación que se va a realizar de la prueba deseada, a continuación los inserta en la
base de datos, en la tabla correspondiente, y devuelve un mensaje indicando el
resultado de la operación. A continuación se muestra una tabla resumen con todos los
parámetros de entrada y salida:
Nombre Tipo Descripción
Parámetros de Entrada
medico Stirng
Indicará el nombre del médico que está realizando el diagnóstico. Forma parte de la clave primaria de la tabla observaciones por lo que es un parámetro que debe ser distinto de null.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
81
fecha String
Este parámetro servirá para indicar la fecha en la que se realizó la observación, de forma que se pueda ver toda la evolución del proceso de observaciones. Al igual que el anterior forma parte de la clave primaria de la tabla observaciones.
hora String
Este parámetro servirá para indicar la hora en la que se realizó la observación. Al igual que los dos anteriores, forma parte de la clave primaria de la tabla observaciones.
texto String Este parámetro será una cadena de caracteres que servirá para indicar la descripción de la observación.
puid String
Este parámetro será el identificador de la prueba a la cual se desea asignar la observación, como sabemos es único para cada prueba.
Parámetros de Salida
return String Indica el resultado de la operación de inserción. En caso de error devuelve un mensaje indicando la causa.
Tabla 3.25: Atributos del método InsertRemarks() del Servicio ClinicalImageService.
3.4.19. SearchFilesBySUID()
A continuación se muestra la interfaz de invocación para este método:
public String[] SearchFilesBySUID (String UID);
Este método será utilizado para buscar los distintos ficheros existentes en la base de
datos pertenecientes a una serie de una prueba determinada, esto es; en base al
identificador de la serie, busca todos los ficheros existentes para la misma y los
devuelve en una tabla. A continuación se muestra una tabla que recoge de forma
resumida el conjunto de parámetros de entrada salida para este método:
Nombre Tipo Descripción
Parámetros de Entrada
UID String
Este parámetro es el identificador de serie y debe ser único en el sistema para cada serie.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
82
Parámetros de Salida
return String[]
Este parámetro de salida será una tabla indicando todos los nombre de los ficheros almacenados en el sistema, para cada fichero se tiene un nombre diferente, por lo que es clave primaria de la tabla ficheros. En caso de error se responde con un mensaje indicando la causa del mismo.
Tabla 3.26: Atributos del método SearchFilesBySUID() del Servicio ClinicalImageService.
3.4.20. SearchFilesByName()
Este método normalmente se ejecutará justo a continuación del anterior, ya que, el
anterior proporciona una tabla con todos los identificadores de ficheros (nombre)
almacenados y correspondientes a una serie determinada de una prueba y con este otro
método se lee toda la información relativa a un fichero determinado. A continuación, se
muestra la interfaz de invocación para este método:
public String[] SearchFilesByName (String Nombre);
Y como siempre, una tabla resumen con todos los parámetros de entrada y salida para
este método:
Nombre Tipo Descripción
Parámetros de Entrada
Nombre String
Este parámetro indica el nombre del fichero que se quiere recuperar, este nombre, es identificador de fichero y es único en la base de datos, para cada fichero.
Parámetros de Salida
return String[]
Este parámetro de salida es una tabla con todos los datos almacenados en la base de datos para el fichero de nombre indicado en el parámetro de entrada. Los valores que se pueden recuperar son: nombre del fichero, tipo, ancho, alto, número de frames y el identificador de serie al que pertenece. En caso de error devuelve un mensaje indicando la causa.
Tabla 3.27: Atributos del método SearchFilesByName() del Servicio ClinicalImageService.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
83
3.5. CGI´s
Por último se describen los diferentes CGI´s (Common Gateway Interface) que se han
usado en el sistema. Como en el proyecto de partida [1], en el sistema local tendremos
un directorio el que contiene los diferentes ficheros DICOM correspondientes a los
estudios realizados, que a su vez están referenciados de alguna forma en la base de
datos. Pero los ficheros DICOM tienen el problema de que no son ficheros de imagen
“típicos”, por ello usamos unos scripts (cgi´s) para procesar dichos ficheros DICOM y
obtener a partir de ellos las imágenes deseadas. En este proyecto se reutilizarán los
cgi´s codificados en [1]: dcm2jpg.cgi y dcmecg2png.cgi, adaptándolos a la nueva
funcionalidad.
Ahora en el lado del servidor no tenemos una aplicación web que pueda recuperar y
procesar las imágenes desde la base de datos para mostrarlas por pantalla como se
tenía en [1], si no que ahora tenemos Axis2, una serie de métodos que podemos
ejecutar (Servicio Web ) y una base de datos junto con un directorio que almacena los
estudios DICOM. Por todo lo anterior el que debe procesar ahora los fichero DICOM
es el servidor, por lo que es éste el que contiene los cgi´s (estarán dentro del Servicio
desplegado en Axis2 ). El problema es que Axis2 corre bajo Tomcat y éste toma por
defecto que los cgi´s son script de Perl. La solución adoptada ha sido la codificación de
un cgi en Perl que invoque a los demás como si fueran “comandos” obteniendo así el
resultado deseado.
Por otro lado para obtener los datos de la cabecera de cada fichero DICOM se ha
codificado otro cgi en Perl que, haciendo uso de las librerías dcm4che, consigue el
correcto procesamiento del mismo.
Todavía queda otro cgi más, es el cgi que permite al usuario final obtener un fichero
DICOM completo (Imagen y Metadatos) del servidor. Este cgi es el cgi
DicomFile.dcm que esta codificado en Perl y que, haciendo uso del cgi codificado en el
proyecto anterior [1], consigue obtener un fichero desde el directorio de
almacenamiento para devolverlo al cliente.
De forma que en su totalidad el árbol de los cgi´s utilizado es el siguiente:
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
84
• call.pl:
� dcm2jpg.cgi
� dcmecg2png.cgi
• DicomFile.dcm:
� cogefichero.cgi
• header.pl
A continuación se verá cada uno de ellos por separado de forma que se aclare su
funcionamiento y su forma de invocación.
3.5.1. CGI: call.pl
Este cgi está codificado en Perl y será utilizado para invocar a los cgi´s desarrollados
en el Proyecto: Diseño e Implementación de un Servidor de Imágenes DICOM con
Interfaz WEB [1], es decir, los cgi´s dcm2jpg.cgi y dcmecg2png.cgi. Estos cgi´s
permiten obtener una imagen en formato digital, jpg o png a partir de un fichero
DICOM. De estos dos últimos se hablará en las próximas secciones.
Concretando más en el funcionamiento de este script, se puede decir que toma una
serie de parámetros de la barra de navegación del cliente y ejecuta alguno de los cgi´s
anteriores con los parámetros que ha recogido.
La invocación desde línea de comandos sería:
call.pl ‘CGI’ ‘RUTA_FILE’ ‘FRAME’ ‘WIDTH’ ‘HEIGHT’
Pero obviamente se ejecutará desde un navegador por ello la invocación seria
(suponiendo que se tiene correctamente configurado axis2 y todos los cgi´s
permitiendo además que tomcat los ejecute, en un capítulo posterior se verá como
instalar y configurar correctamente el sistema):
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
85
http://locahost:8080/axis2/cgi-bin/call.pl?CGI+RUTA _FILE+FRAME+
WIDTH+HEIGHT
Esta última es la línea que ejecuta el cliente para obtener una imagen digital del fichero
que se quiere procesar. Por otro lado aclarar que esa ruta no la tiene por qué saber el
cliente sino que será tarea del servicio devolver dicha ruta al cliente cuando éste
ejecute el método correspondiente.
Por último se muestra una breve explicación del significado de cada parámetro de
entrada de este script, aunque ya se puede intuir su significado:
• CGI: Este parámetro indicará el tipo de script que se desea ejecutar, esto es o
bien dcm2jpg.cgi o dcmecg2png.cgi.
• RUTA_FILE: Este parámetro es la ruta absoluta del fichero que queremos
procesar
• FRAME: Este parámetro indica el número de imágenes a procesar, por lo
general será 1.
• WIDTH: Este parámetro servirá para indicar la anchura de la imagen
devuelta.
• HEIGTH: Este parámetro servirá para indicar la altura de la imagen devuelta.
Los dos últimos parámetros son opcionales y si no se indican la imagen se envía al
tamaño real de la misma. A continuación se verá más en profundidad el funcionamiento
de los cgi dcm2jpg.cgi y dcmecg2png.cgi.
3.5.2. CGI: dcm2jpg.cgi
El programa CGI “dcm2jpg.cgi ”, como ya se introdujo anteriormente, permite
convertir una imagen contenida en un fichero DICOM en una imagen en formato
JPEG, que puede ser mostrada con cualquier navegador Web. Este programa recibe
los siguientes parámetros, en este orden:
• Fichero DICOM: fichero DICOM a leer.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
86
• Frame: frame de la imagen a procesar. Una imagen puede contener múltiples
frames, según de qué tipo sea.
• Ancho: opcional. Ancho de la imagen resultante.
• Alto: opcional. Alto de la imagen resultante.
Los dos últimos parámetros son opcionales, de forma que si no se especifica nada, se
obtiene una imagen con las dimensiones originales. Si se especifica sólo el ancho, se
escala la imagen hasta alcanzarlo, manteniendo la relación de aspecto. En el caso de
especificar ambas dimensiones, se escalará hasta alcanzar una de ellas, sin exceder
ninguna de las dos.
Para más información consultar [1] de la bibliografía.
3.5.3. CGI: dcmecg2png.cgi
El programa CGI “dcmecg2png.cgi ” genera un gráfico a partir de las señales
muestreadas en una Instancia SOP del tipo Waveform. Estas instancias pueden
contener distintos canales, cada uno de ellos identificados por una etiqueta y unidades
de medida, además de otros datos opcionales. Todos los canales son muestreados a la
misma tasa, de forma que todas la muestras se guardan entrelazadas en la instancia. El
gráfico generado contendrá cada uno de estos canales, con sus unidades de medida y su
título correspondiente.
Como único parámetro, este CGI recibe el nombre del fichero DICOM que contiene la
información.
Para más información consultar [1] de la bibliografía.
3.5.4. CGI: DicomFile.dcm
Este script es muy simple, sirve para invocar al cgi cogefichero.cgi , que se
verá en la sección siguiente.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
87
Ya se comentó los problemas que planteaba Tomcat con los cgi´s que no son script de
Perl, por ello este script codificado en Perl permite ejecutar, como si de una línea de
comandos se tratara, el cgi cogefichero.cgi, el cuál permitirá obtener el fichero DICOM
correspondiente almacenado en la base de datos.
Se ha elegido como nombre del script DicomFile.dcm, para que el fichero que se quiere
recuperar reciba ese nombre por lo que tendrá una extensión DICOM y se podrá abrir
con cualquier visor DICOM.
A continuación se muestra más en detalle el funcionamiento del script invocado,
cogefichero.cgi.
3.5.5. CGI: cogefichero.cgi
Este CGI es un programa muy simple, que lee un fichero y lo vuelca en la salida
estándar. Esto permite que el usuario pueda descargarse directamente el fichero
DICOM si lo desea. Aunque para conseguir esto no hace falta desarrollar ninguna
aplicación, ya que bastaría con modificar el fichero de configuración de Tomcat y crear
un Alias al directorio de la base de datos de ficheros, pero esto no es lo más
aconsejable, ya que habría que modificarlo cada vez que cambiamos la configuración
del sistema. Lo que hacemos es que el servidor Web, a través de de este CGI, accedería
al directorio especificado en el fichero de configuración de las páginas Web y cogería la
imagen directamente, sin necesidad de configurar nada adicional. Para más
información consultar igual en otros casos anteriores [1] de la bibliografía.
3.5.6. CGI: header.pl
Este es el último de los CGI´s involucrados en este proyecto. Este script permitirá
obtener los datos de la cabecera de un fichero DICOM. Para conseguir ese objetivo se
hace uso de las librerías dcm4che, unas librerías implementadas en Java para el manejo
de ficheros DICOM, de esta librería se hablará más en detalle en el siguiente capítulo.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
88
Las librerías dcm4che, contienen una serie de herramientas ya implementadas que
realizan operaciones básicas con ficheros DICOM, entre las que destacan: el paso de un
fichero DICOM a txt (datos de la cabecera), paso de fichero DICOM a jpg y viceversa,
etc.
En este caso se quiere conseguir recuperarlos datos de la cabecera de un fichero
DICOM, por ello lo que se hará será hacer uso de la herramienta que proporciona esta
librería; dcm2txt.
En definitiva el script header.pl, es un script codificado en Perl, el cual prepara todas
las variables de entorno necesarias para el correcto funcionamiento de la herramienta
Dcm2txt de dcm4che. Una vez realizadas todas las configuraciones necesarias ejecuta
dicha herramienta y captura la salida de la misma en una tabla, que se muestra por la
salida estándar. Con lo que el resultado final es que el cliente obtiene todos los datos de
la cabecera del fichero DICOM deseado.
4. Cliente del Servicio
En este apartado se hablará del cliente de pruebas del servicio, pero no desde un
aspecto de funcionalidad implementada, sino desde un aspecto de posibles opciones que
ofrece, esto es, se verá el núcleo del cliente de pruebas. El cliente implementado además
de para comprobar la funcionalidad del servicio se ha diseñado de forma estructurada
para poder ser fácilmente reutilizado para desarrollar otros clientes. Para ello en el
cliente del servicio se han codificado en PHP una serie de clases las cuales haciendo uso
de las librerías NuSOAP, pueden invocar los métodos descritos en el servicio
ClinicalImageService.
Por tanto en este bloque se verán las clases implementadas, explicando las diferentes
funcionalidades que ofrecen, es decir los métodos que contienen. Por otro lado se verá
el fichero de configuración del cliente del servicio y por último algunas herramientas
adicionales las cuales se han incorporado al cliente para completar su funcionalidad.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
89
4.1. Clases del Cliente del Servicio
En esta sección se realizará una descripción de las clases que se han implementado para
el cliente:
� CPaginaWeb
� CPaciente
� CPrueba
� CSerie
� CFichero
� CListado
� CUser
A continuación se describe cada una de ellas.
4.1.1. CPaginaWeb
Esta clase ofrece la plantilla básica para la página web del cliente, contiene los métodos
necesarios para insertar la cabecera y el pie de una página HTML básica junto con el
diseño que se ha elegido para el caso que nos ocupa. También realiza la comprobación
de usuarios y activa y destruye las variables de sesión con los datos del usuario
identificado. En resumen el conjunto de métodos implementados en esta clase son
(para más detalles véase el código fuente):
� CPaginaWEB(): Este método es el constructor de la clase y básicamente crea
objeto de la clase CPaginaWEB y establece el Título de la página que es
identificada por ese Objeto, y que será el parámetro de invocación para este
método.
� CheckUser(): La funcionalidad de este método es la de comprobar el usuario y
la contraseña del usuario que quiere iniciar una sesión. Este método invoca al
método del mismo nombre del servicio web ClinicalImageService.
� InitSession(): Este método se encarga de inicializar una serie de variables de
sesión para el usuario que ha iniciado sesión en el sistema. Se guardan el
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
90
nombre de usuario (login), la contraseña, nombre de usuario, apellidos y si la
operación de indentificación ha tenido éxito.
� DestroySession(): Este método se encarga de destruir las variables de sesión
inicializadas en el método anterior al salir de la aplicación cliente.
� SacarCabeceraHTML(): Este método es el encargado de crear el código HTML
necesario para una página web en este cliente, al menos en lo referente a la
cabecera, e inicializa el cuerpo.
� SacarPieHTML(): Este método completa al método anterior de forma que
inserta el código HTML necesario para terminar el cuerpo y la etiqueta HTML
de la pagina web. De forma que entre este método y el anterior se pueda
rellenar con lo que se quiera.
4.1.2. Clase CPaciente
Esta clase es la que contiene todo el juego de operaciones para un paciente, ejemplo de
estas operaciones son: buscar paciente por el identificador de paciente, insertar nuevo
paciente, actualizar datos de pacientes previamente insertados, etc.
A continuación, al igual que se hizo con la clase anterior, se muestran los métodos o
funciones implementadas en esta clase y que son las que dan el conjunto de
posibilidades para un cliente web de este servicio:
� CPaciente(): Este método es el constructor de la clase, recibe como parámetros,
el identificador de paciente, el nombre del paciente, los apellidos, el sexo, la
fecha de nacimiento, el teléfono de contacto y el domicilio. Con los parámetros
anteriores crea un objeto de la clase CPaciente el cuál servirá para identificar a
un paciente en concreto dentro del cliente.
� MostrarFormularioNuevo(): Este método sirve para mostrar un formulario
vacío mediante el cual insertar nuevos pacientes en la base de datos.
� MostrarFormularioEditar(): Este método sirve para mostrar un formulario,
igual que el anterior, pero relleno con los datos del paciente, de forma que se
puedan editar.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
91
� MostrarFormularioFile(): Esta función permite mostrar un formulario para la
inserción de un paciente mediante un fichero DICOM.
� Insertar(): Este es el método que se comunica con el método InsertPatient del
servicio ClinicalImageService, mediante el cual se consigue insertar los datos
para un paciente en la base de datos, concretamente en la tabla paciente.
� Enviar(): Este método es similar al anterior pero su funcionalidad es
comunicarse con el método load_image() para insertar un paciente mediante un
fichero DICOM.
� Actualizar(): Esta función permite al cliente actualizar los datos de un paciente
en concreto , esto es, el identificador de paciente, el nombre, los apellidos, la
fecha de nacimiento, etc.
� BuscarPorID(): Esta función es la que permite buscar a un paciente concreto
por su identificador. Se comunica con el método SearchPatientByID() del
servicio ClinicalImageService y obtiene todos los datos existentes en la tabla
paciente, del paciente con la ID pasada como parámetro.
� MostrarTitular(): Este es un método que tan solo muestra algunos datos
relativos al paciente sirve para mostrar los mismo con un “estilo” diferente.
� MostrarInformacion(): Este método es el que hace posible que se muestren en
la página paciente.php los datos de un paciente concreto, esto es como sabemos:
nombre, apellidos, fecha de nacimiento, etc.
� BuscarPruebas(): Con este método se pueden buscar todas la pruebas realizadas
a un paciente. Su función es comunicarse con el método SearchTestByID() del
servicio ClinicalImageService.
4.1.3. Clase CPrueba
Esta clase ha sido implementada para manejar de forma cómoda todos los datos
referentes a las pruebas realizadas a los pacientes. Permite al usuario buscar datos
relativos a una prueba, buscar series dentro de una prueba y mostrar la información
referente a la misma.
El conjunto de métodos implementados para conseguir el objetivo anterior ha sido:
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
92
� CPrueba(): Este es el constructor de la clase, como parámetros significativos se
tienen: el identificador de la prueba, fecha y hora de la misma, el nombre del
médico que la llevó a cabo, una descripción de la misma y el identificador de
paciente, es decir, el paciente a quién pertenece la prueba.
� BuscarPorUID(): Este método permite obtener todos los datos mencionados en
el constructor de la clase en base al identificador de la prueba, es decir mediante
el identificador de la prueba podemos obtener la fecha y la hora en que se
realizó, la descripción y a quién se realizó
� BuscarSeries(): Con este método conseguimos obtener todos los identificadores
de serie asociados a una prueba identificada por su puid.
� CalcularNumeroImagenes(): Este método, tal y como su nombre indica, permite
obtener el número de imágenes asociadas a una prueba.
� MostrarTitular(): Con este método se muestra un breve titular con los datos
más relevantes de la prueba; la descripción de la misma y el médico que la
realizó.
� MostrarInformacion(): Con este método se pretende ofrecer al usuario final
toda la información relacionada con la prueba que está visualizando, es decir, se
muestra además de lo ya mencionado, el numero de series que componen la
prueba y el número total de imágenes de la misma.
� MostrarInfoPrevia(): Con este método se muestra más en detalle el contenido
de cada una de las series que componen la prueba incluyendo vistas
preliminares de las imágenes que las componen.
� MostrarDiagnosticos(): Con este método se consiguen mostrar todos los
diagnósticos realizados a una prueba
� MostrarObservaciones(): Igual que el anterior pero en vez de diagnósticos se
muestran las observaciones que pueden haber realizado los médicos.
4.1.4. Clase CSerie
Tal y como se mencionaba en el punto anterior, una prueba puede estar compuesta por
una o más series, pues bien, este punto se encarga de describir la clase CSerie, la
encargada de manejar todos los datos relacionados con una serie.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
93
� CSerie(): Este es el constructor de la clase, como parámetros significativos se
tienen: el identificador de la serie, fecha y hora de la misma, el tipo de serie, una
descripción de la misma y el identificador de prueba, es decir, la prueba a la que
pertenece la serie.
� BuscarPorUID():Este método realiza la misma funcionalidad que el mismo
método en la clase CPrueba.
� BuscarFicheros(): Con este método se consiguen buscar todos los ficheros que
componen una serie.
� MostrarInformacion(): Este método realiza la misma función que el del mismo
nombre en la clase CPrueba.
4.1.5. Clase CFichero
Con esta clase terminamos el árbol de dependencia de la base de datos, es decir, un
paciente tiene una o más pruebas, una prueba estará compuesta por una o más series y
una serie está compuesta por uno o más ficheros. Por tanto en este punto se muestra el
contenido de la clase CFichero, la cual se encarga de manejar la información relativa a
los fichero DICOM almacenados en la base de datos del sistema.
� CFichero(): Este es el constructor de la clase, como parámetros significativos se
tienen: el nombre del fichero, el tipo de fichero, el ancho y el alto de la imagen
contenida en él, el numero de frames de las que está compuesto e identificador
de la serie a la que pertenece.
� BuscarPorNombre(): Con este método se recuperan todos los datos
mencionados antes para un fichero concreto
� MostrarImagen(): Con este método se consigue mostrar la imagen contenida en
el fichero DICOM, previamente procesado por el cgi correspondiente del
servicio ClinicalImageService.
� MostrarDicomHeader(): Este método permite obtener el contenido de la
cabecera del fichero DICOM
� NumeroImagenes(): Este método sirve para contar el número de imágenes que
forman el fichero.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
94
4.1.6. Clase CListado
Esta clase se ha implementado para permitir al usuario final obtener un listado
ordenado de todos los pacientes existentes en el sistema, todo ello ordenado en base a
una serie de parámetros. Los parámetros según los cuales se puede ordenar el listado
son: identificador de paciente, documento nacional de identidad (DNI), nombre o
apellidos de los pacientes o fecha de nacimiento de los mismos. Por otro lado también
se puede indicar el sentido en el que se quiere que se muestre el listado, esto es en
sentido ascendente o descendente. A continuación se muestra el conjunto de métodos
que forman esta clase:
� CListado(): Este es el constructor de la clase y como parámetros recibe, el tipo
de parámetro mediante el cuál se va a ordenar el listado (ID, DNI, Nombre,
Apellidos, Fecha de Nacimiento), sentido (ascendente o descendente) en el que
se quiere el listado, el número de resultados por página (se muestra una tabla
con el numero de filas indicado en este parámetro, para ver el resto se pone un
enlace a otra página) y el número de página actual. Como resultado se obtiene
un objeto de la clase CListado que permitirá manejar el listado de pacientes.
� MostrarListado(): Este método es el encargado de mostrar el listado, es que el
que se encarga de crear la tabla y el número de páginas indicado en los
parámetros del constructor.
4.1.7. Clase CUser
Esta clase es muy similar a la clase CPaciente, aunque centrada en los usuarios del
sistema.
� CUser(): Este es el constructor de la clase. Los parámetros de invocación del
mismo son: Nombre del usuario, Apellidos, nombre de usuario (login),
password y rol (Administrador o Usuario).
� MostrarFormularioNuevo(): Este método muestra un formulario para insertar
nuevos usuario en el sistema. Los parámetros mostrados en él son los mismos
que se han indicado en el constructor de la clase.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
95
� MostrarFormularioEditar(): Con este método se obtiene un formulario para
editar las características del usuario. Dependiendo del rol se podrán editar
todos los usuarios (Administrador) o sólo editar las características del usuario
conectado, es decir, así mismo (Usuario).
� Insertar(): Este método es el encargado de enviar los parámetros indicados en
el formulario para insertar nuevos usuarios en el servicio ClinicalImageService
para que éste actualice la base de datos.
� Actualizar(): Igual que el anterior pero para editar un usuario existente en la
base de datos.
� MostrarListado(): Este método es igual que el método del mismo nombre de la
clase CListado, pero en este caso para los usuarios del sistema.
4.2. Configuración del Cliente del Servicio
Esta sección se va a dedicar a analizar el fichero de configuración del cliente web,
aunque en el capitulo siguiente se verá en detalle la instalación y configuración tanto
del servicio ClinicalImageService como del Cliente Web de pruebas.
En el fichero de configuración tan solo hay que indicar una serie de rutas relacionadas
bien con el cliente o bien con el servicio. A continuación se detalla cuales son esas
rutas:
� CWebPath: En esta variable habrá que indicar la ruta absoluta donde se
encuentra el directorio que contiene el cliente web.
� TmpPath: Este parámetro sirve para indicar la ruta absoluta donde se
encuentra la carpeta tmp (carpeta temporal), dentro del directorio del cliente
web.
� URLClient: Este parámetro indica la URL del cliente.
� WSDLService: Con este parámetro se indica la URL del WSDL (fichero de
Descripción del Servicio) del servicio, en este caso, el servicio
ClinicaImageService.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
96
4.3. Herramientas Auxiliares: jpg2dcm
Esta es la última sección dedicada al cliente web. En ella se hablará sobre la
herramienta jpg2dcm una herramienta que permite la conversión de una imagen en
formato jpg a imagen DICOM.
Esta es una herramienta que está incorporada en las librerías java dcm4che, de las
cuales se hablará más en detalle en un capitulo posterior. Como se decía dicha
herramienta ya viene incorporada en las librerías mencionadas, con lo cual se han
implementado diversos scripts para utilizarla en el cliente web.
En primer lugar se han incorporado todas las librerías necesarias al directorio de
librerías del cliente. Con ello se facilita el uso de las mismas desde scripts.
En segundo lugar se han desarrollado dos script que permiten invocar a las librerías
anteriores desde el cliente web, se han implementado dos para diferenciar los entornos
de trabajo; un script se ha implementado como un script de MS-DOS (.bat) para su
ejecución bajo Windows, y otro script de Bash (.sh) para su invocación desde un
sistema Operativo Linux. También se podría utilizar el script de Bash desde Windows
tan solo usando un interprete como puede se el programa sh.exe. Los script
básicamente lo que realizan es la preparación del entorno para la ejecución de la
herramienta, esto es, establecer las rutas y variables de entorno necesarias para la
correcta ejecución de los mismos. Estos script se pueden encontrar en el directorio
bin/ dentro del directorio que contiene el cliente web completo.
Una vez concluida la implementación de los script ya se pueden invocar desde el
cliente, aunque antes hay que realizar un paso previo. Para la ejecución de esta
herramienta es necesario un fichero de configuración, que contenga los datos que se
quieran introducir en la cabecera del fichero DICOM que se va a crear, para ello se ha
creado una plantilla (vacía) que contiene una serie de códigos DICOM (el fichero es
una serie de <código, valor>), la cuál será rellenada mediante el cliente con los datos
introducidos en el formulario correspondiente. La plantilla se encuentra en el
directorio llamado plantilla/ dentro del directorio raíz del cliente web.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 3
97
Una vez rellena la plantilla con los datos deseados, y obtenida la imagen jpg que se
quiere convertir a DICOM, y tras la ejecución de los script, se consigue el fichero
DICOM deseado. Y ya podemos enviarlo al servicio como si de un fichero procedente
de una resonancia se tratara.
Figura 3.6: Proceso de Conversión de Imagen Digital a Imagen DICOM.
Rellenado de la
Plantilla
Selección de
Imagen Digital
Introducción de
Datos
Ensamblado de
los Datos
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
98
Capítulo 4:
Instalación y Configuración del Servicio
1. Introducción
En este capítulo se describen los pasos necesarios para realizar la instalación del
sistema completo en las dos plataformas más utilizadas, GNU Linux (Ubuntu 8.04) y
Microsoft Windows (Windows XP). Veremos cómo instalar cada uno de los paquetes
que componen del Proyecto en cada plataforma así como las dependencias de los
mismos. Por último repasaremos los ficheros de configuración necesarios para la
puesta en marcha.
2. Paquetes Necesarios
A continuación se detallan los paquetes necesarios para el Proyecto, así como las
versiones utilizadas y la dirección donde pueden encontrarse. Todos los enlaces están
comprobados a fecha de octubre de 2008.
• Kit de Desarrollo de Java (JDK) y Entorno de Ejecución Java (JRE): versión 6.
� Linux:
Instalación de los paquetes: sun-java6-bin, sun-java6-jre, sun-java6-jdk, desde
los repositorios de Ubuntu.
� Windows:
JRE:
http://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-
CDS_Developer-Site/en_US/-/USD/VerifyItem-Start/jre-6u10-windows-
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
99
i586-
p.exe?BundledLineItemUUID=FEtIBe.p.PMAAAEd74liLEzz&OrderID=2IB
IBe.pHGsAAAEd4oliLEzz&ProductID=PLNIBe.npD0AAAEbpuoKz7Lc&Fil
eName=/jre-6u10-windows-i586-p.exe
JDK:
http://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-
CDS_Developer-Site/en_US/-/USD/VerifyItem-Start/jdk-6u10-windows-
i586-
p.exe?BundledLineItemUUID=MV9IBe.pfcIAAAEdYaNiLEz1&OrderID=R
mhIBe.piwsAAAEdVqNiLEz1&ProductID=mU9IBe.pkJgAAAEb7aMQVbLE
&FileName=/jdk-6u10-windows-i586-p.exe
• Servidor WEB Apache-Tomcat: versión 6.0.18, con fecha del 17 de Enero de
2008
� Linux:
http://ftp.udc.es/apache-dist/tomcat/tomcat-6/v6.0.18/bin/apache-tomcat-
6.0.18.tar.gz
� Windows:
http://ftp.udc.es/apache-dist/tomcat/tomcat-6/v6.0.18/bin/apache-tomcat-
6.0.18.exe
• Servidor WEB XAMPP (Apache 2 +PHP5+…): versión 1.6.8a , con fecha del
24 de Septiembre de 2008
� Linux:
http://www.apachefriends.org/download.php?xampp-linux-1.6.8a.tar.gz
� Windows:
http://www.apachefriends.org/download.php?xampp-win32-1.6.8-
installer.exe
• PostgreSQL: versión 8.3.4, con fecha del 22 de Septiembre de 2008.
� Linux:
Instalación de los paquetes: postgresql-8.3, postgresql-client-8.3, pgadmin3,
desde los repositorios de Ubuntu.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
100
� Windows:
http://wwwmaster.postgresql.org/download/mirrorsftp?file=/binary/v8.3.4/
win32/postgresql-8.3.4-1.zip
• Axis2: versión 1.4.1 (WAR file), con fecha del 24 de Agosto de 2008
� Linux:
http://ftp.udc.es/apache-dist/ws/axis2/1_4_1/axis2-1.4.1-war.zip
� Windows:
http://ftp.udc.es/apache-dist/ws/axis2/1_4_1/axis2-1.4.1-war.zip
• Perl: version 5
� Linux:
En la versión que se ha escogido de Linux no hace falta porque ya viene
instalado, si hiciera falta se podría instalar desde los repositorios de Ubuntu
como los demás paquetes.
� Windows: ActivePerl version 5.10
http://downloads.activestate.com/ActivePerl/Windows/5.10/ActivePerl-
5.10.0.1004-MSWin32-x86-287188.msi
3. Instalación en Linux
Para llevar a cabo la instalación del Sistema en GNU Linux será necesario partir de
alguna distribución Linux existente, como puede ser Ubuntu, Debian, Fedora, Suse,
Mandrake, etc. Cualquiera de ellas es válida, siempre que se diponga de los paquetes
necesarios para compilar las distintas partes y dependencias del Proyecto, aunque en la
mayoría de los casos se usarán ficheros binarios y no será necesario compilar. En este
caso, como ya se indicó con anterioridad la distribución escogida es Ubuntu versión
8.04.
Para descomprimir (y compilar) los distintos paquetes se necesita un directorio de
trabajo, que normalmente será /opt , aunque puede ser cualquier otro. Al instalar cada
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
101
paquete, estos se instalarán en sus directorios por defecto, que suelen estar dentro de
/usr/local .
3.1. Entorno Java
Para la instalación de los paquetes necesarios para proporcionar un entorno de
desarrollo java en el sistema se usarán los repositorios de Ubuntu. Para ello se deberá
ejecutar en un terminal:
$ sudo apt-get install sun-java6-bin sun-java6-jre sun-java6-jdk
Con ese comando se instalaran los 3 paquetes indicados y se resolverán las posibles
dependencias que fueran necesarias teniendo un entorno java instalado completamente
en nuestro equipo.
3.2. Apache Tomcat
El servidor web Apache-Tomcat será usado en este proyecto para desplegar en él
Axis2 y dentro de este último el servicio web ClinicalImageService. Para tener
operativo el Servidor WEB Apache-Tomcat de forma que después se pueden integrar
los CGI´s para el procesamiento de ficheros DICOM, se va a necesitar el paquete Perl
5 (versión 5.003 o superior), que normalmente se encuentra instalado por defecto en la
mayoría de las distribuciones Linux, por lo que no debe presentar mayor problema.
Los pasos para instalar Apache-Tomcat son:
• Descargar el fichero apache-tomcat-6.0.18.tar.gz , desde la web
indicada en la sección de paquetes necesarios, en un directorio cualquiera del
equipo, por ejemplo en el escritorio.
• Descomprimir el paquete en /opt como superusuario
$ sudo tar xvfz apache-tomcat-6.0.18.tar.gz -C /opt
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
102
• Renombrar el directorio apache-tomcat-6.0.18 a tomcat
$ sudo mv /opt/apache-tomcat-6.0.18 /opt/tomcat
Notas:
• El servidor Apache-Tomcat también se puede instalar desde los repositorios de
Ubuntu usando el comando apt-get install o un gestor de paquetes
como Synaptic, pero se ha optado por usar los ficheros binarios que proporciona
apache para tener todos los elementos que forman el sistema en el mismo
directorio.
• Por defecto el servidor Apache-Tomcat está configurado para correr en el
puerto 8080, aunque es configurable en los ficheros de configuración del mismo.
Una vez instalado, para ejecutar el Servidor WEB Apache-Tomcat tan solo se debe
ejecutar el script que viene con el paquete:
$ sh /opt/tomcat/bin/startup
O bien para detenerlo:
$ sh /opt/tomcat/bin/shutdown
Dicho script sería necesario para iniciar Tomcat cada vez que reiniciemos el sistema
por ello en este proyecto se crearán unos script que inicien todos los servidores
involucrados en el mismo al iniciar el sistema, de forma que no haya que iniciar cada
uno de ellos por separado. Esto se verá en la sección de configuración del sistema.
Con esto, el Servidor WEB (Tomcat) estará escuchando en el puerto 8080. No
obstante, habrá que realizar algunos cambios en la configuración del Servidor, para
habilitar el uso de los CGI´s. Para probar si la instalación es correcta:
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
103
http://localhost:8080/
Figura 4.2: Apache Tomcat Corriendo en Ubuntu 8.04
3.3. Xampp para Linux (Lampp)
El servidor web Xampp for Linux (Lampp) se usará para contener la aplicación que
corresponde al cliente de pruebas del servicio web, es un servidor Apache que soporta
PHP y MySQL, además de algunos otros aspectos menos relevantes para el proyecto.
El cliente de pruebas consistirá en un conjunto de páginas web codificadas en PHP que
junto con la librería NuSOAP para el uso de servicios web en páginas web PHP
compondrán el cliente de pruebas. Para tener operativo el Servidor WEB Lampp tan
solo será necesario que descargar el paquete correspondiente y descomprimirlo dentro
del directorio /opt .
Los pasos para instalar Lampp en Ubuntu son:
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
104
• Descargar el fichero xampp-linux-1.6.8a.tar.gz desde la web
indicada en la sección de “paquetes necesarios” en un directorio cualquiera del
equipo, por ejemplo en el escritorio.
• Descomprimir el paquete en /opt como superusuario
$ sudo tar xvfz xampp-linux-1.6.8a.tar.gz -C /opt
Notas:
• Por defecto el servidor Lampp está configurado para correr en el puerto 80,
aunque es configurable en los ficheros de configuración del mismo.
Una vez instalado, para ejecutar el Servidor WEB Lampp tan solo se debe ejecutar el
script que viene con el paquete para ese fin:
$ /opt/lampp/lampp start
Sería necesario ejecutar el script lampp start para iniciar Lampp cada vez que
reiniciemos el sistema por ello se incluirá también en el script de inicio. Como se verá
en la sección de configuración del sistema.
Otras opciones que proporciona el script lampp son:
$ /opt/lampp/lampp stop -> Para Detener Lampp $ /opt/lampp/lampp restart -> Para Reiniciar los
Lampp $ /opt/lampp/lampp security -> Para Establecer la Seguridad
Con esto, el Servidor WEB (Lampp) está escuchando en el puerto 80 y para probar si
la instalación es correcta se puede abrir un navegador y acceder a la dirección:
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
105
http://localhost/
Figura 4.3: Xampp for Linux Corriendo en Ubuntu 8.04
3.4. PostgreSQL
En este proyecto se utilizará como base de datos una base de datos PostgreSQL. En
ella se almacenará toda la información que el sistema manejará. La instalación de
PostgreSQL en un sistema Linux como es Ubuntu 8.04 se hace como la gran mayoría
de aplicaciones en este sistema operativo, a través de los repositorios de Ubuntu. Los
pasos son los siguientes:
• Instalar desde los repositorios de ubuntu los siguientes paquetes: postgresql-
8.3, postgresql-client-8.3, pgadmin3. El primero es el sistema gestor de
postgres, el segundo el cliente de la base de datos y el tercero es una aplicación
que permite administrar diferentes bases de datos a través de una interfaz
gráfica. Para la instalación de los paquetes necesarios usamos el siguiente
comando:
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
106
$ sudo apt-get install postgresql-8.3 postgresql-cl ient-
8.3 pgadmin3
• A continuación, por razones de seguridad se establece la nueva contraseña al
usuario del sistema creado por PostgreSQL:
$ sudo passwd postgres
• Una vez completado el paso anterior, se verifica si la instalación fue
satisfactoria y para ello se accede a la shell del servidor de bases de datos:
$ sudo su postgres –c “psql template1”
• Si el acceso ha sido satisfactorio se cambia la contraseña al usuario
predeterminado del servidor de bases de datos:
template1=# ALTER USER postgres WITH PASSWORD
'nueva_contraseña';
Con todo esto ya se puede administrar el servidor de bases de datos a través de la
herramienta pgAdmin III, pero antes se deben configurar algunas cosas para que todo
funcione correctamente, esto se verá en la sección de configuración del sistema.
3.5. Axis2
La instalación de Axis2 en un Sistema Operativo Linux y en un Sistema Operativo
Windows mediante el fichero .war se realiza del mismo modo, el único requisito es
tener instalado correctamente el servidor web Apache-Tomcat.
Axis2 se despliega en Tomcat de forma muy simple. Entrando en la sección
Administración, Tomcat Manager, se introduce el usuario y el password del usuario
manager de tomcat. En la sección de Administración aparecerá una lista con las
aplicaciones que tenemos desplegadas en tomcat y más abajo una sección para
desplegar una aplicación mediante un fichero .war. En esa sección se selecciona el
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
107
fichero axis2.war descargado, y se despliega el fichero en Tomcat. Si todo va bien
aparecerá un mensaje indicando que axis2 se ha desplegado correctamente y aparecerá
en la lista de aplicaciones desplegadas en Tomcat. Pinchando en el enlace o bien
poniendo en el navegador la siguiente ruta http://localhost:8080/axis2/ se puede
acceder a la página principal de Axis2.
Figura 4.4: Página Principal de Axis2 corriendo en Ubuntu 8.04
3.6. Servicio Web ClinicalImageService
En este punto se verá como desplegar el servicio ClinicalImageService en Axis2. El
procedimiento para ello es muy simple. Basta con entrar en la sección de
Administración en la Interfaz Web de Axis2, introducir el usuario y contraseña
correspondiente (por defecto user:admin., pass:axis2) y entrar en la sección de “Upload
Service”. Una vez en la sección correspondiente, se selecciona el fichero
ClinicalImageService.aar (en realidad es un .war renombrado) obtenido
gracias al plugin de eclipse y se pulsa en el botón “upload”. Si todo ha ido
correctamente el servicio se habrá desplegado correctamente en Axis2.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
108
No obstante para el correcto funcionamiento del servicio será necesario copiar los
ficheros cgi´s y librerías necesarias en un directorio dentro de Axis2, tal como se verá
en la siguiente sección. Las librerías son los ficheros .jar usados en el servicio, esto es,
el conector java con la base de datos postgresql y las librerías dcm4che. Estas librerías
deben copiarse en el directorio WEB-INF/lib/ dentro de la carpeta de Axis2. Con
ello el servicio podrá funcionar correctamente.
3.7. CGI´s
La instalación de los CGI´s en axis2 es también un proceso muy sencillo, tan solo es
necesario crear un directorio llamado /WEB-INF/cgi-bin dentro del directorio de
axis2 desplegado en tomcat. Si Tomcat está configurado correctamente para permitir
la ejecución de CGI´s éstos funcionarán correctamente sin más que copiar los mismos
al directorio creado. Cómo configurar Tomcat para permitir la ejecución de CGI´s se
verá en una sección posterior.
A continuación se listan el conjunto de cgi´s utilizados:
Nombre Descripción
dcm2jpg.cgi
Este cgi escrito en c++ se encarga de procesar un fichero dicom devolviendo la imagen contenida en el mismo como una imagen jpg recibe como parámetros un fichero dicom, el ancho y el alto para la imagen jpg devuelta.
dcmecg2png.cgi Este cgi en c++ realiza una operación como la anterior pero cuando se trata de un electrocardiograma (ecg).
DicomFile.dcm Este cgi está implementado en perl y se encarga de obtener un fichero dicom desde la base de datos.
call.pl Este cgi en perl es utiliza para invocar a los cgi´s dcm2jpeg y dcmecg2png, ya que tomcat solo permite el uso de cgi´s en perl.
header.pl Este cgi en perl permite el procesamiento de un fichero dicom devolviendo como resultado la cabecera del mismo.
Tabla 4. 1: Conjunto de CGI´s Utilizados por ClincalImageService
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
109
3.8. Cliente Web
El despliegue del cliente Web dentro de Lampp o Xampp es muy simple también, basta
con copiar la carpeta correspondiente al cliente web al directorio htdocs/ de Lampp
(o Xampp) , y en el caso de estar en un sistema operativo Linux se deben asignar
permisos de ejecución a dicho directorio y a todos los fichero que en él hay.
$ sudo chmod 755 /ruta_directorio_cliente_web/ -R
Una vez copiado el directorio al lugar correspondiente y asignados los permisos de
ejecución tan solo quedaría configurar la aplicación para que se comunique de forma
correcta con el servicio, pero esto se verá en una sección posterior.
4. Instalación en Windows
Para llevar a cabo la instalación del Sistema en un quipo con sistema operativo
Windows, se recomienda utilizar alguna de sus versiones orientadas a estaciones de
trabajo, esto es, Windows NT, Windows 2000 Professional, o Microsoft Windows XP
Professional, o incluso las destinadas a servidores. Como referencia, indicar que este
Proyecto ha sido probado utilizando Microsoft Windows XP Professional sin ningún
tipo de problemas.
Para la instalación de los distintos paquetes se va a necesitar un directorio de trabajo,
que normalmente será D:\Servidores\ , aunque puede ser cualquier otro. En él se
instalarán los servidores web Tomcat y Xampp, además del servidor DICOM. El resto
de paquetes se instalarán en las rutas por defecto, que normalmente será
C:\Archivos de Programas\ .
4.1. Entorno Java
La instalación del Kit de desarrollo de Java (JDK) y del Entorno de Ejecución Java
(JRE) bajo Windows es muy sencilla, ya que viene con un programa de instalación muy
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
110
completo. Dicho programa está basado en el sistema de instalación MSI de Windows
(Microsoft System Installer), que viene de serie a partir de Windows 2000, por lo que no
se deben tener problemas. No obstante, se puede descargar obtenerlo del sitio Web de
Microsoft.
Para instalarlo simplemente se ejecuta el fichero de instalación, que mostrará un
asistente en el que se irán seleccionando las distintas opciones de instalación. Lo
normal es dejar las opciones por defecto, ya que se adaptan bien a las necesidades más
comunes. Una vez finalizado el proceso de instalación, ya se tiene un entorno java
completo instalado en el sistema.
4.2. Apache Tomcat
Al igual que ocurría con el entorno java la instalación del Servidor Web Apache-
Tomcat bajo Windows es muy sencilla, ya que se utilizará el programa de instalación
proporcionado por Microsoft (Microsoft System Installer). También existe otra opción
que es la descarga de los ficheros binarios, aunque en este proyecto se ha usado la
anterior.
Para instalarlo simplemente se ejecuta el fichero de instalación, que mostrará un
asistente en el que se irán seleccionando las distintas opciones de instalación. Lo
normal es dejar las opciones por defecto, ya que se adaptan bien a las necesidades más
comunes. Una de las opciones más importantes es si queremos instalar tomcat como
servicio o no, esto se deja a la elección del usuario pero se recomienda que sí, para que
así Apache-Tomcat se inicie con el sistema. Otra opción que es necesario cambiar será
el directorio de instalación que debe ser cambiado al de trabajo D:\Servidores\ .
Una vez finalizado el proceso de instalación, ya se tiene Apache-Tomcat funcionando,
aunque quedaría configurarlo para soportar los CGI´s.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
111
http://localhost:8080/
Figura 4.5: Apache Tomcat Corriendo en Windows Xp
4.3. Xampp para Windows (Xampp)
Al igual que ocurría con los dos paquetes anteriores la instalación del Servidor Web
Xampp bajo Windows es muy sencilla, ya que se utiliza el programa de instalación
proporcionado por Microsoft (Microsoft System Installer).
Para instalarlo simplemente se ejecuta el fichero de instalación, que mostrará un
asistente en el que se irán seleccionando las distintas opciones de instalación. Lo
normal es dejar las opciones por defecto, ya que se adaptan bien a las necesidades más
comunes, aunque al igual que en el caso anterior se debe cambiar el directorio de
instalación al D:\Servidores\ . Una vez finalizado el proceso de instalación, ya está
Xampp (Apache, PHP, MySQL, etc.) funcionando correctamente.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
112
http://localhost/
Figura 4.6: Xampp for Windows Corriendo en Windows Xp
4.4. PostgreSQL
Como los dos paquetes anteriores la instalación de PostgreSQL en Windows es muy
sencilla, ya que se utiliza el programa de instalación proporcionado por Microsoft
(Microsoft System Installer).
Para instalarlo simplemente ejecutamos el fichero de instalación, que mostrará un
asistente en el que se irán seleccionando las distintas opciones de instalación. En el
asistente se pedirá crear el usuario postgres y pedirá una contraseña para el mismo, y
además instala un servidor de base de datos local por defecto por lo que se pueden
ahorrar algunos pasos en la configuración. El instalador instala también la herramienta
de administración pgAdmin III. Una vez finalizado el proceso de instalación, está el
gestor de bases de datos PostgreSQL instalado en el sistema.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
113
4.5. Axis2
La instalación de Axis2 en un Sistema Operativo Windows es igual que en Linux ya
que se utiliza el despliegue mediante fichero .war proporcionado por apache.
Recopilando lo que se expuso para indicar la instalación en Linux, se comienza ahora
entrando en la sección de Administración, pulsando con el ratón en Tomcat Manager,
dentro de la página principal de Tomcat, por lo que se deduce que se debe tener
instalado correctamente Tomcat en el equipo. Una vez se ha pulsado el enlace de
Tomcat Manager se introduce el usuario y el password del usuario manager de tomcat
lo que hará que aparezca en pantalla la sección de Administración de Tomcat. En ella
aparece una lista con las aplicaciones que hay desplegadas en tomcat y más abajo una
sección para desplegar una aplicación mediante un fichero .war. En esta sección, se
selecciona el fichero axis2.war descargado y se pincha con el ratón en el botón
desplegar. Si todo ha ido bien aparecerá un mensaje indicando que axis2 se ha
desplegado correctamente y aparecerá en la lista de aplicaciones desplegadas en
Tomcat. Pinchando en el enlace o bien poniendo en el navegador la siguiente ruta
http:localhost:8080/axis2 se puede acceder a la página principal de Axis2.
Figura 4.7: Xampp for Windows Corriendo en Windows Xp
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
114
4.6. Servicio Web ClinicalImageService
La instalación del Servicio Web ClinicalImageService bajo un sistema operativo
Windows es exactamente igual que la instalación bajo un sistema operativo Linux por
lo que no se entrará en más detalles sobre cómo instalar el servicio (expuesto en la
sección 3.6 de este documento).
4.7. CGI´s
Al igual que ocurría con el servicio ClinicalImageService, los pasos para la instalación
de los CGI´s bajo Windows son los mismo que bajo Linux (sección 3.7 de este
documento).
4.8. Cliente Web
Al igual que ocurre en los dos puntos anteriores, la explicación de la instalación del
cliente web bajo Linux, en la sección 3.8 de este documento, describe los pasos a
seguir para la correcta instalación del mismo bajo un sistema Operativo Windows.
5. Configuración del Sistema
En esta sección se detallarán los pasos necesarios para configurar las aplicaciones que
se han instalado, según cualquiera de los apartados anteriores, para el correcto
funcionamiento del sistema.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
115
5.1. Configuración de Apache-Tomcat
En esta sección se hablará de cómo configurar Apache-Tomcat para que éste pueda
ejecutar CGI´s, ya que según se explicó en secciones anteriores, ClinicalImageService
utiliza de cgi´s para realizar algunas de sus operaciones.
Para configurar Tomcat para el uso de CGI´s se debe realizar las siguientes
modificaciones:
• Modificación del fichero web.xml : buscar las líneas relacionadas con el uso de
cgi´s y en concreto debemos incluir en el fichero lo siguiente:
<servlet> <servlet-name>CGIServlet</servlet-name>
<servlet-class>org.apache.catalina.servlets.CGISe rvlet </servlet-class>
<init-param> <param-name>debug</param-name> <param-value>6</param-value> </init-param> <init-param> <param-name>executable</param-name> <param-value>C:\Perl\bin\perl.exe</param- value> </init-param> <init-param> <param-name>cgiPathPrefix</param-name> <param-value>WEB-INF/cgi-bin</param-value > </init-param> <load-on-startup>5</load-on-startup> </servlet>
En la línea referente al ejecutable que se encargará de interpretar, y en
definitiva de ejecutar, los cgi´s se debe indicar la ruta del mismo, que dependerá
del sistema operativo. Por otro lado en el mismo fichero se debe incluir también
lo siguiente:
<servlet-mapping> <servlet-name>CGIServlet</servlet-name> <url-pattern>/cgi-bin/*</url-pattern> </servlet-mapping>
Una vez terminada la configuración de web.xml será necesario un paso más:
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
116
• Modificación del fichero context.xml : En este fichero tan solo se debe
añadir un parámetro a la etiqueta Context, esto es se debe cambiar donde pone
<Context> por <Context privileged="true"> .
Una vez realizadas las modificaciones indicadas se reinicia Tomcat para aplicar los
cambios realizados y ya está Tomcat preparado para la ejecución de CGI´s.
5.2. Configuración de PostgreSQL
Una vez instalado correctamente postgresql en el sistema lo primero que se debe hacer
es abrir pgAdminIII y crear un nuevo servidor, para lo cual será necesario dirigirse al
menú principal y seleccionar Archivo y luego Añadir Servidor. Aparecerá la siguiente
pantalla:
Figura 4.8: Añadir Servidor de Base de Datos en pgAdmin III
En la pantalla que se muestra en la figura 4.8 se rellenan los campos Nombre (Nombre
del Servidor), Servidor (localhost, ya que será un servidor local), se deja como
propietario al usuario postgres y se establece su contraseña. Con esto se finaliza la
creación del servidor de bases de datos.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
117
El siguiente paso es crear un rol de login nuevo, para el servicio, para ello se crea un
rol nuevo llamado dicom, esto no es del todo necesario, pero de esta forma se tiene
mejor organizado todo lo que tenga que ver con el servicio del presente proyecto.
Añadir un nuevo rol se hace conectándose al servidor y en la sección denominada Roles
de login, pulsar con botón derecho del ratón para así añadir uno nuevo.
Figura 4.9: Añadir un Nuevo Rol de Login en pgAdmin III
En la pantalla para añadir un nuevo rol (rol es distinto del usuario aunque en algunos
casos el nombre del rol coincida con el nombre del usuario), se rellenan los campos
Nombre del Rol, dándole el nombre de dicom, se establece la contraseña y se asignan
los permisos, que en este caso serán todos ya que el nuevo usuario dicom será el
propietario de la base de datos dicom que se va a crear a continuación y en definitiva
será el superusuario del sistema de base de datos dicom.
Por último queda crear una base de datos para el proyecto, por defecto, con la creación
del servidor se crea una base de datos llamada postgres, pero se necesita otra diferente
llamada dicom. Para ello se realiza la misma operación que se hizo para añadir un
nuevo rol, se selecciona la subsección referente a las base de datos, en el explorador de
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
118
objetos y pinchando en el botón derecho aparecerá un menú con el cual podremos
añadir una nueva base de datos. Entonces se verá la siguiente pantalla:
Figura 4.10: Añadir una Nueva Base de Datos en pgAdmin III
En dicha pantalla se rellenan los campos Nombre con el nombre de la base de datos,
que en este caso será dicom, se indica que el propietario es el usuario dicom, el usuario
creado en el paso anterior y se indica que tome como plantilla postgres. Con eso está
creada la base de datos dicom. Ya lo único que falta es restaurar la estructura de la base
de datos a usar, lo cual se hace haciendo uso de los ficheros de resguardo que se
proporcionan en este proyecto.
5.3. Configuración de Axis2
Al igual que Tomcat, Axis2 también tiene un fichero de configuración, en éste la
flexibilidad de configuración es mucho menor que la del fichero de configuración de
Tomcat, pero se indica aquí un cambio que podrá ser útil para la actualización del
servicio sin necesidad de reiniciar todo el servidor. Para poder realizar esto, debemos
poner a true la línea <parameter name="hotupdate">false
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
119
</parameter> .En este fichero de configuración también se pueden cambiar el
usuario y el password por defecto, lo cual se recomienda por motivos de seguridad.
5.4. Configuración del Cliente Web
Tal y como se dijo en la sección correspondiente a la instalación del cliente web, éste
tiene un fichero de configuración, en el cuál se indicarán una serie de parámetros
necesarios para que cliente y servicio se puedan comunicar correctamente. En realidad
ese conjunto de parámetros indica la ruta del fichero de descripción del servicio (wsdl),
dividido en dos $place y $clinical_wsdl para permitir más facilidad de cambio.
Una vez configurada la aplicación correctamente ya puede utilizarse sin ningún
problema.
6. Instalación y Configuración de dcm4che
A continuación se detalla el proceso de despliegue de las librerías dcm4che tanto en
Axis2 como en el Cliente Web
6.1.1. dcm4che en Axis2
Esta sección realiza una breve explicación de cómo instalar o configurar axis2 para que
éste soporte las librerías dc4che.
La instalación es muy simple puesto que, al igual que se hizo con los conectores de la
base de datos, tan solo hay que copiar el contenido (todos los ficheros .jar) de la carpeta
lib/, que se encuentra dentro de la raíz donde se haya descargado el Kit de desarrollo, a
la carpeta lib/ dentro de axis2.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 4
120
Una vez realizado el paso anterior, es necesario reiniciar Apache-Tomcat para que
Axis2 reconozca las librerías y todo funcionará correctamente. Por tanto no es
necesario configurar nada más.
6.1.2. dcm4che en el Cliente Web
La instalación en la parte del cliente es muy similar a la instalación en Axis2, pero en
este caso además de copiar el contenido de la carpeta lib/ hay que copiar también el
contenido de la carpeta etc/. Para ello se debe crear una carpeta llamada dcm4che/
dentro del directorio correspondiente a las librerías en el lado del cliente y una vez
realizada la operación copiar las dos carpetas anteriores dentro de la que se ha creado.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 5
121
Capitulo 5:
Guía de Usuario
1. Introducción
Este capítulo pretende servir de guía al usuario final. Como ya se ha explicado en
capítulos anteriores la interfaz de usuario está basada en una aplicación web codificada
en HTML y PHP5 la cual tiene una interfaz SOAP que permite la comunicación con el
Servicio e invocar los diferentes métodos desplegados en él.
A continuación se muestran las diferentes secciones que corresponden a la aplicación
cliente. Para acceder a la página principal del Cliente Web, usar la siguiente dirección:
http://localhost/dicom_ws/
2. Acceso a la Aplicación
En primer lugar se presenta la página principal del sistema, que no es la página
principal que se verá en la siguiente sección, sino que es la página de acceso al sistema
y en la que el usuario debe introducir su nombre de usuario y contraseña.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 5
122
Figura 5.1: Cliente Web - Página de Acceso al Sistema
Como ya se ha indicado en esta primera página el usuario debe introducir su nombre de
usuario y su password y pulsar en enviar, con lo que se envía al servidor esta
información mediante la interfaz SOAP. Si todo va bien se accede a la sección principal
de la aplicación si no la aplicación devolverá un error indicando que el usuario no es
correcto y debe identificarse de nuevo.
Figura 5.2: Cliente Web - Error de Acceso al Sistema.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 5
123
3. Página Principal
Si todo va bien en la sección anterior, es decir, si el sistema valida el usuario que está
accediendo a la aplicación, se muestra la sección principal, la cual se puede ver en la
siguiente figura.
Figura 5.3: Cliente Web - Sección Principal del Sistema: Listar Pacientes.
Como se puede observar en la sección principal se muestran las diferentes operaciones
que se pueden realizar en el servidor. Se tiene una sección que permitirá mostrar un
listado de los pacientes ordenados éstos de diferentes formas y a elección del usuario
(se verá en una sección posterior).
Además en esta página principal también se ofrece la posibilidad de insertar nuevos
pacientes de tres formas diferentes: mediante un fichero DICOM, mediante un
formulario web o a partir de una imagen digital. Esto es lo que se muestra en la
siguiente figura:
Servicio Web para la Gestión de Imágenes Médicas Capítulo 5
124
Figura 5.4: Cliente Web - Sección Principal del Sistema: Insertar Pacientes.
Por último también se tiene la posibilidad de seleccionar un paciente en concreto
mediante su identificador de paciente de modo que la aplicación muestre los datos de
dicho paciente (se verá en la sección del paciente). Esto es la sección que se muestra en
la siguiente figura:
Figura 5.5: Cliente Web - Sección Principal del Sistema: Buscar Paciente.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 5
125
Por otro lado también se tienen en esta sección dos botones en la parte superior de la
pantalla, de los cuales uno es para salir del sistema y el otro sirve para llevar al usuario
a la página de administración del sistema que se verá después. Estos botones estarán
presentes en todas las páginas que se vean a partir de ahora.
4. Página de Paciente
A continuación se muestra un ejemplo de los datos que se pueden ver en la sección del
paciente, a esta sección se puede llegar bien introduciendo un identificador en la
sección principal, donde pone selección de paciente, o bien a través del listado de
pacientes que se verá después. En esta sección tendremos dos subsecciones una
referente a la información general del paciente y otra relacionada con las pruebas
realizadas incluyendo una vista preliminar de las mismas.
Figura 5.6: Cliente Web - Página de Paciente: Información General
En esta subsección o pestaña también se puede editar los datos del paciente pulsando
en el botón ‘Editar Ficha’, mediante el cual aparecerá un formulario para poder
modificar los datos del paciente en cuestión.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 5
126
Figura 5.7: Cliente Web - Página de Paciente: Información General – Editar Ficha
Por último se tiene la sección con las pruebas que se le han realizado al paciente en
cuestión, incluyendo una vista previa de las pruebas realizadas,
Figura 5.8: Cliente Web – Página de Paciente: Pruebas Realizadas
Servicio Web para la Gestión de Imágenes Médicas Capítulo 5
127
5. Página de la Prueba
Ahora se muestra la página de usuario que presenta al usuario final los datos relativos
a la prueba realizada al paciente de estudio. Esta página está compuesta por 5 pestañas,
una relacionada con los datos generales del paciente y de la prueba, otra relacionada
con la serie en cuestión dentro de la prueba, otra pestaña con opciones de visualización
y por últimos dos pestañas relacionadas con los posibles diagnósticos y observaciones.
La Pestaña relacionada con la información general de la prueba y el paciente de estudio
es la que se muestra a continuación.
Figura 5.9: Cliente Web - Página de la Prueba de un Paciente: Información General.
En la imagen se puede ver la página de la prueba, en ella se muestran los datos del
paciente y se describe la prueba realizada, continuación se muestran figuras
relacionadas con el resto de pestañas de esta sección.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 5
128
Figura 5.10: Cliente Web - Página de la Prueba de un Paciente: Series.
Figura 5.11: Cliente Web - Página de la Prueba de un Paciente: Opciones de Visualización
Servicio Web para la Gestión de Imágenes Médicas Capítulo 5
129
Figura 5.12: Cliente Web - Página de la Prueba de un Paciente: Diagnósticos
Figura 5.13: Cliente Web - Página de la Prueba de un Paciente: Observaciones
6. Página del Fichero
En este punto se muestra la página que se encarga de mostrar las imágenes tomadas a
los pacientes a tamaño real, aunque se pueden escalar para facilitar al usuario el
observarlas y poder añadir un diagnóstico o alguna observación en la sección anterior.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 5
130
En esta página también se facilita al usuario que pueda descargar el fichero Dicom
correspondiente al estudio que está viendo, para así conservarlo de forma local en su
equipo.
Figura 5.14: Cliente Web - Página para la visualización de las Imágenes.
Por otro lado también se puede ver el contenido de la cabecera del fichero DICOM o
descargar el mismo:
Figura 5.15: Cliente Web - Página Visualización de Cabecera de Imágenes DICOM.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 5
131
7. Página para Insertar Pacientes
Esta sección permite al usuario final (no tiene porque estar situado en el mismo centro
en el que se encuentra el servicio) insertar nuevos pacientes en el sistema. En la sección
se proporcionan tres formas; una primera forma es mediante un formulario, es decir se
rellena dicho formulario con los datos del paciente y se envía mediante SOAP hasta el
servicio para que éste inserte los datos en la base de datos. En este caso no se envía
ninguna imagen hacia el servicio solo se inserta un paciente en la base de datos.
Una segunda opción es insertar un paciente nuevo mediante fichero Dicom, es decir, se
puede insertar un nuevo paciente enviando al servicio un fichero dcm, el cual contiene
los datos del paciente, el servicio interpretará dicho fichero e insertará los datos
correspondientes.
La última opción es la inserción de pacientes mediante imágenes digitales, esto es,
imágenes tomadas desde una cámara digital por ejemplo. Estas Imágenes son
convertidas a formato DICOM previamente a ser insertadas, por lo que la imagen que
se inserta realmente se comporta como cualquier otra imagen en formato DICOM y la
información del paciente va en la cabecera de dicho fichero.
A continuación mostramos una serie de imágenes donde se pueden ver los diferentes
formularios de inserción de pacientes existentes en la aplicación:
Servicio Web para la Gestión de Imágenes Médicas Capítulo 5
132
Figura 5.16: Cliente Web - Página para la Inserción de Ficheros DICOM.
Figura 5.17: Cliente Web - Página para la Inserción de Fichas de Pacientes.
Figura 5.18: Cliente Web - Página Inserción de Pacientes mediante Imágenes Digitales.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 5
133
8. Página para Listar Pacientes
Esta página muestra en forma de listado los pacientes existentes en la base de datos.
En la sección principal se podía indicar si se quería que la lista estuviera ordenada, en
sentido ascendente o descendente, según algunos campos identificativos de los
pacientes como pueden ser el ID, el DNI, el Nombre, los Apellidos o la Fecha de
Nacimiento. También se indicaba el número de usuarios que se querían mostrar, es
decir el número de filas que contendrá la tabla resultado. Como resultado obtendremos
varias páginas si el número de pacientes en la base de datos es superior al número de
resultados por página indicado.
A continuación se muestra una imagen que permitirá hacerse una idea de lo comentado
en el párrafo anterior.
Figura 5.19: Cliente Web - Página con el Listado de Pacientes.
9. Página para la Administración del Sistema
Esta es la última sección que conforma la Aplicación de Cliente de pruebas del Servicio.
A ella se puede entrar desde cualquier sección de la aplicación seleccionando el icono
Servicio Web para la Gestión de Imágenes Médicas Capítulo 5
134
. Esto llevará a la página de Administración del Sistema, previa autenticación del
administrador, que se muestra a continuación:
Figura 5.20: Cliente Web - Sección de Administración del Sistema: Listar Usuarios
Figura 5.21: Cliente Web - Sección de Administración del Sistema: Insertar Usuarios
Como se ve en la figura 5.13 esta página es muy similar a la principal, básicamente
contiene dos subsecciones; una subsección para insertar nuevos usuarios, que consiste
Servicio Web para la Gestión de Imágenes Médicas Capítulo 5
135
en un formulario con una serie de campos a rellenar, de los cuales el más importante es
el rol de usuario. Existen 2 roles de usuarios, está el rol de administrador, el cual
tendrá control absoluto del servicio y podrá añadir nuevos usuarios al sistema, y por
otro lado está el rol de usuario, que sólo permite la visualización de imágenes y la
inserción de observaciones y diagnósticos.
En segundo lugar hay una sección que muestra un listado con los usuarios que existen
en el sistema. Esta sección es similar a la de los pacientes por lo que no hay nada nuevo
que añadir.
Figura 5.22: Cliente Web - Sección de Administración del Sistema - Listado de Usuarios
Servicio Web para la Gestión de Imágenes Médicas Capítulo 6
136
Capítulo 6:
Conclusiones y Trabajo Futuro
1. Conclusiones tras la Realización del Proyecto
Este punto pretende recoger las conclusiones a las que se ha llegado tras la realización
del proyecto. Se analizará si se han cumplido o no, y en qué medida, los objetivos que
se marcaron al inicio del mismo.
En la motivación para el desarrollo de este proyecto fin de carrera se indicó que
actualmente los sistemas de adquisición de imágenes existentes en los centros
hospitalarios suelen ser sistemas propietarios y que normalmente siguen una
arquitectura totalmente centralizada. Además se vio que no daban cobertura a todas las
disciplinas del ámbito de la medicina, es decir, que existen servicios en medicina que no
pueden apoyarse en el diagnóstico basado en imagen, no tienen soluciones PACS, al
menos no de forma que las imágenes singan estándares, por no existir maquinaria de
adquisición de imágenes especializadas como en otras disciplinas.
Una vez recordada la motivación del proyecto se puede destacan dos aspectos; uno es la
problemática relacionada con el uso actual de sistemas centralizados y propietarios y
otro está relacionado con la posibilidad de dar cobertura a la hora de diagnosticar a
servicios en medicina que no disponen de maquinaria especifica de adquisición de
imágenes. Por tanto, tras analizar todo lo anterior se pensó en desarrollar un servicio,
basado en servicios web, que tratara de remediar en la medida de lo posible los dos
aspectos señalados antes.
En relación con la problemática de sistemas centralizados y propietarios, se puede
comprobar que el servicio implementado soluciona dicha problemática ya que usa la
Servicio Web para la Gestión de Imágenes Médicas Capítulo 6
137
tecnología de servicios web como medio de comunicación. Al utilizar Servicios Web se
consigue tener una interfaz abierta de comunicación, que además en el caso de este
proyecto está basada en estándares, lo cual ofrece importantes beneficios. Debido a lo
anterior los usuarios tienen una forma de ejecutar operaciones en equipos de forma
remota y totalmente transparente a ellos, además el uso de una interfaz abierta de
comunicación ofrece la posibilidad de creación de nuevos “clientes” siempre y cuando
éstos se adecuen a la interfaz definida en el servicio.
Se ha comentado que el servicio está basado en estándares, a continuación se detallan
una serie de aspectos relacionados con ese hecho que han sido importantes para la
implementación de la interfaz del servicio. Se ha intentando diseñar una interfaz lo
más “estándar” posible, al menos, en lo relacionado con la carga y acceso a las
imágenes, para ello se ha utilizado la recomendación CIAS como se vio en el Capítulo
3. Pero a pesar de los esfuerzos por intentar aplicar las diferentes definiciones de
interfaces definidas en dicha recomendación no se pudo implementar de forma
completa debido a que dicha recomendación fue elaborada para CORBA y no para
Servicios Web, lo cual introdujo problemas de compatibilidad entre tipos de datos de
una arquitectura y otra. Finalmente se intentó seguir la misma estructura para la
interfaz aunque utilizando tipos de datos de los Servicios Web.
A pesar de la problemática descrita anteriormente en relación a incompatibilidad de los
tipos de datos entre una arquitectura y otra, se puede concluir que el servicio
desarrollado soluciona la problemática de los sistemas centralizados y propietarios, ya
que ofrece una interfaz abierta, y además da pie al uso de otras tecnologías de
computación distribuida actualmente en desarrollo, como los sistemas de computación
en Grid (estos sistemas se basan en los Servicios Web).
Por otro lado se tenía el problema de intentar dar cobertura a todas las disciplinas
médicas, permitiendo el diagnóstico mediante imagen. Para ello el servicio
implementado incluye una herramienta capaz de convertir imágenes digitales en
formato JPEG (formato más usual actualmente en cámaras fotográficas digitales,
Webcams, etc.) a formato DICOM. Es decir, el sistema permite al usuario final
mediante un formulario web (con datos relativos al paciente, al médico y una o más
imágenes en formato digital jpg) formar un fichero DICOM estándar con el estudio
Servicio Web para la Gestión de Imágenes Médicas Capítulo 6
138
realizado. Lo que permite utilizar una solución abierta e integrable con otros sistemas
basados en DICOM. Además, se trata de una solución barata en cuanto a costes, ya que
no necesita de ningún sistema caro de adquisición de imágenes, tan solo una cámara.
En definitiva se puede concluir que el sistema desarrollado ofrece un servidor de
imágenes médicas que aunque centralizado tiene una interfaz abierta basada en
estándares y que permite administrar y gestionar los estudios que en él existen, dando
cobertura a todas las disciplinas médicas. Además facilita la integración con otros
sistemas de imágenes basados también en el estándar DICOM.
2. Trabajo Futuro
Este apartado pretende ofrecer una visión general sobre posibles líneas de continuación
en relación con el tema del proyecto. Se verán dos visiones; una centrada en el sistema
de gestión de imágenes médicas y otra centrada en un escenario futuro en el entorno
sanitario.
En relación al servicio de gestión de imágenes médicas, las tareas futuras a
corto/medio plazo podrían ser las que se detallan a continuación:
• Módulo WS-Grid: Este módulo pretende hacer evolucionar el servicio
desarrollado de la tecnología de Servicios Web a la tecnología de Servicios
Grid, lo cual permitirá una mejora considerable en cuanto a la ejecución de
tareas y capacidad de almacenamiento.
• Módulo de Autenticación en el Servicio: Este módulo pretende dar mayor
seguridad al servicio de forma que el usuario no solo tenga que identificarse
cuando quiere entrar en el sistema sino que una vez identificado el usuario
reciba un código de autenticación y sea ese código necesario para realizar
cualquier operación en el mismo. Por otro lado, también se podría evolucionar
la forma de autenticado desde usuario y contraseña a certificados digitales
usando el mismo criterio descrito antes.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 6
139
• Módulo de Realidad Virtual: Este módulo pretenderá integrar herramientas de
reconstrucción 3D a partir de imágenes DICOM almacenadas en el sistema y
cumplan con los requisitos para poder ser reconstruidas en 3D.
• Módulo para Gestión de Sesiones Clínicas: Este módulo pretenderá ofrecer una
forma alternativa de almacenar, gestionar y crear sesiones clínicas,
bibliográficas, teóricas, etc., tan importantes en la práctica médica de hoy día.
• Módulo Generador de Conocimiento: Este módulo permitirá crear documentos
en base a la información almacenada en el sistema.
Estos son tan solo algunos ejemplos de las posibles ampliaciones que se pueden
realizar al servicio propuesto.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 7
140
Capítulo 7:
Referencias Bibliográficas
1. Referencias
[1]. Payo Ollero J. Diseño e Implementación de un Servidor de Imágenes DICOM
con Interfaz WEB. Escuela Superior de Ingenieros. Universidad de Sevilla. 08-
2002.
[2]. DICOM Home Page (NEMA) [Recurso Electrónico Web].
Disponible en: http://dicom.nema.org/.
Última consulta Enero de 2008.
[3]. CIAS (Clinical Image Access Service Specification) [Recurso Electrónico Web].
Disponible en: http://www.omg.org/
Última consulta Enero de 2008.
[4]. World Wide Web Consortium (W3C) [Recurso Electrónico Web].
Disponible en: http://www.w3.org/.
Última consulta Enero de 2008.
[5]. Apache Axis2 [Recurso Electrónico Web]. Disponible en:
http://ws.apache.org/axis2/.
Última consulta Enero de 2008.
[6]. Apache Tomcat [Recurso Electrónico Web].
Disponible en: http://tomcat.apache.org/.
Última consulta Enero de 2008.
[7]. Apache Friend - Xampp [Recurso Electrónico Web].
Disponible en: http://www.apachefriends.org/en/xampp.html.
Última consulta Enero de 2008.
Servicio Web para la Gestión de Imágenes Médicas Capítulo 7
141
[8]. PosrgreSQL [Recurso Electrónico Web]
Disponible en: http://www.postgresql.org/.
Última consulta Enero de 2008.
[9]. Schildt H. Java 2: Manual de Referencia. Madrid: McGraw-Hill Interamericana
de España; 2001
[10]. PHP: Hipertext Preprocessor [Recurso Electrónico Web].
Disponible en: http://www.php.net/.
Última consulta Enero de 2008.
[11]. NuSOAP – SOAP Toolkit for PHP [Recurso Electrónico Web].
Disponible en: http://sourceforge.net/projects/nusoap/.
Última consulta Enero de 2008.
[12]. JavaScript, Wikipedia [Recurso Electrónico Web].
Disponible en: http://es.wikipedia.org/wiki/JavaScript.
Última consulta Enero de 2008.
[13]. Open Source Clinical Image and Object Management [Recurso Electrónico
Web]. Disponible en: http://www.dcm4che.org/.
Última consulta Enero de 2008.
[14]. The Perl Directory [Recurso Electrónico Web].
Dispobible en: http://www.perl.org/.
Última consulta Enero de 2008.
Top Related