MCTWP: Plataforma de Software Libre para gestión de Imagen Médica en Ensayos Clínicos

Transcripción

1 MCTWP: Plataforma de Software Libre para gestión de Imagen Médica en Ensayos Clínicos Miguel Ángel Laguna Lobato 1 de abril de 2013 Universidad Rey Juan Carlos Escuela Superior de Ciencias Experimentales y Tecnología Laboratorio de Análisis de Imagen Médica y Biometría

2 Director Prof. Dr. Juan Antonio Hernández Tamames Codirector Prof. Dr. Norberto Malpica González

3 Los doctores D. Juan Antonio Hernández Tamames y D. Norberto Malpica Gonzalez de Vega, Profesores Titulares de Universidad del Departamento de Tecnología de Electrónica de la Universidad Rey Juan Carlos, en calidad de directores de la Tesis Doctoral que lleva por título Multi Clinical Trial Web PACS realizada por D. Miguel Ángel Laguna Lobato, HACEN CONSTAR: que esta Tesis Doctoral reúne los requisitos necesarios para su defensa y aprobación En Móstoles, a 1 de abril de 2013 Dr. D. Juan Antonio Hernández Tamames

4

5 Título: Autor: Multi Clinical Trial Web PACS Miguel Ángel Laguna Lobato Tribunal Calificador: Presidente D. Vocales D. D. D. Secretario D. Suplentes: D. D. Acuerdan otorgar la calificación de: En Madrid, a de de 2013

6

7 Para Olga y Guillermo

8

9 Agradecimientos He de reconocer, que cuando decidí iniciar este trabajo, no sabía muy bien lo que estaba haciendo. Sabía que por mi profesión y por mis inquietudes, podría ser una buena opción, que me permitiría desarrollar aún más mis habilidades y conocimiento. Sin embargo, tengo que admitir que no calibré adecuadamente el esfuerzo que me llevaría poder completar un trabajo tan completo. Por esta razón, mi primer agradecimiento debe ir dirigido a Encarni y también a Olga, porque ellas han sido quienes más han sufrido mis ausencias y a la vez, quienes más ánimo y apoyo me han dado. Haber realizado este trabajo, ha supuesto para mi un hito muy importante, que me ha situado justo en el inicio de un largo camino que deseo recorrer con calma pero con entusiasmo. Ha sido una experiencia intensa, en la que no solo me he desarrollado a nivel académico, sino que también me ha permitido mejorar y evolucionar el nivel de los desarrollos que he llevado a cabo en el ámbito profesional. Es por esta otra razón, que tengo que agradecer a mis antiguos jefes, Chema y Jesús, que me permitieran experimentar en mi puesto de trabajo y que me dieran la libertad y la confianza para poder aplicar aquellas ideas y mejoras que venían derivadas de mi trabajo de investigación. Pero como no puede ser de otra manera, a quién más tengo que expresar mi agradecimiento, es a mis directores, Juan y Norberto. Ellos supieron ver una oportunidad en mi inusual propuesta y ellos me dieron la posibilidad de entrar en este mundo del que ahora no quiero salir.

10 Tengo que agradecer a ambos, su dedicación y su paciencia, sus consejos y su tiempo y por supuesto su amistad y su cercanía, pues en todo momento me han hecho sentir uno más. A ellos les debo que esta tesis haya salido adelante, porque en los momentos difíciles, uno de los sentimientos a los que me aferraba, era el compromiso moral que tenía y tengo con ellos. He de agradecer también a la Fundación CIEN y a la Fundación Reina Sofía que me facilitaran el acceso a su laboratorio y a los datos con los que esta tesis se ha validado y como no, he de agradecer a todo el equipo de laboratorio su colaboración, en especial a Pablo y Alexandra. Por supuesto, hay una extensa lista de personas que también han influido de manera positiva en este trabajo. Unos porque fueron pacientes y entendieron mi esfuerzo, otros porque me dieron ánimos y buenos consejos, y otros porque me ayudaron a superar algún obstáculo y colaboraron en algún punto. Así que, gracias Ramón, aunque ahora nuestros caminos anden más separados, encontraremos la manera de confluir. Gracias Lorenzo y Rubén, por haber sido pacientes y saber criticar mis ocurrencias siempre de manera constructiva. Gracias Marcial, para mi es todo un orgullo que alguien como tú confíe en mi. Gracias Andrés, no se me olvida aquel favor. Gracias Carlos, codirigir contigo dos proyectos fin de carrera, me ha permitido adquirir otro punto de vista. Gracias familia, qué grande te hace sentir una familia! Gracias Lucía por enseñarnos a todos lo que es valor, fuerza y constancia. Aún no sabes lo lejos que vas a llegar. Gracias Verónica, qué gran responsabilidad en tus manos y cuanta falta hace, más gente como tú en este mundo. Por último, aunque no por eso menos importante, quiero agradecer siempre todo a mis padres. Yo no sería quien soy sin ellos y sin todos sus esfuerzos y sacrificios. Se que ellos se sienten orgullosos y felices de que pueda superar estos retos, pero ellos no saben que esto no es nada si se compara con sus logros. No importa qué haga en esta vida y cuantas cosas consiga, todo se lo deberé siempre a mis padres.

11

12

13 Índice general 1. Introducción Aplicaciones de la imagen médica Factores que limitan la aplicación de la imagen médica Marco de trabajo Organización de la memoria Estado del arte PACS como modelo inicial Inconvenientes de los sistemas basados en PACS MIRC MIRC en ensayos clínicos Inclusión de imágenes en MIRC Perfil TCE de IHE Perfil TCE MIDAS Soporte a algoritmos de tratamiento Escenarios de uso de MIDAS Modelos grid cabig National Biomedical Imaging Archive Automatización del análisis de la imagen médica BIRN Infraestructura de BIRN LONI LONI IDA i

14 LONI Pipeline XNAT Gestión del almacenamiento Colaboración y acceso público Planteamiento y justificación Soporte de múltiples formatos de imagen Protocolo de gestión de imagen médica Otras carencias Diferencias con XNAT Justificación del trabajo Hipótesis y Objetivos Hipótesis Objetivos Material y método Metodología y gestión del proyecto Modelos prescriptivos Metodologías ágiles Método de trabajo Herramientas de desarrollo Gestión del código fuente Infraestructura de sistemas Sistema operativo Infraestructura para el almacenamiento de datos Entidades de negocio Persistencia de las colecciones de imágenes Persistencia de los metadatos Problemas de la gestión de tres almacenes diferentes Servidor de aplicaciones Fundamentos de la arquitectura de la aplicación Patrón comando y aspectos transversales ii

15 Abstracción para las entidades de negocio Abstracción para la capa de acceso a datos Integración con la capa de vista Librerías para el tratamiento de las imágenes Resultados Descripción funcional Área de administración Área de investigación Entidades de negocio y flujo principal Gestión de la imagen Adquisición de imágenes Exportación de imágenes Modelo de datos para la imagen médica Tratamiento de la imagen médica Asociación automática de imágenes a un ensayo Gestión del almacenamiento Entidades de negocio Contenido de las imágenes Metadatos de las imágenes Gestión conjunta del almacenamiento Ejemplo de uso en escenario real Descripción del ensayo clínico gestionado Administración del ensayo Administración de usuarios y roles Administración de modalidades, procesos y tipos de imágenes Área de investigación Área de protocolables: ensayo, grupos, pacientes y estudios Gestión de tareas y resultados Movimiento, borrado de pacientes y eliminación de resultados iii

16 Entorno de explotación Backup Conclusiones Discusión Discusión sobre los tres tipos de almacenamiento Explotación de los metadatos Automatización de pipelines Integración con otras plataformas Referencias A. User Manual 129 A.1. Introduction and quickstart A.1.1. What is this? A Data model and workflow A Internal image representation and management A Image management A Storage management A Image acquisition A.2. Play it! A Virtual Machine Network configuration A.3. User s manual A.3.1. Administration area A.3.2. Research area A Associating uploaded images A Attach files A Protocol management A Manual task creation A Task and result management A Subject reallocation A Downloading and transferring images A.4. Image upload iv

17 A.5. How to install the application A.5.1. Basic packages A Java configuration A.5.2. Tomcat installation A APR Installation A Tomcat installation A Installing tomcat as a system service A Configuring AJP A Apache credentials A.5.3. exist installation A Configure exist A.5.4. PostgreSQL configuration A.5.5. Image storage A.5.6. Install (X)MedCon A.5.7. Reboot machine A.5.8. Application deployment and configuration A Configuring database access A (X)MedCon bin path A XML Data Base connection A Image collection path A DICOM configuration v

18

19 Índice de figuras 2.1. Arquitectura basada en PACS mejorada con un grid. Reproducción sobre imagen original de [1] Pantalla de consulta de un ETF en MIRC Esquema del servicio de almacenamiento MIRC. Obtenida de mircwiki.rsna.org Diagrama de perfiles de integración del marco técnico IHE para radiología. Obtenida del volumen 1 del marco técnico de radiología de IHE Diagrama de actores del perfil TCE. Obtenida del volumen 1 del marco técnico de radiología de IHE Instalación MIDAS de la Optical Society of America Arquitectura DGIS. Imagen obtenida de [2] Infraestructura de la red BIRN. Imagen obtenida de [3] Representación funcional de XNAT. Imagen obtenida de [4] Arquitectura de almacenamiento Teorema CAP, obtenido de [5] Propuesta de infraestructura Arquitectura Representación esquemática de un aspecto transversal Utilización de AOP para implementar un aspecto transaccional Patrón comando solucionando dependencias transversales Flujo de trabajo y control de calidad Modelo de objetos básico Entidades del flujo de trabajo vii

20 6.4. Clases abstractas para la representación de imágenes Especialización para Analyze Modelo de plugin para gestión de imagen. Implementación de Analyze Administración de los ensayos clínicos Administración de los usuarios del ensayo Administración de los tipos de procesos Administración de los tipos de imágenes Gestión de elementos protocolables y contenedores de imágenes Protocolo de ejemplo de un grupo del ensayo Tareas pendientes de un usuario Composición de capturas relativas al movimiento y borrado de pacientes A.1. Entity model. Boxes are shaded in gray for simplicity A.2. Workflow and quality control A.3. Image management model. Pink entities represent the Analyze specialization A.4. Storage architecture A.5. Main window of the application A.7. Workflow of researchers A.6. Meaning of buttons A.8. Temporal storage of uploaded images A.9. Wrong patient id A.10.Attached files management A.11.Protocol management A.12.Task form A.13.User tasks list A.14.Images of a study A.15.Upload images applet viii

21 1. Introducción Desde que aparecieron las primeras modalidades de adquisición de imagen médica digital, la gestión informatizada de las imágenes producidas en las exploraciones a pacientes ha supuesto un problema, tanto por la cantidad de recursos necesarios para su correcto tratamiento, como por la gran capacidad de almacenamiento exigido, así como por el ancho de banda requerido para la transmisión de este tipo de datos en un tiempo razonable. Hasta hace pocos años, el coste económico de la infraestructura necesaria para la utilización generalizada de la imagen médica digital, era muy elevado. Probablemente, este factor resultó determinante en el desarrollo de sistemas de información para la gestión de los datos de imagen médica, pues en un principio, estos sistemas se plantearon desde la perspectiva del proceso asistencial 1. En consecuencia, otras posibles aplicaciones de la imagen médica digital, como por ejemplo su utilización en ensayos clínicos, quedaron relegadas a un segundo plano. Así pues, en la actualidad, la gestión de la imagen médica en el ámbito asistencial ha alcanzado una fase de desarrollo muy madura, en la que cabe destacar como hitos más representativos el estándar Digital Imaging and Communications in Medicine (DICOM[6]) y los sistemas Picture Achivement Communication System (PACS[7]). El estándar DICOM, creado por la National Electrical Manufacturers Association (NEMA 2 ), surgió para facilitar la cooperación entre dispositivos de distintos fa- 1 Conviene destacar que la aplicación de la imagen médica en el ámbito asistencial es una actividad que repercute beneficios económicos directos, por lo tanto es percibida como una inversión a corto/medio plazo, mientras que otras aplicaciones de la imagen médica, pueden no resultar tan rentables en el corto plazo 2 1

22 Capítulo 1 bricantes de dispositivos de adquisición y tratamiento de imagen médica. Por lo tanto, DICOM no solo especifica un formato contenedor para la representación de la imagen médica, sino que también define una serie de servicios DICOM, que implementan procesos relacionados con la gestión de la imagen médica, como por ejemplo: Almacenamiento, consulta y recuperación de la imagen. Impresión de la imagen. Gestión de listas de trabajo. Transmisión de la imagen. El hecho de que DICOM fuera creado por la NEMA, propició la rápida adopción de este estándar, que al homogeneizar los entornos de adquisición y tratamiento de imagen médica, hizo posible la generalización en el uso de los sistemas PACS. Los sistemas PACS son repositorios centralizados de imágenes, en los que la organización de las imágenes gira en torno a la entidad paciente y a los distintos episodios clínicos, en los que se capturan imágenes médicas. El informe de 2008 sobre el uso de las TIC en los hospitales españoles, elaborado por el Ministerio de Sanidad y Consumo[8], demuestra el interés que ha recibido la gestión de la imagen en el proceso asistencial, ya que para entonces, el 62 % de los hospitales españoles disponía de un sistema PACS. En la actualidad, el porcentaje de hospitales españoles con sistemas PACS es seguramente muy superior, ya que, si bien la actualización del 2010 del informe sobre el uso de las TIC en los hospitales españoles, no indica expresamente el grado de implantación de estos sistemas, si muestra un mayor grado de implantación de la historia clínica electrónica con respecto al año 2008, lo que obviamente va ligado a una mayor utilización de sistemas PACS Aplicaciones de la imagen médica La imagen médica resulta también de gran importancia en el ámbito investigador. Como se verá más adelante en esta sección, puede desempeñar un papel funda- 2

23 1.1 Aplicaciones de la imagen médica mental en los ensayos clínicos, como medio de confirmación de hallazgos clínicos. Por lo tanto, una correcta gestión de la imagen médica en los ensayos clínicos, puede resultar tan beneficiosa como en el ámbito asistencial. Se podría pensar a priori, en aplicar de manera directa las soluciones, herramientas y estándares de gestión de la imagen médica en el ámbito asistencial. Sin embargo, existen diferencias sustanciales entre ambos ámbitos que suponen grandes resistencias a esta alternativa. Obviamente, esto no significa que ninguno de los avances realizados en esta materia, sea de aplicación a los ensayos clínicos, sino todo lo contrario, muchos de los avances son de aplicación, pero requieren ser adaptados a la realidad del escenario investigador. En esta sección se dibujarán algunos de los aspectos diferenciadores más destacables en los que se diferencian ambos ámbitos, pero para comprender mejor estas diferencias, conviene repasar brevemente el concepto de imagen médica. Por imagen médica se entiende el conjunto de técnicas y procesos que son usados para obtener representaciones gráficas del cuerpo humano. Algunas de las técnicas actualmente en uso son[9]: Radiología, Tomografía, Resonancia Magnética, Fluoroscopía, Ultrasonidos. La imagen médica es usada principalmente en el ámbito asistencial como medio de diagnóstico no invasivo 3. Los pacientes, en el ámbito asistencial, acuden a los hospitales y centros sanitarios, por un problema de salud que precisa ser diagnosticado. El paciente es atendido en sucesivas visitas en las que se le pueden solicitar pruebas de imagen que confirmen 3 Salvo en el caso de las pruebas que requieren contraste, en las que obviamente es preciso inyectar al paciente un radiofármaco o en otras pruebas en las que es preciso introducir al paciente la cámara o sensor, por ejemplo gastroscópias o ecografías vaginales. 3

24 Capítulo 1 una sospecha diagnóstica. En este escenario, la gestión de estas imágenes está totalmente centrada en los eventos asistenciales o procesos de salud del paciente. Como ya se ha mencionado con anterioridad, los sistemas PACS son los encargados de gestionar el almacenamiento y flujo de trabajo de las imágenes que se adquieren en los hospitales y centros sanitarios. Obviamente el paciente es el eje central de la organización de la información en los sistemas PACS, y entorno a él se estructuran los episodios del paciente, los estudios que se realizan por cada uno de estos episodios, las series que se adquieren para cada estudio y por último las imágenes que componen cada serie. Los sistemas PACS, están integrados con otros sistemas sanitarios de ámbito asistencial, con el fin de conformar la historia clínica del paciente y coordinar la asistencia sanitaria del mismo. Imagen médica como medio de obtención de biomarcadores De manera muy básica, un ensayo clínico es un estudio mediante el cual se pretende determinar si un nuevo tratamiento, un nuevo medicamento, un nuevo algoritmo de análisis o un nuevo dispositivo contribuirá a prevenir, detectar o tratar una enfermedad. En algunos ensayos clínicos es muy común recurrir a biomarcadores que permitan guiar la evolución del ensayo o medir la eficacia del tratamiento aplicado o del fármaco sobre el que se realiza el estudio. Concretando con una definición más precisa, un biomarcador es cualquier característica que puede ser medida y evaluada de manera objetiva como indicador de un proceso biológico, patógeno o como respuesta farmacológica a una intervención terapéutica [10]. Existen varios tipos de biomarcadores, por ejemplo, aquellos que dan prueba de un mecanismo, los que dan prueba de un principio y los más importantes para un ensayo clínico, los que dan prueba de eficacia[11]. Estos últimos, pueden tener consideración de hallazgos clínicos, con la ventaja de se precisa menos tiempo para ser detectados o identificados, Así pues, la importancia de la aplicación de un biomarcador en un ensayo clínico, reside en que permite reducir en gran 4

25 1.1 Aplicaciones de la imagen médica medida, el tiempo necesario para la realización del mismo[12]. Al igual que la imagen médica resulta de gran utilidad en el ámbito asistencial, como medio diagnóstico no invasivo, la importancia de la aplicación de la imagen médica en el ámbito investigador, reside en su utilización como medio de obtención de biomarcadores no invasivo. La imagen médica puede ser utilizada en los ensayos clínicos de tres modos diferentes[13]: Como medio de detección, Como medio de caracterización, y Como medio de monitorización y/o evaluación. Procesamiento y tratamiento de la imagen médica Por otro lado, otro factor diferenciador entre ambos ámbitos, radica en que la gestión de la imagen médica en los ensayos clínicos implica en casi todos los casos etapas de procesamiento y manipulación de la imagen. Es muy común que las imágenes adquiridas en un ensayo clínico, sean pre-procesadas, normalizadas, caracterizadas, procesadas y/o post-procesadas. Además, el resultado de estas tareas, suele ser a su vez datos o imágenes que serán la entrada de procesos sucesivos, lo que hace más compleja la gestión de la imagen en los ensayos. Como se puede intuir, los flujos de trabajo para el procesamiento de las imágenes médicas, pueden llegar adquirir cierto nivel de complejidad, que debe ser gestionado adecuadamente por una herramienta informática, ya que de otra manera no es posible asegurar aspectos tan esenciales como la replicabilidad de los experimentos y/o mediciones. Algunos autores van más allá y consideran que la gestión informatizada de los ensayos clínicos debe asegurar la procedencia de todos los datos e imágenes que se utilicen y produzcan. Este concepto, denominado data provenance, implica que no solo se guarden los datos o imágenes originales que dan lugar a nuevas estructuras, sino que además se almacene información sobre los procesos aplicados, 5

26 Capítulo 1 alteraciones realizadas, o añadidos, de manera que esta información no solo sea de utilidad para poder reproducir fielmente los experimentos, sino como variables que permitan predecir la influencia que determinados parámetros de adquisición de imágenes pueden tener sobre resultados experimentales, en ensayos multicéntricos [14]. Tanto los algoritmos de procesamiento, como los resultados de los mismos, dependen de las técnicas de adquisición de las imágenes originales, lo que en algunos casos supone tener que manipular imágenes en formatos diferentes a DICOM. Por ejemplo en neuroimagen, es común recurrir a las especificaciones Nifti[15] y Analyze 4, cuando se trata de imagen fmri 5, entre otras. Por lo tanto, se puede observar que si bien DICOM es el referente a nivel mundial en gestión de imagen médica, en el ámbito investigador es preciso entender y soportar otros formatos de representación de imagen médica Factores que limitan la aplicación de la imagen médica Todos los factores comentados con anterioridad, diferencian claramente el uso de la imagen médica en los ámbitos asistencial e investigador, pero no son los únicos que afectan a la aplicación de la imagen médica en los ensayos clínicos. Existen otros factores que condicionan la manera en que se puede aplicar la imagen médica en los ensayos clínicos[13, 14]: 1. La manera de compartir y gestionar las imágenes. Un buen sistema de información es aquel que se usa. Al igual que en otros contextos, es importante considerar aspectos transversales al sistema de información, como por ejemplo el ancho de banda requerido para las comunicaciones entre sistemas, o también, las políticas de acceso a datos desde centros remotos. 4 Formato de imagen desarrollado por la Mayo Clinic. 5 functional magnetic resonance imaging 6

27 1.2 Factores que limitan la aplicación de la imagen médica A pesar de la alta implantación de dispositivos de adquisición de imágenes en los centros asistenciales, y a pesar del aumento en la capacidad de las redes de transmisión de datos, hoy en día la mayoría de las imágenes que son enviadas a los laboratorios de imagen y a los centros en los que se realizan los ensayos clínicos, todavía son enviadas en soportes físicos. Esto demuestra que los límites en usabilidad de un determinado software no solo proceden de la capacidad de procesamiento del hardware que lo ejecute. Por poner un ejemplo relativamente reciente, en el National Lung Screening Trial[16], de las exploraciones realizadas en los centros satélites, el 94 % fueron enviadas mediante discos duros externos, el 5,9 % mediante discos ópticos y tan solo el 1 % fue enviada mediante internet. Este estudio, fue realizado entre los años 2005 y 2007, momento en el que las redes de comunicación de datos hacían más que viable el envío en un tiempo razonable de este tipo de estudios. Sin embargo, suele ocurrir que las redes informáticas de los centros asistenciales están aisladas de internet, por motivos de seguridad. Solventar este tipo de restricciones suele ser tedioso y poco efectivo. 2. La estandarización de los protocolos de adquisición de la información. Antes de que el ensayo comience, es importante definir y unificar los métodos de adquisición de imágenes, para minimizar la variabilidad en las imágenes adquiridas, ya que esto puede suponer un problema en la fase de procesamiento. Esta necesidad ha sido reconocida por la ACR 6, que ha lanzado la iniciativa UPICT[17], que consiste en la definición de uniforme de protocolos de adquisición de imagen médica en ensayos clínicos, con la finalidad de aumentar la calidad en los protocolos y procedimientos de adquisición. 3. La estandarización de los métodos de revisión y evaluación de las imágenes. Al igual que en el punto anterior, los métodos de procesamiento y medición en las imágenes deben estar definidos y homogeneizados. 6 American College of Radiology 7

