Trabajo Fin de Grado Grado en Ingenier Ia Inform Atica

FACULTAD DE INFORMÁTICA
Trabajo fin de grado
Grado en Ingenierı́a Informática
Mención en Computación
Diseño y desarrollo de una herramienta para

la importación de estudios clı́nicos DICOM a
un repositorio centralizado (PACS)
Autor: Raúl Silguero Santos

Directores: Julián Alfonso Dorado De La Calle
Daniel Sánchez Marzoa
A Coruña, a 6 de septiembre de 2018.

Información general
Tı́tulo del proyecto: “Diseño y desarrollo de una herramien-

ta para la importación de estudios clı́ni-
cos DICOM a un repositorio centralizado
(PACS)”
Clase del proyecto: Proyecto clásico de ingenierı́a.
Mención: Computación
Nombre do alumno: Raúl Silguero Santos
Nombre de los directores: Julián Alfonso Dorado De La Calle

Daniel Sánchez Marzoa
Miembros del tribunal:
Fecha de lectura:
Cualificación:
A todas las personas que me han
ayudado a conseguir mis metas

Agradecimientos
En primer lugar querrı́a agradecer a mis directores de proyecto don Julián
Alfonso Dorado De La Calle y don Daniel Sánchez Marzoa su
apoyo incondicional desde el primer momento, respondiendo a mis dudas y
ayudándome en todo momento, por su atención y guı́a durante todos estos
meses, sin ellos no hubiera sido posible llevar a cabo este proyecto.
A todo el personal de la empresa M3M por la oportunidad que me han
dado de realizar un proyecto en un entorno profesional, además de por su ayuda
y amabilidad desde el primer dı́a.
A mis padres Elena y Óscar, por darme esta oportunidad y hacerme ver
las cosas importantes de la vida, ası́ como enseñarme a valorarlas y apoyarme
incondicionalmente para que siempre dé lo mejor de mi en lo que haga, sin
vosotros no hubiera llegado hasta aquı́.
A mi hermano Dani, por siempre sacarme una sonrisa y haber compartido
este viaje a mi lado tanto en los buenos momentos como en los malos.
A toda mi familia, en especial a mi madrina Ana y a mi tı́o Carlos por
haberme iniciado en este mundo de la informática, con paciencia y siempre
dispuestos a darme opinión, consejos y oportunidades.
A Chrı́stell, por todo el cariño, paciencia y fuerzas que me has y sigues
dando cada dı́a. Gracias por no dejar que me rindiese nunca, por ayudarme a
mejorar mis puntos débiles y hacer que me sienta orgulloso de mi trabajo.
A los hermanos que me llevo de esta facultad: Carlos, Martı́n, Alva-
ro y Jose, habéis hecho que los recuerdos que me llevo de la carrera sean
inolvidables.
A todos mis amigos y compañeros que me han apoyado, ayudado y com-
partido momentos memorables durante estos últimos años.
Raúl.
Resumen
El aumento del número de clı́nicas y hospitales privados en nuestro paı́s, ası́
como el creciente número de profesionales del sector médico que se especializan
en una de sus ramas , presenta ante la sociedad una ingente cantidad de op-
ciones para decidir dónde realizar sus pruebas médicas. Esta situación provoca
que si cambiamos de hospital o consultamos a un experto para obtener una
segunda opinión sobre nuestro caso médico, por ejemplo, estos nuevos estudios
no podrı́an ser unificados con posibles estudios anteriores del paciente, pues
contienen diferentes datos de identificación para el mismo paciente, debido a
que cada centro sanitario identifica a sus pacientes de manera independiente.
Ası́, nace la necesidad de resolver este problema para que los centros médi-
cos puedan incorporar estudios clı́nicos no realizados en sus instalaciones de
cualquier paciente al posible historial que pudiera tener ese paciente con ellos.
Este proyecto consiste en la realización del diseño e implementación de
un sistema que permita la importación de estudios clı́nicos a un repositorio
centralizado. El integrador de estudios, como llamaremos a la herramienta,
es capaz de leer estudios DICOM (Estándar reconocido mundialmente para
el intercambio de imágenes médicas) de diferentes fuentes (CD,DVD,USB...)
extrayendo información de los mismos para poder comparar estos datos con
los presentes en el PACS (Sistema de archivado y transmisión de imágenes
médicas) del centro médico en busca de pacientes a los que pueda pertenecer
el estudio. Una vez realizada esta comparación, al usuario se le mostrarán
todos los posibles pacientes que son candidatos a ser el dueño real de ese
nuevo estudio clı́nico, pudiendo ası́, elegir a quien le pertenece, con lo que el
integrador realizará las modificaciones necesarias al estudio a nivel DICOM
y lo enviará al PACS para que se almacene con el resto de estudios que el
paciente tiene en su centro médico.
Lista de palabras clave

Estudio clı́nico, historial médico, aplicación web, medicina, paciente, hos-
pital, DICOM, PACS, entrada y salida, dispositivos de almacenamiento.
viii
Índice general
1. Introducción 1
1.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Problemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . 4
2. Fundamentos tecnológicos 5
2.1. Base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. BackEnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3. Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.4. JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Gestión de la entrada/salida de dispositivos de almacenamiento 8
2.3.1. .Net y C# . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Front End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1. JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.3. CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5. DICOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.1. Modelo de datos . . . . . . . . . . . . . . . . . . . . . . 11
2.5.2. Elementos DICOM . . . . . . . . . . . . . . . . . . . . . 11
2.5.3. Objetos DICOM . . . . . . . . . . . . . . . . . . . . . . 12
2.5.4. Servicios DICOM . . . . . . . . . . . . . . . . . . . . . . 13
2.5.5. DICOMDIR . . . . . . . . . . . . . . . . . . . . . . . . . 15
ix
x ÍNDICE GENERAL
2.5.6. Quick DICOM Editor . . . . . . . . . . . . . . . . . . . . 16

2.5.7. CONQUEST Dicom . . . . . . . . . . . . . . . . . . . . 17
3. Estado de la cuestión 19
3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3. Medavis DICOM importer . . . . . . . . . . . . . . . . . . . . . 21
3.4. Consideraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4. Metodologı́a de desarrollo 25
4.1. Metodologı́a seleccionada . . . . . . . . . . . . . . . . . . . . . . 25
4.1.1. Fases de cada iteración . . . . . . . . . . . . . . . . . . . 26
5. Planificación, recursos y costes 27

5.1. Asignación de recursos . . . . . . . . . . . . . . . . . . . . . . . 27
5.2. Planificación inicial . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.1. Iteraciones del proyecto . . . . . . . . . . . . . . . . . . . 28
5.2.2. Planificación económica inicial . . . . . . . . . . . . . . . 31
5.3. Planificación final . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.1. Planificación económica final . . . . . . . . . . . . . . . . 33
6. Sistema desarrollado 35
6.1. Análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . 36
6.3. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.3.1. Estructura de los directorios . . . . . . . . . . . . . . . . 37
6.3.2. Configuración . . . . . . . . . . . . . . . . . . . . . . . . 37
6.3.3. Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.3.4. Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3.5. Iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.4. Iteración 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.4.1. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.4.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.4.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . 52
ÍNDICE GENERAL xi
6.4.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.5. Iteración 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.5.1. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.5.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.5.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . 58
6.5.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.6. Iteración 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.6.1. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.6.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.6.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . 69
6.6.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.7. Iteración 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.7.1. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.7.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.7.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . 80
6.7.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.8. Iteración 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.8.1. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.8.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.8.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . 87
6.8.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7. Conclusiones 93
8. Trabajo futuro 95
Referencias 97
Apéndices 101
A. Manual de instalación 103

A.1. Software necesario . . . . . . . . . . . . . . . . . . . . . . . . . 103
A.2. Instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
A.2.1. MySql . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
xii ÍNDICE GENERAL
A.2.2. Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

A.2.3. Apache Server . . . . . . . . . . . . . . . . . . . . . . . . 104
B. Manual de Usuario 107

B.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
B.2. Pasos para la integración de un estudio DICOM . . . . . . . . . 108
B.3. Aplicación web . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
B.4. Aplicación de gestión de la E/S de dispositivos de almacenamiento114
xiv ÍNDICE GENERAL
Índice de figuras
2.1. Estructura del modelo de datos DICOM . . . . . . . . . . . . . 11

2.2. Atributos DICOM . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Ejemplo de elementos DICOM . . . . . . . . . . . . . . . . . . . 12
2.4. Ejemplo de IOD . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5. Estructura del DICOMDIR . . . . . . . . . . . . . . . . . . . . 16
2.6. Ejemplo de lectura de DICOMDIR con Quick DICOM Editor . 17
2.7. Ejemplo de base de datos en CONQUEST Dicom . . . . . . . . 18
3.1. Dispositivo Integrity . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2. Vista de detalles del estudio . . . . . . . . . . . . . . . . . . . . 20
3.3. Vista de reconciliación de estudios . . . . . . . . . . . . . . . . . 21
3.4. Mediavis DICOM Importer . . . . . . . . . . . . . . . . . . . . . 22
5.1. Planificación temporal inicial Iteración 1 . . . . . . . . . . . . . 29

5.6. Planificación económica inicial . . . . . . . . . . . . . . . . . . . 31
5.7. Planificación temporal final Iteración 1 . . . . . . . . . . . . . . 31
5.12. Planificación económica final . . . . . . . . . . . . . . . . . . . . 33
xv
xvi ÍNDICE DE FIGURAS
6.1. Arquitectura General . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2. Entidad relación . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3. Diseño inicial de la página principal de la web . . . . . . . . . . 40
6.4. Diseño inicial de la página de matching automático de la web . . 40
6.5. Diseño inicial de la página de matching manual de la web . . . . 41
6.6. core/model/patient . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.7. core/model/patientService . . . . . . . . . . . . . . . . . . . . . 44
6.8. core/model/patientMod . . . . . . . . . . . . . . . . . . . . . . 45
6.9. core/model/patientModService . . . . . . . . . . . . . . . . . . 46
6.10. core/model/study . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.11. core/model/studyService . . . . . . . . . . . . . . . . . . . . . . 47
6.12. core/model/studyMod . . . . . . . . . . . . . . . . . . . . . . . 48
6.13. core/model/studyModService . . . . . . . . . . . . . . . . . . . 49
6.14. utils/DirectoryActions . . . . . . . . . . . . . . . . . . . . . . . 50
6.15. dicom/services/DicomDirReader . . . . . . . . . . . . . . . . . . 51
6.16. Scripts SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.17. Estructura de la base de datos en MySQL Workbench . . . . . . 52
6.18. Estructura de los proyectos . . . . . . . . . . . . . . . . . . . . . 53
6.19. Paquete Paciente . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.20. Paquete Paciente Modificado . . . . . . . . . . . . . . . . . . . . 53
6.21. Paquete Estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.22. Paquete Estudio Modificado . . . . . . . . . . . . . . . . . . . . 54
6.23. Paquete Servicio de la entidad Paciente . . . . . . . . . . . . . . 54
6.24. Paquete Servicio de la entidad Paciente Modificado . . . . . . . 54
6.25. Paquete Servicio de la entidad Estudio . . . . . . . . . . . . . . 54
6.26. Paquete Servicio de la entidad Estudio Modificado . . . . . . . . 54
6.27. Módulo Utils . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.28. Estructura de la carpeta config . . . . . . . . . . . . . . . . . . 55
6.29. Excepciones creadas . . . . . . . . . . . . . . . . . . . . . . . . 55
6.30. Tests del módulo Core . . . . . . . . . . . . . . . . . . . . . . . 56
6.31. Lista de pacientes en la base de datos . . . . . . . . . . . . . . . 56
6.32. Lista de estudios en la base de datos . . . . . . . . . . . . . . . 56
ÍNDICE DE FIGURAS xvii
6.33. core/model/mediaService . . . . . . . . . . . . . . . . . . . . . . 58
6.34. Carpeta config creada al ejecutar la clase App . . . . . . . . . . 58
6.35. core/app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.36. Pruebas funcionales SI (i) . . . . . . . . . . . . . . . . . . . . . 60
6.37. Pruebas funcionales SI (ii) . . . . . . . . . . . . . . . . . . . . . 60
6.38. Logs al insertar un paciente ya registrado en BD . . . . . . . . . 61
6.39. Logs al insertar un nuevo estudio a BD . . . . . . . . . . . . . . 61
6.40. Logs al leer una serie . . . . . . . . . . . . . . . . . . . . . . . . 61
6.41. Logs al leer una imagen e importarla . . . . . . . . . . . . . . . 61
6.42. MediaDetector/Program.cs . . . . . . . . . . . . . . . . . . . . . 63
6.43. core/rmi/PatientServiceRmi . . . . . . . . . . . . . . . . . . . . 64
6.44. core/rmi/PatientModServiceRmi . . . . . . . . . . . . . . . . . 65
6.45. core/rmi/StudyServiceRmi . . . . . . . . . . . . . . . . . . . . . 66
6.46. core/rmi/StudyModServiceRmi . . . . . . . . . . . . . . . . . . 67
6.47. core/rmi/MediaServiceRmi . . . . . . . . . . . . . . . . . . . . . 67
6.48. web/controller/StudyController y web/controller/StudyModCon-
troller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.49. web/controller/MediaController . . . . . . . . . . . . . . . . . . 69
6.50. web/dto/StudyDTO y web/dto/StudyModDTO . . . . . . . . . 70
6.51. web/conversor/StudyToStudyDtoConversor y web/conversor/S-
tudyModToStudyModDtoConversor . . . . . . . . . . . . . . . . 70
6.52. Solución .NET MediaDetector . . . . . . . . . . . . . . . . . . . 71
6.53. Paquete Rmi en el módulo Core . . . . . . . . . . . . . . . . . . 71
6.54. Paquete Rmi en el módulo Web . . . . . . . . . . . . . . . . . . 71
6.55. Paquetes Conversor y Dto en el módulo Web . . . . . . . . . . 72
6.56. Paquete Controller en el módulo Web . . . . . . . . . . . . . . . 72
6.57. Carpeta Web en el módulo Web . . . . . . . . . . . . . . . . . . 73
6.58. Página principal de la web . . . . . . . . . . . . . . . . . . . . . 73
6.59. Página principal de la web, mostrando la segunda página de
estudios importados . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.60. Página principal de la web, ordenando estudios por nombre del
paciente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.61. Acción de borrar un estudio . . . . . . . . . . . . . . . . . . . . 74
xviii ÍNDICE DE FIGURAS
6.62. Comprobación al borrar un estudio . . . . . . . . . . . . . . . . 74

6.63. Opción inspeccionar, fichero index.html de la aplicación web . . 75
6.64. Carpeta xml dentro de la estructura de directorios de la herra-
mienta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.65. dicom/utils/Config.java . . . . . . . . . . . . . . . . . . . . . . . 77
6.66. dicom/utils/NetworkConfig.java . . . . . . . . . . . . . . . . . . 77
6.67. dicom/utils/StoreConfig.java . . . . . . . . . . . . . . . . . . . . 77
6.68. dicom/utils/QueryConfig.java . . . . . . . . . . . . . . . . . . . 78
6.69. dicom/utils/DicomStudy.java . . . . . . . . . . . . . . . . . . . 78
6.70. dicom/utils/DicomObjectDicomStudyConversor.java . . . . . . 79
6.71. dicom/utils/DicomFileMetadataReader.java . . . . . . . . . . . 79
6.72. dicom/services/QueryRetrieveSCU.java . . . . . . . . . . . . . . 79
6.73. dicom/services/store/StoreSCU.java . . . . . . . . . . . . . . . . 80
6.74. Estructura del paquete dicom/utils . . . . . . . . . . . . . . . . 81
6.75. Estructura de los servicios del módulo Dicom . . . . . . . . . . 81
6.76. Estructura de los tests del módulo Dicom . . . . . . . . . . . . 82
6.77. Interfaz e implementación del paquete dicom/facade . . . . . . . 84
6.78. Interfaz e implementación del servicio core/model/MatcherService 85
6.79. Interfaz e implementación del servicio RMI core/rmi/Matcher-
ServiceRmi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.80. Controlador web del servicio de Matching web/controller/Mat-
cherController . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.81. dicom/facade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.82. core/model/matcherService . . . . . . . . . . . . . . . . . . . . 87
6.83. core/rmi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.84. web/controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.85. Ación de ver un estudio . . . . . . . . . . . . . . . . . . . . . . 88
6.86. Almacenar estudio con el estudio presentado de forma automática 89
6.87. Almacenar estudio cuando no se encuentra ningún estudio de
forma automática . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.88. Pestaña Buscar, para la realización de búsquedas manuales . . . 90
6.89. Búsqueda manual, utilizando el campo ”Nombre Paciente” . . . 90
6.90. Búsqueda manual, realizada por el campo ”Fecha de nacimiento” 91
ÍNDICE DE FIGURAS xix
6.91. Acción de almacenar estudio recuperado a través de la búsqueda

manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.92. Pestaña de Histórico . . . . . . . . . . . . . . . . . . . . . . . . 91
A.1. Bats de arranque de la aplicación . . . . . . . . . . . . . . . . . 104

A.2. Bats de arranque de la aplicación, módulo Core . . . . . . . . . 104
A.3. Bats de arranque de la aplicación, módulo Web . . . . . . . . . 104
B.1. Página principal de la web, pestaña de Integrador de estudios . 108

