Diseño e implementación de una herramienta de telemedicina para la detección precoz de glaucoma

78 

Texto completo

(1)UNIVERSIDAD POLITÉCNICA DE MADRID ESCUELA TÉCNICA SUPERIOR DE INGENIEROS DE TELECOMUNICACIÓN. GRADO EN INGENIERÍA DE TECNOLOGÍAS Y SERVICIOS DE TELECOMUNICACIÓN TRABAJO FIN DE GRADO. DISEÑO E IMPLEMENTACIÓN DE UNA HERRAMIENTA DE TELEMEDICINA PARA LA DETECCIÓN PRECOZ DE GLAUCOMA Alejandro Ramos Martı́n 2020.

(2)

(3) GRADO EN INGENIERÍA DE TECNOLOGÍAS Y SERVICIOS DE TELECOMUNICACIÓN TRABAJO FIN DE GRADO Tı́tulo:. Autor: Tutor: Ponente: Departamento:. DISEÑO E IMPLEMENTACIÓN DE UNA HERRAMIENTA DE TELEMEDICINA PARA LA DETECCIÓN PRECOZ DE GLAUCOMA D. Alejandro Ramos Martı́n D. Juan José Gómez Valverde Departamento de Ingenierı́a Electrónica. MIEMBROS DEL TRIBUNAL Presidente: Vocal: Secretario: Suplente:. Los miembros del tribunal arriba nombrados acuerdan otorgar la calificación de:. Madrid, a. de. de 2020.

(4) UNIVERSIDAD POLITÉCNICA DE MADRID ESCUELA TÉCNICA SUPERIOR DE INGENIEROS DE TELECOMUNICACIÓN. GRADO EN INGENIERÍA DE TECNOLOGÍAS Y SERVICIOS DE TELECOMUNICACIÓN TRABAJO FIN DE GRADO. DISEÑO E IMPLEMENTACIÓN DE UNA HERRAMIENTA DE TELEMEDICINA PARA LA DETECCIÓN PRECOZ DE GLAUCOMA Alejandro Ramos Martı́n 2020.

(5)

(6) Resumen La detección precoz de algunas enfermedades puede suponer un hecho decisivo para posponer o estabilizar los efectos más adversos de estas sobre las personas que las padecen. En el caso del glaucoma, que se trata de una patologı́a ocular que supone la segunda causa de ceguera en el mundo, una detección temprana puede marcar la diferencia entre la pérdida completa de visión de un paciente, o conservar su vista, ası́ como mejorar su posterior tratamiento. Es por este motivo que existen actualmente campañas médicas para la detección temprana de patologı́as de estas caracterı́sticas en una determinada población de estudio, denominadas screening o cribado, que han demostrado muy buenos resultados. Además, la aplicación de la telemedicina a estos procesos ha permitido la evaluación remota de los casos por expertos clı́nicos y han surgido numerosas iniciativas para su uso en nuevas estrategias de cribado. Por otro lado, las técnicas de procesamiento de imágenes biomédicas basadas en aprendizaje profundo han experimentado un gran desarrollo a lo largo de los últimos años, y hay varios proyectos que han demostrado su posible aplicación en la detección automática de glaucoma con imágenes de fondo de ojo. El proyecto presentado ha consistido en el desarrollo de una plataforma web que integra ambos escenarios: por un lado, la evaluación remota de imágenes de fondo de ojo por especialistas médicos, y por otro, la aplicación de una herramienta basada en Deep Learning para la detección automática de glaucoma en los casos de estudio.. Summary Early diagnosis of some type of diseases can be a very important factor in order to postpone or stabilize their most critical effects on those who suffer them. This may be the case of glaucoma, an eye pathology that stands as the second major cause of blindness in the world nowadays. An early detection of this disease can suppose the difference between complete vision loss on a patient, or keeping his or her vision as well as improving the later treatment. For this reason, there are currently many medical campaigns for early detection of pathologies with these characteristics in a certain population. These strategies are known as screening and have achieved very successful results. Moreover, use of telemedicine in these processes has allowed remote evaluation of clinical cases by medical specialists and has also been applied in new screening strategies. On the other hand, development of recent biomedical image processing technics based on Deep Learning has proven to be reliable for automatic glaucoma detection in eye fundus images. Therefore, this project has focused on the design and implementation of a web application that covers both scenarios: on the one hand, remote eye fundus images evaluation by medical specialists, and on the other hand integrating a Deep Learning model for glaucoma automatic detection in all the cases of study.. i.

(7) Palabras clave Glaucoma, cribado, aprendizaje profundo, telemedicina, base de datos, servidor REST API, información cualitativa, predicción, detección, diagnóstico, aplicación web, administrador, examinador, evaluador. Key words Glaucoma, screening, Deep Learning, telemedicine, database, REST API server, qualitative information, prediction, detection, diagnosis, web application, administrator, examiner, evaluator. ii.

(8) Agradecimientos Quisiera empezar dando las gracias a todas las personas que han contribuido a que este Trabajo de Final de Grado haya sido posible. En primer lugar, quiero agradecer a mi tutor, Juan José Gómez Valverde, su voto de confianza para este trabajo. A pesar de las grandes dificultades añadidas este año por el Covid-19, hemos sacado este proyecto adelante sin redefinir ni limitar sus objetivos. Siempre le agradeceré el tiempo dedicado, su paciencia, cordialidad y entusiasmo, que hacen de él un gran profesional y docente. Sin duda tengo que agradecer también a mi familia el apoyo que me ha dado durante estos últimos meses, que no han sido nada fáciles. A mi hermana, Ana, por compartir conmigo unas jornadas de trabajo tan intensas en su preparación para la selectividad y amenizarlas con su optimismo y buen humor, siempre admirables. A mis padres, José Manuel y Carmen, por darme la oportunidad de conocer, aprender y valorar. Gracias por confiar y creer en lo que hago. Echando la vista atrás, he sido muy afortunado de conocer en estos años de carrera a personas maravillosas con las que he compartido tan buenos momentos. Gracias por aportar siempre vuestro granito de arena en el dı́a a dı́a, vosotros sabéis quiénes sois. Gracias también a los de siempre, Charlie, Fer, por su cariño y por dejarme aprender de ellos. Con vosotros al fin del mundo. No puedo olvidarme tampoco de José Ángel. Oh capitán mi capitán, tu calidad como docente es solamente comparable con tu calidad humana. Gracias por inspirarme con tus valores, tu talante y tu pasión por la vida. Por último, y no por ello menos importante, quiero dar las gracias a los excelentes profesionales que han hecho frente a la pandemia, por su ejemplaridad y su lucha, que no estará nunca lo suficientemente premiada ni reconocida. Quisiera hacer especial mención a la labor de los sanitarios, entre ellos mi madre, a quien vi salvar la vida de una persona cuando tenı́a siete años, y que me demostró que, más allá del trabajo, existe la vocación. La vocación por atender a una causa mayor que nosotros mismos. La vocación por ser lo mejor de nosotros mismos.. iii.

(9) Índice de contenidos. Resumen. i. Agradecimientos. iii. 1 Introducción y objetivos. 1. 1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. 1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2. 2 Estado del Arte. 3. 2.1. El papel de la telemedicina en los procesos de cribado . . . . . . . . . . .. 3. 2.2. La importancia del cribado en oftalmologı́a . . . . . . . . . . . . . . . . .. 4. 2.3. Desarrollo actual de soluciones técnicas para el diagnóstico de enfermedades oculares basadas en aprendizaje profundo . . . . . . . . . . . . . . . . . .. 4. 2.3.1. Diagnóstico Asistido por Ordenador (CAD) en las estrategias de cribado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3 Método y Desarrollo. 5 6. 3.1. ¿De dónde partimos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6. 3.2. Requisitos funcionales y casos de uso . . . . . . . . . . . . . . . . . . . .. 7. 3.2.1. Administrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 3.2.2. Técnico o examinador . . . . . . . . . . . . . . . . . . . . . . . .. 9. 3.2.3. Evaluador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 10. iv.