28 Capítulo Marco de trabajo El trabajo de investigación de esta tesis, se inició en el Laboratorio de Análisis de Imágen Médica y Biometria de la Universidad Rey Juan Carlos, en el año En una primera etapa se trabajó en la creación de una herramienta de gestión de imagen clínica, centrando los esfuerzos en el almacenamiento de imágenes en formato DICOM y en la comunicación con los hospitales. El doctorando no participó en esta primera etapa. En el año 2007 se inicia una segunda etapa en la que se desea mejorar la aplicación existente. Tras un periodo de planteamiento y estudio de la situación actual en materia de gestión de imagen clínica, se concluye un objetivo mayor, la creación de una arquitectura conforme a la descripción de la hipótesis de esta tesis. El doctorando trabaja actualmente como jefe del Servicio de Informática del Hospital General Universitario de Ciudad Real ( donde además de las labores propias de su cargo, coordina el grupo de desarrollo del proyecto regional de Sistema de Información Hospitalario. Terminó sus estudios de Ingeniería Informática en la Escuela Superior de Informática de Ciudad Real de la Universidad de Castilla - La Mancha. La presente tesis se desarrolla bajo una premisa fundamental, la utilización y producción de software libre. Todos los elementos utilizados para el desarrollo de la misma 7, están licenciados bajo alguna de las licencias conocidas como libres y por supuesto, el resultado final de la misma será publicado bajo licencia GPL Organización de la memoria La organización del resto de capítulos de esta tesis es la siguiente: Capítulo segundo: En este capítulo se analiza el estado actual de los estándares y formatos de imagen clínica, propuestas de consolidación en el uso 7 Desde los sistemas operativos, software de gestión de proyecto, entornos de desarrollo, servidor de aplicaciones, bases de datos XML, bases de datos relacionales, librerías de tratamiento de imagen, procesador de textos y cualquier otro software de utilidad. 8

29 1.4 Organización de la memoria de estándares y formatos, tecnologías y soluciones de almacenamiento y gestión de imagen clínica en general, así como las experiencias previas en materia de ensayos clínicos. Capítulo tercero: En este capítulo se justifica la necesidad del presente proyecto, dado que ninguna de las alternativas presentadas en el estado del arte ofrece una solución integral y apropiada al problema que se pretende abordar. Capítulo cuarto: En este capítulo se presenta la hipotesis y los objetivos a satisfacer en este trabajo. Capítulo quinto: En este capítulo se describe la metodología utilizada en el trabajo realizado, documentando las fases del trabajo y las soluciones que se han utilizado para superar los problemas encontrados. Se describe también la especificación de la arquitectura y los modelos creados para dar soporte a la misma. Capítulo sexto: En este capítulo se presenta un análisis de los resultados obtenidos, así como un breve debate en el que poner de manifiesto qué partes de la arquitectura deberán ser mejoradas y/o trabajos futuros. Capítulo séptimo: Aquí se presentan las conclusiones del trabajo, así como una breve discusión de los aspectos más delicados. Bibliografía: Donde se incluye la bibliografía consultada en la elaboración de la tesis. Apéndices: Se incluye un manual en inglés, que fue escrito como documentación del producto obtenido y que se puede obtener en la web del proyecto. 9

30

31 2. Estado del arte El objetivo de este capítulo es presentar el estado de la gestión de la imagen médica en el ámbito investigador, mediante el análisis de los proyectos más representativos de gestión de imagen médica. En este capítulo se analizará la evolución histórica de las herramientas software para la gestión de la imagen médica en los ensayos clínicos, partiendo de las primeras propuestas que abogaban por aplicar sistemas PACS para la gestión de las imágenes en un ensayo clínico, hasta llegar a las mas recientes alternativas que soportan funcionalidades avanzadas, como la gestión de comunidades abiertas donde compartir imágenes y resultados. Se dedicará especial atención a las solución de tipo grid, puesto que este tipo de soluciones está teniendo especial relevancia en los ensayos clínicos relacionados con el cáncer PACS como modelo inicial Dado el éxito que tuvieron los sistemas PACS durante la década de los 90, con una implantación masiva en los hospitales más importantes, y los importantes avances que en materia de hardware y capacidad de transmisión de información por Internet, tuvieron lugar en los primeros años de la década del 2000, aparecieron varias propuestas [1, 18, 19] de gestión de ensayos clínicos, en las que se intentaba acomodar el concepto de PACS al ámbito de investigación. Sanjay et al. [19] describió el flujo de trabajo de un laboratorio de análisis de imagen médica, planteando un símil con un departamento centralizado de radiología. En 11

32 Capítulo 2 este escenario, las diferentes modalidades de adquisición del hospital (o incluso de centros adjuntos) envían las imágenes al PACS y posteriormente, los radiólogos informan dichas imágenes desde las estaciones de trabajo. De manera similar, los investigadores de un laboratorio de análisis pueden actuar de manera similar a los radiólogos, con la diferencia de que las modalidades de adquisición pueden estar repartidas por cualquier lugar del mundo. Según el autor, la aplicación de los sistemas PACS en el ámbito investigador, permitiría solucionar varios problemas: Estandarización de las herramientas de tratamiento y visualización de imagen. Normalización del flujo de trabajo en el ensayo clínico. Abaratamiento de los costes y reducción del tiempo necesario. Sin embargo, este escenario presenta algunas carencias en su especificación, ya que no contempla aspectos como seguridad en las transacciones por internet, políticas de acceso a datos, escalabilidad de la arquitectura y otros problemas comunes a la gestión TIC. Algunos de estos aspectos si son contemplados por Huang et al. [1], quien propuso una arquitectura mejorada en la que el PACS centralizado está mejorado con un grid que confiere escalabilidad a la arquitectura, así como que los centros participantes puedan acceder al PACS también, tal y como se puede apreciar en la figura 2.1. En este trabajo se destaca la importancia de definir rigurosamente el protocolo del ensayo clínico, la necesidad de la implantación de controles de calidad de la imagen, o la importancia de disponer de un sistema de backup que permita asegurar la durabilidad de la información Inconvenientes de los sistemas basados en PACS Como ya se ha visto, la principal ventaja de la aplicación de un sistema PACS centralizado es la simplificación de las operaciones de adquisición de imágenes mediante las operaciones estandarizadas de query/retrieve, descritas en el estándar DICOM. 12

33 2.1 PACS como modelo inicial Figura 2.1.: Arquitectura basada en PACS mejorada con un grid. Reproducción sobre imagen original de [1]. Sin embargo, en las propuestas anteriores se ignoran algunos aspectos fundamentales, que son característicos del escenario que describen. Si bien los sistemas PACS suponen una plataforma que unifica los criterios de compartición y gestión de las imágenes, en estos ensayos, existen varios centros que actúan como emisores de imágenes y al menos un laboratorio de referencia en el que se reciben, almacenan y procesan las imágenes. Así pues, existen dos factores muy importantes: El ancho de banda requerido para comunicar cada centro emisor con el laboratorio de referencia. Las políticas de gestión de sistemas de información y de protección de las redes corporativas. En estos casos, se requiere un ancho de banda mínimo para que los envíos de imágenes sean efectivos y se da la circunstancia de que no siempre es factible disponer de la tecnología necesaria entre todos los centros emisores y el laboratorio de referencia. Además, no se tienen en cuenta las restricciones de seguridad que se tendrían que 13

34 Capítulo 2 satisfacer, pues un mismo PACS tendría que ser dado de alta como destinatario de operaciones de C-GET o C-MOVE. Esto podría ser especialmente complicado de satisfacer en un entorno como el sistema sanitario español, en el que un laboratorio de análisis de imagen situado en Madrid, pudiera recibir imágenes de centros de diferentes comunidades autónomas, donde cada una dispone de diferentes políticas de acceso a la información, diferentes tecnologías, entre otros problemas. Otro inconveniente importante, derivado del uso de los sistemas PACS, reside en las posibles colisiones que se podrían originar con los identificadores de pacientes, episodios y series de imágenes. Obviamente, al tratarse de diferentes centros no se puede asegurar que alguno de estos identificadores esté repetido. Por otro lado, también puede ocurrir que un mismo paciente tenga diferentes identificadores en varios centros. Por último, los sistemas PACS están vinculados al estándar DICOM de manera que no es posible incluir imágenes en otros estándares de imagen médica. Esto está relacionado con el hecho de que los sistemas PACS no disponen de las abstracciones necesarias para dar soporte al proceso de investigación, por lo tanto no contemplan la posibilidad de adjuntar a un estudio las imágenes y/o datos resultantes del post-procesado de un conjunto de imágenes anatómicas. Si bien el estándar DICOM soporta secondary capture como en [20, 21], este mecanismo no permite registrar ciertos resultados de post-procesado, que no se obtienen en formato DICOM. Los principales inconvenientes para registrar estos resultados en un PACS son: Es un mecanismo dependiente del estándar DICOM. Esto implica que no es posible gestionar otros formatos de imagen, que pueden ser importantes en determinados ámbitos, por ejemplo, en neuroimagen es común utilizar los formatos especializados Nifti y Analyze. El modelo de datos está centrado en el paciente. En el ámbito investigador lo importante no es el paciente si no el grupo y la imagen, que es utilizada como entrada a diferentes cadenas de procesamiento. Los sistemas PACS carecen de flujos de trabajo apropiados. Los sistemas PACS no ofrecen gestión de flujos de trabajo, ni permiten gestionar tareas y/o 14

35 2.1 PACS como modelo inicial resultados de procesamiento. Están especializados en el almacenamiento de imágenes. De entre todas las propuestas basadas en esta idea, las más relevantes han sido: a) MIRC, el Medical Image Resource Center, b) el perfil Teaching Files and Clinical Trial Export (TCE) del framework técnico de IHE para Radiología, y c) MIDAS. A continuación, se analizarán en detalle cada una de ellas MIRC El Medical Image Resource Center[22], es un servidor de ficheros electrónicos para la enseñanza o ETF 1 de sus siglas en inglés, desarrollado por el comité de radiología informática de la RSNA 2. Los ficheros electrónicos para la enseñanza, son la evolución de las placas físicas que se utilizaban con fines didácticos en radiología. Estas placas solían ser de pruebas obtenidas a pacientes reales, que posteriormente eran utilizadas para enseñar a otros radiólogos o estudiantes. Las placas se acompañaban de información clínica relevante y sea agrupaban en librerías, de modo que estaban disponibles para su consulta. Normalmente, cuando estas librerías alcanzaban cierta dimensión resultaban complicadas de mantener y actualizar. Con la aparición de imagen clínica digital, la RSNA inicia el proyecto MIRC, definiendo los ETF como la alternativa electrónica a las placas físicas y los informes que las acompañaban. Así pues, MIRC nace con el propósito de construir una librería de documentación clínica accesible desde internet, utilizando como estructura básicas de almacenamiento los ficheros de enseñanza electrónicos, aunque en la actualidad, MIRC soporta prácticamente cualquier tipo de información digital, incluyendo documentos, presentaciones, bases de datos, resultados de procesamiento de imágenes, e incluso información obtenida de ensayos clínicos. 1 Electronic Teaching Files 2 Radiological Society of North America, 15

36 Capítulo 2 Figura 2.2.: Pantalla de consulta de un ETF en MIRC. Para lograr esta finalidad, se recurre a la idea de sistema PACS, si bien los responsables del desarrollo de MIRC tiene claro que los sistemas PACS no tienen potencial para soportar aplicaciones no clínicas, y que es necesario añadir al concepto nuevas funcionalidades. Las más destacables fueron: 1. Utilización de esquemas XML para la representación de la información. De esta manera se hace posible la construcción de búsquedas avanzadas sobre el conjunto de datos almacenado, sin que tenga que existir de manera prefijada un único modelo descriptivo de la estructura de los datos a representar. 2. Interfaz web pública. De esta manera se facilita la consulta y exploración del contenido de la librería de aprendizaje. Aunque el objetivo principal de esta herramienta no era soportar la gestión de la imagen médica en los ensayos clínicos, actualmente, MIRC incluye dos extensiones relacionadas con este ámbito. Por un lado, dispone de un servicio de 16

37 2.1 PACS como modelo inicial almacenamiento especializado para ensayos clínicos 3 y por otro lado, dispone de medios facilitadores para importar información relevante de los resultados obtenidos en los ensayos[23] MIRC en ensayos clínicos Los servicios de almacenamiento de MIRC para ensayos clínicos permiten conectar dispositivos de adquisición de imágenes con centros o laboratorios en los que se realizan tareas de procesamiento de imágenes. La figura 2.3, muestra el diagrama básico de la organización del servicio de almacenamiento de MIRC para ensayos clínicos, en el que se puede ver como las diferentes modalidades de cada organización, acceden servidor MIRC a través del protocolo seguro HTTPS, que se ejecuta en el puerto Figura 2.3.: Esquema del servicio de almacenamiento MIRC. Obtenida de mircwiki.rsna.org En estos centros se instala un servicio MIRC que implementa diferentes interfaces de comunicación: 1. DICOM Import Service. Este servicio permite recibir imágenes de diferentes modalidades, estaciones de trabajo y/o PACS a través del protocolo DICOM. Este servicio implementa la clase de servicio DICOM Storage como proveedor Administrator s_manual 4 DICOM C-STORE SCP (Service Class Provider). 17

38 Capítulo 2 2. HTTP Import Service. Este servicio permite recibir imágenes DICOM o cualquier otro tipo de información a través del protocolo HTTP. 3. DICOM Export Service. Este servicio permite enviar imágenes a estaciones de trabajo y/o PACS a través del protocolo DICOM. Este servicio implementa la clase de servicio DICOM Storage como cliente HTTP Export Service. Este servicio permite enviar contenidos, incluyendo imágenes DICOM a través del protocolo HTTP. 5. Database Export Service. Este servicio permite exportar a una base de datos externa cualquier tipo de información almacenada, incluido imágenes DICOM. Las imágenes DICOM que se reciben en el ensayo clínico, son transformadas a objetos MIRC (o lo que es lo mismo a formato ETF) por un procesador de objetos que se basa en una plantilla, que debe ser definida para cada ensayo, para extraer y clasificar la información de interés. Sin embargo, este procesador siempre agrupa la información por el UID 6 del estudio al que pertenecen las imágenes Inclusión de imágenes en MIRC Aunque MIRC está basado en el uso de DICOM y la extensión de PACS, permite subir imágenes en formatos genéricos como jpeg. MIRC dispone de un almacenamiento temporal de imágenes, denominado Personal Cabinet que es lugar donde se almacenan las imágenes antes de que estas sean vinculadas a algún ETF y/o documento. El archivo personal de imágenes, permite una gestión básica de las mismas, de manera que estas pueden ser renombradas, eliminadas, compartidas, exportadas, en definitiva manipuladas convenientemente. 5 DICOM C-STORE SCU (Service Class User). 6 Universal Identifier 18

39 2.1 PACS como modelo inicial Perfil TCE de IHE IHE[24] es una iniciativa independiente, promovida por profesionales de la salud y empresas del sector tecnológico del ámbito sanitario. La finalidad de IHE es mejorar y facilitar el intercambio de información entre sistemas de información sanitarios. Si bien los estándares de informática sanitaria son una herramienta que permite crear entornos de interoperabilidad, sucede que en muchas ocasiones estos estándares conllevan un alto grado de ambigüedad en su aplicación. Para solventar este problema, surgió la iniciativa IHE, que fundamentalmente se dedica a desarrollar marcos de especificaciones técnicas. Estos marcos técnicos se centran en áreas de aplicación específica. Por ejemplo, el marco técnico de radiología, en el que se modela el flujo de trabajo de un servicio de radiología. Dentro de los marcos técnicos, IHE especifica de manera detallada cómo deben ser aplicados los diferentes estándares de informática sanitaria, eliminando la ambigüedad implícita en los estándares utilizados. Dentro de un marco técnico, IHE define perfiles de integración. Los perfiles de integración, describen escenarios reales de integración de sistemas. Siguiendo con el ejemplo del marco técnico de radiología, algunos de los perfiles de integración, que se pueden ver en la figura 2.4, son: SWF, Scheduled Workflow. PIR, Patient Information Reconciliation. KIN, Key Image Note. El perfil Scheduled Workflow define los procesos que dan continuidad e integridad a un servicio de radiología. En este perfil, como en todos los demás, se definen actores y transacciones. Los actores que se definen en este perfil de integración, representan los roles que los diferentes sistemas de información, cumplen para implementar los procesos que se describen en el escenario. Un servicio de radiología, debe atender solicitudes de realización de pruebas radiológicas a pacientes. Se espera de este servicio, que obtenga, como respuesta 19

40 Capítulo 2 Figura 2.4.: Diagrama de perfiles de integración del marco técnico IHE para radiología. Obtenida del volumen 1 del marco técnico de radiología de IHE. 20

41 2.1 PACS como modelo inicial a dichas solicitudes, uno o varios estudios radiológicos, compuestos de diferentes series de imágenes, así como un informe del estudio. Así pues, IHE identifica una serie de actores, como por ejemplo: Order Placer, que representa al sistema de información que realiza solicitud de una prueba radiológica. Image Archive, que representa al sistema encargado del almacenamiento y clasificación de las imágenes capturadas en el servicio de radiología. Acquisition Modality, que representa a los diferentes dispositivos de adquisición de imágenes del servicio de radiología. Conviene aclarar que un actor no tiene porque coincidir con un sistema de información. De hecho, los actores solo representan una determinada responsabilidad. En la práctica, un mismo sistema de información puede implementar las responsabilidades de más de un actor. IHE especifica la comunicación entre actores mediante transacciones. Es en estas transacciones donde se limita y especifica de manera precisa e inequívoca, el uso de los diferentes estándares de comunicaciones aplicados al ámbito sanitario. Así pues, es en las transacciones donde está el verdadero valor de IHE. Para terminar con el ejemplo del servicio de radiología, algunas de las transacciones que se definen en este marco técnico son: RAD-2, Placer Order Management, que representa la transacción que emite el actor Order Placer para solicitar al servicio de radiología una prueba para un paciente. RAD-10, Storage Commitment, que representa la transacción que emite el actor Acquisition Modality para enviar al actor Image Archive una o varias imágenes adquiridas para un paciente Perfil TCE Dentro del marco técnico dedicado a la radiología[24], el perfil número 17 está dedicado a la generación de ETF y exportación para ensayos clínicos. Este marco se 21

42 Capítulo 2 denomina TCE 7 y describe las funcionalidades de selección de imágenes, series y/o estudios, incluyendo notas clave, informes, documentos de evidencia y estados de presentación, que necesitan ser exportados a alguna librería de ETF o a algún ensayo clínico. Figura 2.5.: Diagrama de actores del perfil TCE. Obtenida del volumen 1 del marco técnico de radiología de IHE. La figura 2.5, muestra los actores que intervienen en el perfil así como las transacciones necesarias para implementar la funcionalidad del perfil. El soporte que este perfil da a los ensayos clínicos, se limita a definir cómo deben ser exportadas tanto las imágenes como la información complementaria a ellas. También incluye la funcionalidad de exportar datos a ensayos clínicos multicéntricos. La especificación de IHE define un caso de uso para ejemplificar las funcionalidades que ofrece en referencia a los ensayos clínicos. En este caso de uso, un 7 Acrónimo de Teaching Files and Clinical Trial Export 22

43 2.1 PACS como modelo inicial paciente, que está siendo atendido en algún centro sanitario, desea participar en un ensayo en el que participa el centro. El paciente, que ya ha autorizado convenientemente su participación mediante la firma del consentimiento informado, autoriza el envío de las pruebas pertinentes al centro de referencia y/o laboratorio de imagen. Utilizando una estación de trabajo del centro, bien el médico, enfermero o técnico autorizado, exporta las pruebas e imágenes de interés, o bien captura nuevas imágenes que son remitidas al centro de referencia. En este caso de uso, las funciones de los actores definidos en el perfil TCE de IHE, son: 1. El actor Export Selector permite por un lado, la selección de imágenes, series y estudios de interés y por otro lado, la selección del ensayo clínico de destino, al que se remitirán las imágenes seleccionadas. Este actor, puede estar integrado con una modalidad de adquisición o con una estación de trabajo, lo cual facilita las tareas de visualización de imágenes y captura de las mismas. 2. El actor Export Manager procesa la solicitud de envío generada por el Export Selector y realiza la anonimización de los datos a exportar. Este actor debe permitir la opción de reasociar la información personal del paciente correcto a todas aquellas imágenes anonimizadas. Este acto, puede agruparse con un Image Manager/Archive, lo que al igual que en el anterior caso, simplifica el diseño del mismo. 3. El actor Receiver será el destino del envío de las pruebas procesadas por el actor Export Manager. Típicamente, este actor estará integrado con el sistema de gestión del ensayo clínico. Por lo tanto, este perfil está dedicado en exclusiva a resolver el problema de la comunicación de datos desde los centros de adquisición de imágenes a otros destinos diferentes a los ya previstos en el marco técnico de radiología, como por ejemplo un laboratorio de imagen médica. Como se verá más adelante, otras propuestas recurren a esta solución para abordar esta necesidad. 23

44 Capítulo MIDAS MIDAS[25] es otro ejemplo de sistema para el almacenamiento y gestión de grandes colecciones de datos científicos multimedia. MIDAS es desarrollado por Kitware, Inc. y está disponible bajo licencia Open Source. MIDAS es un sistema web para el almacenamiento digital de grandes repositorios de datos multimedia, especialmente optimizado para los ámbitos médico y científico, que utiliza estándares abiertos para facilitar la interoperabilidad con otros sistemas de información, así como dispositivos de captura y estaciones de trabajo. MIDAS dispone de herramientas de gestión de los repositorios de datos, un motor de búsqueda y un visor de imágenes on-line. A diferencia de los sistemas mencionados con anterioridad, MIDAS posee la capacidad de trabajar con otros formatos específicos de representación de imagen médica, por ejemplo con modelos tridimensionales de representación de imagen. Además, no está limitado solo al almacenamiento y gestión de imágenes, sino que permite la gestión también de otros medios digitales, como notas clínicas. Figura 2.6.: Instalación MIDAS de la Optical Society of America. 24

45 2.1 PACS como modelo inicial En cuanto a las opciones de interoperabilidad, no solo soporta los servicios típicos del estándar DICOM, sino que además implementa interfaces de comunicación REST[26], protocolos de transferencia de ficheros como FTP y/o SCP. También dispone de un API de programación en C++ que lo hace extensible. Al igual que en el caso del perfil TCE y MIRC, MIDAS presta atención a la anonimización de datos de pacientes, aunque permite ir más allá que las anteriores propuestas. MIDAS presenta un proceso de inclusión de imágenes en el que se aplica un sistema de filtros. De esta manera, es posible aplicar determinadas operaciones de manera automática a las imágenes y/o pruebas que son remitidas al servidor, como por ejemplo las operaciones de anonimización de imágenes que son ejecutadas por el filtro correspondiente. Otro filtro importante, es el encargado de extraer metadatos de las cabeceras DICOM de los archivos remitidos y su posterior registro, de manera que esta información pueda ser explotada de alguna manera. MIDAS también soporta los servicios de transferencia DICOM, como en el caso de MIRC y el perfil TCE. Por lo tanto es posible recibir imágenes de una estación de trabajo o enviar a un PACS resultados Soporte a algoritmos de tratamiento Una característica diferenciadora de MIDAS, es que dispone de una interfaz de programación en C++ y de un sistema de ficheros público, en el que es posible incluir algoritmos de tratamiento de imágenes. Para dar un mejor soporte a está funcionalidad, MIDAS dispone de una API que es accesible desde C++ y que simplifica el desarrollo de estos algoritmos, sobre todo para las operaciones relacionadas con el tratamiento de las colecciones de imágenes que gestiona MIDAS. Además, MIDAS publica también una interfaz REST, que permite integrar esta aplicación con otras, de manera que se pueden automatizar determinadas tareas, como por ejemplo la recuperación de colecciones de imágenes, la inclusión de nuevas imágenes a una colección existente o el procesamiento en remoto. 25

46 Capítulo Escenarios de uso de MIDAS MIDAS es utilizado en diferentes universidades y sociedades. Una de las más representativas es la Optical Society of America. La figura 2.6, muestra la pantalla principal de acceso a las distintas colecciones gestionadas en esta sociedad. Las colecciones que la OSA tiene publicadas en su sistema, están a disposición del público y además son utilizadas por la propia sociedad para la creación de conjuntos de visualización tridimensional. En este escenario, se hace uso intensivo de las capacidades de almacenamiento y visualización de los datos gestionados Modelos grid La tecnología grid representa una evolución en la infraestructura informática necesaria para dar soporte y habilitar la colaboración de personas y recursos a través de computación de alta capacidad y sistemas de gestión de datos [27]. Esta tecnología, representa una alternativa económica de supercomputación, basada en la coordinación de recursos informáticos distribuidos entre una o varias organizaciones. La reciente popularidad de esta tecnología se debe fundamentalmente a su bajo coste frente a otras alternativas, ya que debido al carácter distribuido de la misma, diferentes organizaciones pueden colaborar construyendo una infraestructura de cómputo con mayor capacidad de la que pueden disponer individualmente [28]. Esta tecnología, heredera de los sistemas distribuidos, está siendo utilizada en proyectos de investigación, en los que diferentes universidades, laboratorios y centros colaboran en la consecución de los diferentes estudios utilizando para un grid que construyen entre todos. Por ejemplo, es utilizada en proyectos de física, meteorología, astronomía, genética, entre otros. Una de las propuestas pioneras en la aplicación de esta tecnología a los ensayos clínicos basados en imagen médica, ha sido el sistema DGIS 8 [2]. 8 DICOM Grid Interface Service. 26

47 2.2 Modelos grid Figura 2.7.: Arquitectura DGIS. Imagen obtenida de [2]. DGIS, supone un avance más en la aplicación de un grid sobre la idea central de un sistema PACS. Como se ha explicado en el apartado anterior, el principal problema de la aplicación de un sistema PACS al ámbito investigador, radica en que estos, son sistemas monolíticos que no están diseñados para soportar un flujo de comunicaciones diferente al asistencial. En un ensayo clínico es preciso disponer de un sistema que provea una manera flexible de comunicar a los participantes del ensayo. DGIS fue diseñado para solucionar dos grandes inconvenientes: Seguridad en el acceso y transporte de las imágenes. En los ensayos multicéntricos, es habitual recurrir a Internet como medio de comunicación entre los diferentes centros y el laboratorio de análisis de imagen médica. Esto implica que es preciso proteger las comunicaciones y garantizar un sistema de autenticación de usuarios adecuado. Ninguna de las dos funcionalidades son provistas por los sistemas PACS ni por la especificación DICOM. Implementar un método estándar de acceso y recuperación de imágenes. Es preciso que las imágenes sean identificadas de manera unívoca, independientemente del centro de procedencia de las mismas, así como disponer de mecanismos que permitan la búsqueda distribuida de imágenes en un sistema grid. 27

48 Capítulo 2 Si bien es posible desarrollar un recubrimiento sobre un sistema PACS para utilizar conexiones seguras o utilizar redes privadas virtuales, los autores de DGIS apostaron por la utilización de la tecnología grid, como se puede observar en figura 2.7 DGIS es por lo tanto una extensión a la especificación PACS que enlaza diferentes PACS institucionales con un grid de almacenamiento de datos de imagen médica según las recomendaciones de la OGSA 9. DGIS oferta mediante la infraestructura Grid, los servicios DICOM de verificación, almacenamiento y consulta y recuperación de imágenes 10. En la actualidad, existen numerosas plataformas de gestión basadas en grid, como por ejemplo: IXI, es un sistema grid, inicialmente desarrollado por el Imaging Sciences Centre del Imperial College London[29], y actualmente en explotación por la empresa IXICO Ltd. 11. Este software ha sido creado para el análisis de imágenes médicas, mediante el uso de colecciones de recursos de computación, de diferentes organizaciones que comparten un mismo fin, mejorando tanto la velocidad de cómputo, así como la complejidad de los algoritmos que pueden ser usados en el tratamiento de la imagen. IXI no solo define un grid de cómputo, sino también cómo gestionar el almacenamiento de las imágenes en el propio grid. SAS, es un sistema Grid desarrollado por el Center for Advanced Analytics and Business Intelligence y el High Performance Computing Center ambos pertenecientes a la Texas Tech University y en colaboración con el SAS Institute[30]. IBM Stentor, es una alternativa de IBM para la gestión de ensayos clínicos multi-céntricos basados en imagen médica. Este producto soporta las funciones del laboratorio de gestión, en donde se deben almacenar las imágenes capturadas en diferentes centros, aplicarles un sistema de control de calidad, procesarlas y conformar el circuito de trabajo. 9 The Open Grid Services Architecture O también conocidas como Verification Service Class, Storage Service Class y Query/Retrieve Service Class

49 2.2 Modelos grid Hay tres propuestas que destacan por encima de las demás. La mayoría de las soluciones encontradas están relacionadas con empresas que comercializan el servicio de explotación de la herramienta, de manera que la información existente es escasa y de ámbito comercial. Es posible que las razones para no compartir esta información estén fundamentadas en la protección del copyright. Las tres propuestas más populares y utilizadas, son tres proyectos de Software Libre. Seguramente, esta circunstancia no es una casualidad. Estos proyectos son: cagrid, BIRN y LONI Pipeline. A continuación se detallará en profundidad sobre cada uno de ellos cabig El estudio del cáncer es un área que se ha vuelto muy compleja debido a la aplicación de la imagen médica. La gran cantidad de datos que se adquieren en un estudio y los numerosos resultados obtenidos tras el procesamiento de los mismos, suponen un reto a la hora de su gestión. Además, ocurre que la colaboración entre diferentes instituciones es fundamental en el estudio del cáncer, lo que supone un mayor grado de complejidad en la gestión de los datos [31]. Por estas razones el National Cancer Institute de Estados Unidos, propuso la creación de una federación de sistemas de información interoperables, en los que cada grupo de sistemas debe encargase de realizar determinadas tareas especializadas. Como resultado, nació cabig. El proyecto cabig es por lo tanto una alternativa distribuida para la colaboración en los proyectos de investigación relacionados con el cáncer. A diferencia de otras alternativas, como MIRC o el perfil TCE de IHE, que implementan soluciones centralizadas, cabig tiene la ventaja de ser una herramienta más resiliente, pues puede ser extendida con mayor facilidad y presenta mayor tolerancia a fallos. En el corazón de cabig reside cagrid, que es el framework, orientado al servicio, que soporta todas las funcionalidades grid que permiten la naturaleza distribuida de este proyecto. Básicamente, este framework da soporte a las funcionalidades de: publicación, descubrimiento e invocación de datos y servicios [32]. 29