B.2. Ación de ver un estudio . . . . . . . . . . . . . . . . . . . . . . 108
B.3. Almacenar estudio con el estudio presentado de forma automática109
B.4. Pestaña Buscar, para la realización de búsquedas manuales . . . 110
B.5. Búsqueda manual, utilizando el campo ”Nombre Paciente” . . . 111
B.6. Búsqueda manual, realizada por el campo ”Fecha de nacimiento”111
B.7. Acción de almacenar estudio recuperado a través de la búsqueda
manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
B.8. Ación de borrar un estudio . . . . . . . . . . . . . . . . . . . . . 113
B.9. Confirmación requerida a la hora de borrar un estudio . . . . . . 113
B.10.Pestaña de Histórico . . . . . . . . . . . . . . . . . . . . . . . . 113
B.11.Vista de la aplicación de consola para gestionar la entrada y
salida de dispositivos de almacenamiento de la aplicación . . . . 114
Capı́tulo 1
Introducción
El presente capı́tulo tiene como objetivo la presentación del contexto en el

que se encuentra este proyecto junto con los objetivos del mismo. Además, se
hará una breve introducción a cada capı́tulo de este Trabajo Fin de Grado.
1.1. Contexto
Llamamos imagen médica [1] al conjunto de técnicas y procesos usados
para crear imágenes del cuerpo humano, o partes de él, con propósitos clı́nicos
(revelar, diagnosticar o examinar enfermedades) o para la ciencia médica.
Sus inicios se remontan al 8 de noviembre de 1895 cuando el ingeniero
mecánico y fı́sico alemán Wilhelm Conrad Röntgen [2] produjo radiación elec-
tromagnética en las longitudes de onda correspondiente a los actualmente lla-
mados rayos X.
En el siglo XX se producen grandes avances tecnológicos en radiologı́a e im-
portantes descubrimientos en el diagnóstico, como son las ecografı́as (redujeron
la exposición del paciente a los rayos X), las tomografı́as axiales computariza-
das (TAC o TC, desde que en 1970 se diseñó el primer equipo de TC hasta
la actualidad, han ido sucediéndose diferentes generaciones que han mejorado
la rapidez y la calidad de la imagen) o las resonancias magnéticas( no utiliza
radiaciones ionizantes ni el aire ni el hueso son obstáculos).
Todos estos hitos en la historia de la imagen médica [3], sumados a la apa-
rición y al crecimiento de la infórmatica, supusieron el paso a la digitalización
de sus procesos de generación, transferencia y almacenamiento. Esto provocó
la necesidad de la creación de unos estándares sobre los formatos de la in-
formación médica y los protocolos de transferencia de esta información. Ası́,
en 1985 y mediante la NEMA (National Electrical Manufacturers Associa-
tion) [4] y el ACR (American College of Radiology) [5], se creó el estándar
1
2 1.2. Problemática
DICOM (Digital Imaging and Communication in Medicine) [6].

El estándar DICOM está pensado para el manejo, visualización, almace-
namiento, impresión y transmisión de imágenes médicas. En él se incluye un
formato digital de imagen, la definición de un formato de fichero y de un
protocolo de comunicación (TCP/IP) [7] de red para la comunicación entre
sistemas que tengan capacidad de recibir imágenes y datos de pacientes en
formato DICOM.
Una vez obtenidas las imágenes médicas, estas se almacenan en un sistema
de archivos y comunicación (PACS) [8]. La misión primordial del PACS es
que el conjunto de exploraciones de un paciente y sus informes, incluyendo
los anteriores, estén a disposición del médico para poder realizar los informes
radiológicos y utilizar las herramientas de diagnóstico necesarias.
Ası́, para que los médicos puedan tener a su disposición todos los estudios
clı́nicos que un paciente se haya hecho (en otro centro médico, en la consulta
privada de un especialista...) y por consecuente realizar mejores y más rápidos
diagnósticos, surge la necesidad de la creación de este software para poder
unificar todos los estudios clı́nicos de un paciente en el PACS de los centros
médicos.
1.2. Problemática
El problema radica en que cada centro médico dispone de un identificador
diferente para cada paciente, causando problemas cuando, por ejemplo, una
persona:
• Quiere una segunda opinión sobre el estudio clı́nico que se haya realizado
en un centro médico en concreto.
• Se realiza la prueba en un sitio diferente a donde se le realizará el

diagnóstico.
• Prefiere que sea un especialista el que revise sus pruebas médicas.
Los problemas vienen provocados porque los centros no pueden unificar

este nuevo estudio clı́nico con posibles estudios anteriores del paciente debido
a que estos contienen diferentes datos de identificación para el mismo paciente.
Todo esto podrı́a provocar que el médico tenga que realizar diagnósticos
sin toda la información necesaria, lo cual podrı́a derivar en diágnosticos lentos,
erróneos...
1. Introducción 3
Ası́, el importador de estudios que se presenta se encargarı́a de resolver

dicho problema para que los centros médicos puedan incorporar estudios clı́ni-
cos, de cualquier paciente, que no hayan sido realizados en sus instalaciones,
al posible historial que pudiera tener ese paciente con ellos.
1.3. Objetivos
Como se describe en la sección anterior, en este trabajo se pretende diseñar
e implementar una aplicación web que permita leer estudios DICOM de dife-
rentes fuentes (CD,DVD,USB...) extrayendo información de los mismos para
poder comparar estos datos con los presentes en el PACS del centro médico en
busca de pacientes a los que puede pertenecer el estudio.
Para conseguirlo, se han definido una serie de subobjetivos que nos permi-
tirán abordar el proyecto:
• Estudio del estándar DICOM de almacenamiento y comunicación de ima-

gen médica, incluyendo las herramientas que nos serán útiles para nues-
tros objetivos.
• Estudio del sistema de archivado y transmisión de imágenes médicas

(PACS).
• Estudio del proceso de entrada y salida de dispositivos de almacenamien-

to para la correcta lectura de los datos con estructura DICOM.
• Análisis de las tecnologı́as candidatas a ser usadas en el proyecto.
• Diseño e implementación de una aplicación de consola para la gestión de

la entrada/salida de dispositivos de almacenamiento (CD/DVD/USB..)
y la lectura del contenido de los mismos.
• Diseño e implementación de una aplicación web intuitiva y eficiente para

su uso en centros médicos, que permitirá:
– Visualizar los datos más caracterı́sticos de los estudios clı́nicos im-

portados.
– Comprobar las modificaciones realizadas anteriormente sobre estu-
dios clı́nicos importados.
– Unificar estudios de manera automática o manual.
4 1.4. Estructura de la memoria
1.4. Estructura de la memoria

La memoria se estructura en varios capı́tulos que se detallan a continuación:
1. Introducción: El presente capı́tulo donde se explican el contexto, la

problemática, los objetivos y la estructura del trabajo fin de grado.
2. Fundamentos tecnológicos: En este capı́tulo se listan las tecnologı́as

elegidas para el desarrollo de este trabajo.
3. Estado de la cuestión: Se realiza un análisis de las alternativas existen-

tes, similares a lo realizado en este trabajo, que se encuentran disponibles
en el mercado.
4. Metodologı́a de desarrollo: Se expone la metodologı́a usada en este

proyecto.
5. Planificación, recursos y costes: Se muestran más detalladamente

las tareas realizadas en el proyecto y se presentan los recursos necesarios
para llevarlas a cabo.
6. Sistema desarrollado: Análisis de requisitos y diseño general de la

aplicación, ası́ como su desarrollo en las iteraciones expuestas.
7. Conclusiones: Conclusiones referentes a la realización del trabajo fina-

lizado.
8. Trabajo futuro: Se lista una serie de ampliaciones o mejoras que se

podrı́an realizar sobre el trabajo en un futuro.
9. Referencias: Se incluyen todas las referencias bibliográficas utilizadas

en el proyecto.
10. Apéndices: Manual de uso e instalación de la aplicación.

Capı́tulo 2
Fundamentos tecnológicos
En este capı́tulo se analizan las tecnologı́as elegidas para la realización de

dicho proyecto. En primer lugar, se describirá la opción elegida para la base
de datos de la herramienta, después el backend [9], la entrada y salida de
dispositivos de almacenamiento, el frontend y finalmente se hablará más en
profundidad sobre el estándar DICOM.
2.1. Base de datos

Se va a emplear MySql [10] para implementar la base de datos de la apli-
cación.
MySql es un sistema de gestión de bases de datos relacional desarrollado por
Oracle Corporation y está considerada como la base datos de código abierto
más popular del mundo, sobre todo, para entornos de desarrollo web.
Las grandes ventajas de MySql, y por las cuales se ha elegido como el
almacenamiento persistente de la herramienta, son:
• Rapidez: Velocidad al realizar las operaciones, lo que le convierte en uno

de los gestores con mejor rendimiento.
• Eficiencia: Bajo coste en requerimientos para la elaboración de bases de

datos, ya que debido a su bajo consumo puede ser ejecutado en una
máquina con escasos recursos sin ningún problema.
• Fácil configuración, instalación y uso.
• Soporta gran variedad de Sistemas Operativos.
• Seguridad: El sistema flexible de autorización de MySql, permite algunos

o todos los privilegios de base de datos (como el privilegio de crear o
5
6 2.2. BackEnd
eliminar una base de datos) a usuarios especı́ficos o grupos de ellos.

Además, las contraseñas están cifradas.
• Escabilidad: MySql maneja bases de datos de hasta 50 millones de filas

o más. El lı́mite de tamaño de archivo predeterminado para una tabla es
de 4 GB, pero este se puede incrementar (si el sistema operativo puede
manejarlo) a un teórico lı́mite de 8 millones de terabytes (TB).
El mayor problema de MySql es que puede provocar problemas de integri-

dad en entornos de alta concurrencia en la modificación. Pero en el caso de esta
herramienta, una aplicacion web, existe baja concurrencia en la modificación
de datos y, en cambio, el entorno es intensivo en lectura de datos, lo que hace
a MySql ideal para el desarrollo de este proyecto.
Para realizar esta implementación de manera más sencilla, se va a utilizar
la herramienta MySql Workbench [11], la cual es una herramienta visual de
diseño de bases de datos que integra desarrollo de software, administración
de bases de datos, diseño de bases de datos, gestion y mantenimiento para el
sistema de base de datos MySQL. Además, nos servirá para realizar pruebas
para el correcto funcionamiento de la base de datos ası́ como de las operaciones
que interactuan con esta.
2.2. BackEnd
Se ha optado por una arquitectura Java [12] para el desarrollo del servidor
web de la aplicación.
2.2.1. Java
Lenguaje orientado a objetos muy completo y ampliamente utilizado por
su sencillez, portabilidad y gran cantidad de librerı́as.
Java es un lenguaje orientado a objetos, que fue diseñado especı́ficamente
para tener tan pocas dependencias de implementación como fuera posible. Es
uno de los lenguajes de programación más populares en uso, particularmente
para aplicaciones de cliente-servidor de web, lo cual es una de las causas por las
que Java presenta una gran cantidad de librerı́as, facilitando ası́ los desarrollos
en este lenguaje de programación.
Su sintaxis es la de C++ “simplificada”, lo cual lo convierte en un lenguaje
de programación muy fácil de aprender. Los creadores de Java partieron de la
sintaxis de C++ y trataron de eliminar de este todo lo que resultase complicado
o fuente de errores en este lenguaje. Esto provoca que no se puedan realizar
optimizaciones en el código, especialmente en cuanto a manejo de memoria,

que es completamente automático en Java.
Cabe destacar la librerı́a dcm4che [13], la cual es una colección de aplica-
ciones Open Source y utilidades para entidades médicas, las cuales han sido
desarrolladas en Java por su rendimiento y portabilidad. dcm4che incluye una
robusta y estricta implementación del estándar DICOM, lo que nos facilita el
uso de ”Tags”DICOM, objetos DICOM...
2.2.2. Maven
Maven [14] es una herramienta de software para la gestión y construcción
de proyectos Java [15]. Es similar en funcionalidad a Apache Ant, pero tiene
un modelo de configuración de construcción más simple, basado en un formato
XML.
Maven utiliza un Project Object Model (POM) para describir el proyec-
to de software a construir, sus dependencias de otros módulos y componentes
externos, y el orden de construcción de los elementos. Viene con objetivos pre-
definidos para realizar ciertas tareas claramente definidas, como la compilación
del código y su empaquetado.
Las partes del ciclo de vida principal del proyecto Maven son:
• compile: Genera los ficheros .class compilando los fuentes .java.
• test: Ejecuta los test automáticos de JUnit existentes, abortando el pro-

ceso si alguno de ellos falla.
• package: Genera el fichero .jar con los .class compilados.
• install: Copia el fichero .jar a un directorio de nuestro ordenador donde

maven deja todos los .jar. De esta forma esos .jar pueden utilizarse en
otros proyectos maven en el mismo ordenador.
• deploy: Copia el fichero .jar a un servidor remoto, poniéndolo disponible

para cualquier proyecto maven con acceso a ese servidor remoto.
Cuando se ejecuta cualquiera de los comandos maven, por ejemplo, si eje-

cutamos mvn install, maven irá verificando todas las fases del ciclo de vida
desde la primera hasta la del comando, ejecutando solo aquellas que no se
hayan ejecutado previamente.
82.3. Gestión de la entrada/salida de dispositivos de almacenamiento
2.2.3. Spring
Spring [16] es un framework para el desarrollo de aplicaciones y contenedor
de inversión de control, de código abierto para la plataforma Java.
La caracterı́stica principal es la inyección de dependencias a través de la
inversión de control. Spring está compuesto por varios módulos, sin embargo,
solo es necesario utilizar los que nos sirvan para la aplicación que estemos
desarrollando.
2.2.4. JUnit
JUnit [17] es un conjunto de clases (framework) que permite realizar la
ejecución de clases Java de manera controlada para poder evaluar si el funcio-
namiento de cada uno de los métodos de la clase se comporta como se espera.
2.3. Gestión de la entrada/salida de dispositi-

vos de almacenamiento
2.3.1. .Net y C#
.NET [18] es un framework de Microsoft que hace un énfasis en la transpa-
rencia de redes, con independencia de plataforma de hardware y que permite un
rápido desarrollo de aplicaciones. Basada en ella, la empresa intenta desarro-
llar una estrategia horizontal que integre todos sus productos, desde el sistema
operativo hasta las herramientas de mercado.
.NET Framework consta de dos componentes principales: Common Lan-
guage Runtime (CLR) y la biblioteca de clases de .NET Framework. Common
Language Runtime es el fundamento de .NET Framework, pues administra
la memoria, ejecución de subprocesos, ejecución de código, comprobación de
la seguridad del código, compilación y la posibilidad de comunicación entre
lenguajes bajo el estándar CLR. Esto permitirı́a utilizar diferentes lenguajes,
aprovechando los puntos fuertes de cada uno.
Lo que hace destacar a este framework por encima de otros son las amplı́as
guı́as y la facilidad para realizar operaciones de entrada y salida en equipos
Windows, uno de los requisitos de la herramienta.
Como lenguaje administrado por .NET se usará C# [19].
C dispone de una sintaxis básica derivada de C/C++ y utiliza el modelo
de objetos de la plataforma .NET, similar al de Java, aunque incluye mejoras
derivadas de otros lenguajes.
Es un lenguaje sencillo, moderno, orientado a objetos y a componentes,

siendo esta última cualidad una de las razones de mayor peso en su elección.
La orientación a componentes en C# significa que la propia sintaxis del len-
guaje incluye elementos propios del diseño de componentes que otros lenguajes
tienen que simular mediante construcciones más o menos complejas. Es decir,
C# permite definir cómodamente propiedades (similares a campos de acceso
controlado), eventos (asociación controlada de funciones de respuesta a noti-
ficaciones) o atributos (información sobre un tipo o sus miembros). Gracias a
esto se podrá gestionar los eventos de E/S de forma fácil y eficiente.
2.4. Front End
2.4.1. JavaScript
JavaScript [20] es un lenguaje de programación interpretado, dialecto del
estándar ECMAScript. Se define como orientado a objetos, basado en proto-
tipos, imperativo, débilmente tipado y dinámico.
Se utiliza, principalmente, en su forma del lado del cliente (front-end), im-
plementado como parte de un navegador web permitiendo mejoras en la inter-
faz de usuario y páginas web dinámicas. JavaScript se diseñó con una sintaxis
similar a C, aunque adopta nombres y convenciones del lenguaje de progra-
mación Java. Sin embargo, Java y JavaScript tienen semánticas y propósitos
diferentes.
Todos los navegadores modernos interpretan el código JavaScript integrado
en las páginas web.
2.4.2. HTML
HTML [21] o HyperText Markup Language (lenguaje de marcas de hiper-
texto), hace referencia al lenguaje de marcado para la elaboración de páginas
web. Es un estándar que sirve de referencia del software que conecta con la
elaboración de páginas web en sus diferentes versiones, define una estructura
básica y un código (denominado código HTML) para la definición de contenido
de una página web, como texto, imágenes, videos, juegos, entre otros. Es el
estándar que se ha impuesto en la visualización de páginas web y es el que
todos los navegadores actuales han adoptado.
El lenguaje HTML basa su filosofı́a de desarrollo en la diferenciación. Para
añadir un elemento externo a la página (imagen, vı́deo, script...), este no se
incrusta directamente en el código de la página, sino que se hace una referencia
a la ubicación de dicho elemento mediante texto. De este modo, la página web
10 2.5. DICOM
contiene solamente texto mientras que recae en el navegador web (interpretador

del código) la tarea de unir todos los elementos y visualizar la página final.
Al ser un estándar, HTML busca ser un lenguaje que permita que cualquier
página web escrita en una determinada versión, pueda ser interpretada de la
misma forma (estándar) por cualquier navegador web actualizado.
2.4.3. CSS
CSS [22] (siglas en inglés de Cascading Style Sheets), o en español ”Hojas
de estilo en cascada”, es un lenguaje de diseño gráfico para definir y crear la
presentación de un documento estructurado escrito en un lenguaje de marcado.
Es muy utilizado para establecer el diseño visual de los documentos web.
Junto con HTML y JavaScript, CSS es una tecnologı́a usada por muchos
sitios web para crear páginas visualmente atractivas, interfaces de usuario para
aplicaciones web y GUIs para muchas aplicaciones móviles.
CSS está diseñado principalmente para marcar la separación del contenido
del documento y la forma de presentación de este, caracterı́sticas tales como
las capas o layouts, los colores y las fuentes.
2.5. DICOM
En los inicios de la imagen médica, cada fabricante diseñaba sus productos
de manera independiente, creando sus propios formatos para almacenar infor-
mación y enviarla a otros equipos, lo cual provocaba una casi nula compati-
bilidad entre equipos de diferentes fabricantes. Ası́, viendo que era necesario
crear un estándar que permitise interacción entre difentes equipos y almacenar
información de estudios médicos, se creó el formato DICOM, en un esfuerzo
común entre la NEMA y el ACR.
Este estándar define un formato para almacenar información, ası́ como un
protocolo de comunicación basado en TCP-IP que permite la interacción entre
workstations, servidores e impresoras médicas por igual.
Aun ası́, el primer estándar DICOM importante es la versión 3.0, que fue
desarrollado en 1993, puesto que significó la aceptación de todos los fabrican-
tes del estándar DICOM. Desde entonces, y hasta el dı́a de hoy, el estándar
DICOM es usado en todos los hospitales y en cualquier material médico de
cualquier fabricante.
2.5.1. Modelo de datos

