UroAnalytics: predicción y gestión de datos para una unidad de uro-oncología

Trabajo de Fin de Grado de Ingeniería Informática y del Grado en Ingeniería de Computadores, Facultad de Informática UroAnalytics: predicción y gestión de datos para una unidad de uro-oncología. UroAnalytics: data prediction and management for a unit of uro-oncology. Autores: Laura Falque González (GII), Mariana de la Caridad Villar Rojas (GII), Richard Junior Mercado Correa (GII), Mateo González de Miguel (GIC), Maryny Zara Castada Collado (GII) Director: Antonio Sarasa Cabezuelo Codirector: Javier Cambronero Santos Curso académico 2021/2022 ÍNDICE AGRADECIMIENTOS .......................................................................................................................... 1 RESUMEN ............................................................................................................................................. 2 ABSTRACT ............................................................................................................................................ 3 CAPÍTULO 1. INTRODUCCIÓN ......................................................................................................... 4 1.1. MOTIVACIÓN ....................................................................................................................... 4 1.2. OBJETIVOS ........................................................................................................................... 4 1.3. PLAN DE TRABAJO ............................................................................................................. 5 CHAPTER 1. INTRODUCTION ........................................................................................................... 7 1.1. MOTIVATION ....................................................................................................................... 7 1.2. OBJECTIVES ......................................................................................................................... 7 1.3. WORK PLAN ......................................................................................................................... 8 CAPÍTULO 2. ESTADO DEL ARTE .................................................................................................. 10 CAPÍTULO 3. TECNOLOGÍAS EMPLEADAS ................................................................................. 11 3.1. Git ......................................................................................................................................... 11 3.2. Visual Studio Code ............................................................................................................... 11 3.3. Bootstrap ............................................................................................................................... 11 3.4. PHP ....................................................................................................................................... 11 3.5. JavaScript .............................................................................................................................. 12 3.6. Python ................................................................................................................................... 12 3.7. Jupyter ................................................................................................................................... 12 3.8. Base de datos ......................................................................................................................... 12 CAPÍTULO 4. ESPECIFICACIÓN DE REQUISITOS ....................................................................... 14 4.1. Actores .................................................................................................................................. 14 4.2. Casos de uso .......................................................................................................................... 14 4.2.1. Casos de uso para el actor User .................................................................................... 14 4.2.2. Casos de uso para el actor Admin ................................................................................. 28 CAPÍTULO 5. ARQUITECTURA DE LA APLICACIÓN ................................................................. 31 CAPÍTULO 6. MODELO DE DATOS ................................................................................................ 33 6.1. Tabla patients ........................................................................................................................ 33 6.2. Tabla users ............................................................................................................................ 37 CAPÍTULO 7. DISEÑO ....................................................................................................................... 39 7.1. Estilo ..................................................................................................................................... 39 7.2. Colores .................................................................................................................................. 39 7.3. Principios de diseño .............................................................................................................. 40 7.3.1. Principio de consistencia interna y externa ................................................................... 40 7.3.2. Principio de cierre ......................................................................................................... 41 7.3.3. Principio de gestión del estado visible .......................................................................... 42 7.3.4. Principio de proximidad ................................................................................................ 42 7.3.5. Principio de visibilidad y feedback ............................................................................... 43 CAPÍTULO 8. IMPLEMENTACIÓN .................................................................................................. 45 8.1. MÓDULO USUARIO .......................................................................................................... 45 8.1.1. Registro ......................................................................................................................... 45 8.1.2. Solicitudes de registro ................................................................................................... 48 8.1.3. Inicio de sesión (Login) ................................................................................................ 53 8.1.4. Cerrar sesión ................................................................................................................. 57 8.2. MÓDULO PACIENTES ........................................................................................................... 58 8.2.1. Visualizar pacientes ...................................................................................................... 59 8.2.2. Añadir paciente ............................................................................................................. 62 8.2.3. Ver estadísticas ............................................................................................................. 64 8.2.4. Exportar pacientes ......................................................................................................... 68 8.2.5. Importar pacientes ......................................................................................................... 69 8.3. MÓDULO CONSULTAS.......................................................................................................... 70 8.3.1. Inicio consulta ............................................................................................................... 71 8.3.2. Ver tabla ........................................................................................................................ 74 8.3.3. Ver estadísticas ............................................................................................................. 75 8.3.4. Ver detalles ................................................................................................................... 75 8.3.5. Exportar consulta .......................................................................................................... 78 CAPÍTULO 9. MÓDULO PREDICCIONES ....................................................................................... 79 9.1. Limpieza de los datos ............................................................................................................ 79 9.2. Modelos de predicción .......................................................................................................... 82 9.2.1. Descripción inicial de los datos .................................................................................... 83 9.2.2. Limpieza de columnas con filas vacías ......................................................................... 84 9.2.3. Visualización general y estudio de los datos ................................................................. 86 9.2.4. Generación de los modelos de predicción ..................................................................... 91 9.3. Predicciones ........................................................................................................................ 109 9.4. Frontend del apartado de Predicciones ............................................................................... 116 9.4.1. Importación de datos del paciente ............................................................................... 119 9.4.2. Predicción con los datos del formulario ...................................................................... 125 CAPÍTULO 10. CONCLUSIONES Y TRABAJO FUTURO ............................................................ 128 10.1. Conclusiones ................................................................................................................... 128 10.2. Trabajo Futuro................................................................................................................. 128 CHAPTER 10. CONCLUSIONS AND FUTURE WORK ................................................................ 130 10.1. Conclusions ..................................................................................................................... 130 10.2. Future Work .................................................................................................................... 130 CAPÍTULO 11. TRABAJO INDIVIDUAL ....................................................................................... 132 CAPÍTULO 12. ANEXO .................................................................................................................... 141 12.1. Diagramas de actividad ................................................................................................... 141 12.2. Guía de usuario ............................................................................................................... 154 12.2.1. Login ....................................................................................................................... 154 12.2.2. Registro ................................................................................................................... 157 12.2.3. Página de inicio ....................................................................................................... 158 12.2.4. Consultas ................................................................................................................. 160 12.2.5. Predicciones ............................................................................................................ 167 12.2.6. Pacientes ................................................................................................................. 170 12.2.7. Manual de usuario ................................................................................................... 174 12.2.8. Cuenta del usuario .................................................................................................. 174 12.2.9. Peticiones de registro .............................................................................................. 176 BIBLIOGRAFÍA ................................................................................................................................ 177 1 AGRADECIMIENTOS Habiendo terminado el TFG, nos damos cuenta de lo largo y difícil que ha sido este camino universitario, y que no habría sido posible sin la ayuda de muchas personas. En primer lugar, queremos agradecer a nuestro tutor, Antonio Sarasa Cabezuelo, el cual nos ha acompañado en este proceso, aportándonos su sabiduría y experiencia. Por otro lado, damos las gracias al Hospital Infanta Leonor, concretamente al doctor Javier Cambronero Santos por haber colaborado con nosotros y aportarnos los elementos necesarios para la realización de nuestro proyecto. Por último, pero no menos importante, a nuestros familiares, por toda su comprensión y apoyo en los mejores y peores momentos. 2 RESUMEN El cáncer de próstata es uno de los tumores con mayor prevalencia en la actualidad. Hay muchas variables que influyen en el desarrollo de esta enfermedad, por lo que los especialistas necesitan una gran cantidad de datos para poder estudiar las causas y consecuencias de esta enfermedad, así como encontrar los métodos más efectivos para poder tratarla. Una de las variables más relevantes es la recidiva bioquímica, que indica si un paciente vuelve a tener un tumor activo tras el tratamiento radical primario. En este trabajo se ha propuesto crear una herramienta que sea capaz de gestionar un conjunto de datos relacionados con el cáncer de próstata, con el objetivo de facilitar la labor del médico especialista en Urología para realizar un correcto seguimiento y predicción del riesgo de recidiva. En este sentido, la aplicación es capaz de predecir si, a partir de un conjunto de datos, un paciente padecerá de recidiva bioquímica utilizando técnicas de Machine Learning. El conjunto de datos utilizado para entrenar a los modelos de Machine Learning contiene información relacionada con el seguimiento de 269 pacientes, en la que cada uno posee información en más de 50 variables durante un periodo que va desde el año 2008 hasta el año 2015. PALABRAS CLAVE Cáncer, próstata, predicción, consultas, machine learning, recidiva bioquímica, Urología, Urooncología 3 ABSTRACT Prostate cancer is one of the most prevalent tumors today. There are many variables that influence the development of this disease, so specialists need a large amount of data to be able to study the causes and consequences of this disease, as well as to find the most effective methods to treat it. One of the most relevant variables is biochemical recurrence, which indicates whether a patient has an active tumor again after primary radical treatment. In this work we have proposed to create a tool that is able to manage a set of data related to prostate cancer, with the aim of facilitating the work of the Urology specialist to perform a correct monitoring and prediction of the risk of recurrence. In this sense, the application is able to predict whether, from a set of data, a patient will suffer from biochemical recurrence using Machine Learning techniques. The dataset used to train the Machine Learning models contains information related to the follow-up of 269 patients, in which each patient has information on more than 50 variables during a period ranging from 2008 to 2015. KEYWORDS Cancer, prostate, prediction, consultations, machine learning, biochemical recurrence, Urology, Uro-oncology 4 CAPÍTULO 1. INTRODUCCIÓN En este capítulo se describe la problemática por la que nace este proyecto y su respectiva solución. Además, se plantean los objetivos para el desarrollo de este proyecto. 1.1. MOTIVACIÓN El problema que se quiere solucionar con esta aplicación es la dificultad que supone detectar un posible caso de recidiva de cáncer de próstata. Los modelos de predicción utilizados en la unidad de Uro-oncología del Hospital Universitario Infanta Leonor están basados en regresiones lineales, las cuales son conocidas por ser muy simples, y en curvas Cox. Asimismo, la gestión de pacientes se realiza mediante hojas Excel. Una posible solución al problema de la predicción de riesgo sería la del estudio de los datos para determinar qué modelos de predicción son los más adecuados en este caso. En lo referente a la gestión y manejo de datos, la mejor solución sería diseñar una aplicación web, capaz de conectarse a una base de datos, en la que poder realizar operaciones y consultas sobre una tabla de pacientes. Para unificar estas dos soluciones, se ha propuesto crear una aplicación web que resuelva los problemas descritos anteriormente, es decir, manipular los datos de los pacientes de manera gráfica y sencilla y generar predicciones sobre un paciente dado, habiendo realizado un estudio previo sobre los datos iniciales, utilizando técnicas de Machine Learning con los siguientes modelos: kNN, regresión logística y random forest. 1.2. OBJETIVOS El objetivo principal de este proyecto es la creación de una herramienta que permita a un médico experto en Uro-oncología analizar datos de pacientes con cáncer de próstata con el objetivo de predecir la posibilidad de que un paciente padezca de recidiva bioquímica. Este objetivo principal se particulariza en los siguientes objetivos más específicos: ● Realizar un estudio de los datos para poder comprenderlos. De esta forma, se pueden generar modelos de predicción capaces de pronosticar de manera efectiva los casos de recidiva bioquímica. 5 ● Crear una aplicación web para que un médico pueda realizar sus estudios de forma intuitiva. ● Generar los modelos de predicción, basados en los algoritmos de Random Forest, kNearest Neighbours y Regresión Logística. La limpieza y la correcta selección de los datos, así como el establecimiento de los parámetros adecuados permitirán tener modelos de predicción precisos y efectivos. ● Facilitar la gestión e incorporación de los datos. ● Mostrar al médico gráficos de los datos más relevantes, así como informes de consultas. ● Facilitar la capacidad de importar y exportar datos de manera masiva y sencilla a través de hojas de Excel. ● Ofrecer un sistema de gestión de usuarios con acceso autenticado que restrinja el uso a los médicos registrados en la aplicación. 1.3. PLAN DE TRABAJO Para llevar a cabo el proyecto se definió un plan de trabajo con distintas fases. Para cada una de estas fases se establecieron uno o varios objetivos a conseguir. El calendario de trabajo se muestra en la figura 1. A continuación, se presenta una tabla con el plan de trabajo. FASE OBJETIVOS HORAS 1 Establecer las funcionalidades y objetivos principales del proyecto 20 2 Especificación de requisitos 20 3 Estudio de las tecnologías a utilizar 40 4 Implementación de la estructura básica de la aplicación 50 5 Estudio de los datos adquiridos 30 6 Limpieza de los datos adquiridos 40 7 Implementación del apartado de Consultas 60 12 3.5. JavaScript JavaScript [5] es un lenguaje de programación que se ha utilizado en la aplicación web para implementar la información dinámica de la interfaz gráfica como es el caso de las gráficas que aparecen en la sección Ver estadísticas de la página de Pacientes. 3.6. Python En el backend se ha utilizado Python [6] para implementar una API con Flask [23], que es un framework de Python. Python es un lenguaje de programación centrado en la legibilidad y simplicidad del código y que dispone de librerías muy útiles para el procesamiento de datos. Además de implementar Flask, Python se ha utilizado para realizar un notebook de Jupyter [7] para pruebas en predicciones. Cabe destacar que en el notebook para el proceso de predicción se ha utilizado la librería Scikit-learn [8] que proporciona los conocimientos básicos del aprendizaje automático y herramientas como por ejemplo el preprocesamiento de datos y ajuste de modelos. Asimismo, se ha hecho uso de las librerías Pandas [24], SQLAlchemy [25] y PandasProfiling [26] de Python para la gestión y visualización de datos a gran escala de manera cómoda y eficiente. 3.7. Jupyter Jupyter es una interfaz web que facilita tareas como limpieza y conversión de datos, distribuidas de forma sencilla y organizada en distintas celdas del notebook. Además, permite incluir especificaciones markdown muy útiles a la hora de documentar cada tarea procesada. Mediante esta herramienta se ha generado un notebook empleado para la realización de pruebas de los diferentes pasos que componen la fase de predicción y volcar el contenido relevante de dichas pruebas en el código de la página de Predicciones de la aplicación web. 3.8. Base de datos Para administrar los datos de la aplicación web se ha utilizado MySQL [9], un sistema de gestión de bases de datos desarrollado por Oracle. 13 Para alojar los datos de la base de datos, se ha utilizado XAMPP [29], ya que esta herramienta que contiene por defecto un servidor Apache para alojar tanto el código PHP del frontend como phpMyAdmin [30] para administrar de manera sencilla la base de datos. 14 CAPÍTULO 4. ESPECIFICACIÓN DE REQUISITOS En este capítulo se describen los actores principales que conforman la aplicación, así como los casos de uso. 4.1. Actores En la aplicación se han definido dos tipos de usuarios: ● User: es el usuario genérico de la aplicación, es decir, un doctor de la unidad de urooncología del hospital, que hará uso de casi todas las funcionalidades implementadas. ● Admin: es un usuario con permisos especiales dentro de la aplicación, con la capacidad de aceptar o denegar peticiones de registro de otros usuarios. Al igual que User, es un doctor del hospital, pero con permisos de administración. 4.2. Casos de uso A continuación, se explican los casos de uso para cada uno de los actores. 4.2.1. Casos de uso para el actor User En la figura 2 se muestra el diagrama de casos de uso del actor User, donde se pueden apreciar todas las acciones que este puede llevar a cabo. 15 Figura 2. Diagrama de casos de uso del actor User. Identificador C001 Nombre Iniciar sesión Descripción El usuario se autentica para poder acceder a la aplicación. Actor principal Usuario y Administrador Actor secundario N/A Datos de entrada Correo electrónico y contraseña. Datos de salida Ventana principal de la aplicación para un usuario autenticado. Precondiciones Debe estar dado de alta previamente por el administrador y existir en la base de datos. Postcondiciones Éxito: El usuario es autenticado y puede acceder a las herramientas de la aplicación. 16 Fallo: Mensaje de error y vuelta a iniciar sesión. Flujo principal 1. El usuario introduce su correo electrónico y contraseña. 2. Se comprueban los datos introducidos. 3. Se confirma la identidad del usuario. 4. Se muestra la ventana principal correspondiente a un usuario autenticado. Flujo alternativo 2.a. No se reconoce los datos introducidos. Se muestra un mensaje de error y se vuelve al paso 1. Identificador C002 Nombre Cerrar sesión Descripción El usuario cierra la sesión de la aplicación. Actor principal User y Admin Actor secundario N/A Datos de entrada N/A Datos de salida Pantalla de inicio de sesión. Precondiciones El usuario debe estar previamente autenticado. Postcondiciones Éxito: Se muestra la pantalla de inicio de sesión. Fallo: Mensaje que muestra el error. Flujo principal 1. El usuario pulsa el botón “Cerrar sesión”. 2. Se cierra la sesión del usuario. 3. Se muestra la pantalla de inicio de sesión. Flujo alternativo 2.a. No se ha podido realizar el cierre de sesión del usuario. Se muestra un mensaje de error. 17 Identificador C003 Nombre Registro Descripción Un nuevo usuario se registra en la aplicación. Actor principal User Actor secundario Admin Datos de entrada Nombre, apellidos, correo electrónico y contraseña. Datos de salida Mensaje por pantalla que dice que el usuario tiene que esperar a que el administrador acepte el registro. La confirmación se notificará a través del correo electrónico proporcionado por el usuario en el registro. Precondiciones Que no exista un usuario en la base de datos con el mismo correo electrónico. Postcondiciones Se muestra un mensaje de que el usuario tiene que esperar un correo electrónico de confirmación. Flujo principal 1. El usuario introduce nombre, apellidos, correo electrónico, nombre de usuario y contraseña. 2. Se comprueba si los datos son válidos. 3. El sistema comprueba si el usuario no existe en la base de datos. 4. Se muestra un mensaje de que el usuario tiene que esperar un correo electrónico de confirmación. Flujo alternativo 2.a. Los datos introducidos no son válidos, se muestra un mensaje de error y se vuelve al paso 1. 3.a. Ya existe el usuario en la base de datos. Se muestra un mensaje de error y se vuelve al paso 1. 18 Identificador C004 Nombre Modificar datos de usuario Descripción El usuario modifica los datos personales de su cuenta. Actor principal User y Admin Actor secundario N/A Datos de entrada Nombre, apellidos, correo electrónico y contraseña. Datos de salida Ventana de confirmación de datos modificados. Precondiciones El usuario debe estar autenticado en la aplicación. Postcondiciones Éxito: Los nuevos datos se han actualizado correctamente en la base de datos. Fallo: Mensaje de error. Flujo principal 1. El usuario selecciona los campos que desea modificar. 2. El usuario modifica los campos seleccionados. 3. El usuario pulsa el botón de confirmar cambios. 4. Se muestra un mensaje de operación realizada. Flujo alternativo 3.a. Los datos introducidos por el usuario no son válidos. Se muestra un mensaje de error y se vuelve al paso 1. Identificador C005 Nombre Eliminar cuenta Descripción El usuario accede a su perfil y elimina su cuenta. Actor principal User y Admin Actor secundario N/A Datos de entrada Solicitud del usuario para eliminar su cuenta. Datos de salida Ventana de confirmación de baja. Precondiciones El usuario debe estar autenticado en la aplicación. 19 Postcondiciones Éxito: El usuario ha sido eliminado de la base de datos. Fallo: Mensaje de error. Flujo principal 1. El usuario pulsa el botón de eliminar cuenta desde su perfil. 2. El usuario es eliminado de la base de datos. 3. Se muestra un mensaje de éxito. Flujo alternativo 1.a. Ocurre un error en el sistema. Se muestra un mensaje de error. Identificador C006 Nombre Realizar consulta Descripción El usuario realiza una consulta filtrando por atributos de pacientes. Actor principal User y Admin Actor secundario N/A Datos de entrada Filtros seleccionados. Datos de salida Datos de pacientes obtenidos por la consulta. Precondiciones El usuario debe estar autenticado en la aplicación y debe haber seleccionado algún filtro previamente a realizar la consulta. Postcondiciones Éxito: Se muestran los datos de la consulta. Fallo: Mensaje de error. Flujo principal 1. El usuario selecciona el filtro que le interesa aplicar y proporciona el o los valores. 2. El usuario pulsa la opción de realizar consulta. 3. El sistema accede a la BBDD y muestra los resultados de la consulta en formato de tabla. Flujo alternativo 1.a. Si los datos proporcionados en el filtro no cumplen los requisitos de rango o tipo se muestra un mensaje de error al usuario. 20 Identificador C007 Nombre Ver tabla consulta Descripción Se le muestra al usuario los datos de la consulta que realizó previamente. Actor principal User y Admin Actor secundario N/A Datos de entrada N/A Datos de salida Datos que se obtienen de la consulta realizada previamente. Precondiciones El usuario debe estar autenticado en la aplicación y debe haber realizado una consulta previamente. Postcondiciones Éxito: Se muestran los datos de la consulta. Fallo: Mensaje de error. Flujo principal Se muestran los datos de la consulta previa en formato de tabla. Flujo alternativo 1.a. Se muestra un mensaje informando al usuario de que no se encuentran datos que concuerdan con la búsqueda realizada en la vista anterior. Identificador C008 Nombre Ver estadísticas consulta Descripción Se le muestra al usuario los datos de la consulta que realizó previamente. Actor principal User y Admin Actor secundario N/A Datos de entrada N/A Datos de salida Datos que se obtienen de la consulta que concuerda con la búsqueda previa. 21 Precondiciones El usuario debe estar autenticado en la aplicación y debe haber realizado una búsqueda correcta en la vista anterior. Postcondiciones Éxito: Se muestran los datos de la consulta. Fallo: Mensaje de error. Flujo principal Se muestran los datos de la consulta previa. Flujo alternativo 1.a. Si no se encuentran datos que concuerden con la consulta previa, la tabla mostrada aparecerá vacía. Identificador C009 Nombre Ver detalles consulta Descripción Se le muestra al usuario los datos de la consulta que realizó previamente. Actor principal User y Admin Actor secundario N/A Datos de entrada N/A Datos de salida Datos que se obtienen de la consulta previa. Precondiciones El usuario debe estar autenticado en la aplicación y debe haber realizado una consulta previamente. Postcondiciones Éxito: Se muestran los datos de la consulta. Fallo: Mensaje de error. Flujo principal 1. El usuario elige ver detalles extendidos (opcional). 2. El usuario excluye datos de los detalles que se generarán (opcional). 3. El usuario indica que quiere ver los detalles. 4. El sistema genera un perfil de datos que se abre en una nueva pestaña. 5. El usuario navega por los datos. 28 Identificador C018 Nombre Ver manual de usuario Descripción El usuario puede visualizar y navegar por el manual de usuario, además de descargarlo si lo desea. Actor principal User y Admin Actor secundario N/A Datos de entrada N/A Datos de salida Información del manual de usuario Precondiciones El usuario debe estar autenticado en la aplicación. Postcondiciones Éxito: Se muestra o se descarga la información referente al manual de usuario. Fallo: Error del sistema. Flujo principal 1. El usuario accede al manual de usuario. 2. El usuario navega entre las diferentes opciones del índice del manual. 3. El usuario descarga el manual de usuario (opcional). Flujo alternativo 1.a. Ocurre un error en el sistema y se informa al usuario. 4.2.2. Casos de uso para el actor Admin En la figura 3 se muestra el diagrama con los casos de uso del actor Admin, que tiene todas las funcionalidades propias del User, pero con la capacidad de gestionar el registro de usuarios. 29 Figura 3. Diagrama de casos de uso del actor Admin. Identificador C019 Nombre Gestionar peticiones de registro Descripción El administrador comprueba si el usuario que se ha registrado es un médico del hospital y confirma el registro de dicho usuario. Actor principal Admin Actor secundario User Datos de entrada Nombre, apellidos y correo electrónico. Datos de salida Ventana de confirmación de registro. Precondiciones El administrador debe estar autenticado en la aplicación. Postcondiciones Éxito: El usuario se ha sido añadido a la base de datos. Fallo: Mensaje de error. 30 Flujo principal 1. El administrador accede a la solicitud de registro del usuario. 2. El administrador acepta la solicitud. 3. Se añade el usuario a la base de datos. 4. Se envía un mensaje al usuario solicitante informando de que ha sido registrado. 5. Se muestra un mensaje de éxito. Flujo alternativo 2.a El administrador rechaza la solicitud. Se elimina la notificación y se envía un mensaje al usuario solicitante informando del rechazo. 31 CAPÍTULO 5. ARQUITECTURA DE LA APLICACIÓN Para desarrollar la aplicación, se ha utilizado la arquitectura cliente-servidor. En esta arquitectura, las tareas se reparten entre los proveedores de servicios, o servidores, y los clientes. Un cliente realiza peticiones a un servidor, y éste genera una respuesta. En la figura 4 se puede observar un esquema del funcionamiento de la aplicación. Figura 4. Esquema de peticiones Este modelo es muy flexible y permite separar las distintas funcionalidades, ofreciendo así un mayor modularidad y una disminución de dependencias entre los distintos componentes. Una de las ventajas de aplicar esta arquitectura es, que, en un caso real de producción, se podría delegar las operaciones más pesadas como, crear modelos de predicción a partir de muchos datos o hacer uso de métodos complejos de librerías de Python, a una máquina más potente, disminuyendo notablemente la carga de trabajo en el dispositivo utilizado por el cliente. Además, si en algún momento surge la necesidad de pasar la aplicación web a otra plataforma como, a una aplicación móvil o de escritorio, se puede realizar el cambio de manera sencilla, ya que gran parte de la funcionalidad se encuentra implementado en el lado del servidor, y solo haría falta modificar el cliente. En cuanto a patrones de diseño, se ha aplicado el patrón Modelo Vista Controlador, que separa los datos, la interfaz gráfica y la lógica. Para ello, esta aplicación consta de dos partes: 32 el frontend para la interfaz de usuario y el backend, que se encarga de la lógica y del procesamiento de los datos. El frontend se ha desarrollado con PHP y Javascript, y el backend se ha creado como una API con Flask, un framework de Python para crear aplicaciones web. Como base de datos relacional se ha utilizado MySQL. Para alojar el backend no ha sido necesario utilizar ninguna herramienta externa, ya que simplemente basta con utilizar el comando Python por defecto. Sin embargo, para alojar el frontend en PHP y la base de datos, se ha utilizado XAMPP, ya que esta herramienta contiene por defecto un servidor Apache para alojar el código PHP y phpMyAdmin para administrar de manera sencilla la base de datos. 33 CAPÍTULO 6. MODELO DE DATOS En este capítulo se describe en detalle el modelo de datos utilizado en el proyecto. En la figura 5 se puede observar la base de datos “tfg_bd” y las tablas que esta incluye. Figura 5. BBDD en phpMyAdmin ● Patients: recoge tanto los datos de los pacientes iniciales usados en el entrenamiento del modelo como de los nuevos pacientes introducidos por los usuarios. ● Users: recoge los distintos usuarios que pueden acceder a la aplicación. Tienen dos roles posibles: usuario corriente y administrador. Al ser únicamente dos tablas completamente independientes, no se han establecido relaciones entre dichas tablas. La utilidad de MySQL para esta aplicación es la de mantener la persistencia de datos. 6.1. Tabla patients Esta tabla aúna los datos de los pacientes de la unidad de uro-oncología. Los pacientes son insertados en la base de datos a través de funcionalidades como “Importar pacientes” o “Añadir paciente”. En el primer caso se importarán uno o varios pacientes en formato .xls o .xlsx y en el segundo caso se importaría un único paciente introduciendo cada campo en el formulario de la aplicación. 34 Los datos deben seguir un formato concreto, es decir, al menos una de las columnas y sus tipos deben coincidir con los que se muestran a continuación y, en caso de no ser así, la aplicación devolverá un error al tratar de importarlos. Además, si en algún caso, uno o varios pacientes no cumplen en algún campo con el rango de valores especificado, se tratará dicha entrada como incorrecta y se anulará su inserción. A continuación, de describen las variables de la tabla: N: Número del paciente a introducir FILIACIÓN 1.- FECHACIR: Fecha PRL SOCIODEMOGRÁFICAS 2.- EDAD 3.- ETNIA (1.- Caucásico, 2.- Negro, 3.- Hispano, 4.- Asiático) ANTECEDENTES 4.- OBESO: Obesidad (0.- NC, 1.- IMC < 25, 2.- IMC 25-30, 3.- IMC > 30) 5.- HTA (1.- Si, 2.- No, 3.- NC) 6.- DM: Diabetes Mellitus (1.- Si, 2.- No, 3.- NC) 7.- TABACO (0.- NC, 1.- No, 2.- Exfumador, 3.- < 10 cigarrillos/día, 4.- 10-20 cigarrillos/día, 5.- > 20 cigarrillos/día) 8.- HEREDA: Familiar 1º grado con CaP (1.- Si, 2.- No) CLÍNICO-PATOLÓGICAS 9.- TACTOR: Tacto rectal preoperatorio (1.- Negativo, 2.- Sospechoso, 3.- Positivo) 10.- PSAPRE: PSA preoperatorio en biopsia (0-6 ng/ml, 6,01-10 ng/ml, 10,01-20 ng/ml, > 20 ng/ml) 11.- PSALT: PSAl/PSAt 12.- TDUPPRE: Tiempo de duplicación de PSA preoperatorio (2º el de biopsia). 13.- ECOTR (1.- Normal, 2.- Sospechosa (nódulo)) 35 BIOPSIA PROSTÁTICAS 14.- NBIOPSIA: Nº biopsias previas 15.- HISTO: tipo histológico (1.- Adenocarcinoma, 2.- Otro) 16.- GLEASON1: Gleason en biopsia (1.- 6, 2.- 7 (3+4), 3.- 7 (4+3), 4.- 8-10, 5.- Inclasificable) 17.- NCILPOS: Nº cilindros positivos (en cualquier lado) (1.- < 25%, 2.- 25-50%, 3.- 50%) 18.- BILAT: Bilateralidad (1.- Si, 2.- No) 19.- PORCENT: Mayor % afectación un cilindro 20.- IPERIN: Infiltración perineural (1. Si, 2.- No, 3.- NC) 21.- ILINF: Infiltración linfática: (1. Si, 2.- No, 3.- NC) 22.- IVASCU: Infiltración vascular (1. Si, 2.- No, 3.- NC) 23.- TNM1: cTNM biopsia (1.- cT2ab (unilateral), 2.- cT2c, 3.- cT3) TRAS PROSTATECTOMÍA 24.- HISTO2: Tipo histológico (1.- Adenocarcinoma, 2.- Otro) 25.- GLEASON2: Gleason pieza PRL (1.- 6, 2.- 7 (3+4), 3.- 7 (4+3), 4.- 8-10, 5.- < 6) 26.- BILAT2: Bilateralidad (1.- Si, 2.- No) 27.- LOCALIZ: Localización en pieza (1.- ZP, 2.- ZT, 3.- ZFMA, 4.- Múltiple) 28.- MULTIFOC: Multifocalidad (1.- Si, 2.- No) 29.- VOLUMEN: Volumen tumoral (% pieza) 30.- EXTRACAP: Extensión extracapsular (1.- Si, 2.- No) 31.- VVSS: Invasión Vesículas Seminales (1.- Si, 2.- No, 3.- NC) 32.- IPERIN2: Infiltración perineural pieza (1.- Si, 2.- No, 3.- NC) 33.- ILINF2: Infiltración linfática pieza (1.- Si, 2.- No, 3.- NC) 34.- IVASCU2: Infiltración vascular pieza (1.- Si, 2.- No, 3.- NC) 35.- PINAG: PIN alto grado pieza (1.- Si, 2.- No, 3.- NC) 36 36.- MARGEN: Márgenes quirúrgicos positivos (1.- Si, 2.- No, 3.- NC) 37.- TNM2: TNM pieza (1.- pT2ab, 2.- pT2c, 3.- pT3, 4.- pT4, 5.- pN+) EVOLUTIVOS 38.- PSAPOS: PSA posoperatorio 1º (si mayor 0,2 no se considera RBQ) 39.- RTPADYU: RTP adyuvante (1.- Si, 2.- No) 40.- RTPMES: Tiempo hasta RTP adyuvante (meses). 41.- RBQ: Recidiva BQ (1.- Si (CASOS), 2.- No (CONTROLES), 3.- Persistencia PSA (PSA > 0,2 primer posoperatorio tras PRL)) 42.- TRBQ: Tiempo hasta RBQ (meses desde PRL) (Bajo riesgo (18 meses), Alto riesgo (< 18 meses)) 43.- T1MTX: Tiempo hasta 1ª metástasis (meses) 44.- FECHAFIN: Fecha última revisión. 45.- FALLEC: Fallecimiento (1.- Si, 2.- No) 46.- TSUPERV: Tiempo de supervivencia desde RBQ si Fallecimiento (meses) 47.- TSEGUI: Tiempo de seguimiento desde PRL (meses) 48.- PSAFIN: Último PSA en seguimiento 49.- CAPRA-S: Valor rango 0-13 (Bajo riesgo (0-2), Medio (2-5), Alto riesgo (> 5)) MARCADORES 50.- RA-NUCLEAR: Receptor androgénico nuclear epitelial. (0.- Negativo (< 90% expresión), 1.- Positivo (90% sobreexpresión)) 51.- RA-ESTROMA: Receptor androgénico nuclear estromal. (0.- Negativo (< 30% expresión), 1.- Positivo (30% sobreexpresión)) 52.- PTEN: Pérdida de expresión (0.- Positivo (Presencia / No pérdida), 1.- Pérdida parcial o completa) 53.- ERG: Ausencia (0.- Negativo (> 0,7), 1.- Positivo (0-0,7)) 54.- Ki67: Presencia (0.- Bajo (0-0,005), 1.- Intermedio-alto (0,06 sobreexpresión)) 37 55.- SPINK1: Presencia (0.- Negativo (0-0,005), 1.- Positivo (> 0,05 sobreexpresión)) 56.- C-MYC: Presencia (0.- Negativo (0-0,2), 1.- Positivo (> 0,2 sobreexpresión)) 57.- IMC (kg/m2) 58.- ASA: Grado ASA (I-IV) 59.- GR: Grupo de riesgo: GRUPO TNM GLEASON PSA (BAJO (0) cT1-cT2a <7 < o = 10, MEDIO (1) cT2b 7 >10-20, ALTO (2) cT2c o > >7 >20) 60.- PNV: Preservación neurovascular (1.- Si, 2.- No) 61.- TH: Tiempo de hospitalización (días) 62.- PGG: Porcentaje de ganglios afectados (%) 63.- NGG: Número de ganglios afectados (Nº) 6.2. Tabla users En esta tabla se registran los usuarios que pueden acceder a la aplicación. Se diferencian dos tipos de usuarios: ● Administrador: tiene todas las funcionalidades de un usuario corriente y a mayores puede aceptar o denegar peticiones de registro de usuarios. ● Usuario corriente: tiene acceso a todas las funcionalidades de la aplicación excepto a las peticiones de registro de usuarios. A continuación, se describen las variables de esta tabla: ● id: identificador de cada usuario ● name: nombre de usuario ● surname_1: primer apellido del usuario ● surname_2: segundo apellido del usuario ● email: email asociado a la cuenta de usuario ● password: contraseña asociada a la cuenta de usuario ● type: tipo de usuario, puede ser user o admin. ● accepted: evalúa si el usuario ha sido aceptado por el administrador. 44 Figura 15. Estado de entrenamiento 45 CAPÍTULO 8. IMPLEMENTACIÓN En este capítulo se describe la implementación realizada en la aplicación web. Para ello se presentará la funcionalidad por módulos funcionales. 8.1. MÓDULO USUARIO 8.1.1. Registro En este apartado, un potencial nuevo usuario introduce sus datos rellenando un formulario, y posteriormente es añadido a la base de datos como un usuario “no registrado”. La solicitud de registro se muestra en la figura 16. La aceptación de este nuevo usuario se describe más adelante. Figura 16. Página de registro 46 En el caso de que el formulario no se rellene de manera correcta, se muestra un mensaje de error (figura 17), indicando los fallos cometidos por el usuario. Figura 17. Mensajes de error en la página de registro Si el formulario se rellena correctamente, se redirige a la siguiente página, indicando que la solicitud de registro fue un éxito, como indica la figura 18. 47 Figura 18. Éxito en la solicitud de registro La creación de un nuevo usuario se hace a través de la petición POST /register que aparece en las figuras 19 y 20. Figura 19. Procesamiento de la solicitud de registro en postRegister.php 48 Figura 20. Inserción de potencial nuevo usuario a la base de datos en tfg_server.py 8.1.2. Solicitudes de registro Este apartado es exclusivo de los administradores. En él se podrán aceptar o rechazar las peticiones de registro de un potencial nuevo usuario. Las solicitudes se muestran ordenadas por antigüedad, apareciendo primero las solicitudes más antiguas (figura 21). Figura 21. Solicitudes de registro 49 La tabla con las solicitudes de registro está paginada, y se muestran, como máximo, cinco peticiones. El administrador podrá pasar página a través de los botones habilitados para ello. Las solicitudes de registro se obtienen a través de una petición a GET /register_petitions (figura 22), y la respuesta (figura 23) de dicha petición se muestra al usuario a través de una tabla (figura 21). Figura 22. Petición al backend de las solicitudes de registro desde el frontend 50 Figura 23. Petición a las solicitudes de registro del frontend Un administrador puede aceptar o rechazar solicitudes pulsando un botón (figura 24), y cuando se realiza una de estas acciones, se notifica al solicitante a través del correo electrónico proporcionado sobre la aceptación o el rechazo de la solicitud (figura 26). 51 Figura 24. Modal de aceptación de solicitud de registro Esta funcionalidad, tanto para aceptar como para rechazar, se muestra en la figura 25. Figura 25. Aceptación de la solicitud de registro. Se notifica al solicitante sobre su aceptación a través del correo electrónico proporcionado Para poder enviar la notificación de aceptación de la solicitud de registro a través del correo electrónico, se ha utilizado PHPMailer [21], una extensión de PHP que se puede instalar a través de Composer [22]. 52 Figura 26. Correo con aceptación de la solicitud de registro En cuanto a la implementación del mecanismo de paginación, que además aparecen en otras partes de esta aplicación, se han utilizado la URL y variables de sesión, cuya implementación se muestra en la figura 27 y 28. Figura 27. Variables utilizadas para la paginación 53 Figura 28. Implementación de los botones y del mecanismo de paginación 8.1.3. Inicio de sesión (Login) Una vez aceptada la solicitud de registro, el usuario puede loguearse para poder acceder a la aplicación (figura 29). Hay que destacar que cada vez que se hace login, el backend devuelve al usuario un token JWT, que servirá para identificarse cada vez que haga peticiones al backend. De este modo, se restringen las peticiones únicamente a usuarios registrados y aceptados. 60 Figura 38. Petición al backend mediante un id de paciente Por otra parte, la visualización de datos de los pacientes se ha implementado con un método GET tal y como se muestra en la figura 39. 61 Figura 39. Petición al backend de todos los pacientes La llamada a estos métodos del backend se produce desde un fichero php. En dicho fichero realiza una llamada a una función distinta del backend dependiendo de si el usuario ha filtrado por el id del paciente o no. La lógica descrita puede apreciarse en la figura 40. Figura 40. Petición de pacientes desde el frontend 62 Si se observa la penúltima línea de la figura 40, se puede apreciar un require_once de un fichero llamado “viewTable.php”. En dicho fichero se genera la tabla con los datos de los pacientes, y se ha incluido en una carpeta “common” porque también es usada por el módulo de consultas. En la figura 41 se puede apreciar un fragmento de código extraído de “viewTable.php”, cuya implementación define que si no existen pacientes en la base de datos o se realiza una búsqueda de un id de paciente inexistente, la aplicación devolverá un mensaje de aviso al usuario. Figura 41. Código de la tabla de pacientes 8.2.2. Añadir paciente Mediante esta funcionalidad, el usuario puede añadir los datos de un paciente a través de un formulario. En dicho formulario se tienen en cuenta los tipos de las variables, por lo que saltará un error si el usuario intenta introducir un tipo no válido. A su vez, está permitido dejar campos en blanco, eso está contemplado como una casuística válida. En la figura 42 se muestra una porción de los datos que pueden ser rellenados por el usuario de un total de 63 campos. 63 Figura 42. Añadir paciente Una vez el usuario haya rellenado los campos que desea, deberá pulsar el botón de añadir mostrado en la parte inferior de la vista. Posteriormente, el paciente nuevo será añadido a la base de datos y el usuario será redirigido a la página principal del módulo pacientes donde podrá observar los datos de dicho paciente en la tabla de visualización de datos. La implementación de esta funcionalidad se ha completado mediante un método POST, tal y como se describe en la figura 43. Figura x. Vista añadir paciente 2 64 Figura 43. Petición de añadir paciente En dicha figura podemos observar una llamada a la función newPatientsDF, cuyo comportamiento se define en la limpieza de datos más adelante. 8.2.3. Ver estadísticas En este apartado el usuario puede visualizar estadísticas construidas con la muestra total de los pacientes que se encuentran en la base de datos. Todas las gráficas muestran información acerca del número de pacientes con una característica determinada (fumadores, no fumadores, con obesidad, en un rango de edad determinado, …). Las distintas gráficas que se pueden encontrar en esta pestaña se muestran en la figura 44. 65 66 Figura 44. Estadísticas de los pacientes A continuación, se describen dos fragmentos de código incluidos en la implementación de las gráficas anteriores. Dichos fragmentos pueden apreciarse en las figuras 45 y 46. En la figura 45 se observa una petición GET al backend, donde se recibirán los datos que posteriormente serán mostrados en la gráfica mediante llamadas a la función loadData, apreciable en la figura 46. 67 Figura 45. Petición para las estadísticas desde el frontend Figura 46. Función para cargar las estadísticas 68 8.2.4. Exportar pacientes Gracias a esta funcionalidad, el usuario puede exportar todos los pacientes disponibles en la base de datos, con sus respectivos campos y valores, a un documento Excel (figura 47). Figura 47. Exportar datos pacientes Tras realizar una petición GET a /database (figura 48), el servidor devolverá un archivo JSON (figura 49). A continuación, el frontend convierte dicho archivo en un fichero Excel para preparar la descarga de los datos. Figura 48. Petición al servidor 69 Figura 49. Código del servidor 8.2.5. Importar pacientes Esta vista permite al usuario importar pacientes de forma masiva desde un fichero Excel que contenga alguna de las columnas de la base de datos. El Excel en cuestión debe comenzar con el nombre de las columnas en la primera fila, y la tipología de los datos dentro de cada campo debe de ser correcta, si esto no ocurre, se avisará al usuario del error (figura 51). A continuación, se presenta la vista principal que contiene esta funcionalidad (figura 50). 76 Figura 61. Inicio detalles de consulta Al excluir los campos no deseados, se podrá además seleccionar un switch adicional en el que, si se activa, se generarán unos datos más extensos e interactivos. Esta última opción aumentará el tiempo de espera para la generación del análisis. Acto seguido de entregar el formulario, se realiza una petición GET a /getDetails (figura 62), donde gracias al uso de los hilos en el backend, se ignora el posible bloqueo al usuario de las demás funcionalidades de la aplicación mientras se genera el análisis solicitado. Este hilo creará un archivo temporal llamado “detalles[id público del usuario].html” gracias a la librería pandasProfiling. 77 Figura 62. Código del servidor de la ruta /getDetails) Al terminar de generar los datos, se le mostrarán al usuario leyendo el archivo originado haciendo una petición GET sin token de usuario a /getDetailsFile (figura 63), para, de nuevo, no bloquear la página al usuario en cuestión mientras se realiza la solicitud. Figura 63. Código del servidor de la ruta /getDetailsFile 78 8.3.5. Exportar consulta Gracias a esta funcionalidad, el usuario puede exportar los resultados de la consulta ejecutada, a un documento Excel (figura 64). Figura 64. Exportar datos El código implementado para esta funcionalidad es el mismo que el utilizado en el módulo de pacientes (figuras 48 y 49). 79 CAPÍTULO 9. MÓDULO PREDICCIONES En este capítulo se describe el estudio y la implementación del módulo de predicciones. 9.1. Limpieza de los datos A continuación, se explicará el procedimiento que se siguió para obtener la mejor integridad de los datos. 1. Para comenzar, con la ayuda de la librería Pandas de Python, se hizo de forma cómoda la lectura tanto de la base de datos de phpmyadmin, como del Excel proporcionado por el usuario. 2. Tras leer ambas tablas, se transforman los nombres de las tablas a mayúsculas y los espacios en blanco por guiones. Esto lo conseguimos utilizando una función map (función que aplica un cambio en todas y cada una de las columnas del DataFrame en cuestión) de las columnas contenidas en el Excel. De esta forma se eliminan confusiones a la hora de importar un Excel que no tenga exactamente el mismo nombre de columnas. 3. Después se realiza la intersección de campos entre la base de datos y el Excel incorporado, para así comprobar si hay columnas coincidentes. En caso contrario, se obtendría un error que posteriormente sería mostrado al usuario. 4. Al ser el identificador de paciente un dato que se debe ocultar se elimina del Excel si es que existe. En la base de datos se obtendrá un nuevo identificador para cada paciente con una variable incremental. 5. Posteriormente, se creó un archivo JSON que contiene las 63 variables iniciales como claves y cada una de ellas, además de su descripción, su tipo de dato (int, float, …), su rango posible de valores y el campo ‘reemplazar’, explicado más adelante. En la figura 65 podemos observar un ejemplo de tupla clave-valor contenido en el JSON descrito. 80 Figura 65. Ejemplo de entrada del JSON de variables 6. Mediante este JSON, se puede comprobar de forma sencilla si cada uno de los campos contenidos en el Excel son correctos. Si se diese el caso contrario existirían dos posibles opciones: que el tipado de datos no sea el correcto, o que el dato no esté contenido en su rango posible de valores. Si ocurriese lo primero, se mostraría un error al usuario con todas y cada una de las columnas que no hayan cumplido esta condición, haciéndole ver al usuario que hay valores en el Excel introducido que tienen tipos inválidos. Por otro lado, si el dato no está contenido en su posible rango, simplemente se eliminaría dicho paciente por riesgo de contaminación de pacientes no deseados en la base de datos. 7. Por último, se concatenaron las tablas: la producida después de la limpieza del Excel, y la de la base de datos. Al tener riesgo de obtener pacientes duplicados (no por su identificador, si no por todos y cada uno de los valores iguales), antes de importar los pacientes nuevos, se eliminan todos aquellos que cumplan que cada uno de sus campos son iguales al de otro paciente, es decir, son entradas duplicadas en la base de datos y esto sesgaría a la IA. Todos estos pasos se realizan para poder abstraer de la forma más segura al usuario, y así conseguir minimizar tanto de riesgos de contaminación de la base de datos como de posibles errores que puedan surgir al intentar insertar datos no válidos en la base de datos desde el backend, lo que originaría la detención absoluta del servidor. Además, la aplicación informa al usuario de las posibles columnas incorrectas que estén contenidas en el Excel que se está intentando importar, así como de los pacientes que se han conseguido introducir en la base de datos. De los 269 pacientes que había inicialmente en la base de datos, tras la limpieza descrita anteriormente se han conservado 204 pacientes completamente válidos. Por último, el campo “reemplazar” del archivo JSON se ha utilizado para poder mostrar al usuario los datos con su debida traducción, ya que casi todos ellos están codificados con un 81 código numérico. Un ejemplo es el campo “ETNIA”, el cual viene dado por datos numéricos del 1 al 4, siendo el 1 “caucásico”, y el 4 “asiático”. El objetivo de esto es que el usuario pueda apreciar el significado real del valor de la variable y no el código numérico asociado a dicho valor. Cabe destacar que todo este procedimiento se repite siempre que se intentan insertar pacientes nuevos, dando como resultado una base de datos lo más íntegra posible. Las siguientes imágenes (66, 67) muestran el código utilizado para implementar esta funcionalidad. Figura 66. Función de limpieza de datos 1 82 Figura 67. Función de limpieza de datos 2 9.2. Modelos de predicción Tras realizar la limpieza de datos inicial en el apartado anterior, se realizaron los entrenamientos necesarios para poder generar los distintos modelos de predicción, y así, predecir con los algoritmos que se mencionan más adelante. La idea es poder predecir si una persona padecerá de recidiva bioquímica (RBQ) tras ser operado de cáncer prostático, a partir de unos datos. La recidiva bioquímica consiste en la detección de aumento de los valores de PSA (marcador tumoral prostático) tras su negativización una vez realizada la prostatectomía radical como tratamiento oncológico en un paciente. El entrenamiento de la aplicación y, por tanto, las predicciones, se realizan en base a este conjunto de datos iniciales. Cualquier dato que se añada a la aplicación, no supone un cambio en la decisión tomada al predecir. Estos nuevos datos se utilizan principalmente para los módulos Pacientes y Consultas, es decir, la gestión y el estudio de pacientes. Para ello, se ha utilizado un notebook 1 (adjuntos con esta memoria) con la limpieza de datos para realizar el análisis de los datos y las distintas pruebas; para así, posteriormente, copiar y pegar el código necesario del notebook en el código que contiene el backend de la aplicación. 1 Es muy probable que las figuras mostradas en esta memoria no se correspondan con el contenido del notebook, debido a que éste podría haber sido modificado después de generar este documento. 83 Para realizar el análisis de los datos se ha utilizado la librería Pandas, y para generar los modelos y realizar las predicciones se ha utilizado scikit-learn, una librería de Machine Learning muy sencilla de utilizar. La parte de la limpieza, preparación y selección de los datos para los entrenamientos se ha realizado de manera manual, ya que las automatizaciones de estos procesos se pueden realizar hasta cierto punto. Ha sido necesario realizar unas reflexiones y unas valoraciones más subjetivas para preparar de manera adecuada los datos para generar los modelos. Es muy difícil que una máquina sea capaz de determinar que, por ejemplo, el FALLECIMIENTO (columna de nuestra base de datos) sea un dato relevante para predecir casos recidiva bioquímica, ya que el fallecimiento no es decisivo para predecir estos casos. 9.2.1. Descripción inicial de los datos En primer lugar, se visualizaron los datos para tener una idea inicial de cómo es el dataset. Haciendo df.shape (figura 68) se obtiene el número de filas y de columnas del dataset tras la primera limpieza previa. Figura 68. Forma del dataset tras la primera limpieza Se ha observado que el dataset tiene 204 filas (es decir, 204 casos de seguimiento de cáncer de próstata) y 60 columnas (o variables). Viendo esto, se puede apreciar la gran escasez de datos para realizar el entrenamiento. Al ser casos muy extraños, no existe ninguna forma de obtener más datos. También se ha utilizado df.describe(include="all",datetime_is_numeric=True) para ver un resumen estadístico (figura 69). 84 Figura 69. Resumen estadístico Con este resumen estadístico se puede apreciar que, por ejemplo, la edad media de los pacientes es de unos 62 años, que el más joven tiene 46 años, y que el más mayor tiene 78 años. También aparecen las estadísticas de otras columnas como PSAPRE, PSALT, etc. Explicar e interpretar estos tecnicismos médicos se alejan del ámbito de este Trabajo Final de Grado. 9.2.2. Limpieza de columnas con filas vacías Algo que se ha tenido muy en cuenta (ya que es necesario para poder realizar los entrenamientos), es no tener ninguna columna con datos nulos. Para detectar estos nulos se ha utilizado df.info() (figura 70). Figura 70. Visualización para localizar columnas vacías Como se puede observar en las capturas anteriores, hay algunas columnas con entradas nulas. Algunas ni siquiera llegan a las 100 entradas no nulas, por lo que fue necesario hacer más limpieza para no tener ninguna columna con datos vacíos, y que scikit-learn pueda hacer 85 sus entrenamientos correctamente. Para hacer esta limpieza, se rellenaron aquellos nulos con la mediana de los datos de cada columna. Antes de hacer el rellenado, se eliminaron aquellas columnas con más del 50% de filas vacías, ya que rellenar con la mediana una columna prácticamente vacía sería falsear demasiado el dataset, haciendo que las predicciones no sean certeras y reflejen una realidad que no es. A continuación, en la figura 71, se muestra la función para eliminar las columnas casi vacías. Figura 71. Función para eliminar columnas con valores faltantes mayores o iguales al 50% Una vez eliminadas las columnas casi vacías, se rellenaron las demás columnas con la mediana a través de la función descrita en la figura 72: Figura 72. Función para rellenar columnas con filas vacías con la mediana Una vez rellenadas las columnas se puede confirmar que, efectivamente, no hay ninguna columna con filas vacías (figura 73). 92 reflexionar en si utilizar más datos de entrenamiento (un 80/20, por ejemplo), o más datos de test (un 60/40), para compensar de alguna forma la escasez de datos y el desbalance de las distintas categorías. Si se utilizan más datos dedicados al entrenamiento, con un 80/20 o incluso un 90/10, es muy probable que la calidad de los modelos aumente. El problema de esto es que no habría suficientes datos para testear, y se perdería la capacidad de evaluar correctamente la calidad de los modelos (sobre todo, para evaluar las predicciones de los casos de “SI”, que son muy escasos). Por otra parte, si se utilizan más datos dedicados a los test, con un 60/40, se obtendría una mejor capacidad de valorar la calidad de los modelos (y más casos de “SI” para testear), a cambio de una peor calidad de los modelos. En un caso real donde se necesite predecir la recidiva bioquímica, la calidad de los modelos de predicción es muy importante, por lo que en ese caso es muy probable que se acabe utilizando un 80% del dataset para entrenar y el otro 20% restante para evaluar. Sin embargo, de cara a este TFG se ha optado por tener más datos de test, utilizando un 60% para entrenar y un 40% para testear (figura 82), ya que de este modo habrá más casos de “SI” para poder mostrar por pantalla y obtener mejores valores de accuracy, precision y recall. De esta forma se puede compensar la escasez de “SI” y mostrar algo más equilibrado en la aplicación. Figura 82. Generación de datos de entrenamiento y de test. De esta forma, hay 122 entradas dedicadas al entrenamiento y 82 entradas para testear. 9.2.4.2. Random Forest Los Random Forests (Bosques Aleatorios en castellano) ilustrados en la figura 83, son una combinación de varios Árboles de Decisión, a los cuales, aleatoriamente, se les pasa un subconjunto de los valores de un conjunto de datos. Este método de aprendizaje entra dentro del grupo de los Ensamble Learning Methods (o Métodos de Aprendizaje Combinado), ya que utiliza varios estimadores para generar los modelos de predicción. 93 Figura 83. Visualización gráfica de Random Forests (31) En este caso, no se ha realizado un escalado para que los datos del dataset tengan un rango similar, ya que estos métodos no lo requieren. Aplicar estas técnicas en Árboles Aleatorios no aportarían ningún tipo de beneficio. En scikit-learn, un Random Forest Classifier se puede crear con RandomForestClassifier(), y se han utilizado los parámetros class_weight, bootstrap, n_estimators y max_samples. Las conclusiones sobre cada parámetro se describirán a continuación: ● class_weight. Indica los pesos de cada clase de la variable a predecir (en este caso, RBQ). Por defecto todas las clases tienen peso 1. Se ha utilizado balanced, de tal forma que el peso de una clase es inversamente proporcional a la frecuencia de dicha clase. De esta manera, se consigue compensar el desbalance del “SI” sobre el “NO” predominante en este modelo. ● bootstrap. Establecido a true. Este parámetro indica al clasificador que tiene que utilizar subconjuntos del dataset. El tamaño de cada subconjunto es indicado por max_samples. ● max_samples. Indica el número de entradas máximo de cada Árbol de Decisión del Random Forest. Para seleccionar este valor, se ha iterado sobre un rango entre 100 y 122 (teniendo el 60% de datos para entrenar tenemos, como máximo, 122 entradas). El 94 rango establecido podría haber sido mayor. Sin embargo, utilizar tan pocas entradas para cada árbol podría perjudicar el entrenamiento de cada árbol. Se ha ejecutado la función de la figura 84 para encontrar este valor. Figura 84. Función para encontrar el mejor valor de max_samples Los resultados de la función se muestran en la figura 85. Figura 85. Resultados de get_best_max_samples Se puede observar que cualquier valor ofrece un accuracy de aproximadamente 0,92. Cualquier valor de max_sample puede servir. Se ha utilizado, en este caso, utilizar 100 valores para cada árbol. ● n_estimators. Este parámetro indica el número de árboles de decisión que contendrá el bosque aleatorio. Para seleccionar este valor, se han realizado entrenamientos en varias 95 iteraciones y se ha dibujado un gráfico con los resultados. El número de estimadores mínimos es 2, ya que un Bosque debe de tener más de un Árbol. En cuanto al número máximo, la teoría recomienda utilizar la mayor cantidad posible. Usar muchos estimadores hará que los entrenamientos tarden más. En este caso se ha establecido el máximo a 100. La búsqueda de este valor se ha realizado utilizando la función descrita en la figura 86. Figura 86. Función para encontrar el mejor valor de n_estimators Los resultados se muestran en la figura 87. Figura 87. Accuracy para cada valor de n_estimators Se puede observar que la precisión es aproximadamente 0,9 para cualquier valor n_estimators, por lo que todos los valores actuarán de manera similar. Existen algunos picos; sin embargo, eso no será siempre así en todas las ejecuciones de la función mencionada anteriormente. Una vez seleccionados los parámetros, se procede a entrenar y evaluar el modelo con los parámetros seleccionados (figura 88). En la celda siguiente se muestra el entrenamiento y la generación de los resultados de la evaluación (que no siempre serán iguales). 96 Figura 88. Celda con el entrenamiento y generación de los resultados del entrenamiento. Los resultados del entrenamiento se describen en el informe y en la matriz de confusión que se muestran en la figura 89. Figura 89. Resultados del entrenamiento Se obtiene un score de 0,96. Este resultado puede parecer bueno. Sin embargo, hay que tener en cuenta otros valores, como precision (relación entre los positivos predichos y todos los verdaderos positivos) y recall (relación entre la cantidad de casos predichos como verdaderos positivos entre todos los verdaderos positivos), ofrecidos también en el informe de clasificación de la figura 89. 97 También se ha utilizado una curva ROC y la AUC (figura 90) para ver la relación entre la tasa de verdaderos positivos y la tasa de falsos positivos, mostrada en la figura 90. Estos resultados determinan cómo de bueno es un clasificador. Figura 90. Celda para generar la curva ROC y la AUC Figura 91. Curva ROC y AUC Observando la gráfica anterior y el valor de AUC, se puede comprobar que el modelo es capaz de distinguir las distintas clases, aunque se podría mejorar bastante adquiriendo más datos. En el eje X se puede comprobar que la Tasa de Falsos Positivos es siempre 0, ya que el dataset de test no ha clasificado ningún “SÍ” de manera incorrecta. Esto no es porque el clasificador distingue el “SÍ” de manera perfecta, si no que esto es debido a la escasez de los casos de “SÍ” utilizados en el test (mirar la matriz de confusión de la Figura 89). En el eje Y se puede observar un mayor movimiento. La curva tiene poca altura, indicando que hay pocos 98 verdaderos positivos (en la Figura 89 se puede ver que se los 4 casos de “SI”, sólo se acierta 1 caso). Se puede comprobar que el modelo es capaz de predecir correctamente la mayoría de los casos de “NO”, pero el predictor es muy malo prediciendo los casos de “SI” (solo ha acertado 1 caso de 4). Cabe destacar que los casos de “SI” son muy escasos, por lo que se necesitan más datos para tener un mejor pronóstico. Con este primer estimador se ha presenciado el problema que surge al tener tan pocos datos y al tener una variable a predecir muy desbalanceada. Los modelos que se generan están muy sesgados y evaluar la efectividad de un predictor es muy complicado. Con este dataset, los modelos que se generan tienden a predecir “NO” y en un caso real, es muy probable que los predictores den varios falsos negativos. Este fenómeno se podrá observar también en los estimadores que se mencionan más adelante. 9.2.4.3. k Nearest Neighbours (kNN) El algoritmo de k-Nearest Neighbours es uno de los métodos de clasificación por clustering más básicos del Machine Learning. Este es un algoritmo de aprendizaje no paramétrico y basado en instancias. ● No es paramétrico porque no hace suposiciones sobre la forma de los datos. El algoritmo no sabe si la distribución de los datos tiene, por ejemplo, una distribución normal o de Fischer. ● El aprendizaje es basado en instancias porque el algoritmo no aprende de manera explícita el modelo, si no que memoriza los datos instanciados en el entrenamiento para posteriormente hacer las predicciones. Este método de aprendizaje clasifica a una nueva instancia según la clase de sus k vecinos más cercanos. 99 Figura 92. Ejemplo de kNN (32) En el ejemplo de la Figura 92, se quiere clasificar el círculo verde. Si k=3, entonces éste es clasificado como un triángulo rojo. Sin embargo, si k=5, se clasifica como un cuadrado azul. Para realizar el entrenamiento, ha sido necesario realizar un escalado, ya que los algoritmos basados en distancias como kNN se ven muy afectados por el escalado de las variables. Para realizar un entrenamiento correcto, es necesario que las columnas tengan una escala similar. Para ello, se ha utilizado el escalado de Min Max (o normalización), que reduce la escala de los datos a un rango que por lo general suele ser entre 0 y 1. Los parámetros utilizados para generar este modelo han sido n_neighbors y p. A continuación se describirán las reflexiones realizadas para elegir los valores de estos parámetros. ● n_neighbors. Este parámetro indica el valor de k, es decir, el número de vecinos más próximos que se utilizarán para decidir la categoría de la nueva instancia. ● p. Este parámetro indica el tipo de distancia que se utilizará para determinar la cercanía entre las distintas instancias. Si p=1, se utilizará la distancia Manhattan. Si p=2, se utilizará la distancia euclídea. Para seleccionar los dos parámetros anteriores, se han utilizado dos bucles que iteran sobre los potenciales valores de k (figura 93, 94 y 95), uno utilizando la distancia Manhattan (p=1) y otro utilizando la distancia euclídea (p=2), para obtener gráficamente los resultados de accuracy para cada valor de k, 100 dependiendo de la distancia utilizada. De este modo, se puede decidir de manera más sencilla el mejor valor de n_neighbors y de p. Figura 93. Función para obtener los accuracy para cada valor de n_neighbors. Figura 94. Resultados de accuracy para cada valor de k utilizando distancia Manhattan (p=1) 101 Figura 95. Resultados de accuracy para cada valor de k utilizando distancia euclídea (p=2) Tras varias ejecuciones, se ha comprobado que se obtienen accuracy muy similares, aunque esto varía en cada ejecución. Hay que tener mucho cuidado a la hora de elegir el valor de k, sobre todo cuando se tienen datos muy desbalanceados. Usar un k muy bajo haría que se produzca overfitting en el entrenamiento, y usar un k muy alto puede disminuir, o incluso hacer imposible que el resultado de la predicción sea el de la clase minoritaria. Figura 96. Ejemplo de clustering utilizando k=3 y k=20 108 Para este caso, se han utilizado para la votación los modelos ya entrenados anteriormente. Es necesario tener en cuenta que los modelos que se han utilizado están sesgados, por lo que la votación estará también sesgada, y tenderá a clasificar a las nuevas instancias como “NO” (figuras 106, 107 y 108). Figura 106. Celda para generar el modelo de Voting Classifier Figura 107. Resultados de Voting Classifier 109 Figura 108. Curva ROC y AUC de Voting Classifier 9.3. Predicciones Una vez realizada los estudios necesarios para generar los modelos de predicción, se ha procedido a implementar el apartado de predicciones, donde un usuario puede rellenar un formulario para que, al pulsar un botón, se devuelva el resultado de la predicción de la recidiva bioquímica. En primer lugar, se ha copiado, pegado y adaptado el código utilizado en el notebook en el backend de la aplicación. Para ello, se ha creado un fichero predictions.py cuyo contenido es exclusivamente el código relacionado con la generación de los modelos de predicción. El entrenamiento se realiza a través de la función que aparece en la figura 109. Se puede observar que la función recibe un dataframe como parámetro, y devuelve los modelos generados junto con un diccionario con los scores de cada modelo. Los detalles de las funciones internas se explicarán más adelante. 110 Figura 109. Función para generar los modelos El apartado 1 se corresponde con la limpieza y selección de los datos. El apartado 2 se corresponde con el entrenamiento. Viendo la figura anterior se puede comprobar que se realizan una serie de operaciones para realizar los entrenamientos. En el apartado 1 se produce la limpieza y selección de los datos mediante la manipulación de un dataframe. Los motivos y las decisiones tomadas para crear estas funciones para limpiar los datos se han discutido en el apartado anterior. ● drop_columns(df) (figura 110). Esta función se encarga de eliminar las columnas que no deben de ser utilizadas para realizar el entrenamiento. Figura 110. Función para eliminar columnas ● replace_IPERIN2_NC(df) (figura 111). Esta función se encarga de reasignar los casos desconocidos de IPERIN2 a “SI” o “NO” de manera aleatoria. 111 Figura 111. Función para reasignar los casos desconocidos de IPERIN2 ● replace_RBQ_persistencia(df) (figura 112). Esta función se encarga de reasignar los casos de persistencia de RBQ a “SI” o “NO”, de manera aleatoria. Figura 112. Función para reasignar los casos de persistencia de RBQ ● df_categorical_to_encoded(df) (figura 113). Esta función se encarga de transformar los valores categóricos (si existen) a valores numéricos, para que la generación de los modelos pueda ser correcta. Figura 113. Función para transformar datos categóricos a datos numéricos ● na_to_median(df) (figura 114) Esta función rellena las filas vacías de cada columna con la mediana de los datos de su misma columna. 112 Figura 114. Función rellenar campos vacíos con la mediana En el apartado 2 de la figura con la función trainModels(df) se encuentran las funciones utilizadas para generar los modelos de predicción. Todas estas funciones son muy similares entre sí, ya que todas realizan un entrenamiento con un algoritmo dado, y posteriormente devuelven un modelo con sus respectivos scores. Las implementaciones de estas funciones se muestran en las figuras siguientes: ● Random Forest (figura 115) Figura 115. Entrenamiento con Random Forest ● Regresión Logística (figura 116) 113 Figura 116. Entrenamiento con Regresión Logística ● k-Nearest Neighbours (figura 117) Figura 117. Entrenamiento con kNN 114 ● Voting Classifier (figura 118) Figura 118. Entrenamiento con Voting Classsifier Todas las funciones mencionadas anteriormente se ejecutan cuando se realiza la primera petición al backend (tfg_server.py en la figura 119); es decir, la generación de los modelos se realiza una única vez, y dichos modelos se guardan en el backend, para así evitar realizar entrenamientos (operación muy pesada) cada vez que se quiera realizar una predicción. Figura 119. Generación de modelos En la figura anterior se puede comprobar que se utiliza el decorador @app.before_first_request de Flask, que permite ejecutar una función antes de hacer la primera 115 petición al backend. En este caso, se ejecuta trainOnStartup(), que ejecuta las funciones mencionadas anteriormente y almacena los modelos generados y los scores en variables globales. De este modo, se almacenan los estados de los modelos, para que todos los usuarios que lo necesiten puedan acceder a los modelos para realizar las predicciones. Los estados que se almacenan aparecen en la figura 120, con sus respectivas inicializaciones: Figura 120. Estados que se almacenan en el backend ● pipe_rfc (Random Forest Classifier). Almacena el modelo generado con Random Forest ● pipe_lrc (Logistic Regression Classifier). Almacena el modelo generado con Regresión Logística. ● pipe_knn (k-Nearest Neighbours). Almacena el modelo generado con kNN. ● pipe_best. Almacena el modelo generado con Voting Classifier. ● scores. Almacena el accuracy, precision y recall de cada modelo ● last_train. Almacena la fecha en la que se realizó el entrenamiento. De este modo se puede tener una idea de la novedad de los datos utilizados. Una vez generados los modelos de predicción, se pueden realizar las predicciones a través de POST /predict (figura 121), pasándole en el cuerpo de la petición un JSON con el siguiente formato: { “features”: string, “algorithm”: string } El campo features se corresponde con un string que contiene datos numéricos separados por coma. El backend se encarga de transformar dicho string en una lista de números. algorithm 116 contiene el algoritmo a utilizar que, en este caso, pueden ser “rfc”, “lrc”, “knn” o “best”. El mecanismo de este endpoint se describe en la figura siguiente. Figura 121. Endpoint para realizar las predicciones A través de lo descrito anteriormente, un usuario puede hacer predicciones a través de una serie de datos de entrada. Para facilitar su uso, se dispone del apartado de “Predicciones” en el frontend de la aplicación de UroAnalytics. 9.4. Frontend del apartado de Predicciones A continuación, se describe la implementación del apartado de “Predicciones”, cuyo resultado aparece en las tres figuras 122, 123 y 124: 117 Figura 122. Descripción e importación de datos del apartado “Predicciones” Figura 123. Formulario de datos de “Predicciones” 124 Figura 133. Rellenado automático de los valores en el formulario Si la importación de los datos se realiza con éxito, se rellena el formulario y aparece un mensaje de éxito (figura 134). Figura 134. Formulario relleno con mensaje de éxito Si la importación no se realiza correctamente, entonces aparece un error como el que aparece en la figura 135. 125 Figura 135. Importación de datos de predicción fallida 9.4.2. Predicción con los datos del formulario Una vez rellenado el formulario, el usuario puede seleccionar un algoritmo y posteriormente realizar una predicción con el algoritmo seleccionado (figura 136). Figura 136. Selección de algoritmos Los resultados que aparecen cada vez que se cambia de algoritmo se obtienen a través de peticiones AJAX al backend con Javascript a GET /training/scores (figura 137). 126 Figura 137. Función que se ejecuta cuando se cambia de algoritmo Cuando se selecciona el algoritmo, aparece el botón de “Predecir” junto con los valores de accuracy, precision y recall (figura 138). Figura 138. Resultado del entrenamiento y de la predicción 127 La predicción que puede realizar un usuario también se realiza a través de una petición AJAX con Javascript a POST /predict (figura 140). Dicha petición se ha implementado con la función de la figura 139. Figura 139. Función ejecutada cuando se pulsa el botón de “Predecir” Figura 140. Función para pedir al backend el resultado de la predicción 128 CAPÍTULO 10. CONCLUSIONES Y TRABAJO FUTURO En este capítulo se describe la retrospectiva del proyecto, haciendo ver la conclusión, posibles mejoras futuras y el trabajo individual realizado por cada integrante del grupo 10.1. Conclusiones Se ha implementado una herramienta web capaz de gestionar una cantidad masiva de datos, así como hacer predicciones de riesgo a partir de estos, y capaz de realizar las tareas necesarias para facilitar la investigación de los expertos en Uro-oncología. En cuanto a funcionalidades destacan la importación de un conjunto de pacientes, gestionando posibles errores y limpiando automáticamente dichos datos; ejecución de consultas aplicando una amplia variedad de filtros, obteniendo estadísticas y realizando exportaciones; generación de predicciones de recidiva bioquímica que pueda tener un paciente a partir de unos datos. Las principales ventajas que cubre esta aplicación son la comodidad y la centralización de distintas funcionalidades en una sola aplicación, a través de una interfaz sencilla e intuitiva, que facilita la gestión e incorporación de pacientes. Se puede bajar el código de la aplicación a través del siguiente enlace: https://github.com/potchi23/TFG-UroAnalytics 10.2. Trabajo Futuro A continuación, se listan algunas líneas de trabajo futuro para mejorar la aplicación: ● Adquisición de más datos. Se ha conseguido una cantidad aceptable de datos para desarrollar este proyecto. Sin embargo, la escasez de datos ha perjudicado en gran manera a los modelos de predicción, dando poco margen para realizar un estudio adecuado y, como consecuencia, generar unos modelos de predicción no muy buenos. ● Predicciones. Tal como se ha mencionado en el punto anterior, la escasez de datos ha perjudicado el estudio adecuado de los datos, provocando así que sea muy 129 difícil que hacer los ajustes necesarios y seleccionar los parámetros adecuados para cada modelo se hagan de manera satisfactoria. ● Gráficas. Se cuenta con una gran cantidad de datos y se muestran los gráficos de los datos más importantes. Sin embargo, puede ser interesante que las gráficas sean más interactivas. ● Refactorización. Este proyecto ha sido desarrollado por cinco personas, por lo que coordinarse y ponerse de acuerdo en cómo implementar la aplicación ha sido más compleja. Por falta de tiempo ha sido muy complicado ponerse con la refactorización del código. ● Notificaciones. Puede ser interesante poder notificar a los usuarios de esta aplicación acerca de las posibles mejoras y actualizaciones que se puedan producir en la aplicación. 130 CHAPTER 10. CONCLUSIONS AND FUTURE WORK This chapter describes the retrospective of the project, showing the conclusion, possible future improvements and the individual work carried out by each member of the group. 10.1. Conclusions A web tool has been implemented, capable of managing a massive amount of data, as well as making risk predictions from this data, and capable of performing the necessary tasks to facilitate the research of experts in Uro-oncology. In terms of functionalities, the import of a set of patients, managing possible errors and automatically cleaning such data; execution of queries by applying a wide variety of filters, obtaining statistics and performing exports; generation of predictions of biochemical recurrence that a patient may have from certain data stand out. The main advantages covered by this application are the convenience and centralization of different functionalities in a single application, through a simple and intuitive interface, which facilitates the management and incorporation of patients. The application code can be downloaded through the following link: https://github.com/potchi23/TFG-UroAnalytics 10.2. Future Work Listed below are some lines of future work to improve the application: ● Acquisition of more data. An acceptable amount of data has been obtained to develop this project. However, the scarcity of data has been very detrimental to the prediction models, giving little margin to carry out an adequate study and, as a consequence, generating not very good prediction models. ● Predictions. As mentioned in the previous point, the scarcity of data has hindered the proper study of the data, making it very difficult to make the necessary adjustments and select the appropriate parameters for each model in a satisfactory manner. 131 ● Graphs. A large amount of data is available and graphs of the most important data are shown. However, it may be interesting to make the graphs more interactive. ● Refactoring. Five people have developed this project, so coordinating and agreeing on how to implement the application has been more complex. Due to lack of time it has been very complicated to refactor the code. ● Notifications. It may be interesting to be able to notify the users of this application about possible improvements and updates that may occur in the application. 132 CAPÍTULO 11. TRABAJO INDIVIDUAL Richard Junior Mercado Correa ● Aprendizaje de los fundamentos básicos del Machine Learning, utilizando distintos tipos de recursos para ello. Se puso mucho hincapié en los modelos de Random Forest, K-nearest neighbours y Regresión Logística. ● Participación en la especificación de requisitos y generación de diagramas de actividades para las funcionalidades de importación y exportación de datos a la aplicación. ● Participación en la decisión de las tecnologías a utilizar en la aplicación, en las que se decidió utilizar PHP en el frontend, Flask en el backend y MySQL como base de datos. ● Creación del repositorio de GitHub para alojar el código del proyecto, junto con la creación de un readme en Markdown para facilitar la instalación, ejecución y desarrollo de la aplicación web. ● Creación del logotipo de la aplicación web, utilizando como referencia la imagen de la vara de Asclepio. ● Participación en el estudio y análisis del conjunto de datos para su posterior utilización. ● Generación de los distintos modelos de predicción de la aplicación, haciendo los estudios y pruebas necesarias a través de notebooks de Jupyter con el conjunto de datos proporcionado. ● Creación de la infraestructura básica de la aplicación web. ● Creación de una clase con un método que encapsula todo el código necesario para hacer una petición HTTP al backend desde PHP, utilizando cURL. De este modo la solicitud de peticiones es más sencillo. ● Implementación de las funcionalidades básicas de gestión de un usuario: Login, Registro, Solicitudes de Registro y Logout. ● Implementación del apartado de “Predicciones” de la aplicación, en la que se desarrollaron las siguientes funcionalidades: rellenar un formulario con datos para 133 utilizarlos en la predicción, importación de datos, selección de algoritmos y realización de la predicción. ● Contribución en el apartado de “Consultas”, corrigiendo los errores de paginación en la visualización de las consultas. ● Contribución en el apartado de “Pacientes”, en el que se corrigieron los errores de visualización de los datos de los pacientes. ● Escritura de la memoria del proyecto. 140 ● Participación en la implementación de funciones del backend para la generación de detalles referentes a un conjunto de datos a través de la librería Pandas Profiling (función del backend: getDetails en la ruta /getDetails). ● Corrección de bugs en la aplicación, tanto de frontend como de backend. ● Escritura de la memoria del proyecto. 141 CAPÍTULO 12. ANEXO 12.1. Diagramas de actividad En este apartado se especificarán los diagramas de actividad correspondientes a los casos de uso anteriormente mencionados. C001-Iniciar sesión En la figura 141 se muestra el diagrama referente al inicio de sesión del usuario en la aplicación. Figura 141. Diagrama de actividad Iniciar sesión C002-Cerrar sesión En la figura 142 se muestra el diagrama referente al cierre de sesión del usuario. 142 Figura 142. Diagrama de actividad Cerrar sesión C003-Registro En la figura 143 se muestra el diagrama de cuando un nuevo usuario se registra en la aplicación, indicando los datos necesarios. Figura 143. Diagrama de actividad Registro C004-Gestionar peticiones de registro El administrador comprueba si el usuario que se ha registrado es un médico del hospital y confirma el registro de dicho usuario. Esta acción se representa en la figura 144. 143 Figura 144. Diagrama de actividad Gestionar peticiones de registro C005-Modificar datos de usuario La figura 145 muestra el diagrama dado cuando el usuario modifica los datos personales de su cuenta. 144 Figura 145. Diagrama de actividad Modificar datos de usuario C006-Eliminar cuenta El usuario elimina su cuenta perdiendo el acceso a la aplicación. Esta acción se describe en el diagrama de la figura 146. Figura 146. Diagrama de actividad Eliminar cuenta 145 C007-Realizar consulta En la figura 147 se muestra la acción del usuario realizando una consulta de pacientes indicando alguno o todos los atributos que deben cumplirse. Figura 147. Diagrama de actividad Realizar consulta C008-Ver tabla consulta Se muestra al usuario los datos de la consulta que realizó previamente en formato tabla. Está acción parte de una anterior (C007-Realizar consulta), cuando la consulta enviada al sistema se ha procesado correctamente. En la figura 148 se muestra esta acción. 146 Figura 148. Diagrama de actividad Ver tabla consulta C009-Ver estadísticas consulta Se muestra al usuario estadísticas en gráficos de la consulta que realizó previamente. Está acción parte de una anterior (C007-Realizar consulta), cuando la consulta enviada al sistema se ha procesado correctamente. A continuación, se puede observar en la figura 149 la acción descrita. Figura 149. Diagrama de actividad Ver estadísticas consulta 147 C010-Ver detalles consulta Se muestra al usuario detalles de la consulta que realizó previamente. Está acción parte de una anterior (C007-Realizar consulta), cuando la consulta enviada al sistema se ha procesado correctamente. Seguidamente, en la figura 150 se describe la acción gráficamente. Figura 150. Diagrama de actividad Ver detalles consulta C011-Exportar consulta El usuario exporta los datos de la consulta que realizó previamente. Está acción parte de una anterior (C007-Realizar consulta), cuando la consulta enviada al sistema se ha procesado correctamente. Esta acción se describe en el diagrama de la figura 151. 148 Figura 151. Diagrama de actividad Exportar consulta C012-Realizar predicción Se realiza un estudio sobre un conjunto de datos de pacientes y se hace una predicción sobre un paciente en concreto. El conjunto de datos que se utilizan para predecir no es la base de datos completa, sino un conjunto de datos iniciales. La figura 152 refleja dicha acción. 149 Figura 152. Diagrama de actividad Realizar predicción C013-Visualizar pacientes Se muestra al usuario una tabla con todos los datos de pacientes, es decir, los atributos de pacientes que se encuentran en la base de datos. Esta acción es descrita en la figura 153.