50 Capítulo 2 El proyecto cabig, se caracteriza por la utilización de ontologías que permiten la integración semántica entre diferentes instituciones y la independencia de sistemas operativos y redes, ya que está orientada al servicio y cada participante puede implementar estos servicios de manera diferente. cabig se divide en cuatro áreas: Clinical Trial Management. Integrative Cancer Research. In vivo Imaging. Tissue Banks and Pathology Tools. cabig también se diferencia de otras alternativas en que, si bien hace uso del estándar DICOM, no está acoplado o limitado al mismo, como por ejemplo las soluciones ya comentadas, MIRC o el perfil TCE de IHE. cabig permite la utilización de DICOM, mediante servicios específicos de integración que permiten su uso. Un ejemplo de uso de DICOM es el soporte a los Clinical Trial Processors que permiten la integración con el componente de cabig NBIA, que se verá a continuación National Biomedical Imaging Archive El National Biomedical Imaging Archive (NBIA) es una parte importante de cabig, cuya finalidad es muy similar a la perseguida por los MIRC y los teaching files. Este componente es un servicio abierto que permite a los usuarios almacenar de manera segura las imágenes de sus estudios. Este componente permite también la búsqueda y descarga de todas las imágenes médicas almacenadas, ya que permite la anonimización de las mismas, mediante la utilización de los Clinical Trial Processor definidos por la Radiological Society of North America [33]. NBIA se integra con otros componentes de cabig lo que le permite integrar otros datos como anotaciones, datos clínicos y genómicos, entre otros. También se puede federar con otras instancias de si misma, haciendo posible uno de los objetivos más destacables de este subproyecto, la posibilidad de hacer una explotación y data-mining por toda la comunidad científica. 30

51 2.2 Modelos grid Automatización del análisis de la imagen médica Otro de los hitos más destacables, desde el punto de vista del ámbito investigador, es que cabig supone un avance importante en la automatización de tareas o creación de cadenas de procesamiento de datos. El proyecto XIP [34], es un sobproyecto de cabig alineado con los objetivos del DICOM WG-23 Application Hosting Standard, cuya finalidad es la de facilitar la creación de plugins de procesamiento o entornos RAD 12 que hagan posible la definición de pipelines de análisis de imagen y datos. XIP permite obtener un mayor rendimiento en la utilización y detección de biomarcadores, así como la rápida creación de prototipos avanzados de tratamiento de imágenes y la reutilización de soluciones y rutinas previamente definidas en otras cadenas de procesamiento o pipelines BIRN La red BIRN, de sus siglas en inglés Biomedical Informatics Research Network, es una comunidad virtual, financiada por el National Institutes of Health, que gestiona recursos propios y compartidos para proveer servicio de almacenamiento, recuperación, análisis y documentación de imagen y datos biomédicos[3]. La red BIRN es coordinada por el BIRN Coordinating Center, o BIRN-CC, que ejecuta las funciones comunes de gestión, definición, integración, empaquetado, y otras funciones relacionadas. para dar soporte a los bancos de prueba que participan de este proyecto, que son: Function BIRN, cuyo objeto de estudio es la enfermedad de la esquizofrenia, así como el estudio de nuevos tratamientos. Morphometry BIRN, que estudia la neuroanatomía de enfermedades neuropsiquiátricas. Mouse BIRN, que estudia modelos animales a diferentes escalas de enfermedades neurológicas que afectan a seres humanos. 12 Acrónimo de Rapid Application Development. 31

52 Capítulo 2 Cada banco de pruebas, se ejecuta de manera independiente a los demás, y en cada uno de ellos colaboran investigadores de diferentes centros. Toda la gestión correspondiente al procesamiento e interpretación de los datos, es propia de cada proyecto y no es gestionada por BIRN-CC. Sin embargo, tanto las imágenes y datos originales, como los resultados parciales y finales del procesamiento de las mismas, están a disposición de los participantes de la red. Esta agregación de imágenes y datos, ofrece nuevas oportunidades a los investigadores, al mismo tiempo que les permite tener el control sobre los procesos que se efectúan sobre sus datos de campo. En la siguiente sección se examinará la infraestructura y la gestión de esta red Infraestructura de BIRN A grandes rasgos, la infraestructura de esta red de investigación, consiste en una red propia que se despliega de manera distribuida entre los distintos centros participantes de la red. Esta red propia es la que soporta las funciones de comunicación y almacenamiento, ambas de manera federada. Todos los servicios concernientes a estas funcionalidades son gestionados por el BIRN-CC. Por contra, los servicios de análisis de imagen y datos biomédicos son realizados con infraestructura propia de cada centro participante, aunque utilicen el middleware de BIRN para la construcción de grids capaces de construir las cadenas de procesamiento distribuido. En la figura 2.9, se puede observar una abstracción funcional del reparto de responsabilidades que se efectúa en este proyecto. Por ejemplo, toda la gestión propia de BIRN-CC está relacionada con la gestión de usuarios y credenciales, autorización y definición de roles y la gestión de los recursos distribuidos, esto es tanto sistemas de ficheros, como bases de datos. A un nivel de abstracción menor, BIRN dispone de interfaces para la adquisición de datos de diferentes fuentes de datos, entre las que cabe destacar Human Imaging Database (HID) y XNAT. También dispone de una interfaz para exportar y/o compartir datos de manera pública, para ello dispone de XCEDE, que es un sistema basado en XML que permite exportar metadatos entre diferentes bases de datos. 32

53 2.2 Modelos grid Figura 2.8.: Infraestructura de la red BIRN. Imagen obtenida de [3]. Respecto del procesamiento de imágenes y datos, BIRN permite utilizar FIPS, FBIRN Image Processing Stream, así como LONI Pipeline, que se verá más adelante. De esta manera, es posible automatizar el procesamiento de las imágenes y datos gestionados en BIRN. Por último, BIRN también da soporte a las funciones de integración de datos y visualización. Estas funciones son muy importantes, sobre todo en el campo de la neuroimagen, ya que permiten representar grandes conjuntos de datos, normalmente obtenidos en las etapas de análisis y procesamiento, de manera integrada con el flujo de trabajo de BIRN. 33

54 Capítulo LONI El Laboratorio de neuroimagen, de la Universidad de California, Los Ángeles; lleva años desarrollando herramientas informáticas de apoyo a la investigación colaborativa, para conformar un entorno de trabajo que soporte el intercambio de ideas, datos y técnicas [35]. Para lograr este objetivo, el proyecto LONI ha desarrollado dos plataformas diferentes, una para soportar los servicios de almacenamiento de datos e imágenes, denominado LONI IDA (Image Data Archive); y otro para la construcción de cadenas de procesamiento de datos e imágenes, denominado LONI Pipeline LONI IDA LONI IDA es un sistema de almacenamiento de datos e imágenes pensado para dar soporte a ensayos clínicos en los que participan múltiples centros y que producen grandes colecciones de datos. Esta solución está basada en un repositorio centralizado en el que se presta especial atención a los siguientes aspectos[14]: Privacidad de los pacientes, asegurando el cumplimiento de las normas HI- PAA 13. Control de acceso, para evitar accesos no autorizados. Auditoría de acciones, para poder recomponer determinadas acciones. Transformación y visualización de imágenes automática, para facilitar las operaciones de visualización y exportación de datos a diferentes plataformas. En la actualidad, LONI IDA alberga más de 30 proyectos de investigación que contienen más de imágenes, que son accedidas por más de 220 usuarios. Algunos de los proyectos que usan esta aplicación son: the National Institute of Aging y the Alzeimer s disease Neuroimaging Initiative. 13 Health Insurance Portability and Accountability Act, 34

55 2.3 XNAT LONI Pipeline LONI Pipeline es un entorno de computación distribuido, que enlaza datos, herramientas y servicios de diferentes fuentes, mediante una capa externa que permite operar sobre los mismos, sin necesidad de que estos tengan que ser alterados en su origen [36]. Dicha capa intermedia, denominada capa de mediación, utiliza XML para la definición y caracterización de los recursos que permiten acceder a los datos. LONI Pipeline utiliza este lenguaje para acceder a los datos de origen, que posteriormente son procesados en los flujos de trabajo, que también se definen en XML. Este proyecto, que está pensado para el caso particular del procesamiento de datos clínicos en el ámbito neurológico, incorpora como ventaja más destacable, sobre otras alternativas genéricas, que permite guardar una traza completa de las operaciones y transformaciones aplicadas a los datos, con la finalidad de garantizar la procedencia de los datos tratados XNAT XNAT[4] es una alternativa para la gestión local de proyectos de investigación y ensayos clínicos, soportada por BIRN 15, HHMI 16, Harvard University y Washington University. Esta solución, centrada en las necesidades particulares de los laboratorios de neuroimagen, permite gestionar ensayos, datos demográficos y de imagen, análisis, experimentos y parámetros de definición de umbrales de activación, mediante el uso de esquemas XML adaptados a las necesidades de cada laboratorio de análisis[14]. XNAT está diseñado para dar soporte al flujo de trabajo que se aplica en los laboratorios de neuroimagen, contemplando las diferentes etapas de un ensayo, entre las que cabe destacar: 14 data provenance 15 Biomedical Informatics Research Network, 16 Howard Hughes Medical Institute, 35

56 Capítulo 2 Figura 2.9.: Representación funcional de XNAT. Imagen obtenida de [4]. Captura de series de imágenes. XNAT ha sido diseñado para poder capturar datos de diferentes fuentes de imágenes y metadatos, bien sea a través de DICOM pushes 17, transferencias de ficheros por HTTP o FTP, e incluso a través de medios locales, como por ejemplo discos duros portables. Control de calidad. Las imágenes y datos que se importan en XNAT, son ubicados temporalmente en un pre-archivo. Los datos almacenados en este pre-archivo pueden ser inspeccionados para certificar su validez y completitud. Una vez dado el visto bueno sobre los datos, estos son transferidos al almacenamiento principal de XNAT. Una vez que los datos residen en este almacenamiento, XNAT asegura que estos permanecerán invariables. Procesado de imágenes. Las imágenes que se incorporan al archivo, suelen ser sujeto de algoritmos de pre-procesamiento y procesamiento automatizado. XNAT posee un com- 17 Es decir, soportando la transacción C-STORE o C-MOVE del estándar DICOM. 36

57 2.3 XNAT ponente denominado ArcBuild, que es el encargado de ejecutar convenientemente los distintos algoritmos de procesamiento, así como de registrar que dichos procesos fueron llevados a cabo. Este componente permite asegurar la procedencia de los datos o data provenance. Utilización y/o visualización de los datos. XNAT permite descargar y visualizar datos de diferentes maneras. No solo dispone de visores de imágenes, sino que facilita la descarga en formatos tabulares 18 de metadatos. También permite la descarga de imágenes a una copia de trabajo local, de esta manera el investigador puede trabajar libremente con la imagen sin que esta esté sujeta al control que la somete XNAT en el almacenamiento principal Gestión del almacenamiento XNAT incluye una serie de tipos de datos abstractos, definidos en XSD 19 que son utilizados para capturar tanto la jerarquía metadatos asociados a las imágenes, así como datos específicos de los protocolos de imagen. Estos esquemas abstractos de XNAT definen entidades como proyectos, sujetos y/o experimentos. Estas definiciones abstractas permiten a los usuarios de XNAT, definir datos específicos, como por ejemplo una serie de una resonancia magnética, mediante herencia y aplicando restricciones sobre el modelo. XNAT permite definir tipos de datos sin necesidad de heredar de los datos abstractos. Posteriormente, XNAT generará un modelo relacional en base de datos, derivado de la definición de los tipos de datos comentados en el párrafo anterior. Cuando XNAT adquiere nuevos datos e imágenes, los metadatos son transformados a XML, de manera conforme a los esquemas y posteriormente persistidos en las tablas relacionales. Por otro lado, los datos binarios de las imágenes, es decir, los pixels/voxels, son almacenados en colecciones de ficheros almacenados en un sistema de ficheros. 18 Por ejemplo en formato de hoja de cálculo. 19 XML Scheme Definition. 37

58 Capítulo 2 XNAT garantiza la gestión del almacenamiento persistente de las imágenes y de los datos relacionados, asegurando que los experimentos y procesos puedan ser revisitados en el futuro, con la finalidad de corroborar los resultados y contrastar nuevas técnicas, como funcionalidades más representativas. Sin embargo, dado que XNAT recurre a tres repositorios diferentes para la gestión del almacenamiento, pueden suceder errores derivados de la falta de sincronización entre los repositorios. Por este motivo, XNAT dispone de herramientas auxiliares que se utilizan para supervisar la congruencia de los datos almacenados. Además, también se contempla el escenario de un cambio en el esquema de datos, que obliga a actualizar la estructura de datos relacional Colaboración y acceso público Aunque XNAT está pensado para la gestión de local de los laboratorios de neuroimagen, también implementa funciones de compartición de datos, a diferentes niveles. XNAT permite tanto la colaboración entre investigadores, como el acceso público a determinada información de un proyecto. Para facilitar la colaboración de otros investigadores, XNAT permite la definición de paquetes en los que se agrupan conjuntos de datos, que se pueden hacer visibles a determinados usuarios. De esta manera, es posible dar acceso a usuarios externos que tan solo podrán colaborar con los datos del paquete creado para tal fin. Respecto del acceso público, es común que una vez que los estudios han concluido, estos pongan en un espacio público los resultados e incluso parte de los datos iniciales. XNAT soporta esta funcionalidad, que obviamente requiere que se implementen rutinas de anonimización de los datos. 38

59 3. Planteamiento y justificación En el capítulo anterior se han mostrado diferentes aproximaciones a la gestión de la imagen médica en otros ámbitos diferentes al asistencial. Sin embargo, ninguna de las alternativas presentadas se adapta de manera adecuada a la problemática de la gestión de la imagen médica en los ensayos clínicos. Por un lado, los sistemas PACS y las variaciones sobre los mismos, presentan determinadas carencias cuando se desean aplicar al ámbito investigador, a destacar: Proceso de control de calidad. En un ensayo clínico resulta importante establecer un mecanismo que permita chequear la validez de las imágenes recibidas antes de ser incorporadas al ensayo. Esto cobra mayor importancia cuando en un mismo ensayo colaboran diferentes entidades, porque cada una puede aplicar criterios diferentes en la captura de imágenes. Este control permite asegurar que las imágenes del ensayo cumplen los requisitos mínimos establecidos. Almacenamiento y clasificación de las imágenes. Las imágenes de un ensayo clínico deben estar convenientemente almacenadas y clasificadas. El objetivo de esta actividad es múltiple, pero cabe destacar que lo más importante es asegurar la disponibilidad de las imágenes y la inmutabilidad de las mismas (sobre todo cuando las imágenes ya han sido procesadas y existen resultados asociados a las mismas). Los actuales sistemas PACS ya implementan esta función, pero el enfoque que poseen, centrado en la actividad asistencial, no los hace adecuados para la actividad investigadora. Gestión de tareas de procesamiento. La labor de los investigadores en un ensayo, es la de realizar procesos de cuantificación y transformación a las imágenes 39

60 Capítulo 3 del mismo. Es preciso disponer de un sistema que permita gestionar convenientemente las tareas que tiene cada investigador, así como el registro de los resultados obtenidos. Trazabilidad y replicabilidad. Estas propiedades resultan fundamentales en un ensayo clínico, ya que permiten conocer en cada momento, qué procesos ha sufrido una imagen o un conjunto de ellas y qué resultados se han obtenido del mismo, así como permitir que se puedan replicar los procesos aplicados a una imagen o conjunto de imágenes, para validar los resultados obtenidos Soporte de múltiples formatos de imagen Por otro lado, los sistemas PACS no soportan otros formatos de representación de imagen médica, como por ejemplo Nifti y Analyze, lo que supone otro serio inconveniente para su aplicación en ensayos clínicos. Otras funcionalidades, de menor importancia, que tampoco son soportadas por los sistemas PACS, pero que también deben ser consideradas para dar un soporte adecuado, son: La gestión de covariables. El soporte de otros formatos de imagen médica. La anonimización/deanonimización de imágenes Protocolo de gestión de imagen médica Por norma general, todo ensayo clínico debe disponer de un protocolo en el que se detallen las actividades que han de ser realizadas en el transcurso del mismo. Este protocolo, es definido de manera previa al comienzo del ensayo clínico y en el se recogen diferentes aspectos como: El tipo de pacientes/muestras a analizar. Los procesos a aplicar sobre las muestras. 40

61 3.3 Otras carencias Las variables a registrar en los procesos. En el caso particular de los ensayos clínicos basados en imagen médica, el protocolo debe definir al menos, las tareas propias del tratamiento de imágenes comentadas con anterioridad. Algunos autores, como Sharib y Philip[37] reconocen la necesidad de modernizar la gestión de la imagen médica en los ensayos clínicos, ya que es común que en este tipo de ensayos, el flujo de trabajo y las tareas de gestión de las imágenes, sean realizadas de manera manual. Los aspectos negativos de una gestión no automatizada y alineada con el protocolo definido para el ensayo clínico, son de una gran importancia, pues obviamente no es posible garantizar aspectos tan relevantes como el control de calidad, la replicabilidad de los experimentos o el correcto almacenamiento y clasificación de las imágenes. En los ensayos clínicos donde no se realiza una gestión informatizada de la imagen médica, es común encontrar que el conjunto de pruebas diagnósticas se encuentra disperso en colecciones de DVD s, discos magnéticos y/o memorias flash e incluso ordenadores portátiles. Esta situación no permite conocer la ubicación exacta de las imágenes ni tampoco permite asegurar la perdurabilidad e inmutabilidad necesaria en las imágenes que son utilizadas para el procesamiento y obtención de resultados Otras carencias Si bien MIDAS supone un avance importante sobre la mera adaptación de un PACS, pues contempla operaciones específicas, ajenas al ámbito asistencial, como la gestión de grandes colecciones de datos; resulta ser una plataforma enfocada a la gestión de grandes repositorios de imágenes y no da soporte al flujo de trabajo necesario para la gestión de las imágenes en el ámbito de un ensayo. Además, aunque MIDAS no se trata de una adaptación a un PACS, resulta DICOM dependiente. 41

62 Capítulo 3 Con respecto a las alternativas grid, sucede lo mismo a excepción de cabig. En este proyecto destaca el subproyecto NBIA, que como ya se ha comentado, está más enfocado a equipos individuales de investigación, desempeñando un papel similar a MIRC y/o el perfil TCE que a la presente tesis. Igualmente, este proyecto cabig está fuertemente ligado al estándar DICOM, y se centra en gran medida en el estudio del cáncer. BIRN y LONI son dos iniciativas muy similares, de hecho resultan interoperables entre si. Al igual que cabig están muy ligadas a un ámbito en concreto, que en este caso, se trata de la neuroimagen. De nuevo estos sistemas no contemplan las funcionalidades propias de un laboratorio de investigación, o contemplan aspectos muy específicos y relacionados fundamentalmente con la compartición y gestión de grandes colecciones de imágenes y/o datos Diferencias con XNAT Por contra, XNAT es un proyecto muy similar al presente trabajo. XNAT está enmarcado dentro del entorno del proyecto BIRN, de hecho, XNAT tiene desarrolladas las funciones de compartición de datos con la red BIRN. Este proyecto tiene por objeto la gestión de ensayos clínicos basados en imagen neurológica. Este proyecto es contemporáneo al trabajo de la presente tesis 1 y es destacable las similitudes que comparten en determinadas áreas, como por ejemplo la arquitectura diseñada para la herramienta informática. Si bien esta circunstancia pone de manifiesto la validez intelectual de ambos trabajos, existen diferencias significativas entre ambos proyectos, ya que mientras que el presente trabajo ha sido desarrollado solo por el autor de este trabajo, en el caso de XNAT, existe un grupo de trabajo conformado por al menos 8 personas, como se puede ver en la página del proyecto. Sin embargo, a pesar de las semejanzas en algunos puntos, los objetivos perseguidos por ambos proyectos no son idénticos y el presente proyecto está más 1 De hecho, la primera publicación de nuestro trabajo se produce en Enero de 2007, ver [38] y la primera publicación de XNAT se produce en marzo de 2007, ver [4] 42

63 3.5 Justificación del trabajo centrado en el desarrollo de una aplicación que soporte el flujo de trabajo de un laboratorio de investigación. Ambos proyectos ofrecen una máquina virtual con una instalación operativa en la que se demuestra la capacidad de cada aplicación. Una revisión somera de ambas aplicaciones mediante estas máquinas virtuales, muestra enseguida la facilidad de uso de nuestro proyecto frente a la complejidad de XNAT, derivada de la compatibilidad con la red BIRN Justificación del trabajo Por lo tanto, en el momento de iniciar este proyecto no existía ninguna solución completa y válida para la gestión de la imagen médica en el ámbito investigador y era preciso definir un nuevo concepto de sistema de gestión de imagen médica que, aprovechando todo el conocimiento disponible, como por ejemplo el de los sistemas PACS, se adaptara al flujo de trabajo real de este tipo de ensayos clínicos, entendiendo por flujo de trabajo, la automatización de un proceso de negocio, de manera total o parcial, en el que documentos, información o tareas son elementos que pasan de un participante a otro con la finalidad de completar tareas, de acuerdo a un conjunto de reglas definidas [39]. La aplicación de un software específico, permitiría también mejorar la gestión de las actividades que realizan los diferentes participantes. Identificando roles, con los que delimitar las actividades que desempeña cada participante se facilitan las tareas de autorización y auditoría, que resultan fundamentales en este ámbito. La propuesta presentada en este trabajo para la gestión de la imagen médica en los ensayos clínicos, se desarrolla conjuntamente dentro del Laboratorio de Análisis de Imagen Médica y Biometría 2 de la Universidad Rey Juan Carlos y la Fundación CIEN 3. Como ya se ha mencionado, nuestro grupo lleva trabajando varios años en esta materia con algunas propuestas previas como el modelo propuesto para la gestión 2 Laimbio 3 Fundación Centro de Investigación en Enfermedades Neurológicas, 43

64 Capítulo 3 de ensayos clínicos basados en imagen[38] y un prototipo que implementaba dicha versión del modelo. En la actualidad, el resultado del presente trabajo está siendo evaluado en la fundación CIEN. 44

65 4. Hipótesis y Objetivos 4.1. Hipótesis La hipótesis conceptual general es la siguiente: La investigación llevada a cabo en laboratorios de análisis de imagen médica requiere sistemas específicos de organización de los datos y flujos de trabajo orientados todos ellos a generar nuevos resultados que permitan evaluar nuevos biomarcadores y extraer nuevos conocimientos a partir de las imágenes. De manera más específica, esta hipótesis puede ser expresada a través de los objetivos concretos que se plantean en la siguiente sección Objetivos Las características y/o funcionalidades básicas a las que debe dar soporte esta plataforma software son: Diseñar una arquitectura de procesamiento y gestión de la imagen médica centrada en el ámbito investigador y que soporte el flujo de trabajo de un laboratorio de investigación basado en imagen médica. De este objetivo se desprenden los siguientes, relacionados con la arquitectura de la aplicación: Diseñar una arquitectura que sea independiente del formato de imagen y que pueda ser extendida con facilidad, mediante la creación de nuevos 45

66 Capítulo 4 módulos que soporten las funciones necesarias para interpretar nuevos formatos de imagen médica. Diseñar una infraestructura de almacenamiento que permita, además de las funciones básicas de persistencia, indexar las imágenes por los diferentes atributos de las cabeceras de las imágenes, para dar soporte a la implementación de búsquedas avanzadas. Diseñar los mecanismos necesarios en la gestión de la imagen médica, que permitan ejecutar un control de calidad sobre las imágenes recibidas, de manera que solo sean incluidas en el ensayo clínico aquellas que los investigadores evalúen como aptas. Diseñar un mecanismo para exportar tanto imágenes como resultados de procesamiento, que permita remitir imágenes en formato DICOM a cualquier estación de trabajo o PACS, aunque la imagen a exportar se encuentre en un formato diferente a DICOM. Esta funcionalidad permitirá compartir los resultados del ensayo con los centros colaboradores. Diseñar un flujo de trabajo que soporte la gestión de protocolos de ensayos clínicos, mediante la gestión de procesos, tareas, tipos de imágenes y resultados. Este flujo de trabajo debe contemplar los siguientes objetivos: Los investigadores principales deberán poder definir y crear tantos tipos de procesos, tipos de imágenes y protocolos como deseen. El flujo de trabajo deberá soportar la creación automática de tareas conforme a las especificaciones de los protocolos creados, según los tipos de imágenes indicados. Cada tarea estará ligada a un tipo de proceso específico. El flujo de trabajo soportará la gestión de tareas de manera individualizada para cada investigador, de manera que estos sepan en todo momento, qué tareas tienen pendientes, y puedan cerrar, reasignar, obviar tareas. El flujo de trabajo permitirá la gestión de resultados. Estos resultados estarán vinculados a las tareas y representarán el resultado de 46

67 4.2 Objetivos las tareas de procesamiento de imágenes. Los resultados podrán ser valores, documentos e incluso nuevas imágenes. La aplicación contará con las funciones típicas de gestión de usuarios, auditoría y seguridad: Gestionar los usuarios, roles y permisos de los participantes en el ensayo clínico, asegurando la trazabilidad de las acciones y la replicabilidad de los experimentos y mediciones. Permitir la consulta de auditoría de acciones realizadas por un usuario en el sistema. Facilitar e implementar funciones de copia de seguridad y restauración. Los objetivos anteriores están expresados a nivel funcional, sin embargo, a nivel técnico, se desea que la infraestructura satisfaga otros objetivos que no están directamente relacionados con el dominio de la aplicación, pero que se consideran igualmente fundamentales. Estos son: Utilizar librerías y herramientas software libre, siempre que sea posible, y en su defecto, utilizar alternativas de código abierto. Generar una arquitectura bien estructurada en la que se maximice la cohesión, se disminuya el acoplamiento y se realice un reparto de responsabilidades adecuado, para facilitar las tareas de mantenimiento y/o de colaboración de otros interesados. Implementar las funciones necesarias para garantizar la atomicidad de las operaciones y acciones que se lleven a cabo en la aplicación, a pesar de que estas puedan exceder el ámbito transaccional de la base de datos relacional. Crear la especificación de componentes de conversión entre los diferentes formatos de imagen clínica. 47