(10) 3.3. 3.4. Herramientas utilizadas en el proyecto . . . . . . . . . . . . . . . . . . .. 11. 3.3.1. El Modelo-Vista-Controlador (MVC) . . . . . . . . . . . . . . . .. 11. 3.3.2. Laravel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 11. 3.3.3. Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 12. 3.3.4. Base de datos relacional con MySQL . . . . . . . . . . . . . . . .. 13. 3.3.5. Resumen de herramientas utilizadas . . . . . . . . . . . . . . . . .. 13. Técnicas utilizadas para el desarrollo del sistema . . . . . . . . . . . . . .. 14. 3.4.1. Servidor REST API para desplegar el modelo de Deep Learning .. 14. 3.4.2. Herramientas usadas en Python para invocar a la aplicación de Deep Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 15. Herramienta Grad-CAM para obtener información cualitativa del modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 16. Planificación y fases del proyecto . . . . . . . . . . . . . . . . . . . . . .. 16. 3.4.3. 3.5. 4 Resultados y plan de pruebas. 19. 4.1. Herramienta para la Detección Precoz de Glaucoma: BitScreen OPH . .. 19. 4.2. Arquitectura Global de la Herramienta . . . . . . . . . . . . . . . . . . .. 20. 4.3. Resultados de la aplicación web . . . . . . . . . . . . . . . . . . . . . . .. 20. 4.3.1. Inicio de sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 21. 4.3.2. Login como usuario administrador . . . . . . . . . . . . . . . . . .. 24. 4.3.3. Login como usuario técnico o examinador . . . . . . . . . . . . . .. 34. 4.3.4. Login como usuario evaluador . . . . . . . . . . . . . . . . . . . .. 41. 4.4. Resultados del servidor REST API para el modelo de Deep Learning . .. 49. 4.5. Modelo de la base de datos de BitScreen OPH . . . . . . . . . . . . . . .. 51. 4.6. Plan de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 53. 4.6.1. 54. Tabla de pruebas realizadas para la aplicación . . . . . . . . . . .. v.

(11) 4.6.2. Prueba del modelo de Deep Learning sobre un conjunto de datos de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5 Conclusiones y lı́neas futuras. 55 57. 5.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 57. 5.2. Lı́neas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 58. A Aspectos éticos, económicos, sociales y ambientales. 63. A.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 63. A.2 Descripción de impactos relevantes relacionados con el proyecto . . . . .. 64. A.3 Análisis detallado de alguno de los principales impactos . . . . . . . . . .. 64. A.4 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 65. B Presupuesto económico. 66. vi.

(12) Capı́tulo 1 Introducción y objetivos 1.1. Motivación. El glaucoma está considerado como una de las causas más importantes de ceguera en el mundo, viéndose especialmente afectadas por esta enfermedad las personas mayores de 60 años. Se trata de una patologı́a crónica asintomática en sus primeros estadios, y se manifiesta como un conjunto de afecciones oculares que pueden dañar al nervio óptico. Este nervio es el encargado de enviar al cerebro la información visual percibida por el ojo. La parte frontal del ojo está cubierta por un lı́quido claro llamado humor acuoso. Este lı́quido es producido en la zona del ojo localizada entre la córnea y el iris, denominada la cámara anterior, y circula libremente por esta región aportando los elementos necesarios para el metabolismo de las estructuras anteriores del ojo, como la córnea y el cristalino [1]. El humor acuoso sobrante es expulsado de esa región a través del canal de Schlemm. Cualquier factor que obstruya el flujo de este lı́quido por el canal causará un aumento de la presión en el ojo, pudiéndose producir glaucoma. Todas las partes del ojo citadas en este apartado se ilustran en la Figura 1.1. Figure 1.1: Anatomı́a del ojo. https://es.wikipedia.org/. Fuente:. La detección precoz del glaucoma puede posponer los efectos más adver1.

(13) sos de la enfermedad, ası́ como mejorar su posterior tratamiento. Su diagnóstico se basa en pruebas estructurales del disco óptico, ası́ como funcionales. En los últimos años han surgido numerosas iniciativas para la detección del glaucoma basadas en la evaluación remota por expertos clı́nicos, utilizando, entre otras, imágenes de fondo de ojo adquiridas con retinógrafos digitales. Además, el avance de las técnicas de procesamiento de imagenes biomédicas se ha revolucionado en los últimos años con el desarrollo de técnicas de aprendizaje profundo (o Deep Learning) y hay varios proyectos que han demostrado su posible aplicación en la detección automática de glaucoma con imágenes de fondo ojo.. 1.2. Objetivos. El objetivo del presente trabajo es diseñar e implementar una herramienta de telemedicina que ayude a la detección de glaucoma en imágenes de fondo de ojo utilizando técnicas de aprendizaje profundo. De esta forma, el proyecto se dividirá en dos partes: • La primera parte se centrará en el desarrollo de la plataforma web, y se llegará a una versión funcional de la misma que permita a los profesionales sanitarios, por un lado, crear estudios de los casos clı́nicos y, por otro, realizar evaluaciones de los mismos para detectar si existe algún indicio de la patologı́a según los datos enviados y las imágenes adquiridas. • La segunda parte consistirá en la integración del software de detección automática de glaucoma en el sistema, dando como resultado una valoración generada por el programa sobre las imágenes incluidas en el estudio. El evaluador del caso tendrá acceso a esta valoración realizada por la máquina desde la plataforma, mostrando información visual cualitativa basada en las zonas de análisis que más han contribuido a la clasificación final del sistema. La finalidad de este proyecto es que permita llevar a cabo estrategias de cribado, también conocidas como screening, orientadas a la detección precoz de glaucoma, proporcionando a los especialistas médicos información de ayuda al diagnóstico mediante técnicas de clasificación automática. El concepto de cribado se refiere en el ámbito de la medicina a campañas de detección de una determinada enfermedad, aplicadas sobre una población de estudio sin sı́ntomas o indicios aparentes de la misma, con el objetivo de realizar una detección temprana de dicha patologı́a y prevenir sus efectos más adversos.. 2.

(14) Capı́tulo 2 Estado del Arte Este capı́tulo tiene como objetivo estudiar las aportaciones que han supuesto los desarrollos tecnológicos actuales a las estrategias de cribado, haciendo especial incapié en la aplicación de la telemedicina a estas técnicas y la relevancia de los programas de ayuda a la detección en estos procesos.. 2.1. El papel de la telemedicina en los procesos de cribado. El concepto de telemedicina ha estado expuesto a diversas interpretaciones desde su aparición en los años 70. Fue definido en el año 2010 por la OMS como una técnica que permitiera la atención médica a distancia de personas o comunidades utilizando las TIC para el diagnóstico, tratamiento o prevención de enfermedades, con el fin de mejorar la asistencia sanitaria de las mismas [2]. A dı́a de hoy, la práctica de la telemedicina ha desembocado en dos vertientes de aplicación. Por un lado está la telemedicina en tiempo real, que requiere la presencia simultánea de todos los profesionales sanitarios involucrados en una práctica médica determinada, de forma parecida a una videoconferencia. En la otra vertiente se sitúa la estrategia de store-and-forward, que consiste en el almacenamiento temporal de los datos clı́nicos recogidos de un estudio o un paciente, para ser posteriormente utilizados por un experto médico que participe en el mismo proceso [3]. La telemedicina basada en store-and-forward es ampliamente utilizada en los procesos de cribado, y han surgido numerosas iniciativas para su uso en casos de cáncer de mama [4][5], cáncer de cuello de útero [6] o cáncer de pulmón [7]. Además, el uso de esta técnica supone una contribución importante en cribados que hacen uso de imágenes médicas, como es el caso de la teledermatologı́a, siendo este uno de los campos más desarrollados en este área.. 3.

(15) 2.2. La importancia del cribado en oftalmologı́a. La aplicación del cribado para la detección temprana de enfermedades de retina es uno de los casos de mayor éxito en oftalmologı́a [3], siendo especialmente relevante su uso en detección de retinopatı́a diabética (DR) y de degeneración macular asociada a la edad (AMD). Ambas se presentan asintomáticas en sus primeros estadios y suponen respectivamente una causa creciente de pérdida de visión en personas de mediana edad y edad avanzada. Además, existen también estudios que demuestran la efectividad del cribado para detección de Glaucoma. Una detección temprana puede posponer o frenar los efectos de estas patologı́as en el ojo, previniendo la pérdida de visión de las personas que las padecen. Por este motivo, los procesos de cribado juegan un papel muy importante en la detección de estas enfermedades a tiempo.. 2.3. Desarrollo actual de soluciones técnicas para el diagnóstico de enfermedades oculares basadas en aprendizaje profundo. La aplicación de las técnicas de aprendizaje automático y de Deep Learning sobre imágenes biomédicas ha resultado ser muy útil para la detección de patologı́as y existen estudios que muestran muy buenos resultados. Un ejemplo de ello es el realizado por la empresa DeepMind en 2018 [8], que utilizaba Deep Learning para el diagnóstico de enfermedades oftalmológicas en imágenes de Tomografı́a de Coherencia Óptica (OCT), llegando a unos resultados muy precisos que permitı́an predecir correctamente qué tratamiento necesitaban los pacientes. Debido al alto número de adquisiciones diarias, y sumado al tiempo que requiere analizar cada una de estas imágenes, el uso de estas tecnologı́as permitió priorizar el estudio de los casos urgentes y prevenir la degeneración de las patologı́as graves en los pacientes. En numerosas ocasiones se ha referido al aprendizaje automático como perteneciente al marco de tecnologı́as de Inteligencia Artificial (IA). Estas técnicas tienen un auge cada vez mayor en gran cantidad de aplicaciones, y es común la propuesta de retos y concursos por parte de organismos internacionales para abordar un determinado problema haciendo uso de estas tecnologı́as. Una referencia actual para este trabajo es el reto internacional REFUGE2 propuesto para otoño de este año 2020 por la International Conference on Medical Image Computing and Computer Assisted Intervention en Lima, Perú [9]. El reto propuesto es evaluar y comparar diferentes algoritmos para detección automática de glaucoma y segmentación del disco óptico, aplicados sobre un set de prueba con imágenes de fondo de ojo.. 4.

