Desarrollo de una plataforma web y móvil para pacientes y profesionales médicos

DESARROLLO DE UNA PLATAFORMA WEB Y MÓVIL PARA PACIENTES Y PROFESIONALES MÉDICOS DEVELOPMENT OF A WEB AND MOBILE PLATFORM FOR PATIENTS AND MEDICAL PROFESSIONALS TRABAJO FIN DE GRADO CURSO 2023-2024 AUTORES FRANCISCO JAVIER ANTORANZ ESTEBAN SERGIO SÁNCHEZ CHAMIZO CARLOS PEÑA PAN DIRECTOR ANTONIO SARASA CABEZUELO GRADO EN INGENIERÍA DEL SOFTWARE FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID DESARROLLO DE UNA PLATAFORMA WEB Y MÓVIL PARA PACIENTES Y PROFESIONALES MÉDICOS DEVELOPMENT OF A WEB AND MOBILE PLATFORM FOR PATIENTS AND MEDICAL PROFESSIONALS TRABAJO DE FIN DE GRADO EN INGENIERÍA DEL SOFTWARE AUTORES FRANCISCO JAVIER ANTORANZ ESTEBAN SERGIO SÁNCHEZ CHAMIZO CARLOS PEÑA PAN DIRECTOR ANTONIO SARASA CABEZUELO CONVOCATORIA: JUNIO 2024 GRADO EN INGENIERÍA DEL SOFTWARE FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID 14 DE MAYO DE 2024 DEDICATORIA A todos aquellos que nos han dado la oportunidad para llegar hasta aquí y realizar este trabajo. AGRADECIMIENTOS Nos gustaría agradecer a Antonio Sarasa por su dedicación y atención hacia nosotros en este duradero proceso, a todos los profesores que nos han transmitido los conocimientos necesarios para poder llevarlo a cabo, a Víctor Giménez por su apoyo incondicional en el grupo de Whatsapp y por último y no menos importante a nuestras familias. RESUMEN DESARROLLO DE UNA PLATAFORMA WEB Y MÓVIL PARA PACIENTES Y PROFESIONALES MÉDICOS El objetivo de este trabajo de fin de grado es elaborar un prototipo de aplicación que sea capaz de gestionar la interacción entre doctores y pacientes facilitando diferentes servicios. El proyecto cuenta con una aplicación web destinada a los doctores y una aplicación móvil para los pacientes. Los doctores pueden planificar sus citas con los pacientes, crearles un historial médico, configurarles un tratamiento y consultar con ellos a través de un chat. Los pacientes pueden solicitar una cita, consultar sus citas en un horario, recibir alarmas de los tratamientos para la toma de un medicamento y crear una consulta con un médico. Palabras clave Doctor, Paciente, Cita, Tratamiento, Consulta, Historial, Web, Móvil, Servidor. ABSTRACT DEVELOPMENT OF A WEB AND MOBILE PLATFORM FOR PATIENTS AND MEDICAL PROFESSIONALS The objective of this final degree project is the development of an application prototype that is capable of managing the interaction between doctors and patients by facilitating different services. The project has a web application for doctors and a mobile application for patients. Doctors can plan their appointments with patients, create a medical history for them, set up a treatment for them, and consult with them via chat. Patients can request an appointment, consult appointments in their schedule, receive treatment alarms for taking medication, and create a consultation with a doctor. Keywords Doctor, Patient, Appointment, Treatment, Consultation, History, Web, Mobile, Server. ÍNDICE DE CONTENIDOS Capítulo 1 - Introducción ........................................................................................................ 1 1.1 Motivación ............................................................................................................ 1 1.2 Objetivos ............................................................................................................... 1 1.3 Plan de Trabajo .................................................................................................... 2 1.4 Estructura de la memoria .................................................................................... 5 Chapter 1 - Introduction ......................................................................................................... 7 1.1 Motivation ...................................................................................................................... 7 1.2 Objective ........................................................................................................................ 7 1.3 Workplan ........................................................................................................................ 8 1.4 Memory Structure .........................................................................................................10 Capítulo 2 - Estado de la Cuestión .................................................................................13 2.1.1 Whatsapp .....................................................................................................13 2.1.2 MyChart ........................................................................................................13 2.1.3 HealthTap .....................................................................................................13 2.1.4 Zocdoc .........................................................................................................14 2.1.5 Practice Fusion .............................................................................................14 Capítulo 3 - Tecnología Empleada .................................................................................15 3.1 Lenguajes de Programación ..............................................................................15 3.1.1 JavaScript .....................................................................................................15 3.1.2 Cascading Style Sheets (CSS) .....................................................................16 3.1.3 HyperText Markup Language (HTML) .........................................................16 3.1.4 Java ..............................................................................................................16 3.1.5 Extensible Markup Language (XML) ..........................................................16 3.2 Herramientas/Entornos de Desarrollo ................................................................17 3.2.1 Node.js ..........................................................................................................17 3.2.2 Bootstrap ......................................................................................................18 3.2.3 Embedded JavaScript (EJS) .......................................................................18 3.2.4 Visual Studio Code ......................................................................................18 3.2.5 Android Studio .............................................................................................18 3.2.6 MySQL ...........................................................................................................19 3.2.7 Xampp ..........................................................................................................19 Capítulo 4 - Arquitectura de la Aplicación y modelo de datos ..................................21 4.1 Arquitectura de la aplicación ............................................................................21 4.2 Estructura de la Base de Datos ..........................................................................23 4.2.1 Tabla Doctores .............................................................................................25 4.2.2 Tabla Pacientes ...........................................................................................25 4.2.3 Tabla Asignaciones .....................................................................................26 4.2.4 Tabla Consultas ............................................................................................26 4.2.5 Tabla Mensajes ............................................................................................26 4.2.6 Tabla Tratamiento ........................................................................................27 4.2.7 Tabla Alarma ................................................................................................27 4.2.8 Tabla Citas ....................................................................................................28 4.2.9 Tabla Notificaciones ....................................................................................28 4.2.10 Tabla Enfermedades ...................................................................................29 4.2.11 Tabla Sessions ...............................................................................................29 Capítulo 5 - Implementación, Estructura y Diseño de la Aplicación Móvil .................31 5.1 Diseño de la Aplicación Móvil ............................................................................31 5.2 Estructura en la Aplicación Híbrida de Android ...............................................32 5.3 Implementación de la Aplicación Móvil ...........................................................37 5.3.1 Módulo Gestión de Usuarios Paciente .......................................................37 5.3.2 Módulo Gestión de Citas Paciente ............................................................50 5.3.3 Módulo Gestión de Tratamientos Paciente ..............................................53 5.3.4 Módulo Gestión de Consultas Paciente ....................................................63 Capítulo 6 - Implementación, Estructura y Diseño de la Aplicación Web ..................75 6.1 Diseño de la Aplicación Web ............................................................................75 6.2 Estructura del Servidor .........................................................................................75 6.3 Estructura de la Aplicación Web .......................................................................78 6.4 Implementación de la Aplicación Web ............................................................81 6.4.1 Módulo Gestión de Usuarios Doctor ..........................................................81 6.4.2 Módulo Gestión de Asignaciones ..............................................................84 6.4.5 Módulo Gestión de Historial Doctor ...........................................................87 6.4.11 Módulo Gestión de Citas Doctor ...............................................................89 6.4.12 Módulo Gestión de Tratamientos Doctor ..................................................94 6.4.13 Módulo Gestión de Consultas Doctor .......................................................95 Capítulo 7 - Conclusiones y Trabajo Futuro ....................................................................97 7.1 Conclusiones ........................................................................................................97 ÍNDICE DE FIGURAS APÉNDICES Figura Apéndice A-1Diagrama Gestión de Usuarios ...................................................... 111 Figura Apéndice A-2Diagrama de Gestión de Historial Médico ................................... 112 Figura Apéndice A-3Diagrama de Gestión de Citas ...................................................... 113 Figura Apéndice A-4Diagrama de Gestión de Tratamientos ........................................ 114 Figura Apéndice A-5Diagrama Gestión de Consultas.................................................... 115 Figura Apéndice B-1Pantalla Principal MedAlerta .......................................................... 153 Figura Apéndice B-2Pantalla Inicio Sesión MedAlerta .................................................... 154 Figura Apéndice B-3Pantalla Registro MedAlerta ........................................................... 154 Figura Apéndice B-4Pantalla Registro MedAlerta ........................................................... 155 Figura Apéndice B-5Pantalla Editar Perfil ......................................................................... 156 Figura Apéndice B-6Gestión de usuarios ......................................................................... 157 Figura Apéndice B-7Gestión de usuarios - Añadir Usuario .............................................. 157 Figura Apéndice B-8Gestión de usuarios - Funcionalidades de Usuario Parte 1 .......... 158 Figura Apéndice B-9.- Gestión de usuarios - Funcionalidades de Usuario Parte 21 ....... 159 Figura Apéndice B-10Gestión de usuarios - Iniciar Tratamiento ..................................... 160 Figura Apéndice B-11Gestión de usuarios - Añadir cita ................................................. 160 Figura Apéndice B-12Gestión de usuarios - Crear Historial ............................................. 161 Figura Apéndice B-13Gestión de usuarios - Descargar Historial ....................................... 162 Figura Apéndice B-14Gestión de usuarios - Pdf Historial ................................................. 162 Figura Apéndice B-15Gestión de usuarios - Añadir Detalles al Historial ........................ 163 Figura Apéndice B-16Consultas - Lista de consultas ....................................................... 163 Figura Apéndice B-17Consultas - Chat de consultas ...................................................... 164 Figura Apéndice B-18Calendario - Vista Mensual ........................................................... 165 Figura Apéndice B-19Calendario - Vista Semanal .......................................................... 165 Figura Apéndice B-20Calendario - Vista Diaria y cartel de detalle de la cita ............. 166 Figura Apéndice B-21CitasVer/Confirmar/Rechazar peticiones de citas. .................. 167 Figura Apéndice C-1Inicio de sesión de la app .............................................................. 168 Figura Apéndice C-2Registro de la app .......................................................................... 169 Figura Apéndice C-3Validar cuenta ................................................................................ 170 Figura Apéndice C-4Pantalla principal de la aplicación móvil. .................................... 171 Figura Apéndice C-5Gestión del perfil - Editar perfil. ...................................................... 172 Figura Apéndice C-6Gestión del perfil - Cambio de contraseña. ................................. 173 Figura Apéndice C-7Consultas - Consultas del paciente ............................................... 174 Figura Apéndice C-8Consultas - Chat de consultas de la app ..................................... 175 Figura Apéndice C-9Consultas - Crear consulta con un doctor ................................... 176 Figura Apéndice C-10Consultas - Chat de consultas de la app ................................... 177 Figura Apéndice C-11Calendario - Vista principal del calendario ............................... 178 Figura Apéndice C-12Calendario - Detalles de la cita .................................................. 179 Figura Apéndice C-13Crear CitaSolicitud de cita ........................................................ 180 Figura Apéndice C-14Alarma - Notificación de la alarma ............................................ 181 ÍNDICE DE TABLAS Tabla 1Fecha de entregas de hitos ..................................................................................... 3 Tabla 2en. Milestone delivery date ...................................................................................... 9 Tabla 3Tabla de cambios a futuro.de cambios a futuro. .................................................98 Tabla 4Table of future changes. f future changes. ......................................................... 100 Tabla 5Tabla de requisitos registrar doctor ...................................................................... 117 Tabla 6Tabla de requisitos registrar paciente .................................................................. 118 Tabla 7Tabla de requisitos inicio de sesión doctor .......................................................... 119 Tabla 8Tabla de requisitos inicio de sesión paciente ...................................................... 120 Tabla 9Tabla de requisitos validar cuenta paciente....................................................... 121 Tabla 10Tabla de requisitos editar perfil doctor .............................................................. 123 Tabla 11Tabla de requisitos editar perfil paciente .......................................................... 124 Tabla 12Tabla de requisitos validar cuenta paciente ..................................................... 125 Tabla 13Tabla de requisitos eliminar cuenta doctor. ...................................................... 126 Tabla 14Tabla de requisitos eliminar cuenta paciente ................................................... 127 Tabla 15Tabla de requisitos para vincular médico paciente. ........................................ 128 Tabla 16Tabla de requisitos para desvincular médico paciente. .................................. 129 Tabla 17Tabla de requisitos para crear/modificar historial médico .............................. 131 Tabla 18Tabla de requisitos para ver historial médico .................................................... 132 Tabla 19Tabla de requisitos para añadir detalles al historial médico ............................ 133 Tabla 20Tabla de requisitos para eliminar el historial médico de un paciente ............ 134 Tabla 21Tabla de requisitos solicitar Cita ......................................................................... 135 Tabla 22Tabla de requisitos aceptar o rechazar Cita ..................................................... 136 Tabla 23Tabla de requisitos crear Cita ............................................................................. 138 Tabla 24Tabla de requisitos ver citas doctor .................................................................... 139 Tabla 25Tabla de requisitos ver citas paciente ............................................................... 139 Tabla 26Tabla de requisitos eliminar cita ......................................................................... 141 Tabla 27Tabla de requisitos creación de un tratamiento. .............................................. 142 Tabla 28Tabla de requisitos paral a configuración de una alarma. ............................. 143 Tabla 29Tabla de requisitos para la recepción de una alarma. .................................... 144 Tabla 30Tabla de requisitos crear consulta ...................................................................... 146 Tabla 31Tabla de requisitos ver consultas doctor ............................................................ 147 Tabla 32Tabla de requisitos ver consultas paciente ....................................................... 148 Tabla 33Tabla de requisitos ver mensajes consulta doctor ............................................ 149 Tabla 34Tabla de requisitos ver mensajes consulta paciente ........................................ 150 Tabla 35Tabla de requisitos enviar mensajes consulta doctor ....................................... 151 Tabla 36Tabla de requisitos enviar mensajes consulta paciente ................................... 152 1 Capítulo 1 - Introducción 1.1 Motivación La motivación de este proyecto de Fin de Grado surge de la necesidad de superar las barreras de acceso y mejorar la calidad de vida de las personas a través de una adecuada atención médica. Son múltiples las dificultades a las que se enfrentan los médicos y los pacientes. Entre estas dificultades destacan la escasez de tiempo para los desplazamientos, la falta de familiaridad de ciertos sectores de la población la tecnología, y las limitaciones geográficas, especialmente para personas con movilidad reducida. La solución ideada para abordar estos desafíos consiste en el desarrollo de una aplicación móvil dirigida a los pacientes, complementada con una plataforma web diseñada específicamente para los doctores. Estas herramientas están creadas con el propósito de facilitar y optimizar la comunicación de ambas partes. 1.2 Objetivos El objetivo de este trabajo de fin de grado es elaborar una aplicación capaz de facilitar el uso a pacientes y doctores, mejorando la comunicación entre ambos y optimizando el proceso de atención médica. Para cumplir este objetivo se crearon las siguientes marcas: • Investigar las dificultades: Su objetivo es identificar las principales necesidades tanto de los médicos como de los pacientes para determinar cuáles son las demandas más usuales y centrarse en solucionarlas de manera efectiva. Esta investigación permite comprender y orientar el desarrollo de la aplicación. • Diseñar la aplicación web y móvil: El segundo objetivo sería plantear el diseño de ambas aplicaciones para que la comunicación sea efectiva. Para ello, ambas contarán con una estructura sencilla e intuitiva para que 2 todo tipo de personas puedan navegar libremente independientemente de su nivel de experiencia tecnológica. • Garantizar la seguridad y la privacidad de datos: El tercer objetivo es comprobar que los datos personales que se tratan están guardados de manera segura y no existen vulnerabilidades que hagan accesibles estos datos. • Elaborar pruebas: El cuarto objetivo es elaborar pruebas sobre las diferentes funcionalidades para asegurarse que los usuarios no tendrán ningún tipo de problema. • Probar la aplicación en una parte del sector médico: El quinto objetivo consiste en identificar una pequeña parte del sector médico, como un hospital o un centro de salud. Se distribuye la aplicación y se proporciona asistencia de ser necesario. • Analizar los resultados: El último objetivo es analizar los datos recogidos durante las pruebas y utilizar esta información para realizar mejoras. Este análisis evaluará el rendimiento de la aplicación en términos de usabilidad, eficacia y satisfacción del usuario. Basándose en estos datos se llevarán a cabo ajustes y mejoras continuas para optimizar la funcionalidad de la aplicación. 1.3 Plan de Trabajo En esta sección se muestra el plan de trabajo a seguir para la consecución de los objetivos descritos en el apartado anterior. Al comienzo del Trabajo de Fin de Grado se separaron los hitos y se establecieron fechas aproximadas de entregas recomendadas para cada uno (ver Tabla 1, Figura 1.1). 3 Hitos Fecha de entrega Planificación de requisitos Mediados de octubre Gestión de usuarios Mediados de noviembre Gestión de pacientes Mediados de diciembre Gestión del historial médico Mediados de enero Gestión de tratamientos Final de enero Gestión de citas médicas Final de Febrero Gestión de consultas Final de Marzo Finalización de código Final de Abril Realización de la memoria 14 de mayo Tabla 1Fecha de entregas de hitos Figura 1.1Mapa de plan de trabajo A continuación, se explican los hitos que se han llevado a cabo a lo largo del desarrollo del proyecto. 4 Planificación de requisitos: El hito inicial del proyecto, se dedicó a la creación de los casos de uso que engloban las acciones de los usuarios de la aplicación. Se coordinó una reunión con el tutor para debatir y confirmar estos requisitos. Gestión de usuarios: Este segundo hito se concentra en permitir a los usuarios realizar operaciones básicas de registro, inicio de sesión, cierre de sesión, modificación y eliminación de perfil. Gestión de pacientes: En este tercer hito, el enfoque se dirige a los médicos, quienes desde la aplicación web podrán poder agregar, editar y eliminar a pacientes a sus asignaciones. Además, podrán listar, buscar, ver información básica, filtrar y ordenar entre todos sus pacientes. Gestión de historial médico: En este cuarto hito, se espera que los doctores puedan crear, ver, modificar y eliminar los historiales médicos de sus pacientes a través de la aplicación web. Gestión de tratamientos: En este quinto hito, se prevé que los doctores puedan recetar medicaciones con un tratamiento mediante aplicación web y que los pacientes puedan recibir dichos tratamientos y recibir las alarmas correspondientes. Gestión de citas médicas: En este sexto hito, se espera que tanto desde la aplicación web como móvil se puedan proponer o crear citas, confirmarlas, cancelarlas y observarlas a través de un calendario u horario. Gestión de consultas: En este séptimo hito, los pacientes crear una consulta con sus doctores desde la aplicación móvil, permitiendo una comunicación fluida entre ambas partes a través de las consultas. Finalización de código: En este octavo hito, se ha llevado a cabo la fase de prueba exhaustiva de ambas aplicaciones en su totalidad. Se han evaluado los posibles fallos y se ha verificado que todas las funcionalidades estén implementadas de manera correcta. 5 1.4 Estructura de la memoria La memoria del TFG se ha dividido en diferentes capítulos, los cuales corresponden a los siguientes: La portada del TFG, el apartado de dedicatoria y agradecimientos, un resumen que cuenta en qué consiste la aplicación desarrollada, el índice global donde se pueden ver los diferentes capítulos que formar parte de la memoria del proyecto como el capítulo 1 donde se realiza la introducción que engloba la motivación, objetivos, plan de trabajo seguido y la estructura de esta memoria, el capítulo 2 donde explican aplicaciones cuya funcionalidad es similar a la aplicación diseñada, el capítulo 3 donde se exponen las tecnologías utilizadas durante el desarrollo del código, el capítulo 4 donde se explica la arquitectura de ambas aplicaciones, del servidor y de la base de datos, el capítulo 5 en el que se detalla la implementación y diseño de la aplicación móvil, el capítulo 6 en el que se expone la implementación y la aplicación de la aplicación web, y el capítulo 7 donde se documentan las conclusiones y el trabajo futuro a desarrollar y las 3 últimas partes de esta memoria son apéndices donde se encuentran todos los casos de uso y los manuales de usuario tanto de la aplicación web como del móvil. 6 13 Capítulo 2 - Estado de la Cuestión En este capítulo se van a exponer y explicar brevemente las diferentes aplicaciones en las que se ha inspirado para elaborar la aplicación. 2.1.1 Whatsapp WhatsApp [1] es una aplicación de mensajería instantánea, ampliamente utilizada a nivel mundial. Lanzada en 2009, permite a los usuarios enviar mensajes de texto, realizar llamadas de voz y video, compartir imágenes, videos, documentos, ubicaciones y contactos. WhatsApp utiliza un sistema de notificaciones para alertas a los usuarios sobre nuevos mensajes, llamadas, o cualquier mención. Estas notificaciones aparecen en la pantalla del dispositivo incluso cuando la aplicación no está en uso. 2.1.2 MyChart MyChart [2] es un portal de salud desarrollado por Epic Systems, que permite a los pacientes acceder a sus registros médicos y comunicarse con profesionales de la salud. A través de esta plataforma, los pacientes pueden ver sus historiales médicos, resultados de pruebas y diagnósticos, y gestionar citas médicas. También proporciona recordatorios de citas y medicamentos, y permite realizar visitas virtuales. 2.1.3 HealthTap HealthTap [3] es una plataforma de telemedicina que conecta a los pacientes con los médicos para consultas en línea, ofreciendo una manera conveniente y rápida de recibir atención médica. A través de HealthTap, los pacientes pueden realizar consultas médicas por videollamadas, llamadas de voz o mensajes de texto, y obtener respuestas a preguntas médicas en tiempo real. Los médicos pueden emitir recetas electrónicas y proporcionar planes de tratamiento personalizas. 14 2.1.4 Zocdoc Zocdoc [4] es una plataforma que facilita a los pacientes a encontrar médicos y programar citas de manera rápida y sencilla. A través de Zocdoc, los pacientes pueden buscar médicos por especialidad, ubicación y disponibilidad, leer reseñas y calificaciones de otros pacientes, y reservar citas en línea. La plataforma también envía recordatorios automáticos de citas por correo electrónico y mensajes de texto. También proporciona información detallada sobre los médicos, incluyendo su formación, experiencia y especialidades, lo que ayuda a los pacientes a tomar decisiones informadas sobre su atención médica. 2.1.5 Practice Fusion Practice Fusion [5] es un sistema de registros médicos electrónicos (EMR) basado en la nube, ideal para pequeñas y medianas prácticas médicas. Este sistema permite a los médicos gestionar los registros de sus pacientes, incluyendo información demográfica, historiales médicos y notas de consulta. Practice Fusion facilita la programación y gestión de citas médicas, la emisión de recetas electrónicas directamente de las farmacias, y proporciona una interfaz intuitiva y fácil de usar. Además, ofrece herramientas de reportes y análisis para mejorar la gestión de la práctica médica y la atención al paciente, y cuenta con una comunidad en línea para que los usuarios compartan experiencias y mejores prácticas. 15 Capítulo 3 - Tecnología Empleada En este capítulo se van a tratar las diferentes tecnologías usadas en el proceso de desarrollo de la aplicación. Se expondrán las diferentes herramientas y lenguajes de programación utilizados para los dos fronts: la aplicación híbrida móvil y la aplicación web, así como en el backend. 3.1 Lenguajes de Programación En este apartado se van a tratar los diferentes lenguajes de programación utilizados en la aplicación. 3.1.1 JavaScript JavaScript [6] es un lenguaje destacado en el desarrollo web. Suele utilizarse para crear y controlar la carga dinámica en el lado del cliente, es decir, en el navegador web del usuario. En otras ocasiones, como en esta aplicación, se utiliza en el lado del servidor a través del framework Express.js. En el lado del servidor, se ha utilizado para: la gestión de solicitudes o peticiones GET o POST, la configuración de middlewares, el control y acceso a la base de datos, el envío de correos electrónicos, entre otros. Para la lectura y almacenamiento de los archivos y carpetas se han utilizado las librerías fs[7] y path[8] de node.js. En el lado del cliente, se ha utilizado para la carga dinámica de datos en las pantallas del calendario, citas, gestión de usuarios, creación de historial médico y otros pequeños scripts. En el calendario concretamente, se ha utilizado la librería externa FullCalendar.js [9] de JavaScript y para la creación del historial médico se ha utilizado PDFKit[10]. 16 3.1.2 Cascading Style Sheets (CSS) CSS [11] es un lenguaje utilizado para el diseño de páginas web elaboradas con HTML. Se ha utilizado en la mayoría de las vistas para mejorar la estética del proyecto, esto implica definir atributos como el diseño de los iconos, las dimensiones de los títulos, tipografía, colores, estilizar mensajes y colores de fondo. Dentro del proyecto web, se encuentra en la carpeta “public/stylesheets/style/”, y dentro de cada HTML se llama a este archivo para poder modificar los atributos deseados. Además, se ha utilizado la librería CSS y JavaScript de Bootstrap. 3.1.3 HyperText Markup Language (HTML) HTML [12] es un lenguaje de marcado utilizado para la creación de páginas web. Se ha usado para definir la estructura inicial de las páginas, su contenido, la barra de navegación, los botones, el pié de página, entre otras. A su vez, esta estructura se puede estilizar y manipular mediante el uso de CSS para aspectos visuales y es capaz de añadir interactividad y funcionalidad dinámica con JavaScript. 3.1.4 Java Java [13] es el lenguaje de programación orientado a objetos, utilizado junto con Kotlin en Android Studio para desarrollar aplicaciones. Se optó por Java debido a su amplio uso por desarrolladores y la existencia de una amplia familiaridad con este lenguaje obtenido a lo largo de la carrera. Se ha utilizado en el entorno de la aplicación móvil para conectar la implementación de las funcionalidades con los componentes definidos en el XML, gestionar la creación de alarmas, notificaciones y además también se usa para enviar información mediante solicitudes HTTP al servidor node.js. 3.1.5 Extensible Markup Language (XML) XML [14] es un lenguaje de marcado utilizado para definir la estructura y el contenido de diversos elementos en el desarrollo de aplicaciones Android. 17 Se ha empleado para definir la interfaz de usuario. Los archivos XML de diseño guardados dentro de la carpeta “res/layout/”, se utilizan para definir componentes como pantallas, fragments, mensajes de las consultas, mensajes que muestran los datos de una cita o una consulta, cuadros de texto y botones entre otros. También se pueden definir recursos estáticos como cadenas de texto y colores en la carpeta “res/values/”, iconos en la carpeta “res/drawable/”, y el sonido de la alarma en la carpeta “res/raw/”. En todas las aplicaciones hay un archivo de configuración llamado AndroidManifest.xml. 3.2 Herramientas/Entornos de Desarrollo En este apartado se van a tratar las diferentes herramientas y entornos de desarrollo utilizados en el proyecto. 3.2.1 Node.js Es un entorno de ejecución de JavaScript que permite diseñar la lógica de la aplicación del lado del servidor. Se utiliza principalmente para crear la aplicación web usando tecnologías como HTML, CSS y Javascript. Node.js [15] es la plataforma base sobre la que se ejecutan paquetes con “npm install <paquete>” o frameworks como Express.js, que facilita plantillas, estructura de carpetas básicas, manejo del enrutamiento y gestión de solicitudes y respuestas HTTP. Con node.js se pueden instalar dependencias como express-session que permite la creación y gestión de sesiones con los usuarios que interactúan con la aplicación, o como nodemailer para gestionar el envío de correos electrónicos. Se da uso de node.js también para conectar el servidor con la base de datos MySql utilizando “npm run start” previamente habiendo instalado su dependencia con “npm install mysql”. 18 3.2.2 Bootstrap Bootstrap [16] es un framework front-end ampliamente utilizado para el desarrollo de sitios web y aplicaciones web. Se consideró oportuno usarlo debido al ahorro de tiempo y a la facilidad que proporciona al crear interfaces de usuario adaptables. Esta librería ofrece componentes pre-estilizados como botones, formularios, barras de menú y otros elementos que son visualmente atractivos. Bootstrap utiliza HTML, CSS y Javascript para su implementación. 3.2.3 Embedded JavaScript (EJS) EJS [17] es un motor de plantillas que posibilita la generación de HTML dinámico usando JavaScript. La plantilla permite la inserción de fragmentos de código JavaScript dentro de los archivos de plantilla, facilitando la creación eficiente de contenido web interactivo como listas de paciente, listas de consultas, títulos e implementación de mensajes entre otros. 3.2.4 Visual Studio Code Visual Studio Code[18] es un editor de código altamente popular y gratuito desarrollado por Microsoft. Se optó por utilizar este entorno debido a la facilidad que brinda a la hora de escribir código, de depurar y de gestionar proyectos. Además de que se cuenta con experiencia previa en el uso de este editor, también se eligió por la comodidad que proporciona respecto a la integración y colaboración con GIT. 3.2.5 Android Studio Android Studio [19] es el entorno de desarrollo por excelencia para aplicaciones Android. Se utilizó este entorno debido a la gran variedad de herramientas y funcionalidades avanzadas que proporciona, las cuales facilitan la creación de una aplicación móvil para Android. En particular resultó sencillo el uso de sus emuladores móviles, que ha permitido probar la aplicación de manera precisa y eficaz. 19 3.2.6 MySQL MySQL [20] es una base de datos relacional, donde se guarda toda la información de la aplicación tanto web como de móvil, al ser relacional implica que la información se organiza en tablas compuestas por filas y columnas. Estas tablas contienen datos específicos como pacientes, citas, tratamiento y doctores, entre otros, donde en el caso de pacientes, se especifican atributos como el nombre, apellidos, email, código postal, fecha de nacimiento, dni, dirección y contraseña de cada paciente, lo mismo sucede con el resto de las tablas. 3.2.7 Xampp Xampp [21] es un paquete de software libre que proporciona un entorno de desarrollo que incluye MySQL como gestor de base de datos, esto ha permitido probar la aplicación y manejar datos localmente de manera eficiente. 20 21 Capítulo 4 - Arquitectura de la Aplicación y modelo de datos En este capítulo se describe la arquitectura utilizada y las tablas que forman la base de datos. 4.1 Arquitectura de la aplicación Durante el desarrollo del proyecto se ha utilizado la arquitectura cliente-servidor, con dos clientes: los pacientes en la aplicación móvil, y los médicos utilizando la plataforma web. Por la parte de la aplicación de Android, los pacientes realizan peticiones al servidor que se encuentra alojado en la parte de la página web. Por parte de la plataforma web, los médicos también hacen solicitudes o peticiones y reciben respuestas del servidor. En cuanto al servidor se utiliza XAMPP, que permite trabajar localmente. En este entorno, Apache actúa como el servidor web que maneja las solicitudes HTTP entrantes desde los clientes, mientras que MySQL, por otro lado, actúa como el sistema de gestión de bases de datos que almacena y gestiona los datos de la aplicación. Los datos de la aplicación pueden verse representados en la figura 4.1. con un modelo entidadrelación. En resumen, los clientes son los que toman la iniciativa al enviar solicitudes al servidor. El servidor, por su parte, permanece a la espera de recibir estas solicitudes de los clientes. Una vez llegan, el servidor procesa y envía las respuestas de vuelta a los clientes que, en este caso, son tanto los médicos como los pacientes. Esta configuración se puede observar en la figura 4.2. 22 Figura 4.1Modelo entidad - relación de la aplicación 29 Figura 4.12Tabla notificaciones 4.2.10 Tabla Enfermedades En la tabla enfermedades (ver figura 4.13) almacena las enfermedades que se muestran para asignar en el historial médico. Su clave única es la unión del dni del doctor y el nombre de la enfermedad. Figura 4.13Tabla enfermedades 4.2.11 Tabla Sessions En esta tabla (ver figura 4.14) se guarda toda la información necesaria para cada sesión de usuario. Posee un identificador de sesión como clave única, un número que indica la expiración de la sesión y por último una variable que almacena aquellos datos que se quieran mantener en cada sesión. Estos datos se guardan en un mismo campo con una estructura “. json”. Figura 4.14Tabla sessions 30 31 Capítulo 5 - Implementación, Estructura y Diseño de la Aplicación Móvil En esta sección se exponen los detalles de la implementación, la estructura y el diseño de la aplicación móvil, organizando las diversas funcionalidades en los siguientes módulos funcionales: ● Módulo Gestión de usuarios ● Módulo Gestión de citas ● Módulo Gestión de tratamientos ● Módulo Gestión de consultas 5.1 Diseño de la Aplicación Móvil La aplicación móvil de Android presenta un diseño sencillo y altamente intuitivo. Ha sido diseñado para garantizar la accesibilidad y sencillez para personas de cualquier edad y nivel de experiencia. Se busca que la persona se sienta cómoda y pueda visualizar al momento las funciones de la aplicación sin causarle ningún tipo de confusión. La elección de la paleta de colores se ha centrado en la simplicidad y efectividad visual. Se ha optado por tonos sencillos como un azul oscuro y blanco. Este último por un lado ayuda a que el contenido sea fácilmente legible, mientras que el azul oscuro por otro lado es un buen contraste con el blanco mejorando aún más la legibilidad del texto. Además, estos colores se han extendido del icono de la aplicación, el cual también presenta tonalidades para crear una sensación de profesionalidad y confianza. En determinadas ocasiones se presentan colores como el negro en cuadros texto para que resalte con el blanco y sea legible, por ejemplo, los botones de “¿Has olvidado la contraseña?” y “Cambiar contraseña” están en rojo para resaltar dicha funcionalidad, ya que la pérdida o el olvido de una contraseña puede ser una situación urgente para los pacientes y tienen que ver que estas opciones están fácilmente 32 disponibles con el objetivo de que puedan proteger sus cuentas ante cualquier eventualidad. En el caso de las consultas con los doctores, se usa un color amarillo suave de fondo en el nombre del doctor, ya que este color transmite una sensación de amabilidad y cercanía con él, además de crear un contraste suave con los colores de los mensajes que son azules de diferentes tonos para que se diferencien fácilmente entre sí. El nombre del doctor en este caso está en negro ya que presenta un contraste agradable respecto al amarillo suave de fondo. En cuanto a la navegación por la aplicación, una vez se inicie sesión, se muestra una estructura clara y sencilla en la que se observa una barra de menú con tres botones situada en la parte inferior de la pantalla. En todo momento la barra está presente para poder cambiar de vista cuando se desee. En la parte superior de las pantallas se encuentra el icono de la aplicación, el nombre del paciente, y un botón con el icono de tres puntos colocados verticalmente para indicar que se despliega un menú. En el caso de las consultas con los doctores, no se muestra ni la barra inferior del menú, ni la barra superior para mayor comodidad a la hora de escribir y leer mensajes. 5.2 Estructura en la Aplicación Híbrida de Android En la aplicación móvil se han estructurado las carpetas como se ven en la Figura 5.1 Utilizando gradle que permite añadir dependencias al proyecto, y construir la aplicación a partir de los ficheros. Dentro de la aplicación se hace una primera división en tres paquetes: manifest, java y res. 33 Figura 5.1Estructura de la aplicación móvil Manifest contiene un fichero XML del mismo nombre con una serie de configuraciones para la aplicación: en ella se indican los permisos que debe tener, como por ejemplo acceso a internet, vibración, mandar notificaciones, acceder al calendario, entre otras(ver figura 5.2); se establecen también las diferentes actividades de la aplicación indicando cual es la primera en ejecutarse; se indican también los elementos receptores que reciben un evento que ocurre en el móvil, como por ejemplo el evento de parar el sonido de la alarma(ver figura 5.3); y por último, la configuración de una serie de servicios que lanzan un evento en el móvil, como por ejemplo para lanzar una notificación(ver figura 5.4). Figura 5.2Manifest XML permisos 34 Figura 5.3Manifest XML receptor de un evento Figura 5.4Manifest XML servicio para lanzar una notificación En la carpeta Java se encuentran los ficheros “.java” de la aplicación, que se han organizado siguiendo un modelo vista controlador. Las clases java asociadas a las diferentes vistas de la aplicación se encuentran dentro de las carpetas “activities/” y “fragments/” (ver Figura 5.5). Figura 5.5Manifest XML servicio para lanzar una notificación 35 Los fragments son ciertas partes de una pantalla o actividad que van cambiando sin la necesidad de refrescar toda la pantalla. En este caso, se hace uso de estos para mantener los navbar y botones inferiores sin la necesidad de estar configurando estos en cada una de las actividades. El controlador se encuentra dentro de la carpeta utils(ver Figura 5.8), este comunica el modelo con la vista mandando y recibiendo información encapsulada en clases Java que se encuentran dentro de la carpeta “data/” (ver Figura 5.6). Figura 5.6Estructura de la aplicación móvil carpeta data El modelo de la aplicación se encuentra dentro de la carpeta “services/” que contiene una serie de clases e interfaces que se encargan de hacer las llamadas API al servidor node.js (ver figura 5.7). Figura 5.7Estructura de la aplicación móvil carpeta services 36 Una vez se ha mencionado las clases que intervienen en el modelo vista controlador, existen otra serie de clases dentro del proyecto en la carpeta de “utils/”(ver figura 5.8) que sirven de utilidad. Dentro de esta se encuentran: ● Los adapters, sirven para mostrar una lista de elementos en un recycler view en las vistas. ● Clases que ejecutan métodos asíncronos, es decir, en hilos secundarios al principal que permiten mandar peticiones API al servidor y dentro del proyecto destacan las clases ActualizarMensajesAsync y NotificarMensajesAsync que mandan peticiones al servidor para llevar a cabo la gestión del chat de consultas en un segundo plano. ● Las clases manager ayudan en la gestión del dispositivo móvil. NotificacionesManager se encarga de la creación de las notificaciones y sus canales. NavigationManager ayuda a encapsular en una sola clase la lógica del cambio de pantallas. Por último, el SessionManager se centra en el mantenimiento de una sesión en el dispositivo móvil guardando los datos necesarios del usuario. ● Los receiver implementan las acciones a cometer cuando se recibe un evento en el móvil. En el proyecto se tienen tres tipos: el AlarmReceiver, que actúa al recibir una alarma, el InicioMovilReceiver, que se ejecuta al iniciarse el móvil y el NotificationButtonReceiver, que se ejecuta cuando el usuario le da al botón de parar una alarma. 37 Figura 5.8Estructura de la aplicación móvil carpeta utils 5.3 Implementación de la Aplicación Móvil La implementación de la aplicación móvil se ha dividido en los módulos o funcionalidades, previamente mencionados, en los que el actor principal es el paciente. Las capturas de las pantallas se podrán visualizar en el manual del usuario paciente con el fin de no repetir las imágenes. 5.3.1 Módulo Gestión de Usuarios Paciente Dentro de esta sección están implementadas las acciones que puede realizar el paciente respecto a la creación y administración del perfil. 5.3.1.1 Iniciar Sesión Al iniciar la aplicación por primera vez, la primera pantalla que aparece es la de iniciar sesión, en ésta se tienen que introducir los campos que corresponden al dni y a la contraseña, en la figura 5.9 se muestra un trozo del código utilizado para crear el diseño de esta pantalla. El código donde se implementan los botones y los cuadros de texto se muestran en la figura 5.10. 38 Figura 5.9Código del diseño de Inicio de Sesión Figura 5.10Código de la implementación de Inicio de Sesión 45 Figura 5.19Generación número Aleatorio Una vez el router recoge los datos y los envía por correo haciendo uso del mailer(librería de node.js) a través de la función “sendVerificationEmail” dentro del archivo mailer.js. Para lograr enviar un correo se ha creado una cuenta de gmail para este proyecto. Dentro de la cuenta se genera una contraseña de la aplicación (ver figura 5.21) y se le pasa a la configuración de una variable “transport” (ver figura 5.20) que se usa para enviar el correo. Figura 5.20Variable ”transport” Figura 5.21Contraseña de aplicación Dentro de la función mencionada(ver Figura 5.22) “transport” indica: 1. Correo del destinatario pasado 46 2. Asunto del mensaje 3. El contenido del mensaje en formato HTML. Pasándole el código de verificación. Figura 5.22Función sendVerificationEmail Una vez recibido el correo(ver figura 5.23) el usuario introduce el código en la pantalla y le da a comprobar, si es correcto el usuario accede a la pantalla cargando configuraciones del sistema y por último a la pantalla principal, en caso contrario se le muestra un mensaje de error. En caso de no recibir un correo, el paciente puede darle al botón de volver a enviar el correo y se volverá a hacer una petición al servidor. Si el envío ha ido bien mostrará un mensaje de correo electrónico enviado a “nombre del correo”, en caso 47 contrario mostrará un mensaje de error. Figura 5.23Ejemplo correo de verificación 5.3.1.4 Editar perfil Para editar el perfil del usuario en el móvil, el paciente deberá cambiar los datos de un formulario previamente rellenado por él en el registro. Los datos que se permiten cambiar son: nombre, apellidos, fecha de nacimiento, dirección, código postal y número de teléfono. Como en otros formularios parecidos, como por ejemplo en el registro, todos los datos deben ser válidos. Los datos se envían al servidor a través del controlador que llama al service del paciente mediante el método “registrarPaciente”. En el servidor se realiza una llamada a la base de datos para modificar mediante una llamada UPDATE los datos que tengan el dni del paciente enviado (ver figura 5.24). 48 Figura 5.24Dao pacientes - método editarPaciente Finalmente los datos son modificados en la base de datos y por consiguiente los datos del móvil también cambian. 5.3.1.5 Eliminar Cuenta Para eliminar una cuenta una vez se ha pulsado sobre el botón, se le muestra un diálogo de confirmación a la vista donde si lo acepta, envía una petición al service a través del controlador para que el servidor borre al paciente de la base de datos (ver figura 5.25). Dentro del servidor el router llama al dao para que mediante sentencias DELETE sobre la base de datos se consigan eliminar todos los datos de un paciente en la tablas (ver figura 5.26), si ocurre un error se le muestra un mensaje de error, en caso contrario te redirige a iniciar sesión y elimina la cuenta del “sessionManager” (ver figura 5.27). 49 Figura 5.25Diálogo de confirmación Figura 5.26Llamadas dato bajaPaciente Figura 5.27Llamada API bajaPaciente. 50 5.3.2 Módulo Gestión de Citas Paciente Dentro de esta sección están implementadas las acciones que puede realizar el paciente respecto a la solicitud y administración de citas. 5.3.2.1 Mostrar Citas En la plantilla XML (ver figura 5.28) de la pantalla de citas se destacan dos elementos principales: 1. “CalendarView” para mostrar el calendario del mes, si se hace clic sobre un día mostrará un dialog con la información de la cita más temprana ese día y si no un mensaje de no existen citas ese día. 2. Un “recyclerView”, que utiliza un adapter para mostrar una lista de elementos. Figura 5.28Código XML Mostrar citas Al crear la actividad se manda una petición al servidor a través del Controlador para obtener la lista de citas y enviarla al adaptador usado en el “recyclerView” (ver figura 5.29). 51 Figura 5.29Obtener citas La clase “CitasListAdapter” contiene una clase “ViewHolder” estática que es la encargada de definir el comportamiento de un elemento. En la figura 5.30 se observa: 1. En el método “OnCreateViewHolder” se vincula el adaptador con el holder que va definir el comportamiento del elemento. En este caso “CitasListAdapter.ViewHolder” (clase estática dentro de adapter) que recibe la referencia a la vista XML del ítem que se ve en la figura 5.30. 2. El método “OnBindViewHolder” recibe el índice del elemento de la lista de citas actual y llama al método “bind” del holder para definir un elemento pasándole los datos de ese elemento (clase cita), este método recibe los datos y modifica los dos textView del ítem para que muestren la información de la cita que se le ha enviado(“getNombre_doctor()+ ‘ ‘ + getApellidos_doctor()” y “c.writeDate()”). 52 Figura 5.30Código del adapter de citas Esta clase permite tener una manera personalizada de mostrar una lista de elementos. En este caso no se define una acción cuando se hace clic sobre el ítem, pero más adelante en consultas se mostrará como el holder del adaptador de consultas maneja esa posibilidad. 5.3.2.2 Solicitar Cita El paciente para solicitar una cita ha de rellenar un formulario donde selecciona un doctor de un spinner en el que se le muestran todos los doctores con los que está vinculado, en caso contrario se le mostrará un mensaje de que no existen doctores disponibles para crear una cita. Una vez rellenado los campos fecha, hora y asunto se comprueba que no se manda ningún campo vacío y se envía al service a través del controlador que mediante un método POST envía los datos al servidor. Estos datos son guardados en la tabla de notificaciones con el tipo cita. Una vez finalizado correctamente el guardado en la base de datos, el doctor tendrá accesible la cita para poder aceptarla o rechazarla y en caso que se acepte se le mostrará al usuario la cita en la pantalla de mostrar citas. 53 5.3.3 Módulo Gestión de Tratamientos Paciente 5.3.3.1 Configurar Alarmas Se comienza en el momento en que el doctor ha iniciado un tratamiento, que será explicado más en profundidad en la parte de la web. Una vez creado el tratamiento, la configuración de las alarmas en el móvil comienzan en el momento que el paciente inicie sesión, más concretamente en la actividad “CargandoConfiguracionesActivity”. Esta actividad cuenta con una pantalla de carga que muestra una barra de progreso que dura 5 segundos, dentro de la cual hay una función que inicializa las alarmas del paciente (ver figura 5.31). Figura 5.31CargandoConfiguracionesActivity Dentro del método “initAlarms()” se llevan a cabo tres acciones: 1. ProgressBar (figura 5.32). 54 2. Obtención de las alarmas de la base de datos (figura 5.33). 3. Creación de sub-alarmas (figura 5.34). La barra de progreso es meramente visual (figura 5.32), es una pantalla que aparece justo después del inicio de sesión con el objetivo de que resulte más atractiva visualmente la carga de las alarmas, y de esta manera el paciente es consciente de que en el caso de tener algún tratamiento, las alarmas se configuran al inicio. Figura 5.32CargandoConfiguracionesActivity - método initAlarms() - progressBar En la base de datos no se encuentran todas las alarmas, sólo se encuentran la primera de cada medicamento (figura 5.33). Cada alarma tiene los siguientes campos: id_alarma, id_tratamiento (ya que cada alarma tiene un tratamiento asociado y como se ve en este caso, estas dos alarmas corresponden al mismo tratamiento), medicamento, dosis, hora de la primera toma, tomas al día, fecha de inicio y fecha de fin del tratamiento. Figura 5.33MySQL - Tabla alarmas En la figura 5.34 se realiza una llamada al servidor para que obtenga la información de las alarmas de dicho paciente. También se realiza el parseo de las 61 5. Inicio del reproductor de medios. Se crea una instancia de “MediaPlayer” y se inicia un archivo de audio de alarma “R.raw.alarmclock”. Este reproductor se establece en bucle para reproducir continuamente el sonido de la alarma. 6. Intención de parar el sonido al tocar la notificación ejecutando “stopPendingIntent”. El sonido se detiene al deslizar la notificación, pulsarla o al presionar sobre el botón de “Detener” como se explica en el punto 3. 7. Envío de la notificación. Finalmente, la alarma suena y aparece la notificación (ver figura 5.44) en el móvil. Figura 5.40NotificacionesManager - método lanzarNotificacion 62 Figura 5.41NotificacionesManager - método crearCanalNotificaciones Figura 5.42Notificaciones MedAlerta - Nombre del canal 63 Figura 5.43NotificationButtonReceiver - Método onReceive Figura 5.44Notificación - Notificación recibida. 5.3.4 Módulo Gestión de Consultas Paciente Dentro de esta sección están implementadas las acciones que puede realizar el paciente respecto a la solicitud y administración de citas. 5.3.4.1 Ver Consultas En la pantalla de las consultas, aparecen dos elementos, un “recyclerView” muy parecido al que se ha visto anteriormente y un botón. En este caso, el “recyclerView” en vez de ser de citas, se muestra una lista de las consultas de dicho paciente, para acceder a cada consulta, se pulsa sobre el ítem de la consulta (ver figura 5.45) deseada. Mediante el método “onClick” (ver figura 5.46) de la clase “consultasListAdapter” se puede acceder a una consulta específica mediante el método “navigateToDestinationWithData” del “NavigationManager” pasándole como parámetro la clase que se quiera mostrar (“ChatViewActivity.class”) y la consulta (“e“) que se ha pulsado, que tiene la información de los usuarios que van a comunicarse. 64 Figura 5.45XML - Item de consulta. Figura 5.46ConsultasListAdapter - Método onClick(). El botón “Crear consulta” redirige a una pantalla para la creación de una nueva consulta. 5.3.4.2 Crear Consultas El paciente para crear una consulta debe rellenar un formulario como en el solicitar citas donde selecciona el doctor que desee mediante un spinner en el que se muestran todos los doctores que tiene asignado el paciente, en caso de que no haya doctores, se mostrará un mensaje de que no existen doctores disponibles para crear una consulta. El paciente una vez que elija al doctor deseado, deberá poner un título a dicha consulta, este campo no puede estar vacío, y al crear la consulta se envían los datos desde el controlador hasta al servidor mediante el service con una llamada POST. Estos datos son guardados en la tabla de consultas con el dni del paciente, dni del doctor, el título, la fecha del último mensaje que será en ese momento la fecha en la que se ha creado dicha consulta y los mensajes no leídos por parte del doctor y el paciente que se inicializan a 0. Una vez los datos han sido guardados en la base de datos se mostrará un mensaje de que la consulta se ha creado correctamente. El paciente podrá ver la nueva consulta en la pantalla “Ver consultas”, pudiendo acceder al chat y comunicarse con el doctor. 5.3.4.3 Ver Mensajes Consultas 65 Una vez accedes a un chat, en la parte superior se mostrará el nombre del doctor con el que estás hablando y casi toda la pantalla es ocupada por un “recyclerView” con dos items, los cuales son el mensaje del doctor, y el mensaje del paciente. Ambos elementos están colocados de manera que parezca un chat real, por lo que el mensaje del doctor está colocado en la parte izquierda y el del paciente en la parte derecha alineando a la derecha con “android: layout_gravity=end” (ver figuras 5.47 e 5.48). Figura 5.47Item del mensaje del doctor. Figura 5.48Item del mensaje del paciente. Para determinar qué ítem corresponde a cada usuario (paciente o doctor) es determinado por un atributo de la tabla mensajes llamado propietario. Este atributo indica 1 si el mensaje es del paciente y 0 si el mensaje es del doctor. En la actividad “chatViewActivity” se llama al método “getAllMensajes” del service a través del controller para enviar los datos al servidor y posteriormente hacer una llamada al DAO para traer todos los mensajes de una consulta de la base de datos. Estos mensajes se insertan dentro del adapter que es una instancia de “MensajesListAdapter” y mediante el método “setMensajesList” del adapter (ver figura 5.49), se introducen todos los mensajes para procesarlos. Los mensajes se guardan en una lista de objetos tipo “Mensaje” (ver figura 5.50), donde cada mensaje tiene el id de la consulta a la que pertenece, el mensaje, el propietario y la fecha en la que fue escrito. 66 Figura 5.49ChatViewActivity - Método getAllConsultas() Figura 5.50Clase de un Mensaje 67 Dentro de la clase “MensajesListAdapter”, existe un método llamado “onCreateViewHolder” (ver figura 5.51), donde en función del “viewType” de cada mensaje (que es lo mismo que el propietario) se asigna un ítem, es decir, es aquí donde se diferencia de quién es cada mensaje. Para detectar qué atributo se está pasando (propietario) se sobreescribe una función de “MensajesListAdapter” llamada “getItemViewType()” (ver figura 5.52) que devuelve el propietario de cada mensaje y para que en el método explicado arriba se pueda diferenciar de quién es cada mensaje. Figura 5.51MensajesListAdapter - Método onCreateViewHolder Figura 5.52MensajesListAdapterMétodo getItemViewType El paciente al recibir un mensaje que no ha sido leído, recibe una notificación al móvil. Los mensajes al ser creados tienen dos atributos que se inicializan a 0 (“leido_doctor” y leido_paciente”). En el caso del paciente, el que importa es “leido_paciente”. Si en una consulta hay mensajes que el paciente aún no ha visto, en la pantalla de consultas aparecerá un icono de una campana azul (ver figura 5.53). 68 Para saber qué mensajes no han sido leídos se envía una señal al servidor cada diez segundos que lo compruebe en la clase “NotificarMensajesAsync” (ver figura 5.54). Éstos mensajes se guardan en una lista y si la lista no está vacía, se envía una notificación al móvil (ver figura 5.55), la cual si se pulsa, redirige a la pantalla de las consultas. Figura 5.53Consultas - Icono de notificación de mensajes no leídos Figura 5.54NotificarMensajesAsync - Método onCreate() 69 Figura 5.55Notificación - Mensajes no leídos En la figura 5.56 se observa cómo se guarda el atributo “dni” en SharedPreferences, que permite el almacenamiento de datos simples y persistentes, es decir, guardar datos incluso después de que la aplicación se cierre. De esta manera se consigue que las notificaciones sigan apareciendo, ya que, si se conserve el dni del paciente, se puede acceder a sus consultas y por lo tanto a sus mensajes. Figura 5.56NotificarMensajesAsync - SharedPreferences 70 El atributo “leido_paciente” cambia de valor a 1 en el caso que el paciente entre en una consulta, indicando que esos mensajes ya han sido leídos. Esto se puede ver en el método “ponerMensajesComoLeídos” (punto 1, ver figura 5.57) pasándole como parámetro el dni de paciente y la consulta, para así marcar en leído los mensajes que pertenecen a dicho paciente y a dicha consulta. La información se envía al servidor y se modifica el atributo “leido_paciente” de los mensajes de dicho usuario. El “recyclerView” está configurado para que se muestren los últimos mensajes escritos, no sólo al ver la consulta, sino también tras escribir un mensaje. Esto se hace para que el “recyclerView” actúe como un chat sencillo visualmente y cómodo (punto 2, ver figura 5.57). Los mensajes son instantáneos, es decir, si el doctor escribe un mensaje, al cabo de dos segundos se podrá ver en el chat, ésto sucede por la clase “ActualizarMensajesAsync” (ver figura 5.58) en donde se van recogiendo todos los mensajes cada dos segundos y posteriormente pasarlos al adapter “MensajesListAdapter” para que se mantengan actualizados. De esta manera se consigue refrescar el chat para que se muestre dinámico (ver punto 3 figura 5.57). 77 Figura 6.2Estructura de carpeta private La carpeta “public/” y “views/” contienen archivos que no se usan para el funcionamiento del servidor. Estas carpetas se tratarán más tarde al explicar el front-end de la web. El directorio “routes/” está reservado para ficheros de tipo JavaScript(“.js”) que se encargan de definir las diferentes rutas de la aplicación (ver Figura 6.3). Figura 6.3Estructura de directorio routes El archivo “app.js” crea la instancia de la aplicación express y configura diferentes middlewares, módulos y rutas principales. 78 Los ficheros JavaScript “DAODoctores.js” y “DAOPacientes.js” guardan una clase con variedad de funciones que permiten realizar consultas a la base de datos SQL de sus respectivos usuarios (doctores y pacientes). El archivo “mailer.js” posee información de configuración del correo electrónico que se usa para la verificación de usuarios. El fichero “medAlerta.sql” almacena una copia de la base de datos. Los archivos “ngrok.exe” y “ngrok_recovery_codes.txt” permiten exponer el servidor local de la aplicación a internet. Los archivos “package.json” y “package-lock.json” almacenan meta información de la aplicación node.js como su nombre, versión, dependencias, entre otras cosas. Finalmente cualquier documento de texto llamado “readme.txt” guarda meta información de los archivos de la aplicación. 6.3 Estructura de la Aplicación Web La sección de la parte web de la aplicación es la que se encarga de la parte front-end. Comparte el directorio con el servidor pero solo utiliza la carpeta “public/” y “views/” (ver figura 6.4). 79 Figura 6.4Estructura de ficheros de la aplicación web La carpeta “public/” (ver figura 6.5) contiene recursos que utiliza la aplicación web para su funcionamiento. Esta está compuesta por otras tres carpetas: ● “images/” guarda imágenes de los tipos: “.webp“, “.png“ y “.jpg“ ● “scripts/” almacena ficheros JavaScript(“.js“) con scripts para su posterior uso en las vistas. ● “stylesheets/” es donde se guarda un fichero “.css“ que guarda información para el diseño de las páginas web. 80 Figura 6.5Estructura de la carpeta public La carpeta “views/“ (ver figura 6.6) posee todas las vistas de la página web en archivos de tipo Embedded JavaScript (“.ejs“) Figura 6.6Estructura de la carpeta views 81 6.4 Implementación de la Aplicación Web La implementación de la aplicación web se ha dividido en los módulos o funcionalidades previamente mencionados. Las capturas de las pantallas se podrán visualizar en el manual de usuario doctor con el fin de no repetir las imágenes. 6.4.1 Módulo Gestión de Usuarios Doctor 6.4.1.1 Iniciar Sesión Para iniciar sesión el usuario deberá rellenar un formulario con su dni y contraseña. Esta información recogida en el formulario (ver figura 6.7) se manda a través de un método POST, este método envía la información por el cuerpo del mensaje HTTP. Figura 6.7Formulario inicio de sesión Todas las peticiones al servidor son recogidas por “app.js” y dependiendo de la ruta, “app.js” enruta la llamada y la manda a otro router, en este caso a “doctorRouter” (ver Figura 6.8). 82 Figura 6.8Enrutamiento de app.js Nuevamente el router “doctorRouter” enruta la llamada hacia el router “usuarioRouter” (ver figura 6.9) Figura 6.9Enrutamiento de doctor.js Finalmente el “usuarioRouter” recibe la petición POST. Al recibirla se recoge el dni del doctor y su contraseña, la cual se cifra(ver Figura 6.10) antes de mandar ambos datos al DAO donde hace una llamada SELECT de la tabla doctores para comprobar si existe un usuario con esos datos. En caso de existir se crea la session de usuario para la web y se redirecciona a la página principal, habiéndose ya iniciado la sesión. Si no existe dicho usuario con contraseña en la base de datos se manda al usuario sin iniciar sesión a la página de inicio de sesión y se pasa un mensaje de error que la página detecta y muestra al usuario. 83 Figura 6.10Función de cifrado para contraseñas 6.4.1.2 Registrar El registro de usuario se realiza al igual que el inicio de sesión con un formulario que te pide varios datos: dni, email, contraseña (2 veces para asegurar que se ha insertado la contraseña correcta), nombre, apellidos, fecha de nacimiento, domicilio, código postal y número de teléfono. El formulario hace una llamada POST que tras ser finalmente redirigida al “usuarioRouter”, comprueba que los datos sean válidos (dni sea un dni existente, las contraseñas sean iguales, etc.). Tras comprobar que los datos son correctos se cifra la contraseña al igual que en el inicio de sesión y se hace una llamada al DAO donde se inserta a la tabla doctores. Finalmente se añaden al doctor las enfermedades por defecto guardadas en el fichero “private/data/ enfermedades.json” para que se generen por defecto algunos ejemplos para el doctor. Si durante el proceso de registro se detecta un error en los datos o no se permite añadir el doctor a la base de datos entonces se redirige a la página de registro con un mensaje de error. 6.4.1.3 Editar Perfil Para editar el perfil de usuario, el doctor debe cambiar los datos de un formulario. Los datos que se permiten cambiar son: nombre, apellidos, fecha de nacimiento, domicilio, código postal y número de teléfono. Al igual que en los demás formularios de este apartado, se envían los datos con una llamada POST que viaja hasta “userRouter”. Aquí se comprueba que los datos son válidos, si lo son, estos son actualizados en la base de datos a través de un dao que hace una llamada de UPDATE al usuario. Tras cambiar los datos en la base de datos se cambian también en la sesión actual. Durante la edición 84 del perfil, si ocurren errores se redirige a la página de edición del perfil y se muestra un mensaje de error. 6.4.1.4 Eliminar Cuenta Para eliminar una cuenta el doctor debe pulsar un botón en el navbar que muestra un modal que pregunta por una confirmación para eliminar la cuenta. Si se confirma se genera una llamada GET que acaba en el “doctorRouter” y ejecuta múltiples llamadas al DAO (ver figura 6.11) que realizan operaciones de DELETE de las diferentes tablas donde se almacenan los distintos datos del doctor. Finalmente se redirecciona al inicio. Nótese que en las funciones del DAO se utilizan como parámetro de entrada el dni del usuario de la sesión actual (“req.session.currentUser.dni”). Figura 6.11Llamadas a funciones de bajas de doctor al dao 6.4.2 Módulo Gestión de Asignaciones La gestión de asignaciones se centra en la tabla de la lista de usuarios, donde se muestran los usuarios que un doctor tiene asignado. En esta tabla se permite tanto asignar nuevos pacientes como eliminar antiguos pacientes. Inicialmente en la página web la tabla está vacía pero, al inicializarse o cuando ocurre algún cambio como filtrado, vinculación o desvinculación de un paciente, la tabla se actualiza con JQUERY (ver figura 6.12). Figura 6.12Inicialización de página con script JQUERY Como ya se ha especificado se declaran variables vacías. Para conseguir las variables también se llama a una función que ejecuta una función AJAX (ver figura 6.13) 85 Figura 6.13Función AJAX de obtención y carga de usuarios En esta función se realiza una llamada GET al “doctorRouter” donde se llama al DAO para obtener los pacientes. Luego estos pacientes se formatean para pasarlos como datos “.json” a la llamada AJAX (ver figura 6.14) Figura 6.14Obtención, formateo y envío de datos en formato .json Tras hacer la llamada al router si se ha ejecutado con éxito se ejecuta una función definida en la parte “success” de la función AJAX. En esta parte se guardan los usuarios obtenidos, se carga el buscador y se llama a la función mostrar usuarios,que por cada usuario inserta una fila. Por cada fila se añaden los datos y botones de cada usuario (ver Figura 6.15) 86 Figura 6.15Inserción de fila de datos de usuario en la lista de usuarios Si ocurre algún fallo se ejecuta la parte “error” y se manda un mensaje por consola. 6.4.3 Vincular Médico Paciente La vinculación de cada paciente se hace a través de un botón, que abre un modal con un formulario que pregunta por un dni o correo electrónico del paciente. Al confirmar hace una llamada POST al “doctorRouter”. Este ejecuta una función que comprueba si el dato insertado contiene un carácter “@” perteneciente a un correo electrónico. Dependiendo de esto busca llamando a una función del DAO que comprueba que exista el paciente y obtenga sus datos. Si no se encuentra al paciente con dicho dato se lanza un error que se recoge en la vista y muestra un mensaje de error. Después de obtener los datos del paciente, cuando existe, se llama de nuevo al DAO y se añade el dni del paciente y del doctor a la tabla asignaciones. Finalmente se redirecciona a la página web con la lista de usuarios, lo que los recarga. De esta manera se muestra al nuevo paciente asignado. Si ocurre algún fallo se redirecciona a la página con un mensaje de error. 6.4.4 Desvincular Médico Paciente Al presionar el botón de eliminar al lado de un paciente se ejecuta una función que llama a un enlace con el dni del paciente a eliminar (ver figura 6.16). Dicha llamada llega al “doctorRouter” que a través del DAO elimina la asociación entre el doctor y el 93 Figura 6.23Modal eliminar Además de esto, se ha configurado un evento para que cuando se haga clic en una casilla de un día se mande a la vista diaria de ese día facilitando mucho más la navegación por el calendario al doctor. Después de configurar el calendario, una vez se ha cargado la página, se manda una solicitud AJAX al router de citas que llama al DAO para obtener todas las citas. En el JavaScript se guardan estas en un objeto eventos que es asignado al calendario (ver figura 6.24). 94 Figura 6.24Cargar Citas 6.4.12 Módulo Gestión de Tratamientos Doctor Cuando se quiere añadir un tratamiento a través del botón de la página de funciones de usuario se muestra un modal con un formulario. Este tiene varios campos incluyendo una tabla con varios input. Al final de esta tabla se puede presionar a un botón que agrega una fila a la tabla (ver figura 6.25), la cual te permite añadir un nuevo medicamento. Figura 6.25Botón para agregar filas Al confirmar el formulario se hace una llamada post que llega al router “doctorRouter” que ejecuta una función. En esta primero se comprueba que los datos se han insertado, luego comprueba si hay un único medicamento o varios y dependiendo de esto se ejecuta el código una única vez o varias en un “for()” . El código comprueba que los datos de cada medicamento sean válidos (comprueba que las dosis y tomas al día sean mayor que 0 y que el tratamiento se realice en una fecha 95 posterior a la actual). Si algún dato es inválido se vuelve a la página y devuelve un mensaje de error. Si todos los datos son válidos se hacen dos llamadas al DAO (si hay varios medicamentos se hace una llamada adicional por cada medicamento extra), las cuales ejecutan funciones INSERT en las tablas de tratamiento y alarmas, para su uso en la parte de la aplicación web. Finalmente, si todo se ha ejecutado correctamente, se manda a la página de funciones de usuario con un mensaje de éxito, mientras que si ha ocurrido un error se manda un mensaje de error. 6.4.13 Módulo Gestión de Consultas Doctor 6.4.14 Carga de Consultas Para cargar la página de las consultas se hace una llamada al DAO donde se obtienen las consultas del doctor con su información básica a través de una función SELECT. Cuando se hace clic en una consulta específica, se esconden las consultas y se hace una llamada GET con AJAX. De esta manera se llega al router de “consultaRouter” y se obtienen los mensajes al llamar a una función SELECT del DAO. Estos mensajes se mandan en formato “.json” y se muestran en en un nuevo div que anteriormente estaba escondido. Adicionalmente al entrar en una consulta también se llama a una función POST con “fetch()” que borra las notificaciones de los mensajes del doctor, esto se hace también en la “consultaRouter” donde se actualiza el valor de las notificaciones del doctor a 0 a través de una función UPDATE en el DAO. De esta manera el doctor podrá saber qué mensajes son nuevos y qué mensajes ha leído ya. 6.4.15 Envío de Mensajes Mediante un formulario se pueden enviar mensajes, al igual que en la carga de los mensajes se llama (con una llamada POST) a una función que acaba en el router “consultaRouter” y donde se obtienen al ejecutar un comando INSERT con el nuevo mensaje del doctor. 96 6.4.16 Actualización de Mensajes Una vez se cargan los mensajes al presionar en una consulta concreta, a través de un script se eliminan los mensajes y se vuelven a obtener con una llamada GET en AJAX que llega al “consultaRouter”. Desde aquí se obtienen los mensajes y se muestran nuevamente. De esta manera, el doctor puede verlos en tiempo real sin necesidad de cargar la página de nuevo. 97 Capítulo 7 - Conclusiones y Trabajo Futuro 7.1 Conclusiones En conclusión, en este TFG se ha implementado una aplicación 1 en dos dispositivos diferentes (móvil y web) con el fin de cumplir el objetivo marcado: “elaborar una aplicación capaz de facilitar el uso a pacientes y doctores, mejorando la comunicación entre ambos y optimizando el proceso de atención médica.” Dentro de las marcas que se establecieron para lograr este objetivo, se ha investigado las dificultades y deseñado la aplicación. De tal forma que la aplicación se ha estructurado e implementado los módulos funcionales mencionados para lograrlo, dejando por otro lado para futuro la elaboración de pruebas, garantizar la seguridad, pruebas en un sector real y el análisis de resultados. Referente a la experiencia del usuario se ha llevado a cabo un diseño sencillo y fácil de manipular con el objetivo que la aplicación sea accesible y manipulable por todo tipo de usuarios. 7.2 Trabajo a Futuro En esta sección se van a abordar las funcionalidades o retoques que se han dejado como cambios a futuro después del desarrollo de estos últimos meses. Se van a visualizar en la tabla 3 una serie de cambios a realizar tanto para el dispositivo móvil como para la aplicación web. 1 Repositorio de la aplicación: https://github.com/Antoranz/MedAlerta.git 98 CAMBIOS PLATAFORMA Tema oscuro. Ambos Feedback a los usuarios sobre qué horarios ya han sido reservados para no solicitar una cita en ese intervalo. Móvil Añadir una posibilidad para que los pacientes puedan deshabilitar y habilitar alarmas. Móvil En los mensajes se indique la hora en la que han sido enviados Ambos Distinguir los mensajes en el chat por días. Móvil Buscar una alternativa con webSockets u otras herramientas para actualizar los mensajes. Ambos Subir el servidor a un host en la nube. Ambos Utilizar herramientas de seguridad para ver las vulnerabilidades del código y mejorarlas. Ambos Enviar confirmaciones de citas aceptadas al correo electrónico del paciente. Web Especificar chats no leídos en la notificación. Móvil Recuperar Contraseña. Web Validar correo. Web Hacer más bonito el PDF. Web Usuario Administrador. Web Multiplataforma, que los pacientes puedan realizar las funcionalidades en web y los doctores en móvil también. Ambos Tests automáticos. Ambos Añadir imágenes de perfil de usuario. Ambos Tabla 3Tabla de cambios a futuro.de cambios a futuro. 99 Chapter 7. -Conclusions and future work 7.1 Conclusions In conclusion, in this TFG an application 2 has been implemented on two different devices (mobile and web) in order to meet the objective set: "to develop an application capable of facilitating the use of patients and doctors, improving communication between them and optimizing the medical care process." Within the brands that we set ourselves to achieve this goal, the difficulties have been investigated and the application designed. In such a way that the application has been structured and implemented the functional modules mentioned to achieve this, leaving for the future the elaboration of tests, guaranteeing security, tests in a real sector and the analysis of results. Regarding the user experience, a simple and easy-to-use design has been carried out with the aim of making the application accessible and manipulable by all types of users. 7.2 Future Work In this section we are going to address the functionalities or tweaks that have been left as future changes after the development of these last few months. A series of changes to be made for both the mobile device and the web application will be displayed in Table 4. CHANGES PLATFORM Dark theme. Both Feedback to users about which times have already been reserved so as not to request an appointment in that interval. Mobile Add a possibility for patients to disable and enable alarms Mobile 2 Application Repository: https://github.com/Antoranz/MedAlerta.git 100 Messages indicate the time they were sent. Both Distinguish messages in chat by days. Mobile Search an alternative with webSockets or other tools to update messages. Both Upload the server to a cloud host. Both Use security tools to see code vulnerabilities and improve them. Both Send confirmations of accepted appointments to the patient's email. Web Specify unread chats in the notification. Mobile Recover password. Web Validate email. Web Make the PDF more beautiful. Web User Administrator. Web Multiplatform, so that patients can perform the functionalities on the web and doctors can also perform the functions on mobile phones. Both Automatic tests. Both Add user profile images. Both Tabla 4Table of future changes. f future changes. 101 CONTRIBUCIONES PERSONALES Francisco Javier Antoranz Esteban Durante los primeros dos meses el alumno estuvo investigando, documentando y registrándose en firebase para poder realizar una primera implementación de la web. Después de un proceso tedioso con una documentación desactualizada, se decidió por abandonar firebase y hacer el proyecto en local con Xampp. El alumno participó en la elaboración del registro e inicio de sesión del móvil donde se investigó acerca del funcionamiento de cómo mantener una sesión iniciada, aunque se mantenga cerrada la aplicación (utilizando sharedPreferences). Javier se implicó en la elaboración e investigación del uso de la librería de mailer.js para enviar correos electrónicos desde la cuenta “med[email protected]” a los usuarios de la aplicación. Se visualizaron una serie de videos que ayudaron a la configuración de la cuenta de google y a la creación del código JavaScript para poder configurarlo correctamente. Ligado al funcionamiento del correo, se colaboró en la recuperación de la contraseña y la validación del correo al iniciar sesión en la aplicación móvil donde también se utilizó mailer.js para enviar códigos de seguridad al usuario. En la aplicación web el alumno desarrolló: los tratamientos; la funcionalidad del listado de usuarios y sus búsquedas por sus diferentes atributos (nombre,DNI, apellidos,etc); el diseño de la vista de editar perfil; brevemente en una primera plantilla para la creación de un historial (vista “.ejs”), donde se estuvo investigando en una primera instancia en como guardar estos PDFs en firebase; y participó en una primera parte en el diseño global de la aplicación web. Para poder realizar estas funcionalidades, se investigó acerca del funcionamiento de Bootstrap para lograr una aplicación responsive. 102 Francisco investigó acerca del funcionamiento de la librería de JavaScript Full Calendar, leyendo su documentación y aplicándolo para poder ver las citas que un doctor tenía al día, a la semana y al mes. El alumno participó en el diseño y la elaboración de la creación y la aceptación de una cita donde debido a unos problemas que sucedieron con las validaciones de las fechas, el alumno tuvo que crear un procedimiento en Xampp para poder solucionarlo. Con relación al móvil el alumno participó en el diseño general y la estructura de la aplicación. El alumno se basó en el modelo de vista controlador aprendido en la universidad para poder aportar una estructura al proyecto basado en este modelo. Javier se encargó de la separación de las funcionalidades en el móvil aislando el código situado en las actividades en otras carpetas o paquetes en función de donde le correspondiera, con el objetivo de llevar a cabo un buen desarrollo software y aislar las clases útiles, las peticiones del servidor y otras funcionalidades de las vistas. Con relación al diseño Francisco se encargó de investigar el funcionamiento de los fragments y de la creación de los menús y botón navbar visualizando diferentes videos de youtube y mirando la teoría aprendida en la optativa de PAD. En este proceso adaptó todas las clases activities a fragments teniendo que cambiar el funcionamiento de la gestión de las pantallas. Con respecto a las consultas el estudiante participó en el diseño de las consultas, donde se investigó acerca del funcionamiento de los “RecyclerView” y Adapters que tanto se usa en la aplicación. Participando en la implementación de estas clases para poder mostrar esta lista de mensajes y refrescar los mensajes cada poco tiempo. El universitario desarrolló la vista de mostrar citas donde se investigó para poder mostrar un calendario parecido al de la web donde le aparecen al paciente los días que tiene una cita marcados. Después de una serie de problemas con compatibilidad de librerías el estudiante decidió hacer una lista de citas y mostrar un calendario. El alumno participó en la investigación de las llamadas API desde la aplicación móvil y web con el objetivo de poder recibir y mandar información a la base de datos. 109 [18] Visual Studio Code: https://code.visualstudio.com/ [19] Android Studio: https://developer.android.com/?hl=es-419 [20] MySql: https://www.mysql.com/ [21] Xampp: https://www.apachefriends.org/es/index.html 110 APÉNDICES Apéndice A - Casos de Uso Durante este capítulo, se expondrán los diferentes casos de uso que se han presentado en la aplicación, así como la forma de actuar de los actores en estos. Actores En el modo en el que se interactúa con la aplicación se distinguen tres tipos de usuarios: el paciente, el doctor y el usuario no registrado. El paciente es un usuario que busca atención y asistencia médica continua. El paciente disfruta de la aplicación en formato app de móvil, e interactúa con esta solicitando citas, enviando consultas a doctores y recibiendo alarmas y notificaciones. El doctor es un profesional de salud que ofrece sus servicios a través de la aplicación facilitando una comunicación cercana y continua con el paciente. El doctor usando la plataforma puede gestionar su agenda de citas, configurar tratamientos y proporcionar asesoramiento médico. Diagrama de Casos de Uso En este punto, se exponen los casos de uso que describen las diferentes interacciones que pueden realizar cada actor dentro de la aplicación. Se han organizado de tal manera que cada diagrama representa una funcionalidad en específico. Gestión Usuarios La Gestión de Usuarios se centra en las acciones que pueden realizar tanto los doctores como los pacientes a la hora de gestionar y administrar sus perfiles. En este módulo ambos actores pueden realizar las mismas acciones visibles en la figura A.1. 111 Figura Apéndice A-1Diagrama Gestión de Usuarios Gestión de Historial Médico La Gestión de Historial Médico se basa en las acciones que tienen a su disposición los doctores para documentar y guardar un historial con datos médicos relevantes para el doctor. Desde la página web el doctor necesita estar vinculado a un paciente para poder crear un historial médico de dicho paciente. Adicionalmente el doctor podrá añadir detalles a dicho historial a lo largo del tiempo. Estas interacciones se ilustran en la figura A.2. 112 Figura Apéndice A-2Diagrama de Gestión de Historial Médico Gestión de Citas La Gestión de Citas se enfoca en las acciones que pueden realizar tanto los doctores como los pacientes para programar y gestionar sus citas médicas. Dentro de la aplicación el usuario necesita estar vinculado a un doctor para poder solicitar una cita, y a su vez, el doctor necesita estar asociado a un paciente para poder crearle una cita. Estas interacciones se ilustran en la figura A.3 113 Figura Apéndice A-3Diagrama de Gestión de Citas Gestión de Tratamientos La Gestión de Tratamientos pone énfasis en las acciones que pueden realizar los doctores para programar un tratamiento a un paciente y la gestión de ese tratamiento para configurar alarmas para las tomas de medicamentos a los pacientes. Dentro de la aplicación el doctor necesita estar asociado a un paciente para poder añadirle un tratamiento. Estas interacciones se ilustran en la figura A.4 114 Figura Apéndice A-4Diagrama de Gestión de Tratamientos Gestión de Consultas La Gestión de Consultas se focaliza en las acciones que pueden realizar tanto los doctores como los pacientes para poder recibir y enviar mensajes sobre una consulta o tema. Dentro de la aplicación el paciente necesita estar vinculado a un doctor para poder crear una consulta. Estas interacciones se ilustran en la figura A.5 115 Figura Apéndice A-5Diagrama Gestión de Consultas Especificación de requisitos En este punto, se exponen las diferentes especificaciones de requisitos que describen las diferentes interacciones que pueden realizar cada actor dentro de la aplicación. Gestión Usuarios La Gestión de Usuarios se centra en las acciones que pueden realizar tanto los doctores como los pacientes a la hora de gestionar y administrar sus perfiles. En este módulo se distinguen una serie de requisitos diferentes dependiendo de la plataforma donde se implementan, en web (doctores) y en móvil (pacientes) Registro 116 La Tabla 5 muestra los requisitos para el registro de un doctor y la Tabla 6 para los de un paciente. Requisito Registro Doctor Identificador 1.1.1 Prioridad Alta Precondición El usuario debe acceder al registro desde la plataforma web. Descripción Los usuarios no registrados pueden registrarse, solo una cuenta por DNI. Entrada DNI, nombre, apellidos, contraseña, repetir contraseña, correo electrónico, domicilio,código Postal, número de Teléfono, fecha de Nacimiento. Salida Mensaje de error o redirige a Inicio de Sesión Secuencia normal Paso Acción 1 El usuario accede a la página web y pulsa en el enlace: “Crear una cuenta”. 2 El sistema muestra una pantalla en la que le pide al usuario todos los campos necesarios para crear un usuario. 3 El usuario rellena todos los campos y hace clic en registrar usuario. 4 El sistema valida la información y la guarda. 5 Muestra de nuevo la pantalla principal, o un error si no pasa las validaciones. PostCondición Se ha creado la cuenta de usuario tipo doctor. Excepciones Paso Acción 3 Se muestra el mensaje correspondiente si las contraseñas no coinciden. 117 3 Se muestra el mensaje correspondiente si el correo electrónico no cumple con los requisitos. 3 Se muestra un mensaje de error si hay algún campo vacío. 4 Se muestra el mensaje correspondiente si el correo electrónico o el ya hay una cuenta registrada con ese dni 4 Se muestra un mensaje de error si no supera las validaciones (Formato DNI,fecha de nacimiento inferior a la fecha actual, número de teléfono). Comentarios NA. Actores Usuario no registrado Tabla 5Tabla de requisitos registrar doctor Requisito Registro Paciente Identificador 2.1.1 Prioridad Alta Precondición El usuario debe acceder al registro desde la plataforma móvil. Descripción Los usuarios no registrados pueden registrarse, solo una cuenta por DNI. Entrada DNI, nombre, apellidos, contraseña, repetir contraseña, correo electrónico, domicilio,código Postal, número de Teléfono, fecha de Nacimiento. Salida Mensaje de error o redirige a Inicio de Sesión Secuencia normal Paso Acción 1 El usuario inicia el dispositivo móvil y pulsa en el enlace: “Crear una cuenta”. 2 El sistema muestra una pantalla en la que le pide al usuario todos los campos necesarios para crear un usuario. 3 El usuario rellena todos los campos y hace clic en registrar 118 usuario. 4 El sistema valida la información y la guarda. 5 Muestra de nuevo la pantalla de inicio de sesión, o un error si no pasa las validaciones. PostCondición Se ha creado la cuenta de usuario tipo paciente. Excepciones Paso Acción 3 Se muestra el mensaje Toast correspondiente si las contraseñas no coinciden. 3 Se muestra el mensaje Toast correspondiente si el correo electrónico no cumple con los requisitos. 4 Se muestra el mensaje Toast correspondiente si el correo electrónico o el ya hay una cuenta registrada con ese dni 4 Se muestra un mensaje Toast si hay algún campo vacío. 4 Se muestra un mensaje TOAST si no supera las validaciones (Formato DNI,fecha de nacimiento inferior a la fecha actual, número de teléfono). Comentarios NA. Actores Usuario no registrado Tabla 6Tabla de requisitos registrar paciente Iniciar Sesión La Tabla 7 muestra los requisitos para el inicio de sesión de un doctor y la Tabla 8 para los de un paciente. Requisito Inicio sesión doctor Identificador 1.1.2 Prioridad Alta 125 1 Llegada a la pantalla de recuperar contraseña, se debe introducir la nueva contraseña y el código enviado al correo. 2 Si el código no se ha recibido, se deberá pulsar en ‘Reenviar correo’ para que se vuelva a enviar. 3 Una vez introducido el código y la contraseña, se pulsa en ‘Cambiar contraseña’. PostCondición El usuario ha cambiado su contraseña y es redirigido a la pantalla de inicio de sesión. Excepciones Paso Acción 1 Se muestra el mensaje correspondiente si las credenciales son incorrectas Comentarios NA Actores Usuario registrado como paciente Tabla 12Tabla de requisitos validar cuenta paciente Eliminar cuenta La Tabla 13 muestra los requisitos para eliminar la cuenta de un doctor y la tabla 14 para los de un paciente. Requisito Eliminar doctor Identificador 1.1.6 Prioridad Baja Precondición El doctor debe estar en la página web y logedo. Descripción Los doctores registrados deben poder eliminar su cuenta en la web. Entrada NA Salida Redirigir a iniciar sesión. Secuencia normal Paso Acción 126 1 El usuario accede a la página web logueada, hace clic en las opciones de gestión de usuario y le da a eliminar cuenta. 2 Acepta el modal de eliminar cuenta 3 El sistema redirige a la pantalla de inicio de sesión. PostCondición El doctor ha eliminado su cuenta Excepciones Paso Acción 2 Si le da a rechazar el modal se mantiene el estado actual en la web. Comentarios NA Actores Usuario iniciado como doctor Tabla 13Tabla de requisitos eliminar cuenta doctor. Requisito Eliminar cuenta paciente Identificador 2.1.6 Prioridad Baja Precondición El paciente debe estar en la aplicación móvil y logedo. Descripción Los pacientes registrados deben poder eliminar su cuenta en la web. Entrada NA Salida Redirigir a iniciar sesión. Secuencia normal Paso Acción 1 El paciente accede al móvil logueado, hace clic en el menú de opciones de arriba a la derecha y le da a eliminar cuenta. 127 2 Acepta el Dialog de confirmación. 3 El sistema redirige a la pantalla de inicio de sesión. PostCondición El paciente ha eliminado su cuenta Excepciones Paso Acción 2 Si se da a rechazar el Dialog se mantiene el estado actual de la aplicación. Comentarios NA Actores Usuario iniciado como paciente Tabla 14Tabla de requisitos eliminar cuenta paciente Gestión asignaciones La Gestión de Asignaciones se encarga de la vinculación y desvinculación de un paciente con un doctor. Esta vinculación es realizada por el doctor. Si se desea realizar una funcionalidad sobre un paciente debe existir una vinculación. Vincular médico paciente La Tabla 15 muestra los requisitos para la vinculación de un doctor y un paciente. Requisito Vincular médico paciente Identificador 1.2.1 Prioridad Alta Precondición El doctor debe acceder a la página de gestión de usuarios. Descripción El doctor debe poder añadir un paciente a su lista. 128 Entrada DNI o correo Salida Mensaje de éxito o error. Secuencia normal Paso Acción 1 El usuario accede a gestión de pacientes y hace clic en “Añadir Usuario”. 2 El sistema muestra un modal en el que se le pide al doctor que introduzca un DNI o un correo. 3 El sistema valida la información y agrega el paciente a la lista. PostCondición Se ha agregado el paciente a la lista de usuarios. Excepciones Paso Acción 3 Se muestra el mensaje correspondiente si no se ha encontrado el usuario con ese correo o DNI. 3 Se muestra el mensaje correspondiente si el usuario ya está en la lista. Comentarios NA. Actores Doctor Tabla 15Tabla de requisitos para vincular médico paciente. Desvincular médico paciente La Tabla 16 muestra los requisitos para la desvinculación de un doctor y un paciente. Requisito Desvincular médico paciente Identificador 1.2.2 Prioridad Alta Precondición El doctor debe acceder a la página de gestión de usuarios. 129 Descripción El doctor debe poder eliminar un paciente de su lista. Entrada NA. Salida Mensaje operación correcta Secuencia normal Paso Acción 1 El usuario accede a gestión de pacientes, busca el paciente que desea y hace clic en “Eliminar”. 2 El sistema recibe la información y refresca la vista dando un mensaje de operación exitosa. PostCondición Se ha eliminado el paciente de la lista de usuarios. Excepciones Paso Acción 2 Si se produce un error interno, se muestra un mensaje de error. Comentarios NA. Actores Doctor Tabla 16Tabla de requisitos para desvincular médico paciente. Gestión historial médico La Gestión de Historial Médico se basa en las acciones que tienen a su disposición los doctores para documentar y guardar un historial con datos médicos relevantes del paciente para determinar un mejor diagnóstico. Desde la página web el doctor necesita estar vinculado a un paciente para poder crear un historial médico de dicho paciente. Adicionalmente el doctor podrá añadir detalles a dicho historial a lo largo del tiempo. Crear/Modificar historial médico La Tabla 17 muestra los requisitos para la creación de un historial médico de un doctor. 130 Requisito Crear/modificar historial médico Identificador 1.3.1 Prioridad Media Precondición El doctor debe estar registrado y debe tener asignado un paciente Descripción El doctor crea o modifica un historial médico a un paciente. Entrada nombre, apellidos, sexo, fecha de nacimiento, peso, altura, marcar las casillas que corresponden a las enfermedades que padece el paciente si tuviera alguna, escribir alergias si tuviera, escribir notas si fueran necesarias y comentar detalles si fueran necesario Salida Mensaje de error o redirige a la pantalla de gestión de usuarios del doctor Secuencia normal Paso Acción 1 El usuario accede a la página web y en el menú pulsa el apartado ‘Gestión Usuarios’ 2 El doctor selecciona el botón ‘Funciones Paciente’ del paciente que desee. 3 En dicho menú, selecciona ‘Crear historial médico’. 4 A continuación se procede a rellenar todos los datos relevantes del paciente y se puede crear una nueva enfermedad en el caso de que la que padezca no se encuentre entre las opciones predeterminadas. 5 Cuando esté rellenado el formulario, el doctor debe pulsar ‘Generar PDF’ y el doctor será redirigido al menú de gestión de usuarios PostCondición Se ha generado un PDF con la información del paciente en él. Excepciones Paso Acción 4 Se muestra el mensaje correspondiente si algún campo está vacío 131 Comentarios NA. Actores Doctor registrado Tabla 17Tabla de requisitos para crear/modificar historial médico Ver historial médico La Tabla 18 muestra los requisitos para que un doctor pueda visualizar un historial médico de un paciente. Requisito Ver historial médico Identificador 1.3.2 Prioridad Media Precondición El doctor debe estar registrado y debe tener asignado un paciente Descripción El doctor visualiza el historial médico de un paciente. Entrada NA. Salida Se muestra un pdf con el historial médico del paciente. Secuencia normal Paso Acción 1 El usuario accede a la página web y en el menú pulsa el apartado ‘Gestión Usuarios’ 2 El doctor selecciona el botón ‘Funciones Paciente’ del paciente que desee. 3 En dicho menú, seleccione ‘Ver historial médico’. 4 A continuación se descarga y se muestra un pdf que contiene la información correspondiente al historial médico de dicho paciente. PostCondición Se muestra un PDF con la información del paciente en él. 132 Excepciones Paso Acción 4 Si se produce un error interno, se muestra un mensaje de error. Comentarios NA. Actores Doctor registrado Tabla 18Tabla de requisitos para ver historial médico Añadir detalles al historial médico La Tabla 19 muestra los requisitos para que un doctor pueda añadir detalles al historial médico de un paciente. Requisito Añadir detalles a un historial médico Identificador 1.3.3 Prioridad Media Precondición El doctor debe estar registrado, debe tener asignado un paciente y haber creado un historial médico a dicho paciente. Descripción El doctor puede añadir detalles al historial médico de un paciente. Entrada Detalle que se desee añadir al historial médico. Salida Se te redirigirá a la pantalla de gestión de usuarios al tener éxito. Secuencia normal Paso Acción 1 El usuario accede a la página web y en el menú pulsa el apartado ‘Gestión Usuarios’ 2 El doctor selecciona el botón ‘Funciones Paciente’ del paciente que desee. 3 En dicho menú, selecciona ‘Añadir detalles al historial médico’. 133 4 A continuación, le das al botón ‘guardar’ para que se guarde dicho comentario en el historial médico, o a ‘cancelar’ si no deseas que se guarde. PostCondición Se añade un detalle al historial médico de dicho paciente. Excepciones Paso Acción 4 Si se produce un error interno, se muestra un mensaje de error. Comentarios NA. Actores Doctor registrado Tabla 19Tabla de requisitos para añadir detalles al historial médico Eliminar historial médico La Tabla 20 muestra los requisitos para que un doctor pueda eliminar el historial médico de un paciente. Requisito Eliminar historial médico Identificador 1.3.4 Prioridad Media Precondición El doctor debe estar registrado, debe tener asignado un paciente y haber creado un historial médico a dicho paciente. Descripción El doctor puede eliminar el historial médico de un paciente Entrada NA. Salida Mensaje de historial médico eliminado exitosamente. Secuencia normal Paso Acción 134 1 El usuario accede a la página web y en el menú pulsa el apartado ‘Gestión Usuarios’ 2 El doctor selecciona el botón ‘Funciones Paciente’ del paciente que desee. 3 En dicho menú, selecciona ‘Eliminar historial médico’. PostCondición Se elimina el historial médico de un paciente. Excepciones Paso Acción 3 Si se produce un error interno, se muestra mensaje de error. Comentarios NA. Actores Doctor registrado Tabla 20Tabla de requisitos para eliminar el historial médico de un paciente Gestión de Citas La Gestión de Citas se focaliza en las acciones que pueden realizar tanto los doctores como los pacientes a la hora de gestionar y administrar sus citas médicas.Se necesita una vinculación existente entre paciente y doctor para poder agregar una cita a un paciente con ese doctor. Solicitar cita La Tabla 21 muestra los requisitos para que un paciente pueda solicitar una cita. Requisito Solicitar cita Identificador 2.4.1 Prioridad Media