68

69 5. Material y método En este capítulo se van a tratar varios temas relacionados con el método empleado para guiar el proceso de desarrollo e investigación que se presenta en este trabajo, las herramientas utilizadas y los principios arquitectónicos así como las justificaciones de cada una de las diferentes elecciones tomadas. La presente tesis, tiene por objeto abordar el desarrollo de una aplicación para solucionar el problema de la gestión del flujo de trabajo y las imágenes médicas, en un laboratorio de análisis de imagen médica en el que se desarrollan ensayos clínicos multicéntricos. Sin embargo, a pesar de que el objeto de este trabajo es la obtención de un software, conviene destacar el hecho de que el dominio del problema relacionado no está definido, por lo tanto es preciso realizar un proceso de investigación sobre el dominio del problema, que permita delimitar los casos de uso y funcionalidades requeridas. En otras palabras, el proceso de construcción de este software es un proceso de prototipado continuo, que permita experimentar los avances que se produzcan en la investigación. Esta circunstancia tendrá un peso importante en la decisión de la metodología a aplicar para el desarrollo de la aplicación. Por otro lado, se analizará el papel que desempeña el Software Libre en este proyecto. En la construcción del mismo se ha recurrido a múltiples librerías que implementan funcionalidades específicas de tratamiento de imágenes de un determinado formato, frameworks de desarrollo, motores de persistencia y en definitiva de todo el software de terceros que ha sido necesario. Obviamente, este proyecto no habría sido posible sin las numerosas aportaciones que un gran número de personas han realizado previamente. Es por esta razón, que el doctorando desea contribuir con este pequeño esfuerzo, liberando todo el 49

70 Capítulo 5 código fuente de la aplicación con la licencia de uso GPL en su versión 3. El código fuente de este proyecto, así como diferentes tipos de documentación están a disposición de todo aquel que así lo desee en com/p/mctwp/. Por último, en este capítulo se describirán otros aspectos, relacionados con la infraestructura de sistemas y la puesta en producción de la aplicación, que han sido necesarios para poder superar determinadas barreras y ofrecer un buen servicio Metodología y gestión del proyecto Como ya se ha esbozado en la introducción del presente capítulo, el desarrollo de presente trabajo presenta diferentes problemas que deben ser abordados de una manera principalmente experimental. Dado que no existe ningún software previo que ofrezca una solución integra a la gestión de la imagen médica en el ámbito investigador, existe la necesidad de experimentar con diferentes tecnologías y librerías software para desarrollar funcionalidades que satisfagan los retos que plantea el dominio del problema. Esta circunstancia resulta fundamental, por que a diferencia de un desarrollo software en el que el dominio de aplicación es bien conocido, aquí no se pueden realizar estimaciones predictivas sobre el desarrollo de los componentes necesarios y mucho menos sobre la metodología de desarrollo software utilizar. Así pues, a continuación se hará un breve repaso, del estado del arte en materia de metodologías de desarrollo, con la intención de poder argumentar mejor la elección tomada Modelos prescriptivos Los modelos prescriptivos o comúnmente denominados, metodologías clásicas de ingeniería de software, se caracterizan porque independientemente del ciclo 50

71 5.1 Metodología y gestión del proyecto de vida que implementen, imponen la práctica de actividades predeterminadas, en las que se definen las tareas y conjuntos de acciones, así como los resultados y/o entregables de cada actividad. Por lo tanto, las actividades propias del desarrollo software se definen de manera rígida y cerrada [40]. Estas actividades, son una representación formal del ciclo de desarrollo. Si bien, en cada modelo pueden recibir nombres diferentes, en esencia son las mismas, destacando las siguientes: Comunicación Esta actividad es la que permite un diálogo con el cliente o usuario. En esta actividad se recogen los requisitos de usuario y los casos de uso. Planificación Esta actividad tiene por objeto realizar la estimación de recursos, la programación de fechas, planificar el seguimiento del proyecto,... Modelado En esta actividad se obtendrá el diseño conceptual, fruto del análisis de los requisitos capturados. Desarrollo En esta actividad se realizará el trabajo de codificación y construcción de los artefactos software, descritos en el modelo. También se incluyen en esta fase, las pruebas y aceptación. Despliegue Por último, se encuentra la actividad dedicada a la entrega del producto. Algunas metodologías también incluyen tareas de retroalimentación y soporte. El elemento diferenciador entre los diferentes modelos prescriptivos, se encuentra en la organización de las actividades, es decir, en el ciclo de vida a aplicar en el desarrollo del software. Tan solo se enumeran a continuación las alternativas más representativas, ya que son de sobra conocidas: Modelo en cascada [41]. Modelo iterativo [42]. 51

72 Capítulo 5 Rapid Application Development [43]. Modelo evolutivo [44]. Modelo en espiral [45]. Proceso unificado de desarrollo [46]. El problema común que se observa en todas estas alternativas, radica en la rigidez que presentan estas metodologías. Estos métodos están pensados de tal manera que se le otorga mayor importancia al proceso, primando este sobre cualquier otro aspecto. Además, el papel de la actividad del modelado es crucial. Estos métodos precisan de una buena modelización. Sin embargo, dada la naturaleza del presente trabajo y su carácter experimental, no sería práctico aplicar un método rígido, sino más bien todo lo contrario. Es preciso recurrir a un método más flexible, donde el dialogo con el usuario esté presente de manera continua y donde se priorice la experimentación continúa Metodologías ágiles A principios de la década del 2000, en un momento en el que los métodos prescriptivos eran la tendencia en la gestión del desarrollo software, se firmó el manifiesto ágil [47]. En este manifiesto se plasmó una nueva corriente para gestionar el proceso de desarrollo software, en la que, sin denostar el uso de procesos, herramientas o actividades descritas en los modelos prescriptivos, se priorizaba sobre cualquier otro aspecto la relación entre individuos y sus iteraciones, la obtención y desarrollo de software funcional y de utilidad frente al cumplimiento de planes y diseños y/o contratos. La característica más importante del manifiesto ágil, precisamente la que le confiere el adjetivo ágil, es sin duda, la capacidad de adaptación al cambio. En este sentido, Ivar Jacobson define la agilidad como la capacidad de responder a los cambios de manera apropiada, ya que los cambios no solo obedecen a caprichos del usuario final, sino que pueden surgir por modificaciones en el equipo de desarrollo, evoluciones tecnológicas o problemas económicos [48]. 52

73 5.1 Metodología y gestión del proyecto Sin duda, este enfoque de afrontar un desarrollo software, resulta más adecuado para el caso de este trabajo. Ahora bien, existen multitud de métodos denominados ágiles, entre los que cabe destacar SCRUM [49] y XP Programming [50]. Qué método escoger?. Algunos autores como Martin Fowler, advierten de que todo el ecosistema de métodos, denominados ágiles, no son en realidad metodologías, sino más bien prácticas que pueden aplicarse en el seno de otras metodologías para conferir agilidad en el desarrollo del software. Por ejemplo, SCRUM es un método de gestión de equipos que no especifica actividades de gestión de proyectos software, sino buenas prácticas en la gestión del proyecto que permiten o confieren al equipo, la agilidad necesaria. Sin embargo, surge un inconveniente al intentar esbozar cómo aplicar un método ágil en el desarrollo de este proyecto. La práctica totalidad de métodos ágiles encontrados, están enfocados a la gestión de equipos de desarrollo. Las prácticas que describen y las recomendaciones en la organización y gestión, están dirigidas a mejorar la comunicación entre los miembros del equipo. Obviamente, este proyecto será desarrollado por una sola persona. Si bien existen variaciones de los métodos ágiles, para la gestión de proyectos unipersonales, como por ejemplo Personal Kanban [51], se ha preferido, no aplicar ninguna metodología existente y hacer uso de la máxima del manifiesto ágil, priorizar por encima de todo, las relaciones humanas y la obtención de un software funcional Método de trabajo El hecho de que no se haya elegido ninguna metodología específica, no significa que el trabajo haya sido realizado de manera arbitraria y desordenada. Para la gestión de este proyecto se han reutilizado herramientas, técnicas y actividades de diferentes metodologías y se han aplicado de manera estructurada, según el criterio del doctorando, priorizando, como ya se ha dicho, las relaciones entre los participantes del proyecto y la obtención de un software funcional y de utilidad. 53

74 Capítulo 5 Así pues, el trabajo de desarrollo se planteó como un proceso continuo de prototipado, en el que los hitos a conseguir se planificaran de manera frecuente y delimitando el alcance, pero siempre bajo la premisa de construir un software lo más mantenible y extensible posible. Parte de la metodología y organización ha sido similar al de experiencias previas en el desarrollo ágil con Java[52, 53], en las que se utilizaban tecnologías similares a las utilizadas en este proyecto y se aplicaban principios ágiles derivados, entre otros, de los conceptos SOLID[54] (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion). Para dar cabida a este proceso continuo de prototipado, se ha utilizando el concepto de sprint derivado de SCRUM, si bien la duración de los mismos no ha sido siempre regular, dado que el doctorando ha tenido que compaginar el desarrollo de esta tesis, con su actividad profesional, no era posible determinar una duración predefinida, así que la duración de estos ha estado condicionada por la disponibilidad del doctorando. Sin embargo, se ha intentado mantener un ritmo constante, en el que los sprints no fueran muy cortos, ya que al tratarse de un solo desarrollador, la cantidad de objetivos a cumplir es más reducida y esto puede conllevar un riesgo asociado, cuando se desea equilibrar dos aspectos opuestos: Por un lado, dado que se está prototipando continuamente, se desean construir estructuras abstractas, bien diseñadas que fomenten la cohesión y disminuyan el acoplamiento, porque de esta manera se facilitan posteriores cambios de diseño. Pero por otro lado, se desea que los ciclos de desarrollo o sprints no sean demasiado largos y así evitar en los usuarios la sensación de que el proyecto no avanza, manteniendo el interés de los mismos. Para la planificación de cada sprint, se ha recurrido a la descripción de un backlog previo y consensuado, en el que recoger las funcionalidades o historias de usuario a desarrollar, tal y como se indica en SCRUM. Este backlog ha sido utilizado también para chequear el cumplimiento de los objetivos del sprint. Respecto a las herramientas de gestión del proyecto, en la sección sección 5.2 se 54

75 5.2 Herramientas de desarrollo detallarán las herramientas utilizadas, entre las que cabe destacar los repositorios para el código fuente, gestores de tareas y herramientas de diseño. También se detallará la evolución que ha sufrido el proyecto en el uso de estas herramientas. Como resumen de esta sección, destacar que el método de trabajo definido, ha permitido al doctorando avanzar de manera paulatina pero sin interrupciones, así como poder probar soluciones, librerías, implementaciones y desechar sin demasiado coste, aquellas que no satisfacían los objetivos Herramientas de desarrollo Desde el inicio del trabajo, se decidió que el lenguaje de programación sería Java, por el dominio y experiencia del doctorando y por la gran cantidad de librerías y proyectos de Software Libre de ámbito sanitario, desarrollados en este lenguaje. Como entorno de desarrollo se decidió utilizar Eclipse. Este entorno de desarrollo destaca por su versatilidad y por la simplificación de determinadas tareas muy comunes, como son el despliegue de aplicaciones web, la integración con servidores y contenedores de aplicaciones, la disponibilidad de plugins de integración con otros software de gestión de proyectos, como Subclipse 1 o Mylyn 2, y por supuesto, por la sencillez y potencia de depuración de aplicaciones. Hasta la construcción del primer prototipo, el desarrollo se hizo de manera aislada en el ordenador personal del doctorando, sin embargo, desde el 27 de julio de 2007 y hasta finales de agosto de 2009, se utilizó una forja de desarrollo Trac junto con un repositorio Subversión, hospedado en un servidor del Laboratorio de Análisis de Imagen Médica y Biometría de la Universidad Rey Juan Carlos. Subversión fue la solución escogida para la gestión del código fuente, por sencillez, y porque dado que el equipo de desarrollo era unipersonal, no se obtendría, a 1 Plugin para eclipse que integra las funciones de un cliente de Subversion, para gestión de repositorios de código fuente. 2 Plugin para eclipse que se integra con gestores de tareas, facilitando la realización de tareas rutinarias como acceso al listado de tareas, asociar contextos a las mismas o permitir el vínculo entre las transacciones de Subversion y las tareas 55

76 Capítulo 5 priori, beneficio claro por utilizar un DCVS 3 como Git o Mercurial. Para la gestión del proyecto, como se ha comentado, inicialmente se recurrió a Trac 4. Este es un proyecto de S.L. desarrollado en Python que permite gestionar de manera sencilla y colaborativa la documentación de un proyecto y sus tareas. Si bien, el equipo de desarrollo era unipersonal, con el desarrollador han colaborado otros usuarios, que han utilizado la plataforma de gestión para comunicar incidencias, consultar el estado del proyecto o documentar funcionalidades. La elección de Trac y Subversion, también vino motivada porque ambas aplicaciones se integran perfectamente. Esto supuso una gestión del proyecto más sencilla, pudiendo llevar de manera automática una traza completa de la evolución del proyecto, gracias al enlace entre tareas y transacciones, que entre otras cosas, ha facilitado la utilización de Mylyn, para integrar el contexto de tareas pendiente en el espacio de trabajo de Eclipse. El objetivo fundamental de aplicar las herramientas comentadas hasta ahora, era disponer de una plataforma de gestión, adecuada a las necesidades del proyecto, pero que no supusiera una gran carga en su administración, ya que dichas tareas, eran asumidas por el doctorando. Como ya se comentara al principio de este capítulo, en referencia a las metodologías ágiles, se deseaba disponer de un proceso de desarrollo controlado y gestionado, pero sin que dicho control y gestión apartara el foco del doctorando del objetivo del proyecto, ni perjudicara las relaciones entre los participantes del proyecto. Cuando el proyecto alcanzó un grado de madurez mínimo, se migró a la forja de Google Code, en la que se utilizó también un repositorio Subversion, y en la que actualmente está hospedado el proyecto. Desde que el proyecto se migrara a la forja de desarrollo de Google Code, se encuentra registrado en la red de código abierto, Ohloh 5. Según esta red, que ofrece determinadas estadísticas basadas en el análisis de los repositorios de 3 Distribuited Control Version Systems. 4 trac.edgewall.org/. 5 es un directorio público de personas y proyectos de software Open Source. 56

77 5.2 Herramientas de desarrollo código fuente, el proyecto : a) consta de líneas de código 6. De las cuales, más de son código Java, y b) se han realizado 113 commits en la forja de Google. Previamente, en la forja de la universidad, se habían realizado 139 commits. En la página actual, además del código fuente, se han puesto a disposición pública documentación, una demo de la aplicación y un vídeo demostrativo de la aplicación. Todo este material, incluyendo el presente documento, ha sido credo utilizando exclusivamente Software Libre: TexLive, TeXstudio, JabRef, InkScape y Gimp, a excepción de la máquina virtual, que fue creada con VMWare Player Gestión del código fuente En la actualidad, el código fuente es gestionado mediante la herramienta Maven, lo que facilita en gran medida los procesos de compilación, empaquetado y despliegue de la aplicación. Esto es importante en un proyecto de software libre, ya que facilita a cualquier persona interesada, la utilización del código fuente. Maven tiene como principal ventaja, la gestión de dependencias sobre librerías de infraestructura. Mientras el proyecto fue gestionado de manera manual, se perdió mucho tiempo en la resolución manual de las dependencias que debían ser satisfechas, por las diferentes librerías. Esta complejidad, también suponía una traba importante a la hora de poder compartir el código fuente con otros interesados. Por último, otra ventaja importante derivada del uso de Maven, es la facilidad para que diferentes programadores puedan escoger que entorno de desarrollo utilizar. Maven dispone de múltiples plugins que permiten acoplar la estructura del proyecto a los requisitos de cada entorno. De esta manera es posible programar esta aplicación desde Eclipse, NetBeans, IntellIDEA, JDeveloper, o cualquier otro entorno soportado. Incluso es posible programar, sin la utilización de ningún entorno. 6 Excluyendo líneas en blanco y comentarios. 57

78 Capítulo Infraestructura de sistemas En esta sección se describirá la infraestructura de sistemas utilizada y el plan de despliegue de la aplicación en producción. Respecto de las librerías de desarrollo y proyectos de terceros, utilizados para la construcción y desarrollo del software, estos se irán comentado a medida que se traten los diferentes puntos relacionados en este capítulo. Al igual que en las decisiones sobre las herramientas de desarrollo o la metodología, en lo referente a la infraestructura se ha dado prioridad a las soluciones basadas en Software Libre y se ha intentado, en la medida de lo posible, que el resultado fuera flexible y escalable Sistema operativo La elección del sistema operativo, tanto para la estación de trabajo que sirve de puesto de desarrollo, como las diferente máquinas que han desempañado las funciones de servidor, ha sido Ubuntu, en sus versiones desktop y server. Las razones han sido múltiples, pero cabe destacar la utilización de GNU/Linux, la facilidad de configuración de determinados servicios como RAID y LVM, Apache, PostgreSQL o Tomcat. en el lado del servidor; y de aplicaciones para desktop como TexLive, TeXstudio, Eclipse o ImageJ Infraestructura para el almacenamiento de datos Como se puede ver en la figura 5.1, la aplicación requiere gestionar la persistencia de tres tipos diferentes de entidades: Entidades de negocio, en un sistema RDBMS Por un lado, la aplicación debe gestionar la persistencia de las entidades de negocio, esto es, de los objetos de modelo que representan las entidades de Paciente, Estudio y Serie. 58

79 5.3 Infraestructura de sistemas Figura 5.1.: Arquitectura de almacenamiento. Colecciones de imágenes Por otro lado, la aplicación debe gestionar la persistencia, tanto de las imágenes adquiridas en las modalidades de adquisición, como las imágenes resultantes de los procesos de tratamiento, normalización y/o manipulación de otras imágenes. Metadatos de las imágenes Por último, la aplicación precisa almacenar de manera independiente, los metadatos de las imágenes persistidas. Este almacén permitirá la indexación y búsqueda de imágenes y/o estudios por campos específicos de los formatos contenedores de las imágenes. Para gestionar las necesidades de almacenamiento comentadas, existen diferentes tecnologías y aproximaciones, que serán examinadas en esta sección para llegar a la conclusión de la combinación más adecuada, dada la naturaleza del presente proyecto. 59

80 Capítulo Entidades de negocio Resulta obvio que la mejor manera de resolver esta necesidad, es recurrir a una solución de almacenamiento relacional en combinación con un framework de mapeo objeto/relacional. Si bien, existen soluciones nativas de persistencia de objetos, hoy por hoy, el estándar de facto en persistencia de entidades de negocio es Hibernate y/o JPA 7. Para el presente proyecto, se ha elegido como base de datos relacional PostgreSQL, por ser la solución de Software Libre reconocida por su estabilidad y eficiencia, así como por las posibilidades de extensibilidad que ofrece, sobre todo tras las mejoras de la versión 8 y posteriores. Aunque no está claro que este sistema relacional tenga un mejor desempeño sobre otros sistemas también libres, como MySQL o MariaDB, si parece existir consenso respecto de la mayor estabilidad y extensibilidad de PostgreSQL frente a otras alternativas 8. Hibernate[55], es el framework escogido, por razones similares a PostgreSQL, para la tarea de gestión del mapeo del modelo de objetos que representa las entidades de negocio al modelo de almacenamiento relacional Persistencia de las colecciones de imágenes Este apartado es el más controvertido de los tres. Dado que las imágenes están representadas en ficheros, que en determinados casos pueden ser de un tamaño considerable, surge la pregunta sobre cual es la mejor elección para el almacenamiento de las mismas. La primera opción, quizás por su aparente sencillez, consiste en la gestión de los ficheros, que representan las imágenes, utilizando un sistema de ficheros. Sin 7 Java Persistence API, especificación de persistencia ORM de J2EE 8 Existen multitud de benchmarks y test realizados por revistas técnicas, bloggers e investigadores, que muestran diferentes resultados, dependiendo fundamentalmente de la configuración de los servidores y las pruebas realizadas. 60

81 5.3 Infraestructura de sistemas embargo, esta opción no resulta tan simple, pues existen determinados factores que complican la gestión adecuada de las imágenes: Cuántos ficheros representan una imagen?. Puede ser que haya formatos de imagen, que no encapsulen toda la información en un solo fichero, sino que recurran a varios, por ejemplo Analyze dispone de un fichero para la meta información y otro para los datos de la representación gráfica. Integridad de los datos. Como no puede ser de otra forma, aunque se disponga de tres almacenes diferentes, la información almacenada en cada uno de ellos estará interrelacionada entre si. Por lo tanto, surgen las siguientes preguntas: Cómo se puede garantizar la atomicidad de las operaciones de persistencia? Cómo se puede garantizar la consistencia de los datos? y su accesibilidad? Cómo se pueden unificar las políticas de copia y restauración de datos? Una segunda opción, consiste en la persistencia de las imágenes en la propia base de datos. Tanto Hibernate como PostgreSQL permiten la gestión de tipos LOB 9, lo que simplifica y resuelve las dudas expresadas acerca del almacenamiento en un sistema de ficheros, ya que las operaciones que se realizan con las imágenes están dentro del alcance transaccional de la base de datos. Sin embargo, algunos estudios como el de Sears y Van Ingen[56], desaconsejan superar determinados umbrales respecto del tamaño de los datos a persistir, que se suelen ubicar por debajo del megabyte de tamaño. En el caso particular de la imagen médica, existe una gran variabilidad en el tamaño de los ficheros, así como en el número de ficheros que componen una imagen. El principal problema de esta segunda alternativa, es el rendimiento. Las operaciones de consistencia de datos y gestión transaccional, se vuelven muy costosas cuando se aplican a datos que exceden el megabyte. 9 Large Objetcs 61

82 Capítulo 5 Figura 5.2.: Teorema CAP, obtenido de [5]. Existe una tercera opción, muy reciente, pero con una gran aceptación. Las alternativas NO-SQL[5] no sufren de los inconvenientes de rendimiento que adolecen los sistemas gestores de bases de datos relacionales, y además garantizan cierto nivel de consistencia. Además, la principal ventaja de estos sistemas, reside en la posibilidad de escalabilidad. Por contra, este tipo de almacenamiento sufre de un problema conocido, que se ha denominado como el teorema CAP. Este teorema, debe su nombre a las iniciales de tres aspectos fundamentales de cualquier tecnología de almacenamiento de datos, que so: Consistency. Los datos son consistentes, independientemente de la instancia en la que se encuentren. Availability. Los datos deben ser siempre accesibles. Partition Tolerance. El sistema es tolerante a fallos en los nodos de almacenamiento o en la red de comunicación entre nodos. La figura 5.2, ilustra gráficamente la relación entre los tres aspectos. Según este 62

83 5.3 Infraestructura de sistemas teorema, en un sistema distribuido solo es posible garantizar de manera simultánea dos de los tres aspectos comentados 10. Dado que los dos aspectos que más interesa garantizar en este proyecto, son la consistencia y la disponibilidad, resulta que lo ideal, según este teorema, es aplicar un sistema gestor de base de datos, que precisamente se caracterizan por ambos aspectos. Otras alternativas, como por ejemplo la aplicación de el proyecto XADisk, permiten la aplicación de una capa de transaccionalidad al sistema de ficheros, de manera, que incluso es compatible con la especificación de XA Transacctions, que implementan en concepto de transacciones en dos fases. De este modo, sería posible sincronizar las transacciones de dos o más sistemas, para que una operación que involucre a varios recursos transaccionales, sea atómica. Sin embargo, el incipiente estado del proyecto XADisk, en el momento de iniciar el proyecto fue valorado negativamente. Por contra, dado que este proyecto ha alcanzado un buen nivel de madurez, sobre todo durante el año 2012, se considerará su aplicación, como trabajo futuro en la evolución de la herramienta, ya que su aplicación podría conferir una mayor consistencia Persistencia de los metadatos Respecto del almacén de metadatos, cada formato de imagen médica posee una cabecera propia en la que reside información relacionada con la imagen, la técnica de obtención, el dispositivo de captura, filiación del paciente, representación de los datos gráficos, dosimetría, entre otros. El lenguaje XML resulta idóneo para representar los metadatos de los diferentes formatos de imagen, ya que al tratarse de un lenguaje semi-estructurado, permite disponer de diferentes esquemas de representación, adaptados a cada formato de imagen y utilizar transformaciones XSLT para homogeneizar la representación de cada metadato en un lenguaje común. 10 Aunque este teorema ha recibido críticas [57], dado que aun no se ha demostrado su falsedad, se asumen como cierto. 63

84 Capítulo 5 Así pues, es preciso disponer de un medio de almacenamiento y gestión de contenido XML, para los metadatos de las imágenes médicas. Las bases de datos relacionales como PostgreSQL, suelen incluir mecanismos propios 11, que permiten almacenar y operar de manera sencilla contenido en formato XML. En esta línea, PostgreSQL permite almacenar los datos XML como un tipo CLOB[58] al que puede aplicar determinadas funciones de tratamiento XML, como validación contra esquemas o búsquedas XPath. 12 Sin embargo, El soporte a XML por parte de PostgreSQL, y en general de las bases de datos libres, se encuentra aún en un estado muy incipiente. Por ejemplo, no se soportan de manera apropiada operaciones como transformaciones XSLT, creación de índices por campos XML o expresiones xpath, y el rendimiento que ofrecen las consultas SQL que combinan expresiones xpath, es aún muy mejorable. Por contra, existen bases de datos nativas en XML, que ofrecen un rendimiento mucho mayor que la alternativa relacional y que además soportan de manera muy cómoda las operaciones anteriormente mencionadas, sobre todo, la creación de índices. Se ha optado por escoger la base de datos nativa exist 13. Respecto a otras bases de datos XML nativas, que sí permiten la definición de índices, la ventaja de exist reside tanto en la eficiencia de la misma, como en la gran versatilidad a la hora de su integración en proyectos Java, ya que ofrece varias posibilidades de gestión, destacando la interfaz XMLDB, un API basada en REST, SOAP y XML-RPC Problemas de la gestión de tres almacenes diferentes A modo de resumen de esta sección, para la gestión del almacenamiento se ha decido recurrir a tres tecnologías diferentes. Esta decisión conlleva inconvenientes, sobre todo a la hora de asegurar la consistencia y sincronización de los tres 11 que normalmente suelen ser compatible con la especificación SQL/XML definida por ISO/IEC 9075 Parte Para más información, ver datatype-xml.html