(16) 2.3.1. Diagnóstico Asistido por Ordenador (CAD) en las estrategias de cribado. El concepto de CAD surgió inicialmente como un conjunto de técnicas que permitieran a una máquina analizar imágenes biomédicas y detectar en ellas la presencia de patologı́as, pudiendo superar, o incluso reemplazar, la capacidad de diagnóstico de un especialista médico [3]. Sin embargo, esta aproximación cambió a partir de los años 80, cuando se planteó esta tecnologı́a como una herramienta enfocada a la ayuda a la detección (o al diagnóstico), y ha supuesto una contribución muy preciada a los procesos de cribado. Se comprobó que no era necesario que la máquina superara la precisión del ojo humano para poder aportar información útil que sirviera de apoyo a los especialistas en su decisión. Los pasos que siguen las tecnologı́as CAD en el proceso de clasificación de una imagen [3] son: (1) preprocesado y adaptación de la imagen para mejorar su calidad antes de ser procesada, (2) segmentación de la imagen en las regiones de mayor interés de análisis, para centralizar el proceso de detección en dichas regiones, (3) identificación de hallazgos que puedan contribuir a la clasificación de la patologı́a buscada, y finalmente, (4) clasificación de la imagen a partir de los hallazgos encontrados. Un gran reto al que se enfrenta actualmente la investigación de las tecnologı́as CAD es la extracción de información no únicamente cuantitativa, sino también cualitativa, de las imágenes, con el objetivo de aportar, además del resultado de la clasificación, información sobre los hallazgos que han contribuido a la decisión final establecida en el proceso.. 5.

(17) Capı́tulo 3 Método y Desarrollo En este capı́tulo se abordarán los requisitos funcionales de la aplicación y el estudio realizado en relación con los casos de uso por parte del usuario. Esta primera parte pretenderá aportar un esquema conceptual de cómo tiene que funcionar la aplicación y explicar el rol de cada uno de los usuarios. A continuación, se explicarán las técnicas utilizadas para el desarrollo del proyecto y se justificará la elección de ciertas herramientas empleadas.. 3.1. ¿De dónde partimos?. Es importante mencionar antes de nada que la forma que se ha dado al proyecto, ası́ como la definición de los objetivos funcionales, parten de dos proyectos realizados anteriormente por el grupo de investigación Biomedical Image Technologies Laboratory del Departamento de Ingenierı́a Electrónica de la ETSIT. A continuación se incluye una descripción breve de ambos proyectos: • La plataforma web Bitscreen PTB, orientada a la detección de casos de tuberculosis infantil en procesos de cribado mediante el estudio de radiografı́as de tórax, y el modelo de la base de datos que utiliza. Esta aplicación se basa en la técnica de store-and-forward, mencionada anteriormente en la sección El papel de la telemedicina en los procesos de cribado del Capı́tulo 2, y permite a un usuario técnico la creación de estudios asociados a cada paciente, para la posterior evaluación de los mismos por parte de un especialista, en busca de una manifestación temprana de la patologı́a. La aplicación Bitscreen OPH, presentada en este TFG, ha partido del código completo de esta aplicación y contiene su misma estuctura interna: roles de los usuarios, uso de la metodologı́a store-and-forward y estrategia de cribado orientada a la detección precoz de glaucoma en una población mediante el estudio de imágenes de fondo de ojo. Además, esta aplicación ha heredado el modelo de la base de datos 6.

(18) que utiliza Bitscreen PTB, que comprende su estructura y diseño de las tablas, ası́ como los datos iniciales de algunas tablas que tienen en común. • Desarrollo en Python de un modelo de Deep Learning entrenado para la detección automática de glaucoma en imágenes de fondo de ojo. El sistema lee la imagen que se quiere analizar y la preprocesa para ser introducida en el modelo. El modelo devuelve como resultado de la clasificación dos opciones, positivo o negativo, siendo “positivo” indicativo de que la imagen de fondo de ojo contiene signos sospechosos de glaucoma y “negativo” cuando el sistema clasifica la imagen como normal o sin signos de glaucoma. La clasificación internamente se basa en un score numérico entre 0 y 1 y el cálculo de un umbral que optimiza la clasificación. El objetivo de este bloque del proyecto ha sido integrar este modelo entrenado en el sistema. Este apartado ha consistido principalmente en enviar las imágenes introducidas en la plataforma automáticamente a la red, y almacenar el resultado de la clasificación automática en la Base de Datos para poder ser utilizada como información de ayuda a los especialistas a la hora de evaluar los estudios. Además, se ha introducido también un apartado de información cualitativa en las imágenes, a la que podrán acceder los evaluadores, del que se hablará más adelante.. 3.2. Requisitos funcionales y casos de uso. La estrategia de cribado requiere generalmente una amplia población de estudio. Este hecho conlleva la necesidad de una clasificación eficiente de los datos y de un control ordenado sobre los pacientes y los estudios realizados. Por este motivo, la aplicación debe proporcionar el acceso a los datos de manera intuitiva y ordenada. Los usuarios que participan se definen según sus roles en este proceso. A continuación, se explican los requisitos funcionales de la aplicación y los diferentes casos de uso por parte de estos usuarios. El cumplimiento de estos requisitos (RFXX) se verificará en el Plan de pruebas del Capı́tulo 4 de este documento.. 3.2.1. Administrador. RF1: El administrador puede registrar en la plataforma los centros médicos que vayan a hacer uso de la aplicación, y editar los datos de los ya creados. RF2: El administrador es capaz de dar de alta a los usuarios en la aplicación, donde introducirá sus datos y elegirá su rol, ası́ como editar los datos de los usuarios existentes. RF3: En el proceso de alta de usuario, el administrador introducirá sus datos personales, entre otros, la dirección de correo electrónico que utilizará el usuario para identificarse, y su estado figurará como pending.. 7.

(19) RF4: Tras registrar al nuevo usuario en la aplicación, este recibirá en su correo un formulario para finalizar el proceso de registro. El usuario deberá introducir en este la contraseña que desee usar para su cuenta. RF5: Una vez termine el usuario de darse de alta en la aplicación, tras introducir sus credenciales, se activará su cuenta y su estado pasará a active, lo que garantizará su acceso. RF6: Cada email tendrá un token identificativo único. Si el usuario tarda más de 24 horas en formalizar la activación de su cuenta tras recibir el correo, expirará el token y no podrá acceder al formulario. El usuario tendrá que comunicarlo al administrador vı́a correo para volver a enviarle el formulario. El administrador podrá hacer esto desde el menú de edición de los datos del usuario. RF7: Si un usuario introduce sus datos de usuario erróneamente más de tres veces seguidas al hacer el Login, cambiará su estado a blocked y se desactivará su cuenta temporalmente, sin poder acceder a la aplicación. RF8: En el caso anterior, únicamente el administrador podrá reactivar al usuario en la plataforma. Esto podrá hacerlo desde el menú de edición de los datos del usuario, y se enviará un formulario al correo del usuario que le permitirá reactivar su cuenta introduciendo sus credenciales. RF9: Una vez introducidas las credenciales nuevas en el formulario, el estado del usuario volverá a active. RF10: De la misma forma que en RF6, el token del email expirará en 24 horas y el usuario tendrı́a que solicitar de nuevo su reactivación al administrador vı́a correo. RF11: El administrador nunca podrá ser bloqueado. RF12: El administrador tendrá acceso a la lista de usuarios de la aplicación. RF13: El administrador tendrá acceso a la lista de pacientes de la aplicación. RF14: El administrador podrá crear nuevos pacientes y editar los datos de los ya existentes en la plataforma. RF15: Además, tendrá acceso la lista de estudios asociados a cada paciente. RF16: El administrador únicamente podrá visualizar, y no modificar, los datos de los estudios, ya estén abiertos o cerrados. RF17: El administrador podrá acceder y modificar los datos de su perfil desde su interfaz de usuario. RF18: Si el administrador olvida su contraseña, podrá solicitar desde la ventana de registro que se le envı́e al correo un formulario para introducir unas nuevas credenciales. Para ello tendrá que escribir su correo electrónico y el proceso se realizará 8.