En la figura 2.1 se presenta el modelo de datos DICOM básico.
Figura 2.1: Estructura del modelo de datos DICOM
La base de un fichero DICOM es la información del paciente, el cual podrá

tener varios estudios. Estos estudios tendrán una modalidad (tipo de prueba
realizada) y múltiples series, con varias imágenes relacionadas entre sı́ por la
región del cuerpo a la que pertenecen o por el corte elegido.
Por ejemplo, un paciente se realiza un radiodiagnóstico. A la información de
este paciente se le añadirı́a un nuevo estudio, el cual tendrı́a como modalidad
TAC. Este nuevo estudio podrı́a contener tres series. Una con imágenes de
cortes axiales, otra con imágenes de corte sagital y una última con imágenes
del corte coronal.
2.5.2. Elementos DICOM

Un objeto DICOM está compuesto por elementos o atributos DICOM [23].
Cada uno de estos elementos contiene un Tag, un ”Tipo de Dato”llamado
VR (Value Representation), una longitud y un valor. DICOM codifica estos
elementos de la manera que se muestra en la figura 2.2:
Para explicar más en detalle los elementos DICOM, nos vamos a basar en
el ejemplo de la figura 2.3
• Tag: Todo elemento DICOM tiene un Tag que lo define de manera única
y está compuesto de dos números llamados grupo y elemento. Elementos
DICOM que estan relacionados entre ellos a veces tienen el mismo grupo
en su Tag. En el ejemplo podemos ver varios elementos del grupo 0028.
• Value Representation: Se representa como un código de dos carácte-

res. Define el tipo de dato del elemento. En el ejemplo vemos UI (Unique
12 2.5. DICOM
Figura 2.2: Atributos DICOM
Figura 2.3: Ejemplo de elementos DICOM
Identifier), US (Unsigned Short)... Aunque la recomendación es que este

elemento se defina explicitamente, como todo elemento tiene un Tag, este
ya define implicitamente el VR.
• Value Length: DICOM es un protocolo binario, por lo que los elementos

tienen longitud, y esta siempre es par (se les añade padding si es impar).
• Value Field: Indica el nombre del elemento, lo cual es más intuitivo

para los desarrolladores que el uso de los Tags.
2.5.3. Objetos DICOM

Las clases del modelo de datos DICOM se llaman clases SOP y son definidas
por IOD’s (Information Object Definition) [24]. Un IOD es una colección de
módulos, siendo un módulo una colección de elementos de una entidad de

información y que juntos representan algo. DICOM usa aquı́ dos conceptos
orientados a objetos, como son la composición y la reutilización, puesto que
estos módulos contienen partes que se comparten entre diferentes IOD’s.
Ası́, todos los objetos DICOM tienen que incluir el SOP Common Module
y módulos de las cuatro entidades de información más importantes: Paciente,
Estudio, Series e Imágenes. Además, todos las instancias DICOM que sean
Imágenes han de incluı́r también el módulo de Imagen Module. En la figura
2.4 veremos un ejemplo de un IOD.
En la columna Module se especifican los módulos, en la columna Reference
se detallan la definición de dicho módulo y en la columna Usage se define si se
debe de incluı́r siempre (M) o es opcional (U).
2.5.4. Servicios DICOM

DICOM ofrece un conjunto muy amplio de servicios. Siguiendo el estándar,
las operaciones para el intercambio de información médica pertenecen a los
servicios DIMSE [25] (DICOM Message Service Element). En el estándar se
diferencian dos grupos de servicios DIMSE, DIMSE-N y DIMSE-C, siendo
algunas de las operaciones de este último grupo las que se usarán en este
proyecto.
Para poder explicar estas operaciones, se debe indicar primero que todo
servicio DICOM implica la comunicación entre dos de las siguientes entidades:
• Service Class Provider (SCP): El nodo DICOM que provee el servicio

DICOM. Un ejemplo de esto podrı́a ser un servidor PACS que provee de
un servicio de almacenamiento a clientes DICOM.
• Service Class User (SCU): El nodo DICOM que usa el servicio DI-
COM. Un ejemplo de esto podrı́a ser una estación de trabajo que usa
el servicio de almacenamiento del servidor PACS para mandar imágenes
DICOM al archivo del servidor PACS.
Una nota importante cuando se habla de nodos en servicios DICOM es que

estos pueden realizar el rol de SCP o SCU según convenga. Una vez definidos
los nodos, se explicarán las operaciones DIMSE-C que se usarán en el proyecto:
• C-Store: El SCU manda objetos DICOM al SCP para su almacenamien-

to.
• C-Move: El SCU manda una petición al SCP para que le envı́e un

objeto DICOM a el o a otro SCU. En esta operación se puede ver el
14 2.5. DICOM
Figura 2.4: Ejemplo de IOD
comportamiento anteriormente mencionado de que un nodo en DICOM

puede actúar tanto de SCU como de SCP, puesto que el SCP actuará
ahora de SCU mandando una petición C-Store al SCU de destino.
• C-Find: El SCU trata de realizar una búsqueda entre los estudios del
SCP, mandando una serie de atributos en forma de string. El SCP de-
vuelve por cada emparejamiento una lista con los atributos requeridos y
sus valores.
A partir de estas operaciones y sus combinaciones, se podrán implementar

todas las funcionalidades requeridas en el proyecto, entre las cuales destaca la
operación Query&Retrieve.
Query&Retrieve, o Q&R, es la operación DICOM (no recogida en DIMSE
puesto que es una combinación de operaciones DICOM) que permite buscar
estudios en un PACS y recuperar uno de ellos. Para explicar más en detalle
esta operación, se dividirá en las dos fases de la misma:
• Query [26]: En esta fase se quiere recuperar una lista de estudios a partir
de una serie de atributos, con los que se pretende filtrar esta búsqueda.
Esto se realiza ejecutando una operacón C-FIND.
• Retrive [27]: En esta fase se quiere obtener uno de los estudios de entre los
que se encontraron en el anterior paso. Para esto, en primer lugar, se eje-
cuta una operación C-Move, siendo el destino el propio SCU que mandó
la petición. En este momento se puede observar una de las particulari-
dades de los nodos en servicios DICOM comentandas con anterioridad,
puesto que los roles del SCU y el SCP se invierten, siendo el antiguo
SCP el que lanza una petición C-Store (pasando a ser el nuevo SCU) al
antiguo SCU (convirtiéndose este en el nuevo SCP).
2.5.5. DICOMDIR
Existen dos maneras en las que aplicaciones DICOM pueden colaborar
entre ellas. Pueden comunicarse a través de conexiones TCP/IP o pueden
intercambiarse ficheros a través de algún medio fı́sico.
Por ejemplo, un paciente le entrega a su médico un CD diciéndole que con-
tiene ficheros DICOM con la información que este necesita para poder realizar
un diagnóstico. Si se tuviese más información que es, se tendrı́a que leer el CD
e ir mirando cada fichero, viendo si es un fichero DICOM, leyéndolo, descifran-
do que se encuentra dentro del mismo y si es lo que se estaba buscando. Pero
si el CD está hecho acorde a lo dictado en el estándar, este proceso se vuelve
mucho más sencillo. Lo único que se necesita es leer el fichero DICOMDIR [28],
encontrar los archivos del paciente contenidos en él y conseguir las referencias
a los ficheros DICOM que se están buscando. Ası́, el DICOMDIR es lo que
su propio nombre indica, un registro de directorios con información sobre los
ficheros DICOM del dispositivo de almacenamiento.
En la figura 2.5 se ejemplifica la estructura del DICOMDIR.
16 2.5. DICOM
Figura 2.5: Estructura del DICOMDIR
2.5.6. Quick DICOM Editor

Quick DICOM Editor [29] es una herramienta que nos permite:
• Ver los Tags DICOM de uno o varios ficheros.
• Modificar la información de un objeto DICOM
• Verter todos los Tags DICOM a un fichero de texto.
• Previsualizar imágenes
Todas estas funcionalidades serán muy útiles a la hora de comprobar que se

ha leı́do correctamente el DICOMDIR, pues con ella podemos ver la estructura
de este fichero y navegar por los distintos posibles pacientes, estudios, series e
imágenes (pudiendo visualizarlas) contenidos en él.
A continuación, en la figura 2.6, se muestra un ejemplo de la lectura de un
DICOMDIR con datos ficticios pero con estructura de datos real proporcionado
por la empresa. Como se puede comprobar, se permite acceder a la estructura
de datos de un fichero DICOMDIR y navegar por la estructura de Tags DICOM
del mismo, pudiendo observar todos los elementos DICOM de cada uno de los
objetos DICOM presentes, siguiendo el modelo de datos del estándar DICOM
en el que un paciente tiene estudios, que tienen series que incluyen imágenes.
Figura 2.6: Ejemplo de lectura de DICOMDIR con Quick DICOM Editor
2.5.7. CONQUEST Dicom

CONQUEST Dicom [30] es una potente herramienta que ofrece una amplia
variedad de funcionalidades DICOM, algunas de ellas son:
• Visualización y modificación de imágenes DICOM.
• Servicio de almacenamiento DICOM.
• Servicio de Query/Retrieve DICOM.
• Modificación de ficheros DICOM mediante scripts escritos en Lua.
En este proyecto será utilizado como un PACS. En él se introducirán datos

de prueba con estructura DICOM real para poder realizar operaciones DICOM
contra él, pudiendo ası́ verificar el correcto funcionamiento del aplicativo. A
continuación, en la figura 2.7, se muestra un ejemplo de la visualización de
la base de datos del CONQUEST Dicom usado para la realización de este
proyecto.
18 2.5. DICOM
Figura 2.7: Ejemplo de base de datos en CONQUEST Dicom

Capı́tulo 3
Estado de la cuestión
3.1. Introducción
Cada dı́a, el mundo sanitario se convierte en un contexto mucho más tec-
nológico, donde los profesionales tienen a su alcance aplicaciones y herramien-
tas cada vez más sofisticadas que les ayudan a una mejor y más rapida toma de
decisiones. También los pacientes se benefician de este avance, por ejemplo, ob-
teniendo CDs con el estudio clı́nico que se realizan en su centro sanitario. Estos
CDs son el princial medio de intercambio de información entre instituciones
médicas.
En este apartado se verá una serie de aplicaciones que realizan la tarea
de importar esta información al PACS para que el profesional médico pueda
tener acceso directo a las anteriores examinaciones de ese paciente, lo cual
evita duplicar estudios clı́nicos y mejora los tratamientos.
3.2. Integrity
El Integrity [31] es un dispositivo de pago que permite leer, reconciliar
y almacenar estudios médicos desde un disco(CD/DVD) a un PACS. Permi-
te realizar búsquedas múltiples para identificar coincidencias entre datos del
estudio (nombre del paciente, demografı́a...).
Esta herramienta dispone además de una interfaz basada en web que pro-
porciona acceso multiusuario, separando el proceso de lectura del disco de la
reconciliación. Realiza análisis antivirus a los estudios importados, permite
editar atributos de los estudios y almacenar en hasta diez destinos, incluyendo
PACS y archivos locales.
Como se puede observar en las figuras 3.1, 3.2 y 3.3, el Integrity cuenta
19
20 3.2. Integrity
Figura 3.1: Dispositivo Integrity
Figura 3.2: Vista de detalles del estudio
con una intuitiva interfaz web que nos permite realizar muchas funciones clave
para la correcta importación de estudios. Destaca la capacidad de revisión, e
incluso, edición de los datos de los estudios para su correcta reconciliación con
anteriores estudios del paciente, lo cual facilita mucho la tarea de cerciorarse
que todo está correcto y de que se está realizando la importación de forma
adecuada por parte del profesional.
Los fallos del Integrity radican en que es un dispositivo hardware de pago
Figura 3.3: Vista de reconciliación de estudios
que se ha dejado de fabricar, por lo que se ha descartado su uso.
3.3. Medavis DICOM importer

Medavis DICOM Importer [32] es un software que permite importar in-
formación en formato DICOM incluso si no se tiene un PACS propio, lo cual
podrı́a resultar útil si, por ejemplo, fuera en la recepción de nuestro centro
médico donde se le pidiese el CD a los pacientes.
Esta herramienta se caracteriza por una interfaz gráfica sencilla que intenta
facilitar el uso a personas con escasos conocimientos del estándar DICOM. Dis-
pone de una versión gratuita para uso no-comercial, en la que solo se permiten
realizar ciertas acciones, y una PRO, con todas las funcionalidades.
Como se puede apreciar en la figura 3.4, se puede ir importando imagen
a imagen, visualizándola con herramientas como el zoom o panning, o bien
importar toda la información con un solo click, acelerando el proceso de im-
portación de información DICOM notablemente.
22 3.4. Consideraciones
Figura 3.4: Mediavis DICOM Importer
3.4. Consideraciones
No es extensa la cantidad de herramientas en el mercado que permitan
realizar la tarea de poder importar la información que un paciente trae en un
CD para ser usada por los profesionales del centro médico al que asiste. Ambas
opciones tratadas son de pago, una siendo hardware y otra software. Además,
el mayor problema radica en que no todos los centros médicos disponen de
personal formado en el estándar DICOM.
Viendo estas carencias, se plantea realizar un importador de estudios pro-
pio, recogiendo las funcionalidades más destacadas de estas aplicaciones, an-
teriormente mencionadas, y añadiendole algunos puntos en las que estas no se
adaptan a lo que el sector necesita debido al avance que el mismo experimenta.
Ası́, se realizará una aplicación cogiendo los puntos fuertes de ambas he-
rramientas:
• Interfaz gráfica sencilla para el usuario: No mostrar detalles demasiado

especı́ficos del estandar DICOM, sino los datos realmente importantes
para agilizar y facilitar el trabajo de los profesionales.
• Permitir revisar los datos de los estudios a importar: La parte más im-
portante de este proceso de intercambio es que la importación se haga
con reconciliaciones verı́dicas.
• Permitir flexibilidad a la hora de importar los estudios: De forma manual

o automática, y permitiendo elegir por qué campos se filtran los posibles
estudios con los que reconciliar los importados desde el CD del paciente.
Además de todas estas ideas, se impulsa el añadir la posibilidad de leer

no solo CD o DVD, sino también USB, lo cual añade mayor flexibilidad tanto
para los pacientes como para los profesionales del sector sanitario para usar
esta herramienta.
También el mostrar un historial de las modificaciones realizadas: Permite
mantener un registro de los cambios realizados a los estudios que se han ido
importando y permite una más facil y rápida corrección de cualquier fallo que
se haya cometido.
24 3.4. Consideraciones
Capı́tulo 4
Metodologı́a de desarrollo
En este capı́tulo se describe la metodologı́a elegida para el desarrollo del

proyecto.
Una metodologı́a de desarrollo de software hace referencia a un framework
(entorno o marco de trabajo) que es usado para estructurar, planear y controlar
el proceso de desarrollo en sistemas de información.
La elección de una metodologı́a apropiada y que se ajuste a las carac-
terı́sticas y necesidades del proyecto en el que se aplica, es fundamental para
la correcta realización del mismo.
4.1. Metodologı́a seleccionada

Para el desarrollo de este proyecto se ha decidido utilizar una metodologı́a
iterativa incremental [33], basada en dividir el proyecto en múltiples iteracio-
nes más fácilmente abordables en las que se obtiene un producto funcional al
acabar cada una de las iteraciones en las que se divide el proyecto.
Las iteraciones se pueden entender como miniproyectos: en todas las itera-
ciones se repite un proceso de trabajo similar (de ahı́ el nombre “iterativo”)
para proporcionar un resultado completo sobre producto final, de manera que
el cliente pueda obtener los beneficios del proyecto de forma incremental. Para
ello, cada requisito se debe completar en una única iteración: el equipo debe
realizar todas las tareas necesarias para completarlo (incluuyendo pruebas y
documentación) y que esté preparado para ser entregado al cliente con el mı́ni-
mo esfuerzo necesario. De esta manera no se deja para el final del proyecto
ninguna actividad arriesgada relacionada con la entrega de requisitos.
Las principales ventajas de esta metodologı́a son:
• Separa el proyecto en subproyectos fáciles de abordar.
25
26 4.1. Metodologı́a seleccionada
• Se puede gestionar de manera natural los cambios que van apareciendo