85 5.3 Infraestructura de sistemas almacenes, ya que al no estar coordinados los contextos de transaccionalidad, no es posible garantizar la atomicidad de las operaciones que requieran operar sobre dos o más almacenes. Mas adelante, en este mismo capítulo, en la sección se analizarán estas inconveniencias así como el diseño y la implementación utilizada para paliar en la medida de lo posible este inconveniente. Cabe destacar, que desde el momento de inicio del desarrollo de este proyecto, las tecnologías de persistencia utilizadas han madurado bastante y en el escenario actual, es posible realizar un nuevo estudio, puesto que a priori, parece factible poder aplicar transacciones coordinadas entre PostgreSQL, exist y el sistema de ficheros, mediante la aplicación del proyecto XADisk Servidor de aplicaciones La plataforma escogida como servidor de aplicaciones consiste en el front-end Apache HTTP Server y contenedor de servlets, Apache Tomcat. Para la integración de ambos servidores se ha recurrido al protocolo AJP, mediante el conector Apache Tomcat Connector o también conocido como modjk. Si bien existen servidores de aplicaciones basados en Software Libre, como JBoss o Apache Geronimo, no se precisan las características relativas a J2EE, ya que como se verá más adelante, la arquitectura software utiliza Spring[59] e Hibernate como IoC 14 y ORM 15. La combinación de ambos servidores tiene algunas ventajas sobre los servidores de aplicaciones que son de gran importancia para la aplicación objeto de esta tesis: Por un lado, esta combinación resulta más liviana y mantenible. Los servidores de aplicaciones, implementan toda la especificación de J2EE, lo que conlleva una cantidad importante de infraestructura que no va a ser utilizada, pero que en muchos casos, puede requerir tareas de mantenimiento. 14 Inyector de dependencias, o también conocido como Inversion of Control[60] 15 Object Relational Mapping 65

86 Capítulo 5 Por otro lado, la separación de funciones en dos servicios distintos, permite diferentes opciones de configuración, ofreciendo mayor flexibilidad y capacidad de adaptación a diferentes situaciones. Es posible ubicar ambos servicios en una misma máquina, si es preciso simplificar la infraestructura y la carga de trabajo así lo permite. En caso de que la carga de trabajo sea superior a la capacidad de la máquina, es posible separar los dos servicios en máquinas diferentes, optimizando cada una de ellas a las necesidades de cada servicio. En escenarios de mucha carga, la combinación de ambos servicios y el protocolo AJP permiten la creación de un cluster de contenedores de servlets que procesen las peticiones recibidas por el front-end HTTP. Sirva de ejemplo, la figura 5.3 en la que se muestra un posible escenario de despliegue de la infraestructura requerida para la ejecución de la aplicación, donde cada servicio se despliega en una máquina diferente. Figura 5.3.: Propuesta de infraestructura. Este despliegue permite que en un futuro cualquiera de los tres servidores, pueda ser sustituido por un cluster que permita aumentar el rendimiento y/o garantizar una mayor tolerancia a fallos. 66

87 5.4 Fundamentos de la arquitectura de la aplicación 5.4. Fundamentos de la arquitectura de la aplicación Como ya se ha mencionado previamente, se ha puesto mucho énfasis en producir un código fuente que resulte fácilmente adaptable y mantenible, y para ello se ha tenido muy presente principios básicos de la orientación a objetos, como SOLID. Dado que se pretende que el proceso de desarrollo esté basado en la realización de ciclos cortos de desarrollo en los que ir evolucionando el prototipo, es fundamental disponer, no solo de un buen diseño, sino de realizar una codificación limpia y que permita en la medida de lo posible, la evolución continúa del prototipo, evitando así correr el riesgo de crear resistencias cuya resolución pueda desviar el objetivo del desarrollo. Uno de los problemas más comunes en el desarrollo de software, consiste en no diferenciar bien las responsabilidades que debe cumplir cada clase, módulo, paquete o componente, propiciando que las diferentes estructuras se acoplen entre sí. Cuando esto ocurre, el código presenta resistencia a ser modificado, ya que las dependencias entre estructuras se distribuyen por todo el código y hacen más complicado cualquier cambio. Estos problemas son descritos en SOLID como rigidez, fragilidad, y viscosidad. Para lograr los objetivos expuestos, se ha recurrido en diferentes ocasiones a patrones de diseño bien conocidos. El primero de ellos, el patrón de diseño Modelo Vista Controlador o MVC, es el que gobierna la arquitectura de la aplicación. Para la implementación del MVC, se decidió recurrir al framework de Java, Java Server Faces (JSF) de la especificación J2EE[61, 62]. Con este framework, las capas de vista y control Figura 5.4.: Arquitectura. quedan bien delimitadas y si se hace un uso adecuado, es fácil no acoplar las estructuras de estas capas. No hay mucho que decir por lo tanto de estas dos capas, 67

88 Capítulo 5 salvo que cumplen bien con sus responsabilidades, que son: presentar datos al usuario, ordenar acciones a la capa de lógica de negocio y controlar la navegación en la aplicación. No obstante, respecto de la capa de Modelo, el diseño de la aplicación resulta bastante más complejo. Esta capa ha sido divida a su vez en subcapas, como se muestra en la figura 5.4, donde, como es de esperar, cada una de ellas ha sido diseñada para cumplir con una responsabilidad determinada. Para articular toda la lógica de negocio, se ha recurrido al patrón comando. Como se verá en la siguiente sección, este patrón se convierte en el eje central de la ejecución de acciones de la lógica de negocio. Más adelante, en este capítulo, se verán qué otros patrones han sido aplicados para solventar situaciones específicas Patrón comando y aspectos transversales El patrón comando[63, 55] desempeña un papel crucial en la capa de modelo. Este patrón es uno de los patrones básicos del diseño orientado a objetos, se enmarca dentro de la categoría de patrones de comportamiento 16, y básicamente, la función que este patrón desempeña, consiste en encapsular en una sola clase, el estado y el comportamiento de una acción determinada: El estado se representa mediante atributos del comando, algunos de los cuales son también parámetros que controlan la ejecución del comando o que son necesarios para lograr el objetivo del comando. El comportamiento del comando se suele programar en un método que es el que se ejecuta cuando se solicita la ejecución del comando. Este patrón ha sido utilizado para ofrecer una manera controlada y supervisada de acceso a la lógica de negocio, permitiendo además la implementación de aspectos transversales como son por ejemplo la auditoría y la autorización de acciones. 16 Behavioral patterns. 68

89 5.4 Fundamentos de la arquitectura de la aplicación Figura 5.5.: Representación esquemática de un aspecto transversal. Los aspectos transversales se caracterizan por no pertenecer directamente a la lógica de negocio de la aplicación, aunque estén presentes en la misma. La figura 5.5, muestra de manera esquemática un ejemplo de aspecto transversal, en el que se implementa un sistema de auditoría por el que todas las operaciones queden debidamente auditadas en alguna bitácora o log. Así pues, si dos clases diferentes implementan métodos de lógica de negocio, estos deben tener una dependencia funcional con el método de registro de autoría, para satisfacer dicho aspecto transversal. La implementación de estos aspectos transversales suele suponer un reto a la hora de su diseño, pues típicamente no son sencillos de encapsular en una estructura o clase y cumplir así con el objetivo de reparto de responsabilidades. La programación orientada al aspecto, es una técnica, relativamente reciente y soportada en Java, que permite definir aspectos transversales e implementar su comportamiento de una manera encapsulada. Esto supone una gran ventaja, pero tiene en contra una merma en el rendimiento de la aplicación, pues la programación orientada al aspecto[64] recurre a la técnica de reflexión[65] y al patrón proxy[63]. Por un lado, la reflexión es una técnica que permite explorar en tiempo de ejecución la estructura de un objeto, y puede ser usada con la finalidad de poder interceptar llamadas a determinados métodos. Sin embargo, esta técnica resulta bastante costosa. Por otro lado, el patrón proxy es utilizado para envolver un determinado objeto de manera que el objeto envolvente simula el comportamiento del objeto envuelto. La programación orientada al aspecto, permite definir qué métodos deben ser interceptados para que les sean aplicados determinados aspectos transversales, 69

90 Capítulo 5 como los ya comentados. La figura 5.6 muestra cómo un proxy, que envuelve las clases que implementan la lógica de diseño, absorbe la dependencia con la clase que implementa la auditoría. De esta manera se obtiene un código menos acoplado. Para poder dar solución a la implementación de estos aspectos sin introducir el coste de la programación orientada al aspecto, se ha utilizado el patrón comando. Este patrón implica el uso de al menos dos elementos: por un lado una estructura abstracta que define un comando y por otro una clase especializada en la ejecución de comandos. Si bien el patrón comando no puede ser Figura 5.6.: Utilización de AOP para utilizado como un sustituto natural de la implementar un aspecto programación orientada al aspecto para la transaccional. aplicación de aspectos transversales, determinados aspectos pueden ser incluidos en la clase especializada en la ejecución de comandos. Por ejemplo, la configuración de la transacción de acceso a datos, la comprobación de credenciales y autorización y el registro de auditoría en la realización de una acción. Figura 5.7.: Patrón comando solucionando dependencias transversales. Así pues, se ha creado una variante del patrón comando para soportar este escenario, similar a la ilustrada en la figura 5.7. Sin embargo, el beneficio del patrón 70

91 5.4 Fundamentos de la arquitectura de la aplicación comando no se limita a una implementación más eficiente, sino que permite construir una capa de unión entre las capas de vista y control y la capa de modelo. Si bien existe un patrón conocido que ostenta esta responsabilidad, el patrón fachada, este aplica solo al ámbito de una clase en la que se implementen métodos de conveniencia para simplificar el acceso a la lógica de negocio. Con la aplicación del patrón comando, se construye un paquete en el que se programan tantos comandos como casos de uso existan. Por tanto la responsabilidad de los comandos queda también bien delimitada: son los responsables de invocar a la lógica de negocio de una manera controlada en la que se respeten los aspectos transversales definidos en la aplicación. Con esta capa intermedia, construida a base de comandos, se consigue que la lógica de negocio se independice de los aspectos transversales, algo muy deseable ya que sigue el principio de que cada clase cumpla una responsabilidad delimitada. También se consigue que la lógica de negocio se independice de la forma en que esta debe ser invocada, de esta forma la lógica de negocio esta centrada solo en lo que le atañe, es decir, la implementación de las funcionalidades exigidas, sin injerencias, ni dependencias de la capa de vista, ni de la forma de publicar el acceso a la misma, ni de los aspectos transversales. Una vez aislada la lógica de negocio de aspectos secundarios al objeto principal del estudio, es posible centrar los esfuerzos de desarrollo en la construcción de prototipos incrementales que aborden la problemática de la gestión de la imagen médica en los ensayos clínicos Abstracción para las entidades de negocio Usar Hibernate, como cualquier otro motor de persistencia ORM, conlleva una serie de ventajas que son bien conocidas, pero también supone tener en cuenta una serie de factores a la hora de crear las entidades del modelo de negocio, es decir los objetos que se van a persistir en BBDD. Por ejemplo, Hibernate utiliza el patrón proxy, para soportar una función denominada carga perezosa o lazy load. Esta función permite a Hibernate recuperar bajo 71

92 Capítulo 5 demanda, la información de una entidad de negocio. Por contra, la otra opción de carga de entidades de negocios, denominada eager fetch, supone cargar en memoria toda la información de la entidad, así como todas sus relaciones, lo que puede resultar muy costoso, en cuanto a ocupación de memoria. Para implementar la funcionalidad de carga perezosa, Hibernate utiliza el patrón proxy, mediante la librería CGLib. Esta librearía java está especializada en implementar proxies dinámicos, es decir, en tiempo de ejecución. Por lo tanto, Hibernate no recupera el objeto solicitado de base de datos, sino que crea un proxy que aparenta ser el objeto solicitado a la base de datos y se lo entrega al usuario. Esta funcionalidad es muy interesante, pero tiene sus inconvenientes, por ejemplo, los proxies no sirven para implementar polimorfismo dinámico, lo que supone un problema con entidades especializadas. Además el proxy depende de la sesión de acceso a datos, ya que para cargar una propiedad o asociación necesita la conexión a base de datos (o lo que es lo mismo el contexto de persistencia). La implementación de los proxies tiene también implicaciones con la implementación que por defecto ofrece Java del método equals, pudiendo ocurrir que dos proxies diferentes, que recubren a la misma entidad de negocio, sean considerados como objetos diferentes. Todos estos inconvenientes son perfectamente salvables utilizando técnicas y patrones adecuados. El patrón visitor, permite solventar los inconvenientes que los proxies presentan con respecto al polimorfismo dinámico. El patrón patrón OSIVF (Open Session in View Filter) permite paliar los efectos negativos de las cargas perezosas, vinculando la durabilidad de una sesión Hibernate con el thread que se crea para procesar la solicitud web (HTTP Request). Pero para ofrecer una solución adecuada al problema relacionado con la identidad de los objetos y el problema que presentan los proxies con el método equals es preciso recurrir a las denominadas claves de negocio[55]. Por lo tanto, se ha creado una entidad abstracta, denominada DomainObject, de la que dependen todos los objetos de modelo que implementan a las entidades de negocio de la aplicación. En esta abstracción se implementa una clave de negocio basada en el estándar UUID[66], así como una implementación adaptada 72

93 5.4 Fundamentos de la arquitectura de la aplicación Listing 5.1: Fragmento del código de la clase DomainObject 1 public class DomainObject implements Serializable{ 2 private Integer code = 0; 3 private String oid = null; 4 5 public DomainObject(){ 6 oid = java.util.uuid.randomuuid().tostring(); 7 } 8 10 public int hashcode(){ 11 return getoid().hashcode(); 12 } public boolean equals(object obj){ 16 boolean result = false; result = (this == obj); if( (!result) && (obj!= null)) 21 if(obj instanceof DomainObject) 22 result = this.getoid(). 23 equals(((domainobject)obj).getoid()); return result; 26 } 27 } 73

94 Capítulo 5 a esta clave de negocio para los métodos hashcode y equals, que garantiza un funcionamiento apropiado. El listado 5.1, muestra parte del código fuente de dicha clase. Además esta abstracción para los objetos de modelo utiliza los tipos de datos genéricos de Java 6[67] para implementar todas las funcionalidades asociadas con la clave primaria que las entidades de negocio tienen, por el hecho de estar persistidas en una base de datos. Listing 5.2: Fragmento del código de la clase GenericDAO 1 public abstract class GenericDAO<T extends DomainObject, ID extends Serializable> extends HibernateDaoSupport{ 2 3 public List<T> findall(){ 4 List<T> result = null; 5 6 try{ 7 result = this.gethibernatetemplate(). 8 loadall(persistentclass); 9 }catch (RuntimeException re){ 10 logerrmsg("findall", re); 11 throw re; 12 } return result; 15 } 16 } Por lo tanto todos los objetos de modelo que implementan entidades de negocio, especializan la clase DomainObject, indicando el tipo concreto de dato de la clave primaria Abstracción para la capa de acceso a datos Dado que las entidades de negocio, precisan estar persistidas en base de datos, es preciso implementar las operaciones típicas del patrón CRUD para cada objeto 74

95 5.4 Fundamentos de la arquitectura de la aplicación de modelo. Tanto Hibernate como Spring dan facilidades para la utilización del patrón de acceso a datos DAO, que es capaz de gestionar la persistencia de cualquier objeto de dominio. Para aprovechar la abstracción realizada para las entidades de negocio y simplificar la creación de clases DAO, se ha creado una abstracción, que también utiliza los tipos de datos genéricos de datos, para implementar una sola vez la lógica básica de persistencia. Cumpliendo con el principio OCP 17 es posible crear especializaciones DAO para cada entidad de negocio, en la que se pueden implementar operaciones de persistencia específicas, como por ejemplo métodos de búsqueda dependientes de atributos propios de cada entidad. Como se puede ver en el listado 5.2, para crear una especialización, es preciso indicar el tipo T que hereda de DomainObject y que restringe el uso del DAO a una entidad de negocio específica. En el código del método findall se puede ver cómo se recurre a Hibernate, además de cómo se resuelve el resultado al tipo genérico Integración con la capa de vista Java Server Faces es la tecnología escogida para la implementación de la capa de vista. Esta tecnología separa por un lado la definición de las interfaces de usuario, mediante páginas web escritas en xhtml y utilizando Facelets, de la lógica de esta capa, que se implementa en los ManagedBeans. Las acciones de los usuarios provocarán la ejecución de métodos específicos de los ManagedBeans, que son los encargados de ejecutar la lógica de negocio de la aplicación. Por tanto, estos beans, deben conocer la infraestructura necesaria para poder invocar comandos, ya que como se indica en la sección 5.4.1, los comandos encapsulan la lógica de negocio, pero estos deben ser ejecutados a instancias de una tercera clase, que solicite al delegado del servicio, la ejecución de un comando específico. Por lo tanto, dado que los ManagedBeans, son los encargados de invocar la lógica de negocio, estos deben tener implementadas las operaciones de creación de 17 Open-Closed Principle, de SOLID. 75

96 Capítulo 5 comandos, ejecución de comandos y obviamente el tratamiento de excepciones. Estas operaciones, son operaciones rutinarias que se deben ejecutar de una manera predeterminada. Además, para poder ejecutar comandos, hace falta tener acceso al delegado de servicio. En este proyecto se ofrece una implementación abstracta de un ManagedBean, en la que se resuelve el acceso al delegado de servicio y se implementan los métodos de creación y ejecución de comandos, denominada AbstractBean. En el listado 5.3 se puede observar cómo esta abstracción tiene una referencia al delegado del servicio y cómo esta es utilizada en el método runcommand para proceder con una ejecución correcta de cualquier comando. Listing 5.3: Fragmento del código de la clase AbstractBean 1 public abstract class AbstractBean { private WebApplicationContext wac = null; 5 private ServiceDelegate service; 6 7 protected Command runcommand(command cmd){ 8 Command result = cmd; 9 10 try{ 11 result = service.runcommand(cmd); 12 if(result.getusercomment()!= null){ 13 setinfomessage(result.getusercomment()); 14 } 15 }catch(exception ce){ 16 seterrormessage(ce.getlocalizedmessage()); 17 } return result; 20 } } 76

97 5.5 Librerías para el tratamiento de las imágenes 5.5. Librerías para el tratamiento de las imágenes En la sección 6.1.3, se describe con detalle la gestión que la aplicación realiza con respecto a la imagen médica. Sin embargo, gran parte del trabajo que se realiza para la gestión de la imagen, es delegado en software de terceros especializados en determinados formatos y/o estándares de imagen médica. Gracias al éxito del Software Libre, es posible encontrar múltiples proyectos que implementan un mismo estándar. Por ejemplo, para el tratamiento de imágenes en DICOM, se han encontrado tres implementaciones muy completas y robustas: a) dicom3tools 18 ; b) dcmtk 19 ; y c) dcm4che2 20 Así pues, surge la pregunta Qué implementación escoger?. Para determinar cual es la mejor opción, es preciso evaluar detenidamente cada opción, sin embargo, no siempre se dispone del tiempo necesario o no se conocen todos los factores determinantes en el momento de la evaluación. En nuestro caso, se decidió utilizar la implementación de dcm4che2, tal y como sugiere la revisión realizada por Vázquez et al.[68]. Pero sería un error básico de diseño hacer la plataforma dependiente de esta implementación, ya que ligaría el futuro de la aplicación al de este proyecto y supondría un problema importante de cara a su sustitución por otra implementación. Para otros formatos como NIFTI y Analyze, se ha recurrido a implementaciones libre como NiftiLib. El proyecto xmedcon es también utilizado para simplificar la conversión entre formatos de imagen

98

99 6. Resultados En este capítulo se describe a nivel funcional la aplicación desarrollada como resultado del presente trabajo de investigación. Las funcionalidades aquí descritas, resultan básicas para comprender las decisiones técnicas y metodológicas descritas en el capítulo anterior. En este capítulo también se describe la experiencia sobre la utilización de la aplicación y los resultados obtenidos en la Fundación CIEN 1 en Madrid, dónde se aplica a diferentes ensayos sobre enfermedades neurodegenerativas Descripción funcional La aplicación desarrollada consta principalmente de dos áreas bien diferenciadas. Por un lado, existe un área específica de gestión y administración, dedicada al usuario administrador y en la que se permite la creación y gestión administrativa de ensayos clínicos, usuarios investigadores y los roles con los que participarán en cada ensayo clínico al que se le otorgue acceso. Por otro lado, la aplicación dispone del área de investigación en la que los usuarios investigadores pueden interactuar con cada uno de los ensayos clínicos en los que han sido autorizados. Cada usuario dispondrá de unos privilegios y permisos específicos para cada ensayo clínico. Estos permisos, agrupados en roles predeterminados, pueden ser diferentes para cada ensayo en el que el usuario participe. 1 Fundación Centro de Investigación en Enfermedades Neurológicas, 79

100 Capítulo 6 En el área de investigación, los usuarios pueden interactuar con los grupos del ensayo, los pacientes y sus estudios de cada grupo y obviamente, pueden trabajar con las imágenes disponibles. En este área el trabajo se repartirá entre los diferentes usuarios mediante el uso de tareas, que tendrán asociados resultados. En las sucesivas secciones se irán desgranando con mayor nivel de detalle, cada una de las áreas, así como la parte específica de envío y recepción de imágenes, que puede ser realizada de diferentes maneras Área de administración El área de administración esta diseñada para soportar la gestión de las entidades fundamentales para el funcionamiento del área de investigación. Solo los usuarios marcados específicamente como administradores, pueden entrar en este área. La aplicación permite la ejecución de múltiples ensayos clínicos, con la participación de múltiples usuarios en cada uno de ellos y de manera que un usuario pueda participar en varios ensayos clínicos. La participación de un usuario en un ensayo clínico está determinada por un rol que describe los privilegios y permisos que el usuario posee en el ensayo en el que se aplica. Esto permite la creación de diferentes roles, en los que se delimita las operaciones y funcionalidades que se pueden invocar, de manera que un mismo usuario pueda desempeñar roles diferentes en dos ensayos distintos. En este área también es posible administrar los procesos y tipos de imágenes que se pueden incorporar a la aplicación. La aplicación controla mediante tareas, los trabajos de procesamiento de imágenes que deben ser realizados por los investigadores, sobre los sujetos del ensayo. De esta manera, cuando una tarea es creada, es necesario indicar el tipo de procesamiento que debe ser aplicado a la misma. En el área de administración, es posible registrar los tipos de procesos que pueden ser utilizados en la aplicación. Además, en algunas áreas de la aplicación, se controla que determinados tipos de proceses sean aplicados a determinados tipos de imagen, por ejemplo: DETALLAR EJEMPLO DE ESTO MISMO. 80

101 6.1 Descripción funcional En este área es posible administrar los tipos de imágenes válidos. Más adelante, en la sección 6.1.2, se detallarán los lugares de aplicación de estos conceptos, junto con una explicación más detallada de las tareas, de manera que se comprenderá mejor la aplicación y utilidad de estos conceptos. Por último, el área de administración, permite la gestión de las distintas carpetas temporales en las que se almacenan las imágenes que se reciban, así como el registro de las modalidades de adquisición y/o estaciones de trabajo que pueden enviar imágenes mediante el protocolo DICOM. Igualmente, estos conceptos quedarán mejor explicados en la sección Cuando la aplicación recibe una transacción DICOM para el almacenamiento de un estudio, la aplicación comprueba que el AE-TITLE de la máquina que inicia la transacción, está autorizada para enviar imágenes y solo en caso positivo, acepta la conexión y almacena temporalmente las imágenes recibidas. El almacenamiento temporal de imágenes, organiza las imágenes recibidas por carpetas temporales. Estas carpetas son creadas automáticamente por la aplicación y siguen el siguiente criterio. Si las imágenes recibidas, son transferidas desde una modalidad o estación de trabajo DICOM, el nombre de la carpeta temporal será el del AE-TITLE de la máquina que inicia la transacción. Si las imágenes recibidas son enviadas desde un puesto de trabajo, utilizando el protocolo HTTP, entonces las imágenes temporales son almacenadas en una carpeta con el nombre del usuario que está realizando la transacción. Posteriormente, en cada ensayo se autorizará a cada usuario a que pueda acceder a determinadas carpetas temporales, para confirmar la incorporación de las imágenes al ensayo en cuestión. Algunos de los conceptos aquí expresados, pueden resultar confusos, ya que se han presentado desde la perspectiva de su administración. En las siguientes secciones, se van a explicar con más detenimiento cada uno de ellos. Se sugiere al lector que vuelva a esta sección, según avance en la lectura y compresión de dichas entidades, a lo largo de la siguiente sección. 81

102 Capítulo Área de investigación El objeto fundamental del presente trabajo es la gestión de un ensayo clínico basado en imagen médica. Para ello, se han diseñado un conjunto de entidades y un flujo de trabajo que implementan las necesidades básicas del objetivo expresado. Sin embargo, para que la aplicación resulte de utilidad y permita un trabajo efectivo, son necesarias entidades auxiliares y flujos de trabajo complementarios que hacen posible que la herramienta sea de utilidad. En primer lugar, se van detallar las entidades de negocio y el flujo de trabajo básico. Después se irán explicando entidades y flujos complementarios para ir describiendo de una manera incremental y comprensible, la funcionalidad completa de la aplicación Entidades de negocio y flujo principal La figura 6.1, ilustra en un solo diagrama, el flujo de trabajo principal y las entidades que toman parte en el mismo. Tal y como se detalla en la figura 6.1 las entidades que conforman el flujo de trabajo principal son los ensayos. Un ensayo es una entidad que representa a un ensayo clínico y que recoge, por lo tanto, los atributos que describen dicha entidad: nombre, fechas de inicio y fin, financiador y tipo de financiación. Un ensayo contienen a su vez grupos de pacientes. Un grupo es una entidad contenedora, cuya finalidad es representar la agrupación de una serie de paciente conforme a un criterio funcional del ensayo clínico, por ejemplo, el grupo de control. Los pacientes poseen estudios de imagen médica. Estos estudios son el resultado de los procesos de adquisición de imágenes y obviamente se componen de imágenes o series de las mismas. Las imágenes son las entidades que representan los datos capturados y/o obtenidos por procesamiento de imágenes capturadas. Las imágenes son el objeto de tareas en las que se solicita la realización de algún proceso determinado. Las tareas son vinculadas a un usuario en el tiempo y permiten recoger, no solo el resultado del procesamiento, sino un evolutivo en cuanto 82

