Desarrollo de aplicación para recogida de datos en estudio clínico

Universidad Complutense de Madrid Facultad de Informática Desarrollo de aplicación para recogida de datos en estudio clínico Autor Ernesto Vivar Laviña Directores de proyecto José Luis Ayala Rodrigo Josué Pagán Ortiz Trabajo de Fin de Grado Grado en Ingeniería de Software Junio de 2020 2 Agradecimientos Lo primero dar las gracias a José y a Josué por su dedicación e implicación en este trabajo. Gracias de todo corazón por estar ahí durante todo el desarrollo del TFG, con reuniones, con los correos que algunos llegaban a alcanzar proporciones bíblicas y las respuestas a correos enviados a altas horas de la madrugada. Espero que este proyecto pueda seguir creciendo en un futuro y ayudar a todas las personas posibles, ya que una de las razones principales por las que elegí este TFG fue su fin social. Gracias a mis padres, Rosa y Rafael, y a mi hermano Pau, por darme desde que era un niño todo su apoyo y cariño a lo largo de mi vida, aceptar mis decisiones y acompañarme en ellas. Porque aunque nos peleemos y nos tiremos los trastos a la cabeza os quiero muchísimo. Gracias por estar siempre ahí y en serio, sois la mejor familia que puede uno tener. También agradecer a mi primo Alex por su positividad, alegría y cariño, ya que gracias a el descubrí el mundo de la informática y la programación. Gracias por haberme metido el gusanillo por este mundo, siempre seras mi primo fav. Gracias a toda mi familia, por estar siempre ahí, en lo bueno y en lo malo, y porque se que pase lo que pase tendré a mi familia a mi lado siempre. Muchas gracias. Tambien agradecer al equipo de AnyChart 1por habernos ofrecido una licencia para poder emplear su biblioteca de gráficas en el proyecto. 1Página oficial de AnyChart https://www.anychart.com/es/ Accedido: 26/06/2020 3 4Agradecimientos Resumen Resumen en Español Las cefaleas en racimo o cefaleas de Horton son un tipo de cefaleas primarias caracterizadas por su dolor extremadamente intenso y repetitivo que puede presentarse en episodios de duración variable de entre 15 minutos y más de 3 horas que pueden repetirse hasta 10 veces en un mismo día. Este tipo de cefaleas son una patología que afecta a 1 de cada 1.000 personas siendo mas común en hombres que en mujeres. Actualmente los mecanismos y las causas concretas que desencadenan los brotes de estas cefaleas no son del todo conocidos. Por otro lado se tiene conocimiento de que ciertos tratamientos como Sumatriptán y Zolmitriptán o la inhalación de oxígeno son tratamientos bastante útiles para paliar el dolor de los brotes. El objetivo principal de este Trabajo de Fin de Grado es comprobar si existe una relación entre las variaciones de ciertos valores atmosféricos y de polución, tales como la presión atmosférica o la humedad, y los episodios de dolor. Se tiene la hipótesis de que en el periodo previo al inicio de un episodio podrían producirse cambios en las variables ambientales que resulten en cambios fisiológicos del paciente dando lugar al episodio de dolor. Así mismo el estudio contempla el seguimiento de los hábitos de vida de los pacientes con el fin de hallar posibles desencadenantes del dolor. Los principales problemas de un estudio clínico como este son por un lado el recopilar información valiosa de los pacientes que padecen esta patología y el posterior manejo y estudio de dichos datos. Para recopilar datos que sean estudiados se ha desarrollado una aplicación nativa para dispositivos móviles con el SO de Google Android. Dicha aplicación permite al paciente introducir los datos de manera sencilla y con una interfaz amigable, por otro lado, la aplicación también permite a los médicos que forman parte del estudio clínico visualizar de manera rápida y sencilla los datos introducido por los pacientes de manera rápida y sin la necesidad de concertar una cita presencial. Gracias a esta aplicación se desea poder llevar a cabo un estudio clínico de manera que tanto el paciente como el médico cuenten con una forma sencilla, amigable y online de proporcionar distintos datos y llevar un seguimiento de estos datos dentro del marco del estudio clínico para poder comprobar si hay algún factor atmosférico que desencadene los brotes o racimos de este tipo de cefaleas. 5 6Resumen Summary in English Cluster headaches or Horton’s headaches are a type of primary headache characterized by extremely intense, repetitive pain that may occur in episodes of varying duration from 15 minutes to more than 3 hours and may repeat up to 10 times a day. This type of headache is a pathology that affects 1 out of every 1,000 people and is more common in men than in women. Currently the mechanisms and specific causes that trigger these headaches are not completely known. On the other hand, it is known that certain treatments such as Sumatriptan and Zolmitriptan or the inhalation of oxygen are quite useful treatments to palliate the pain of clusters. The main objective of this End-of-Grade Work is to check whether there is a relationship between variations in certain atmospheric and pollution values, such as atmospheric pressure or humidity, and the episodes of pain. It is hypothesized that in the period prior to the onset of an episode there could be changes in environmental variables that result in physiological changes in the patient leading to the pain episode. The study also includes the monitoring of patients’lifestyle habits in order to find possible pain triggers. The main problems of a clinical study such as this one are, on the one hand, the collection of valuable information from patients suffering from this pathology and the subsequent handling and study of such data. In order to collect data to be studied, a native application for mobile devices with Google Android OS has been developed. This application allows the patient to enter the data in a simple way and with a friendly interface. On the other hand, the application also allows the doctors who are part of the clinical study to visualize the data entered by the patients in a quick and easy way and without the need to make an appointment in person. Thanks to this application, we want to be able to carry out a clinical study so that both the patient and the doctor have a simple, user-friendly, online way of providing different data and keeping track of these data within the framework of the clinical study in order to check whether there is any atmospheric factor that triggers outbreaks or clusters of this type of headache. Índice general Agradecimientos 3 Resumen 5 Lista de figuras 9 Lista de tablas 11 Acrónimos 13 Palabras clave 15 1. Introducción 17 1.1. Objetivos ...................................... 18 2. Estado del arte 19 2.1. Cefaleasymigrañas................................. 19 2.2. Cefaleasenracimo ................................. 19 2.2.1. Factoresderiesgo ............................. 20 2.3. Métodos de registro de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.4. Aplicaciones móviles actuales . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.4.1. Aplicaciones para dispositivos Android . . . . . . . . . . . . . . . . . . 22 2.4.2. Aplicaciones para dispositivos iOS . . . . . . . . . . . . . . . . . . . . . 23 3. Metodología 25 3.1. Patronesdediseño ................................. 25 3.1.1. PatrónSingleton .............................. 25 3.1.2. PatrónDAO................................. 26 3.1.3. Patrón Repositorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2. Arquitecturaglobal................................. 27 3.3. Arquitectura de la aplicación Android . . . . . . . . . . . . . . . . . . . . . . . 29 3.4. Casosdeuso .................................... 30 3.4.1. Casos de uso del paciente . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.4.2. Casos de uso del médico . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7 8ÍNDICE GENERAL 3.4.3. Casos de usos compartidos . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.5. BasesdeDatos ................................... 37 3.5.1. Basededatosremota............................ 37 3.5.2. Basededatoslocal............................. 39 3.6. Promedioponderado ................................ 40 4. Implementación 43 4.1. Introducción .................................... 43 4.2. Back-end oladodelservidor ............................ 43 4.2.1. Basesdedatos ............................... 43 4.2.2. Slim Framework y Retrofit2: API de CharmApp . . . . . . . . . . . . . 45 4.3. Front-end oladodelcliente............................. 47 4.3.1. Android Studio: Java y XML . . . . . . . . . . . . . . . . . . . . . . . . 47 5. Resultados 51 5.1. Flujo de uso de la aplicación CharmApp para el rol del paciente . . . . . . . . . 51 5.1.1. Login.................................... 51 5.1.2. Tutorial................................... 51 5.1.3. Inicio .................................... 51 5.1.4. Guardardiario ............................... 53 5.1.5. Crear y cerrar una crisis . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.1.6. Consultar el calendario . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.1.7. Consultar el diario y la crisis para un día concreto . . . . . . . . . . . . . 56 5.1.8. Consultar las gráficas de temperatura, presión y humedad . . . . . . . . . 56 5.2. Flujo de uso de la aplicación CharmApp para el rol del médico . . . . . . . . . . 56 5.2.1. Login.................................... 58 5.2.2. Listadepacientes.............................. 58 5.2.3. Ver diarios y crisis de los pacientes . . . . . . . . . . . . . . . . . . . . 58 5.3. Evaluación de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6. Conclusiones y líneas futuras 63 6.1. Conclusiones .................................... 63 6.2. Líneasfuturas.................................... 64 Bibliografía 65 A. Diagramas de flujo 67 Autorización de difusión 83 Índice de figuras 2.1. Ejemplo de formulario online para recogida de datos . . . . . . . . . . . . . . . 21 2.2. Ejemplo de formulario físico para recogida de datos . . . . . . . . . . . . . . . . 21 2.3. Resultados para la búsqueda en marketeplace Google Play Store . . . . . . . . . 22 2.4. Capturas de pantalla de la aplicación Mi cefalea en racimos . . . . . . . . . . . . 22 2.5. Resultados para la búsqueda en marketeplace AppStore.............. 23 3.1. Diagrama de la arquitectura de Retrofit2 . . . . . . . . . . . . . . . . . . . . . . 27 3.2. Diagrama de clase de los patrones DAO y Repositorio . . . . . . . . . . . . . . . 28 3.3. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.4. Esquema basado en el original de Clean Architecture de Robert C. Martin . . . . 29 3.5. Diagramadecasosdeuso.............................. 30 3.6. Diagrama entidad-relación para la BBDD “charmapp” . . . . . . . . . . . . . . 38 3.7. Diagrama entidad-relación para la BBDD “charmapp_environment” . . . . . . . 39 3.8. TablasdelaBBDDlocal .............................. 40 3.9. Ejemplo del cálculo del promedio ponderado de la temperatura . . . . . . . . . . 41 4.1. Tecnologías usadas en el proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.2. Captura de pantalla de Android Debug Database . . . . . . . . . . . . . . . . . . 45 4.3. LogotipodeMariaDB................................ 45 4.4. Logotipo de AWS EC2 Instance . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.5. Logotipos de Slim Framework y Retrofit . . . . . . . . . . . . . . . . . . . . . . 46 4.6. Logotipo de AWS Elastic Beanstalk Instance . . . . . . . . . . . . . . . . . . . 46 4.7. Logotipos de Android Studio, Java y XML, tecnologías usadas para el Front-end 47 5.1. Pantalladelogin .................................. 52 5.2. Pantalla de inicio del tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.3. Pantalla de inicio para el paciente . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.4. Menú lateral de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.5. Pantalla con el formulario del diario . . . . . . . . . . . . . . . . . . . . . . . . 55 5.6. Pantalla con el formulario de las crisis . . . . . . . . . . . . . . . . . . . . . . . 55 5.7. Pantalla con el calendario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.8. Pantalla para editar diarios y/o crisis . . . . . . . . . . . . . . . . . . . . . . . . 57 5.9. Pantalla con las gráficas de temperatura y presión atmosféricas . . . . . . . . . . 57 9 16 Palabras clave Capítulo 1 Introducción Durante los últimos años y gracias a la aparición de los teléfonos inteligentes y otros dispositivos móviles ha propiciado la aparición de multitud de aplicaciones tanto de redes sociales, entretenimiento, juegos, musica y aplicaciones médicas. Gracias a las aplicaciones médicas se ha facilitado en gran medida tanto el control de multitud de patologías como el estudio de estas. Algunas de estas aplicaciones son: Medscapes: Aplicación que permite calcular dosis de medicamentos así como información de estos, casos clínicos, etc. Prognosis: Aplicación con numerosos casos médicos con estudios de casos reales, discusiones sobre los casos, entre otros. Dermomedia: Aplicación para detectar mas de 100 patologías cutáneas gracias a distintos estudios a través de contenido visual e interactivo Debido a esta evolución en las tecnologías y aplicaciones móviles nacen aplicaciones para el control y registro de enfermedades, así como para obtener datos y estudiarlos con el fin de facilitar el diagnostico de patologías, el tratamiento de estas o los factores que están relacionados con una enfermedad. De todo esto nace la idea de este TFG, CharmApp, una aplicación móvil para el control y registro de datos de pacientes que sufren de cefaleas en racimo, así como el control por parte del médico y con el fin de comprobar si los ataques de cefaleas en racimo pueden ser predichas basado en el estudio de todos los datos recogidos de los pacientes que usen la aplicación. Este tipo de patología, las cefaleas en racimo, es una de las cefaleas más raras y de las que se sabe relativamente poco en comparación con el resto de enfermedades de la familia de las cefaleas y migrañas. La mayoría de conclusiones que se tienen sobre la enfermedad son solamente hipótesis y teorías. Con el estudio que existe detrás de la aplicación y conjuntamente el equipo de médico de Neurología del Hospital Universitario Rey Juan Carlos de Móstoles, se busca el probar o rebatir estas hipótesis que existen sobre las cefaleas en racimo. Posteriormente, en el capítulo 2, el estado del arte, se explicará con más detalle las causas y efectos de las cefaleas en racimo, así como sus factores de riesgo. 17 18 CAPÍTULO 1. INTRODUCCIÓN 1.1. Objetivos El objetivo de este TFG es la implementación de una aplicación móvil para recoger datos sobre los pacientes de cefaleas en racimo, con el fin de obtener datos suficientes para, posteriormente, determinar si los brotes de la enfermedad pueden ser predichos. Para ello, se ha desarrollado una aplicación que cuenta con distintos formularios: Formulario de diario: Se rellena cada día por el paciente con el fin de saber como ese encuentra Formulario de crisis: Se rellena cada vez que se inicia y finaliza una crisis o brote, con las características de la crisis como el nivel de dolor, el tipo de dolor o factores externos como tabaco o alcohol Además se ha implementado un servicio de localización del dispositivo con dos fines: Recoger las localizaciones del paciente de forma periódica para obtener y calcular datos atmosféricos y de polución para ser estudiados Mostrar datos al paciente a través de la aplicación tanto a modo de resumen, como en un apartado con distintas gráficas para distintas medidas de presión atmosférica o temperatura, entre otros. En los siguientes capítulos se explica el estado del arte en el que se ha basado el estudio y desarrollo del trabajo así como la metodología del diseño y su implementación. Para finalizar se presentan y analizan los resultados obtenidos con este trabajo así como sus conclusiones. Capítulo 2 Estado del arte 2.1. Cefaleas y migrañas Las cefaleas son uno de los trastornos más comunes del sistema nervioso. Son trastornos primarios dolorosos e incapacitantes que pueden ser causadas por otros factores como el consumo excesivo de analgésicos1. La cefalea es la alteración principal, de la cual surge una clasificación entre la que se encuentran trastornos como la cefalea tensional, la migraña o jaqueca, o la cefalea en racimos. Por lo tanto, la migraña se define como un tipo de cefalea que se manifiesta por su presentación pulsátil (latidos) e intensidad moderada-severa, iniciado generalmente de forma unilateral [1]. Las cefaleas y migrañas han sido subestimadas, se conocen mal y los pacientes no reciben, en muchas ocasiones, el diagnóstico y tratamiento adecuados. Pero esté problema está aun más presente en un tipo concreto de cefaleas, las cefaleas en racimos. 2.2. Cefaleas en racimo Las cefaleas en racimos, también conocidas como cefalea en brotes es una patología poco frecuente, pues afecta a 1 de cada 1.000 personas, y siendo 7 veces más frecuente en hombres que en mujeres según la AEMICE.2En 2019, se calculó que en España alrededor de 47.000 personas estaban diagnosticadas con cefaleas en racimos. Entre los distintos síntomas de la enfermedad destacan, entre otros: Dolor: El cual es extremadamente intenso y repetitivo, apareciendo, la mayoría de las veces, en unas condiciones similares. Puede durar entre unos minutos hasta varios días. Caída del párpado Fotofobia o intolerancia a la luz Fonofobia o fobia a los ruidos fuertes 1Web de la OMS. Accedido: 28/05/2020 https://www.who.int/es/news-room/fact-sheets/ detail/headache-disorders 2Web de la AEMICE. Accedido: 28/05/2020 https://www.dolordecabeza.net/dolor-de-cabeza/ cefalea-en-racimos/ 19 20 CAPÍTULO 2. ESTADO DEL ARTE Puesto que es una patología poco frecuente y muy dinámica al presentar periodos tanto sintomáticos como asintomáticos, su diagnostico es bastante precario, pudiendo demorarse hasta 5 años, haciendo que en el 20% de los casos la cefalea en racimos se cronifica, es decir, dicha patología pasa estar presente en el paciente durante toda su vida3. Afortunadamente, y gracias al trabajo de investigadores y neurólogos, cada vez se van teniendo más datos sobre cómo afecta la enfermedad y cómo tratarla. Aunque desgraciadamente no existe un método que permita a los doctores saber si las crisis pueden predecirse, para así reducir los síntomas. Además, estas cefaleas se caracterizan también por presentar dos periodos en pacientes: Periodo sintomático: Durante el que se suceden uno o varios ataques Periodo asintomático o de remisión: Periodo de duración entre meses o años, que se sucede al periodo sintomático del paciente Pese a que la cefalea en racimos se encuentra dentro del mismo grupo que el resto de cefaleas y migrañas, sus causas no están del todo claras, pero la teoría más aceptada es que el hipotálamo podría ser el generador de estas cefaleas en racimo, ya que durante los ataques se activa la región posterior de la materia gris del hipotálamo [2]. Aunque tenga similitudes con otros tipos de cefaleas o migrañas, su tratamiento puede ser distinto entre unos pacientes y otros. Uno de los tratamientos mas utilizados es la inhalación de oxígeno 100% puro o inhalación de fármacos como Sumatriptan o Zolmitriptan. Pero todos estos tratamientos sirven solamente para paliar los dolores de las cefaleas, no para curar la enfermedad. 2.2.1. Factores de riesgo Puesto que este tipo de cefaleas son bastante desconocidas, en relación con otros tipos, los factores de riesgo que desencadenan los brotes o racimos no se tienen del todo claro, sin embargo se tienen varias hipótesis distintas respecto a los factores que pueden desencadenar un brote. Consumo de alcohol y/o tabaco Cambios de presión atmosféricas como viajar en avión Cambios de temperatura Medicamentos como analgésicos o vasodilatadores Algunos factores como la exposición al calor, cambios de temperaturas o la ingesta de alcohol [3], han sido observados en varios estudios clínicos como posibles desencadenantes de ataques de cefaleas. A pesar de que cerca del 85% de pacientes con cefaleas en racimo son fumadores, no se ha comprobado que el dejar de fumar se relacione con una remisión de la enfermedad, como estudió G.C. Manzoni en un estudio con 374 pacientes de género masculino [4]. Aunque lo interesante de la ingesta de alcohol es que si el paciente está en periodo de remisión, periodo posterior a un ataque de una duración de entre 6 meses y 2 años, el alcohol raramente desencadena un ataque como se explica en un seminario de neurología [5]. 3Web de GNDiario. Accedido: 15/05/2020 https://www.gndiario.com/cefalea-racimos 2.3. MÉTODOS DE REGISTRO DE DATOS 21 2.3. Métodos actuales para el control y registro de datos de pacientes con cefaleas en racimo Actualmente el método más común en el cual se incluyen a pacientes y médicos para las cefaleas en racimo constan de formularios, ya sean online, como el que se presenta en la figura 2.1, o físicos como el de figura 2.2. Figura 2.1: Ejemplo de formulario online para recogida de datos usado por el equipo de investigación en el que se desarrolla este proyecto Figura 2.2: Ejemplo de formulario físico imprimible para recogida de datos usado por el equipo de investigación en el que se desarrolla este proyecto Debido a que previamente estudios han intentado encontrar relación entre los ataques y su frecuencia con variables atmosféricas como la temperatura o la humedad relativa. Lo malo de estos métodos es que no han tenido en cuenta todas las variables atmosféricas, y desde el Hospital Rey Juan Carlos de Madrid creen que es importante tener en cuenta la relación con la variación de presión atmosférica. Partiendo de esto, se quieren mejorar los métodos actuales que ya existen aprovechando las nuevas tecnologías para crear una aplicación móvil que sirva para obtener los datos necesarios del paciente con el fin de contrastar la hipótesis de que la presión atmosférica puede ser un factor fundamental en la patología. 2.4. Aplicaciones móviles actuales Gracias a las nuevas tecnologías han ido apareciendo un número considerable de aplicaciones para dispositivos móviles enfocadas a los trastornos neuronales, en el caso de las cefaleas como la migraña encontramos múltiples. A continuación se exploran, distinguiendo el sistema operativo 22 CAPÍTULO 2. ESTADO DEL ARTE que posea el dispositivo móvil, varias aplicaciones enfocadas a la patología que nos interesa, la cefalea en racimos. 2.4.1. Aplicaciones para dispositivos Android Si somos usuarios de un dispositivo con el SO Android, podemos acceder a varios marketplace de aplicaciones como Aptoide o APKPure entre otros. Sin embargo, nos centraremos en las aplicaciones que podemos encontrar en el marketplace oficial de Google, Google Play Store. Si realizamos una búsqueda dentro de la aplicación con el texto “Cefalea en racimos” o “Cluster headache” en inglés, obtendremos como resultado una serie de aplicaciones como se observa en la figura 2.3. Figura 2.3: Resultados para la búsqueda en marketeplace Google Play Store La mayoría de estas aplicaciones como Migraine Buddy, Headache Tracker, o Headache Diary son aplicaciones que sirven como diario de seguimiento de todo tipo de patologías relacionadas con migrañas y cefaleas. De entre los resultados que obtenemos cabe destacar Mi cefalea en racimos de Christophe DELAGE. 2.4.1.1. Mi cefalea en racimos de Christophe DELAGE De entre todas las aplicaciones que aparecen entre los resultados la que más destaca, gracias a su título es la de Mi cefalea en racimos que se puede observar en la figura 2.4. Esta aplicación llama primero la atención por su nombre, y si la instalamos en nuestro dispositivo y la utilizamos, nos presenta una serie de utilidades, que pese a su pobre interfaz gráfica, bastante útiles e interesantes para este tipo de cefaleas. Alguna de estas funcionalidades son: Figura 2.4: Capturas de pantalla de la aplicación Mi cefalea en racimos 2.4. APLICACIONES MÓVILES ACTUALES 23 Añadir datos sobre un ataque Gestionar los tratamientos administrados Histórico con los ataques guardados Gráficos con estadísticas de los ataques y tratamientos Sin embargo tiene bastantes limitaciones entre las que están el no tener un estudio clínico con un equipo de profesionales detrás, tampoco almacena datos de manera masiva para poder ser estudiados...Limitaciones que nuestra app CharmApp quiere solventar. 2.4.2. Aplicaciones para dispositivos iOS Si por otra parte, somos usuarios de dispositivos con el SO iOS, podremos acceder al marketplace oficial de Apple, AppStore, dejando de lado otros marketplace no oficiales para iOS como AppCake o vShare. Realizando una búsqueda similar que con un dispositivo Android pero esta vez en la aplicación AppStore con el texto “Cefalea en racimos” o “Cluster headache” en inglés, obtendremos como resultado una serie de aplicaciones. Como observamos en la figura 2.5 con el termino en español “Cefalea en racimos”, no obtendremos ningún resultado, mientras que con el término en inglés “Cluster headache” obtenemos algunos resultados como Migraine Buddy o N1 - Headache. Figura 2.5: Resultados para la búsqueda en marketeplace AppStore Al igual que en el caso de las búsquedas en Android las aplicaciones únicamente sirven como diario de seguimiento de cualquier tipo de patología relacionada con migrañas y cefaleas. Del mismo modo cabe destacar que, al contrario que en el caso de Android, no encontramos ninguna aplicación orientada específicamente a las cefaleas en racimo. Con todo lo visto en las diferentes aplicaciones relacionadas a las migrañas, cefaleas y cefaleas en racimo existentes en los marketplace oficiales de Google Play Store y AppStore para dispositivos Android e iOS respectivamente, CharmApp quiere sobresalir sobre todas éstas con sus características como: Contar con un estudio clínico y profesionales de la neurología que diseñan su funcionalidad Servir tanto de diario para los pacientes como de herramienta de seguimiento a los médicos 24 CAPÍTULO 2. ESTADO DEL ARTE Poder ver variables que podrían influir en el desencadenamiento de una crisis Notificaciones de aviso y recordatorios Servicio de localización con el fin de contar con multitud de datos ambientales de pacientes para poder estudiarlos y analizarlos en su relación con la cefalea en racimos. Capítulo 3 Metodología 3.1. Patrones de diseño En esta sección se explican los patrones de diseño empleados en la aplicación. 3.1.1. Patrón Singleton El patrón singleton se ha empleado en varias partes del desarrollo de la aplicación, ya que permite tener una instancia única en cualquier punto de la aplicación. Una de sus aplicaciones está en el uso de este patrón para realizar las peticiones entre la aplicación y el API a través del uso de Retrofit2. A continuación se puede observar un fragmento de código Java perteneciente al singleton del cliente de Retrofit2 para poder llevar a cabo las peticiones. 1*Clase con la instancia a Retrofit2 para poder hacer las llamadas a la API 2* 3*@author Ernesto Vivar Lavina [email protected] 4*/ 5public class RetrofitClient { 6 7/** 8*URL base para las llamadas a la API 9*/ 10 private static final String BASE_URL = "http://192.168.0.1/appname/ public/"; 11 12 /** 13 *Instancia de la clase RetrofitClient 14 */ 15 private static RetrofitClient instance; 16 17 /** 18 *Objeto Retrofit 19 */ 20 private Retrofit retrofit; 21 22 /** 23 *Constructor por defecto 25 32 CAPÍTULO 3. METODOLOGÍA CU-03 Rellenar crisis Descripción Rellenar el formulario de crisis Actor Paciente Entradas Fecha de inicio de la crisis Fecha de fin de la crisis(opcional) Deporte hecho Alcohol tomado Tabaco fumado Medicación tomada Sensación durante la crisis Nivel de dolor de la crisis Salidas Mensaje toast informando de que se ha guardado correctamente la crisis Precondición Todas las entradas completadas con datos válidos Secuencia Validar los datos introducidos. Si hay algún dato que fallase, mostrar diálogo de error . Si los datos están completos, llamar al API e insertar los datos. Volver a la pantalla principal. Postcondición Crisis rellenada y guardada correctamente correctamente. Diagrama de flujo Diagrama de flujo A.3 en la página 70 Cuadro 3.3: Caso de uso 03: Rellenar crisis CU-04 Consultar historial Descripción Consultar el historial de hasta 30 días atrás de los diarios y crisis Actor Paciente Entradas Fecha a consultar Salidas Crisis y diario para esa fecha Precondición Fecha entre el día actual y hace 30 días Secuencia Comprobar que la fecha es correcta. Llamar al API para obtener el diario y crisis para dicha fecha. Si existe diario, mostrarlo. Si existe crisis, mostrarlo. Si no existiese diario o crisis, mostrar diálogo de error. Postcondición Diario y crisis para la fecha seleccionada. Diagrama de flujo Diagrama de flujo A.4 en la página 71 Cuadro 3.4: Caso de uso 04: Consultar historial 3.4. CASOS DE USO 33 CU-05 Editar diario Descripción Editar un diario del paciente introducido anteriormente Actor Paciente Entradas Datos a modificar del diario Salidas Ninguna Precondición Datos a modificar completados con datos validos Secuencia Comprobar que los datos a modificar son correctos. Llamar al API para guardar las modificaciones. Mostrar el diario actualizado. Postcondición Diario modificado correctamente. Diagrama de flujo Diagrama de flujo A.5 en la página 72 Cuadro 3.5: Caso de uso 05: Editar diario CU-06 Editar crisis Descripción Editar una crisis del paciente introducida anteriormente Actor Paciente Entradas Datos a modificar de la crisis Salidas Ninguna Precondición Datos a modificar completados con datos validos Secuencia Comprobar que los datos a modificar son correctos. Llamar al API para guardar las modificaciones. Mostrar la crisis actualizada. Postcondición Crisis modificada correctamente. Diagrama de flujo Diagrama de flujo A.6 en la página 73 Cuadro 3.6: Caso de uso 06: Editar crisis CU-07 Ver gráficas Descripción Ver gráficas con distintos datos atmosféricos y de polución Actor Paciente Entradas Ninguna Salidas Ninguna Precondición No hay Secuencia Llamar a la base de datos local para leer los datos. Mostrar gráficas con los datos leídos. Postcondición Diagrama de flujo Diagrama de flujo A.7 en la página 74 Cuadro 3.7: Caso de uso 07: Ver gráficas 34 CAPÍTULO 3. METODOLOGÍA CU-08 Solicitar registro Descripción Solicitar registro en el estudio Actor Paciente Entradas Email, nombre, apellidos, teléfono y entidad médica asociada del paciente Salidas Email al equipo de la entidad médica con los datos del paciente Precondición Paciente no incluido en el estudio previamente Secuencia Comprobar que todas las entradas están rellenas y los datos son correctos. Llamar al API para enviar un email al correo electrónico de la entidad médica. Volver a la pantalla de inicio de sesión Postcondición Solicitud de registro enviada correctamente. Diagrama de flujo Diagrama de flujo A.8 en la página 75 Cuadro 3.8: Caso de uso 08: Solicitar registro 3.4. CASOS DE USO 35 3.4.2. Casos de uso del médico En esta subsección se muestran las tablas de casos de uso para el rol del médico. CU-09 Login doctor Descripción Iniciar sesión por parte de un médico Actor Médico Entradas Email y contraseña del usuario Salidas Ninguna Precondición Usuario y contraseña correctos e insertados en la base de datos. Secuencia Llamar al API para validar los datos. Comprobar que el email existe. Si el email existe y la contraseña es correcta, acceder. Si el email existe y la contraseña es incorrecta, mostrar dialogo de error. Si el email no existe, mostrar diálogo de error. Postcondición Médico logeado correctamente Diagrama de flujo Diagrama de flujo A.1 en la página 68 Cuadro 3.9: Caso de uso 09: Login doctor CU-10 Ver todos los pacientes Descripción Ver todos los pacientes asociados a un médico Actor Médico Entradas Id del Médico Salidas Lista de pacientes asociados Precondición Médico logeado en la aplicación Secuencia Llamar al API para comprobar el id del médico. Leer los pacientes asociados al médico. Mostrar la lista de pacientes leídos. Postcondición Pacientes visualizados correctamente. Diagrama de flujo Diagrama de flujo A.9 en la página 76 Cuadro 3.10: Caso de uso 10: Ver todos los pacientes CU-11 Ver crisis Descripción Ver los datos de una crisis de un paciente Actor Médico Entradas Id del paciente y fecha de la crisis a visualizar Salidas Crisis del paciente Precondición Ninguna Secuencia Llamar al API para comprobar el id del paciente y la fecha. Si los datos son correctos mostrar la crisis leída. Si los datos son incorrectos no mostrar nada. Postcondición Crisis leída correctamente. Diagrama de flujo Diagrama de flujo A.10 en la página 77 Cuadro 3.11: Caso de uso 11: Ver crisis 36 CAPÍTULO 3. METODOLOGÍA CU-12 Ver diario Descripción Ver los datos de un diario de un paciente Actor Médico Entradas Id del paciente y fecha del diario a visualizar Salidas Diario del paciente Precondición Ninguna Secuencia Llamar al API para comprobar el id del paciente y la fecha. Si los datos son correctos mostrar el diario leído. Si los datos son incorrectos no mostrar nada. Postcondición Diario leído correctamente. Diagrama de flujo Diagrama de flujo A.11 en la página 78 Cuadro 3.12: Caso de uso 12: Ver diario CU-13 Registrar un nuevo paciente Descripción Registro de un nuevo paciente en el estudio. Actor Médico Entradas Datos completos del paciente Salidas Ninguna Precondición Datos completos. Paciente no inscrito anteriormente. Secuencia Comprobar y validar los datos. Si los datos no son correctos, mostrar dialogo de error. Si los datos son correctos llamar al API para guardarlos Postcondición Paciente registrado correctamente. Diagrama de flujo Diagrama de flujo A.12 en la página 79 Cuadro 3.13: Caso de uso 13: Registrar un nuevo paciente CU-14 Dar de baja a un paciente Descripción Dar de baja a un paciente del estudio Actor Médico Entradas Id del paciente a dar de baja Salidas Ninguna Precondición Paciente insertado den la base de datos y dado de alta Secuencia Llamar al API para comprobar los datos Si los datos son incorrectos, mostrar dialogo de error. Si los datos son correctos, dar de baja al paciente Postcondición Paciente dado de baja correctamente. Diagrama de flujo Diagrama de flujo A.13 en la página 80 Cuadro 3.14: Caso de uso 14: Dar de baja a un paciente 3.5. BASES DE DATOS 37 3.4.3. Casos de usos compartidos Como se mostraba en la figura 3.5 los roles del médico y del paciente compartían algunos casos de uso cuyas tablas se presentan a continuación. CU-15 Ver perfil Descripción Ver perfil Actores Paciente y Médico Entradas Ninguna Salidas Perfil del usuario Precondición Usuario logeado correctamente Secuencia Llamar al API para validar los datos. Mostrar la pantalla del perfil del usuario Postcondición Perfil del usuario leído correctamente. Diagrama de flujo Diagrama de flujo A.14 en la página 81 Cuadro 3.15: Caso de uso 15: Ver perfil CU-16 Cambiar contraseña Descripción Cambiar contraseña Actor Paciente y Médico Entradas Contraseña actual. Nueva contraseña Salidas Ninguna Precondición Contraseña actual correcta Secuencia Llamar al API para comprobar la contraseña actual. Si la contraseña es incorrecta, mostrar dialogo de error. Si la contraseña es correcta, cambiarla por la nueva contraseña. Postcondición Contraseña cambiada correctamente. Diagrama de flujo Diagrama de flujo A.15 en la página 82 Cuadro 3.16: Caso de uso 16: Cambiar contraseña 3.5. Bases de Datos En los dos siguientes puntos se presentan las bases de datos de la aplicación. Una base de datos remota alojada en una instancia EC2, un servidor virtual con el sistema operativo Linux de AWS, y una base de datos local empleando la tecnología de SQLite y Room para Android, lo que permite crear y administrar una base local en cualquier dispositivo Android y que esté disponible incluso si el dispositivo no tiene una conexión activa a internet. 3.5.1. Base de datos remota Esta base de datos alojada en AWS contiene las tablas necesarias para el funcionamiento de la aplicación. Esta BBDD permite tener todos los datos centralizados y online para el correcto uso y 38 CAPÍTULO 3. METODOLOGÍA Figura 3.6: Diagrama entidad-relación para la BBDD “charmapp” funcionamiento de la aplicación. Para su gestión se ha usado PHPMyAdmin como interfaz gráfica para comprobar el correcto funcionamiento de las peticiones de la aplicación al API y viceversa. Base de datos “Charmapp” diary: Tabla donde se guardan los datos de los diarios rellenados por los pacientes. headaches: Tabla donde se guardan los datos de las crisis rellenadas por los pacientes. En esta base de datos se emplea como claves primarias o PK, dos atributos llamados patient_id y researcher_id. De este modo todas las tablas están relacionadas con los pacientes y los médicos mediante sus respectivos ids. A parte de estas tablas, existen otra serie de tablas cuya función es la de evitar los posibles campos multivalorados con el fin de mantener la estructura de la base de datos lo más normalizada posible. Base de datos “charmapp_environment” atmospheric: Tabla donde se guardan los datos de las variables atmosféricas leídas por las distintas estaciones como la temperatura, la presión o la humedad. patients_atmospheric: Tabla donde se guardan las medias calculadas para distintos datos con el fin de estudiar esos datos en el futuro. pollution: Tabla donde se guardan los datos de los elementos de contaminación leídos por las distintas estaciones como el CO o el NO stations: Tabla principal donde se guardan los datos de las distintas estaciones atmosféricas, meteorológicas y de polución. Gracias a estas estaciones es posible calcular el promedio ponderado de las variables de temperatura o presión entre otras. sys: Tabla donde se guardan otros datos leídos de las distintas estaciones como el país, el amanecer o el ocaso. weather: Tabla donde se guardan los datos relacionados con la meteorología leída de las distintas estaciones como la descripción del día. 3.5. BASES DE DATOS 39 Figura 3.7: Diagrama entidad-relación para la BBDD “charmapp_environment” 3.5.2. Base de datos local Esta base de datos se implementa en la memoria caché del dispositivo de modo que cada dispositivo tiene sus datos propios a los que podría acceder aun cuando el dispositivo no cuente con una conexión activa a internet. Para su implementación se ha usado SQLite junto con la biblioteca de persistencia oficial de Android Room, ya que esta librería permite escribir de manera rápida y sencilla las clases necesarias para el correcto funcionamiento de la BBDD. Durante el proceso de desarrollo de la aplicación y con el fin de debuggear la base de datos se ha utilizado una librería gratuita para Android llamada Database Debuger1, la cual ofrece a través del navegador web, una interfaz gráfica bastante simple para gestionar la base de datos y sus tablas. station_table: Esta tabla es una copia de la tabla stations de la base de datos remota. Se tiene esta copia local con el fin de mejorar y agilizar la ejecución de la aplicación, ya que a la hora de consultar datos de las estaciones meteorológicas se hacen directamente a esta tabla de la BBDD local. forecastData_table: Esta tabla es una copia individual para cada usuario de CharmApp de la tabla patient_atmospheric. Esta tabla se usa para guardar los datos atmosféricos recogidos por la aplicación de manera local para luego poder mostrarlos en forma de gráficas al paciente. 1GitHub del proyecto Android Debug Database. Accedido: 28/05/2020 https://github.com/ amitshekhariitbhu/Android-Debug-Database 40 CAPÍTULO 3. METODOLOGÍA Figura 3.8: Tablas de la BBDD local 3.6. Promedio ponderado El método del promedio ponderado es el método matemático escogido para realizar el cálculo de las variables atmosféricas y de polución, de manera que contando con las distancias entre las tres estaciones mas cercanas al dispositivo Android y el dispositivo Android se define el promedio ponderado Z, como: Z= 1 P2 i=0 1 d2 o,i ·X2 i=0 1 d2 o,i ·zi(3.1) Donde: do,i Representa la distancia en kilómetros entre el dispositivo origen y la estación i. ziRepresenta el valor de la variable cuya medía se quiere calcular, en este caso, temperatura, presión, humedad, CO y NO, de la estación i. En la figura 3.9 se puede ver un ejemplo gráfico del método del promedio ponderado para calcular la temperatura media ponderada con la distancia de las estaciones de medición a la ubicación del dispositivo Android. 3.6. PROMEDIO PONDERADO 41 Figura 3.9: Ejemplo del cálculo del promedio ponderado de la temperatura 48 CAPÍTULO 4. IMPLEMENTACIÓN 4.3.1.1.1. Android Studio Como herramienta principal para el desarrollo del front-end del TFG se ha utilizado Android Studio, ya que es el IDE oficial de Google, compañía dueña de Android, para el desarrollo de aplicaciones nativas para Android. Esta herramienta de desarrollo brinda muchas funciones extremadamente útiles en el desarrollo de aplicaciones móviles, algunas de estas funciones son: Editor visual para las interfaces de usuario Emulador propio para ejecutar las aplicaciones sin necesidad de un móvil Control de versiones con Git, SVN o Tortoise entre otros Generador de archivos APK automático Etc... A parte de estas funciones, en la propia página web oficial de Android Studio, se puede acceder a multitud de tutoriales divididos en distintos temas, muestras de código de otros desarrolladores, guías para desarrolladores y diseñadores o distintos codelabs, donde poder adquirir las habilidades necesarias. Durante el desarrollo del TFG, la aplicación Android Studio se actualizó varias veces, el TFG se empezó con la versión 3.5, y actualmente se utiliza la última versión de la aplicación, la versión 4.0. 4.3.1.1.2. Java Java13 es un lenguaje de programación bastante conocido con el cual se pueden desarrollar proyectos software tanto de escritorio, como web, o incluso aplicaciones móviles. Java fue lanzado en el año 1996 y permite desarrollar aplicaciones de escritorio, para dispositivos móviles, videojuegos, aplicaciones web, etc. de manera rápida, segura y fiable, siendo Java uno de los lenguajes de programación más populares hoy en día. Se ha empleado este lenguaje en el TFG, ya que al desarrollar una aplicación nativa para Android es, junto con Kotlin, el lenguaje oficial de programación para Android, ya que la herramienta Android Studio, permite crear aplicaciones Android programadas con Java o Kotlin únicamente. Actualmente y en el TFG se usa la ultima versión de Java, la versión 14.0.1. 4.3.1.1.3. XML XML es un lenguaje de marcado que se puede emplear con distintos fines como mensajería, datos o interfaces. En el TFG se ha utilizado este metalenguaje para crear las diferentes interfaces de usuario o pantallas de la aplicación. 13Página web oficial de Java. https://www.oracle.com/java/ Accedido: 04/06/2020 4.3. FRONT-END O LADO DEL CLIENTE 49 Gracias a que la propia herramienta Android Studio cuenta con una función llamada Layout Editor14 que permite crear los diseños XML tanto mediante una interfaz de arrastrar y soltar como crear los diseños escribiendo directamente el código XML. Aparte de los diseños que ofrece el propio Android Studio se han usado otras librerías para implementar diseños alternativos o que no ofrece Android Studio. Algunas de estas librerías son: Diagonal Layout15:Esta librería permite crear layouts para poner un título y una imagen o un color pero con forma diagonal en cualquier sentido. En el TFG se ha usado para los títulos de varias pantallas. Expandable Layout16:Esta librería permite crear un layout que se pueda expandir y contraer al pulsar un botón. En el TFG se ha utilizado en varias pantallas. Easy Splash Screen17:Esta librería para Android permite crear Splash Screens para las aplicaciones sin necesidad de utilizar codigo XML, ya que se programa directamente en Java. AnyChart18:Esta librería para Android permite crear y usar multitud de gráficos con los datos que se quiera. En el proyecto se ha utilizado para las gráficas meteorológicas. 14Documentación oficial de Layout Editor https://developer.android.com/studio/write/ layout-editor?hl=es-419 Accedido: 04/06/2020 15Página del proyecto en GitHub https://github.com/florent37/DiagonalLayout Accedido: 04/06/2020 16Página del proyecto en GitHub https://github.com/skydoves/expandablelayout Accedido: 04/06/2020 17Página del proyecto en GitHub https://github.com/pantrif/EasySplashScreen Accedido: 04/06/2020 18Página del proyecto en GitHub https://github.com/AnyChart/AnyChart-Android/ Accedido: 04/06/2020 50 CAPÍTULO 4. IMPLEMENTACIÓN Capítulo 5 Resultados En este capitulo se presentan los resultados obtenidos tras el diseño e implementación de la aplicación Android CharmApp. Se presentarán el flujo de uso de la aplicación desde la perspectiva del paciente y del médico. Durante la realización del capítulo se empleó un dispositivo Android Xiaomi Mi A3 con Android 10. 5.1. Flujo de uso de la aplicación CharmApp para el rol del paciente En esta sección se simula el flujo de uso para los pacientes. Se da por sentado que el paciente está inscrito dentro del estudio clínico y aparece registrado en la BBDD con sus credenciales y demás datos. Durante la simulación se usarán tanto los botones de la pantalla de inicio como los del menú lateral para desplazarse a las distintas pantallas. 5.1.1. Login El paciente accede a la aplicación a través de la pantalla de Login 5.1. Tras introducir el usuario y la contraseña si son correctos se inicia sesión y se accede a la pantalla de inicio, si alguno de los datos fuera erróneo, se muestra un toast con el mensaje del error. 5.1.2. Tutorial Tras iniciar sesión por primera vez en la aplicación mostrará un pequeño tutorial explicando las distintas pantallas y funcionalidades de la aplicación. Este tutorial puede saltarse en cualquier momento pulsando el botón omitir. El tutorial solo aparece la primera vez que el usuario inicia sesión en un dispositivo, posteriormente si se desea volver a ver el tutorial, se podrá acceder a el usando el menú lateral de la aplicación. 5.1.3. Inicio Una vez finalizado el tutorial el usuario accederá a la pantalla de inicio 5.3. En la pantalla de inicio se muestran los siguientes elementos: Resumen de la temperatura, presión y humedad. 51 52 CAPÍTULO 5. RESULTADOS Figura 5.1: Pantalla de login Figura 5.2: Pantalla de inicio del tutorial 5.1. FLUJO DE USO DE LA APLICACIÓN CHARMAPP PARA EL ROL DEL PACIENTE 53 Figura 5.3: Pantalla de inicio para el paciente Botones para rellenar el diario, añadir una crisis y consultar el historial En la esquina superior izquierda un botón de menú, en el que aparecen distintas opciones como aparece en la figura 5.4. Estas opciones son: •Inicio •Nueva crisis •Calendario •Registros atmosféricos •Perfil •Ayuda •Cerrar sesión Desde esta pantalla el usuario puede desplazarse usando los tres botones centrales o el menú lateral, presente en todas las pantallas, a cualquier otra pantalla de la aplicación. 5.1.4. Guardar diario Cada día el paciente tendrá que guardar un diario con unas cuantas preguntas. También se le recordará rellenar el diario del día mediante notificaciones en su dispositivo. Cuando el paciente vaya a rellenar el diario aparecerá una pantalla como la de la figura 5.5. 54 CAPÍTULO 5. RESULTADOS Figura 5.4: Menú lateral de la aplicación En esta pantalla el paciente podrá guardar el diario para el día de hoy o para cualquier día de los quince días anteriores. Seleccionará y rellenará todas las opciones para finalmente guardar el diario en la BBDD o si hay algún campo erróneo la aplicación mostrará un dialogo de error con los campos a revisar. Finalmente al guardar el diario correctamente o al volver hacia atrás el paciente volverá a la pantalla de inicio. 5.1.5. Crear y cerrar una crisis Si entramos en la pantalla de crear crisis observaremos una pantalla como en la figura 5.6. En esta pantalla, al igual que en la de guardar diario, deberemos rellenar y seleccionar todos los campos para crear una nueva crisis. Seleccionaremos y rellenaremos todas las opciones, a excepción de la fecha de fin de la crisis (si es que ésta aún no ha finalizado), y dando al botón de "Guardar", si todos los campos son correctos guardará una nueva crisis en la BBDD o mostrará un diálogo de error con los campos a revisar. Si existe una crisis iniciada, pero sin fecha de finalización, al entrar en la pantalla de crisis aparecerán los campos rellenos con los datos de la última crisis activa. Rellenando el campo de fecha de fin de la crisis y guardando, se actualizará la crisis en la BBDD dándose por finalizada. 5.1.6. Consultar el calendario En esta pantalla podremos ver un pequeño calendario como en la figura 5.7, donde poder seleccionar un día entre hoy y hace 30 días para consultar y editar los diarios y las crisis guardadas. 5.1. FLUJO DE USO DE LA APLICACIÓN CHARMAPP PARA EL ROL DEL PACIENTE 55 Figura 5.5: Pantalla con el formulario del diario Figura 5.6: Pantalla con el formulario de las crisis 56 CAPÍTULO 5. RESULTADOS Figura 5.7: Pantalla con el calendario 5.1.7. Consultar el diario y la crisis para un día concreto Cuando el usuario selecciona una fecha en el calendario, aparecerán dos layouts que se expanden con los datos del diario y de la crisis de ese día como en la figura 5.8 y en caso de que no hubiese datos, mostraría un dialogo de información. En esta pantalla, aparte de consultar los datos guardados, se tiene la posibilidad de editar los datos del diario y/o de la crisis, a excepción de las fechas. Una vez editados los datos y guardados, se modificarán los datos en la BBDD. 5.1.8. Consultar las gráficas de temperatura, presión y humedad A esta pantalla se accede a través del menú lateral de la aplicación. Cuando el usuario accede, se observan tres gráficas con los datos de las últimas 48 horas de la temperatura, presión y humedad, basadas en la localización del dispositivo Android como en la figura 5.9. 5.2. Flujo de uso de la aplicación CharmApp para el rol del médico En esta sección se simula el flujo de uso para los médicos. Del mismo modo que en el flujo de uso del paciente, se da por sentado que el paciente está inscrito en el estudio clínico y aparece registrado en la BBDD con sus credenciales y el resto de datos, así como que el médico participa en el estudio clínico y tiene pacientes asignados. 5.2. FLUJO DE USO DE LA APLICACIÓN CHARMAPP PARA EL ROL DEL MÉDICO 57 Figura 5.8: Pantalla para editar diarios y/o crisis Figura 5.9: Pantalla con las gráficas de temperatura y presión atmosféricas 64 CAPÍTULO 6. CONCLUSIONES Y LÍNEAS FUTURAS 6.2. Líneas futuras Como se dice anteriormente, en un futuro pueden llevarse a cabo nuevos desarrollos con distintos fines para mejorar la eficiencia del estudio clínico en el que se encuentra este TFG. Pueden ser implementadas nuevas funcionalidades que añadan facilidades a los investigadores, a los pacientes y a los médicos. Algunas de estas líneas de trabajo o futuros desarrollos serían: Desarrollo de una aplicación móvil híbrida: se propone el desarrollo de una aplicación híbrida para poder incluir dentro del estudio clínico a pacientes cuyo dispositivo móvil tenga el SO iOS de Apple en vez del SO Android de Google. De esta manera se puede llegar a tener dentro del estudio clínico a un gran número de pacientes sin necesidad de tener que descartar pacientes porque su dispositivo móvil utilice iOS. Interfaces adaptadas a personas con discapacidad: se propone el desarrollo de interfaces que se adapten a distintas discapacidades que pueda sufrir un paciente del estudio, tales como, problemas de visión, problemas de audición... Técnicas de gamificación: se propone la gamificación de la aplicación con el fin de mejorar la adherencia al estudio de manera que éste crezca de manera rápida. Blockchain en la cadena de datos: se propone incluir la tecnología de blockchain de modo que se pueda confiar en los datos recogidos por la APP y que son almacenados en la base de datos. Bibliografía [1] J. I. B. A. y María J. González Calderón, “Definición y diagnóstico de las migrañas desde una perspectiva psicobiológica,” Cuadernos del Marqués San Adrián: Revista de humanidades, no. 7, pp. 11–28, 2010. [2] I. H. Society, “The international classification of headache disorders 3rd edition,” pp. 665–666, 2013. [3] A. Abarca, “Cefalea en racimos,” Medicina Legal de Costa Rica, vol. 33, no. 1, pp. 246–253, 2016. [4] G. Manzoni, “Cluster headache and lifestyle: remarks on a population of 374 male patients,” Cephalalgia, vol. 19, no. 2, pp. 88–94, 1999. [5] R. Halker, B. Vargas, and D. W. Dodick, “Cluster headache: diagnosis and treatment,” in Seminars in neurology, vol. 30, pp. 175–185, c Thieme Medical Publishers, 2010. [6] R. C. Martin, Clean architecture: a craftsman’s guide to software structure and design. Prentice Hall, 2018. [7] M. A. Morato, Diseño e implementación de una plataforma web para el seguimiento y monitorización de pacientes con cefalea en racimos. [8] B. Barshan and M. C. Yüksek, “Recognizing daily and sports activities in two open source machine learning environments using body-worn sensor units,” The Computer Journal, vol. 57, no. 11, pp. 1649–1667, 2014. 65 66 BIBLIOGRAFÍA Apéndice A Diagramas de flujo 67 68 APÉNDICE A. DIAGRAMAS DE FLUJO Figura A.1: Diagrama de flujo para el login del usuario 69 Figura A.2: Diagrama de flujo para rellenar diario 70 APÉNDICE A. DIAGRAMAS DE FLUJO Figura A.3: Diagrama de flujo para rellenar crisis 71 Figura A.4: Diagrama de flujo para consultar historial 72 APÉNDICE A. DIAGRAMAS DE FLUJO Figura A.5: Diagrama de flujo para editar un diario 73 Figura A.6: Diagrama de flujo para editar una crisis 80 APÉNDICE A. DIAGRAMAS DE FLUJO Figura A.13: Diagrama de flujo para dar de baja a un paciente 81 Figura A.14: Diagrama de flujo para ver el perfil del usuario 82 APÉNDICE A. DIAGRAMAS DE FLUJO Figura A.15: Diagrama de flujo para cambiar la contraseña del usuario Autorización de difusión Autorización para la difusión del Trabajo Fin de Grado y su depósito en el Repositorio Institucional E-Prints Complutense Los abajo firmantes, alumno y tutor del Trabajo Fin de Grado (TFG) en Ingeniería de Computadores de la Facultad de Informática, autorizan a la Universidad Complutense de Madrid (UCM) a difundir y utilizar con fines académicos, no comerciales y mencionando expresamente a su autor, el Trabajo Fin de Grado (TFG) cuyos datos se detallan a continuación. Así mismo autorizan a la Universidad Complutense de Madrid a que sea depositado en acceso abierto en el repositorio institucional con el objeto de incrementar la difusión, uso e impacto del TFG en Internet y garantizar su preservación y acceso a largo plazo. TÍTULO del TFG: Desarrollo de aplicación para recogida de datos en estudio clínico. Curso académico: 2019/2020 Tutor del TFG: José Luis Ayala Rodrigo, Departamento de Arquitectura de Computadores y Automática, y Josué Pagán Ortiz (Universidad Politécnica de Madrid). Firma del alumno Firma del tutor 83