durante el proyecto. La finalización de cada iteración es el lugar natural
donde el cliente puede proporcionar su feedback tras examinar el resul-
tado obtenido.
• Permite mitigar desde el inicio los riesgos del proyecto. Desde la pri-
mera iteración, el equipo tiene que gestionar los problemas que pueden
aparecer en una entrega del proyecto. Al hacer patentes estos riesgos, es
posible iniciar su mitigación de manera anticipada.
• Dado que cada iteración debe dar como resultado requisitos terminados,
se minimiza el número de errores que se producen en el desarrollo y se
aumenta la calidad.
• Permite conocer el progreso real del proyecto desde las primeras itera-
ciones y extrapolar si su finalización es viable en la fecha prevista.
4.1.1. Fases de cada iteración

Cada iteración consta de:
• Análisis: Se definen los objetivos a cumplir en la iteración, obviando el

funcionamiento interno del sistema. Una vez finalizada esta fase no se
pueden variar los objetivos de la iteración.
• Diseño: Se definen las arquitecturas y los modelos de datos con los que
se representará la información.
• Implementación: Siguiendo lo establecido en el diseño, se genera el código

fuente de la aplicación.
• Pruebas: Se comprueba el correcto funcionamiento de la aplicación y se

subsanan todos los posibles fallos cometidos durante el desarrollo de la
iteración.
Capı́tulo 5
Planificación, recursos y costes
En este apartado se expone la planificación seguida en este proyecto, la

cual nos permite obtener estimaciones de recursos, costes y la duración del
proyecto.
5.1. Asignación de recursos

A continuación, se detallan los recursos de los que dispone el proyecto para
su realización, dividiéndolos en recursos humanos y técnicos.
Los recursos humanos presentes en este proyecto son los siguientes:
• Jefe de proyecto: Delimita las tareas a realizar y revisa los resultados

que se van obteniendo.
• Analista, responsable del análisis y diseño.
• Programador, encargado de la fase de implementación.
Los directores del proyecto realizan el rol de jefes de proyecto y el alumno

realiza los rolos de analista y programador.
5.2. Planificación inicial

Este proyecto se inicia el dı́a 4 de septiembre de 2017 y se estima la fecha
de finalización el dı́a 12 de Enero de 2017. Habiendo entre ambas fechas
100 dı́as laborables, y asumiendo un trabajo de 4 horas diarias, se obtendrı́a
un total de 400 horas.
27
28 5.2. Planificación inicial
5.2.1. Iteraciones del proyecto

Se definen las iteraciones a seguir para la realización de este proyecto, con
su respectiva planificación temporal.
• Utilidades del proyecto: El objetivo de esta iteración es obtener una ver-

sión del programa con las clases básicas para el manejo de la base de
datos, directorios para manejar la entrada, salida y modificación de los
estudios a nivel DICOM y la lectura del DICOMDIR, que es un directorio
de contenido que proporciona un ı́ndice de información de resumen para
cada uno de los ficheros DICOM contenidos. La planificiación temporal
de esta iteración se puede ver en la figura 5.1.
• Lectura de estudios clı́nicos: El objetivo de esta iteración es la implemen-

tación de la parte común de la entrada/salida de la herramienta, como
es la lectura del anteriormente comentado DICOMDIR para encontrar
el/los estudios contenidos en el dispositivo de entrada y darlos de alta
en base de datos. La planificiación temporal de esta iteración se puede
observar en la figura 5.2.
• Hilos Monitores: El objetivo de esta iteración es la creación de un bucle

iterativo persistente que se encargue de la lectura de estudios a partir de
CD/DVD/USB... ası́ como, su presentación en la interfaz de usuario en
la web. La planificiación temporal de esta iteración se representa en la
figura 5.3.
• Operaciones DICOM: El obejtivo de esta iteración es la creación de las

operaciones DICOM de Query & Retrieve, que se utilizan para consultar
un archivo DICOM (por ejemplo, en un servidor PACS) sobre su conte-
nido y recuperar algunas partes de ese contenido, y Store, que se utiliza
para transferir imágenes DICOM y otros datos digitales relacionados de
un nodo DICOM a otro nodo DICOM. Es un servicio fundamental en
DICOM, ya que permite el intercambio de datos entre múltiples dispo-
sitivos a través de la red DICOM. La planificiación temporal de esta
iteración se presenta en la figura 5.4.
• Matching: El objetivo de esta iteración es la búsqueda manual, mediante

las operaciones DICOM comentadas con anterioridad, de estudios en el
PACS que pudieran pertenecer al mismo paciente del estudio que se
pretende importar. La planificiación temporal de esta iteración se puede
visualizar en la figura 5.5.
Figura 5.1: Planificación temporal inicial Iteración 1

30 5.2. Planificación inicial

5.2.2. Planificación económica inicial

Los costes del proyecto se derivan de los recursos anteriormente menciona-
dos, sin los cuales no se podrı́a realizar un correcto desarrollo del mismo.
En la siguiente figura se muestra en detalle la estimación inicial de costes
y esfuerzo
Figura 5.6: Planificación económica inicial
5.3. Planificación final

Durante el desarrollo del proyecto existieron una serie de complicaciones
que supusieron que la duración del mismo se alargara. Una mayor carga de
aprendizaje y retrasos en algunas de las iteraciones debido a una mayor carga
de trabajo en las fases de análisis e implementación, provocaron añadir 100
horas más de desarrollo.
Este desvı́o supuso la adición de cinco semanas más de trabajo por parte del
analista/programador, cambiando ası́ la fecha final del desarrollo del proyecto
al 16 de Febrero de 2018.
A continuación, en las figuras 5.7, 5.8, 5.9, 5.10 y 5.11, se muestra la pla-
nificación temporal final del proyecto, la cual refleja este desvı́o temporal.
Figura 5.7: Planificación temporal final Iteración 1

32 5.3. Planificación final

5.3.1. Planificación económica final

Teniendo en cuenta los desvı́os temporales expuestos, se calcula el coste
final del proyecto usando los salarios usados para la planificación inicial.
Figura 5.12: Planificación económica final
En base a lo mostrado en la figura 5.12 se puede denotar una desviación

económica de 2.000€, un 18 % con respecto a lo planificado inicialmente.
34 5.3. Planificación final
Capı́tulo 6
Sistema desarrollado
En este capı́tulo se muestra la arquitectura del sistema y una visión inicial

del mismo, ası́ como los requisitos generales que ha de cumplir.
6.1. Análisis de requisitos

En este apartado se recogerán una serie de requisitos que ha de cumplir la
aplicación:
• Lectura de estudios DICOM de diferentes fuentes: CD,DVD,USB... además,

esta lectura deberá ser rápida y transparente para el usuario, mostrándo-
sele los estudios directamente una vez estos hayan sido leidos por la he-
rramienta.
• Contrastar estudios contra un PACS: Se debe poder comunicarse con un

PACS y obtener información de los estudios contenidos en este, permi-
tendose hacer esto a través de diferentes campos (elementos).
• Modificar estudios DICOM: La herramienta podrá modificar estudios

leidos para igualar ciertos elementos de los mismos a los de los estudios
del PACS, para que finalmente estos estudios se almacenen con el mismo
paciente.
• Librerı́as DICOM: Necesarias para evitar tener que realizar operaciones

de bajo nivel a la hora de obtener información de archivos DICOM.
• Interfaz simple y rápida: Los mayorı́a usuarios de esta herramienta no

tienen grandes conocimientos de informática, por lo que se desea crear
una interfaz de usuario con la información necesaria, las funcionalidades
fáciles de ver y usar, a la vez de realizarse de forma rápida.
35
36 6.2. Arquitectura del sistema
6.2. Arquitectura del sistema

A continuación se muestran los principales módulos de la herramienta:
Figura 6.1: Arquitectura General
En la 6.1 vemos los siguientes módulos:
• Web: Este módulo contendrá la parte web de la aplicación, divida en:
◦ Interfaz de Usuario: Se implementará en HTML, JavaScript y CSS.

◦ Servicio REST: Ofrecerá a la interfaz de usuario acceso a las fun-
cionalidades del servidor. Se implementerá mediante Spring.
• Core: Este es el módulo principal del programa. Implementará la lógica

del mismo y expondrá un servicio a la parte web para acceder a sus
funciones.
◦ Modelo: Implementación del modelo de datos necesario (DAOs, cla-

ses,etc).
◦ Hilos monitores: Se implementará una interfaz de hilo monitor que
observará el método de entrada de datos que le corresponda (CD/DVD,USB...)
y cuando reciba datos, los leerá y copiará en un directorio local
además de añadirlo a la base de datos (MySQL).
◦ Servicio RMI [34]: Se ofrecerá un servicio RMI para la comunicación
con el módulo web.
• DICOM: Implementará los servicios DICOM que se usarán en el resto

del programa. Se compone de:
◦ Lectura DICOMDIR: Se encargará de leer los DICOMDIR para

extraer la localización de los estudios recibidos por el medio fı́sico
(CD/DVD,USB...),
◦ Servicio Q&R: Implementará las operaciones ”Query Retrieve de-

2 2
volverá los resultados obtenidos del PACS.

◦ Servicio STORE: Implementará las operaciones ”Store”para el envı́o
de estudios al PACS. Servicio de modificación de estudios: Se en-
cargará de la modificación de los archivos DICOM.
• Módulo de utilidades generales, utilizables en otros proyectos.
◦ Manejo de directorios: Se encargará de la creación, destrucción y

movimiento de directorios y archivos.
• Licensing: Módulo de licencias de la empresa. (Ya implementado).
6.3. Diseño
6.3.1. Estructura de los directorios

Los estudios que se reciban se traerán al disco duro organizados en la
siguiente estructura de directorios:
• Incoming: En el se copian todos los estudios que se lean del método de

entrada. Ası́, cada hilo monitor creará en incoming una carpeta propia
y los estudios se difereciarán con el identificador del estudio cuando se
le da de alta en la BD. En este directorio se almacenará el estudio tal y
como venga en el método de entrada.
• Processed: Se transladaran aquı́ a los estudios modificados tras realizar

el matching. De igual manera, cada hilo monitor creará su propia carpeta
y los estudios se nombrarán con el identificador del estudio modificado
(tabla diferente a la de incoming) cuando se le da de alta en la BD.
• Historic: Los estudios ya enviados se moverán a esta carpeta. Cada hilo

monitor creará una carpeta propia y los estudios se nombrarán con el
identificador del estudio modificado.
6.3.2. Configuración
Los diferentes módulos del programa requerirán ser configurables para
adaptarlos a cada cliente. Dentro de cada módulo, los ficheros de configuración
necesarios serán:
38 6.3. Diseño
• Web: La web necesitará permitir la configuración de los parámetros de

conexión al servidor y de ciertos aspectos de su interfaz. Para ello dis-
pondrá de un fichero JavaScript que almacenará estos datos:
◦ config.js
◦ Url de conexión con el servidor
◦ Intervalo de refresco de datos en pantalla principal
◦ Columnas de las tablas usadas, permitiendo especificar los datos
asociados a cada columna según la tecnologı́a de las dataTables
• Core: Necesitará permitir la configuración de los directorios usados para

almacenar los estudios. Para ello se creará un fichero XML y la librerı́a
Javax para leerlos desde el programa:
◦ configImportador.xml
◦ Directorio incoming
◦ Directorio processed
◦ Directorio Historic
• DICOM: Se necesitará poder configurar los datos de conexión al PACS

contra el que se trabaje. Para ello se creará un fichero xml y la librerı́a
Javax para leerlos desde el programa.
◦ configDicom.xml
◦ AET Origen (Application Entity Title)
◦ AET Destino
◦ Ip
◦ Puerto
◦ QueryTimeout
◦ MoveTimeout
◦ MaxResults
◦ OrderBy
◦ SearchType
• Utils: Se permitirá configurar las distintas utilidades presentes en este

módulo.
6.3.3. Backend
En la figura 6.2 se muestra el modelo de datos del sistema.
Con este diseño se quiere conseguir una base de datos sencilla que permita
añadir trazabilidad a la herramienta.
Figura 6.2: Entidad relación
La entidad Paciente consta de un identificador de paciente, nombre, fecha

de nacimiento y sexo. Ası́ mismo, un paciente tiene estudios, por lo que está
relacionada con la entidad estudio. De los estudios se guarda su identificador,
su identificador universal de instancia, su numero de acceso, su modalidad, su
descripción, el nombre del médico que lo realizó y la fecha del mismo.
Para poder llevar un histórico de las modificaciones que se vayan realizando,
añadimos dos entidades más: Paciente Modificado y Estudio Modifica-
do, que se corresponden con los pacientes estudios originales. Ası́ se puede
conservar la información inicial y poder ver las modificaciones que se hicieron.
La entidad Paciente Modificado guarda un identificador, nombre, fe-
cha de nacimiento y sexo. La entidad Estudio Modificado guarda un iden-
tificador, identificador universal de instancia, número de acceso, modalidad,
descripción, nombre del médico que lo realizó y la fecha del mismo.
6.3.4. Frontend
A continuación, en las siguientes figuras 6.3, 6.4 y 6.5, se muestra el diseño
inicial de la interfaz de usuario.
• Página principal 6.3
• Matching automático 6.4
• Matching manual 6.5
Como se puede observar, se busca una interfaz muy simpla que permite
realizar las funcionalidades ofrecidas de manera sencilla e intuitiva. Esto es
40 6.3. Diseño
Figura 6.3: Diseño inicial de la página principal de la web
Figura 6.4: Diseño inicial de la página de matching automático de la web
ası́ debido a que los profesionales que usarán esta herramienta no dominan
la informática, muchos de los cuales son de avanzada edad. Ası́, se intentará
crear una herramienta que permita realizar operaciones complejas utilizando
una interfaz gráfica sencilla que suponga una curva de aprendizaje baja y
simplifique las acciones que tenga que realizar el usuario para llevar a cabo
tales operaciones.
Figura 6.5: Diseño inicial de la página de matching manual de la web
6.3.5. Iteraciones
En esta sección se describe de forma detallada el desarrollo del proyecto.
Como se comenta en el capı́tulo 5, al usar una metodologı́a iterativa incremen-
tal este apartado estará estructurado en iteraciones.
6.4. Iteración 1
El objetivo de esta iteración es obtener una versión del programa con las
clases básicas para el manejo de la base de datos, directorios...etc.
6.4.1. Análisis
Esta iteración se centra en crear las utilidades del proyecto, por lo que las
tareas a abordar serán:
• Creación de la base de datos: Los respectivos scripts para la creación y

borrado de las tablas de la base de datos.
• Código de manejo de la base de datos: Toda la infraestructura necesaria

para la interacción entre Java y la base de datos.
• Servicios: Se crearán los servicios que implementarán las funcionalidades

sobre la información del programa.
42 6.4. Iteración 1
• Código de manejo de directorios: Se crearán las funciones de manejo de

directorios/ficheros.
• Lectura de DICOMDIR: Se creará el servicio de lectura de DICOMDIR.
• Archivos de configuración: Se crearán los archivos de configuración ne-

cesarios.
• Test unitarios: Se implementarán test unitarios para las clases encarga-

das del manejo de la base de datos, manejo de directorios, lectura de
DICOMDIR...
• Manejo de excepciones: Se deberán manejar los diferentes casos de error

mediante excepciones, definiendo excepciones propias en caso de ser ne-
cesario.
6.4.2. Diseño
Para la parte de creación de la base de datos, se procederá siguiendo el
diseño estipulado en el apartado de backend.
El primer paso será la creación de un script llamado CreateTables.sql que
será el encargado de crear todas las entidades y relaciones de nuestra base
de datos. También necesitaremos un script para poder borrar estas tablas y
relaciones, por lo que crearemos un script llamado DropTables.sql. Estos scripts
se localizarán en el módulo Core.
Una vez se tenga creada la base de datos, ha de crearse todo el código para
el manejo de la misma, lo cual incluye los POJOs que representen las tablas
de la base de datos, los DAOs, los RowMappers... Todo esto se organizará
dentro del módulo Core en un paquete llamado model, dentro del cual se
hará un nuevo paquete con el nombre de la tabla que representa (por ejemplo
”paciente”) que incluirá todas las clases necesarias para la interacción con esa
tabla.
Además, una vez implementado todo esto, se crearán los servicios (interfaz
e implementación) que implementarán las funcionalidades que se acabarán
de codificar en cada uno de los respectivos DAOs de la herramienta. Estos
servicios se crearán dentro de paquetes llamados por el nombre de la entidad
concatenado con Service.
Durante esta implementación, se irá añadiendo el código necesario para el
correcto funcionamiento de Spring. A continuación se muestra el diseño de las
cuatro entidadades de la herramienta:
- Paciente:
Figura 6.6: core/model/patient
El primer paso será crear la entidad persistente Patient que incluirá los
campos definidos en las tablas de la base de datos, como se puede visualizar
en la figura 6.6.
Los métodos que se incluyen en la interfaz SqlPatientDAO son los siguien-
tes:
• Create: Devuelve un nuevo Paciente.
• FindPatientByPatientName: Devuelve una lista de pacientes cuyo nom-

bre es el especificado como parámetro.
• FindPatientByPatientID: Devuelve el paciente cuyo identificador es el