103 6.1 Descripción funcional Figura 6.1.: Flujo de trabajo y control de calidad. a los comentarios, cambios de estado, registro de documentos y/o resultados, que pueden ir realizando los usuarios. Entidades protocolables y tareas El diagrama de clases representado en la figura 6.2, muestra algunas de las entidades mencionadas y en especial, una sobre la que aún no se ha mencionado nada, la entidad Protocolable. Esta particular denominación viene motivada porque las entidades ensayo, grupo, paciente y estudio se consideran contenedoras de imágenes y por lo tanto, son susceptibles de disponer de un protocolo de creación automática de tareas. Un protocolo de imagen representa un conjunto de procesos que deben ser ordenados de manera automática a todas las imágenes que se añadan al contenedor indicado. Este concepto permite automatizar la creación de tareas de manera 83

104 Capítulo 6 84 Figura 6.2.: Modelo de objetos básico.

105 6.1 Descripción funcional objetiva. Como ya se ha mencionado en el capítulo del Estado del Arte, existen una serie de factores que pueden influir de manera negativa, sino son bien gestionados. Entre estos factores, descritos en la sección 1.2, se incluyen los de la estandarización de los protocolos de adquisición y de los métodos de revisión y evaluación de las imágenes. Una forma de gestionar bien ambos factores es mediante la definición de el protocolo del ensayo clínico, en el que se diseñan los procesos a aplicar sobre las imágenes que han sido capturadas de una manera determinada. La presente herramienta permite definir el protocolo del ensayo clínico mediante el uso de los protocolos y los tipos de imagen. Así, el cumplimiento del protocolo, está asegurado, si este es definido antes de incluir imágenes en el ensayo, pues ninguna imagen quedará exenta de ser procesada conforme a las tareas que se indiquen en el protocolo, y todas y cada una de las tareas, quedarán convenientemente auditadas, de manera que será posible conocer si han sido totalmente realizadas o no, así como conocer el estado y evolución de cada una en particular. Por lo tanto, la entidad protocolable, es una entidad abstracta que recoge la lógica de negocio necesaria para implementar las funcionalidades comunes a todas las entidades que deben satisfacer las funciones relacionadas con la gestión de los protocolos. En la figura 6.3, se representan las clases que implementan las entidades de gestión de los protocolos. Como se puede ver, un protocolo (o una entidad protocolable) puede contener una serie de procesos. Estos procesos, indican qué usuario será el receptor por defecto de la tarea que se cree para cada imagen recibida, cuantos días dispone para cumplir la tarea, y que tipo de proceso debe ser realizado en la tarea creada. El tipo de proceso contiene datos sobre el proceso a realizar, así como una pequeña ayuda a modo de recordatorio. Como se puede observar, un proceso está vinculado de manera unívoca a un tipo de imagen. Esto es utilizado para que la creación de la tarea solo sea efectiva, si la imagen que se está añadiendo al contenedor, es de un tipo específico. La entidad ImageContainer es otra abstracción que representa las funcionalidades comunes de un contenedor de imágenes. Esto es así porque existen entidades 85

106 Capítulo 6 Figura 6.3.: Entidades del flujo de trabajo. que si bien son contenedoras de imágenes, no son protocolables, es el caso, por ejemplo de la entidad Resultado, que se detallará más adelante. Creación manual de tareas La aplicación permite la creación manual de tareas sobre cualquier contenedor. Sin embargo, en este caso y a diferencia de la creación automática de tareas mediante los protocolos, sucede que la tarea creada afecta a todas las imágenes del contenedor, ya que se considera que la creación de una tarea fuera de protocolo, obedece a un criterio de agrupamiento, esto es, a una operación que debe ser realizada en conjunto a todas las imágenes del contenedor. Obviamente, es posible indicar la realización de una tarea al nivel de estudio, en el que se puede considerar que afecta solo a una imagen, en la mayoría de los casos. 86

107 6.1 Descripción funcional Salvando esta diferencia, una tarea creada manualmente, es gestionada por la aplicación exactamente igual que otra que ha sido creada de manera automática. Trabajo con las tareas Las tareas son asignadas siempre a un usuario investigador, que asume la responsabilidad de completar la misma y registrar los resultados. Sin embargo, este usuario puede realizar otras acciones sobre la tarea, como por ejemplo asignarla a otro usuario, escribir un comentario de evolución y/o registrar resultados parciales. La aplicación permite descargar todas las imágenes de una tarea en un archivo comprimido, de esta manera el investigador no tiene que preocuparse por salvaguardar las imágenes, ya que siempre puede recurrir a la descarga. La aplicación agrupa las imágenes en carpetas, por criterios de datos demográficos, respetando el archivo original que fue asociado al ensayo. La aplicación también permite la descarga de todas las imágenes de un contenedor, por ejemplo de un paciente o de un estudio. Esta operación puede resultar muy costosa si el contenedor posee un gran número de imágenes, por ejemplo un grupo. Resultados de las tareas Toda tarea es susceptible de tener resultados asociados a ella. Los resultados pueden ser de diferente naturaleza, pueden ser valores numéricos o comentarios, imágenes procesadas o incluso hojas de cálculo que contengan biomarcadores. Para todas estas posibles situaciones, la aplicación presente alternativas adecuadas. A una tarea se le puede asociar una o varias entidades resultado. Esta entidad dispone de un campo comentario donde es posible escribir textualmente o describir el resultado obtenido. Sin embargo, esta entidad permite que se asocie a ella tanto una o varias imágenes como uno o varios archivos adjuntos. 87

108 Capítulo 6 Imágenes y archivos adjuntos son gestionados de manera diferente, ya que no son procesados por la aplicación de igual manera. Las imágenes son gestionadas de manera muy similar al resto de la aplicación, pues la entidad resultado es una especialización de la entidad ImageContainer (pero no es una especialización de protcolable). Respecto de los archivos adjuntos, en realidad cualquier entidad de la aplicación permite que se le registren archivos adjuntos, sin un propósito predeterminado. Por ejemplo, serían válidos cualquiera de los siguientes escenarios: Adjuntar a un resultado una hoja de cálculo biomarcadores. Adjuntar a un ensayo un archivo con covariables. Adjuntar a un paciente informes clínicos relevantes para el ensayo clínico. Adjuntar a un ensayo la memoria del proyecto. Adjuntar a un grupo un documento con criterios de selección de pacientes. Movimiento y borrado de pacientes e imágenes La aplicación contempla la posibilidad de realizar cambios o movimientos de pacientes entre grupos, así como la posibilidad de borrar paciente e imágenes o mover imágenes de un paciente a otro. Sin embargo, en el último caso, la aplicación tiene en cuenta el hecho de que ninguna tarea de las imágenes del paciente, tenga resultados registrados. En el caso de existir tareas con resultados registrados, la aplicación podría proceder a borrar los resultados con la finalidad de no dejar datos inconsistentes. Sin embargo, esta funcionalidad podría dar lugar a situaciones no deseadas en las que se perderían resultados. Así pues, en el caso de que alguna tarea tenga asociados resultados, la aplicación advierte de tal circunstancia y no permite la operación. Por supuesto, la aplicación permite el borrado de resultados, pero esta operación no es realizada de manera automática, para evitar que por error se puedan perder datos no deseados. La operación de borrado de resultados debe ser invocada manualmente para cada resultado que se desee eliminar. Obviamente el 88

109 6.1 Descripción funcional privilegio asociado a esta operación debería ser autorizado al mínimo de usuarios investigadores posible, por el peligro de un uso indebido. Respecto del movimiento de pacientes de un grupo a otro, la aplicación procede moviendo también las tareas que hubieran sido generadas por el protocolo del grupo antiguo, sin generar de manera automática las tareas que correspondería al protocolo del grupo nuevo Gestión de la imagen La gestión de la imagen médica en la aplicación, se caracteriza por estar dividida en diferentes etapas en las que se realizan diferentes controles y/o transformaciones. En primer lugar, las imágenes, con independencia del método escogido para su inclusión en la plataforma, son almacenadas en un espacio temporal. Este espacio temporal sirve para que los investigadores puedan examinar las imágenes previamente a la inclusión definitiva en los ensayos clínicos, de manera que las imágenes que no cumplan algún criterio, o que no presenten un mínimo de calidad, puedan ser excluidas de la aplicación. Una vez las imágenes son aceptadas para su inclusión en algún ensayo, la aplicación realiza una serie de tareas, como por ejemplo la creación de las tareas en función de los protocolos configurados. Evidentemente, a parte de la creación de las tareas, la aplicación realiza más operaciones con las imágenes. Estas operaciones, así como las entidades de negocio y las estructuras de gestión de las imágenes serán presentadas en esta sección Adquisición de imágenes La aplicación soporta dos métodos de adquisición de imágenes. Por un lado implementa la transacción DICOM C-STORE como SCP 2, que implementa la recepción de imágenes DICOM, y permite el envío directo de estudios de imagen desde el escaner o el PACS a la aplicación. Por otro lado ofrece un Applet de Java que 2 Service Class Provider 89

110 Capítulo 6 permite el envío mediante protocolo HTTP de múltiples ficheros en una sola operación. Mediante esta segunda opción es posible enviar cualquier tipo de imagen, incluyendo también el formato DICOM, desde cualquier ordenador o servidor, usando simplemente un navegador. La implementación de la transacción C-STORE, se ha realizado mediante la implementación de un super-server en el que se han aislado las dependencias de las librerías usadas para no acoplar la aplicación a la tecnología subyacente Exportación de imágenes La aplicación permite exportar cualquier imagen que un ensayo tenga asociado, a través de una transacción DICOM C-STORE. Esta operación de exportar imágenes, puede ser realizada incluso con imágenes que no estén en formato DICOM, ya que la aplicación dispone de la infraestructura necesaria para proceder con la conversión de la imagen a DICOM de manera previa a la operación de exportado. Además, nuestra aplicación permite exportar los resultados de los análisis funcionales. Estos resultados no suelen estar representados en formato DICOM, lo que supone un problema a la hora de remitir a estaciones de trabajo DICOM o a sistemas PACS. Para solucionar este inconveniente, se ha utilizado la especificación DICOM Secondary Capture (SC), que permite convertir imágenes DICOM manipuladas, o imágenes transformadas de otros formatos de representación a DICOM. La forma de implementar esta funcionalidad, mediante DICOM SC, ha sido similar a la utilizada por Maldjian[21]. Existen otras maneras más sofisticadas de abordar este problema, como se explica en CAD-PACS[20], dónde recurren a las recomendaciones de IHE, pero nuestro escenario de integración no adolece de los inconvenientes que motivan el uso de IHE Modelo de datos para la imagen médica A pesar de que DICOM es el estándar más aceptado para la representación de imagen médica en el ámbito asistencial, existen otros formatos de imagen médica, 90

111 6.1 Descripción funcional que tienen cabida para determinadas tareas. Por ejemplo en el ámbito de neuroimagen, son muy utilizados los estándares Analyze y Nifti. Por esta razón, es preciso diseñar un software que sea independiente del formato de representación de la imagen. La figura 6.4, muestra las clases que soportan las entidades para gestionar la imagen médica. Se ha optado por crear una representación abstracta de las imágenes junto con la creación de una interfaz en la que se definen todas las operaciones específicas y/o dependientes del formato de imagen. Existen cuatro clases abstractas y dos clases auxiliares. Las clases abstractas representan los tres tipos de imágenes existentes y los atributos comunes a todas ellas: Imágenes simples. Son aquellas cuya representación y contenido se unifican en un solo fichero. Imágenes complejas. Son aquellas cuya representación se divide en diferentes ficheros, por ejemplo uno para la cabecera con los datos de filiación del paciente y otro para la representación de la imagen. Se excluyen de este tipo las series de imágenes. Series de imágenes. Son conjuntos de imágenes (simples o complejas) en los que se suceden diferentes cortes de una misma prueba. Esta abstracción podría ser ampliada para dar soporte a otros tipos de imágenes, por ejemplo vídeos, pero dado que de momento no se ha registrado dicha necesidad, no se ha procedido a su especificación. Las clases concretas, Thumbnail y PatientInfo son utilizadas para obtener una miniatura de la imagen y para representar un conjunto mínimo de datos de filiación de paciente, respectivamente. En la figura 6.5, se muestra la implementación de los tipos de imagen para el estándar Analyze. Este formato permite representar imágenes bien en un solo archivo o bien en dos archivos, uno con la información de cabecera y otro con los datos de la imagen, por ese motivo se especializan dos clases, heredando cada una de la clase abstracta apropiada. 91

112 Capítulo 6 Figura 6.4.: Clases abstractas para la representación de imágenes. 92

113 6.1 Descripción funcional Figura 6.5.: Especialización para Analyze Tratamiento de la imagen médica Para poder trabajar con cada uno de los diferentes formatos de imagen médica, es preciso realizar operaciones dependientes del formato de fichero y/o de las normas del estándar, de manera que con estas operaciones es posible abrir un determinado fichero, comprobar si es válido o no, anonimizarlo, convertirlo a otro formato o extraer información de filiación del paciente. Dado que se ha creado una representación abstracta de los diferentes tipos de imagen médica, se ha creado también una interfaz que define las operaciones básicas que deben ser provistas para la gestión de un determinado estándar. Esta interfaz será implementada por una clase o extensión, que se puede denominar plugin. La aplicación dispone de un gestor de plugins que junto con las clases concretas del tipo de imagen, definen el comportamiento de un determinado estándar. La figura 6.6 muestra el diagrama de clases de este apartado. 93

114 Capítulo 6 Figura 6.6.: Modelo de plugin para gestión de imagen. Implementación de Analyze. 94

115 6.1 Descripción funcional Se ofrece una implementación por defecto del plugin en la que se resuelven algunos detalles que pueden ser comunes a varios formatos, por ejemplo, el uso de un mapeador de identificadores específicos de cada estándar de representación de imágenes a un esquema propio de esta plataforma, para la identificación unívoca y homogénea de imágenes y series. Este mapeador resulta de utilidad para los formatos que tienen series de imágenes, como por ejemplo DICOM. Para realizar una correcta gestión de los diferentes plugins de tratamiento de imágenes, existe un gestor de plugins que es el encargado de conocer los plugins existentes; detectar para cada formato de imagen, el plugin encargado de su procesamiento; y obviamente, también es el encargado de publicar al resto de la lógica de negocio las operaciones básicas de manipulación de imágenes. De esta manera, cuando algún módulo de la aplicación desea realizar alguna operación con una imagen determinada, puede solicitar al gestor de plugins la ejecución de esa operación sin preocuparse del formato de imagen, ya que será el gestor quién se encargue de delegar en el plugin apropiado dicha operación. Las operaciones que el gestor de plugins pone a disposición del resto de la infraestructura son: Cargar imágenes Dado un identificador de una imagen, esta operación permite la carga en memoria de las estructuras, que conforme con la figura 6.4, representan a dicha imagen. Crear imágenes Dado un conjunto de ficheros, esta operación crea por primera vez las estructuras, que conforme con la figura 6.4, representan a dicha imagen. Obtener metadatos Dado un identificador de una imagen, obtiene la representación en XML de los metadatos de la misma. Obtener previsualización Dado un identificador de una imagen, obtiene un gráfico de pequeñas dimensiones en formato PNG. 95

116 Capítulo 6 Convertir a DICOM Dado un identificador de una imagen, que no esté en formato DICOM, realiza la conversión y devuelve una imagen DICOM de tipo Secondary Capture. Si la imagen está en formato DICOM, no realiza ninguna transformación. Obtener datos de filiación Dado un identificador de una imagen, obtiene, de manera homogénea e independiente del formato original de la imagen, los datos de filiación del paciente y los datos administrativos de representación del estudio o de la serie, si es que el formato de representación de la imagen lo permite. Para la gestión de los plugins, este gestor recurre a un HashMap que permite asociar un listado de plugins para una extensión de archivo. Diferentes formatos de imagen pueden usar una misma extensión de fichero para su representación. Así pues, el gestor permite agrupar varios plugins para una misma extensión y también varias extensiones para un plugin. En el listado 6.1, se puede ver definido el mapa de extensiones y plugins, y cómo se usa en un método para localizar un plugin determinado. Sin embargo, el mecanismo real para determinar si un plugin es el encargado o no del tratamiento de una determinada imagen, consiste en la inspección por parte del plugin, del contenido de la imagen. Esto, evidentemente resulta costoso en tiempo, porque requiere que diversos plugins lean uno o varios ficheros para determinar si entienden el formato de representación de la imagen. Por esta razón, se ideó un mecanismo de identificación de plugins basado en extensiones. De esta manera se reduce el número de plugins candidatos a examinar la imagen, en muchos casos a uno o dos plugins posibles. Para hacer más eficiente este trabajo, se han implementado métodos de conveniencia que normalizan las extensiones. También se da soporte a ficheros sin extensión, por ejemplo, los ficheros DICOM, no siempre llevan la extensión.dcm, sino que a veces se encuentran sin extensión. Como se puede observar en el listado 6.1, el método de obtención de plugins para un fichero, consiste en la obtención de los plugins registrados para la extensión normalizada del archivo en cuestión. En el método setplugins, se puede observar el 96

117 6.1 Descripción funcional Listing 6.1: Fragmento del código del gestor de plugins 1 public class ImagePluginManager { 2 private Map<String, List<ImagePlugin>> plugins = 3 new HashMap<String, List<ImagePlugin>>(); public void setplugins(list<imageplugin> iplgs) { 8 if (iplgs!= null) { 9 for (ImagePlugin plugin : iplgs) { if (plugin.getsupportnoextension()) 12 addpluginextension("", plugin); String[] extensions = plugin.getsupportedextensions(); 15 if (extensions!= null) 16 for (String extension : extensions) 17 addpluginextension(extension, plugin); 18 } 19 } 20 } private List<ImagePlugin> getplugins(file file) { 25 List<ImagePlugin> result = null; if (file!= null) { 28 String ext = StringUtils.substringAfterLast( 29 file.getname(), 30 FilenameUtils.EXTENSION_SEPARATOR_STR); 31 result = plugins.get(imageutil.normalizeextension(ext)); 32 } return result; 35 } } 97

118 Capítulo 6 caso contrario, en el que se registra un conjunto de plugins en el mapa, conforme a las extensiones que cada plugin soporta Asociación automática de imágenes a un ensayo La aplicación permite asociar de manera definitiva, imágenes que estén en el almacenamiento temporal a un ensayo clínico. Esta operación puede ser invocada para cualquier entidad contenedora, excepto para el ensayo clínico, siempre que exista información suficiente de la filiación del paciente en la imagen. Para clarificar el funcionamiento comentado, se detallarán algunas situaciones reales, que ilustran dicha funcionalidad. La aplicación permite asociar imágenes a un grupo, paciente y/o estudio concreto. Sin embargo, no es posible asociar una imagen a un grupo si la imagen no contiene información del paciente y estudio al que pertenece. Según el modelo de datos de la aplicación, ilustrado en la figura 6.2, una imagen pertenecerá a un estudio, un estudio a un paciente y este último a un grupo. Por lo tanto, no es posible vincular una imagen de manera directa con un grupo. Por contra, si la imagen que va a ser asociada al ensayo, dispone de los datos de filiación adecuados, es posible realizar la asociación al nivel del grupo, porque la aplicación podrá localizar al paciente y estudio dentro del grupo, o en caso necesario, crear al paciente y/o al estudio. Por otro lado, puede ocurrir que los datos de filiación del paciente no coincidan con el paciente y/o estudio al que se pretende asociar. Esto puede suceder si los datos de filiación del paciente no han sido convenientemente capturados en la organización que realiza la captura, o si el paciente es atendido en diferentes organizaciones, situaciones que sucede con cierta facilidad. En este último caso, la aplicación advierte de la discrepancia de datos entre los datos del paciente y/o estudio en el que se va a producir la asociación, con los datos de filiación de la imagen a asociar. Sin embargo, la aplicación permite realizar la asociación, sin producir ningún cambio en la imagen asociada. 98

119 6.1 Descripción funcional Gestión del almacenamiento En la sección 5.3.2, queda recogida la discusión sobre las alternativas de diseño y tecnologías aplicables para la gestión del almacenamiento. En este apartado, se profundizará en los aspectos específicos del diseño e implementación, de la solución escogida para la gestión del almacenamiento, respecto de cada uno de los diferentes almacenes, a los que se dedicará una subsección a cada uno Entidades de negocio Respecto del almacenamiento de las entidades de negocio, estas son gestionadas por Hibernate, cuyo mapeo ha sido declarado según ficheros XML. Cada entidad de negocio tiene un DAO asociado que implementa las operaciones de persistencia a modo de broker, utilizando el objeto de Session 3 de Hibernate. Para implementar las entidades de negocio, se ha recurrido a la implementación abstracta DomainObject, comentada en la sección Cada entidad de negocio tiene un fichero en el que se configuran las opciones de mapeo de los objetos que representan las entidades, con las tablas en las que se persisten los datos de los objetos. En estos ficheros de mapeo Objeto-Relacional, se especifican también las relaciones entre las entidades de negocio. Como ya se comentara también en la sección , la utilización de Hibernate como mecanismo de persistencia, tiene un inconveniente cuando se utiliza especialización entre las entidades de negocio. Esta circunstancia sucede en el diseño de esta aplicación, concretamente en el caso de las entidades protocolables, tal y como se observa en la figura 6.2. Las entidades Ensayo, Estudio, Serie son especializaciones de la entidad Protocolable, que es a su vez una especialización de la entidad ImageContainer. Esta relación de especialización aparece configurada apropiadamente en el fichero de mapeo de ImageContainer, como se puede ver parcialmente en el listado La propagación de la sesión, se realiza a nivel de un filtro web, que es declarado en el contexto de la aplicación web, implementando de esta manera el patrón OSIVF, como se ha comentado previamente. 99

120 Capítulo 6 Listing 6.2: Fragmento del mapeo de ImageContainer 1 <hibernate-mapping> 2 <class name="es.urjc.mctwp.modelo.imagecontainer" 3 table="imagecontainer" > 4 5 <joined-subclass 6 name="es.urjc.mctwp.modelo.protocolable" 7 table="protocolable"> 8 9 <joined-subclass 10 name="es.urjc.mctwp.modelo.trial" 11 table="ensayo"> 12 </joined-subclass> </joined-subclass> 15 </class> 16 </hibernate-mapping> La abstracción ImageContainer está diseñada para contener un conjunto de imágenes, directa o indirectamente (a través de otras entidades relacionadas) de manera que especifica operaciones relacionadas con estas imágenes, como por ejemplo: recuperar todas las imágenes, el tipo de las imágenes o la colección donde se almacenan. Cada una de las especializaciones de esta clase, implementa estos métodos de manera concreta. Por ejemplo, la entidad Ensayo implementa la operación de recuperar todas las imágenes accediendo a todos los estudios, para cada estudio a todas las series y para cada serie a todas las imágenes; luego compone una lista con todas las imágenes obtenidas, que devuelve como resultado. De esta manera es posible simplificar las operaciones con los contenedores de imágenes al resto de la infraestructura, que no tiene que preocuparse del tipo específico de contenedor, para poder trabajar con las imágenes contenidas. Sin embargo, existe otra operación que requiere polimorfismo, que no puede ser implementada de manera tan sencilla, ya que precisa de polimorfismo dinámico y en este caso Hibernate representa un problema, por la creación de proxies CGLib. 100

121 6.1 Descripción funcional La infraestructura de la aplicación, permite lanzar una operación de persistencia masiva sobre un conjunto de imágenes para que estas sean incluidas en un contenedor determinado. La aplicación está diseñada para que los usuarios investigadores, puedan ir enviando imágenes desde diferentes fuentes al servidor. Estas imágenes son almacenadas temporalmente en un espacio intermedio, que sirve para que los investigadores puedan examinar las imágenes previamente a su almacenamiento definitivo, con la finalidad de descartar aquellas que no cumplan los criterios de calidad que se establezcan. Una vez se hayan revisado las imágenes, los investigadores pueden solicitar el almacenamiento masivo de las imágenes que deseen en el contenedor que elijan. Es decir, la aplicación permite almacenar en una sola operación un conjunto de imágenes, por ejemplo en un Grupo. Obviamente, las imágenes deben contener información de filiación y demográfica, de otra forma la aplicación no puede conocer a que entidades subrogadas al grupo pertenecen. Por lo tanto, ante la petición de almacenamiento masivo de imágenes la aplicación debe conocer el tipo del contenedor destinatario y actuar en consecuencia, creando las entidades intermedias que se precisen, obteniendo de las imágenes la información necesaria, o generando un error en el caso de no existir o no estar disponible dicha información. Para poder implementar esta funcionalidad, ha sido necesario construir un Visitor, que resuelva en tiempo de ejecución el polimorfismo que Hibernate no satisface. Este Visitor, denominado PersistImagesVisitor es aceptado por cualquier entidad contenedora de imágenes y resuelve el tipo de contenedor por sobrecarga de operadores, en una clase de utilidades que implementa las operaciones específicas de persistencia para cada contenedor concreto. La clase abstracta ImageContainer, acepta la visita del objeto PersistImagesVisitor, como se ve en el listado 6.3. Cada especialización del ImageContainer implementa este método, invocando un método visit del Visitor, como se muestra en el listado 6.4, pasando como primer parámetro la referencia al objeto this. Ante esta petición, Java resuelve dinámicamente el tipo al que el proxy CGLib intenta suplantar, ya 101