(20) automáticamente.. 3.2.2. Técnico o examinador. RF19: El examinador tiene acceso a la lista de pacientes de la aplicación. RF20: El examinador podrá crear nuevos pacientes y editar los datos de los ya existentes en la plataforma. RF21: El examinador podrá acceder a la lista de estudios asociados a cada paciente, y podrá visualizar y modificar los datos de estudios creados por este o por otros examinadores. RF22: El examinador podrá acceder a la lista de estudios de todos los pacientes asignados a él, desde la opción Studies de su menú desplegable. RF23: El examinador podrá crear nuevos estudios desde las vistas mencionadas en RF3 y RF4. Tendrá que rellenar para cada estudio un historial clı́nico del paciente asociado y podrá introducir los datos e imágenes que se mandarán para evaluación. RF24: El examinador podrá guardar los estudios incompletos para seguir editándolos más tarde, sin necesidad de completar todos los campos obligatorios. RF25: El examinador no podrá enviar un estudio a evaluación si falta algún campo obligatorio por rellenar. RF26: Tras enviar el estudio a evaluación, se almacenará el resultado de la clasificación automática en la base de datos junto con los otros datos de los estudios. RF27: Tras enviar el estudio a evaluación, se almacenará la imagen con la información cualitativa en el mismo directorio local que las imágenes originales. RF28: La plataforma mandará automáticamente el estudio al evaluador que menos estudios tenga pendientes. RF29: El examinador podrá visualizar los resultados de las evaluaciones cuando estas estén finalizadas. RF30: Los estudios estarán en estado draft si no han sido enviados, pending si están pendientes de evaluación, o closed si el evaluador ha cerrado el caso. RF31: El examinador podrá acceder y modificar los datos de su perfil desde su interfaz de usuario. RF32: Si el examinador olvida su contraseña, podrá solicitar desde la ventana de registro que se le envı́e al correo un formulario para introducir unas nuevas credenciales. Para ello tendrá que escribir su correo electrónico y el proceso se realizará automáticamente. 9.

(21) 3.2.3. Evaluador. RF33: El evaluador recibirá los datos de estudio generados por alguno de los examinadores, y podrá visualizar la lista de estudios asignados a su usuario. RF34: El evaluador tendrá acceso únicamente a los estudios de los que sea responsable, y podrá iniciar una evaluación pendiente, editar los datos de una evaluación guardada o visualizar la evaluación cuando haya sido terminada por el usuario. RF35: El evaluador podrá visualizar en los estudios los datos clı́nicos del paciente y las imágenes médicas subidas por el examinador. RF36: Además, si se incluyen entre las imágenes de estudio imágenes de fondo de ojo, el evaluador tendrá acceso a los resultados de la clasificación automática aplicada sobre dichas imágenes para la detección de presencia de Glaucoma en ellas, ası́ como a un apartado de visualización de la información cualitativa generada también por el modelo. RF37: La función del evaluador será analizar los datos de estudio y llevar a cabo un diagnóstico del caso. RF38: El evaluador podrá guardar las evaluaciones incompletas para seguir editándolas más tarde, sin necesidad de completar todos los campos obligatorios. RF39: El evaluador no podrá cerrar un estudio si falta algún campo obligatorio por rellenar. RF40: Las evaluaciones estarán en estado pending si no han sido iniciadas, evaluation si se encuentran en proceso, o closed si se han finalizado. RF41: El evaluador podrá acceder y modificar los datos de su perfil desde su interfaz de usuario. RF42: Si el evaluador olvida su contraseña, podrá solicitar desde la ventana de registro que se le envı́e al correo un formulario para introducir unas nuevas credenciales. Para ello tendrá que escribir su correo electrónico y el proceso se realizará automáticamente. Para terminar este apartado, se ha incluido un diagrama con las situaciones en las que la aplicación hará uso del servidor de correo:. 10.

(22) Figure 3.1: Situaciones de envı́o de emails por la aplicación.. 3.3 3.3.1. Herramientas utilizadas en el proyecto El Modelo-Vista-Controlador (MVC). El MVC o Modelo-Vista-Controlador es un patrón de arquitectura software propuesto por el informático noruego Trygve Reenskaug en 1979. Es una técnica orientada al desarrollo software con interfaz gráfica de usuario y, explicado de una manera sencilla, consiste en dividir el trabajo de diseño de las aplicaciones en tres elementos clave [10][11]. El primero constituye la parte de control del sistema, encargada de la lógica de la aplicación. El segundo, la presentación de la aplicación en forma de componentes gráficas denominadas vistas. Y, por último, el modelo, que comprenderá la organización de los datos utilizados por la aplicación, habitualmente almacenados en bases de datos. Este patrón MVC ha supuesto una aportación muy importante para el mundo del desarrollo web, y es un recurso muy utilizado a dı́a de hoy tanto en los frameworks de desarrollo modernos como en sistemas gráficos empresariales.. 3.3.2. Laravel. Los frameworks, o entornos de trabajo, son herramientas que aportan gran utilidad para el desarrollo de aplicaciones software. Esto se debe a que la difı́cil gestión de proyectos grandes, con un número elevado de ficheros relacionados por una lógica interna, hace necesaria la organización y distribución de los mismos de una forma óptima. Los frameworks aportan una solución eficaz al desarrollador, proporcionando una estructura ordenada que facilite el trabajo y una lógica interna que ayuda a la programación, compilación y lectura entre ficheros. En el caso del desarrollo web existen múltiples entornos que cumplen con la función antes explicada, como Symfony, Laravel, Phalcon o Drupal. Uno de los más utilizados es 11.

(23) Laravel, que se trata de un framework de código abierto, programado en PHP, que utiliza el Modelo-Vista-Controlador como herramienta estructural en su desarrollo. Este entorno ha sido el utilizado para el proyecto por ser gratuito, por su sencillez de uso, explicado en detalle en su documentación [12], por tener un amplio repertorio de opciones que aportan funcionalidad y por ser compatible con múltiples herramientas de programación web a partir de su árbol de dependencias. Además, Laravel aporta una gran cantidad de soluciones de ámbito general al desarrollador: da proporcionado todo el sistema de autenticación de usuarios, manejo de peticiones y respuestas (REST, HTTP), manejo de formularios y validación de los datos, estructura de directorios, multi-idioma, etc. y esto hace que el trabajo de programación sea mucho más rápido e intuitivo que en otros entornos.. Laravel Homestead Laravel necesita un entorno virtual para poder realizar el trabajo de desarrollo. Para ello, utiliza el software de Vagrant [13], una herramienta útil que permite crear y gestionar los entornos de desarrollo, ejecutándose estos en una máquina virtual como Virtualbox, VMware, AWS u otros. Vagrant proporciona un paquete para Laravel llamado Laravel Homestead que incluye todos los ficheros de configuración del entorno y permite trabajar sin necesidad de instalar PHP, un servidor web u otros paquetes de software en la máquina virtual. De esta forma, para empezar a trabajar simplemente se deberá arrancar la máquina virtual y podremos acceder a la plataforma web en la que estemos trabajando desde el navegador. Además, este entorno proporciona una herramienta llamada Composer que permite la integración y la gestión de dependencias en el proyecto introduciendo unos sencillos comandos en el terminal.. 3.3.3. Bootstrap. Bootstrap es una librerı́a muy utilizada a dı́a de hoy para el desarrollo de vistas de aplicaciones web [14]. Ofrece una variedad amplia de estilos que aportan gran cantidad de recursos tanto para el diseño de las vistas como para la funcionalidad de los formularios. Además, esta librerı́a puede integrarse en el framework de Laravel de forma directa utilizando Composer. El desarrollo de la aplicación web presentada en este trabajo se ha basado por completo en Bootstrap por este motivo, utilizándose para el diseño de las vistas, para crear listas de estudios o pacientes, en ventanas emergentes para la previsualización de imágenes, calendarios para selección de fechas o apartados para la subida de imágenes en los estudios, entre otros.. 12.