especificado como parámetro.
• FindPatientByBirthDate: Devuelve una lista de pacientes cuya fecha de

nacimiento sea igual a la especificada como parámetro.
• RemoveByPatientID: Borra un paciente por su identificador.
• ListAllPatients: Devuelve una lista con todos los pacientes.
También se creará el RowMapper correspondiente a Patient para acceder

a la base de datos de una manera más simple y básica.
Una vez se tengan todas estas clases implementadas, se seguirá con la
creación del servicio para la entidad Paciente, el cual tendrá las siguientes
funcionalidades:
• AddPatient: Añade un paciente.
• DeletePatient: Borra un paciente.
• FindPatientsByName: Buscar pacientes por su nombre.
• FindPatientsByBirthDate: Buscar pacientes por su fecha de nacimiento.
• FindPatientByPatientID: Buscar un paciente por su identificador de pa-

ciente.
• FindAllPatients: Buscar todos los pacientes.
Figura 6.7: core/model/patientService
- Paciente Modificado:
El primer paso será crear la entidad persistente PatientMod que incluirá
los campos definidos en las tablas de la base de datos, como se puede visualizar
en la figura 6.8.
Los métodos que se incluyen en la interfaz SqlPatientModDAO son los
siguientes:
• Create: Devuelve un nuevo Paciente Modificado.
• FindPatientModByPatientModName: Devuelve una lista de pacientes

modificados cuyo nombre es el especificado como parámetro.
Figura 6.8: core/model/patientMod
• FindPatientModByPatientModID: Devuelve el paciente modificado cuyo

identificador es el especificado como parámetro.
• FindPatientModByBirthDate: Devuelve una lista de pacientes modifica-

dos cuya fecha de nacimiento sea igual a la especificada como parámetro.
• RemoveByPatientModID: Borra un paciente modificado por su identifi-

cador.
• ListAllPatientMod: Devuelve una lista con todos los pacientes modifica-

dos.
También se creará el RowMapper correspondiente a PatientMod para ac-

ceder a la base de datos de una manera más simple y básica.
Una vez todas estas clases estén implementadas, se seguirá con la creación
del servicio para la entidad Paciente Modificado, el cual tendrá las siguientes
funcionalidades:
• AddPatientMod: Añade un paciente modificado.
• DeletePatientMod: Borra un paciente modificado.
• FindPatientsModByName: Buscar pacientes modificados por su nombre.
• FindPatientsModByBirthDate: Buscar pacientes modificados por su fe-

cha de nacimiento.
• FindPatienModtByID: Buscar un paciente modificado por su identifica-

dor de paciente.
• FindAllPatientsMod: Buscar todos los pacientes modificados.
Figura 6.9: core/model/patientModService
- Estudio:
El primer paso será crear la entidad persistente Study que incluirá los cam-
pos definidos en las tablas de la base de datos, como se puede visualizar en la
figura 6.10.
Los métodos que se incluyen en la interfaz SqlStudyDAO son los siguientes:
• Create: Devuelve un nuevo Estudio.
• GetNumberOfStudies: Devuelve el número de estudios que tiene un pa-

ciente.
• FindStudiesByPatientID: Devuelve una lista con los estudios que perte-

necen a un paciente. Si ese paciente no tiene ningún estudio, se devolverá
una lista vacı́a.
• RemoveByPatientId: Borra todos los estudios que pertenecen a un pa-

ciente.
• RemoveStudy(String): Borra un estudio por su studyUID.
• RemoveStudy(Long): Borra un estudio por su identificador.
• ListAllStudies: Devuelve una lista de todos los estudios.

Figura 6.10: core/model/study
También se creará el RowMapper correspondiente a Study para acceder a

la base de datos de una manera más simple y básica.
del servicio para la entidad Estudio, el cual tendrá las siguientes funcionalida-
des:
Figura 6.11: core/model/studyService

• AddStudy: Añade un estudio.
• DeleteStudy: Borra un estudio por el campo studyInstanceUID.
• DeletePatientStudies: Borra todos los estudios de un paciente.
• RemoveStudy: Borra un estudio por su identificador.
• FindPatientStudies: Busca los estudios de un paciente.
• CountPatientStudies: Cuenta los estudios de un paciente.
• FindAllStudies: Busca todos los estudios.
- Estudio Modificado:
Figura 6.12: core/model/studyMod
El primer paso será crear la entidad persistente StudyMod que incluirá los
campos definidos en las tablas de la base de datos, como se puede visualizar
en la figura 6.12.
Los métodos que se incluyen en la interfaz SqlStudyModDAO son los si-
guientes:
• Create: Devuelve un nuevo Estudio modificado.
• GetNumberOfStudiesMod: Devuelve el número de estudios modificados

que tiene un paciente modificado.
• FindStudiesModByPatientID: Devuelve una lista con los estudios modi-

ficados que pertenecen a un paciente modificado. Si ese paciente no tiene
ningún estudio modificado, se devolverá una lista vacı́a.
• RemoveByPatientId: Borra todos los estudios modificados que pertene-

cen a un paciente modificado.
• RemoveStudyMod(String): Borra un estudio modificado por su stud-

yUID.
• RemoveStudyMod(Long): Borra un estudio modificado por su identifica-

dor.
• ListAllStudiesMod: Devuelve una lista de todos los estudios modificados.
También se creará el RowMapper correspondiente a StudyMod para acceder

a la base de datos de una manera más simple y básica.
del servicio para la entidad Estudio Modificado, el cual tendrá las siguientes
funcionalidades:
Figura 6.13: core/model/studyModService
• AddStudyMod: Añade un estudio modificado.
• DeleteStudyMod: Borra un estudio modificado por el campo studyIns-

tanceUID.
• DeletePatientStudiesMod: Borra todos los estudios modificados de un

paciente modificado.
• FindPatientStudiesMod: Busca los estudios modificados de un paciente

modificado.
• CountPatientStudiesMod: Cuenta los estudios modificados de un pacien-

te modificado.
• FindAllStudiesMod: Busca todos los estudios modificados.
Al manejar datos de entrada (información procedente de los CD/DVD,USB...)

se necesitará poder incorporar estos datos a los equipos que los reciban. Para
esto se implementará en el módulo Utils una clase llamada DirectoryActions
que permitirán realizar las funcionalidades necesarias como son: copiar ficheros
y directorios, mover directorios, comprobar el tamaño de un directorio, borrar
directorios... Todo estos métodos permitirán incorporar toda la información
contenida en el DICOMDIR que estará presente en los dispositivos de almace-
namiento que se introduzcan en los equipos de los profesionales médicos y se
pueden observar en la figura 6.14:
Figura 6.14: utils/DirectoryActions
• CopyFiles: Copia un fichero a un fichero de destino.
• CopyDirs(File,File): Copia el contenido de un directorio a otro.
• CopyDirs(File,File,String): Copia los ficheros de un tipo de fichero de un

directorio a otro
• moveDirs: Mueve el contenido de un directorio a otro.
• removeDir: Borra un directorio.
• remvoveSubDirs: Borra los subdirectorios de un directorio.

Además, en este mismo módulo, se creará una clase llamada Global Na-
mes para establecer constantes como el fichero de Log, puertos USB... para
añadir mayor flexibilidad a la hora de configurar la herramienta en los equipos
médicos.
Para la lectura del DICOMDIR se creará en el modulo Dicom una clase
DicomDirReader que implementará este servicio dentro del paquete services.
Los métodos de esta clase, como se pueden apreciar en la figura 6.15, son los
siguientes:
Figura 6.15: dicom/services/DicomDirReader
• LoadDicomDirFile: Se carga toda la información contenida en el DI-

COMDIR contenido en el directorio especificado.
• GetPatients: Recupera un vector con los pacientes contenidos en el DI-

COMDIR.
• GetStudiesFromPatient: Recupera los estudios del paciente especificado.
• GetSeriesFromStudy: Recupera las series del estudio indicado.
• GetSeriesFromPatient: Recupera las series del paciente pasado como

parámetro.
• GetImagesFromSeries: Devuelve un vector con las imágenes de la serie

especificada.
A lo largo de toda esta implementación se manejan los diferentes casos

de error mediante excepciones, definiendo excepciones propias en caso de ser
necesario. Las excepciones propias se definirán dentro del paquete “exception”
del módulo correspondiente. Los errores a manejar en esta iteración son, por
ejemplo, errores de BD (conexión, inserción, borrado...), errores de manejo

de directorios/archivos (directorio no existente, ocupado...) y errores con la
lectura del DICOMDIR (archivo no existente...).
Por último se tendrán que implementar los archivos de configuración nece-
sarios en el módulo Core dentro del paquete config.
Para la configuración de los puertos a reconocer se creará un fichero Java
Properties File llamado application.properties y para la configuración de los
paths de los ficheros se creará un fichero XML [35] llamado configurationfile-
path.xml.
6.4.3. Implementación
Para la creación de la BD se utilizará la herramienta MySQL WorkBench.
Desde la página principal, crearemos un nuevo schema con nombre studyim-
porter. Añadiremos a este schema un usuario y passoword. Estos tres datos son
importantes puesto que después deberemos indicarlos en el fichero application-
context.xml de Spring para poder conectar con nuestra base de datos.
A continuación se codificarán las cuatro tablas que representan nuestras
entidades persistentes a través de los scripts para la creación y el borrado
de las mismas. Estos scripts serán añadidos al módulo Core en una carpeta
llamada scripts-sql.
Figura 6.16: Scripts SQL
Figura 6.17: Estructura de la base de datos en MySQL Workbench
Para la codificación de todos los apartados anteriormente mencionados, se

crearán en el IDE de Eclipse para Java cuatro proyectos Maven para repre-
sentar los cuatro módulos de los que se compone la herramienta.
Figura 6.18: Estructura de los proyectos
A continuación, se codificarán todo el código correspondiente al manejo de

la base de datos necesario para la interacción entre JAVA y la base de datos
del proyecto. Además también se añadirán todos los ficheros necesarios para
el correcto funcionamiento de Spring y se configurará para su uso con la base
de datos creada. La estructura de esta implementación se puede observar en
las figuras 6.19, 6.20, 6.21 y 6.22:
Figura 6.19: Paquete Paciente
Figura 6.20: Paquete Paciente Modificado
Figura 6.21: Paquete Estudio
Una vez esté toda esta parte codificada, se seguirá con la implementación
de los servicios de cada una de estas entidades. La estructura de estas clases
Figura 6.22: Paquete Estudio Modificado
Figura 6.23: Paquete Servicio de la entidad Paciente
Figura 6.24: Paquete Servicio de la entidad Paciente Modificado
Figura 6.25: Paquete Servicio de la entidad Estudio
Figura 6.26: Paquete Servicio de la entidad Estudio Modificado
y los paquetes en los que se encuentran se puede ver en las figuras 6.23, 6.24,
6.25 y 6.26:
Para manejar los datos de entrada se han implementado las funcionalidades
indicadas utilizando el paquete Java.io, el cual nos facilita la realización de
tareas relacionadas con el flujo de datos, tanto de entrada como de salida. La
estructura de esta implementación se puede ver en la figura 6.27.
Figura 6.27: Módulo Utils

Para poder implementar el servicio de lectura del DICOMDIR, se hará uso

de la libreria dcm4che para Java. El primer paso para poder leer el DICOM-
DIR, el cual proporciona un ı́ndice e información de resumen para cada uno de
los ficheros DICOM contenidos, es recoger toda esta información contenida en
el mismo. Una vez recogida, siguiendo el estándar DICOM, se podrá conseguir
la lista de pacientes existentes en el DICOMDIR. A partir de estos pacientes,
se podrá recuperar los estudios de cada uno de ellos. Con cada uno de estos
estudios, se cogerán las series contenidas en estos y en cada una de estas series
se recuperarán las imágenes existentes en estas.
Se añade una carpeta config dentro del módulo Core para añadir los archi-
vos de configuración necesarios para la correcta instalación de la herramienta
en cada uno de los equipos. La estructura de esta carpeta se puede observar
en la figura 6.28.
Figura 6.28: Estructura de la carpeta config
Las clases creadas para realizar este manejo de las excepciones en esta
iteración son las expuestas en la figura 6.29.
Figura 6.29: Excepciones creadas
6.4.4. Pruebas
Para la parte de la base de datos y del código para su manejo se crearán
cuatro tests unitarios usando JUnit, uno por cada entidad persistente, para
comprobar el correcto funcionamiento de cada una de las funcionalidades que
estas ofrecen. Estos tests se llamarán igual que la clase que testean, con la
palabra Test añadida al final, como se puede visualizar en la figura 6.30
Además de estas pruebas unitarias, también se hace uso de la herramien-
ta MySql Workbench para realizar de manera manual comprobaciones de la
Figura 6.30: Tests del módulo Core
correcta creación de las tablas, creación de nuevas instancias de las entidades

persistentes, borrado de las mismas... Ejemplos de estas pruebas se pueden
comprobar en las figuras 6.31 y 6.32
Figura 6.31: Lista de pacientes en la base de datos
Figura 6.32: Lista de estudios en la base de datos
Para la lectura del DICOMDIR, se creará un ejecutable para leer la infor-

mación de DICOMDIRS de prueba proporcionados por la empresa. Gracias a
los logs incorporados en el código del servicio de lectura, se puede comprobar
el correcto (o incorrecto) comportamiento del mismo.
Además, para cercionarse de que la lectura del DICOMDIR se ha realizado
de manera correcta, se utilizará la herramienta Quick DICOM Editor. Gracias
a esta herramienta, se puede consultar el contenido de cualquier DICOMDIR
para ver si corresponde con lo leı́do en la aplicación.
Una vez leı́do el DICOMDIR, se comprobará el correcto funcionamiento del
código de manejo de directorios copiando las imágenes de las series contenidas
en estos DICOMDIRs de prueba al equipo de desarrollo. De la misma manera,
se puede ir comprobando el correcto funcionamiento de este código gracias

a los logs introducidos en el mismo, además de comprobar manualmente la
estructura de directorios del aplicativo.
6.5. Iteración 2
El objetivo de esta iteración es la implementación de la parte común de los
hilos monitores.
6.5.1. Análisis
Esta iteración se centrará en la lectura de estudios. Para ello, se definen las
siguientes tareas:
• Creación de la MainApp: Se creará la clase principal del módulo Core
• Hilo monitor: Se implementará la parte común de los mismos, la cual se

corresponde con la lectura del DICOMDIR para encontrar los estudios
y copiarlos al directorio incomming, dándolos de alta en base de datos.
• Pruebas con estudios DICOM: Se comprobará el correcto funcionamiento

de la anterior tarea utilizando datos con estructura real pero ficticios
proporcionados por la empresa.
• Manejo de errores: Se controlarán errores tales como la ausencia de archi-

vo de configuración (o mal formado), problemas importando estudios...
En esta iteración se denota mucha menos carga en la fase de Diseño en

contraste a la anterior iteración, pero en proporción una mayor carga en la
fase de Implementación y Pruebas.
6.5.2. Diseño
En el módulo Core se creará la clase App, la cual creará los directorios
necesarios para el programa según se especifican en el archivo de configuración
y lanzará los hilos monitores.
A continuación se creará la interfaz para la parte común de los hilos moni-
tores, llamada MediaService y ubicada en el paquete model del módulo Core,
la cual integrará la funcionalidad de leer el DICOMDIR, dar de alta en base
de datos a los pacientes y estudios recopilados y llevar los estudios (con sus
Figura 6.33: core/model/mediaService
respectivas series e imágenes) al directorio incomming. Una vez creada la in-

terfaz, se procederá a la implementación de la misma, como se puede ver en la
figura 6.33.
Se utiliza la clase textitApp contenida en el paquete app del módulo Core
para codificar la creación de los directorios necesarios para el funcionamiento
de la aplicación. Tal estructura se puede observar en la figura 6.34.
Figura 6.34: Carpeta config creada al ejecutar la clase App
Una vez realizada esta funcionalidad, se añade al código la funcionalidad de

lanzar los hilos monitores, que serán implementados en la siguiente iteración.
Para la codificación y consecuente implementación de la parte común de
los hilos monitores, se sigue el patrón del estándar DICOM, es decir:
• Un paciente tiene estudios
• Un estudio tiene series

• Una serie tiene imágenes
Ası́, el primero paso será localizar el DICOMDIR en la estructura de di-

rectorios y leerlo. Una vez leı́do, se pasa a recuperar todos los pacientes en él
contenidos y se añaden a la base de datos de la aplicación. Para cada uno de
esos pacientes, recuperaremos sus estudios. Estos estudios serán añadidos a la
base de datos y además se moverán al directorio incomming. Para realizar es-
to, utilizaremos las funcionalidades realizadas en la Iteración 1 para el manejo
de directorios. Ası́, recuperaremos las series y las imágenes de cada estudio
y las moveremos a su correspondiente carpeta del directorio incomming. La
estructura del paquete quedará como se expone en la figura 6.35.
Figura 6.35: core/app
Para ayudar en la fase de textitPruebas, se añaden logs para ir compro-

bando el correcto funcionamiento de esta funcionalidad.
6.5.4. Pruebas
En esta iteración se realizan gran cantidad de pruebas funcionales con CD’s
con datos ficticios pero estructura real proporcionados por la empresa para
comprobar que la aplicación se comporta debidamente en cualquier caso de
uso. Ası́, se crea una lista con las pruebas realizadas, su resultado y, en el caso
de que la prueba no fuese pasada, comentarios con los ajustes realizados. Las
pruebas realizadas se muestran es las figuras 6.36 y 6.37.
Para la comprobación de estas pruebas, se volverá a utilizar los logs in-
sertados en las funcionalidades de la lectura del DICOMDIR y el manejo de
directorios de la primera iteración, añadidos a los logs introducidos en la imple-
mentación común de los hilos monitores para la correcta inserción de pacientes
y estudios en la base de datos. Para este último apartado, también se volverá
a comprobar de forma manual, a través de la herramienta MySQL Workbench
el correcto comportamiento de la implementación realizada. Estos logs pueden
ser visualizados en las figuras 6.38, 6.39, 6.40 y 6.41.
Figura 6.36: Pruebas funcionales SI (i)
Figura 6.37: Pruebas funcionales SI (ii)

