Desarrollo de una APP de autoadministración de test cognitivos para el diagnóstico precoz de la demencia

Universidad Complutense de Madrid Facultad de Informática Desarrollo de una APP de autoadministración de test cognitivos para el diagnóstico precoz de la demencia *** Development of an APP for the self-administration of cognitive tests for early diagnosis of dementia Autores Arantxa Patricia Brock Rabines Estephany Jhoselin Oscco Carbajal Andrea Sthephanie Janampa Zanabria Jaime Palazón Othon Director de proyecto José Luis Ayala Rodrigo Trabajo de Fin de Grado Grado en Ingeniería Informática Junio de 2021 2 Índice general Acrónimos 5 Palabras clave 6 Resumen 7 Abstract 8 1. Introducción 9 1.1. Enfermedades neurodegenerativas . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2. Por qué se propone este TFG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3. ObjetivosdeesteTFG ............................... 10 1.4. Estructuradelamemoria.............................. 10 2. Estado del arte 12 2.1. Test de evaluación cognitiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2. Test Aplicados a nuestro estudio . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.1. VOSPTest ................................. 16 2.2.2. TrailMakingTest.............................. 17 2.2.3. FCSRTTest................................. 17 2.2.4. ROCFTest ................................. 17 2.3. Evaluación cognitiva con tecnologías digitales . . . . . . . . . . . . . . . . . . . 18 2.3.1. Herramientas digitales para evaluación cognitiva . . . . . . . . . . . . . 18 2.3.2. Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.3.3. Machine Learning en la evaluación cognitiva . . . . . . . . . . . . . . . 20 2.3.4. Requisitos en herramientas de evaluación cognitiva . . . . . . . . . . . . 21 3. Metodología 22 3.1. TecnologíasAplicadas ............................... 28 3.1.1. ReactNative ................................ 28 3.1.2. Android Studio y XCode . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.1.3. APIRESTenLaravel ........................... 29 3.1.4. SQL..................................... 29 3.1.5. Postman................................... 30 3 4ÍNDICE GENERAL 3.1.6. Amazon Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1.7. VisualStudioCode............................. 30 3.1.8. Repositorios GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2. Arquitectura..................................... 31 3.2.1. Frontend .................................. 32 3.2.2. Backend................................... 35 3.2.3. BasedeDatos................................ 40 3.3. Controldeerrores.................................. 43 3.4. Planificación del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.4.1. Metodología SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.4.2. Tabla de tareas Kanban en Trello . . . . . . . . . . . . . . . . . . . . . . 47 3.4.3. Organización General . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.4.4. Cronograma................................. 49 3.4.5. Descripción individual del trabajo realizado . . . . . . . . . . . . . . . . 51 4. Test y Evaluación de usabilidad 61 4.1. Test ......................................... 61 4.2. Evaluación de la usabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.2.1. Diseño de la estrategia de validación . . . . . . . . . . . . . . . . . . . . 62 4.2.2. Formulario de evaluación para usuarios y resultados . . . . . . . . . . . 63 5. Conclusiones 68 6. Planificación a futuro 69 A. Introduction 71 A.1. Neurodegenerative diseases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 A.2.WhythisTFGisproposed ............................. 71 A.3.ObjectivesofthisTFG ............................... 72 A.4. Structure of the document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 B. Conclusions 74 Bibliografía 75 Índice de figuras 77 Índice de tablas 78 Agradecimientos 80 Lista de Acrónimos APP Aplicación informática. Application. API Interfaz de programación de aplicaciones. Application Programming Interfaces. BBDD Base de datos. HTTP Protocolo de transferencia de hipertextos. Hypertext Transfer Protocol. FK Clave foránea. Foreign Key. MVC Modelo-vista-controlador. EC2 Amazon Elastic Compute Cloud. RDS Amazon Relational Database Service. AWS Amazon Web Services. SQL Lenguaje de consulta estructurada. Structured Query Language. UI Interfaz de usuario. User Interface. IDE Entorno de desarrollo integrado. Integrated Development Environment. TIC Tecnologías de la información y la comunicación. IA Inteligencia Artificial. SO Sistema operativo. iOS Sistema operativo iphone. iPhone Operating System. ORM Mapeo objeto-relacional. Object-Relational mapping. DCL Deterioro cognitivo leve. EA Enfermedad de Alzheimer. VOSP Percepción visoespacial de objetos. Visual Object and Space Perception Battery. FCSRT Free and Cued Selective Reminding Test. ROCF Test de la figura compleja del Rey. The Rey–Osterrieth complex figure Test. TDAH Trastorno por Déficit de Atención e Hiperactividad. 5 Palabras clave Palabras clave en Español Aplicación. Dispositivo móvil. Usuario. Evaluación cognitivo. Enfermedad neurodegenerativa. Autoadministración. Paciente. Deterioro cognitivo. Keywords in English Application. Smartphone. User. Cognitive evaluation. Neurodegenerative disease. Autoadministration. Patient. Cognitive impairment. 6 Resumen El presente trabajo de fin de grado nace de la necesidad de diseñar herramientas digitales que sean capaces de auto-administrar test de evaluación cognitiva para la detección precoz de enfermedades neurodegenerativas; estas herramientas deben tener como principal propósito que los usuarios puedan realizar los test desde sus propios dispositivos tras una recomendación previa por parte de un especialista. Para ello se han definido una serie de objetivos, incluyendo, el análisis y estudio de los principales test utilizados actualmente en los departamentos de neurología, la adaptación digital de los test finalmente seleccionados, así como, la implementación y desarrollo de los mismos. En concreto realizaremos un desarrollo híbrido con la intención de diseñar una aplicación cuyo acceso esté disponible para la mayoría de personas, es decir, desarrollada para dispositivos de tipo smartphone con sistema operativo Android o iOS, pues estos destacan por ser los más utilizados. Además, contaremos con la colaboración del departamento de neurología del Hospital Clínico San Carlos durante el proceso completo de elaboración del proyecto. Esta contribución nos aportará el criterio médico necesario para la adaptación de los test que conforman nuestra aplicación, así como la forma en la que presentaremos nuestro diseño gráfico de las pruebas al paciente y otras características para poder dotar a la aplicación de un sistema que permita almacenar y procesar las respuestas del paciente automáticamente. Una vez realizado todo el proceso de desarrollo e implementación, realizaremos un despliegue de la APP en dispositivos iOS y Android, que se probará primeramente en población sana. Para esta administración de los test a los primeros usuarios contaremos con la colaboración del neuropsicólogo del departamento. De esta forma, se podrá validar el resultado de la especificidad del diagnóstico a través de esta herramienta, esperando gran similitud con la herramienta no autoadministrada; de igual manera podremos realizar un estudio y análisis de los primeros resultados obtenidos suministrando un test de usabilidad previamente diseñado, con las preguntas necesarias para la compresión de la interacción entre la interfaz y el usuario. 7 Abstract The present project arises from the need to design digital tools that are capable of self-administering cognitive assessment tests for the early detection of neurodegenerative diseases. These tools should have as main purpose that users can run the tests from their own devices after a previous recommendation by a specialist. In order to manage this purpose, some objectives have been defined, including the analysis and the study of the main tests currently used in the departments of neurology, the digital adaptation of the final tests selected, as well as the implementation and development of them. Specifically, we will carry out a hybrid development with the intention of designing an application whose access is available to most people. An application developed for smartphone-type devices with Android or iOS operating system, which stand out for being the most used. In addition, we will have the collaboration of the neurology department of the Clínico San Carlos Hospital during the entire process of this project. This contribution will provide us with the necessary medical criteria for the adaptation of the tests that make up our application, as well as the way in which we will present our graphical design of the tests to the patient and other features to be able to provide the application with a system that allows to store and process the patient’s responses automatically. Once the entire development and implementation process has been completed, we will deploy the APP on iOS and Android devices, which will first be tested on healthy populations. For this administration of the tests to the first users we will count on the collaboration of the neuropsychologist of the department. In this way, it will be possible to validate the result of the specificity of the diagnosis through this tool, expecting great similarity with the tool not auto-managed. In the same way, we will be able to carry out a study and analysis of the first results obtained by providing a previously designed usability test, with the required questions for the compression of the interaction between the interface and the user. 8 Capítulo 1 Introducción El incremento de la esperanza de vida en el ser humano, junto con el aumento demográfico, ha propiciado la aparición de un mayor número de casos de enfermedades neurodegenerativas. Entre otras cosas, este aumento produce un atraso a la hora de poder obtener un diagnóstico por falta de asistencia médica. Por ello, la intención de este trabajo es ayudar, en la manera de lo posible, a mitigar dicho problema. 1.1. Enfermedades neurodegenerativas Este tipo de enfermedades forman una parte extensa dentro del campo de la medicina, específicamente, en la rama de la neurología. Además, se caracterizan comúnmente por ser enfermedades de causa desconocida, con desarrollo progresivo de sus síntomas, que, a su vez, muestran la desintegración gradual de una o varias partes del sistema nervioso del ser humano. Asimismo, a estas características, se le suma una disminución de la funcionalidad e independencia personal. Las personas que padecen alguna de estas enfermedades requieren atención total y continuada, que justifica la necesidad de que los pacientes sean tratados en unidades específicas. [1] Estas enfermedades pueden clasificarse dependiendo de las manifestaciones clínicas que el paciente presenta; entre ellas se pueden distinguir las que muestran principalmente un síndrome demencial, como el Alzheimer; las que se exponen con trastornos de movimiento y postura, en el caso de Parkinson; las que presentan ataxia progresiva, es decir, falta de control muscular o de la coordinación de movimientos voluntarios, como comer, en el caso de la Ataxia Cerebelosa; o aquellas que muestran debilidad y atrofia muscular, por ejemplo la Esclerosis Lateral Amiotrófica; y otras muchas enfermedades con diferentes síntomas. Todas estas enfermedades neurodegenerativas, no tienen un tratamiento que actúe sobre la causa que lo origina, sino más bien se aplican tratamientos paliativos, es decir, no alcanzan cura. [2] 1.2. Por qué se propone este TFG La detección y diagnóstico precoz de las enfermedades neurodegenerativas, según diferentes estudios internacionales, se consideran, actualmente, un problema significativo de salud pública aún 9 16 CAPÍTULO 2. ESTADO DEL ARTE Independientemente de la exactitud de los dibujos realizados por el paciente, los resultados obtenidos se pueden reproducir a los tipos siguientes: I. Construcción sobre el armazón: el sujeto comienza por el rectángulo central, sobre el que se apoya y continúa con el resto de los elementos de la figura. II. Detalles englobados en un armazón: el paciente empieza por algún detalle anexado al rectángulo central. III. Contorno general: el sujeto comienza dibujando el contorno de la figura, continuando después con los detalles interiores. IV. Yuxtaposición de detalles: el sujeto une los detalles de la figura, unos sobre otros. V. Detalles sobre un fondo confuso: el sujeto reproduce un dibujo poco o nada estructurado, donde apenas se reconoce el modelo, pero sí ciertos detalles del mismo. VI. Reducción a un esquema familiar: el sujeto asocia la figura a elementos que le resultan familiares. VII. Garabatos: el sujeto reproduce un dibujo en el que no se pueden reconocer los elementos del modelo ni su forma global. Como se muestra en [5] 2.2. Test Aplicados a nuestro estudio Antes de comenzar con el desarrollo de nuestra aplicación, se realizó el estudio de los principales test con los que actualmente se trabaja en el departamento de neurología del Hospital Clínico San Carlos. Aunque una parte de las pruebas se siguen elaborando de modo tradicional, es decir, a papel, también utilizan el Vienna Test System, que es una herramienta TIC diseñada para la evaluación de habilidades cognitivas, memoria, atención, habilidades motrices, etc. En nuestro caso hicimos uso de la herramienta para realizar un total de 13 test en un periodo de tiempo de dos semanas que se llevó a cabo con un ordenador con teclado especial para la realización de las diferentes pruebas. Esto sirvió para ponernos en contexto y entender la metodología que conlleva este tipo de pruebas; y, así, poder plasmarlo y adaptarlo a una aplicación para dispositivo móvil. Del estudio y realización de estos test, nos quedamos con las principales ideas de alguno de ellos para tomarlos como referencia y adaptación para nuestra aplicación. Los más importantes fueron: 2.2.1. VOSP Test El VOSP Test sirve para explorar y evaluar la percepción de objetos y del espacio. Con este modelo se pueden reconocer 3 subtipos de déficit en la percepción de objetos: el trastorno de la discriminación sensorial visual, la agnosia aperceptiva, y la agnosia asociativa, que son otros tipos de trastornos que impiden indentificar o reconocer el nombre de objetos. [6]. 2.2. TEST APLICADOS A NUESTRO ESTUDIO 17 Se administra un test inicial de cribado y, a continuación, una serie de subtest que establecen pruebas para evaluar la percepción de objetos. Los subtest más relevantes de esta batería son los siguientes: 1. Decisión de objeto: se le presentan 20 láminas al paciente con 4 siluetas en cada una (de esas 4 siluetas hay un objeto real en 2 dimensiones y 3 distractores). El sujeto debe identificar y señalar el objeto real. 2. Siluetas progresivas: compuesto de 10 siluetas situadas inicialmente en un ángulo de rotación máximo y revelando mayor número de detalles progresivamente. Se le pide al participante que identifique el objeto lo antes posible. 3. Discriminación de la posición: se muestran en 20 partes, dos cuadrados adyacentes y un punto situado exactamente en el centro de uno de ellos y desviado del punto medio en el otro [7]. Se pide que el paciente decida qué cuadrado es el que contiene el punto centrado. 4. Localización del número: se presentan 10 láminas, cada una de ellas con 2 cuadrados, uno situado en la parte superior que contiene números del 1 al 9, distribuidos aleatoriamente, y otro, situado en la parte inferior que presentaba un punto. Se solicitó al participante que identificara cuál era el número que se correspondía con la posición del punto. 2.2.2. Trail Making Test El objetivo de este test es evaluar distintas funciones cognitivas, entre ellas la atención, flexibilidad cognitiva y la velocidad psicomotora. [8]. El TMT Test consta de dos partes: La parte A, en la cual se pretende realiza mediante líneas una conexión de forma consecutiva. Esta conexión se realizará entre 25 números que se encontrarán distribuidos al azar en una hoja. En la parte B, la conexión tiene que seguir la misma lógica, pero uniendo números y letras de forma alterna. 2.2.3. FCSRT Test El FCSRT es un test utilizado en neurología para evaluar la capacidad de aprendizaje y memoria verbal. Permite valorar, entre otras la capacidad de retención. Esta prueba en concreto ha sido ampliamente utilizada para la evaluación del déficit de memoria en diferentes enfermedades neurológicas, como la EA, y en otros trastornos, también bastante conocidos como son el estrés pos-traumático, depresión o esquizofrenia. [9]. 2.2.4. ROCF Test Este test consiste en una prueba de copia y reproducción de memoria de figuras geométricas.Se le debe pedir al paciente que realice dos tipos de tareas: [10]: 18 CAPÍTULO 2. ESTADO DEL ARTE Fase de copia: El sujeto debe copiar el modelo de la Figura de Rey (basado en figuras geométricas), indicando que la reproducción no necesariamente debe ser exacta, pero que debe poner atención en los detalles y las proporciones. Fase de reproducción de memoria: Tras un cierto tiempo de la primera fase se le pide al paciente que reproduzca la figura sin tenerla a la vista y sin recibir ninguna ayuda verbal que le permita identificar la forma o la situación de ninguno del total de elementos que conforman la figura. 2.3. Evaluación cognitiva con tecnologías digitales Las enfermedades neurodegenerativas han estado presentes siempre en nuestras vidas, sin embargo, con el paso del tiempo y la evolución tecnológica cada vez se disponen de un mayor número de herramientas y aplicaciones para realizar pruebas de evaluación cognitiva.Igualmente, estas pruebas siguen siendo, en su mayoría, explicadas y supervisadas por un especialista. Los test mencionados anteriormente son utilizados hoy en día en consultas médicas, pero estos suelen hacerse de forma dirigida y supervisada por un médico. Gracias a los avances tecnológicos y de forma alternativa a estos test cognitivos surgen varios tipos de herramientas TIC (como la mencionada anteriormente, Vienna Test System) que realizan adaptaciones de este tipo de pruebas con el objetivo de la detección precoz de enfermedades como la demencia o la EA. Entre ellas destacan las aplicaciones web y las aplicaciones para otros dispositivos digitales. 2.3.1. Herramientas digitales para evaluación cognitiva El software desarrollado e implementado para alguna de estas aplicaciones se realiza con objetivo de investigación médica y otras se realizan para uso comercial, aunque estas últimas, están más orientadas al entrenamiento cognitivo para la mejora de la agilidad mental. Las aplicaciones encontradas hasta la fecha han sido: Neuronation [11] Cognifit [12] iMentia [13] BrainTest [14] MyCognition [15] Neotiv [16] MoCa [17] 2.3.2. Problemas encontrados Alguno de los inconvenientes principales del software utilizado actualmente son los siguientes: 1. Pago: La mayoría de las aplicaciones son de pago. Aunque hay algunas que tienen un pequeño test de prueba gratuito, luego si se quieren seguir utilizando se tiene que pagar la suscripción. 2. Licencias: aplicaciones como iMentia, necesitan una licencia para poder utilizarse. 2.3. EVALUACIÓN COGNITIVA CON TECNOLOGÍAS DIGITALES 19 3. Supervisión: aplicaciones como iMentia que también realizan un test para valorar un posible deterioro cognitivo a través de diferentes test de cribado, necesita supervisión para poder realizarlos. 4. Disponibilidad: Algunas aplicaciones están únicamente disponibles en un sólo sistema operativo (iOS o Android). O no son compatibles con todos los dispositivos (solo apto para tablets etc...). En las siguientes tablas hacemos un pequeño detalle de las aplicaciones encontradas y sus características. TEST ¿QUÉ EVALÚAN? SUPERVISIÓN NeuroNation Entrenamiento cerebral No BrainTest Videojuegos de acertijos para neuroestimulación No myCognition Velocidad de procesamiento, memoria de trabajo y episódica, atención y funciones ejecutivas No Neotiv Memoria No MoCa Detección de enfermedades neurodegenerativas, desorden del sueño, depresión, esquizofrenia Sí Cognifit Memoria a corto plazo y de trabajo, percepción auditiva y visual, atención y tiempo de respuesta No iMentia Memoria, orientación, lenguaje, atención, razonamiento, funciones ejecutivas y comprensión Sí Cuadro 2.2: Tabla I de aplicaciones 20 CAPÍTULO 2. ESTADO DEL ARTE TEST SONIDO/VOZ PAGO OBSERVACIONES NeuroNation No Pago con evaluación gratuita La prueba gratuita valora la función cognitiva a mejorar. BrainTest No Gratuita Juegos para neuroestimulación, como juegos de palabras, sudokus, etc. myCognition No Pago Programa de 15 semanas dividido en 3 niveles (Avanzado, Intermedio e Introducción) con diferentes ejercicios para cada semana. Neotiv No Pago con evaluación gratuita Total de 5 test de memoria, se hace uno cada 24h. Además, incluye un cuestionario de satisfacción al finalizar cada test. MoCa No Pago Dispone de dos formatos de evaluación, mediante APP y mediante papel. Cognifit Sí Pago con prueba gratuita Aparte de las evaluaciones tiene entrenamientos disponibles para adultos y niños. iMentia Sí Pago y gratis con licencia Cada área de trabajo tiene hasta 6 niveles de complejidad. Cuadro 2.3: Tabla II de aplicaciones 2.3.3. Machine Learning en la evaluación cognitiva La realización y desarrollo de este tipo de aplicaciones, así como el uso activo de las mismas nos puede ayudar a desarrollar ideas innovadoras y eficaces capaces de no discriminar a los individuos de riesgo, identificar a los pacientes en fase preclínica o temprana de la enfermedad, establecer estrategias individualizadas y preventivas para mejorar el pronóstico y la calidad de vida de los pacientes. Una de estas ideas innovadoras es un concepto bastante nuevo de aplicar técnicas de Machine Learning a las herramientas TIC de evaluación cognitiva. En medicina, el análisis de datos está basado en técnicas estadísticas, las cuáles cada vez se van quedando más obsoletas debido al crecimiento de la información almacenada. Por ello, actualmente se ha comenzado a utilizar Machine Learning como herramienta de apoyo que permite analizar datos sintomatológicos de pacientes, para así, poder obtener un diagnóstico lo más acertado posible, y un tratamiento adecuado a seguir. Gracias al desarrollo de las tecnologías y con ayuda de técnicas de Machine Learning, se ha podido hacer una estimación y predecir el estado cognitivo de la persona que se está evaluando, de manera bastante precisa. Entre los diferentes algoritmos utilizados, destacan aquellos basados en árboles de decisión y clasificación. [18] Los árboles de decisión son un modelo de predicción cuyo principal objetivo es el aprendizaje inductivo a partir de observaciones y construcciones lógicas. Este tipo de modelos se construyen 2.3. EVALUACIÓN COGNITIVA CON TECNOLOGÍAS DIGITALES 21 a partir de un problema, en el que se especifican las variables evaluadas, las acciones a tomar y el orden en el que se tomará una decisión. Quedando estructurado de la siguiente manera: Nodo principal o raíz: atributo a partir del cual se inicia el proceso de clasificación. Nodos internos: correspondientes a cada una de las preguntas acerca del atributo en particular del problema. Nodos hijos: corresponden a las diferentes respuestas de los nodos internos. Nodos finales u hoja: corresponden a una decisión, que coincide a su vez, con una de las variables de clase del problema a resolver. Figura 2.2: Estructura árbol de decisión. Tras generar el modelo, sólo un camino será seguido dependiendo del valor de la variable evaluada en cada momento.[19] 2.3.4. Requisitos en herramientas de evaluación cognitiva No solo el desarrollo e implementación de nuevas ideas aplicadas a herramientas TIC son importantes para el desarrollo de las mismas. También hay que considerar una serie de requisitos a cumplir por aquellas herramientas enfocadas a la evaluación cognitiva y que además debimos tener en cuenta para este trabajo. Son los siguientes: 1. Accesibilidad: los SO que predominan entre las personas con dispositivos móviles son iOS y Android, por lo que se desarrolló una APP híbrida para poder alcanzar a el mayor número de personas. 2. Portabilidad: hacer la aplicación para un dispositivo smartphone permite al usuario la posibilidad de hacerlo desde prácticamente cualquier lugar en el que disponga datos. 3. Seguridad: que los resultados de las pruebas del paciente solo estén a disposición del especialista. 4. Facilidad de uso: una APP sencilla e intuitiva y fácil de entender. Capítulo 3 Metodología El objetivo de este TFG, como ya se ha mencionado anteriormente, ha sido el desarrollo de una aplicación móvil en la que, por recomendación médica, las personas puedan realizar una serie de test cognitivos, para que, así, posteriormente, puedan ser evaluados por especialistas en el campo de la neurología. Los principales requisitos de la APP consistían en que sea intuitiva y fácil de usar, además de estar disponible tanto para dispositivos con sistema operativo iOS como Android. Esta aplicación la hemos llamado BrainApp y en ella se pueden diferenciar tres partes: Test de cribado En medicina, el cribado, es la realización de una serie de pruebas que sirven de ayuda para la detección precoz de una determinada enfermedad. En nuestra aplicación incorporamos al comienzo un test de cribado. Este test consta de una serie de preguntas que sirven para poner en situación al paciente y al especialista, que luego evaluará cada una de las pruebas. Dentro de este test de cribado podemos encontrar tres tipos de preguntas: 1. Preguntas al paciente: son cuestiones que se realizan al paciente de cómo se ha encontrado en los últimos meses. ¿Le cuesta recordar cosas? ¿Tiene dificultad para encontrar las palabras al hablar? ¿Se ha desorientado últimamente? ¿Tiene dificultades para utilizar el dinero? ¿Tiene dificultades para recordar eventos recientes? ¿Le piden últimamente que repita las cosas? ¿Tiene dificultades en decir el nombre de los objetos? ¿Tiene dificultades en recordar los nombres de otras personas? ¿Nota mayor ansiedad? ¿Se encuentra bajo de ánimo o decaído? 22 23 Cada una de estas preguntas admite una única respuesta, afirmación o negación. Figura 3.1: Pregunta al paciente 1. Figura 3.2: Pregunta al paciente 9. 2. Preguntas sobre datos demográficos: sirven para saber la edad del paciente, así como su género, además de poder evaluar su nivel cultural. ¿En qué año ha nacido? ¿Hasta qué edad estudió? ¿Cuál es su género? Este tipo de preguntas permiten al paciente introducir manualmente cada una de las respuestas con ayuda de un teclado exclusivamente numérico. En el caso de la última pregunta, simplemente, se le muestran dos botones al paciente para que seleccione la respuesta que considere oportuna. Figura 3.3: Pregunta de datos demográficos. Figura 3.4: Pregunta de datos demográficos. 3. Preguntas de orientación: son preguntas que sirven para saber si el paciente está bien orientado en el día actual en el que está realizando la prueba, así como de la edad que tiene. 24 CAPÍTULO 3. METODOLOGÍA ¿Cuántos años tiene? Escriba la fecha de hoy: día actual, día de la semana, mes y año. Para cada una de estas respuestas al igual que las anteriores, en el caso de ser datos numéricos, al paciente solo se le da la posibilidad de un teclado numérico. En caso contrario, si la respuesta no requiere de números se le muestra el teclado normal del dispositivo. Figura 3.5: Pregunta de orientación 1. Figura 3.6: Pregunta de orientación 2. Todas estas preguntas no tienen ningún tipo de validación instantánea, es decir, si el paciente se equivoca al introducir el día actual o los años no corresponden con el año de nacimiento introducido, la aplicación no muestra ningún tipo de error. El único requerimiento que hay en este test de cribado es que todas las preguntas tengan respuesta. Esto se debe a que todas las respuestas serán guardadas en la BBDD y posteriormente cada una de las respuestas será evaluada por el especialista. Test de destreza Esta parte consta de dos pequeñas pruebas que sirven para saber cómo se desenvuelve el paciente con el dispositivo desde el que está realizando el test. En la primera prueba se muestra una pequeña frase con una palabra resaltada; aquí el paciente deberá escribir dicha palabra. Por otro lado, en la segunda prueba se muestran una serie de figuras geométricas donde se indica al participante que debe pulsar únicamente sobre los círculos. 25 Figura 3.7: Test de habilidad 1. Figura 3.8: Test de habilidad 2. Las respuestas de las dos pruebas de destreza no son guardadas en la BBDD ya que sólo ayudan a que el paciente se desenvuelva a la hora de resolver los test que deberá realizar posteriormente. Test de evaluación cognitiva adaptados Como se ha mencionado anteriormente, este proyecto está desarrollado en colaboración con el grupo de neurología del Hospital Clínico San Carlos. Los neurólogos nos mostraron las pruebas con las que trabajaban actualmente, en las cuales se basaron proponiendo cuatro pruebas adaptadas que pudieran ser realizadas con facilidad desde un dispositivo móvil. Las cuatro pruebas están contextualizadas en el mismo asunto. El tema elegido corresponde con un supermercado ya que lo consideramos un tema con el que todo el mundo puede sentirse familiarizado y, para así, darle cierta armonía al conjunto global de nuestra aplicación. Al comienzo de cada una de estas pruebas mostramos al paciente las instrucciones de esta, así como una pequeña demostración de cómo debe realizarse el test. A continuación, se procede a explicar cada una de las pruebas que contiene nuestra aplicación haciendo referencia a la prueba original en la que está basada. 1. Test de memoria Esta primera prueba de memoria está basada en el FCSRT test y consta de dos partes; una primera parte en la que se evalúa la memoria a corto plazo y libre del paciente; y, una segunda en la que se evalúa la memoria a largo plazo, también conocida como memoria diferida. Nuestra adaptación consiste en mostrarle al paciente nueve palabras que tendrá que recordar, 32 CAPÍTULO 3. METODOLOGÍA 3.2.1. Frontend Para iniciar el diseño frontend de nuestra aplicación primero nos apoyamos en la herramienta de diseño gráfico Adobe XD. Esta herramienta nos ayudó sobre todo para visualizar los primeros bocetos de las principales vistas a desarrollar para la APP creando Mockups para ellas. Estos Mockups son maquetas que se utilizan sobre todo para ayudar a visualizar las primeras ideas en cuanto al diseño móvil que teníamos en mente. Fuimos creando los bocetos de las vistas que teníamos claro que iban a ser las primeras en desarrollarse como es el caso de las pantallas de Login y Register, y de forma posterior el resto de las pantallas. Los siguientes Mockups muestran las maquetaciones iniciales de las pantallas. Figura 3.10: Mockups de las pantallas iniciales. Figura 3.11: Mockups de las pantallas de transición y test de usabilidad. 3.2. ARQUITECTURA 33 Una vez entendido el concepto e idea inicial que teníamos a priori para empezar a desarrollar nuestras vistas, escogimos el entorno de Visual Studio Code para programar y desarrollar el software de toda la parte frontend. El framework utilizado fue el explicado en el punto anterior, React Native, que se basa en el lenguaje de programación Java Script. Para poder estilizar la visualización de nuestros componentes también hicimos uso del lenguaje de diseño gráfico css. Las primeras vistas a desarrollar fueron las que estaban relacionadas con todas las pantallas donde realizamos el test general, este test se realiza para saber la situación y orientación actual del usuario que está haciendo uso de la aplicación, y en su mayoría todas las vistas se basan en preguntas al usuario. El esquema principal de todas las vistas desde momento en el que el usuario abre la aplicación hasta que el usuario termina el test general previo a los test de evaluación cognitiva se encuentran ordenados en el siguiente esquema: Figura 3.12: Estructura de la vistas de la aplicación. El uso de la aplicación se hace de forma secuencial , pues no permitimos que una vez iniciada la prueba se pueda volver hacia atrás. Esto se diseño específicamente así para que no se pudiesen retroceder y bien cambiar la respuesta o volver a repetir algún otro tipo de prueba de los test cognitivos. Las siguientes imágenes muestran el diseño que finalmente dimos a nuestras tres pantallas iniciales: 1. Splash Screen 34 CAPÍTULO 3. METODOLOGÍA 2. Login Screen 3. Register Screen (Según hemos listado de arriba, abajo, se muestran de izquierda a derecha). Figura 3.13: Spash Screen Figura 3.14: Login Screen Figura 3.15: Register Screen De estas tres pantallas, destacaremos la actividad de la principal, que es la vista Login Screen. Esta pantalla se encarga sobre todo de la acción de Inicio de Sesión del usuario, y es por ello que partir de esta pantalla comienza de forma secuencial las preguntas generales y los test de evaluación cognitiva así como la interacción del usuario con la aplicación. La interacción cliente-sistema para el inicio de sesión se describe en la imagen 3.16 en cinco pasos. 1. Acceder a la aplicación: primero mostramos la vista Splash Screen una vez el usuario accede a la aplicación, esta vista muestra nuestro logo durante un par de segundos y redirige directamente a la pantalla de Login. 2. Pedir datos: la vista Login Screen pide directamente los datos , como hemos visto en la imagen , 3. Ingresar datos: el usuario tiene que introducir un correo y contraseña válidos. 4. Verificar usuario: los datos introducidos por el usuario se envían a través de una llamada a la API y se cotejan con nuestros datos de la BBDD que tenemos desplegada en AWS. 3.2. ARQUITECTURA 35 Figura 3.16: Diagrama de secuencia de Inicio de Sesión. 5. Mostrar actividad principal: una vez se ha comprobado que el usuario y contraseña se corresponden con un usuario registrado previamente se redirige al usuario a la página Wellcome Screen, a partir de está pantalla daremos dos opciones al usuario , o bien salir e iniciar la prueba o bien iniciar la actividad y comenzar con las preguntas generales y test. 3.2.2. Backend Para realizar una comunicación entre nuestro Frontend y nuestra base de datos hemos tenido que desarrollar una API en el entorno de programación Laravel. Esta decisión fue tomada porque Laravel es un framework del lenguaje de programación php y nuestro nivel de familiaridad con este lenguaje es alto, también hemos tenido en cuenta su fácil acceso a la base de datos, pero esto será explicado en unos apartados más adelante. Laravel es un framework basado en el patrón arquitectónico MVC (Modelo Vista Controlador) que incluye en sus modelos un sistema de datos relacional llamado ELOQUENT ORM que nos facilita la creación de modelos y conectarlos con nuestra base de datos. También incluye Controladores, es la parte del backend que dota nuestra aplicación de funcionalidad y nos permite organizar el código en clases [23]. Laravel también incluye un sistema de vistas llamado Blade, que en este proyecto no se ha utilizado porque para desarrollar el API no era necesario. 1. Eloquent Laravel trabaja con Eloquent ORM, que son los encargados de almacenar la información y los accesos a esta. Eloquent ORM, es un sistema que nos facilita la conexión con la base de datos, nos permite 36 CAPÍTULO 3. METODOLOGÍA manejar los datos por medio de objetos (modelos), de esta manera, realizamos consultas a la base de datos desde nuestros modelos. Para nuestra aplicación, hemos creado doce modelos que están relacionadas con doce tablas en la BBDD. Para poder entender mejor Laravel Eloquent, a continuación mostraremos el modelo Memory.php 1<?php 2namespace App\Models; 3 4use Illuminate\Foundation\Auth\User as Authenticatable; 5use Illuminate\Notifications\Notifiable; 6use Laravel\Passport\HasApiTokens; 7 8class Memory extends Authenticatable 9{ 10 use Notifiable, HasApiTokens; 11 12 protected $table = ’memory_test’; 13 14 /** 15 *The attributes that are mass assignable. 16 *@var array 17 */ 18 protected $fillable = [ 19 ’user_id’, 20 ’word_1’, 21 ’word_2’, 22 ’word_3’, 23 ’word_4’, 24 ’word_5’, 25 ’word_6’, 26 ’word_7’, 27 ’word_8’, 28 ’word_9’, 29 ’fails’, 30 ’points’ 31 ]; 32 } Como podemos observar en el código mostrado, el modelo Memory almacena en el campo fillable los datos que se van a almacenar en nuestra tabla memory_test. Este modelo se encaga de conectarse con nuestra tabla memory_test y almacenar las palabras, el número de fallos y el número de aciertos que el usuario ha escrito en nuestra APP. 2. Rutas y Middleware Laravel permite utilizar un controlador de rutas muy sencillo. Al crear un nuevo proyecto, el propio entorno de programación nos crea una sección de rutas para controlar la funcionalidad que va a tener nuestra API. A continuación se mostrara un ejemplo de rutas de nuestra API en Laravel api.php 3.2. ARQUITECTURA 37 1<?php 2use Illuminate\Http\Request; 3use App\Http\Controllers\Api\AuthController; 4use App\Models\Demographics; 5use App\Models\InitialEvaluatiton; 6 7/* 8|--------------------------------------------------- 9| API Routes 10 |--------------------------------------------------- 11 | 12 | Here is where you can register API routes for your application. These 13 | routes are loaded by the RouteServiceProvider within a group which 14 | is assigned the "api" middleware group. Enjoy building your API! 15 | 16 */ 17 18 //AUTENTICATION (logIn and logOut) 19 Route::group([ 20 ’prefix’ => ’auth’ 21 ], function () { 22 Route::post(’login’, [AuthController::class, ’login’]) ; 23 Route::post(’signup’, [AuthController::class,’signUp’ ]); 24 25 Route::group([ 26 ’middleware’ => ’auth:api’ 27 ], function() { 28 Route::get(’logout’, [AuthController::class, ’ logout’]); 29 Route::get(’user’, [AuthController::class,’user’]) ; 30 }); 31 }); 32 33 //Initial test 34 Route::post(’addQuestions’, [InitialEvaluationController:: class, ’addQuestions’])->middleware(’auth:api’); 35 36 37 //Demographics Test 38 Route::post(’addAnswers’, [DemographicsController::class, ’addAnswers’])->middleware(’auth:api’); Como podemos observar, para definir una ruta es importante indicar el método HTTP que esta va a tener, por ejemplo get, post, update o delete. También será necesario indicar el controlador que se encargará de realizar la funcionalidad a la que queremos direccionar mediante la ruta creada. La sección rutas de Laravel también nos ofrece una funcionalidad muy útil para la gestión de 38 CAPÍTULO 3. METODOLOGÍA acceso (guardar información o modificar datos), esta gestión de acceso son los middleware. Los middleware, son archivos o controladores que se ejecutan cuando se realiza una petición a nuestra API, este mecanismo sirve para filtrar las peticiones HTTP que entran en nuestra aplicación. Por ejemplo en nuestro proyecto hemos utilizado el middleware que Laravel nos ofrece por defecto (auth:api), este middleware verifica que el usuario que está realizando la petición este autentificado en nuestro proyecto. Si el usuario no está autentificado, nuestra API devolverá un mensaje de error, pidiendo al usuario que se identifique (iniciar sesión). Sin embargo, en caso de que el usuario se haya autentificado previamente, el middleware permitirá que la petición continúe. 3. Controladores Los Controladores son las clases que se encargan de añadir la parte funcional a nuestra aplicación. En nuestro proyecto tenemos doce controladores : AuthController: Gestiona el registro y el inicio de sesión del API. Cuando un usuario inicia sesión correctamente, este controlador se encargará de crear un token para poder mantener la sesión activa, de esta forma se le permite al usuario continuar con la aplicación. Un token es una clave de acceso personal que se utiliza para autenticar las solicitudes HTTP que se realizan a nuestra aplicación. InitialEvaluationController: Este controlador recibe las respuestas que el usuario ha realizado en la primera parte de la aplicación. OrientationController, DemographicController: Estos controladores se encargan de comprobar y validar que las respuestas obtenidas después de que el usuario complete el test de Orientación y el test de datos demográficos. Estos controladores utilizan los modelos Orientation y Demographic para almacenar los datos obtenidos en las tablas orentation_test y demographic_test. AlimentationController, AseoController, CleanningController y Memorycontroller: Estos controladores gestionan y validan las respuestas que el usuario ha ingresado al realizar el test de memoria, este test consiste en mostrar 9 palabras distintas pertenecientes a tres departamentos de un supermercado. Después de que se muestren las palabras, el usuario deberá introducir las palabras que este recuerde. Estos controladores se encargan de analizar las palabras que el usuario ha introducido, para realizar las comprobaciones entre las palabras correctas y las palabras que introduce el usuario, nos decantamos por utilizar la función similar_text() de php. La función similar_text calcula la similitud entre dos strings (palabras) y nos devuelve la similitud en porcentaje, para el Test de Memoria decidimos que el mínimo porcentaje de similitud entre las palabras debería ser el 75%. De esta forma almacenamos todas las respuestas que el usuario ha introducido, el número de palabras correctas, que es este caso serían las palabras que tengan un porcentaje de similitud superior al 75%, y el número de palabras incorrectas, las cuales serían aquellas que no lleguen al 75%. 3.2. ARQUITECTURA 39 FluentController: Este controlador almacena las respuestas que el usuario ha introducido en el test de Afluencia, los datos que este controlador se encargará de almacenar utilizando el modelo Fluent, son el número de diseños únicos, el número de repeticiones, y el número total de diseños. LocationController: Este controlador procesa los datos recibidos del usuario al realizar el test de localización. DenominationController: Este controlador valida las respuestas que el usuario introduce en el test de denominación, este test consiste en mostrar una imagen al usuario, y este deberá escribir el nombre del objeto que se le está mostrando. Para realizar las comprobaciones necesarias entre el nombre del objeto y la palabra que introduce el usuario, decimos que para este caso lo mejor sería utilizar la función de levenshtein(). La función de Levenshtein calcula la distancia entre dos strings. Por ejemplo si tenemos una palabra coche y otro carro, la distancia de Levenshtein sería 4 porque se necesitan cambiar 4 caracteres para que la palabra coche sea igual a carro. Para este test, se tomarán como correctas las palabras que tengan una distancia menor al 30 %. PasswordController: Este controlador se encarga de realizar el cambio de contraseña en caso de que el usuario lo solicite, para ello hemos creado tres funciones principales. • create: esta función se encarga de verificar que el usuario que ha solicitado el cambio de contraseña exista en la BBDD, en caso afirmativo, esta función se encarga de crear un nuevo token que será reenviado al usuario vía email. • find: Esta función se encarga de verificar que el token que se le ha enviado al usuario sigue siendo válida ya que tienen un periodo de validez de dos horas. • reset: Después de verificar que el token previamente enviado al usuario, es válido, esta función recibe como argumento la nueva contraseña del usuario y se encarga de encriptar la contraseña utilizando la funcion bcrypt() de php para luego guardarla en nuestra base de datos. A continuación mostraremos un ejemplo de Controlador en Laravel OrientationController.php 1<?php 2 3namespace App\Http\Controllers\Api; 4 5use App\Http\Controllers\Controller; 6use Illuminate\Support\Facades\Auth; 7use App\Models\User; 8use App\Models\Orientation; 9use Carbon\Carbon; 10 use Illuminate\Http\Request; 11 12 class OrientationController extends Controller 13 { 14 /** 40 CAPÍTULO 3. METODOLOGÍA 15 *Add users answers to table orientation_test 16 */ 17 public function addAnswersOrientation(Request $request) 18 { 19 $request->validate([ 20 ’year’ => ’required’, 21 ’month’ => ’required|string’, 22 ’weekDay’ => ’required|string’, 23 ’monthDay’ => ’required’, 24 ’user_years’ => ’required’ 25 ]); 26 27 Orientation::create([ 28 ’user_id’ => Auth::user()->id, //get user id that is autenticated 29 ’year’ => $request->year, 30 ’month’ => $request->month, 31 ’weekDay’ => $request->weekDay, 32 ’monthDay’ => $request->monthDay, 33 ’user_years’ => $request->user_years 34 ]); 35 36 return response()->json([ 37 ’message’ => ’Successfully evaluation filled!’ 38 ], 201); 39 } 40 41 } Como podemos observar en el código de ejemplo, el controlador OrientationController, solo tiene un método, addAnswersOrientation, este método se encarga de comprobar que todos los datos recibidos por la petición existan y sean válidos. En caso de que recibamos una petición con datos incorrectos, Laravel automáticamente devolverá un mensaje de error informando los datos que faltan para realizar la validación correctamente, por otro lado si los datos se han validado correctamente, esta función se encargará de llamar al Modelo Orientation, creado previamente, para almacenar los datos en la BBDD. 3.2.3. Base de Datos Para el desarrollo del API, decidimos que la mejor opción para poder almacenar los datos sería utilizar una Base de datos open source, por ese motivo nos decantamos por utilizar Mysql. La arquitectura de la APP está basada en el modelo cliente-servidor. Esto quiere decir que la base de datos se encuentra en un servidor externo, en nuestro caso, la BBDD se encuentra en AWS. A ella se accede a través del API del servidor mediante llamadas HTTPS. Esta base de datos almacenará toda la información de la aplicación, desde la información de los usuarios registrados en ella, así como las respuestas introducidas por los mismos. Actualmente la base de datos tiene la siguiente estructura 3.17: 3.2. ARQUITECTURA 41 Figura 3.17: Estructura BBDD. La BBDD consta de 12 tablas en las que cada una almacena las respuestas de los usuarios y los datos personales de estos. Tabla users: almacena los datos de los usuarios registrados en la APP. Tabla password_resets: esta tabla almacena el token junto con la fecha y la hora en la que se genera. Esta tabla se modifica cada vez que un usuario solicita un cambio de contraseña. Tabla evaluation_test: en esta tabla se almacenan las respuestas de las 10 primeras preguntas del test de cribado. Tabla demographics_test: guarda las respuestas del participante correspondientes segundo grupo de preguntas del test de cribado Tabla location_test: guarda por cada una de las pantallas del test de localización un booleano (true/false) en caso de haber acertado o no, así como el número total de aciertos, fallos y puntos al finalizar el test. 48 CAPÍTULO 3. METODOLOGÍA Las tarjetas solían representar tareas concretas, hitos y listas de acciones a realizar por parte de todos o algunos de los desarrolladores o testers. Este entorno nos lo facilitó la plataforma web Trello, que guardaba, actualizaba y comunicaba (vía email) de forma distribuida e inmediata todas las tareas y sus estados cada vez que se creaban, asignaban o cambiaban de estado las tarjetas. 3.4.3. Organización General 1. Departamento de Neurología: El departamento de neurología del Hospital Clínico San Carlos, que propuso el desarrollo de la aplicación para evaluar las capacidades cognitivas de sus pacientes, está formado principalmente por el neurólogo Jordi Matias-Guiu Antem, como jefe y supervisor en la parte clínica de este proyecto, así como Vanesa Pytel Córdoba, como neuróloga y encargada del test de denominación del lenguaje y del test de memoria, Alfonso Delgado Álvarez como neuropsicólogo encargado del test de localización de objetos y del test fluencia de diseños y Cristina Delgado Alonso, como ayudante de neurología, encargada de supervisar los test que realizaron dos de los alumnos en el hospital. 2. Equipo de desarrollo: El equipo de desarrollo está formado por los alumnos que realizan este proyecto: Arantxa, Andrea, Jhoselin y Jaime en calidad de programadores, investigadores y redactores de forma predominantemente equitativa y en función de las necesidades del proyecto en cada momento. Así como el tutor Jose L. Ayala que a parte de poner en contacto a los médicos y los desarrolladores, también cumplía el rol de consultor para temas de arquitectura, diseño o tecnologías empleadas. 3. Reuniones con el tutor: Con el ánimo de tener seguimiento del desarrollo y de los avances, se acordó desde un inicio a tener reuniones periódicas, en las cuales el tiempo entre reunión era de por defecto de una semana y fue variando en función de la disponibilidad, periodos de exámenes, vacaciones o sprints de desarrollo. De forma asíncrona, para consultas y dudas utilizó la comunicación vía email. 4. Viernes neurocomputacional: Un viernes de cada mes, se produce una reunión en la que se tratan temas relevantes sobre diferentes proyectos neurocomputacionales, en la que están invitados médicos del Hospital Clínico San Carlos, investigadores y desarrolladores de ambos campos. En este encuentro los diferentes participantes realizan presentaciones del estado del arte y los progresos de sus proyectos. Tras cada presentación se aportan ideas y se hacen comentarios y se contrastan los resultados obtenidos. En lo que nos compete de este proyecto, se participó en el mes Septiembre. Se expuso a los asistentes una fase de análisis y de prototipos. Se analizaron los test que habitualmente 3.4. PLANIFICACIÓN DEL PROYECTO 49 se realizaban para estudios de capacidades cognitivas, también se diseñaron prototipos para la implementación de dichos test en dispositivos móviles. Tras la presentación, los doctores nos hicieron comentarios sobre los test y nos dieron pautas para el futuro. Así, nos propusieron diseñar nuevos test diferentes a los habituales, pero que evaluaran las mismas capacidades cognitivas. Es entonces cuando se definió que la forma de trabajo y comunicación entre desarrolladores y doctores iba a ser más directa, a continuación profundizamos en esta metodología de trabajo. 5. División en subgrupos: Tras las varias reuniones con todos los integrantes de este proyecto, y con el fin de tener una comunicación más fluida, poder consultar dudas y compartir la viabilidad técnica de los test, el tutor propuso asignarlos, de tal forma que cada test iba a ser abordado por una pareja de doctor-alumno. Quedando organizado de la siguiente manera: Vanesa - Andrea: Test relacionado con la denominación de objetos. Jordi - Jhoselin: Test relacionado con la memoria Alfonso - Jaime: Test relacionado con la detección de objetos y test relacionado con la fluencia de diseños. Participando en cada uno de los subgrupos Vanesa, Jordi y Alfonso en calidad de supervisores clínicos. Mientras tanto, Arantxa se encargaría de preparar la estructura de la aplicación y la arquitectura de comunicación con la API y la base de datos. Estos grupos trabajarían de forma ágil y elegirían entre ellos tanto la vía de comunicación ya fuera por mensajería instantánea, como por Meetings online y la frecuencia de los mismos. 6. Drive Compartido: El tutor, creó una carpeta compartida en Google Drive, a la que tenían acceso tanto los alumnos como los médicos, en la cual se agregaron documentos relativos a los diferentes test existentes, documentación relevante a programas de ordenador que evaluaban capacidades cognitivas, y otros estudios de interés sobre el tema. Este espacio, sirvió también como lugar de trabajo en la definición de los test, así como comentarios y actualizaciones. Que daban constancia por escrito de requisitos, correcciones, avances, etc. 3.4.4. Cronograma A continuación se puede observar el cronograma completo del proyecto, que abarca desde el 01/10/2020 hasta el 06/06/2021. En la siguiente imagen se pueden contemplar las diferentes fases de desarrollo del mismo, así como las tareas que forman cada una de las fases. Cronograma BrainApp TÍTULO DEL PROYECTO BrainApp FECHA DE INICIO 01/10/20 FECHA DE FIN 06/06/21 FASE DETALLES C1 C2 OCT NOV DIC ENE FEB MAR ABR MAY JUN SEMANA DEL PROYECTO: Semana 1 4 11 18 25 1 8 15 22 29 1 6 13 20 27 1 3 10 17 24 31 1 7 14 21 28 1 7 14 21 28 1 4 11 18 25 1 2 9 16 23 30 1 6 13 20 27 1Concepción e inicio del proyecto 1 - Estudio de baterías de test de evaluación cognitiva existentes 1 F I N D E L P R O Y E C T O 2 - Propuesta de adaptación de test cognitivos 2 3 - Diseño de Mockups 3 4 - Presentación primer viernes computacional 4 2Desarrollo Frontend 5 - Investigación e instalación de herramientas utilizadas 5 6 - Creación inicial de la estructura del proyecto 6 7 - Creación pantallas iniciales (Splash, Login y Registro) 7 8 - Creación pantallas de preguntas al paciente 8 9 - Creación pantallas de preguntas demográficas 9 10 - Creación pantallas de preguntas de orientación 10 11 - Creación pantallas test de habilidad 11 11 11 12 - Creación pantallas test denominación 12 12 12 13 - Creación pantallas test localización 13 13 13 14 - Creación pantallas test memoria 14 14 14 15 - Creación pantallas test fluencia de diseño 15 16 - Creación pantalla de recuperación de contraseña 16 17 - Control de errores 17 18 - Resolución dependencias con iOS 18 3Desarrollo Backend 19 - Investigación e instalación de herramientas utilizadas 19 19 19 20 - Creación BBDD 20 21 - Creación API 21 22 - Conexión BBDD con API 22 23 - Control de errores 23 23 24 - Creación de controladores para la recopilación de datos 24 24 25 - Conexión interfaz con API 25 4Desarrollo Cloud 26 - Estudio AWS 26 26 27 - Despliegue API 27 27 28 - Despliegue BBDD 28 28 5Lanzamiento y Ejecución 29 - Investigación entornos de simulación 29 29 30 - Generación .apk para testeo 30 31 - Pruebas en dispositivos Android 31 32 - Generación .ipa para testeo 32 32 33 - Pruebas en dispositivos iOS 33 6Cierre del proyecto 34 - Generación .apk definitivo 34 35 - Generación .ipa definitivo 35 36 - Test de usabilidad 36 37 - Documentación 37 Exámenes 3.4. PLANIFICACIÓN DEL PROYECTO 51 3.4.5. Descripción individual del trabajo realizado En esta sección, vamos a describir individualmente el trabajo realizado por cada uno de los integrantes del grupo, mencionando las tareas reflejadas en el cronograma mostrado anteriormente. Está descripción se realizará de la siguiente manera: 1. Descripción I: Andrea 2. Descripción II: Arantxa 3. Descripción III: Jaime 4. Descripción IV: Jhoselin De todas las tareas y subtareas identificadas en el cronograma anterior, cada integrante de nuestro grupo se centró y realizó una mayor participación en algunas en concreto. Fuimos repartiendo los puntos a trabajar y desarrollar en función de nuestras aptitudes, aunque realizamos una participación mínima en todas las tareas, para mantener una comprensión y entendimiento general sobre cómo estaba avanzando el proyecto. Descripción I Como mostramos en el cronograma, las primeras tareas realizadas estaban orientadas sobre todo al estudio de las baterías de test cognitivos utilizados actualmente, aplicaciones móviles que realizan una evaluación cognitiva y de comportamiento parecido al de nuestra futura aplicación, también páginas web y algún otro tipo de herramienta digital que se utilizase actualmente para la evaluación cognitiva. Cada uno de nosotros realizó este estudio inicial por separado. Tras pasar los primeros días trabajando, mantuvimos una reunión junto con dos doctores y un neuropsicólogo del departamento de neurología del Hospital Clínico San Carlos, ellos mismos nos propusieron realizar una adaptación de los test que se realizaban en su departamento. Fueron varios los tipos de test propuestos por lo que decidimos centrarnos en uno en concreto y repartírnoslo. Yo en especial me centré en el VOSP Test, y empecé investigando estudios publicados sobre su metodología para aprender cómo funcionaba y se presentaba a los pacientes. Fuimos haciendo algunas reuniones para ir poniendo en común nuestras ideas para la adaptación de los test, así como las primeras características generales que debía tener nuestra aplicación. Como es habitual en el desarrollo software, previamente al diseño de una aplicación se realizan una serie de maquetaciones y bocetos para hacerse una idea general de lo que quieres construir. Estos bocetos se les conoce como mockups y se realizan con la ayuda de alguna herramienta digital o también a papel. Se escogió realizarlo con la ayuda de la herramienta digital Adobe XD que hemos mencionado en el apartado 3.2 Herramientas Utilizadas. A parte de diseñar algunos bocetos para pantallas generales, de forma individual, se realizaron mockups para las posibles adaptaciones de nuestros test. Yo en particular, me centré en la creación de los mockups de la adaptación de dos subtest (dado que el VOSP Test es una batería que conformada por varios subtest) del test en el que me había centrado. 52 CAPÍTULO 3. METODOLOGÍA Tras una presentación de nuestras primeras propuestas y una reunión con nuestro coordinador y los doctores, se nos detallaron las pruebas que debían incluirse en la aplicación; estas serían cuatro pruebas diferentes y también una serie de preguntas generales y de orientación. Para trabajar de forma más sencilla en el desarrollo de cada una de las pruebas, decidimos hacerlo por parejas; cada pareja se conformaba por un especialista (doctor o neuropsicólogo) y uno de los integrantes de nuestro equipo. Yo trabajé con Vanesa, neuróloga del hospital con el que hemos colaborado y realizamos tanto la adaptación como otras características del Test de denominación del Lenguaje que hemos mencionado en la introducción del apartado 3. Metodología. Para empezar con el desarrollo frontend tuvimos que pasar por un periodo de estudio y aprendizaje, así como la instalación previa de todas las herramientas necesarias para empezar a programar con el framework React Native. Después de terminar la correcta instalación del software necesario, nos pusimos en concreto con la creación de la estructura del proyecto. El inicio de este proyecto se creó en Visual Studio Code y lo subimos a GitHub para poder compartir todas las modificaciones entre todos los integrantes del grupo. Una vez creado el proyecto inicial y decidida su estructura, empecé con la creación de las pantallas iniciales, Splash (pantalla de inicio a la aplicación), la pantalla de Login (Inicio de Sesión) y la pantalla de Register (Registro). El código desarrollado lo llevé a cabo junto con otra de los integrantes de nuestro equipo repartiéndonos equitativamente el trabajo. Una vez terminadas las vistas de estas pantallas y tras otra reunión con los doctores del Hospital Clínico, concretamos las preguntas iniciales que se realizarían a los pacientes previamente y participé de la misma forma que he indicado para el desarrollo de las pantallas iniciales, es decir desarrollando el trabajo de forma equitativa junto con un integrante más. Todo el cuestionario inicial lo comprendían diez pantallas de preguntas generales, dos pantallas de preguntas de orientación, y cuatro pantallas de preguntas demográficas, sumando un total de dieciséis pantallas que nos dividimos a la mitad. Realicé la creación de esas pantallas, así como las pantallas de información necesarias al inicio de cada tipo de bloque de preguntas. Terminando esta parte, empecé con el desarrollo y creación de las pantallas para el Test de Denominación del Lenguaje. Al ser esta una prueba adaptada de un test cognitivo necesité reunirme varias veces con Vanesa, para concretar algunas especificaciones del diseño y de la funcionalidad. Este test estaba compuesto por veinte pantallas, y además de forma posterior se añadieron dos pantallas más para incluir demostraciones de la prueba y ayudar al paciente a entender como se realizaría. A todas estas pantallas se le sumó la creación de otras pantallas de información para indicar al paciente el orden y el tipo de test a realizar además de otras pantallas para mostrar las instrucciones. Una vez fuimos terminando la parte frontend, se realizó un proceso para el control de errores en la aplicación. Realizamos gracias a los entornos de simulación Android Studio y XCode una revisión 3.4. PLANIFICACIÓN DEL PROYECTO 53 del funcionamiento de nuestra APP, y recogimos un listado de posibles escenarios con los que nos podríamos encontrar y podrían dar error. Dentro de todos los tipos de control de errores, yo me centré en los de la parte frontend, en especial en los posibles casos en los que el usuario estaba inactivo por un tiempo prolongado, también en control de tipos, que es cuando el usuario introduce una entrada de un tipo diferente al esperado, esto es por ejemplo cuando esperamos una entrada de tipo numérico y la entrada recibida sea de tipo string y viceversa. Otro tipo de control de errores que apliqué fueron el control de entradas vacías, para evitar en muchos de los casos donde necesitamos saber la respuesta del usuario a una pregunta y se le impidiese pasar a la siguiente pantalla o volver hacia atrás hasta que contestase, esto se hizo informando con un mensaje de alerta. Después de la aplicación de control de errores a la aplicación, se volvió a realizar la simulación completa de la secuencia de la aplicación para comprobar que estos controles de errores aplicados funcionaban correctamente. Para la parte de desarrollo backend, también se realizó en grupo un estudio de las herramientas que necesitaríamos, así como la sintaxis que queríamos utilizar y el servidor que íbamos a escoger para almacenar nuestra BBDD. Una vez acordado tuve que aprender al principio el funcionamiento de estas mismas y realizar la instalación correcta de todas las herramientas (Laravel, MySQL Workbench, Postman, etc.) para empezar a trabajar con ellas y realizar futuras pruebas. Cuando fueron creadas por otro de los integrantes del grupo la API y BBDD, realicé varias pruebas necesarias para conseguir la recepción adecuada de las respuestas del Test de Denominación del Lenguaje. Para el posterior despliegue en la nube de nuestra API y BBDD también tuvimos que estudiar como funcionaban los servicios que nos ofrecía Amazon Web Services y como podíamos utilizarlos. Cuando terminamos con una primera versión funcional de la aplicación debíamos realizar pruebas de testing para comprobar el correcto funcionamiento de esta. Para ello investigamos en como generar el fichero ejecutable de nuestra APP y una vez obtenido realizamos las pruebas. En mi caso cabe destacar que al no disponer de un dispositivo iOS no realicé pruebas para esta versión, pero si las realicé para Android. De esta forma pudimos encontrar algún fallo o punto de mejora, solucionarlo o mejorarlo antes de obtener la versión funcional. Por último, realicé en conjunto con mis compañeros el diseño de la estrategia de evaluación de usuarios y las preguntas que íbamos a aplicar en el test de usabilidad. Descripción II Las primeras tareas realizadas fueron investigar las baterías de los test, aplicaciones, páginas web y herramientas utilizadas para la evaluación cognitiva mediante la realización test neurocognitivos. A su vez, se nos pidió de algunos de los test utilizados en el Hospital Clínico San Carlos en la actualidad, una posible adaptación propuesta por nosotros. Para ello, hubo que estudiar cada uno de los test, como las áreas cognitivas que evaluaban, y hacer varias reuniones entre los integrantes del grupo para poner en común todas nuestras ideas. 54 CAPÍTULO 3. METODOLOGÍA Después de una investigación profunda de varias semanas y una idea común aceptada por todos, realizamos una presentación en la que proponíamos nuestras adaptaciones, incluyendo mockups realizados por nosotros mismos, para que pudiese quedar clara la idea propuesta. Tras esa presentación, y reuniones con nuestro tutor y el grupo de neurólogos, se nos explicó en qué iba a consistir finalmente la aplicación que íbamos a desarrollar y las diferentes pruebas que dicha aplicación iba a contener. Para ello, se dividieron las principales tareas en subgrupos dentro del grupo de trabajo para hacer más dinámico el trabajo. Para la parte de frontend, decidimos trabajar con React Native, puesto que es un framework con el que ninguno había trabajado antes, tuvimos que investigar la forma de utilización del mismo, así como su correcta instalación. Una vez instaladas las herramientas para empezar con el desarrollo del frontend por cada uno de los integrantes del grupo, mientras mis compañeros se dedicaban al desarrollo de la parte frontend, yo me dedicaba a la parte del backend. No se nos propuso ninguna herramienta en concreto para esta parte, por lo que tras reuniones entre el grupo de trabajo e investigar cada uno aquellas que nos pudiesen ser más fáciles y comprensibles de usar. Decidimos utilizar Laravel, ya que algunos integrantes del grupo habían trabajado antes con este framework y hacer una BBDD sql. Aun así tuve que estudiar su forma de instalación y utilización, ya que era completamente nuevo para mí. Tras la instalación del framework y todas las herramientas que se necesitaban para su utilización, como MySQL Workbench para la visualización de la BBDD, Laravel para hacer pruebas de inserción de datos en la BBDD, etc. Creé la API que utilizaríamos para el proyecto. Después de varias reuniones entre los integrantes del proyecto, exponiendo a mis compañeros mis ideas y presentando un posible esquema sobre la BBDD, las principales tablas que formarían la API y los datos que se guardarían en cada una de las tablas; comencé con la creación de la BBDD que iría integrada en la API creada anteriormente. Esto supuso la creación de las primeras migraciones, modelos de datos y controladores para cada una de las primeras tablas de la BBDD. Estas fueron: la tabla de usuarios (users), la tabla de preguntas al paciente (questions), la tabla de preguntas demográficas (demographics) y la tabla de preguntas de orientación (orientation). En este caso, el modelo de datos de cada una de las tablas contiene los diferentes atributos que se guardan en la tabla; así como sus respectivos controladores que se encargan de validar los datos introducidos por el paciente, es decir, que correspondan con los que admite la tabla, como los tipos de datos (string, bool, etc.) y de crear la fila correspondiente en la tabla. Tras la creación de las tablas, con ayuda de Postman, comencé a hacer pruebas para la inserción de los datos en cada una de las tablas. A su vez, se expuso un control de errores, en el que destacan el caso de que los datos introducidos no correspondían con los requeridos, que no hubiese conexión con la BBDD, etc. Una vez me aseguré de que los datos se incluían correctamente, se conectó la BBDD con la API. 3.4. PLANIFICACIÓN DEL PROYECTO 55 Una vez conectada la API con la BBDD y asegurándome de que seguía funcionando correctamente, se comenzaron a conectar cada una de las tablas del backend con su parte correspondiente en el frontend. Este proceso fue algo más largo, porque iban surgiendo errores tanto en backend como en frontend y entre mis compañeros y yo tuvimos que ir solucionándolos. Cuando la parte de registro, inicio de sesión y el guardado de las primeras respuestas de los usuarios estuvo correcta, procedí a crear las tablas de las pruebas principales, en el siguiente orden: tabla del Test de Localización, tabla del Test de Denominación del Lenguaje, tabla del Test de Memoria y finalmente la tabla del Test de Fluencia de Diseño. Para ello se crearon sus migraciones, modelos de datos y controladores correspondientes. A diferencia de las cuatro primeras tablas que creé al comienzo, estas fueron algo más complejas de crear. Esto se debe a que a parte de guardar cada una de las respuestas del usuario que está haciendo la prueba, se calculan el número de fallos y el número de aciertos finales. Por lo que cada uno de los controladores además, contiene la lógica correspondiente en lenguaje php para obtener las puntuaciones correspondientes. Tras crear las diferentes tablas y ser probadas de nuevo con Postman, las conecté con sus correspondientes partes en frontend. Una vez hecha esta conexión en cada una de las pruebas, se comenzó un proceso largo de pruebas, ya que al comienzo no se introducían bien en la base de datos, o directamente la conexión con la BBDD fallaba. Finalmente, cuando todo el flujo de frontend y backend funcionaba correctamente, se creó la instancia en AWS de la API y la BBDD. Haciendo previamente un estudio de como hacer el despliegue de ambas en AWS. Cuando la instancia se creó y funcionaba correctamente desde nuestros ordenadores, investigué sobre la forma de generar un archivo ejecutable para poder probar la APP desde un dispositivo móvil. Tras su correspondiente investigación,tuvimos que generar dos ejecutables diferentes, uno para Android, llamado .apk y otro para iOS llamado .ipa. El .apk podía ser generado desde cualquier ordenador, pero el .ipa únicamente se podía hacer desde un ordenador con sistema operativo macOS. Por lo que me centré en generar el correspondiente .apk, ya que el sistema operativo de mi ordenador es Windows. Este proceso nos llevó bastante tiempo, porque nos fuimos dando cuenta de errores en el flujo de las pantallas que tuve que solucionar con mis compañeros, como los contadores de tiempo que generaban errores en el paso de pantallas, correcciones de estilos en las pantallas, etc. En este proceso también estuvo presente nuestro tutor, ya que cada .apk generado a parte de ser probado por nosotros mismos, fue probado por él y nos iba dando feedback sugiriendo algunos cambios. Se hicieron todas las correcciones pertinentes, y posteriormente me centré en generar el .apk definitivo con el cuál hemos presentado este trabajo, y que tienen tanto el tutor cómo el grupo de neurólogos, para hacer sus correspondientes pruebas. 56 CAPÍTULO 3. METODOLOGÍA Al mismo tiempo del período de generación de archivos ejecutables, junto con mis compañeros propusimos una serie de preguntas que servirían de ayuda para mejoras futuras de la APP, como test de usabilidad. El cual fue aprobado por nuestro tutor y difundido a los doctores. Descripción III Como podemos ver en el cronograma, la primera fase es el estudio de baterías de test de evaluación cognitiva existentes. En ella los analizamos, para entender cuál era su función y cómo se realizaban, qué normas había que seguir para su realización y cómo interpretar sus resultados. Tras esto, realicé test de forma presencial, en el hospital. El programa que utilicé (“Vienna Test System”), implementa una batería de test, que me proporcionó información sobre cómo se disponían test en una plataforma digital, en vez de los tradicionales, en papel. Después de esta fase de análisis de las pruebas cognitivas, participé en las propuestas de adaptaciones de test concretos a una aplicación móvil. Esta fase estudió cuales eran más viables y qué ventajas y desventajas se nos presentan al utilizar un smartphone, como medio para las pruebas. Lo más importante de esta fase es la generación de nuevos test. Es decir, test que evaluaran las mismas capacidades cognitivas, pero fueran diferentes a los originales. De forma complementaria, estudié test similares, existentes en otras entidades. Busqué características como: qué evaluaban sus test, si usaban sonidos, si necesitaban de supervisión y si eran de pago. El siguiente paso fue la realización de mockups y prototipos de las adaptaciones. En concreto, yo realicé la adaptación del test de “La Torre de Londres”. Este test disponía reglas similares, pero en lugar de utilizar torres y discos, utilizaba un tablero vertical y fichas de colores. También, el número de “columnas” era superior y el número de fichas de las que disponía, no era limitado. Esta fase de estudio fue expuesta en el primer viernes computacional, en la que participé activamente y pude contrastar lo propuesto, con los doctores. Seguidamente, vino la fase de instalación de las herramientas. Antes de empezar el proyecto no había tenido contacto con tecnologías de aplicaciones para dispositivos móviles. El Framework “React Native”, fue el primer paso en este mundo, y con el lenguaje de programación en el que está basado, JavaScript. Por ello, al inicio, busqué documentación oficial, foros, estudié tutoriales y entendí cómo era la arquitectura del Framework. Tras esta inmersión en la tecnología, participé de forma pasiva durante la creación de las primeras pantallas que se presentan en nuestra aplicación. Aportando ideas, investigando cómo poder representar ciertas características y probando algunos componentes que pudieran resultar de ayuda. Como se acordó, fui el encargado de adaptar el Test de Localización. Partiendo de la descripción propuesta por el neuropsicólogo, estudié cómo poder implementar este test de la mejor forma. En un principio, existieron varios requisitos que abordar. El primero era cómo llevar este test a la temática de la APP (supermercado), puesto que la descripción inicial, eran dos cuadrados. Uno superior con números dispuestos aleatoriamente y otro inferior con un punto que representa la posición de un número concreto, de los del cuadrado de arriba. Tras la validación del neuropsicólogo, encontré una solución que fue la definitiva: los cuadrados se convertirían en “carritos de la 3.4. PLANIFICACIÓN DEL PROYECTO 57 compra” y los números, en piezas de fruta. Llegado a este punto, la parte visual estaba cubierta. Faltaba, entonces, implementar la parte interna en la que se iban a recoger las acciones del usuario, como contabilizar un fallo o un acierto. Para implementar esto, busqué la mejor forma que me ofrecía JavaScript para recoger la información y opté por dividir la pantalla en cinco celdas. Cada celda era un área invisible táctil que recogía la información de la pulsación del usuario. Todo ello, para situar el área de acierto, exactamente, sobre la fruta que era la correcta y descartar las áreas colindantes. Esto hacía el código reutilizable y que sólo hubiera que modificar los tamaños de las áreas en función de dónde se encontrará la fruta a elegir. Una vez el test cumplía los requisitos, se acordó que tendría dos pantallas demo con ejemplos, diez pantallas de evaluación y la puntuación se recogería como aciertos o fallos. Otro de los test que realicé fue el de Fluencia de Diseño. Este test, también descrito por el neuropsicólogo, constaba de la realización de diseños únicos uniendo cinco puntos con líneas. Se sustituirían los puntos por fresas, pero las líneas se mantendrían. Una vez definido visualmente, la forma de aplicarlo fue la siguiente: las líneas de unión, serían implementadas como botones, que al pulsarlos pintarían una línea, entre las dos fresas más cercanas entre sí. Si se pulsaba de nuevo, la línea desaparecía. Respecto a la puntuación, se definió que el usuario pudiera crear un máximo de quince diseños (únicos o no), y que como máximo, se dispusiera de un minuto. Para esto último tuve que añadir un temporizador. En este test se utilizó una única pantalla que se iba modificando en función de las acciones del paciente. Cuando este finalizaba un diseño, se pulsaba un botón en la parte inferior que decía: “Siguiente”. En este momento se almacenaba la información del diseño realizado y se limpiaba la pantalla. La demo disponía de tres ejemplos, en los que se le informa al paciente cómo se deben realizar los diseños. También se le advertía si repetía alguno. Ello supone el análisis de los diseños y la comparación entre sí. Una vez terminada la prueba se envía una lista con todos los diseños, de donde se extrae la información sobre: diseños únicos, repetidos y porcentaje de acierto. Respecto a los errores relativos al diseño, las dos pruebas que implementé, eran test en los cuales la interacción a interpretar, por parte del usuario con el smartphone, era la posición de la pulsación y también, esta posición respecto de lo que se representaba en la pantalla. Era muy importante que los diferentes tamaños de pantalla no afectasen a la representación visual de los elementos, ni a la posición relativa tocada por el paciente. Esto me obligó a probarlo en diferentes pantallas. Las cuales mostraban las imágenes de forma desestructurada y hubo que refactorizar los estilos de los componentes visuales, para que usaran porcentajes relativos a la pantalla y no a píxeles. Otra resolución de bugs que tuvieron que ver más con toda la aplicación en sí, fueron: el control de fugas de memoria y el mal uso de temporizadores. Así como, errores relativos al traspaso de información entre pantallas. Por último, en la fase proactiva del control de errores que pudiera realizar el paciente, investigué e implementé la forma en la que los pacientes no pudieran ir hacia atrás, en mitad de una prueba; evitar que la aplicación se pusiera en modo apaisado, y finalmente, las alertas por exceso de tiempo sin actividad. Ya que era el único alumno que disponía de un equipo Mac, fui el encargado de realizar la versión de la aplicación en el sistema operativo iOS. Una de las ventajas de usar React Native es que 64 CAPÍTULO 4. TEST Y EVALUACIÓN DE USABILIDAD Pregunta 2: De la siguiente gráfica referente a la pregunta número 2, podemos concluir que las demostraciones presentes al comienzo de cada uno de los test sirven de ayuda a los usuarios de la APP, para luego poder realizarlos correctamente. Figura 4.2: Pregunta 2 del test de usabilidad. Pregunta 3: La gráfica correspondiente a la tercera pregunta nos informa de que las explicaciones de los test de la APP son lo suficientemente claras para los usuarios. Figura 4.3: Pregunta 3 del test de usabilidad. Pregunta 4: La respuesta a la pregunta número 4 nos indica que para la mayoría de usuarios que han probado la APP la prueba más difícil de realizar ha sido el Test de Memoria. 4.2. EVALUACIÓN DE LA USABILIDAD 65 Figura 4.4: Pregunta 4 del test de usabilidad. 2. Este siguiente bloque formado por las cuestiones 5 y 6, evalúan cómo era el entorno en el que se encontraba el paciente cuando realizó la prueba. Estas preguntas las consideramos de suma relevancia debido a que, si el usuario contaba con algún tipo de distracción en el momento de hacer la prueba, esto podría influir en que percibiese alguna parte de la ejecución con dificultad y que no se debiese en concreto por la funcionalidad y diseño de la APP. Preguntas 5 y 6: Las respuestas correspondientes a las preguntas 5 y 6 del test de usabilidad sirven de ayuda a la hora de analizar las respuestas de los test realizados por cada uno de los usuarios en la BBDD, ya que en este caso, al no haber tenido ningún tipo de distracción no deberían existir gran número de fallos en cada uno de los test. Figura 4.5: Pregunta 5 del test de usabilidad. 66 CAPÍTULO 4. TEST Y EVALUACIÓN DE USABILIDAD Figura 4.6: Pregunta 6 del test de usabilidad. 3. El tercer bloque formado solo por la pregunta 7, está indicado para evaluar si el tiempo que damos a cada una de las pruebas es suficiente para el usuario. Pregunta 7: Cada uno de los usuarios han respondido que el tiempo dado para cada una de las pruebas es el adecuado. Figura 4.7: Pregunta 7 del test de usabilidad. 4. El último bloque de preguntas se centra en evaluar la satisfacción general del paciente con respecto a nuestra aplicación, dándole la opción de añadir algún tipo de comentario y obtener aspectos concretos que podamos valorar y mejorar en un futuro. 4.2. EVALUACIÓN DE LA USABILIDAD 67 Pregunta 8: La satisfacción de los usuarios con la APP es bastante favorable. Figura 4.8: Pregunta 8 del test de usabilidad. Pregunta 9: Finalmente en el test de usabilidad añadimos una pregunta en la que los usuarios podían aportar la opinión que considerasen sobre la APP. De esta pregunta obtuvimos una única valoración, en la cual, tres de los usuarios coincidían y consideraban que el tiempo de espera en cada una de las pantallas correspondientes al Test de Denominación del Lenguaje era demasiado. A lo que propusieron o añadir un botón que permitiese avanzar o bien disminuir dicho tiempo de espera. Aunque esta valoración se recoge con la intención de mejorar aspectos a futuro, en concreto, este tiempo está estipulado a 20 segundos por criterio médico; puesto que la APP está principalmente dirigida a personas con enfermedades neurodegenerativas, este tiempo podría resultar más adecuado para ellas. Figura 4.9: Pregunta 9 del test de usabilidad. Finalmente, tras realizar el proceso completo de validación observamos una correcta aceptación de la herramienta por parte de todos los usuarios, incluido el neuropsicólogo que ha estado presente durante la administración de los test. Capítulo 5 Conclusiones La principal conclusión obtenida tras el estudio llevado a cabo a lo largo de este Trabajo de Fin de Grado es que hemos cumplido con el primer objetivo marcado al inicio del proyecto. Siendo este el desarrollo e implementación de una aplicación de autoadministración de test cognitivos para dispositivos móviles. Aunque esta no es la versión final, se ha conseguido realizar el despliegue de una versión funcional en varios dispositivos móviles Android e iOS. Por otro lado, observamos que la lógica final aplicada permite la recopilación y procesamiento de las respuestas de los usuarios a cada uno de los test, proporcionando así una estructura de tipo almacén de datos, que deja todos los resultados del paciente de forma estructurada y filtrada. Además, estos resultados se han procesado con el propósito concreto de facilitar al especialista el número de aciertos y fallos obtenidos en cada una de las pruebas. Finalmente, gracias a la colaboración de Alfonso Delgado, neuropsicólogo del Hospital Clínico San Carlos, se han podido realizar las evaluaciones de validación necesarias para realizar un análisis sobre la usabilidad de nuestra aplicación. Del estudio posterior de estos resultados podemos concluir que nuestra aplicación cumple con los principales objetivos propios de cualquier producto software, que es, ser fácil de usar e intuitiva, además de que la satisfacción general de los usuarios ha sido claramente positiva. 68 Capítulo 6 Planificación a futuro Tras todos los resultados obtenidos con el desarrollo de la APP y las conclusiones mencionadas en el apartado anterior, cabe indicar que todavía queda parte de desarrollo a continuar para ir complementando y perfeccionado esta aplicación. De esta forma podríamos obtener una herramienta de autoadministración de test cognitivos que se pueda implantar dentro de departamentos de neurología y pudiera ser utilizado por recomendación de especialistas para el uso en casa por parte de los usuarios. Como hemos mencionado en la sección 4 de esta memoria, desarrollamos una técnica de evaluación a través del diseño de un test de usabilidad. Este test nos sirvió para comprender los aspectos de la APP que debemos mejorar para facilitar la interacción entre la interfaz de usuario y el futuro paciente. Estos aspectos para mejorar que hemos obtenido como resultado de una primera tanda de evaluación de usuarios, deberán ser los primeros en modificarse y adaptarse para seguir desarrollando la APP de cara a una nueva versión. En segundo lugar, y una vez realizados las modificaciones oportunas, deberíamos ampliar el tamaño muestral de usuarios para evaluar la APP y realizar un análisis estadístico de los resultados obtenidos. Este estudio debería realizarse en población sana (como hemos hecho primero, evaluando a los acompañantes de pacientes que acuden al departamento de neurología) para ayudar a la normalización de los datos. Como hemos explicado en esta memoria, en cada respuesta de cada test se evalúa al usuario con acierto o fallo, y nos quedamos con el total de éstos al final de que se realicen todos los test. Normalizar, implica que debemos analizar cual es la puntuación media obtenida por parte de todos los usuarios evaluados para luego poder interpretar a partir de esos resultados cuáles serían los obtenidos por una persona con alguna enfermedad neurodegenerativa presente. Este análisis no solo implicaría analizar los resultados de los test si no también analizar las respuestas a las preguntas generales y de orientación que se realizaron previamente al inicio de los test. Una vez realizada esta fase de estudio se podría aplicar esta misma evaluación a otro tipo de población como son los usuarios con enfermedad neurodegenerativa ya diagnosticada. Con estos resultados se podrían comparar los obtenidos previamente en la fase anterior. 69 70 CAPÍTULO 6. PLANIFICACIÓN A FUTURO Para dar otro paso más adelante se podría adaptar algún otro tipo de test cognitivo que mida otro tipo de funcionalidad, incluyendo técnicas de reconocimiento de voz y estímulos auditivos, para intentar realizar una evaluación cognitiva más completa al paciente. De esta manera se podría ir adaptando en medida de las necesidades que vayan surgiendo, cambios o adaptaciones de otros posibles test que se realizan de manera presencial y supervisada a través de la aplicación. Por último, podríamos implementar y reconfigurar el diseño de alguno de nuestros test como es el de localización de punto o el test de fluencia de diseño, para adaptarlo a dispositivos tablets. Actualmente nuestra aplicación está configurada para dispositivos smartphone, pues estos dispositivos son los más habituales y de los que en mayor probabilidad dispone una persona. Pero para aquellas personas que dispongan además de este tipo de dispositivo o tableta (o bien dispongan sólo de este tipo), implementar una versión adaptando ciertos parámetros de configuración que permitan el uso en tablets facilitará la posibilidad de realizar los test a través de nuestra aplicación y ampliará aún más el número de personas con posibilidad de realizarlas desde su propio dispositivo. Apéndice A Introduction The increase in human life expectancy, combined with demographic growth, has led to the emergence of a greater number of cases of neurodegenerative diseases. Among other things, this increase has led to a delay in obtaining a diagnosis due to a lack of medical care. Therefore, the intention of this work is to help, as far as possible, to mitigate this problem. A.1. Neurodegenerative diseases Neurodegenerative diseases form an extensive part in the field of medicine, specifically in the field of neurology. Moreover, they are commonly characterised as diseases of unknown origin, with progressive development of their symptoms, which, in turn, show the gradual disintegration of one or more parts of the human being’s nervous system. In addition to these characteristics, there is also a decrease in functionality and personal independence. People suffering from one of these diseases require full and continuous care, which justifies the need for patients to be treated in specific units. [1] These diseases can be classified depending on the clinical manifestations that the patient presents; amongs them we can differentiate those that mainly show a dementia syndrome, such as Alzheimer’s; Those that are exposed with movement and posture disorders, in the case of Parkinson’s; those that present progressive ataxia, i.e. lack of muscle control or coordination of voluntary movements, such as eating, in the case of Cerebellar Ataxia; or those that show muscle weakness and atrophy, for example Amyotrophic Lateral Sclerosis; and many other diseases with different symptoms. All these neurodegenerative diseases do not have a treatment that acts on the cause that originates it, but rather palliative treatments are applied, that is to say, they do not find a cure. [2] A.2. Why this TFG is proposed The early detection and diagnosis of neurodegenerative diseases, according to different international studies, is currently considered a significant public health problem still unresolved, as they 71 72 APÉNDICE A. INTRODUCTION reflect an average delay of 8 to 32 months, between the appearance of the first symptoms and the diagnosis of the disease itself. An early diagnosis would, among many other things, increase understanding of the problem and provide access to treatment and social support. However, to date, no country has proposed systematic screening of patients suffering from this type of disease in primary care, despite the fact that the percentage of undiagnosed cases is very high. [3] The proposal of this final degree project, in the current context, aims to help with the problems described, that is, to allow cognitive tests to be carried out not only and exclusively in a medical centre, whether it is a health centre or a hospital. This would also provide a solution to the current delay in obtaining the diagnosis of the disease, which would also accelerate the pressure of healthcare. A.3. Objectives of this TFG The main objective of this Final Degree Project is the implementation and development of a hybrid mobile application, that is to say, available for devices with Android or iOS operating systems, which includes a series of cognitive assessment tests. To this end, this work was done in collaboration with the Neurology Department of the Hospital Clínico San Carlos, who showed us the different tests they worked with and provided us with their adaptation for mobile devices. Thus, the answers of each of the tests performed on the patients are stored; and, in turn, scores are obtained from them, which will later be studied by these specialists. These scores will provide the neurologist with an estimate when making the patient’s diagnosis. Likewise, another objective of this application is to allow the self-administration of the tests to the patients in a comfortable and simple way. On the other hand, it is worth noting the challenge involved in carrying out a group software project from the outset, as this involved detailed planning of all its phases, from the study to its implementation and testing. This made it necessary to organise the entire team, plan in detail the time and resources available and put into practice the knowledge acquired throughout the years of the course. A.4. Structure of the document This document is structured in a series of chapters, the contents of which are described below: Introduction: describes the problem explained in the previous section, as well as the main objective for which this work is carried out. State of art: contains a detailed description of the research and publications carried out in the field of our work, i.e. within the field of neurocognitive diseases and the tools currently used for carrying out cognitive tests. A.4. STRUCTURE OF THE DOCUMENT 73 Methodology: describes the final result of the application. At the same time, the technologies and tools used for the development of our application are explained in detail, as well as the steps and organisation of the team when carrying out the work. Usability test and evaluation: presents a usability form completed by users after using the APP. As well as a compilation of the different responses obtained. Conclusions and future lines: this chapter presents the conclusions of the work carried out, as well as the possible improvements that could be made to the application after it has been presented. Agradecimientos Primeramente, agradecer a cada una de nuestras familias, en especial a nuestros padres y hermanos, por confiar y creer en nosotros, no sólo en nuestros años de carrera universitaria, sino en cada uno de nuestros pasos en la vida. Gracias a nuestros amigos por apoyarnos y darnos fuerzas para continuar cuando se presentaban dificultades en nuestro camino. Agradecer también a todas aquellas personas con las que hemos trabajado durante los años de nuestra carrera, tanto compañeros como los diferentes docentes que hemos tenido a lo largo de estos años. En especial, agradecer al tutor de este proyecto José Luis Ayala Rodrigo, que nos ha orientado y ayudado en todo momento desde los inicios de este trabajo, mostrándose disponible siempre que ha podido y lo hemos requerido. Atendiendo a cada una de nuestras necesidades y problemas, aportándonos posibles soluciones para que este trabajo se realice con éxito. Por último agradecer a Vanesa Pytel Córdoba y Jordi Matías-Guiu Antem, neurólogos y a Alfonso Delgado Álverez, neuropsicólogo del Hospital Clínico San Carlos, que también nos han ayudado en la realización de este trabajo, aclarándonos cualquier duda y mostrando interés por la fase de desarrollo del mismo. 80