(24) 3.3.4. Base de datos relacional con MySQL. El modelo de datos del proyecto ha consistido en el uso de una base de datos relacional implementada en MySQL. Es relacional porque el modelo se estructura en forma de tablas, las cuales clasifican y organizan los recursos a los que accede la aplicación, y algunas de estas tablas tienen campos en común que relacionan los datos almacenados en ellas. A modo de ejemplo para este proyecto, en el que se guardan estudios médicos asociados a cada uno de los pacientes registrados en la aplicación para más tarde ser evaluados por un especialista, se tendrá una tabla donde se almacenarán las referencias a los estudios creados, y esta tendrá un campo patient id y otro campo evaluator id, con los identificadores de los pacientes y evaluadores registrados en sus respectivas tablas. De esta forma, a partir de los datos de un estudio guardado se puede acceder al evaluador asignado o al paciente asociado a dicho estudio, y viceversa. Las BBDD relacionales son de gran ayuda en proyectos de gran escala, y Laravel facilita en gran medida el acceso a estas estructuras y la relación entre los recursos almacenados y utilizados por la aplicación web.. 3.3.5. Resumen de herramientas utilizadas. Herramienta Versión Licencia Uso Laravel 6.2 MIT Framework. Web de referencia https://laravel.com. Vagrant. 2.2.6. MIT. https://www.vagrantup.com. Bootstrap. 2.3. MIT. MySQL Workbench. 8.0. Oracle. phpMyAdmin. 5.0.1. SublimeText. 3.2. Editor de código fuente. https://www.sublimetext.com. Git. 2.21.0. GNU General Public License v2 Software propietario GNU General Public License v2. MV para desarrollo con Laravel Librerı́a para desarrollo de vistas Implementación de la base de datos Construir el modelo de la base de datos. Control de versiones. https://git-scm.com. 13. https://getbootstrap.com https://www.mysql.com/ products/workbench/ https://www.phpmyadmin.net.

(25) 3.4. Técnicas utilizadas para el desarrollo del sistema. 3.4.1. Servidor REST API para desplegar el modelo de Deep Learning. Este apartado ha consistido en integrar el modelo de Deep Learning proporcionado para el proyecto, mencionado en el apartado ¿De dónde partimos? de este capı́tulo, en una interfaz de aplicación REST para ser desplegada en un servidor remoto. Esta implementación se ha basado en el ejemplo tomado como referencia en [15]. A continuación, se muestra un diagrama con el funcionamiento de este sistema.. Figure 3.2: Diagrama de bloques de la REST API.. La idea es que esta interfaz contenga el modelo de aprendizaje profundo cargado y disponible para procesar las peticiones de tipo REST enviadas desde la plataforma web. En nuestro caso de aplicación, únicamente se utilizarán peticiones de tipo POST, cuyo contenido serán las imágenes de fondo de ojo que se quieren analizar. Estas imágenes serán procesadas en el modelo cargado en el lado del servidor, y la interfaz devolverá una respuesta en forma de objeto serializado JSON con los resultados de la clasificación. Este procedimiento consistirá en dos pasos: (1) Pre-procesado de la imagen para ajustar sus caracterı́sticas (tamaño, normalización de los pı́xeles) a los requisitos de la red (2) Procesado de la imagen por el modelo, predicción de los resultados de clasificación y obtención de la información cualitativa del caso de estudio utilizando la herramienta Grad-CAM que se explicará más adelante en esta sección. 14.

(26) El principal motivo de utilizar una interfaz remota con estas caracterı́sticas es que el modelo de Deep Learning únicamente se cargará al arrancarse el servidor por primera vez, quedando disponible para su uso en cualquier momento por parte de la aplicación. Puesto que los modelos entrenados suelen tener un alto coste de carga, el uso de esta técnica reduce considerablemente los tiempos de operación de cada petición, lo que supone una gran ventaja para nuestro proyecto. La llamada al servidor REST se realizará desde la plataforma web, entre medias del proceso de envı́o del estudio por parte del examinador para su evaluación y la recepción del estudio por parte del evaluador. Cuando el examinador solicite el envı́o de los datos para evaluación, se enviarán las imágenes al servidor. Las imágenes se procesarán de manera independiente y se devolverá el resultado de la red en forma de objeto JSON a la aplicación. Una vez reciba la aplicación estos datos, almacenará los resultados de la clasificación de cada imagen en la base de datos junto con el resto de datos de estudio. La información cualitativa, que se recibe en forma de matriz numérica, será convertida en imagen y almacenada en el mismo directorio que las imágenes originales. Acto seguido terminará el proceso de envı́o del estudio para evaluación. El evaluador recibirá el estudio y una vez comience la evaluación tendrá acceso a estos datos.. 3.4.2. Herramientas usadas en Python para invocar a la aplicación de Deep Learning. Las librerı́as más importantes que se han utilizado en los scripts de Python generados han sido keras, tensorflow, numpy, requests, JSON y matplotlib. • Tensorflow es una librerı́a, creada por Google para la computación rápida de operaciones numéricas en Python [16][17], muy usada actualmente para la implementación de modelos de aprendizaje profundo. Aunque existen gran cantidad de desarrollos basados de forma directa en esta herramienta, es también común el uso por los desarrolladores de otras librerı́as, como Keras, que utilizan tensorflow pero encapsulan sus bloques para una implementación más sencilla de los modelos de Deep Learning. • Keras es una extensión de Pyhton muy conocida, que se basa en tensorflow para la implementación de modelos de aprendizaje profundo [18]. Contiene sublibrerı́as para la generación de modelos de redes neuronales, como VGG19 o ResNet50, ası́ como para la definición de las capas de la red o de las funciones de activación de cada capa. Esta librerı́a se ha utilizado en este proyecto para construir el modelo de red, ResNet50, y para obtener las predicciones de la red a partir de las imágenes de entrada. • Numpy es una librerı́a orientada al cálculo de operaciones numéricas y algebraicas con matrices y arrays en Python [19]. Esta herramienta se ha utilizado en el desarrollo de la aplicación fundamentalmente para el pre-procesado de las imágenes (cambio de tamaño, normalización) antes de ser introducidas en la red. 15.

(27) • Requests es una extensión orientada al envı́o de peticiones HTTP desde una aplicación [20]. En el proyecto se ha utilizado para la realización de peticiones REST al servidor con el modelo de aprendizaje profundo de forma remota, y para atrapar los mensajes de respuesta de este en formato JSON. • JSON es un formato para la creación de objetos Javascript con información serializada [21]. Python tiene un paquete con el mismo nombre que permite la codificación y descodificación de sus recursos en este formato, y ha sido muy útil en el proyecto para encapsular los datos enviados al servidor REST en un único mensaje serializado, y para encapsular de la misma forma el mensaje de respuesta desde el servidor, con los resultados de la predicción y con la matriz de información cualitativa obtenida. • Matplotlib [22] es una extensión utilizada para la representación gráfica de datos numéricos. Se ha utilizado en el proyecto para visualizar gráficamente la información cualitativa obtenida por el modelo y para guardar la imagen resultante en un directorio local.. 3.4.3. Herramienta Grad-CAM para obtener información cualitativa del modelo. Uno de los retos más importantes que desafı́an a las tecnologı́as basadas en aprendizaje profundo es el hecho de que el sistema actúa como una caja negra, es decir, no explica las decisiones tomadas para la predicción a los usuarios. Por este motivo, existen ramas de investigación de estas tecnologı́as que se centran en el estudio de mecanismos para extraer información cualitativa de la red, y se han dado aproximaciones con muy buenos resultados. En este proyecto se ha utilizado una técnica denominada Grad-CAM, aplicada a imágenes, que localiza las zonas de la imagen de entrada que han contribuido con mayor peso a la clasificación obtenida a la salida de la red, y relaciona el resultado con los pı́xeles de estas zonas de la imagen utilizando técnicas de propagación hacia atrás (backpropagation) y de desconvolución de la red [23]. El resultado es una matriz numérica que, si se representa como una imagen, muestra un mapa de color sobre la imagen original con las regiones que más han influido en la decisión final marcadas con mayor intensidad. Existen distintas implementaciones de esta técnica en Python, y en el proyecto se ha utilizado la referenciada en [24] que utiliza un modelo de red basado en Keras.. 3.5. Planificación y fases del proyecto. A continuación se detallan los pasos seguidos para la realización del proyecto, partiendo de las bases mencionadas en la sección ¿De dónde partimos? de este capı́tulo, hasta llegar a la versión funcional presentada en este trabajo.. 16.