Figura 6.38: Logs al insertar un paciente ya registrado en BD
Figura 6.39: Logs al insertar un nuevo estudio a BD
Figura 6.40: Logs al leer una serie
Figura 6.41: Logs al leer una imagen e importarla

6.6. Iteración 3
El objetivo de esta iteración es la lectura de estudios de CD/DVD y USB,
ası́ como su presentación en la interfaz de usuario en la web.
6.6.1. Análisis
Esta iteración se centra en la implementación de los hilos monitores, deli-
mitándose las siguientes tareas a abordar:
• Hilo Monitor USB: Se detectará cuando se inserta un USB y, haciendo uso

de lo implementado en la iteración anterior, se recuperarán los estudios
contenidos en el mismo.
• Hilo Monitor CD/DVD: Se detectará cuando se inserta un CD/DVD y,

haciendo uso de lo implementado en la iteración anterior, se recuperarán
los estudios contenidos en el mismo.
• Servicios RMI: Se crearán los servicios RMI que expondrán las funcio-
nalidades de los servicios del módulo Core al módulo Web.
• Controlador Web: Conectará la parte HTML-JavaScript con el servidor
• Interfaz Web: Esta será la primera versión de la interfaz web, que solo
dispondrá de la pantalla principal donde se listarán los estudios que se
hayan leı́do.
• Tests funcionales: Se realizarán pruebas para comprobar la correcta lec-

tura de los dispositivos de almacenamiento, la correcta incorporación
de los estudios en estos contenidos y el correcto funcionamiento de la
primera versión de la interfaz web en sus diferentes casos de uso.
• Manejo de errores: Se controlarán errores tales como:
◦ Ausencia de archivos de configuración.

◦ Archivos de configuración mal formados.
◦ Dispositivo insertado no válido (Tanto por no tener DICOMDIR,
estar mal formado, no tener estudios...).
◦ Problemas al importar un estudio (Se extrae el dispositivo durante
la copia, errores con el manejo de directorios...).
◦ Errores de conexión con el servidor (No responde, error 404 por una
operación no válida, 500 por un error interno en el servidor...).
6.6.2. Diseño
Para la creación de los hilos monitores, tanto de USB como de CD/DVD,
se creará una aplicación de consola de .NET, llamada MediaDetector, que im-
plementará dichas funcionalidades, cada una en un método distinto, en la clase
Program.cs autogenerada al crear la solución en el IDE Microsoft Visual Stu-
dio, como se puede ver en la figura 6.42.
Figura 6.42: MediaDetector/Program.cs
Para la creación de los servicios RMI, se creará un paquete llamada rmi,

tanto en el módulo Core como en el módulo Web.
En el módulo Core se creará una clase RMIServer, que iniciará el RMI
y una clase para implementar el servicio RMI de cada una de las entidades
persistentes de la aplicación, llamada por el nombre de la entidad concatenada
con ServiceRmi. Esta estructura se puede observar en las figuras 6.43, 6.44,
6.45 y 6.46
Ası́, el servicio RMI de la entidad Paciente presenta las siguientes funcio-
nalidades:
• addPatient: Añade un paciente.
• deletePatient: Borra un paciente.
• findPatientsByName: Realiza una búsqueda de pacientes por su Patient

Name.
• findPatientsByBirthDate: Realiza una búsqueda de pacientes por su fe-

cha de nacimiento.
• findPatientsByPatientId: Realiza una búsqueda de pacientes por su iden-

tificador de paciente.
• findAllPatients: Realiza una búsqueda de todos los pacientes existentes.
El servicio RMI de la entidad Paciente Modificado contiene las funcionali-

dades siguientes:
• addPatientMod: Añade un paciente modificado.

Figura 6.43: core/rmi/PatientServiceRmi
• deletePatientMod: Borra un paciente modificado.
• findPatientsModByName: Realiza una búsqueda de pacientes modifica-

dos por su Patient Name.
• findPatientsModByBirthDate: Realiza una búsqueda de pacientes modi-

ficados por su fecha de nacimiento.
• findPatientsModByPatientId: Realiza una búsqueda de pacientes modi-

ficados por su identificador de paciente.
• findAllPatientsMod: Realiza una búsqueda de todos los pacientes modi-

ficados existentes.
El servicio RMI de la entidad Estudio expone las siguiente funcionalidades:
• AddStudy: Añade un estudio.

Figura 6.44: core/rmi/PatientModServiceRmi
• DeleteStudy: Borra un estudio por el campo studyInstanceUID.
• DeletePatientStudies: Borra todos los estudios de un paciente.
• FindPatientStudies: Busca los estudios de un paciente.
• CountPatientStudies: Cuenta los estudios de un paciente.
• FindAllStudies: Busca todos los estudios.
La entidad Estudio Modificado presenta en su servicio RMI las siguientes

funcionalidades:
• AddStudyMod: Añade un estudio modificado.
• DeleteStudyMod: Borra un estudio modificado por el campo studyIns-

tanceUID.
• DeletePatientStudiesMod: Borra todos los estudios modificados de un

paciente modificado.
Figura 6.45: core/rmi/StudyServiceRmi
• FindPatientStudiesMod: Busca los estudios modificados de un paciente

modificado.
• CountPatientStudiesMod: Cuenta los estudios modificados de un pacien-

te modificado.
• FindAllStudiesMod: Busca todos los estudios modificados.
Adicionalmente, se creará un servicio RMI para comunicarse con la apli-

cación de consola MediaDetector. Este servicio RMI puede verse en la figura
6.83 y presenta el método readMedia, el cual invocará al servicio MediaService
que ejecutará la funcionalidad de lectura del DICOMDIR e importación de los
pacientes y estudios en él contenidos.
En el módulo Web se creará también un paquete llamado rmi que con-
tendrá la clase RmiServices, que expondrá todos estos servicios implementados
en el módulo Core.
Figura 6.46: core/rmi/StudyModServiceRmi
Figura 6.47: core/rmi/MediaServiceRmi

A continuación se creará en controlador web que se encargará de conectar

este servidor con la parte HTML-JavaScript. Para esto, se creará un paquete
llamado Controller en el módulo Web. En este paquete se creará un controla-
dor para cada una de las entidades persistentes de la aplicación pero, debido
a las funcionalidades que se han de ofrecer en la interfaz web, se decide im-
plementar solamente los de las entidades Study y StudyMod debido a que son
los necesarios para implementar dichas funcionalidades. La estructura de estas
clases se puede visualizar en las figura 6.48.
Figura 6.48: web/controller/StudyController y web/controller/StudyModCon-

troller
Las funcionalidades del controlador web de la entidad Estudio serán las

siguientes:
• GetAllStudies: Devuelve una lista con todos los estudios existentes. Esta
funcionalidad se utilizará para mostrar la lista de estudios en la página
principal de la aplicación web.
• DeleteStudy: Borra un estudio. Esta funcionalidad se usará para imple-

mentar la acción de Borrar un estudio, presente en la aplicación web.
Las funcionalidad del controlador web de la entidad Estudio Modificado es

la siguiente:
• GetAllStudiesMod: Devuelve una lista con todos los estudios modifica-

dos existentes. Esta funcionalidad se utilizará cuando se implementa la
pestaña de Histórico en la Iteración 5.
Adicionalmente, también se implementará el controlador para el servicio de

lectura de dispositivos de almacenamiento, como se puede observar en la figura
6.49, cuya funcionalidad es la de leer el DICOMDIR e importar los pacientes
y estudios en él contenidos.
Figura 6.49: web/controller/MediaController
Para llevar a cabo esta implementación se crearán sus correspondientes

DTOs y conversores.
Los DTOs se incluirán dentro de un nuevo paquete llamado dto, y su es-
tructura será la representada en la figura 6.50.
Los conversores de dichos DTOs se incluirán dentro de un nuevo paquete
llamado conversor, y su estructura se puede visualizar en la figura 6.51.
Una vez se tenga implementado todo esto, se pasará a realizar la imple-
mentación de la interfaz web en su primera versión, que solo incluirá la funcio-
nalidad de listar los estudios leı́dos por la aplicación. Para esto, se añadirá una
carpeta llamada Web en el módulo Web. Esta carpeta contendrá los archi-
vos .css, .js e imágenes necesarias para la implementación de la funcionalidad
requerida en la iteración presente.
Para la implementación de los hilos monitores de CD/DVD/USB, se creará
una soluciñon llamada MediaDetector, del tipo aplicación de consola en el IDE
Microsoft Visual Studio. Una vez esta haya sido creada, implementamos en
la clase autogenerada Program.cs los eventos que se lanzarán al introducir un
CD/DVD/USB, lo cual será implementado gracias a las librerias ofrecidas por
Figura 6.50: web/dto/StudyDTO y web/dto/StudyModDTO
Figura 6.51: web/conversor/StudyToStudyDtoConversor y web/conversor/S-

tudyModToStudyModDtoConversor
.NET. Esta implementación se realizará en C#. La solución implementada se

puede ver en la figura 6.52.
Esta aplicación se lanzará con el inicio de la aplicación y lanzará peticio-
nes al servidor para que ejecute la funcionalidad implementada en el servicio
MediaService cuando se inserte un dispositivo de almacenamiento reconocido
(CD/DVD/USB).
Figura 6.52: Solución .NET MediaDetector
Para la implementación de los servicios RMI, se procederá primero con

la implementación de cada uno de los servicios de las entidades persisentes
de la aplicación, seguido por la codificación del servicio para la lectura de
dispositivos de almacenamiento, en el módulo Core.
Una vez esto se realiza, se continúa con la codificación de la clase RmiServer
que bindeará todos estos servicios que se acaban de crear.
La estructura del paquete rmi del módulo Core quedará como se presenta
en la figura 6.53.
Figura 6.53: Paquete Rmi en el módulo Core
Seguidamente se realizará la implementación en el módulo Web de la clase

RmiServices. Para esto, expondrá cada uno de los servicios implementados en
el módulo Core. La estructura del paquete rmi en el módulo Web se peude
visualizar en la figura 6.54.
Figura 6.54: Paquete Rmi en el módulo Web
Una vez creados los servicios RMI, se codificarán los controladores web
de la aplicación. Para esto, se codificarán los DTOs de las entidades Study y

StudyMod, con sus correspondientes conversores, que serán utilizados en dichos
controladores. La estructura de dichas clases es la presentada en la figura 6.55.
Figura 6.55: Paquetes Conversor y Dto en el módulo Web
Ası́, seguidamente, se codificarán los respectivos controladores web en el

módulo Web, uno por cada servicio RMI creado. La estructura de los mismos
se puede ver en la figura 6.56.
Figura 6.56: Paquete Controller en el módulo Web
El último paso de esta iteración es la codificación de la interfaz web de la

aplicación, la cual constará una arquitectura de ficheros de tres partes diferen-
ciadas:
• Archivos .css: Para definir y crear la presentación de las vistas de la

aplicación web.
• Imágenes: Suministradas por la empresa.
• Archivos .js: Donde se guardan funciones y variables globales que se

ejecutarán en la página web.
La estructura de ficheros de esta carpeta es la mostrada en la figura 6.57.

Una vez finalizada esta iteración, se obtendrá una aplicación web comple-
tamente funcional, que presenta los estudios leı́dos por la herramienta, con las
siguientes funcionalidades:
• Ordenar los estudios por cualquiera de los campos que se presentan para
cada uno de ellos.
Figura 6.57: Carpeta Web en el módulo Web
• Realizar búsquedas entre los estudios.
• Borrar un estudio.
• Indicar cuántos estudios se quieren mostrar de cada vez, y navegar por

las distintas páginas de la tabla.
En la Iteración 5 se añadirán las faltantes funcionalidades de la aplicación

web, pero en esta iteración podemos ver una de las mayores ventajas de la
Metodologı́a de desarrollo escogida, y es que se va obteniendo en cada iteración
un producto funcional al que se le van añadiendo funcionalidades.
A continuación, en las figuras 6.58, 6.59, 6.60, 6.61 y 6.62, se muestran
ejemplos de la aplicación web codificada en esta Iteración 3.
Figura 6.58: Página principal de la web

Figura 6.59: Página principal de la web, mostrando la segunda página de es-

tudios importados
Figura 6.60: Página principal de la web, ordenando estudios por nombre del
paciente
Figura 6.61: Acción de borrar un estudio
Figura 6.62: Comprobación al borrar un estudio

6.6.4. Pruebas
Para comprobar el correcto funcionamiento de la lectura de dispositivos de
almacenamiento, se hacen pruebas manuales con dispositivos proporcionados
por la empresa, que simulan a los usados en los centros médicos, volviendo
a repasar todas las pruebas realizadas en la iteración 2 y que comprobando
que en todos los casos de uso la herramienta sigue comportandose de forma
correcta (ausencia de archivos de configuración, fichero DICOMDIR con mal
formato...).
Una vez que toda la parte de lectura e incorporación de estudios a través de
dispositivos de almacenamiento está funcionando de manera correcta, se pro-
dece a comprobar el correcto funcionamiento de los servicios creados, ası́ como
la comunicación entre estos y la aplicación web codificada en esta iteración a
través de los controladores.
Ası́, cuando se inserta un CD con un estudio contenido en él, se deberı́a
mostrar en la aplicación web una vez este fuera importado por la herramienta.
Para esto, se utilizan CDs y USBs que contienen estudios ficticios pero con
estructura real proporcionados con la empresa, probando todos los casos de
uso como se hizo en la parte de lectura de estudios. Todo este proceso se puede
seguir gracias a los Logs incorporados en los servicios RMI y, en la parte de la
aplicación web, se pueden realizar tareas de debug gracias a los navegadores
web. En este caso, se realizarán con la opción Inspeccionar del navegador
Google Chrome [36], como se puede visualizar en la figura 6.63.
Figura 6.63: Opción inspeccionar, fichero index.html de la aplicación web
Adicionalmente, se comprobará que la aplicación web funcione en todos los

principales navegadores web actuales.
6.7. Iteración 4
El objetivo de esta iteración es la creación de las operaciones DICOM Store
y Query&Retrieve.
6.7.1. Análisis
Esta iteración se centra en la implementación de las operaciones DICOM
que realizará la herramienta, ası́ como de los servicios que darán acceso al uso
de las mismas. Ası́, se delimitan una serie de tareas para abordar la iteración:
• Archivos de configuración: Se crearán los archivos de configuración nece-

sarios para la correcta implementación de las operaciones DICOM Store
y Query&Retrieve.
• Servicio Query&Retrieve: Se implementará el servicio de la operación
DICOM Q&R, que permitirá buscar estudios en el PACS y recuperar los
mismos.
• Servicio Store: Se creará el servicio que implementará la operación DI-
COM Store que permitirá almacenar los estudios en el PACS.
• Test unitarios: Se crearán test unitarios haciendo uso de JUnit para las
clases de los servicios Q&R y Store.
• Manejo de errores: Se controlorarán los siguientes errores
◦ Problemas con los parámetros del servicio Query&Retrieve, como
puede ser que sean nulos o esten mal formados.
◦ Problemas con los servicios, como puede ser que el PACS configu-
rado no sea alcanzable, fallos en las consultas...
6.7.2. Diseño
El primer paso en esta iteración será la creación de los archivos de confi-
guración para poder permitir la flexibilidad necesaria para la instalación de la
herramienta en cualquier equipo del cliente. Además, se procederá a esta tarea
con la intención de que la implementación permita al equipo técnico realizar
estas instalaciones de la manera más fácil, rápida e intuitiva. Ası́, se creará un
fichero .xml para que el equipo técnico establezca la configuración del equipo
en cuestión en el que se instale la herramienta. Este fichero será leı́do por la
herramienta para adquirir esta configuración y funcionar de manera correcta
para cada cliente. Esta estructura se puede visualizar en la figura 6.64.
A continuación, se listan los archivos de configuración requeridos por la
herramienta, que se localizarán en el paquete utils del módulo Dicom:
• Config: Archivo principal de configuración que lee el archivo .xml de la

carpeta xml de la estructura de directorios , usando el método LoadCon-
figuration, para obtener las configuraciones para los servicios de Store y
Query&Retrieve. Figura 6.65.
Figura 6.64: Carpeta xml dentro de la estructura de directorios de la herra-

mienta
Figura 6.65: dicom/utils/Config.java
Figura 6.66: dicom/utils/NetworkConfig.java
Figura 6.67: dicom/utils/StoreConfig.java
• NetworkConfig: Recoge elementos de la configuración para poder esta-

blecer conexiones, tales como el hostname, puertos... Figura 6.66.
• StoreConfig: Recoge elementos de la configuración necesarios para poder

realizar la funcionalidad del servicio de Store, como son los puertos, los
aet... Figura 6.67.
• QueryConfig: Recoge elementos de la configuración requeridos para poder

realizar la funcionalidad del servicio de Query&Retrieve, como son los

puertos, los aet... Figura 6.68.
• DicomFileMetadataReader: Clase que lee los tags de un fichero DICOM.