122 Capítulo 6 Listing 6.3: Fragmento del código del ImageContainer 1 public abstract class ImageContainer extends DomainObject { public abstract void accept(persistimagesvisitor piv, 4 List<String> imagesid, String tempcol, Integer imgtype) 5 throws Exception; } que el método visit está definido múltiples veces, para cada especialización del ImageContainer. Por último, el objeto utils, al que recurre el visitor, pertenece a una clase de utilidad que implementa la operación de persistencia adecuada, invocando a los objetos DAO necesarios Contenido de las imágenes El objetivo de la persistencia de las imágenes es disponer de una copia exacta e inmutable de la imagen original que se adjuntó. El almacén de metadatos de las imágenes cubre la necesidad de persistir datos semi-estructurados de manera explotable. En este caso, también se ha buscado no generar dependencias en la aplicación sobre ninguna tecnología en particular y/o determinadas librerías software. Por ello, también se han diseñado interfaces en las que definir el contrato que deben cumplir los almacenes de imágenes y de metadatos. Para gestionar dichos almacenes, se ha recurrido al concepto de colección, de manera que por cada ensayo que se registre en la aplicación, se creará una colección de imágenes, así como una colección de metadatos. Dentro de cada colección, no habrá estructura ni agrupación por grupos, pacientes o estudios. Todas las imágenes estarán al mismo nivel dentro de la colección. Dado que en el almacén relacional se representa la jerarquía y pertenencia de las imágenes a uno u otro estudio, paciente o resultado. no se ha visto preciso 102

123 6.1 Descripción funcional Listing 6.4: Fragmento del código del PersistImagesVisitor 1 public class PersistImagesVisitor { 2 3 public void visit(trial imgcon, List<String> imagesid, 4 String tempcoll, Integer imgtype) throws Exception{ 5 6 Protocolable aux = protocolabledao.findbyid(... 7 utils.persistimagestrial(tempcoll, (Trial)aux,... 8 } 9 10 public void visit(group imgcon, List<String> imagesid, 11 String tempcoll, Integer imgtype) throws Exception{ Protocolable aux = protocolabledao.findbyid( utils.persistimagesgroup(tempcoll, (Group)aux, } } extender dicha complejidad para la colección de las imágenes. Además, hay que tener presente que el propósito de este almacén, es el de poder recuperar las imágenes intactas. Para la gestión de las colecciones de imágenes, se ha creado una interfaz denominada ImageContentCollection, que especifica las operaciones básicas de gestión de las colecciones, tal y como se puede observar en el listado 6.5. Esta interfaz define las operaciones de creación y borrado de colecciones, así como las operaciones de gestión del almacenamiento de contenido, es decir, de imágenes. Con la definición de esta interfaz se pretende independizar al resto de la aplicación de la implementación de la misma. Como ya se ha comentado en la sección , existen problemas en la sincronización de varios almacenes independientes, principalmente relacionados con la ejecución de transacciones separadas. Así pues, se aprecia la posibilidad de realizar cambios en el futuro relacionados con la in- 103

124 Capítulo 6 fraestructura de gestión del almacenamiento del contenido de las imágenes. Por esta razón, para evitar el impacto de este cambio, se define una interfaz independiente de la tecnología escogida para la gestión del almacén, que permita en un futuro, sustituir la actual implementación basada en la utilización de un sistema de ficheros, por otra. Listing 6.5: Fragmento del código de ImageContentCollection 1 public interface ImageContentCollection { 2 3 //Collection operations 4 public abstract void createcollection(string collection) 5 throws ImageCollectionException; 6 public abstract void deletecollection(string collection) 7 throws ImageCollectionException; 8 9 //Image operations 10 public abstract void storecontent(string collection, File content, boolean temporal) throws ImageCollectionException; 11 public abstract void deletecontent(string collection, String idcontent, boolean temporal) throws ImageCollectionException; 12 public abstract File loadcontent(string collection, String idcontent, boolean temporal) throws ImageCollectionException; 13 public abstract List<File> loadallcontents(string collection, boolean temporal) throws ImageCollectionException; 14 } La actual implementación del gestor de colecciones de contenido de imágenes, utiliza un path en un sistema de ficheros. Todas las operaciones relacionadas con la persistencia del contenido de las imágenes, son operaciones de entrada/salida de el sistema de ficheros que alberga el path de almacenamiento Metadatos de las imágenes El objetivo de la persistencia de los metadatos de las imágenes es disponer de una copia exacta e inmutable de la cabecera de la imagen original. Esto permite 104

125 6.1 Descripción funcional la explotación de la información de las cabeceras de las imágenes de manera eficiente. La información que se almacena en los metadatos puede ser de gran utilidad en un momento dado, tras una hallazgo inesperado, o para realizar algún filtro específico, que no había sido previsto en el diseño del ensayo. Las cabeceras de las imágenes pueden contener gran cantidad de información, que dado que no es fácilmente almacenable en un sistema relacional, suelen ser excluidas. Dado que en el almacén de contenidos se mantienen las imágenes intactas, sería factible recuperar la información de los metadatos de una imagen en cualquier momento, cargando el/los ficheros y obteniendo una representación en memoria de la misma. Sin embargo, lo que no es factible con esta operativa, es la búsqueda de imágenes que cumplen algún criterio, en sus metadatos. Sería muy costoso en tiempo. Una manera eficiente de poder recurrir a esta información, de manera explotable, esto es, permitiendo la ejecución de consultas sobre cualquier campo de los metadatos, pasa por el almacenamiento de esta información en XML, de manera que esta sea indexable y permita la ejecución de consultas xpath. El listado 6.6, muestra la interfaz que define las operaciones que debe soportar la clase que implemente esta funcionalidad. De nuevo aquí, al igual que en el resto del trabajo y en especial, al igual que en el apartado anterior, se busca independizar al resto de la infraestructura de la implementación específica para la gestión de las colecciones XML de metadatos. Al igual que en el ejemplo de la colección para el contenido de las imágenes, existen dos operaciones para la creación y borrado de colecciones, además las operaciones propias de gestión de los metadatos de una colección Gestión conjunta del almacenamiento Teniendo en mente los problemas comentados en la sección , se ha creado una clase que implementa la gestión de las dos colecciones mencionadas, la de contenido y la de metadatos. Esta clase, es un broker, que sabe como gestionar las colecciones actuales, dado que estas no están sincronizadas. 105

126 Capítulo 6 Listing 6.6: Fragmento del código de ImageXMLCollection 1 public interface ImageXMLCollection { 2 3 //Collection operations 4 public abstract void createcollection(string collection) 5 throws ImageCollectionException; 6 public abstract void deletecollection(string collection) 7 throws ImageCollectionException; 8 9 //Image Operations 10 public abstract void storenode(string collection, String idnode, 11 Node node) throws ImageCollectionException; 12 public abstract void deletenode(string collection, String 13 idnode) throws ImageCollectionException; 14 public abstract List<String> findnodes(string collection, 15 List<Attribute> criteria); 16 } Si bien esta clase no presenta dependencias sobre la implementación de cada una de las colecciones mencionadas, si presenta funcionales porque asume que dichas colecciones no están sincronizadas. Por lo tanto presentaría resistencia al cambio, en el caso de sustituir las tecnologías actuales de gestión de colecciones por otras que si estuvieran sincronizadas. La razón de esta decisión de diseño, radica en que se ha pretendido crear un cortafuegos para este problema, de manera que todas las dependencias funcionales, derivadas de la actual implementación, quedaran recogidas en una clase. Así, el resto de la infraestructura desconoce totalmente las peculiaridades acercar de la gestión de las colecciones y por lo tanto es realmente independiente. Como se puede ver en el listado 6.7, algunos métodos, como el de creación de colecciones, incorporan bloques try/catch para realizar de una manera pseudosíncrona las acciones de gestión de colecciones. Si la tecnología subyacente permitiera la sincronización de las transacciones de estos recursos, este código sería innecesario, pero de no haber creado esta clase, este código estaría repartido por 106

127 6.2 Ejemplo de uso en escenario real Listing 6.7: Fragmento del código de ImageCollectionManager 1 public class ImageCollectionManager { 2 private ImageContentCollection imcc = null; 3 private ImageXMLCollection imxc = null; 4 5 public void createcollection(string colname) throws... { 6 try { 7 imxc.createcollection(colname); 8 imcc.createcollection(colname); 9 } catch (ImageCollectionException ice) { 10 imxc.deletecollection(colname); 11 imcc.deletecollection(colname); 12 throw ice; 13 } 14 } } diferentes lugares, complicando una futura sustitución de tecnologías de gestión de colecciones Ejemplo de uso en escenario real Una vez descrita la aplicación desde un punto de vista funcional, el objetivo de esta sección es mostrar un caso de uso real, en el que la aplicación ha sido utilizada con éxito, como prueba de validación de los objetivos planteados en el presente trabajo. No se pretende que esta sección sea tan exhaustiva como un manual de usuario, ya que ese es el propósito del Apéndice A. Por lo tanto, en esta sección se mencionarán aquellas áreas más representativas y se acompañaran de capturas de pantallas que demuestren la utilidad de las mismas. A lo largo de esta sección se harán continuas referencias a secciones específicas de la descripción funcional de este capítulo y del Apéndice A, cuando 107

128 Capítulo 6 sea preciso explicar alguna funcionalidad o algún detalle específico de la interfaz gráfica. En esta sección se describirá también el entorno de ejecución y backup en el que está desplegada la instancia de la aplicación que gestiona el ensayo comentado Descripción del ensayo clínico gestionado El proyecto DEMCAM (Demencias en la Comunidad de Madrid), es un estudio transversal que pretende estudiar los diferentes estadios de la enfermedad de Alzheimer. Para llevar a cabo este proyecto, se recoge una muestra de 160 sujetos, repartidos en 40 sujetos controles sanos, 40 deterioros cognitivos leves amnésicos, 40 deterioros cognitivo leves multidominio y 40 enfermos de Alzheimer. La muestra se recluta entre todos los servicios de Neurología de la Comunidad de Madrid. Los pacientes son estudiados con pruebas neurológicas, neuropsicológicas y pruebas de imagen por resonancia. Las pruebas de neuroimagen contemplan adquisiciones anatómicas de alta resolución, estudios de tractografía y tensor de difusión, estudios de espectroscopía y estudios de perfusión sin contraste endovenoso arterial spin labeling. Como resultado, este proyecto permite estudiar la evolución anatómica y funcional del cerebro en los diferentes estadios de la patología Administración del ensayo Desde el área de administración de la aplicación se han realizado las operaciones de creación del ensayo, de registro y alta de los usuarios participantes, de creación y asociación a cada usuario de los roles necesarios para su participación en el ensayo y de configuración de los elementos necesarios para la posterior configuración del protocolo del ensayo clínico, esto es, los tipos de procesos, los tipos de imágenes y las modalidades de adquisición de imagen para las que se habilitará la recepción de imágenes vía protocolo DICOM. 108

129 6.2 Ejemplo de uso en escenario real Figura 6.7.: Administración de los ensayos clínicos Administración de usuarios y roles Como se puede ver en la figura 6.7, en la herramienta se han registrado varios ensayos clínicos, entre los que se encuentra el ensayo que servirá para ejemplificar el uso de la herramienta. En la figura 6.8 aparecen todos los usuarios registrados que participan en el ensayo con un rol predeterminado. Los roles disponibles en la herramienta son configurables, pudiéndose modificar las acciones autorizadas, incluso pudiéndose crear nuevos roles Administración de modalidades, procesos y tipos de imágenes En la figura 6.9 se observa la pantalla de gestión de procesos, en la que se registran los tipos de procesos que los investigadores llevarán a cabo sobre las imágenes del ensayo clínico. Tal y como se explica en la sección Entidades protocolables y tareas, estos tipos de procesos serán utilizados en los protocolos de manera que cuando se inserten nuevas imágenes a una entidad con protocolo definido, se 109

130 Capítulo 6 Figura 6.8.: Administración de los usuarios del ensayo. creará una nueva tarea del proceso especificado, si concuerda el tipo de imagen del protocolo con el de la o las imágenes que están siendo asociadas a la entidad. Respecto de la gestión de los tipos de imágenes, véase la figura Área de investigación Área de protocolables: ensayo, grupos, pacientes y estudios Dentro del área dedicada a la gestión propia del ensayo, se pueden observar las interfaces gráficas para trabajar con las entidades protocolables y/o contenedoras de imágenes. La funcionalidad propia de estos elementos, junto con la gestión de las tareas, está explicada en la sección Entidades protocolables y tareas. En la sección A.3.2 del Apéndice A, se detalla la operativa de los elementos de la interfaz gráfica con mucho detalle. En la figura 6.11, se pueden observar los diferentes grupos que se han registrado en el ensayo clínico. Dentro de cada grupo se agrupan sujetos y dentro de estos, se agrupan estudios, como se puede observar en la composición gráfica mencionada. 110

131 6.2 Ejemplo de uso en escenario real Figura 6.9.: Administración de los tipos de procesos. En la figura 6.12, se puede observar un protocolo de ejemplo, correspondiente a uno de los grupos del ensayo. Este protocolo lista los distintos procesos, de los que se crearán automáticamente tareas, cuando se asocien directa o indirectamente imágenes a este contenedor y el tipo de imagen asociada, corresponda con el tipo indicado en cada línea del protocolo. Otros elementos que se configuran en el protocolo, son el usuario al que por defecto se le asigna la tarea y la duración aproximada que debe tener la tarea para su resolución Gestión de tareas y resultados En la figura 6.13, se pueden observar diferentes pantallas en las que un investigador accede a sus tareas pendientes, descarga las imágenes asociadas a la tarea y comenta progresos en la resolución de la misma. 111

132 Capítulo 6 Figura 6.10.: Administración de los tipos de imágenes. Figura 6.11.: Gestión de elementos protocolables y contenedores de imágenes. 112

133 6.2 Ejemplo de uso en escenario real Figura 6.12.: Protocolo de ejemplo de un grupo del ensayo. Figura 6.13.: Tareas pendientes de un usuario. 113

134 Capítulo 6 Figura 6.14.: Composición de capturas relativas al movimiento y borrado de pacientes Movimiento, borrado de pacientes y eliminación de resultados Estas funcionalidades están convenientemente explicadas en la sección A Se muestran aquí, en la figura 6.14, algunos ejemplos de pacientes que permiten ser movidos de grupo y eliminados. Se muestran también casos en los que la aplicación advierte de la imposibilidad de realizar la operación solicitada. En los casos en los que no se permite la operación de movimiento o borrado, es preciso proceder manualmente, eliminando aquellos resultados que impiden la operación Entorno de explotación El ejemplo anteriormente comentado es ejecutado en una instancia de la aplicación, que está albergada en un solo servidor alojado en la Fundación Reina Sofía. Las características técnicas del servidor son las siguientes: 114

135 6.2 Ejemplo de uso en escenario real Procesador Memoria Controladora Discos Red Componentes de Airen Intel(R) Xeon(TM) CPU 3.60GHz, de doble núcleo kb. Compaq Computer Corporation Smart Array 64xx. 2 discos de 147 gb. 2 controladoras Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet. El sistema operativo que gestiona esta máquina es Ubuntu Server Esta versión está un tanto desfasada, pero conviene recordar que esta aplicación se encuentra en ejecución desde el año Esta máquina tiene configurados los servicios de front-end HTTP, contenedor de aplicaciones y base de datos, tal y como se muestra en la figura 5.3, pero en una misma máquina. Las versiones del software utilizado son: Apache HTTP Server: Apache Tomcat: Apache AJP Connector: PostgreSQL: La instalación se ha realizado tal y como se indica en el procedimiento del manual de instalación, en la sección A.5 - How to install the application Backup Para la configuración del backup de este servicio, se ha recurrido a una solución manual que se apoya en tres elementos: Un conjunto de scripts que obtienen las copias de seguridad de la base de datos relacional, de la base de datos xml y de las imágenes. Dos tareas programadas mediante el sistema cron: Una diaria que lanza una copia total a un directorio del servidor. 115

136 Capítulo 6 Otra semanal que vuelca la última copia semanal a un disco externo. Un disco externo que tiene 5 particiones en las que se alternan las copias semanales, permitiendo una retención de un mes y una semana. La capacidad de almacenamiento del servidor es de 500 Gb. El disco duro externo de copia de seguridad tiene una capacidad de 3 Tb, por lo que se han podido crear 5 particiones para la rotación de copias semanales. El disco duro externo es replicado fuera del centro, de manera totalmente manual y con una periodicidad irregular. 116

137 7. Conclusiones Como se desprende del capítulo de resultados, se han cumplido los objetivos del trabajo. Se ha creado una plataforma de gestión de ensayos clínicos basados en imagen médica, que es independiente del formato de representación de imagen, que soporta las funciones de comunicación del estándar DICOM y que permite la conversión entre los diferentes formatos soportados, así como poder exportar resultados a un PACS utilizando el mecanismo DICOM de captura secundaria. La solución implementada está basada en Software Libre y está publicada como tal. La implementación persigue un diseño abierto y operativo que sea fácilmente extensible y que favorezca posibles colaboraciones en su desarrollo. No se han obviado las funciones de gestión de ensayos y usuarios, ni tampoco aquellas relacionadas con la autorización y auditoría de los procesos que se realizan. Lo más importante de la solución ofrecida, es la gestión de los protocolos de gestión de la imagen médica en los ensayos y la gestión de las tareas y procesos, tal y como se han mostrado en el capítulo de resultados. Estas funciones son las que marcan las diferencias con el resto de proyectos que intentaban abordar la problemática de la gestión de la imagen en los ensayos clínicos, y precisamente son las que permiten garantizar un aspecto fundamental en cualquier tipo de ensayo clínico, la replicabilidad de los experimentos Discusión El presente proyecto ha tenido una duración de casi 6 años, principalmente debido a que el doctorando no ha podido tener una dedicación exclusiva al proyecto, 117

138 Capítulo 7 aunque tampoco hay que obviar la envergadura del proyecto. El estado del arte de determinadas tecnologías ha evolucionado mucho en este tiempo, es por eso, que una revisión crítica de determinadas soluciones, puede ofrecer nuevas formas de abordar algunos de los problemas resueltos. Este es el caso de una las partes más importantes, la gestión del almacenamiento, punto que se abordará con mayor detalle. También se comentará en esta sección se algunas ideas y conceptos que no han podido ser abordados, pero para los que se presentan opciones de futuro muy interesantes. Conviene destacar, que estas apreciaciones son posibles una vez que el proyecto ha alcanzado el nivel de madurez actual, ya que la experiencia obtenida con su desarrollo, permite al doctorando explorar nuevas posibilidades, que inicialmente resultaban desconocidas Discusión sobre los tres tipos de almacenamiento Como ya se avanzó en la sección Infraestructura para el almacenamiento de datos, existen algunos inconvenientes con respecto a la solución escogida para implementar las necesidades de almacenamiento y persistencia. El inconveniente más destacable es el riesgo de inconsistencia, ya que aunque se ha procurado minimizar los efectos negativos derivados de la carencia de un entorno totalmente transaccional, existen escenarios en los que los diferentes almacenes pueden quedar inconsistentes. Como ya se apuntara en la sección 5.3.2, una posible solución consistiría en la aplicación del proyecto XADisk, que en la actualidad es un proyecto maduro y consolidado. Sin embargo, para asegurar una total consistencia entre los tres almacenes diferentes, no basta con aplicar XADisk, sino que habría que aplicar algún gestor de transacciones extendidas o utilizar contenedores de aplicaciones especializados. Esto se debe a que el proyecto XADisk ofrece la posibilidad de trabajar de manera transaccional con un sistema de ficheros, pero es preciso coordinar las diferentes transacciones (la del gestor relacional, la del gestor de base de datos XML y la de XADisk), tal y como se define en XA Transactions o transacciones extendidas [69]. 118

139 7.1 Discusión Otra posibilidad, que tampoco era viable tecnológicamente al inicio del proyecto, consiste en utilizar un único almacén de datos. Postgres ha evolucionado mucho, al igual que otros gestores privativos, en la gestión tanto de archivos XML como de datos binarios o BLOB s. Esto hace posible la utilización de un único gestor en el que tratar convenientemente cada tipo de dato. Como ventaja añadida, esta solución simplifica mucho la gestión posterior de las copias de seguridad. En cualquier caso, cualquiera de las posibles mejoras debe ser evaluada cuidadosamente, pues las consecuencias de una aplicación incorrecta podrían ser importantes. No obstante las modificaciones necesarias al código fuente no serían tan complejas de acometer, pues la capa de persistencia esta bien diseñada y presenta pocos acoplamientos, por lo que no ofrecería demasiada resistencia para acometer el refactor Explotación de los metadatos En la gestión del almacenamiento de metadatos, se ha utilizado un gestor de documentos XML que permite indexar y explotar los documentos que convenientemente convertidos a XML, representan la información de las cabeceras y metadatos de las imágenes y series almacenadas. Sin embargo, este almacén no es explotado en la actualidad por que la priorización de las funcionalidades a desarrollar ha hecho que el enfoque en el esfuerzo de desarrollo, se centrara más en la gestión de los ensayos. Ahora bien, las posibilidades que ofrece este almacén son muy variadas, puesto que mediante consultas xpath, es posible realizar buscar imágenes que satisfagan criterios basados en la metainformación de sus cabeceras, por ejemplo, por la versión del software de la modalidad de adquisición o por los parámetros del proceso de captura. Con muy poco esfuerzo, es posible construir una apartado de interfaz de usuario en el que poder explotar la información de metadatos, ya que esta está vinculada tanto con la información relacional, como con las imágenes originales. Las posibilidades que ofrece este almacenamiento son muy grandes y es una vía nueva por explorar. 119

140 Capítulo Automatización de pipelines Otra mejora interesante para este proyecto es la que se deriva de la posibilidad de integrar y/o automatizar cadenas de procesamiento de imágenes (o pipelines). Esta mejora iría muy ligada a la gestión del flujo de trabajo de tareas y resultados, ya que permitiría la automatización de la realización de determinados procesos. Esta automatización podría ser realizada bien mediante la integración de un software de terceros, como Octave o Matlab, bien por el desarrollo de un sistema de plugins que permitiera la inclusión de clases Java especializadas en el tratamiento de imagen médica o bien mediante la inclusión de un lenguaje de programación propio que permita el desarrollo de scripts propios de procesamiento de imágenes. Esta última opción, la inclusión de un lenguaje de programación propio, es una realidad que el doctorando está aplicando en otro proyecto software de tratamiento de información dosimétrica a pacientes. Mediante JavaCC y JJTree se ha construido un parser y un interprete que permite automatizar el tratamiento de imágenes DICOM con la finalidad de extraer la dosis efectiva (en msievers) que recibe un paciente con cada prueba o tratamiento que suponga un evento de radiación 1. Con la aplicación de un lenguaje propio, se podrían crear cadenas de procesamiento totalmente configurables y adaptadas a las necesidades del ensayo. Además este lenguaje podría ser usado para controlar otros aspectos de la aplicación, que actualmente son estáticos y dependen de decisiones del usuario, como por ejemplo la determinación del tipo de imagen o el cierre automático o no de una tarea Integración con otras plataformas Una última vía de expansión del presente proyecto podría ser la del desarrollo de interfaces de comunicación con otras redes de investigación como LONI, BIRN o cagrid. Esto permitiría la exportación de los datos de los proyectos gestionados 1 El código fuente de este proyecto está albergado de manera pública, al igual que el presente trabajo, en bitbucket. La url del mismo es 120

141 7.1 Discusión con esta herramienta, así como la integración del proyecto con estas extensas redes, lo que permitiría la realización de operaciones de búsqueda de datos y/o material proveniente de otros proyectos integrados en estas redes. El desarrollo de estas interfaces tampoco estaría exento de complejidad, pues los requisitos de las mismas no son triviales. 121

142

143 Bibliografía [1] H. K. Huang, Pacs is only in the beginning of being used as a clinical research tool, Biomed Imaging Interv, vol. 3, pp. e12 41, Jan [2] S. G. Erberich, M. Bhandekar, M. D. Nelson, A. Chervenak, and C. Kesselman, Dicom grid interface service for clinical and research pacs: A globus toolkit web service for medical data grids, Int J Comp Assist Radiol Surg, vol. 1, no. 87, pp , [3] D. B. Keator, J. S. Grethe, D. Marcus, B. Ozyurt, S. Gadde, S. Murphy, S. Pieper, D. Greve, R. Notestine, H. J. Bockholt, and P. Papadopoulos, A national human neuroimaging collaboratory enabled by the biomedical informatics research network (birn), IEEE Trans Inf Technol Biomed, vol. 12, pp , Mar [4] D. S. Marcus, T. R. Olsen, M. Ramaratnam, and R. L. Buckner, The extensible neuroimaging archive toolkit: an informatics platform for managing, exploring, and sharing neuroimaging data., Neuroinformatics, vol. 5, pp , March [5] S. Weber, Nosql databases, Master s thesis, University of Applied Sciences HTW Chur, [Last accessed: 3 Dec 2011]. [6] National Electrical Manufacturers Association, Digital Imaging and Communications in Medicine (DICOM) [7] H. K. Huang, PACS and Imaging Informatics: Basic Principles and Applications. Wiley-Liss, Apr [8] Ministerio de Sanidad y Consumo, Las TIC en el Sistema Nacional de Salud. Scan96,

144 [9] F. J. Cabrero Fraile, Imagen Radiologica. Principios fisicos e instrumentacion. Elsevier, [10] NIH Definitions Work Group, Biomarkers and surrogate endpoints in clinical research: definitions and conceptual model. Amsterdam: Elsevier, [11] D. P. Schuster, The opportunities and challenges of developing imaging biomarkers to study lung function and disease., Am J Respir Crit Care Med, vol. 176, pp , Aug [12] J. K. Aronson, Biomarkers and surrogate endpoints., Br J Clin Pharmacol, vol. 59, pp , May [13] B. J. Erickson and J. C. Buckner, Imaging in clinical trials., Cancer Inform, vol. 4, pp. 13 8, [14] J. Darrell, V. Horn, and A. W. Toga, Is it time to re-prioritize neuroimaging databases and digital repositories?, Neuroimage, vol. 47, pp , Oct [15] W. C. Robert, A. John, B. Hester, F. Kate, H. Christian, J. H. Colin, L. L. Jack, E. R. David, M. S. Stephen, B. W. Jeffrey, and S. S. C., A (sort of) new image data format standard: Nifti-1, in 10th Annual Meeting of the Organization for Human Brain Mapping, vol. 25, OHBM, June [16] K. Clark, D. Gierada, G. Marquez, S. Moore, D. Maffitt, J. Moulton, P. Wolfsberger, M.and Koppel, S. Phillips, and F. Prior, Collecting 48,000 ct exams for the lung screening study of the national lung screening trial, Journal of Digital Imaging, vol. 22, no. 6, pp , [17] American College of Radiology, Uniform protocols for imaging in clinical trials., Clinical & Translational Science Awards, [18] W. Bennett, D. Spigos, K. Vaswani, and J. Terrell, Cable modem access to picture archiving and communication system images using a web browser over the internet, Journal of Digital Imaging, vol. 13, pp , /BF [19] S. Saini, T. T. Zacharia, and J. J. Sumner, Picture archiving and communication systems applied to clinical trials, Applied Clinical Trials, 2 Feb

145 Bibliografía [20] Z. Zhou, B. J. Liu, and A. H. Le, Cad-pacs integration tool kit based on DICOM secondary capture, structured report and ihe workflow profiles., Comput Med Imaging Graph, vol. 31, no. 4-5, pp , [21] J. A. Maldjian, J. Listerud, and S. Khalsa, Integrating postprocessed functional mr images with picture archiving and communication systems, AJNR Am J Neuroradiol, vol. 23, no. 8, pp , [22] C. C. Lim, G. L. Yang, W. L. Nowinski, and F. Hui, Medical image resource center making electronic teaching files from pacs., J Digit Imaging, vol. 16, pp , December [23] A. Gentili, C. B. Chung, and T. Hughes, Informatics in radiology: use of the mirc dicom service for clinical trials to automatically create teaching file cases from pacs., Radiographics, vol. 27, no. 1, pp , [24] IHE International, Inc., IHE Radiology Technical Framework [25] J. Jomier, S. Aylward, C. Marion, J. Lee, and M. Styner, A digital archiving system and distributed server-side processing of large datasets, Proc. SPIE, vol. 7264, [26] R. T. Fielding, D. Software, and R. N. Taylor, Principled design of the modern web architecture, ACM Transactions on Internet Technology, vol. 2, pp , [27] I. Foster and C. Kesselman, The Grid: Blueprint for a New Computing Infrastructure (The Elsevier Series in Grid Computing). Morgan Kaufmann, [28] A. Fuentes, J. L. Vázquez, E. Huedo, R. S. Montero, and I. M. Llorente, Beneficios del uso de la tecnología grid computing en bioinformática. usando la infraestructura de irisgrid, Boletin de RedIRIS, vol. 1, pp , Apr [29] A. L. Rowland, M. Burns, T. Hartkens, A. L. Hajnaland, D. Rueckert, and D. L. G. Hill, Information extraction from images (ixi): Image processing workflows using a grid enabled image database, DiDaMIC Workshop - MIC- CAI, [30] R. Bremer, J. Perez, P. Smith, and P. Westfall, Grid computing at texas tech 125

146 university using sas, in 14th Annual South-Central SAS User s Group Regional Conference, pp , [31] cabig Strategic Planning Workspace, The cancer biomedical informatics grid (cabig): infrastructure and applications for a worldwide research community., Stud Health Technol Inform, vol. 129, no. Pt 1, pp , [32] J. Saltz, S. Oster, S. Hastings, S. Langella, T. Kurc, W. Sanchez, M. Kher, A. Manisundaram, K. Shanbhag, and P. Covitz, cagrid: design and implementation of the core architecture of the cancer biomedical informatics grid, Bioinformatics, vol. 22, pp , August [33] A. Wiley and C. Meenan, National biomedical imaging archive (nbia). web, January [34] J. Pearson, L. Tarbox, G. Paladini, J. G. Wolodzko, P. M. Jacobs, and Z. Lee, Quantitative Imaging Tools for Lung Cancer Drug Assessment, ch. 5, pp Wiley-OSA, [35] A. W. Toga, The laboratory of neuro imaging: what it is, why it is, and how it came to be., IEEE Trans Med Imaging, vol. 21, pp , Nov [36] I. Dinov, L. Kamen, P. Petros, E. Zhizhong, L. andpaul, P. Jonathan, Z. Alen, C. Shruthi, J. Van Horn, D. S. Parker, R. Magsipoc, K. Leung, B. Gutman, R. Woods, and A. Toga, Neuroimaging study designs, computational analyses and data provenance using the loni pipeline., PLoS One, vol. 5, no. 9, [37] A. K. Sharib, R. O. Philip, M. P. Payne, J. T. Jhonson, S. B.and Bigger, and R. Kukafka, Modeling clinical trials workflow in community practice settings, AMIA 2006 Symposium Proceedings, pp , [38] J. A. Hernandez, C. J. Acuna, M. de Castro, E. Marcos, M. Lopez, and N. Malpica, Web-pacs for multicenter clinical trials, Information Technology in Biomedicine, IEEE Transactions on, vol. 11, pp , January [39] Workflow Management Coalition, The workflow management coalition terminology and glossary. Feb

147 Bibliografía [40] R. S. Pressman, Software Engineering: A Practitioner s Approach (Mcgraw-Hill Series in Computer Science). McGraw-Hill Science/Engineering/Math, [41] W. W. Royce, Managing the development of large software systems: concepts and techniques, in Proceedings of the 9th international conference on Software Engineering, ICSE 87, (Los Alamitos, CA, USA), pp , IEEE Computer Society Press, [42] J. McDermid, Software Engineer s Reference Book, ch. Software Development Process Models, pp CRC, [43] J. Martin, Rapid Application Development. Macmillan Coll Div, [44] T. Gilb, Principles Of Software Engineering Management. Addison-Wesley Professional, [45] B. Bohem, The spiral model as a tool for evolutionary acquisition, in crosstalk, [46] I. Jacobson, G. Booch, and J. Rumbaugh, The Unified Software Development Process. Addison-Wesley Professional, [47] M. Fowler, The agile manifesto, Software Development Magazine, vol. 1, [48] I. Jacobson, A resounding yes! to agile processes but also to the next big thing, The Rational Edge, [49] K. Schwaber and M. Beedle, Agile Software Development with Scrum (Series in Agile Software Development). Prentice Hall, [50] K. Beck, Extreme Programming Explained: Embrace Change. Addison-Wesley Professional, [51] J. Benson and T. Barry, Personal Kanban Mapping Work Navigating Life. Modus Copperandi Press, [52] A. Hemrajani, Agile Java Development with Spring, Hibernate and Eclipse. Indianapolis: Developer s Library, [53] B. Tate, Better, Faster, Lighter Java. Sebastopol: O Reilly, [54] R. C. Martin, Design principles and design patterns. on-line,

148 [55] C. Bauer, Java Persistence with Hibernate. Greenwich: Manning Publications, [56] R. Sears, C. Van Ingen, and J. Gray, To blob or not to blob: large object storage in a database or a filesystem?. research microsoft, Apr [57] I. Giangreco, Cap theorem, Master s thesis, University of Basel, [Last accessed: 3 Dec 2011]. [58] N. Samokhalov, Xml support in postresql, in Spring young researcher s collquium on databases and Information System, (Moscow), [59] C. Walls, Spring in Action. Greenwich: Manning Publications, [60] M. Fowler, Inversion of control containers and the dependency injection pattern. [61] D. Geary, Core Javaserver Faces. Englewood Cliffs: Prentice Hall, [62] E. Burns, Javaserver Faces 2.0, the Complete Reference. City: McGraw-Hill Osborne Media, [63] E. Gamma, Design Patterns. Boston: Addison-Wesley, [64] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier, and J. Irwin, Aspect-oriented programming, in In Proceedings of the European Conference on Object-Oriented Programming (ECOOP, pp , Springer, [65] JavaSoft, Java core reflection api and speci cation. online publishing, Jan [66] P. Leach, M. Mealling, and R. Salz, A universally unique identifier (uuid) urn namespace, IETF RFC 4122, [67] J. Zukowski, Java 6 Platform Revealed. Berkeley: APress, [68] A. Vazquez, S. Bohn, and M. Gessat, Evaluation of open source dicom frameworks, MCIM Workshop 2007 Proceedings, pp. C 10, [69] M. Richards, Java Transaction Design Strategies. City: Lulu.com,

149 A. User Manual The author provides this information on an as-is basis. The author makes no warranties regarding the information provided, and disclaims liability for damages resulting of its use. MCTWP Manual by Miguel Ángel Laguna Lobato is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. To view a copy of this license, visit licenses/by-nc-sa/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA. A.1. Introduction and quickstart Multiclinical Trial Web PACS (MCTWP) is a work in progress, to develop a software platform that manages medical images in clinical trials. This project is hosted on and it is licensed under GPLv3 1. You can test this application easily, using a virtual machine that we have created for this purpose. This virtual machine can be played with VMWare Player, or with other VMWare programs such as ESXi. VMWare player is free of charge, and you can get it from If you want to test the 1 General Public License, 129

150 Anexo A application right now, you can go directly to section A.2, but we recommend you first read section A.1.1, and take a look to section A.3. A.1.1. What is this? Medical imaging-based clinical trials are a growing approach in drug testing and clinical research, but usually, they are not being managed with a proper information system. Sometimes, PACS 2 have been used to store and manage images, but they are not a good solution for the research workflow because this kind of systems are tied to the healthcare workflow. Clinical trials have a protocol that describes all activities and procedure steps of the trial. Images are usually used as inputs to image processing tasks and/or results, thus, it is important to have the system manage the complete protocol. When no information system is applied to manage clinical trials, it is hard to support the clinical trial protocol. In such a scenario, images are dispersed in several media formats such as external hard disk, DVD s, laptop computers and so on. Thus, it is very difficult to track task and protocols. There is another important aspect of clinical trials. Sometimes it is necessary to repeat some process in order to check some results, test a new technique or processing method. If images are not properly stored and managed, it is not possible to repeat these experiments, because there is no robust way of retrieving the exact original images of the trial. We have developed a software platform that supports image and protocol management, with the following main functionality: Establishing a quality control process. When several organizations participate in a clinical trial, it is necessary to review all images received before they are accepted, in order to check that every image fulfills all requirements. Storing and classifying images. Once an image is accepted, it has to be added to the clinical trial. A typical trial stores images into patient studies, and patients into groups, thus it is necessary to identify a given patient. 2 Picture Archiving and Communication Systems, see DICOM standard. 130

151 A.1 Introduction and quickstart Figura A.1.: Entity model. Boxes are shaded in gray for simplicity. Supporting basic workflow. Images of a clinical trial are processed by means of algorithms that extract data or obtain new graphical representations. These algorithms are tasks that researchers must complete orderly by means of a established protocol. Ensuring traceability and replicability in the experiments and measurements. Input images can not be deleted once task results are added to them. It is also possible to retrieve the source images and the processes associated to every result. 131

152 Anexo A A Data model and workflow The main entities in clinical trials are depicted in figure A.2. Briefly, the application manages trials that contain groups. Every group contains patients, and these contain studies. Images are stored into studies, and every image can be part of a task. Researchers perform tasks and record results. The complete entity model of the application business are showed in figure A.1, but it does not include all entities that manage roles, audit, log and authorization, because this would make the diagram very complex. This model allows the application to support trial workflow. Researchers can manage images, tasks and results using the entities that support the trial protocol. These entities are the following: ProcessDef. This entity defines a kind of image processing technique that could be applied to any type of image. Researchers can define here not only the name of the process, but a brief help and description and a time limit to do a task of this kind. Examples of this entities are: a) inhomogeneity correction, b) tissue segmentation, c) normalization,... ImageType. This entity defines a kind of image. It is not related to image format representation, but to the image functionality in the trial. For example: a) structural images, b) functional images, c) diffusion images,... Protocolable and Process. Protocolable is an abstract entity, that relates Process- Def instances with any of the specialized classes. This is useful to automatically create tasks when new images are added to any of this containers. A task of a specific process is created automatically when images added match the image type defined. Task and TaskLog. These entities allows researches to manage their daily work. The different processing tasks can be carried out by one single researcher or by a group of researchers. All changes to a task are properly traced down. 132

153 A.1 Introduction and quickstart Once tasks are completed, researchers obtain results such as quantitative measures on the individual images, population statistics or even new images. In any case, that result must be registered, and this is done by means of the Result entity, which can store images or any kind of file containing statistical data. Figura A.2.: Workflow and quality control. The application allows any authorized user to delete or modify images if there are no results registered to any task of the images. When results are registered, the application controls that source images remain unmodifiable. This feature, together with task traceability, allow this application to ensure replicability of experiments. A Internal image representation and management As mentioned above, a set of abstract classes has been designed, as depicted in figure A.3, to deal with image representation and management, in such a way that they are independent from image format and underlying technology. There are four abstract representations of an image, each one corresponding a particular case of image types, that must be specialized to implement a concrete image format. The application knows how to deal with abstract images, and it delegates format dependent operations into specialized classes. Abstract class Image is specialized by three abstract classes too, that are the following: SingleImage, which represents all type of images that are contained into a single file. 133

154 Anexo A Figura A.3.: Image management model. Pink entities represent the Analyze specialization. 134

155 A.1 Introduction and quickstart ComplexImage, which represents all type of images that need several files to be represented, but are not series of images. For example, an image composed by two files, one representing header information, and another containing pixel data. SeriesImage, which represents all type of images that are grouped into series of images. In this case, every image of the series can be a SingleImage or a ComplexImage, even a SeriesImage. Obviously these classes do not implement any specific information about any image format or standard. They must be specialized to implement the necessary code that supports an image format. For example, figure A.3, shows how two specific implementations of SingleImage and ComplexImage support Analyze and Nifti 3 file format. Analyze images can be represented by means of two files, header information and content (voxels), or a single file. A Image management The application needs to manipulate images using specific standard operations, such as loading images, obtaining demographics data, converting between formats, and so on. To decouple this operations from the application, the interface ImagePlugin is used. This interface, as shown in figure A.3, declares all operation that must be implemented for every specific standard. We denote by image plugin every class implementing this interface. As the application has to deal with several image plugins, an image plugin manager is defined. The application asks for standard specific operations from the manager who has the responsibility of forwarding the request to the proper image plugin. An abstract class, called ImagePluginDefaultImpl, solves common problems that are not dependent of image format. For example, it is desirable to use our own image identifiers instead of specific ones, but there is a problem with image series and 3 Nifti is an image standard that is compatible with Analyze, but extends its funcionalities. 135

156 Anexo A complex images. This has been solved using an identifier mapper, that matches specific image id s with our own id s. A Storage management This application has to fulfill several purposes that require more than just a relational database. On one hand, it is necessary to store all relational information about model entities, such as users, trials, patients, tasks, results, etc. On the other hand it is necessary to store the original images. There are controversies about storing files into relational databases. Some studies conclude that several factors must be taken into account. It seems there is a threshold on file size that makes the difference. When files are bigger than 1 Mb, storing files in relational databases is worse than file system. Obviously, although relational databases have perform worst than file systems, they have other advantages, for example, Figura A.4.: Storage architecture. they ease backup policies and ensure data integrity, because files are in the scope of transactions. But something more than a simple image storage system is needed. Every image format has its own meta information about modality, acquisition parameters, facility, demographics,... This information can be helpful, and it is worth not only storing it, but allowing the user to search into this information. As this information is not suitable for relational data bases 4, it is necessary to use a different storage 4 Because it is not well structured information, and it is not the same between standards. 136

157 A.1 Introduction and quickstart technology. For this reasons we chose three different storage systems: Image collection storage Here images remain unmodifiable, and they are grouped into collections. A collection represents a single clinical trial. It has no implication on image storage location, it simply means that images must be retrieved by its application id. Meta information collection storage XML databases are good at storing semi-structured data sets. It doesn t matter what XML database is selected, but it must support xpath queries in order to search for images. Here, all images must be indexed at least by their application ID. Relational database All information about trials, groups, tasks, protocols, patients, results, etc., are stored into a relational database management system. Images are not contained into the relational model, but their application ID is. This way it is possible to coordinate all three parts. The main advantage of this idea is its versatility. It is possible to request from the application images satisfying any meta data criteria, and to obtain the original images, at any moment. But obviously this requires to maintain the three parts synchronized. A Image acquisition The application supports two ways to acquire images, through a HTTP request and through a DICOM C-STORE transaction. A Java Applet allows to send several files at once using HTTP file upload support. On the other hand, a super server listener waits for DICOM transactions. While the first option allows to send an image of any type, the second one only supports DICOM images. The DICOM infrastructure for implementing C-STORE transactions is not dependent on any specific project or library, so it is possible to include different 137

158 Anexo A implementations. 138

159 A.2 Play it! A.2. Play it! If you want to test the virtual machine, you must have a VMWare product able to run vmx files. You can use VMWare Server, ESX/ESXi or vsphere. But if you don t have this infrastructure, or you just want to test it on your laptop you can use VMWare Player, VMWare Fusion or WorkStation. VMWare Player is free of charge, and it runs on GNU/Linux, Macintosh and MS Windows. You can obtain it from the VMWare site. Once you have installed VMWare Player, or an equivalent application, you have to download the virtual machine zip file. It is hosted on the download section of the MCTWP site, at You have to uncompress this file. This will create a folder called mctwp, which contains a file called mctwp.vmx that you can run with VMWare Player. If VMWare Player asks you, if you have copied or moved the virtual machine, select the copied choice. Other VMWare products may ask you if you want to create a new UUID, if this is the case, you must answer YES. The virtual machine has no graphic environment, as it is not needed. The virtual machine only contains an Apache web server, a Tomcat container, a Postgres database and an exist XML database, that has been installed as explained in section A.5. You need to start a session in the virtual machine with username: demo and password: password, in order to configure some aspects of the MCTWP application, and to get the IP direction, otherwise you can not access the application. Next section explains how to get the IP direction to access the application. Although the application comes ready to work, you need to configure two properties that depend on the server IP address. The application can send DICOM images to any workstation or PACS, and can receive images from acquisition modalities, work stations or PACS. But you need to configure the application as detailed in sección A

160 Anexo A A Virtual Machine Network configuration When creating virtual machines it is possible to configure several network options. We have decided to use bridge networking, for simplicity. In this mode, the virtual machine tries to get an IP from the local network, so it can be accessed from any machine, not only from your laptop. Of course you can change this configuration if you want, and fit it to your needs. If you don t change the network configuration, you need to run this machine in a computer connected to a LAN with DHCP enabled. This way, when the virtual machine is switched on, it gets an IP from the LAN and the application is ready to serve requests in the whole LAN. First, you must to know the IP that has been assigned to the virtual machine. To do this, you must run ifconfig command in the virtual machine. That is, once the machine is running, start a session and launch the command, it will give you the right IP. You can now access the application requesting from any computer connected to the same LAN. Of course you can change this configuration if you like, in the same way as you can change other properties of the virtual machine. A.3. User s manual The application consists of four parts: a) Administration area, b) Research area, c) Image upload, and d) DICOM interfaces. The main window of the application, depicted in figure A.5, shows the access to administrator and researcher areas. The administrator of the trial can manage users, roles, trials, modalities and image types, Figura A.5.: Main window of the application. 140