(28) • Paso de BitScreen PTB a BitScreen Master. La primera versión que se desarrolló de la nueva plataforma fue una versión que se denominó Master, y que consistió en trasladar la plataforma BitScreen PTB, especializada en tuberculosis infantil, a una plataforma no especializada con formularios de examinación y evaluación de ámbito general. Las actividades que se realizaron para llegar a esta versión fueron las siguientes: – Crear una base de datos para BitScreen Master. El modelo de esta base de datos será el mismo que para BitScreen PTB, es decir, mismas tablas, misma estuctura de datos y mismo contenido en algunas tablas, con el añadido de cinco tablas más que se introducen automáticamente al instalar el paquete Oauth2 en las dependencias, utilizado para el envı́o de correos electrónicos desde la aplicación. – Modificar las vistas y los formularios para la creación de un estudio, y añadir los campos correspondientes a la base de datos. Los estudios en BitScreen PTB contenı́an un apartado de antecedentes personales vinculados al caso de tuberculosis, por lo que estos campos fueron sustituidos en BitScreen Master por otros para la introducción de datos clı́nicos generales del paciente, relevantes para cualquier caso de estudio. Además, las imágenes adquiridas consistı́an en radiografı́as de tórax , y por lo tanto existı́an campos relacionados con la posición y tipo de imagen que fueron sustituidos por otros de propósito general. – Modificar las vistas y los formularios para la evaluación de un estudio, y añadir los campos correspondientes a la base de datos. Las evaluaciones estaban centradas en la identificación de hallazgos de tuberculosis en las radiografı́as de tórax adquiridas por el examinador. Por lo tanto, se sustituyó este formulario por otro consistente en dos apartados, un apartado de visualización y valoración de las imágenes subidas, con campos relacionados con la calidad de la imagen y observaciones, y un apartado de evaluación general en el que se indique si hay presencia de patologı́as. – Introducir servidor de correo para la gestión de las cuentas de usuario. Finalmente, se introdujeron en BitScreen Master las vistas y las funciones de control encargadas de gestionar el envı́o de los mensajes de correo electrónico a los usuarios desde la plataforma, en las situaciones explicadas en el apartado de Requisitos funcionales y casos de uso de este capı́tulo. Además, se añadió a la configuración de la plataforma la conexión a un servidor de correo de Google para esta funcionalidad. • Paso de BitScreen Master a BitScreen OPH. Esta fase de desarrollo partió de la versión Master para crear la plataforma OPH de oftalmologı́a especializada en el caso de glaucoma, y consistió en los pasos que se explican a continuación. – Crear una base de datos para BitScreen OPH. El modelo de esta base de datos será el mismo que para BitScreen Master. – Añadir a las vistas de creación de un estudio un apartado de historial personal y familiar de glaucoma, y especializar el apartado de subida de las imágenes para el caso de imágenes de ojo, añadiendo campos de tipo de imagen, posición 17.

(29) y ojo al que corresponden, con las opciones ”izquierdo” o ”derecho”. Crear en la base de datos los campos correspondientes. – Modificar las vistas de evaluación de un estudio, adaptando el apartado de visualización y análisis de las imágenes adquiridas para imágenes de ojo, y especializando el apartado de evaluación global para el caso de diagnóstico de glaucoma. • Integración del modelo CAD en BitScreen OPH. Esta ha sido la última fase del proyecto y ha consistido en cinco pasos, (1) integración del modelo de aprendizaje profundo en una REST API para su despliegue en un servidor. (2) Creación de un script ejecutable en el lado del cliente y que se conecte con el servidor REST API. Este script enviará las imágenes de fondo de ojo para su clasificación y recibirá el resultado del modelo, generarando además las imágenes para la visualización de la información cualitativa del sistema que almacenará en la plataforma. (3) Invocación al script desde la plataforma por las funciones de control de los estudios, al enviar (store) o actualizar (update) los estudios para su evaluación. (4) Almacenar los resultados (prediction y score) de la clasificación automática en la base de datos, asociandos a cada imagen de test adquirida en el estudio. (5) Añadir el acceso a los resultados de la clasificación desde el formulario de evaluación y recuperar los resultados de la base de datos y la visualización de la información cualitativa.. 18.

(30) Capı́tulo 4 Resultados y plan de pruebas En este capı́tulo se mostrarán los resultados del trabajo y se desarrollará un plan de pruebas dividido en dos bloques. Por un lado, se definirá una tabla con los requisitos técnicos que tendrá que cumplir la aplicación web y se irá comprobando uno por uno si se cumple un funcionamiento correcto. Por otro lado, se hará una prueba de las tasas de acierto del modelo de predicción sobre unos datos de test, para sacar conclusiones sobre los parámetros de sensibilidad y especificidad del sistema.. 4.1. Herramienta para la Detección Precoz de Glaucoma: BitScreen OPH. La plataforma permite la evaluación remota por expertos clı́nicos de imágenes de fondo de ojo para la detección de glaucoma en ellas. Este proceso se realiza siguiendo una técnica de store-and-forward, que consiste en almacenar en la aplicación los datos médicos y las imágenes adquiridas de los pacientes, para posteriormente ser utilizados por los evaluadores de los casos. La plataforma ofrece distintas funcionalidades según el rol que tenga el usuario. El administrador podrá registrar centros médicos que hagan uso de la plataforma, añadir pacientes y dar de alta y gestionar los usuarios médicos activos; el técnico o examinador abrirá los casos de estudio asociados a cada paciente y los enviará para su evaluación; y finalmente, el evaluador hará uso de los datos e imágenes adquiridas por el examinador para estudiar el caso y diagnosticar si hay indicios de patologı́as. En los apartados siguientes se presentarán los resultados de la plataforma y se explicará sobre estos el funcionamiento de la aplicación.. 19.

(31) 4.2. Arquitectura Global de la Herramienta. Figure 4.1: Arquitectura global.. 4.3. Resultados de la aplicación web. En numerosas ocasiones se ha referido al aprendizaje automático como perteneciente al marco de tecnologı́as de Inteligencia Artificial (IA). Este ha sido el término utilizado por 20.

(32) simplicidad en la aplicación web para referirse a esta tecnologı́a, por lo que de ahora en adelante se hará referencia en el documento a este concepto de la misma forma.. 4.3.1. Inicio de sesión. Figure 4.2: Pantalla de bienvenida.. La primera vista que se se tendrá al iniciar la plataforma es la de bienvenida, y esta dará acceso al formulario de registro para el usuario.. 21.

(33) Figure 4.3: (a) Registro de usuario. (b) El nombre de usuario o la contraseña son incorrectos. (c) Situación de bloqueo: se han introducido mal más de tres veces los datos de registro.. En caso de que el usuario haya olvidado su contraseña, podrá solicitar vı́a correo electrónico el envı́o de un formulario para elegir una nueva, activando el botón Forgot your password?. Esta solicitud será realizable siempre que el usuario no se encuentre bloqueado.. 22.

(34) Figure 4.4: Introducir el correo si olvido de contraseña.. Figure 4.5: Mensaje de correo recibido para recuperar la contraseña.. 23.

(35) Figure 4.6: (a) Formulario para introducir nueva contraseña. (b) Error: Las credenciales introducidas no coinciden.. Figure 4.7: Mensaje de confirmación. Si se pulsa en Continue se redirige al usuario al formulario de Inicio de sesión.. 4.3.2. Login como usuario administrador. La primera página a la que tienen acceso los usuarios es la que se muestra debajo, la cual es común para todos y únicamente difiere en el menú de opciones desplegable situado en la parte superior derecha de la pantalla. Este menú contiene las opciones a las que puede acceder el usuario, y serán diferentes según las competencias que tenga.. 24.

(36) Figure 4.8: Vista home para el usuario administrador.. Si se pulsa en la opción de Users, la plataforma redirigirá al administrador a la lista de usuarios registrados en la aplicación, y desde esta lista podrá dar de alta a nuevos, pulsando en Create, o editar los datos de usuarios ya existentes, pulsando en el icono de la derecha asociado a cada uno.. Figure 4.9: Índice de los usuarios médicos dados de alta en la plataforma.. 25.