Figura 6.71. Contiene los siguientes métodos:
◦ read(File, int []): Lee los tags especificados en el array del tipo int
contenidos en el fichero especificado y devuelve la información re-
copilada.
◦ read(File, int): Lee el tag pasado como parámetro del fichero y de-
vuelve la información recopilada.
◦ read(File): Lee todos los tags presentes en el fichero y devuelve toda
la información recopilada.
• DicomStudy: Clase que representa a un estudio DICOM mediante un

HashMap que contiene sus elementos DICOM obtenidos del objeto DI-
COM. Figura 6.69.
• DicomObjectDicomStudyConversor: Se añade un conversor para conven-

tir objetos DICOM a estudios DICOM y viceversa. Figura 6.70.
• GlobalNames: Clase de definición de constantes de configuración, tales

como los Tags DICOM que se quieren recuperar, la ubicación del fichero
.xml...
Figura 6.68: dicom/utils/QueryConfig.java
Figura 6.69: dicom/utils/DicomStudy.java

Figura 6.70: dicom/utils/DicomObjectDicomStudyConversor.java
Figura 6.71: dicom/utils/DicomFileMetadataReader.java
Figura 6.72: dicom/services/QueryRetrieveSCU.java
Para la implementación del servicio Q&R se agrerará un paquete llamado

Services al módulo Dicom, donde se realizará dicha codificación, cuyo diseño
podemos observar en la figura 6.72.
Las funcionalidades del servicio Q&R son las siguientes:
• Start: Inicia la escucha del servidor en el puerto configurado.
• Stop: El servidor deja de escuchar.
• Open: Abre una conexión con la entidad de destino.
• Close: Cierra la conexión con la entidad de destino.
• GetKeys: Recupera los Tags DICOM que se usarán para filtrar la búsque-
da en el PACS.
• Query: Implementa la operación DIMSE C-Find por la cual se recupera

una lista de objetos DICOM.
• Move: Implementa la operación DIMSE C-Move por la cual se realiza

una petición a la entidad de destino para que le envı́e los objetos DICOM
pasados como parámetro.
Para la codificación del servicio de Store se añadirá un paquete llamado

Store dentro del paquete Services en el módulo Dicom, donde se implementará
dicho servicio, cuyo diseño se puede visualizar en la figura 6.73.
Figura 6.73: dicom/services/store/StoreSCU.java
Las funcionalidades del servicio de Store son las siguientes:
• Start: Inicia la escucha del servidor en el puerto configurado.
• Stop: El servidor deja de escuchar.
• Open: Abre una conexión con la entidad de destino.
• Close: Cierra la conexión con la entidad de destino.
• Send: Implementa la operación DIMSE C-Store por la cual se mandan

los objetos DICOM solicitados para su almacenamiento.
• AddFile: Añade un nuevo fichero DICOM a través del fichero DICOM

recibido.
El primer paso en esta iteración será la creación de la carpeta xml en la
estructura de directorios de la herramienta para poder añadir el fichero .xml
para la configuración de los parámetros necesarios para el correcto funciona-
miento de los servicios del módulo Dicom en cualquier equipo en el que se
instale la misma.
Una vez creada y codificado el fichero .xml para su posterior uso por el
equipo de servicio técnico de la empresa, se procede a crear las clases de con-
figuración en el paquete utils del módulo Dicom que leeran este fichero.
Adicionalmente, también se añadirán clases que aportan métodos que serán

utilizados por ambos servicios DICOM para la realización de sus funcionalida-
des. Ası́, la estructura de del paquete Utils se puede ver en la figura 6.74.
Figura 6.74: Estructura del paquete dicom/utils
Para la codificación de los servicios Query&Retrieve y Store se volverá

a utilizar la librerı́a DCM4CHE, la cual nos facilita, como se comentó con
anterioridad, el uso de objetos DICOM, elementos DICOM de los mismos,
manejo de ”Tags” DICOM, conexión entre equipos DICOM, estructuras de
los servicios DIMSE...
Una vez implementadas las funcionalidades de dichos servicios, la estruc-
tura de los mismos en el módulo Dicom se puede visualizar en la figura 6.75.
Figura 6.75: Estructura de los servicios del módulo Dicom
6.7.4. Pruebas
Para comprobar el correcto funcionamiento de los servicios DICOM im-
plementados en esta iteración se crearán, por cada servicio, test unitarios,
haciendo uso de JUnit, llamados igual que la clase que testean, con la palabra
”Test” concatenada al final.
En ambos casos, se utilizará la herramienta DICOM CONQUEST, gracias
a la cual podremos replicar un PACS real, y realizar operaciones sobre él.
En la clase StoreTest, se comprobará el correcto envı́o de ficheros DICOM
ası́ como su recepción y correcto almacenamiento en el PACS, además de añadir
casos de uso para cerciorarse de que la aplicación responde de manera adecuada

a los posibles errores comentados en el apartado de Análisis de la Iteración 4.
En la clase QueryTest, se comprobará el correcto funcionamiento de las dos
partes que comprenden el servicio Query&Retrieve:
• Query: Se comprobará la correcta implementación de esta parte mediante

queries con diferentes ”Tags” DICOM y viendo que estas búsquedas
devuelven los objetos DICOM correspondientes del PACS.
• Retrieve: Se recuperarán objetos DICOM de las anteriores búsquedas y

se comproborá su validez con respecto a los objetos DICOM almacenados
en el PACS utilizado.
A continuación, se muestra la estructura de dichos test en el módulo DI-

COM en la figura 6.76.
Figura 6.76: Estructura de los tests del módulo Dicom
6.8. Iteración 5
El objetivo de esta iteración es la modificación de los campos del estudio y
su envı́o al PACS siguiendo dos criterios:
• Matcheo automático: El programa realizará una query al PACS por de-

fecto usando unos campos determinados, con el objetivo de encontrar el
estudio candidato a pertenecer al mismo paciente que queremos incluir al
PACS. Se presentará al usuario dicho estudio y, si el usuario lo selecciona,
el programa modificará el estudio y se enviará.
• Matcheo manual: Se presentará al usuario una interfaz que le permitará

hacer una query al PACS y seleccionar el estudio del que se copiarán los
campos y se envı́ará el estudio modificado.
Además, se permitirá comprobar el historial de modificaciones de estudios

que se hayan ido realizando.
6.8.1. Análisis
Esta iteración se centra en la implementación de las dos posibilidades de
reconciliación de estudios, por lo que se dividirá el trabajo en las siguientes
tareas:
• Matcher: Se implementarán las operaciones de matcheo, usando los ser-

vicios Query&Retrieve y Store del módulo Dicom.
• Servicio de Matching: Se implementará el servicio que dará acceso a las

funcionalidades del Matcher.
• Servicio RMI: Se creará el servicio RMI que expondrá las funcionalidad

de Matching al módulo Web.
• Controlador Web: Se encargará de conectar la parte HTML-JavaScript

con el servidor.
• Interfaz Web: Se añadirán los diálgos para realizar el Matching y la

pestaña de Histórico para poder comprobar las modificaciones realizadas
por la herramienta.
• Tests funcionales: Se realizarán tests funcionales para comprobar la co-

rrecta implementación de las funcionalidades del servicio de matching.
6.8.2. Diseño
Para la implementación del Matcher, se creará una interfaz llamada Dicom-
Module y una implementación para las opciones de matcheo definidas, dentro
del paquete facade en el módulo Dicom, usando los servicios de Query&Retrieve
y Store, cuyo diseño se puede observar en la figura 6.77.
Los métodos implementados por el Matcher son los siguientes:
• SetNetworkingConfigs: Establece la configuración para las conexiones en-

tre entidades DICOM.
• Query: Lanza una búsqueda con los tags especificados, devolviendo una
lista con los objetos DICOM encontrados.
• qrFind: Devuelve los estudios DICOM obtenidos al realizar una búsqueda

con los tags especificados
• Move: Se realiza una petición para que se envı́en los objetos DICOM
pasados como parámetro.
Figura 6.77: Interfaz e implementación del paquete dicom/facade
• qrMove: Se realiza una petición para mover los estudios DICOM pasados
como parámetro a la entidad de destino indicada.
• readMetadata(File, int []): Lee los tags especificados en el array del ti-
po int contenidos en el fichero especificado y devuelve la información
recopilada.
• readMetadata(File, int): Lee el tag pasado como parámetro del fichero y

devuelve la información recopilada.
• readMetadata(File): Lee todos los tags presentes en el fichero y devuelve

toda la información recopilada.
A continuación se añadirá el servicio (interfaz e implementación) que dará

acceso a las funcionalidades del Matcher. Este servicio se incluirá en el paquete
MatcherService del módulo Core, como se puede ver en la figura 6.78.
Las funcionalidades que este servicio implementan son las siguientes:
• MatchMedia: Añade el paciente y estudio modificado, encontrado me-

diante el Matching automático, y añade esta información en una nueva
carpeta en el directorio Processed.
• FindMedia: Realiza la funcionalidad de Matching automático, recopila la

información del paciente y realiza una búsqueda que devuelve el estudio
Figura 6.78: Interfaz e implementación del servicio core/model/MatcherService
cuyos datos coinciden con los del paciente, o ninguno si no existe ningún
match.
• FindMediaWithQuery: Realiza la funcionalidad de Matching Manual,

realiza una búsqueda a través de los Tags DICOM indicados y devuelve
la lista de estudios filtrados por estos elementos DICOM.
• Store: Almacena los pacientes y estudios modificados, a través del Mat-

ching Manual, y añade esta información en una nueva carpeta en el di-
rectorio Processed.
• MoveDirs: Método auxiliar para mover directorios
• ReplaceTags: Método para cambiar los valores de los Tags DICOM de

un fichero.
• OverWriteFile: Método para guardar los cambios realizados sobre un

fichero DICOM
• MoveFile: Método auxiliar para mover ficheros.
El siguiente paso será la creación del servicio RMI que expondrá las fun-
cionalidades del servicio de Matching al módulo Web. Ası́, se creará la clase
MatcherServiceRmi en el paquete rmi del módulo Core, con el diseño presen-
tado en la figura 6.79.
Figura 6.79: Interfaz e implementación del servicio RMI core/rmi/MatcherSer-

viceRmi
Seguidamente se continuará con la creación del controlador web (REST)

que se encargará de conectar la parte HTML-JavaScript con el servidor de la
herramienta. Se implementará en el paquete Controller del módulo Web como
se puede observar en la figura 6.80.
Figura 6.80: Controlador web del servicio de Matching web/controller/Mat-

cherController
Una vez se tengan todas estas clases implementadas, se pasará a la codifica-

ción de los diálogos que implementarán la funcionalidad de matching añadidad
en esta iteración. Además, se añadirá una nueva pestaña a la aplicación web,
Histórico, en la que se podrán visualizar las modificaciones realizadas por la
herramienta.
Los pasos a realizar en esta implementación son idénticos a los tomados en
la iteración 3, puesto que se está añadiendo una nueva funcionalidad como se
realizó en su momento en dicha iteración.
Ası́, el primer paso para la codificación de esta iteración será la creación
del Matcher, el cual dispondrá de una interfaz y una implementación, como se
puede observar en la figura 6.81.
Figura 6.81: dicom/facade
Una vez se termine de implementar el Matcher, se añadirán los servicios

para poder acceder a las funcionalidades que se acaban de añadir al Matcher.
La estructura de este servicio se puede visualizar en la figura 6.82.
Figura 6.82: core/model/matcherService
Con el servicio creado, se creará el servicio RMI del Matcher. Además

se añadirá este servicio en las clases RmiServer.java, en el módulo Core, y
RmiServices.java, del módulo Web. Ası́, la estructura de los servicios RMI es
la presentada en la figura 6.83.
Figura 6.83: core/rmi
Por último, se añadirá el controlador web del Matcher. Ası́, la estructura

de los controladores web en el módulo Web quedará como se puede visualizar
en la figura 6.84.
Figura 6.84: web/controller
En la parte de la interfaz web, se dividirá la implementación en dos partes

diferenciadas:
• Pestaña de histórico: Se añadirá una nueva pestaña en la que se visua-

lizarán los estudios modificados por la herramienta, haciendo uso de la
funcionalidad del controlador web de la entidad Estudio Modificado, ya
implementada en la Iteración 3.
• Diálogos de matching: Se añadirán los diálogos para permitir realizar el

Matching Manual y el Matching automático. Se utilizarán las funcionali-
dades del controlador web del Matcher que se acaba de implementar en
esta iteración.
Una vez finalizada esta iteración, se habrán añadido las últimas funciona-
lidades de la herramienta, obteniendo el producto final del proyecto. A conti-
nuación, en las figuras 6.85, 6.86, 6.87, 6.88, 6.89, 6.90, 6.91 y 6.92, se pueden
visualizar las últimas funcionalidades agregadas a la página web.
Figura 6.85: Ación de ver un estudio

Figura 6.86: Almacenar estudio con el estudio presentado de forma automática
Figura 6.87: Almacenar estudio cuando no se encuentra ningún estudio de

forma automática
Figura 6.88: Pestaña Buscar, para la realización de búsquedas manuales
Figura 6.89: Búsqueda manual, utilizando el campo ”Nombre Paciente”

Figura 6.90: Búsqueda manual, realizada por el campo ”Fecha de nacimiento”
Figura 6.91: Acción de almacenar estudio recuperado a través de la búsqueda

manual
Figura 6.92: Pestaña de Histórico

6.8.4. Pruebas
Para la comprobación de la correcta implementación de las funcionalidades
de esta iteración, se ha utilizado la herramienta DICOM Conquest. En esta
herramienta se dispone de una base de datos proporcionada por la empresa
que contiene datos ficticios pero con estructura real. Ası́, utilizando esta he-
rramienta como el PACS de destino, se puede ir comprobando de forma que en
todos los casos de uso la aplicación web realiza sus funcionalidades de forma
correcta.
También se usará la herramienta MySQL Workbench para comprobar la
correcta adición de los pacientes y estudios modificados al realizar la importa-
ción por parte de la aplicación web, y que se generan de manera correcta las
carpetas y ficheros en el directorio Processed de la estructura de directorios de
la aplicación.
Ası́ mismo, se vuelve a usar la opción Inspeccionar del navegador Google
Chrome [36] para tareas de Debug en la parte del módulo Web y se comprue-
ba el correcto funcionamiento de la aplicación en todos los navegadores web
actuales mayormente usados.
Capı́tulo 7
Conclusiones
Con el proyecto finalizado, se puede afirmar que alcanzaron las metas pro-
puestas en el análisis de requisitos inicial, ası́ como los requisitos definidos en
cada una de las iteraciones. Si bien es cierto que durante la realización del pro-
yecto existieron desviaciones temporales modificaciones al diseño e iteraciones
propuestas al inicio del mismo, estas no han interferido en la consecución de
los objetivos y los principios de diseño predefinidos, ası́ como con el diseño de
la web propuesto, que fue realizado siguiendo los mockups propuestos por la
empresa.
A continuación se listan los principales objetivos conseguidos con la reali-
zación de este proyecto:
• Se ha implementado un importador de estudios DICOM capaz de re-

conciliar estudios clı́nicos, tanto de forma automática como de forma
manual, pudiendo filtrarlos por distintos campos.
• La herramienta es capaz de leer CD/DVD/USB y obtener la información

DICOM contenida en estos dispositivos de almacenamiento a través de
la lectura del DICOMDIR.
• Se dispone de una aplicación web con una interfaz de usuario ágil, sencilla
e intuitiva, cuyo objetivo es facilitar el trabajo de los profesionales del
sector clı́nico.
• Se tiene una herramienta con gran trazabilidad, gracias al diseño pro-

puesto para la misma, pudiendo ver todos los cambios realizados por la
misma.
• Se han implementado las tres principales operaciones DIMSE: C-Store,

C-Find y C-Move, ası́ como combinaciones de las mismas, como la ope-
ración Query&Retrieve.
93
94
• Se ha implementado una herramienta totalmente configurable, facilitan-

do ası́ la tarea del equipo técnico de la empresa de configurar la aplicación
en los equipos de los clientes.
Capı́tulo 8
Trabajo futuro
Como lı́neas futuras de trabajo para la continuación y mejora de este pro-

yecto, propondrı́a:
• Añadir un visor a la aplicación web, para permitir la visualización de las

imágenes de los estudios a los profesionales del sector médico, tanto en
2D como en 3D.
• Mejorar la pestaña del historial de modifaciones: añadirle posibles fallos

en las modificaciones, estudios importados, permitir deshacer cambios...
• Implementar más funcionalidades DICOM, como la operación DICOM

Print, que permite mandar un estudio a una impresora para generar
books (pequeños libros con estudios clı́nicos).
• Permitir registrar multiples PACS y poder almacenar en cada uno de

ellos según convenga.
• Añadir diferentes manear de importar estudios, pues puede que no siem-

pre interese importar toda la información que estos contienen. Permitir
previsualizar su contenido y elegir solo aquellas partes que se deseen
incorporar.
• Crear una versión de escritorio de la aplicación.
• Añadir usuarios a la aplicación, tanto administradores como usuarios,

con diferentes funcionalidades.
95
96
Referencias
[1] Wikipedia, “Imagen médica,” https://es.wikipedia.org/wiki/Imagen m%

C3%A9dica, Website, 2018.
[2] ——, “Wilhelm conrad röntgen,” https://es.wikipedia.org/wiki/Wilhelm

R%C3%B6ntgen, Website, 2018.
[3] P. E. A. C. A. Martinez Noguera, E. Montserrat Esplugas, “Evolución

de la imagen médica radiológica desde roentgen hasta la digitalización,”
Presentación Electrónica Educativa, p. 25, 2012.
[4] Nema, “Digital imaging and communication in medicine,” http://medical.