161 A.3 User s manual whereas the researcher can do their job, that is, manage groups, patients and studies, process images, complete task and record results. There is an applet that can be launched apart. This applet allows to load images through HTTP file transfer. Of course, the application also allows researchers to send images by means of the DICOM protocol, because it supports C-STORE as SCP 5. A.3.1. Administration area Administrators can manage several aspects of the application, including users, trials, roles, image and process types and modalities. Administrators can assign users to trials by means of roles. That is, it is possible to associate the same user to different trials with different permission on each one. A role is a set of allowed actions. The application always checks if the user can perform a specific action. The application allows to define roles as desired, you only need to give a name and select what operations are authorized for the role. Note: This is currently a difficult operation, because it is necessary to have knowledge of the whole actions catalogue of the application, and this is not yet documented. If you want to create a specific role, you can ask me by or create a new issue in the project page. Administrators can also manage process types and image types. The meaning of these entities is explained above, in sección A Modality management is needed to allow acquisition modalities to send images to the application. In this case, the administrator detects the AE-TITLE of the sending application. New DICOM associations are rejected if there is no modality registered for the AE-TITLE. 5 Service Class Provider, see DICOM standard. 141

162 Anexo A Figura A.7.: Workflow of researchers. A.3.2. Research area This is the most complete area of the application. In this area, researchers can manage image processing tasks, navigate through trials, groups, patients and studies, and deal with their assigned tasks and record results. The flow of the main navigation is shown in figure A.7. Trials are created in the administration area by Administrators, but researchers can create the rest of the entities at this point, if they are allowed to. Figura A.6.: Meaning buttons. of As you can see in figure A.7, all screens contain a table with very similar buttons. The meaning of these buttons is shown in figure A.6. Other screens, such as task list or results have similar buttons. In all screens, you can see the meaning of any button with pop-up help text, just by moving the cursor over the button. There is not much to be said about the Edit and Explore buttons, they are self explanatory. The Upload Images button is not what it seems. 142

163 A.3 User s manual A Associating uploaded images As said before, images are uploaded in two different ways. They can be uploaded with the upload applet, see section A.4 or through DICOM. But in both cases, images are stored into a temporal storage, where images are grouped by source. Inside this temporal storage, there Figura A.8.: Temporal storage of uploaded is a folder for each source sending images. images. For example, if user miguel sends images through the upload applet, the application will create a folder called miguel, if it does not exist yet. If the source is not a user but it is an acquisition modality, the application will create a folder with the name of the AE-TITLE, if the modality has been given permission. When a user wants to associate images to any entity, application first show all temporal folders he is allowed to use 6. Then the user chooses one temporal folder, and the application shows all the images inside. Later the user selects the desired images and an image type. Images are always associated with studies, as you can see in figure A.1, but the application lets you associate images to a group, patient or study, so, how is this possible? The answer is easy: Based on demographic data of images. However, not all image formats contain demographic data. In this case, the application realizes that, and does not let you to associate these images to a group or a patient. Instead, these images have to be associated to a specific study. If you associate images with demographic data to a group, the application will try to find the patient and the study. If the application find these entities, it will 6 All users are allowed to access only his temporal folder, by default. Administrators can grant user to access other temporal folders 143

164 Anexo A associate images with them, otherwise, the application will create the study and/or the patient. On the other hand, if you try to associate images to a patient or study, and the demographic data does not match the demographic data of the current patient and/or study, the application warns you, although it does not forbid you. As you can see in figure A.9, the current patient info, at the top of the screen, does not match the demographic info of the image, so the application surrounds the name of the patient in red. Figura A.9.: Wrong patient id. A Attach files It is possible to attach files to any entity and results. You can attach spread sheets, pdf documents, or any other related data. Figura A.10.: Attached files management. A Protocol management It is possible to define a protocol for any entity, if the user is allowed to. This is useful for trial and group entities, although it is possible to define protocols for patients and studies. 144

165 A.3 User s manual Figura A.11.: Protocol management. A protocol must be defined at the beginning of the trial, because it is intended to automatically create tasks of specific process types when images are associated to that entity. The protocol is a list of tuples. Each tuple contains a process type, an image type, a default user and the time to do the task. When a new image is associated to an entity, the application checks if the image type, of the image being associated, matches the image type of any process of the protocol. When this happens, the application creates a new task of the defined process type, that is assigned to the default user with the defined deadline. The application not only checks the protocol of the entity to which images are being associated, but it also checks the protocol of higher entities. You must be careful with protocols, because if you change a protocol after images have been added, the application does not recreate tasks again. A Manual task creation You can request tasks manually. In this case, you select the process type, the assigned user and the dead line. When you create a task manually, you must take into account that the task is created for all images contained in the entity. This is very different for tasks created by protocols. Figura A.12.: Task form. Tasks that have been automatically created by protocols only contain a single image, because the application creates one task per 145

166 Anexo A image, or image series. But when you create a task manually, the application relates all images of the entity with the task. You have to be careful when selecting the entity where you want to create the task. A Task and result management Every user has his own task list. It is also possible to search task by dates, process type, and assigned user. As shown in figure A.13, every task has three buttons to edit the task, get the images of the task and to record results of the task. Figura A.13.: User tasks list. in the right lower corner. The application also allows to reassign a set of selected tasks, or to tag them as completed. This can be using with the buttons When editing a task, a user can write comments, can change the deadline (if he is allowed), can change the status or reassign the task to another user. Of course every change is traced down. It is possible to see the task history in the task edition screen, expanding the upper tab. A Subject reallocation The application allows to move patients from one group to another. This operation does not alter existing studies, images or tasks. All of these entities remains unmodified after the operation is completed. However, it may happen that the source and destination groups have different protocols. In this case, the application does not alter existing tasks, nor creates new tasks according to the destination group. It is possible to delete patients of a group, in a very similar way. However, in this case, the application takes into account if there are results associated to any task 146

167 A.4 Image upload of an image of the patient to be deleted. If this is the case, the application does not let you delete the patient. First, you have to delete the results. Both operations can lead to errors, so you have to be careful. For example, suppose that a researcher had already downloaded all images of a task to perform some process on them. If you delete a patient before the researcher records the results, the application will let you delete the patient, but when the researcher upload the results, it comes from a process where there is an image (or a set of images) that no longer belongs to the task. This way, the application could not ensure replicability. A Downloading and transferring images It is possible to download every image independently, using a floppy disk icon that is show under every image. It is possible to send images through DICOM to any workstation in a very similar way. In figure A.14 you can see how to download an image, how to access image tasks and how to send the image to a DICOM destination. Figura A.14.: Images of a study. The orange icon representing a set of floppy disks, that appears in the upper section of the figure, allows a user to download all the images of the study. This icon appears in more places, for example on the patient edition form, to download all images of a patient, or in the form of the images in a task. A.4. Image upload There is a link in the upper right corner that opens the applet to upload images, in a new window or tab. The applet is shown in figure A.15. Note: There is a known bug. Sometimes the applet asks for user credentials, these are the same as in the application. 147

168 Anexo A You only have to select just a bunch of images and press the upload button. The application will ignore images that it does not know how to deal with. Figura A.15.: Upload images applet. A.5. How to install the application This chapter contains the same instructions that appear in the project web page. These instructions have been validated with Ubuntu Server Only an installation with the minimal options is requested. I don t install the graphical environment in server machines, but you could install it, if you want. It doesn t matter whether you choose 32 bit or 64 bit, all needed software is compatible with both. A.5.1. Basic packages Once Ubuntu is installed, you need to install other packages. In order to find all of them, it is necessary that you allow parter repository in the /etc/apt/sources.list file. Make sure the following packages are installed: 148