(37) Figure 4.10: Formulario para crear un nuevo usuario.. Tras guardar los datos del usuario creado, la plataforma enviará automáticamente un correo electrónico a este para finalizar el proceso de registro. La imagen mostrada a continuación contiene la vista correspondiente al formulario de edición de un usuario ya creado. Es importante resaltar la opción Send restore password link situada en la esquina superior derecha de la pantalla. El administrador permitirá con esta opción que el usuario reactive su cuenta si ha sido bloqueado por la aplicación, enviándole la plataforma un correo electrónico con el formulario correspondiente. Las situaciones de uso del servidor de correo desde la apliación se explican en detalle en la sección de Requisitos funcionales y casos de uso del Capı́tulo 3 de este documento. En las dos situaciones mencionadas en este punto, la forma de los correos y la estructura de los formularios enviados es muy similar a los ya vistos en el apartado de Inicio de sesión de este capı́tulo.. 26.

(38) Figure 4.11: (a) Formulario para editar los datos de un usuario. (b) Los cambios se han guardado correctamente.. Si el administrador pulsa la opción de Medical Centers en su menú desplegable, será redirigido a la lista de centros médicos registrados en la aplicación. Tanto los pacientes como los usuarios médicos dados de alta en la plataforma pertenecerán a un centro médico. Desde esta vista el administrador podrá introducir un nuevo centro, pulsando en el botón Create, o editar los datos de un centro ya existente, pulsando el botón de edición para cada ı́tem.. 27.

(39) Figure 4.12: Índice de los centros médicos vinculados a la plataforma.. 28.

(40) Figure 4.13: Formulario para editar los datos de un centro médico.. Figure 4.14: (a) Formulario para crear un nuevo centro médico. (b) Formulario para editar los datos de un centro médico. (c) El centro médico se ha añadido correctamente.. Si el administrador pulsa la opción de Contact en el menú desplegable, podrá ver los datos de contacto del personal administrativo de la plataforma, ası́ como un mapa con la localización de la ETSIT. Por otro lado, desde My Profile se accederá a la vista que se muestra a continuación, donde el usuario podrá añadir o cambiar los datos personales asociados a su perfil. Estas opciones también estarán disponibles para los usuarios médicos.. 29.

(41) Figure 4.15: Formulario para editar los datos de mi perfil.. Finalmente, la opción Patients del menú dará acceso a la lista de pacientes registrados en la plataforma. Desde esta vista el administrador podrá crear un nuevo paciente asociado a un centro médico determinado, editar los datos de un paciente que ya existe o visualizar los estudios asociados a este paciente. La tabla se podrá ordenar por orden alfanumérico según los datos de las columnas de ID del paciente y de Fecha de registro. El administrador podrá visualizar los estudios creados por cualquiera de los usuarios técnicos, independientemente del estado en el que se encuentren: pendientes de enviar a evaluar, en evaluación o cerrados, pero no podrá modificar ningún dato de estos. Únicamente los usuarios técnicos podrán editar los datos de los estudios a los que tiene acceso el administrador.. 30.

(42) Figure 4.16: Índice de los pacientes registrados en la plataforma.. 31.

(43) Figure 4.17: Formulario para registrar un nuevo paciente en la plataforma.. Figure 4.18: Formulario para editar los datos de un paciente.. 32.

(44) Figure 4.19: Índice de los estudios asociados a un paciente.. A continuación, se incluye la vista de un estudio de ejemplo al que tiene acceso el administrador.. 33.

(45) Figure 4.20: Visualización de un estudio.. 4.3.3. Login como usuario técnico o examinador. El usuario técnico, o examinador, tendrá acceso a las opciones del menú desplegable mostrado en la parte superior derecha de la siguiente imagen.. 34.

(46) Figure 4.21: Vista home para el usuario técnico.. La opción Studies del menú permitirá al usuario acceder a una lista con todos los estudios creados, ya sea guardados sin enviar, enviados o cerrados, de los que es responsable.. Figure 4.22: Índice de los estudios asociados al usuario.. 35.

(47) Por otro lado, si el usuario pulsa en Patients accederá a la misma lista de pacientes que la mostrada con el administrador. Desde esta podrá obtener la lista de estudios asociada a cada paciente, y le será permitido crear, editar nuevos estudios, y visualizar los estudios cerrados con el resultado de las evaluaciones.. 36.

(48) Figure 4.23: (a) Formulario para la creación de un nuevo estudio. Las distintas secciones son desplegables. (b) Resultado de guardar estudio.. Las imágenes anteriores muestran el formulario de creación de un nuevo estudio y el resultado de pulsar la opción de guardar los datos. Los campos marcados con un asterisco son de relleno obligatorio para que la aplicación permita el envı́o del estudio al evaluador. Además, para poder enviar el formulario a evaluación es necesario haber subido al menos una imagen de test. En caso de que faltase algún campo obligatorio o que no se hubiese insertado ningún fichero de test, darı́a error en el formulario y marcarı́a estos campos en rojo o indicarı́a el problema en un mensaje, recuperando los datos que ya habı́a seleccionados para no tener que empezar de nuevo utilizando la sesión. No obstante, el usuario siempre tiene la posibilidad de guardar el formulario para seguir editándolo posteriormente sin necesidad de introducir todos los datos obligatorios. Tanto si se selecciona esta opción como si se envı́a el formulario para evaluación, los campos escritos y los de test se almacenarán en la base de datos de la que hace uso la plataforma, asociados al estudio creado, para posteriormente ser recuperados por el evaluador o por el mismo usuario si desea editarlos o visualizarlos. A continuación, se muestra el formulario para la edición del estudio que anteriormente se ha puesto como ejemplo. Este formulario es el mismo tanto en el caso de que el estudio esté pendiente de completarse como en el caso de que se haya enviado a evaluación y esté pendiente del resultado. Una vez se envı́e el estudio al evaluador, podrá editarse pero no eliminarse.. 37.

(49) Figure 4.24: Formulario para editar los datos de un estudio antes de enviarlo.. 38.

(50) Figure 4.25: Resultado de enviar el estudio a evaluación.. Figure 4.26: Estudio cerrado.. Para terminar este apartado, se añaden las capturas del estudio de ejemplo tras haberse completado el proceso de evaluación. La sección siguiente abarcará en detalle los resultados de este proceso.. 39.

(51) 40.

(52) Figure 4.27: (a) Visualizar estudio cerrado. (b) Los datos clı́nicos del estudio podrán visualizarse pulsando el botón de Study Data.. 4.3.4. Login como usuario evaluador. El evaluador tendrá acceso a las opciones del menú desplegable mostrado en la siguiente imagen.. Figure 4.28: Vista home para el usuario evaluador.. 41.

(53) Si el usuario pulsa en la opción Studies será redirigido a la lista con las evaluaciones que tiene asignadas, ya sea en estado pendiente, en proceso de evaluación o finalizadas.. Figure 4.29: Índice de las evaluaciones asignadas al usuario.. Las distintas secciones de la evaluación son desplegables, al igual que en los estudios, para mayor comodidad de los usuarios. A continuación, se muestran los formularios de las evaluaciones por secciones para una evaluación creada a modo de ejemplo. Todos los campos seleccionables son obligatorios para poder cerrar el caso. No obstante, y de la misma forma que ocurrı́a en la creación de los estudios, el evaluador puede guardar la evaluación en proceso para seguir editándola más adelante, sin necesidad de escribir todos estos campos. Los datos se irán almacenando temporalmente en la sesión, y si se guarda o se cierra el estudio se almacenan o actualizan en la base de datos, asociados a la evaluación correspondiente.. 42.

(54) Figure 4.30: Sección con los datos clı́nicos del paciente, adquiridos por el usuario técnico.. En la sección de Tests el evaluador podrá ir navegando por las distintas imágenes subidas, y en el caso de que haya alguna imagen de fondo de ojo entre ellas, podrá acceder a los resultados de la clasificación automática realizada por la IA de forma independiente para cada caso. Esto podrá hacerlo pulsando sobre el icono disponible para ello, y se abrirá una ventana emergente que mostrará estos resultados, ası́ como una imagen generada a partir información cualitativa obtenida por la red. Desde esta ventana el usuario podrá descargar la imagen pulsando la opción de Download habilitada para ello.. 43.

(55) Figure 4.31: (a) Formulario de evaluación para Test 1 subido a modo de ejemplo. (b) Resultados de la IA para Test 1.. 44.

(56) Figure 4.32: (a) Formulario de evaluación para Test 2 subido a modo de ejemplo. (b) Resultados de la IA para Test 2.. 45.

(57) La sección de Evaluación global constará de un apartado para cada caso de análisis deseado en el proceso de cribado. La plataforma actualmente abarca únicamente el caso de Glaucoma, pero se encuentra preparada para poder añadir más casos patológicos en un futuro si ası́ se desea.. Figure 4.33: Evaluación global.. Por último, se muestra la visualización del estudio para el usuario evaluador, una vez se haya finalizado la evaluación y se haya cerrado el caso.. 46.