nema.org/, Website, 2018.
[5] ACR, “American college of radiology,” http://www.acr.org/, Website,

2018.
[6] N. E. M. Association, “Dicom standard,” https://www.dicomstandard.

org/, Website, 2018.
[7] Wikipedia, “Modelo tcp/ip,” https://es.wikipedia.org/wiki/Modelo

TCP/IP, Website, 2018.
[8] ——, “Picture archive and communication system,” https://es.wikipedia.

org/wiki/Picture Archiving and Communication System, Website, 2018.
[9] ——, “Frontend y backend,” https://es.wikipedia.org/wiki/Front-end y

back-end, Website, 2018.
[10] Oracle, “Mysql,” https://www.mysql.com/, Website, 2018.
[11] ——, “Mysql workbench,” https://www.mysql.com/products/

workbench/, Website, 2018.
[12] ——, “Java,” https://www.java.com/es/, Website, 2018.
[13] “Dcm4che,” https://www.dcm4che.org/, Website, 2018.
97
98 REFERENCIAS
[14] T. A. S. Foundation, “Maven,” https://maven.apache.org/, Website,

2018.
[15] Apache, “Maven,” http://maven.apache.org/, Website, 2018.
[16] P. Software, “Spring,” https://spring.io/, Website, 2018.
[17] T. J. Team, “Junit,” https://junit.org/junit5/, Website, 2018.
[18] Microsoft, “.net,” https://www.microsoft.com/net, Website, 2018.
[19] ——, “C,” https://docs.microsoft.com/es-es/dotnet/csharp/, Website,

2018.
[20] P. Sight, “Javascript,” https://www.javascript.com/, Website, 2018.
[21] W. W. W. C. (W3C), “Html,” https://www.w3.org/html/, Website, 2018.
[22] ——, “Css,” https://www.w3.org/Style/CSS/, Website, 2018.
[23] R. Zaharia, “Dicom elements,” http://dicomiseasy.blogspot.com/2011/

11/introduction-to-dicom-chapter-iii-dicom.html, Website, 2008.
[24] ——, “Dicom objects,” http://dicomiseasy.blogspot.com/2011/12/

chapter-4-dicom-objects-in-chapter-3.html, Website, 2008.
[25] N. E. M. Association, “Dicom services,” http://dicom.nema.org/dicom/

2013/output/chtml/part07/sect 7.5.html, Website, 2018.
[26] R. Zaharia, “Query/retrieve part i,” http://dicomiseasy.blogspot.com/

2012/01/dicom-queryretrieve-part-i.html, Website, 2008.
[27] ——, “Query/retrieve part ii,” http://dicomiseasy.blogspot.com/2012/

02/c-move.html, Website, 2008.
[28] ——, “Dicomdir,” http://dicomiseasy.blogspot.com/2013/03/

dicomdir-and-media-interchange.html, Website, 2008.
[29] “Quick dicom editor,” https://sourceforge.net/projects/

dicomeditorbybenp/, Website, 2018.
[30] “Conquest dicom,” https://ingenium.home.xs4all.nl/dicom.html, Websi-

te, 2018.
[31] Codonics, “Integrity,” https://codonics.com/Support/Integrity/, Websi-

te, 2018.
[32] Mediavis, “Mediavis importer,” https://www.medavis.com/en/

medavis-dicom-importer/, Website, 2018.
REFERENCIAS 99
[33] P. Agiles, “Desarrollo iterativo e incremental,” https://proyectosagiles.

org/desarrollo-iterativo-incremental/, Website, 2018.
[34] Wikipedia, “Remote method invocation,” https://es.wikipedia.org/wiki/

Java Remote Method Invocation, Website, 2018.
[35] W. W. W. C. (W3C), “Xml,” https://www.w3schools.com/xml/xml

whatis.asp, Website, 2018.
[36] Google, “Google chrome,” https://www.google.com/chrome/, Website,

2018.
APÉNDICES
101
Apéndice A
Manual de instalación
A.1. Software necesario

El software necesario para la instalación de la herramientas es el siguiente:
• Java 8
• MySql (Versión 7 en adelante)
A.2. Instalación
A.2.1. MySql
La instación de mysql se hará mediante su instalador, que podemos encon-
trar en la página web de Oracle. El instalador Mysql nos mostrará la lista de
software de Mysql que esté instalado en este equipo, además de una serie de
botones que nos permitirán añadir nuevo software, ası́ como actualizar o des-
instalar el ya existente. En nuestro caso necesitamos instalar las herramientas
MySqlWorkbench y MySql Server.
Una vez instalada, pasaremos a crear un nuevo schema llamado studyimpor-
ter, añadiendole el usuario y contraseña indicada por el equipo técnico y dando
permisos totales al mismo. Una vez configurada la base de datos, ejecutaremos
el script CreateTables incluı́do con la herramienta.
A.2.2. Java
Se ejecutará la opción maven install en los módulos Core y Web para
generar los archivos .jar en la carpeta target. Una vez obtenidos estos, generar
103
104 A.2. Instalación
los archivos .bat que lanzarán la aplicación, como se muestra en las figuras A.1,
A.2 y A.3.
Figura A.1: Bats de arranque de la aplicación
Figura A.2: Bats de arranque de la aplicación, módulo Core
Figura A.3: Bats de arranque de la aplicación, módulo Web
A.2.3. Apache Server

Se deberá descargar la última versión de Apache para Windows. A partir
de ahı́, en el equipo en el que se realiza la instalación se seguirán los siguientes
pasos
• Se descomprime la carpeta de Apache en C: con el nombre apache24.
• Se abre un cmd como administrador y se ejecutan los siguientes coman-

dos:
1 cd C:\apache24\bin
2 httpd -k install
3 httpd -k start
4 cd C:\apache24\htdocs
A. Manual de instalación 105
• Se copia el contenido de la carpeta Web en la carpeta htdocs de apache

(el fichero index.html y las carpetas js, imágenes y css).
• Se modifica el fichero C:/apache24/htdocs/js/config.js para especificar la

ip del equipo.
Apéndice B
Manual de Usuario
En este apéndice se va a mostrar un manual de usuario con las vistas

de la aplicación web y la de gestión de la entrada/salida de dispositivos de
almacenamiento para explicar su funcionamiento.
B.1. Introducción
El integrador de estudios es una herramienta capaz de leer estudios DI-
COM (Estándar reconocido mundialmente para el intercambio de imágenes
médicas) de diferentes fuentes (CD,DVD,USB...) extrayendo información de
los mismos para poder comparar estos datos con los presentes en el PACS
(Sistema de archivado y transmisión de imágenes médicas) del centro médico
en busca de pacientes a los que puede pertenecer el estudio. Una vez realizada
esta comparación, al usuario se le mostrarán todos los posibles pacientes que
son candidatos a ser el dueño real de ese nuevo estudio clı́nico, pudiendo ası́
elegir a quien le pertenece, con lo que el integrador realizará las modificaciones
necesarias al estudio a nivel DICOM y lo enviará al PACS para que se alma-
cene con el resto de estudios que el paciente tiene en su centro médico (a este
último proceso lo llamaremos matching).
Para comenzar a leer estudios, el usuario deberá introducir un sistema de al-
macenamiento externo con los mismos. El sistema reconocerá dicho dispositivo
y automáticamente almacenará los estudios que en el se encuentre, mostrando
las principales caracterı́sticas de los mismos en la aplicación web.
107
108 B.2. Pasos para la integración de un estudio DICOM
B.2. Pasos para la integración de un estudio

DICOM
A continuación se listan los pasos a seguir para una correcta importación
de estudio DICOM:
• Insertar el medio fı́sico (CD/DVD,USB): Se debe introducir el medio

fı́sico, donde el estudio DICOM esté localizado, dentro del equipo. Una
vez introducido, la herramienta importará los mismos.
• Acceder a la página web de la aplicación: En esta se pueden ver todos

los estudios importados por la herramienta y sus principales elementos
DICOM, tal y como se puede ver en la figura B.1.
Figura B.1: Página principal de la web, pestaña de Integrador de estudios
• Ver un estudio: En la columna Acciones de cada estudio, existe una

imagen de una lupa que identifica la funcionalidad Ver estudio, la cúal
nos permite revisar los datos más importantes del estudio elegido. Esta
acción se puede ver en la figura B.2.
Figura B.2: Ación de ver un estudio

• Matcheo Automático: Desde esta vista se nos presenta de manera au-

tomática un estudio que potencialmente sea con el que queramos corres-
ponder el estudio elegido, como se puede observar en la figura B.3. En
esta figura se ve como la herramienta presenta la información del estudio
elegido en la columna de la izquierda, con los siguientes campos:
◦ Id paciente: Identificador del paciente.

◦ Nombre paciente: Nombre del paciente al que pertenece el estudio.
◦ Fecha de nacimiento: Fecha de nacimiento del paciente.
◦ Accesion number: Número de identificación del estudio.
En la columna de la derecha, la aplicación presenta la información del

estudio del paciente que potecialmente sea el dueño real del estudio ele-
gido. Si se quiere realizar la importación con este estudio, se debe pulsar
el botón de almacenar. Al importar el estudio elegido, se modificarán los
elementos DICOM del estudio elegido correspondientes a la información
mostrada por la herramienta (Identificador del paciente, su nombre, su
fecha de nacimiento y el accesion number del estudio) para igualarlos a
los datos de la columna de la derecha. El resto de elementos DICOM del
estudio que no se presentan, como podrı́an ser la modalidad del estudio
o su descripción, no se modificarán. Una vez modificados estos elementos
DICOM, el estudio se importará al PACS.
Si no es ası́, se puede pasar a realizar el matching de forma manual
pasando a la pestaña de Buscar.
Figura B.3: Almacenar estudio con el estudio presentado de forma automática

• Matcheo Manual: En la pestaña Buscar se realizan los Matching Manua-

les. Para ello, se seguirán los siguientes pasos:
◦ Realizar búsqueda: Se realizarán consultas filtradas a partir de los

elementos DICOM presentados, ası́ como combinaciones de los mis-
mos. Para ello se rellenarán los campos deseados de entre los pre-
sentados, los cuales son:
◦ Id paciente: Identificador del paciente.
◦ Nombre paciente: Nombre del paciente al que pertenece el es-
tudio.
◦ Fecha de nacimiento: Fecha de nacimiento del paciente.
◦ Accesion number: Número de identificación del estudio.
Una vez se hayan rellenado los campos deseados, se debe pulsar
el botón Buscar para realizar la búsqueda filtrada, conforme a los
campos rellenados. Esta búsqueda presentará la lista de estudios
que hayan pasado los filtros que se hayan elegido. Ejemplos de estas
búsquedas llevadas a cabo pueden ser visualizadas en las figuras
B.4, B.5 y B.6.
Figura B.4: Pestaña Buscar, para la realización de búsquedas manuales

Figura B.5: Búsqueda manual, utilizando el campo ”Nombre Paciente”
Figura B.6: Búsqueda manual, realizada por el campo ”Fecha de nacimiento”

◦ Almacenar estudio: Para almacenar el estudio elegido anteriormente

con la información de uno de los estudios devueltos por la búsqueda,
se elegirá la acción de Almacenar estudio en la columna del estudio
correspondiente. Esta funcionalidad puede verse en la figura B.7.
Al importar dicho estudio, se modificarán los elementos DICOM
del mismo correspondientes a la información mostrada por la he-
rramienta (Identificador del paciente, su nombre, su fecha de naci-
miento y el accesion number del estudio) para igualarlos a los datos
de estudio elegido en la lista de estudios devueltos por la búsqueda
realizada. El resto de elementos DICOM del estudio que no se pre-
sentan, como podrı́an ser la modalidad del estudio o su descripción,
no se modificarán. Una vez modificados estos elementos DICOM, el
estudio se almacenará en el PACS.
Figura B.7: Acción de almacenar estudio recuperado a través de la búsqueda

manual
A continuación se realiza una explicación de las funcionalidades adicionales

de las dos partes en las que se divide la herramienta, la aplicación web y la
aplicación de consola para la gestión de la entrada y salida de dispositivos de
almacenamiento.
B.3. Aplicación web

Cuando el usuario accede a la aplicación se le presenta la información más
destacada de todos los estudios que se han recopilado de los distintos dispo-
sitivos de entrada que el usuario haya introducido en su sistema. Desde esta
vista, adicionalmente de las funcionalidades ya explicadas, se puede:
• Borrar el estudio: Esta opción permite borrar el estudio elegido. Se

puede ver este comportamiento en las figuras B.8 y B.9
• Cambiar a la pestaña de Historic: Se pasará a la vista de la historia

de las modificaciones a estudios realizadas por el usuario. Esta vista se
puede observar en la figura B.10
Figura B.8: Ación de borrar un estudio
Figura B.9: Confirmación requerida a la hora de borrar un estudio
Figura B.10: Pestaña de Histórico

B.4. Aplicación de gestión de la E/S de dispositivos de
114 almacenamiento
B.4. Aplicación de gestión de la E/S de dispo-

sitivos de almacenamiento
Para el correcto funcionamiento del aplicativo deberemos ejecutar el .exe
del mismo. Una vez lanzado, disponemos de una ventana de consola que nos
indica que tipo de dispositivo ha sido insertado/expulsado, como se puede
oberservar en la figura B.11.
Figura B.11: Vista de la aplicación de consola para gestionar la entrada y salida

de dispositivos de almacenamiento de la aplicación

Trabajo Fin de Grado Grado en Ingenier Ia Inform Atica

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Trabajo Fin de Grado Grado en Ingenier Ia Inform Atica

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INFORMÁTICA

Trabajo fin de grado

Grado en Ingenierı́a Informática

Diseño y desarrollo de una herramienta para

Autor: Raúl Silguero Santos

A Coruña, a 6 de septiembre de 2018.

Tı́tulo del proyecto: “Diseño y desarrollo de una herramien-

Clase del proyecto: Proyecto clásico de ingenierı́a.

Nombre do alumno: Raúl Silguero Santos

Nombre de los directores: Julián Alfonso Dorado De La Calle

Miembros del tribunal:

ayudado a conseguir mis metas

Lista de palabras clave

2.5.6. Quick DICOM Editor . . . . . . . . . . . . . . . . . . . . 16

5. Planificación, recursos y costes 27

A. Manual de instalación 103

A.2.2. Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

B. Manual de Usuario 107

2.1. Estructura del modelo de datos DICOM . . . . . . . . . . . . . 11

3.1. Dispositivo Integrity . . . . . . . . . . . . . . . . . . . . . . . . 20

5.1. Planificación temporal inicial Iteración 1 . . . . . . . . . . . . . 29

6.1. Arquitectura General . . . . . . . . . . . . . . . . . . . . . . . . 36

6.62. Comprobación al borrar un estudio . . . . . . . . . . . . . . . . 74

6.91. Acción de almacenar estudio recuperado a través de la búsqueda

A.1. Bats de arranque de la aplicación . . . . . . . . . . . . . . . . . 104

B.1. Página principal de la web, pestaña de Integrador de estudios . 108

El presente capı́tulo tiene como objetivo la presentación del contexto en el

DICOM (Digital Imaging and Communication in Medicine) [6].

• Se realiza la prueba en un sitio diferente a donde se le realizará el

• Prefiere que sea un especialista el que revise sus pruebas médicas.

Los problemas vienen provocados porque los centros no pueden unificar

Ası́, el importador de estudios que se presenta se encargarı́a de resolver

• Estudio del estándar DICOM de almacenamiento y comunicación de ima-

• Estudio del sistema de archivado y transmisión de imágenes médicas

• Estudio del proceso de entrada y salida de dispositivos de almacenamien-

• Análisis de las tecnologı́as candidatas a ser usadas en el proyecto.

• Diseño e implementación de una aplicación de consola para la gestión de

• Diseño e implementación de una aplicación web intuitiva y eficiente para

– Visualizar los datos más caracterı́sticos de los estudios clı́nicos im-

1.4. Estructura de la memoria

1. Introducción: El presente capı́tulo donde se explican el contexto, la

2. Fundamentos tecnológicos: En este capı́tulo se listan las tecnologı́as

3. Estado de la cuestión: Se realiza un análisis de las alternativas existen-

4. Metodologı́a de desarrollo: Se expone la metodologı́a usada en este

5. Planificación, recursos y costes: Se muestran más detalladamente

6. Sistema desarrollado: Análisis de requisitos y diseño general de la

7. Conclusiones: Conclusiones referentes a la realización del trabajo fina-

8. Trabajo futuro: Se lista una serie de ampliaciones o mejoras que se

9. Referencias: Se incluyen todas las referencias bibliográficas utilizadas

10. Apéndices: Manual de uso e instalación de la aplicación.

En este capı́tulo se analizan las tecnologı́as elegidas para la realización de

2.1. Base de datos

• Rapidez: Velocidad al realizar las operaciones, lo que le convierte en uno

• Eficiencia: Bajo coste en requerimientos para la elaboración de bases de

• Fácil configuración, instalación y uso.

• Soporta gran variedad de Sistemas Operativos.

• Seguridad: El sistema flexible de autorización de MySql, permite algunos

eliminar una base de datos) a usuarios especı́ficos o grupos de ellos.

• Escabilidad: MySql maneja bases de datos de hasta 50 millones de filas

El mayor problema de MySql es que puede provocar problemas de integri-

optimizaciones en el código, especialmente en cuanto a manejo de memoria,

• compile: Genera los ficheros .class compilando los fuentes .java.

• test: Ejecuta los test automáticos de JUnit existentes, abortando el pro-