Download - Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

Transcript
Page 1: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 2: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

A mis padres, mi novia y mi hermana

que siempre estuvieron ahí para apoyarme.

Page 3: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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í.

Page 4: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 5: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 6: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 7: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 8: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 9: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 10: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 11: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 12: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 13: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 14: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 15: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 16: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 17: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 18: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 19: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 20: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 21: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 22: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 23: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 24: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 25: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 26: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 27: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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).

Page 28: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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)

Page 29: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 30: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 31: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 32: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 33: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 34: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 35: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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:

Page 36: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 37: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 38: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 39: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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;

Page 40: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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,

Page 41: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 42: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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() :

Page 43: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 44: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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 ( ).

Page 45: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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:

Page 46: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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);

};

Page 47: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 48: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 49: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 50: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 51: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 52: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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:

Page 53: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 54: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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);

Page 55: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 56: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 57: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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() :

Page 58: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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);

Page 59: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 60: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 61: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 62: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 63: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 64: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 65: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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);

Page 66: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 67: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 68: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 69: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 70: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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:

Page 71: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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:

Page 72: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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:

Page 73: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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);

Page 74: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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);

Page 75: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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:

Page 76: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 77: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 78: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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:

Page 79: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 80: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 81: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 82: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 83: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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:

Page 84: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 85: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 86: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 87: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 88: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 89: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 90: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 91: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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:

Page 92: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 93: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 94: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 95: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 96: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 97: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 98: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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-

Page 99: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 100: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 101: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 102: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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:

Page 103: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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:

Page 104: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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:

Page 105: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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:

Page 106: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 107: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 108: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 109: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 110: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 111: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 112: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 113: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 114: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 115: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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:

Page 116: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 117: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 118: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 119: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 120: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 121: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 122: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 123: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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:

Page 124: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 125: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 126: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 127: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 128: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 129: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 130: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 131: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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:

Page 132: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 133: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 134: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 135: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 136: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 137: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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

Page 138: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 139: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 140: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.

Page 141: Proyecto Fin de Carrera - Universidad de Sevillabibing.us.es/proyectos/abreproy/11799/fichero/Memoria...Proyecto Fin de Carrera Escuela Superior de Ingenieros Universidad de Sevilla

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.