(58) 47.

(59) 48.

(60) Figure 4.34: Vista del estudio terminado para el evaluador.. 4.4. Resultados del servidor REST API para el modelo de Deep Learning. En esta sección se muestra un ejemplo del funcionamiento del servidor REST API que contiene el modelo de Deep Learning. Se ha ejecutado en un terminal de usuario el script de Python que utiliza la plataforma para realizar las peticiones al servidor. Este script se ejecuta en el lado del cliente y necesita dos argumentos: python <script> -f <ruta a las imágenes> -p <ruta de almacenamiento de las imágenes de info cualitativa>. El script envı́a las imágenes al servidor como una petición POST. El servidor devuelve una respuesta a cada petición REST en forma de diccionario JSON. Este objeto contiene cuatro mensajes: en primer lugar, un mensaje de confirmación; en segundo lugar, el resultado de la predicción asociado a la imagen enviada como clave, que se muestra como salida en el terminal; en tercer lugar, una matriz numérica que contiene los valores RGB de la imagen de entrada preprocesada; y por último, la información cualitativa en forma de matriz numérica. El script del lado del cliente obtiene una imagen en forma 49.

(61) de mapa de calor asociada a la información cualitativa, y la almacena en la ruta añadida como argumento al script, junto con la imagen original, preprocesada por el servidor y reconstruida en el lado cliente a partir de la matriz RGB recibida. A continuación, se muestra el resultado de enviar, en el primer ejemplo, una imagen al servidor, y en el segundo, dos imágenes, que se encuentran en la carpeta de trabajo local. Las imágenes de información cualitativa almacenadas reciben el nombre introducido como argumento al script, y la imagen original reconstruida, recibe este mismo nombre seguido de la extensión ’ orig’.. Figure 4.35: Resultado de enviar una imagen al servidor.. Figure 4.36: Resultado de enviar dos imágenes al servidor.. 50.

(62) 4.5. Modelo de la base de datos de BitScreen OPH. Como ya se comentó en el apartado Planificación y fases del proyecto del Capı́tulo 3, el modelo de la base de datos utilizado en la aplicación ha sido heredado ı́ntegramente de la plataforma BitScreen Master, a su vez basado en el modelo utilizado por BitScreen PTB con el añadido de cinco tablas más por el uso del paquete Oauth2 para el envı́o de correos. Únicamente se utilizará la tabla oauth access tokens de las nuevas creadas para el almacenamiento de los tokens generados con los correos enviados al usuario. De esta forma, la estructuración de la base de datos de BitScreen OPH consiste en el uso relacional de 38 tablas. A continuación se muestra una tabla con los campos más importantes de las tablas utilizados por la aplicación.. 51.

(63) Nombre de la Tabla addresses countries diagnosisfields diagnosisfields values diagnostics diagnosticsset examinationfields examinationfields values examinations examinationsets healthprofessionals medicalcenters medicalcenters types oauth access tokens patients personalid types persons provinces race types regions roles roles users specialities status studies users. Campos utilizados who id, country id, address, city, postal code, region, phone code, name code, speciality id, type, name diagnosisfield id, value code, description who id, study id, diagnosisfield id, owner id, value, value fixed, value text who id, study id, diagnosisfield id, diagnosis id, value, value fixed, value text code, speciality id, type, name examinationfield id, value code, description who id, study id, examinationfield id, owner id, value, value fixed, value text who id, study id, examinationfield id, examination id, value, value fixed, value text who id, person id, medicalcenter id, speciality id, professional code who id, medicalcenterparent id, name, medicalcentertype id, address id, admin id, is active code, description id, user id who id, person id, medicalcenter id, sns code code, name, description who id, user id, name, last name, personal id, address id, personalidtype id, birth date, gender, racetype id, phone code, postal code, name, region id, country id code, name, description code, code num, name, country id name, description user id, role id role id, code, name name who id, studytype id, patient id, status id, speciality id, examiner id, evaluator id login, email, password, status, error access, password updated at, last access at. 52.

(64) 4.6. Plan de pruebas. El plan de pruebas realizado se ha dividido en dos bloques: Por un lado, se ha probado que la aplicación web cumple con los requisitos funcionales y no presenta fallos técnicos. Por otro lado, se ha probado el modelo de Deep Learning sobre un conjunto de imágenes de test, que no han sido utilizadas en la fase de entrenamiento de la red, y se ha evaluado su comportamiento a partir de la obtención de los parámetros de sensibilidad y especificidad del sistema.. 53.

(65) 4.6.1. Tabla de pruebas realizadas para la aplicación. Prueba realizada Error al introducir mal las credenciales Inicia sesión si los datos de usuario son correctos El usuario recibe un correo y puede cambiar de contraseña únicamente si está activo (RF32, RF42). Resultado 3 3 3. Si se da el caso anterior, la contraseña del usuario se actualiza correctamente en la base de datos (RF32, RF42). 3. Si el usuario introduce mal sus credenciales más de tres veces, su estado cambia a blocked y no puede acceder (RF7). 3. El caso anterior no se da nunca para el usuario administrador (RF11). 3. Si se da el caso anterior, el administrador puede enviar el permiso de reactivación al correo (RF8). 3. Si se da el caso anterior, el usuario puede reactivar su cuenta y cambia su estado a active (RF9). 3. El usuario puede acceder a cada una de las opciones de su lista. 3. El administrador puede crear y editar un centro médico (RF1). 3. El administrador no puede eliminar un centro médico con usuarios, pacientes o centros asociados Los datos del céntro médico se guardan y recuperan correctamente de la base de datos El administrador puede crear y editar un usuario (RF2). 3. Los datos del usuario se guardan y recuperan correctamente Los usuarios reciben un correo para finalizar el proceso de registro (RF4). 3 3. El estado de los usuarios cambia de pending a active cuando finalizan el registro (RF3, RF5). 3. Los usuarios examinador y administrador pueden crear y editar los datos de un paciente (RF14, RF20). 3. Los usuarios examinador y administrador no pueden eliminar un paciente que tenga estudios asociados. 3. Los datos de los pacientes se guardan y recuperan correctamente de la base de datos El administrador puede visualizar los estudios asociados a un paciente (RF15, RF16). 7(solucionado). El examinador puede crear estudios y editar o visualizar lo estudios asociados a cada uno de los pacientes de la plataforma (RF23, RF29). 3. El examinador puede guardar un estudio incompleto sin rellenar los campos obligatorios (RF24). 3. 54. 3 3. 3.

(66) Prueba realizada Si el examinador envı́a el estudio a evaluación pero falta algún requisito obligatorio, la plataforma no lo envı́a y lanza un mensaje de error (RF25). Resultado 3. En caso de error, se recuperan de la sesión los datos escritos de los estudios Los datos de los estudios se guardan y se recuperan correctamente de la base de datos Tras enviar un estudio a evaluación, se almacenan los resultados de la IA en la base de datos (RF26). 3. Tras enviar un estudio a evaluación, se almacenan las imágenes de info cualitativa en el mismo directorio que las imágenes de test (RF27). 3. El evaluador tiene acceso a los estudios asignados a él para evaluación (RF33). 3. El evaluador puede iniciar y editar estudios, y visualizar estudios cerrados (RF34). 3. El evaluador tiene acceso a los datos clı́nicos subidos del paciente en los estudios (RF35). 3. El evaluador tiene acceso a los resultados de la clasificación de la IA (RF36). 3. El evaluador puede visualizar y descargar las imágenes de test subidas por el examinador (RF35). 3. El evaluador puede visualizar y descargar las imágenes con la información cualitativa obtenida por la IA (RF36). 3. El evaluador puede guardar una evaluación incompleta sin rellenar los campos obligatorios (RF38). 3. Los datos de las evaluaciones se guardan y se recuperan correctamente de la base de datos Cuando el evaluador cierra un estudio, el examinador lo visualiza como cerrado y puede acceder a los resultados de la evaluación (RF29). 3. Los usuarios pueden acceder y modificar sus datos de perfil (RF17, RF31, RF41). 3. 4.6.2. 3 3. 3. Prueba del modelo de Deep Learning sobre un conjunto de datos de test. Para evaluar el comportamiento del modelo y comparar su precisión en los resultados con la tasa de acierto de los especialistas médicos, se ha aplicado el modelo sobre un set de 66 imágenes de test, que no han sido utilizadas en las fases de entrenamiento o validación de la red. El modelo clasifica los resultados en dos clases distintas: la clase 55.

Figure

Actualización...

Referencias

Actualización...