Desarrollo de aplicación para implementar algoritmos diagnósticos de urgencias hospitalarias

Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Desarrollo de aplicación para implementar algoritmos diagnósticos de urgencias hospitalarias Autor: Francisco Javier Márquez Lavado Tutor: José Manuel Fornés Rumbao Dpto. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2024 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Desarrollo de aplicación para implementar algoritmos diagnósticos de urgencias hospitalarias Autor: Francisco Javier Márquez Lavado Tutor: José Manuel Fornés Rumbao Profesor titular Dpto. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2024 Trabajo Fin de Grado: Desarrollo de aplicación para implementar algoritmos diagnósticos de urgencias hospitalarias Autor: Francisco Javier Márquez Lavado Tutor: José Manuel Fornés Rumbao El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2024 El Secretario del Tribunal 7 A mi familia A mis maestros 9 Agradecimientos Tras varios años de esfuerzo y dedicación, finalmente ha llegado el momento de cerrar esta etapa, una meta que un día un niño soñó cumplir y que, a pesar de iniciarla con algunas incertidumbres, tenía la confianza de que el resultado iba a ser positivo. Por ello, me gustaría aprovechar este espacio para mencionar y agradecer a aquellas personas que me han acompañado durante este viaje. En primer lugar, quiero expresar mi profunda gratitud a mis padres por su constante apoyo a lo largo de todo este proceso y por el esfuerzo que han realizado para que yo pudiera llegar hasta aquí. Este logro también les pertenece. Asimismo, agradecer también a mis amigos por haber compartido con ellos los mejores momentos de este periodo, tanto a los de toda la vida del pueblo como a los que he conocido durante la carrera. En especial, quiero agradecer a estos últimos por haber sido unos compañeros excelentes, siempre dispuestos a ayudar y que me han servido de inspiración a lo largo del camino. Sin ellos, hubiera sido mucho más complicado. Ahora, con nuevos horizontes por delante, me despido de esta etapa satisfecho y agradecido por todo lo aprendido. Aunque el viaje no siempre ha sido fácil, cada desafío ha sido una oportunidad para crecer y superarse. Gracias a todos por ser parte fundamental de este viaje. Francisco Javier Márquez Lavado Sevilla, 2024 4 Conclusiones y trabajos futuros ................................................................................................................... 89 4.1 Conclusiones .............................................................................................................................................. 89 4.2 Trabajos futuros ........................................................................................................................................ 89 Referencias ............................................................................................................................................................... 91 Glosario ..................................................................................................................................................................... 93 17 ÍNDICE DE FIGURAS Figura 1-1. Capturas de pantalla de Calculate by QxMD en App Store. 23 Figura 1-2. Capturas de pantalla de MDCalc en App Store 24 Figura 1-3. Capturas de pantalla de Epocrates en App Store. 24 Figura 2-1. Logo y eslogan de React Native. 26 Figura 2-2. Esquema general del rol de React Native. 27 Figura 2-3. Esquema de la comunicación desde los hilos JavaScript y hasta los nativos en iOS. 27 Figura 2-4. Esquema de la comunicación desde los hilos JavaScript y hasta los nativos en Android. 27 Figura 2-5. Logo de Expo 28 Figura 2-6. Captura de pantalla con Expo CLI arrancado. 29 Figura 2-7. Captura de pantalla de Expo Go. 30 Figura 3-1. Captura en Android del menú inicial. 36 Figura 3-2. Captura en Android del menú de protocolos. 37 Figura 3-3. Captura en Android del menú de protocolos, con el grupo “dolor” desplegado. 38 Figura 3-4. Captura en Android de la pantalla de anamnesis sin rellenar. 39 Figura 3-5. Captura en Android de la pantalla de anamnesis con las opciones desplegadas para el sexo, edad y enfermedades previas. 39 Figura 3-6. Captura en Android de la pantalla de anamnesis ya completa. 40 Figura 3-7. Capturas en Android de las pantallas con el protocolo en proceso. 41 Figura 3-8. Captura en Android de la pantalla del protocolo con el filtro de parámetros desplegado. 42 Figura 3-9. Capturas en Android del botón de información en la instrucción y su ventana emergente. 43 Figura 3-10. Capturas en Android del botón de información en las opciones y su ventana emergente. 43 Figura 3-11. Captura en Android de la pantalla con el protocolo finalizado. 44 Figura 3-12. Capturas en Android con el ID del diagnóstico guardado mostrado y seleccionado. 45 Figura 3-13. Captura en Android de la pantalla inicial del historial de diagnósticos. 46 Figura 3-14. Captura en Android de la pantalla de historial de diagnósticos con el diagnóstico sin estado. 47 Figura 3-15. Captura en Android de la pantalla de historial de diagnósticos con el diagnóstico con estado éxito. 48 Figura 3-16. Captura en Android de la pantalla de historial de diagnósticos con el diagnóstico con estado error. 48 Figura 3-17. Captura en Android de la pantalla de historial de diagnósticos cuando no se ha encontrado diagnóstico con el código de identificación introducido. 49 Figura 3-18. Diagrama C4 de la arquitectura general de la aplicación. 50 Figura 3-19. Diagrama de actividad de la pantalla Menú inicial. 51 Figura 3-20. Diagrama de actividad de la pantalla Lista de protocolos. 52 Figura 3-21. Diagrama de actividad de la pantalla Protocolo. 53 Figura 3-22. Diagrama de actividad de la pantalla Historial de diagnósticos. 54 Figura 3-23. Captura de Cloud Firestore de la colección “historial_usos”. 55 Figura 3-24. Captura de Cloud Firestore de la colección “protocolos”. 56 Figura 3-25. Diagrama con la llamada a la BBDD para recibir el protocolo del dolor torácico. 56 Figura 3-26. Diagrama con la llamada a la BBDD para recibir todos los diagnósticos guardados del dolor torácico realizados a mujeres. 56 Figura 3-27. Diagrama con la llamada a la BBDD para guardar los datos del diagnóstico final. 56 Figura 3-28. Diagrama con las llamadas a la BBD para recibir un diagnóstico con el ID correspondiente y establecer su resultado final como correcto. 57 Figura 3-29. Diagrama de los componentes de la aplicación y su relación. 57 Figura 3-30. Esquema del contenido de App.js 58 Figura 3-31. Esquema del contenido de MainMenuScreen.js 59 Figura 3-32. Formato de protocol_list.json 59 Figura 3-33. Esquema del contenido de ProtocolListScreen.js 60 Figura 3-34. Esquema del contenido de ProtocolScreen.js 61 Figura 3-35. Esquema del contenido de DiagnosisHistoryScreen.js 61 Figura 3-36. Esquema del contenido de CardDiagnosis.js 62 Figura 3-37. Esquema del contenido de CardMenu.js 63 Figura 3-38. Esquema del contenido de FirebaseAccess.js 63 Figura 3-39. Capturas del componente CardMenu. 64 Figura 3-40. Captura de CardDiagnosis cuando el resultado del diagnóstico no se ha indicado aún. 65 Figura 3-41. Capturas de CardDiagnosis con diagnósticos correctos y erróneos. 65 Figura 3-42. Capturas de Overlay con el botón de información en la instrucción. 66 Figura 3-43. Capturas de Overlay con el botón de información en las opciones. 67 Figura 3-44. Capturas de RNPickerSelect en el campo de sexo. 68 Figura 3-45. Capturas de RNPickerSelect en el campo de edad. 68 Figura 3-46. Capturas de RNPickerSelect en el campo de enfermedad previa. 69 Figura 3-47. Colección de iconos utilizados en la aplicación. 70 Figura 3-48. Imágenes usadas para rellenar los botones del menú de inicio. 71 Figura 3-49. Estructura de directorios del proyecto. 72 Figura 3-50. Diagrama que representa cómo se recopilan los pasos que se han tomado durante el protocolo. 73 Figura 3-51. Captura que señala el texto tomado del campo “question” del protocolo JSON. 74 Figura 3-52. Estructura inicial del protocolo “dolor torácico” en formato JSON. 74 Figura 3-53. Captura que señala los textos tomados de los campos “answer” de las opciones. 75 Figura 3-54. Estructura del campo “options” del protocolo en formato JSON. 76 Figura 3-55. Captura de pantalla con el resultado y su correspondiente campo “options” sin opciones. 76 Figura 3-56. Índice con algunas de las dolencias que trata el libro de protocolos usado. 77 Figura 3-57. Diagrama del protocolo de dolor torácico del libro de protocolos usado. 78 Figura 3-58. Índices con explicaciones relativas al protocolo de dolor torácico del libro de protocolos usado. 79 19 Figura 3-59. Captura de Visual Studio Code con el proyecto abierto. 80 Figura 3-60. Captura del fichero package.json con las versiones de Expo y React Native usadas. 81 Figura 3-61. Captura del instalador de Android Studio con la ventana para seleccionar los componentes a instalar. 82 Figura 3-62. Captura del instalador de Android Studio con la ventana para indicar la ruta de instalación. 82 Figura 3-63. Captura del instalador de Android Studio con la última ventana para finalizar la instalación. 83 Figura 3-64. Captura de Android Studio que señala el botón para abrir el administrador de dispositivos. 83 Figura 3-65. Captura de Android Studio que señala el botón para añadir un nuevo dispositivo desde el administrador de dispositivos. 84 Figura 3-66. Captura del Device Manager de Android Studio con el listado de dispositivos disponibles. 84 Figura 3-67. Captura de Android Studio que señala el botón para iniciar el emulador del dispositivo. 85 Figura 3-68. Captura de la web de Expo Go que señala la versión a seleccionar y el botón a pulsar para iniciar el proceso de instalación. 85 Figura 3-69. Captura de la web de Expo Go que señala el botón a pulsar para descargar el archivo apk. 86 Figura 3-70. Captura del terminal con Expo arrancado que señala la dirección a la que conectarse desde Expo Go. 86 Figura 3-71. Capturas de Expo Go en el emulador Android con la pantalla donde introducir la URL y ya con la aplicación ejecutándose tras pulsar en conectar. 87 21 1 INTRODUCCIÓN ace no mucho tiempo, la búsqueda de información requería consultar libros y enciclopedias físicas, lo cual limitaba el acceso a conocimientos y la rapidez de obtención de datos. En aquellos días, los ordenadores y dispositivos móviles no estaban tan extendidos como lo están hoy en día. Sin embargo, con la expansión del uso de Internet y la proliferación de dispositivos portátiles, se ha abierto un nuevo mundo de posibilidades. Esta transformación digital ha permitido un acceso instantáneo a una cantidad prácticamente infinita de información, conectando personas y recursos a nivel global. Además, la irrupción de la inteligencia artificial ha potenciado aún más estas capacidades, ofreciendo herramientas avanzadas para la gestión de datos, la automatización de procesos y la toma de decisiones. La IA no solo ha transformado sectores tradicionales, sino que también está abriendo nuevos horizontes en áreas como la medicina, la educación y la industria, prometiendo un futuro lleno de innovaciones y oportunidades. Este contexto de cambio constante y avance tecnológico es el marco en el cual se sitúa el presente proyecto, que explora las posibilidades y retos de desarrollar una aplicación móvil enfocada al ámbito de la salud. 1.1 Motivación La motivación detrás del desarrollo de esta aplicación surge de la necesidad de optimizar y agilizar la atención en las consultas de urgencias hospitalarias. En un entorno donde cada segundo cuenta, los profesionales sanitarios requieren herramientas que les permitan tomar decisiones rápidas y precisas. La idea de crear una aplicación que asista en la aplicación de protocolos de actuación nace de la observación de las dificultades que enfrentan médicos y enfermeros para gestionar de manera eficiente el flujo de pacientes y garantizar que se sigan los procedimientos adecuados. Con el fin de mejorar la calidad del servicio y reducir el margen de error, esta aplicación proporciona una interfaz intuitiva y accesible que guía al profesional sanitario a través de cada paso de los protocolos de actuación. El uso de datos históricos y la posibilidad de realimentar el sistema con cada uso permite que los porcentajes mostrados en las opciones se ajusten dinámicamente, proporcionando una referencia estadística basada en casos similares anteriores. Esto no solo facilita la toma de decisiones informadas, sino que también abre la puerta a futuros desarrollos donde la inteligencia artificial podría jugar un papel crucial en la optimización de estos protocolos. Además, la funcionalidad de registrar y revisar diagnósticos permite a los profesionales de la salud identificar patrones y evaluar la efectividad de las decisiones tomadas, contribuyendo a una mejora continua de los protocolos. Esta capacidad de aprendizaje y adaptación es esencial en un campo tan dinámico y vital como el de H Una máquina puede hacer el trabajo de cincuenta hombres ordinarios. Ninguna máquina puede hacer el trabajo de un hombre extraordinario. Elbert Hubbard Introducción 22 las urgencias hospitalarias. De esta forma, el proyecto busca ofrecer una herramienta robusta y adaptable que mejore significativamente la eficiencia y eficacia de los servicios de urgencias, contribuyendo a salvar vidas y a elevar la calidad del cuidado médico. 1.2 Alcance El desarrollo de la aplicación ha abarcado diversas áreas fundamentales para garantizar su funcionalidad y utilidad en el entorno de las urgencias hospitalarias. En primer lugar, se ha implementado un apartado dedicado a la muestra del listado de protocolos de actuación disponibles, organizados en grupos de dolencias (p. ej. dolor, hemorragia, palpitaciones, etc.). Al seleccionar uno de ellos, el usuario es guiado paso a paso a través de las instrucciones necesarias, desde la anamnesis inicial hasta el diagnóstico final, asegurando un proceso sistemático y estandarizado. La anamnesis incluye preguntas sobre la edad, el sexo y enfermedades previas del paciente, parámetros cruciales que afectan el curso de cada protocolo. Cada paso del protocolo proporciona instrucciones claras y opciones de respuesta (por ejemplo, Instrucción: “¿cuál es la temperatura del paciente? Opciones: “menos de 36º, entre 36º y 39º, más de 40º”), junto con un porcentaje que indica la prevalencia de cada opción en casos de pacientes con características similares, basado en datos históricos. Esta funcionalidad ayuda a los profesionales sanitarios a tomar decisiones informadas respaldadas por datos estadísticos. Además, se ha desarrollado una sección para la búsqueda y revisión de diagnósticos guardados. Los profesionales pueden marcar estos diagnósticos como correctos o erróneos, contribuyendo así a la mejora futura de los protocolos. Esta característica también permite la recopilación de datos que, en el futuro, podrían ser utilizados para integrar inteligencia artificial, mejorando aún más la toma de decisiones y la eficacia de los protocolos. Al haber elegido React Native como tecnología para desarrollar la aplicación, permite que pueda ser compatible tanto en dispositivos Android como iOS, ampliando la accesibilidad para los profesionales sanitarios. No obstante, durante el desarrollo del proyecto solo se han podido hacer pruebas en Android, por lo que es posible que haya que realizar los ajustes pertinentes para que funcione correctamente en iOS. Dicho esto, la aplicación ha alcanzado un nivel de desarrollo que permite su uso efectivo en consultas de urgencias, proporcionando una herramienta que asiste la atención de pacientes haciendo uso de protocolos médicos y la toma de decisiones basadas en datos recopilados. 1.3 Objetivos El desarrollo de esta aplicación móvil para la gestión de protocolos de urgencias hospitalarias persigue varios objetivos clave, orientados a mejorar la eficiencia, precisión y calidad de la atención médica en situaciones críticas. A continuación, se detallan los principales objetivos del proyecto: ❖ Mejora en la toma de decisiones: proveer datos estadísticos en tiempo real durante la ejecución de cada protocolo, mostrando los porcentajes de prevalencia de cada opción en base a casos históricos similares. Esto permite a los profesionales tomar decisiones más informadas y respaldadas por datos. ❖ Optimización del tiempo de atención: reducir el tiempo necesario para la toma de decisiones en situaciones de urgencias, guiando a los profesionales a través de un flujo de trabajo claro y eficiente, desde la anamnesis inicial hasta el diagnóstico final. ❖ Recopilación y análisis de datos: facilitar la recopilación de datos relevantes sobre los diagnósticos y tratamientos realizados, permitiendo la identificación de patrones y tendencias que pueden contribuir a la mejora continua de los protocolos médicos. ❖ Compatibilidad y accesibilidad multiplataforma: desarrollar la aplicación para que sea compatible con dispositivos iOS y Android, asegurando que pueda ser utilizada por un amplio rango de profesionales de la salud en diversas plataformas. Aunque inicialmente solo se ha probado en Android, mediante ajustes futuros sigue siendo posible su implementación en iOS. 23 ❖ Preparación para una futura integración de inteligencia artificial: establecer una base de datos y un sistema de recopilación de datos que pueda ser utilizado en el futuro para integrar tecnologías de inteligencia artificial, mejorando aún más la precisión y efectividad de los protocolos de actuación. ❖ Facilitar la educación y capacitación: proveer una herramienta educativa para la formación de nuevos profesionales con poca experiencia, permitiéndoles familiarizarse con los protocolos de urgencias y mejorar sus habilidades de toma de decisiones en un entorno controlado. 1.4 Alternativas en el mercado Si bien existen numerosas aplicaciones en el mercado que ofrecen herramientas valiosas para los profesionales de la salud, ninguna aborda de manera integral la gestión de protocolos de urgencias con la capacidad de recopilar y analizar datos de pacientes como lo hace esta aplicación. No obstante, las que existen se centran más en asistir a los profesionales sanitarios a la hora de atender a pacientes, ofreciendo herramientas de medición de dosis o guías de actuación. Algunas de estas alternativas son las siguientes: ❖ Calculate by QxMD 1 : proporciona calculadoras médicas y herramientas de apoyo a la decisión clínica. Es utilizada por profesionales de la salud para realizar cálculos rápidos y obtener recomendaciones basadas en datos clínicos. Posee una colección de calculadoras médicas fáciles de usar y basadas en evidencia, con actualizaciones regulares. Esta aplicación es la más parecida a la del proyecto debido a su enfoque centrado en el diagnóstico que se decide directamente tras responder una serie de preguntas iniciales. No obstante, no recopila ninguna información estadística. Está disponible para Android, iOS y web. Figura 1-1. Capturas de pantalla de Calculate by QxMD en App Store. ❖ MDCalc 2 : herramienta que proporciona acceso a numerosas calculadoras médicas y protocolos clínicos. Esta aplicación ayuda a los médicos a realizar cálculos rápidos y precisos en diversas áreas de la medicina, facilitando la toma de decisiones en el punto de atención. Para ello, ofrece un amplio número de calculadoras y herramientas clínicas, actualizadas regularmente y validadas por expertos médicos. Sin embargo, no está específicamente diseñada para la gestión de protocolos de urgencias hospitalarias. Está disponible tanto en iOS como en Android. 1 Calculate by QxMD 2 MDCalc Apps Introducción 24 Figura 1-2. Capturas de pantalla de MDCalc en App Store ❖ Epocrates 3 : aplicación integral que proporciona información sobre medicamentos, interacciones, calculadoras médicas y guías de tratamiento, ofreciendo una amplia gama de recursos médicos en una sola plataforma, con una interfaz fácil de usar y acceso a información actualizada. De nuevo, no está específicamente centrada en protocolos de urgencias y carece de la funcionalidad de seguimiento de casos y análisis estadístico. Disponible en iOS, Android y web. Figura 1-3. Capturas de pantalla de Epocrates en App Store. 3 Epocrates - Explore our features 25 2 POR QUÉ REACT NATIVE Y EXPO n el panorama actual del desarrollo de aplicaciones móviles, es indispensable la elección de tecnologías que ofrezcan una solución eficiente, fiable y versátil dentro de la gran variedad de dispositivos y plataformas que conviven entre los distintos usuarios. En este caso, el proyecto se centra en la creación de una aplicación que sea compatible en los dos sistemas operativos móviles que actualmente reinan en el mercado: iOS y Android. Se ha optado finalmente por el uso de React Native, pues hoy en día, es una de las tecnologías más usadas en el desarrollo de aplicaciones móviles gracias a las ventajas que ofrece, y de Expo, básicamente por las comodidades que ofrece a la hora de trabajar con React Native, sobre todo en este tipo de proyectos que no demandan mucho rendimiento, ni buscan ser comercializados. A continuación, se exponen en detalle dichas ventajas y características. 2.1 Fundamentos de React Native y Expo En este apartado se proporciona una descripción general de las características y funcionamiento de ambas tecnologías, además del papel que tienen cada una en el desarrollo de una aplicación móvil. 2.1.1 ¿Qué es React Native? En primer lugar, es necesario conocer qué es exactamente React Native y cuál es su origen. Básicamente, se define como un framework de código abierto 4 que utiliza React junto con las prestaciones nativas del sistema operativo correspondiente, con el fin de crear aplicaciones móviles en iOS y Android. Esto es, permite que el mismo código pueda construir una aplicación que sea ejecutada nativamente en distintas plataformas. Está basado en el lenguaje JavaScript y concretamente usa JSX como sintaxis, el cual facilita la combinación entre declaraciones de variables o funciones y de componentes React. [1] 4 Tipo de software cuyo código fuente es accesible públicamente, permitiendo a cualquier persona inspeccionarlo, modificarlo y distribuirlo. Esto fomenta la colaboración y el desarrollo continuo por parte de una comunidad global de desarrolladores. E Si decides hacer solo las cosas que sabes que van a funcionar, dejarás un montón de oportunidades encima de la mesa. Steve Jobs Por qué React Native y Expo 32 es ponerse en producción o comercializarse, por lo que las ventajas expuestas anteriormente no pesan tanto en este caso. 2.2.1.2 Diferencia con las aplicaciones híbridas En el subapartado anterior se han expuesto las ventajas e inconvenientes del desarrollo nativo en lugar del uso de React Native y, a continuación, se van a presentar alternativas para la creación de una aplicación móvil de forma no nativa, en este caso, concretamente mediante el uso de plataformas que emplean el enfoque híbrido de desarrollo de aplicaciones. Antes que nada, es conveniente explicar qué son las aplicaciones híbridas. Se pueden definir como aplicaciones móviles que han sido creadas mediante una combinación de desarrollo web y nativo, es decir, el núcleo de la aplicación está escrito en un lenguaje de programación web como JavaScript (haciendo uso de HTML, CSS), que es encapsulado en una aplicación nativa y consigue acceso a las funciones del dispositivo mediante el uso de plugins. De esta forma, aunque el corazón de la aplicación esté desarrollado con tecnologías web, esta no se ejecuta desde el navegador como haría una aplicación web, si no desde el propio navegador embebido de la aplicación nativa, evitando así que el usuario crea que es una web lo que está usando. Por ejemplo, en el caso de un dispositivo iOS, se utilizaría el elemento WKWebView para mostrar la aplicación y en Android sería el elemento WebView el encargado. Las aplicaciones híbridas surgen como solución a las aplicaciones web que no permiten acceder a las funcionalidades del dispositivo, más allá de las que puede el navegador desde el que se ejecutan. Mediante plataformas como Apache Cordova (también conocida como PhoneGap) o Capacitor de Ionic es posible realizar la adaptación del código web a una aplicación nativa y, además, de ofrecer componentes para el acceso a las funciones del dispositivo (cámara, sensor de huellas, bluetooth, etc.). A pesar de que en algunos casos React Native también es considerado un tipo de tecnología para el desarrollo de aplicaciones híbridas, pues al final comparte el hecho de que con un mismo código se puedan crear aplicaciones para distintos sistemas operativos, realmente su funcionamiento es distinto. Mientras que estas plataformas como Apache Cordova se basan en la encapsulación del código web en una aplicación móvil y en la renderización a través de un navegador embebido, React Native es capaz de interpretar el código JavaScript para acceder directamente al sistema operativo y renderizar de forma nativa cada componente descrito en este. De esta forma, React Native presenta algunas ventajas que a continuación se presentan. [9] ❖ El rendimiento en aplicaciones creadas con React Native es superior, ya que, al ser renderizadas de forma nativa, la velocidad y la fluidez a la hora de mostrar los elementos de la UI e interactuar con ellos aumenta significativamente. No pasa así en aplicaciones híbridas creadas con Apache Cordova o Ionic, que son ejecutadas mediante un navegador embebido dentro de la aplicación móvil, ralentizando así la experiencia al no disponer directamente de los recursos del dispositivo. ❖ El aspecto de la interfaz de usuario brinda una apariencia más nativa en React Native pues de nuevo, tiene acceso directo a la creación de componentes nativos, lo cual se puede ver reflejado también en una experiencia de usuario más nativa. Mientras tanto las otras aplicaciones híbridas crean los componentes de una forma más “artificial” a través de código web que se va a ejecutar en un navegador embebido. 2.2.2 ¿Por qué Expo? Una vez que se ha optado por el uso de React Native como herramienta para desarrollar una aplicación móvil, el siguiente paso es elegir el entorno de desarrollo sobre el que trabajar. En este caso, predominan dos alternativas, o bien usando la interfaz de línea de comandos oficial de React Native (React Native CLI), o bien la plataforma Expo, creada por desarrolladores terceros, cuyo fin es agilizar el proceso de la creación de una aplicación y que sea más cómodo y sencillo que usar React Native CLI. En el caso de este proyecto, se ha optado por el uso de Expo, pues la facilidad y comodidad que ofrece con sus diferentes herramientas se sobreponen a las ventajas que puede ofrecer el uso de React Native CLI. Tanto es así, que incluso el equipo de React Native incluye en su documentación a Expo como la alternativa más recomendada para desarrolladores novatos o proyectos cuyo fin es experimental u obtener un resultado rápido. A continuación, se exponen algunas de las ventajas que ofrece Expo frente al uso de React Native CLI: ❖ Una de las más destacadas y por la que se ha optado por Expo en este proyecto, es la posibilidad de comenzar a desarrollar un proyecto con React Native de forma casi instantánea sin la necesidad de 33 preocuparse en la configuración específica de dispositivos o de dependencias nativas de cada sistema operativo. Por otra parte, React Native CLI necesita hacer uso de Android Studio para Android y Xcode para iOS para crear el código binario nativo a partir del código JavaScript, por lo que, en el caso de que en el equipo de trabajo nunca se haya desarrollado una aplicación móvil, hay que invertir tiempo en la descarga de estos IDEs, además de su configuración y posterior descarga de emuladores o simuladores del sistema operativo. Sin embargo, con Expo todo este tiempo puede reducirse a la creación del proyecto mediante un comando y la descarga de la aplicación Expo Go en el dispositivo donde se va a probar. Como es obvio, la diferencia de tiempos para iniciar el desarrollo es bastante significativa, pudiendo ahorrar varias horas. ❖ Brinda acceso a un amplio número de librerías prediseñadas y APIs que simplifican el trabajo a la hora de añadir funcionalidades nativas como compras dentro de la aplicación, notificaciones automáticas, uso de mapas, etc. ❖ Otra función interesante es la posibilidad de lanzar actualizaciones directamente en la aplicación sin la necesidad de que el usuario tenga que descargarla desde la tienda de aplicaciones. ❖ El uso de los servicios EAS simplifica los procesos de compartir y desplegar aplicaciones en entornos de desarrollo o producción en la tienda de aplicaciones, además de otras ventajas como, por ejemplo, que no sea necesario trabajar en un equipo Mac para construir la aplicación en iOS, pues directamente puede subirse a la nube, construirse desde ahí y publicarse en la App Store. Sin embargo, el uso de React Native CLI puede tener sentido en un escenario donde la aplicación a crear necesite unas características acordes a estas ventajas que tiene frente a Expo: ❖ Posibilita el acceso total a los módulos nativos disponibles en el ecosistema de React Native, permitiendo así el aprovechamiento del amplio rango de librerías externas y las capacidades del dispositivo. ❖ Proporciona el control completo a la hora de construir la aplicación, lo que permite optimizar el desarrollo y que esto se traduzca en un mejor rendimiento o incluso que se reduzca el tamaño que ocupa. Esto último puede ser una desventaja en aplicaciones creadas con Expo, ya que tienden a pesar algo más que las creadas directamente con React Native CLI. De esta forma, como la aplicación que se ha creado en este proyecto no es muy demandante en cuanto a recursos del dispositivo se refiere, ni se busca por el momento un rendimiento óptimo, pues no va a ser lanzada al mercado, la virtud de facilitar el proceso del desarrollo en React Native que ofrece Expo se sobrepone a las ventajas que el uso de React Native CLI pueda brindar. [10], [11] Por qué React Native y Expo 34 35 3 DISEÑO, DESARROLLO Y FUNCIONAMIENTO DE LA APLICACIÓN n este capítulo se presenta toda la información relativa al proceso de desarrollo de la aplicación y los resultados obtenidos. Se inicia con una explicación superficial del funcionamiento actual de la aplicación. Una vez que se ha proporcionado una visión general sobre su operatividad, se procede a una exposición a más bajo nivel del diseño, destacando los componentes creados y la interrelación entre ellos. Como se comenta en la introducción, el objetivo de este proyecto es la creación de una aplicación móvil, usando React Native, para facilitar el proceso de seguimiento de los protocolos de actuación de las urgencias hospitalarias a los profesionales sanitarios, además de la recopilación de información del diagnóstico final que se le dio a la persona atendida para que sirva como referencia a la hora de determinar un resultado en pacientes futuros. 3.1 Funcionamiento de la aplicación En primer lugar, es conveniente comenzar explicando cuál es el funcionamiento general de la aplicación y qué capacidades la componen, pues de esta forma se facilita la comprensión del papel de los elementos que la conforman, los cuales se exponen en detalle en los siguientes subapartados. Una vez se inicia la aplicación, en el menú principal se muestran dos botones en forma de cajas. El superior, con el texto “Protocolos” en su interior, indica el acceso a la sección donde se encuentran los distintos protocolos de actuación clasificados por categoría. El inferior, con el texto “Historial de diagnósticos”, conduce a la pantalla donde se puede acceder a los distintos diagnósticos de pacientes anteriores que se han guardado, con el fin de establecerlos como casos exitosos o erróneos. A continuación, se comenta más detalladamente el desempeño de ambas partes. E El verdadero peligro no es que las computadoras comenzaran a pensar como los hombres, sino que los hombres comenzaran a pensar como las computadoras Sydney J. Harris, periodista estadunidense Diseño, desarrollo y funcionamiento de la aplicación 36 Figura 3-1. Captura en Android del menú inicial. 3.1.1 Protocolos Al pulsar el botón “Protocolos” del menú principal, se procede a otra pantalla donde se muestran las distintas categorías en las que se han clasificado los protocolos según el grupo de dolencias. En este caso, dichas categorías se vuelven a mostrar como botones en forma de cajas, indicando con un texto en su interior los siguientes tipos: dolor, hemorragia, disnea aguda, palpitaciones y urgencias neurológicas. 37 Figura 3-2. Captura en Android del menú de protocolos. Una vez se pulsa en uno de ellos, dentro se despliegan en forma de botón las distintas dolencias que conforman dicho grupo. En el caso de la categoría “dolor”, se muestran cuatro dolencias: dolor torácico, dolor abdominal, cefalea y lumbalgia, las cuales conducen al protocolo de actuación que le corresponde a cada una. Diseño, desarrollo y funcionamiento de la aplicación 38 Figura 3-3. Captura en Android del menú de protocolos, con el grupo “dolor” desplegado. En el siguiente paso, cuando se toca en una de las dolencias, aparece una nueva pantalla con un formulario cuyo objetivo es realizar una breve anamnesis 11 al paciente para recopilar información que va a ser utilizada posteriormente con fines estadísticos. Las cuestiones son tres: sexo del paciente, rango de edad en el que se encuentra y enfermedades relevantes en este caso que haya padecido anteriormente (estas son distintas para cada dolencia). 11 Proceso sistemático de recopilación de información médica relevante sobre el paciente, que se obtiene a través de una entrevista directa. 39 Figura 3-4. Captura en Android de la pantalla de anamnesis sin rellenar. Figura 3-5. Captura en Android de la pantalla de anamnesis con las opciones desplegadas para el sexo, edad y enfermedades previas. Diseño, desarrollo y funcionamiento de la aplicación 40 Figura 3-6. Captura en Android de la pantalla de anamnesis ya completa. Una vez se haya completado el formulario, pulsando en el botón “Continuar” se pasa a la pantalla donde se muestra el comienzo del protocolo de actuación. En esta se muestra una caja que contiene un texto con el primer paso que tiene que tomar el profesional sanitario y la cuestión para continuar a la siguiente instrucción. También, se incluye un botón de información que al pulsarlo muestra una explicación más detallada de lo que se ha de hacer. Debajo de esto, aparecen botones con las distintas respuestas posibles a la cuestión que plantea el paso actual del protocolo. Encima de cada uno de estos aparece un espacio destinado a mostrar el porcentaje de pacientes, con el mismo sexo, rango de edad y enfermedad previa, que anteriormente pasaron por esa respuesta. 41 Figura 3-7. Capturas en Android de las pantallas con el protocolo en proceso. Además, se incluye un botón en la parte superior con el símbolo “%” para filtrar las variables que se tienen en cuenta para calcular este porcentaje, es decir, solo por coincidencia en el sexo, por el rango de edad, por enfermedad previa o por la combinación de estos deseada. Diseño, desarrollo y funcionamiento de la aplicación 48 Figura 3-15. Captura en Android de la pantalla de historial de diagnósticos con el diagnóstico con estado éxito. Figura 3-16. Captura en Android de la pantalla de historial de diagnósticos con el diagnóstico con estado error. En el caso de que no existiese un diagnóstico con el código de identificación que se introduce, se muestra un mensaje de error. 49 Figura 3-17. Captura en Android de la pantalla de historial de diagnósticos cuando no se ha encontrado diagnóstico con el código de identificación introducido. A pesar de que esta funcionalidad no tenga un papel significativo en la aplicación actualmente, sienta las bases para que en mejoras futuras se pueda llevar un control sobre qué protocolos fueron ineficaces frente a cierto tipo de pacientes, ajustes a realizar en ellos, etc. 3.2 Arquitectura de la aplicación Entrando ya en detalles de cómo se han estructurado los componentes de la aplicación, es conveniente ilustrar con diagramas la arquitectura que le da forma, además de la correspondiente explicación escrita. 3.2.1 Arquitectura general A continuación, se presenta un diagrama con la arquitectura general del proyecto que muestra las relaciones entre los distintos elementos que componen la aplicación. Diseño, desarrollo y funcionamiento de la aplicación 50 Figura 3-18. Diagrama C4 de la arquitectura general de la aplicación. En este diagrama se muestran las distintas pantallas que dan forma a la aplicación y los vínculos existentes entre sí. Cada una de ellas son componentes funcionales de React Native aislados en ficheros distintos y que desempeñan un rol específico dentro del funcionamiento integral: ❖ Pantalla Menú Inicial: como su nombre indica, la función de este componente es desplegar la primera pantalla que se le muestra al usuario (nombrado “Sanitario” en el diagrama) al abrir la aplicación. Sirve de menú de navegación entre las dos funcionalidades generales existentes: acceso al protocolo y consulta del historial de diagnósticos. Para ello, proporciona un botón destinado a cada una, que al presionarlo da paso a su ejecución. Su aspecto final es el que se muestra en la Figura 3-1. 51 Figura 3-19. Diagrama de actividad de la pantalla Menú inicial. ❖ Pantalla Lista de Protocolos: esta pantalla se renderiza una vez que se pulsa el botón “Protocolos” del menú inicial. El cometido de esta es mostrar el conjunto de protocolos disponibles, que en primera instancia aparecen clasificados en grupos en forma de botones. Una vez se presiona en uno de ellos, se despliega una lista con los protocolos pertenecientes al mismo. En la Figura 3-2 y Figura 3-3 se puede ver el resultado final. El componente que da forma a los botones desplegables en forma de cajas que aparecen en esta pantalla es CardMenu, ha sido desarrollado desde cero y se importa desde un fichero externo (se explica su creación en el apartado 3.3.2). Diseño, desarrollo y funcionamiento de la aplicación 52 Figura 3-20. Diagrama de actividad de la pantalla Lista de protocolos. ❖ Pantalla Protocolo: el código encargado de reproducir esta pantalla es el más complejo del proyecto pues es el que tiene el papel que requiere más nivel de procesamiento. En primer lugar, se encarga de hacer una llamada a la base de datos para recibir el protocolo que se ha seleccionado en la pantalla anterior, el cual es proporcionado por parámetros. Una vez que ya lo ha recibido, despliega el formulario de anamnesis para que el sanitario introduzca los datos del paciente (Figura 3-4). Seguidamente, comienza a mostrar el primer paso del protocolo con la primera instrucción y los botones con las posibles opciones. A la vez, en este momento hace otra llamada a la base de datos solicitando, entre el historial completo de diagnósticos almacenado, aquellos casos en los que los datos de los pacientes coinciden con los ahora recopilados en la anamnesis. Con estos datos, este componente se encarga de calcular los porcentajes de pacientes con las mismas características que cumplían cada opción y los muestra encima de cada una de estas. La función encargada de este cálculo de probabilidades se explica en detalle en el apartado 3.3.6.1. Esta consulta, se hace cada vez que se avanza o retrocede un paso del protocolo, y también cuando se cambian los parámetros (género, rango de edad y enfermedad previa relevante) que se van a tener en cuenta para el cálculo de probabilidades, función de filtrado que se muestra en la Figura 3-8. La apariencia del avance por los pasos del protocolo se puede ver en la Figura 3-7. Por último, cuando se alcanza el final del protocolo, muestra, además del diagnóstico final, un botón para guardar el recorrido por el protocolo junto con la información del paciente en el historial de diagnósticos de la base de datos, tal y como se muestra en la Figura 3-11 y la Figura 3-12. 53 Figura 3-21. Diagrama de actividad de la pantalla Protocolo. Diseño, desarrollo y funcionamiento de la aplicación 54 ❖ Pantalla Historial de Diagnósticos: se encarga de la otra funcionalidad de la aplicación destinada a la búsqueda de diagnósticos. De primeras, muestra un campo de entrada en el que se va a introducir el código de identificación del diagnóstico, el cual aparece en pantalla a la hora de guardar el diagnóstico, y un botón para proceder a la consulta en la base de datos, que, en el caso de encontrarlo, retornará el resultado y lo plasmará en un componente en forma de tarjeta que ha sido creado desde cero. Desde aquí, si no se ha establecido aún el estado del diagnóstico, aparecen un botón para indicar que el diagnóstico resultó exitoso y otro para indicar que fue erróneo. Una vez se pulsa en uno de ellos, se hace una llamada a la base de datos para que actualice el diagnóstico con el estado correspondiente. En la Figura 3-13, Figura 3-14, Figura 3-15, Figura 3-16 y Figura 3-17 se puede ver el aspecto final de esta pantalla. Figura 3-22. Diagrama de actividad de la pantalla Historial de diagnósticos. 55 3.2.2 Uso de la base de datos Para el desempeño de las distintas funciones de la aplicación es conveniente hacer uso de una plataforma donde guardar datos como los protocolos, el historial de diagnósticos realizados e información relativa a estos. Considerando que la aplicación se va a usar en distintos dispositivos, la forma más ideal viene a ser una base de datos centralizada donde escribir o leer datos desde cualquiera de estos. En este caso, se ha optado por Cloud Firestore, una base de datos en la nube proporcionada por Firebase (plataforma de desarrollo de aplicaciones de Google). La facilidad a la hora de integrarse con un proyecto en React Native ha sido el factor determinante para su elección, ya que las librerías y SDKs existentes aligeran el proceso de acceso y uso, además de proporcionar herramientas para realizar consultas avanzadas. La base de datos es de tipo NoSQL y almacena los datos en documentos, los cuales están formados por un conjunto de pares campo-valor y se organizan en colecciones. Para este proyecto, se han creado dos colecciones principales: ❖ protocolos: contiene documentos nombrados según la dolencia que abordan. Cada documento incluye el protocolo de actuación correspondiente en formato JSON. ❖ historial_usos: almacena los distintos diagnósticos realizados. Cada diagnóstico se guarda en un documento identificado con un código único. El contenido de estos documentos incluye: o diag_exitoso: un campo booleano que indica si el diagnóstico fue exitoso. o diagnostico: el diagnóstico dado al paciente. o enfermedad: la dolencia que trata el protocolo. o ruta: las opciones seleccionadas hasta el final del protocolo. o fecha: la fecha en que se atendió al paciente. o edad: el rango de edad del paciente. o sexo: el sexo del paciente. o enfermedad_previa: enfermedades previas relevantes del paciente. Figura 3-23. Captura de Cloud Firestore de la colección “historial_usos”. Diseño, desarrollo y funcionamiento de la aplicación 56 Figura 3-24. Captura de Cloud Firestore de la colección “protocolos”. Una vez expuesta la estructura de la base de datos, a continuación, se describen los distintos usos que se le dan. Empezando por la pantalla de protocolos, como se ha comentado anteriormente, cuando se va a comenzar a ejecutar un protocolo, una vez se haya pulsado en él en la pantalla de lista de protocolos, se hace una llamada a la base de datos para recibir de la colección “protocolos” el contenido del protocolo que se le indica, cuyo formato es JSON y que será interpretado por la aplicación para ir mostrando cada paso. Figura 3-25. Diagrama con la llamada a la BBDD para recibir el protocolo del dolor torácico. Otra llamada que hace la pantalla de protocolos es cada vez que se avanza o retrocede un paso del protocolo, en este caso, a la colección “historial_usos” para recibir todos los diagnósticos anteriores guardados de la enfermedad correspondiente, cuyos pacientes coinciden en rango de edad, sexo o enfermedad previa, según se elija en el filtro de parámetros. Una vez recibidos los diagnósticos, se calcula la probabilidad a la que pacientes con las mismas características, cumplen cada una de las opciones mostradas como respuesta. Figura 3-26. Diagrama con la llamada a la BBDD para recibir todos los diagnósticos guardados del dolor torácico realizados a mujeres. De nuevo en la pantalla de protocolos, al acabar uno y pulsar en el botón “guardar diagnóstico”, se hace otra llamada a la base de datos para enviar a la colección “historial_usos” los datos del diagnóstico, retornando esta el código de identificación con el que lo ha guardado. Figura 3-27. Diagrama con la llamada a la BBDD para guardar los datos del diagnóstico final. Pasando a la pantalla de historial de diagnósticos, se hace una llamada a la colección “historial_usos” para recibir el diagnóstico correspondiente al código de identificación proporcionado y otra cuando se añade el resultado 57 final del diagnóstico, actualizando su campo “estado” a true o false, dependiendo de si fue correcto o incorrecto. Figura 3-28. Diagrama con las llamadas a la BBD para recibir un diagnóstico con el ID correspondiente y establecer su resultado final como correcto. 3.3 Desarrollo de la aplicación en React Native Tras haber descrito los diversos elementos que componen la aplicación, junto con sus funciones y las relaciones entre ellos, en este apartado se profundiza en el desarrollo de estos elementos utilizando React Native. Además, se abordan las estrategias implementadas para resolver los diferentes problemas que surgen en la creación de una aplicación con este tipo de funcionamiento. 3.3.1 Elementos del proyecto y su relación Una vez expuesta una visión general sobre los principales elementos que forman la aplicación, conviene entrar más en detalle y explicar el resto de los componentes que se están usando y cómo están relacionados. De esta forma, en el proyecto existen otros componentes y funciones que son usados por las pantallas. Al aislarlos en distintos ficheros, se consigue un código más organizado y limpio que si directamente se codificara todo en los ficheros de las pantallas. En general, estos componentes de los que se habla son usados por algunas pantallas para mostrar elementos en la interfaz de usuario, y las funciones, para acceder y poder realizar operaciones en la base de datos. Figura 3-29. Diagrama de los componentes de la aplicación y su relación. A continuación, se explica el contenido de cada función que compone la aplicación, mostrada en el diagrama: ❖ App.js: es el componente principal que actúa como la función que define y configura la navegación de Diseño, desarrollo y funcionamiento de la aplicación 64 3.3.2 Uso de componentes creados Una de las ventajas del uso de React Native para el desarrollo de aplicaciones móviles es la capacidad de crear componentes personalizados, que permite la construcción de piezas de interfaz de usuario reutilizables y adaptables a las necesidades específicas del proyecto. De esta forma, se promueve la modularidad y la limpieza del código, además de facilitar el mantenimiento y la escalabilidad de la aplicación. En el caso de esta aplicación, solo ha sido necesaria la creación de dos componentes que, a pesar de que solo se han usado en una pantalla respectivamente, era conveniente aislarlos en diferentes archivos para no complicar tanto el código de los ficheros con las pantallas que iban a hacer uso de ellos. No obstante, así, no queda descartada la opción de volver a utilizarlos en futuros desarrollos de la aplicación. Comenzando con el que se usa en la pantalla de lista de protocolos, el componente CardMenu ha sido creado para mostrar en forma de cajas/tarjetas los distintos grupos de dolencias disponibles y dolencias que hay dentro, una vez se pulse sobre uno de ellos. La necesidad detrás de la creación de un componente independiente para esto se da sobre todo al tener que crear un número de tarjetas que va a depender de la cantidad de grupos de dolencias existentes. Esta cantidad se almacena en formato JSON en un fichero externo, donde se indican las distintas dolencias existentes y el grupo del que forman parte. Es en la pantalla de lista de protocolos donde se va a interpretar este fichero y mediante el uso del método “map” se va a llamar, tantas veces como grupos de protocolos haya, al componente CardMenu, pasándole como parámetros datos como el índice, nombre del grupo, lista de dolencias del grupo y el identificador de la imagen con la que va a rellenar la tarjeta. Como este componente va a ser el responsable de renderizar la pantalla protocolos una vez se pulse en una de las dolencias, también es necesario pasarle como parámetro el objecto “navigation” con el que se realiza el cambio de pantalla e indicándole qué protocolo debe mostrar. Figura 3-39. Capturas del componente CardMenu. El otro componente se ha nombrado como CardDiagnosis y es usado en la pantalla de historial de diagnósticos. Este es renderizado cuando se realiza la llamada a la base de datos para recibir un diagnóstico y se reciben los datos correctamente, pasándole como parámetro un objeto con esta información del diagnóstico. De esta forma, el componente muestra una tarjeta con el código de identificación y el resultado del diagnóstico, la dolencia que trataba el protocolo, la fecha en la que se hizo, y la edad, sexo y enfermades previas relevantes del paciente. Si al diagnóstico aún no se le ha dictado si fue correcto o erróneo, el componente comprueba que el valor de “diagn_exitoso” del objecto pasado por parámetros, es undefined y muestra un botón para cada una de las dos opciones, que al pulsarlos hacen la llamada a la base de datos para actualizar el diagnóstico cambiando el estado a éxito (true) o fracaso (false). 65 Figura 3-40. Captura de CardDiagnosis cuando el resultado del diagnóstico no se ha indicado aún. Figura 3-41. Capturas de CardDiagnosis con diagnósticos correctos y erróneos. 3.3.3 Uso de componentes de terceros Otra de las ventajas del uso de React Native es la posibilidad de importar y utilizar librerías externas que, además de facilitar la implementación de elementos visuales y de interacción, permiten ahorrar tiempo al reutilizar soluciones ya probadas y optimizadas. A continuación, se van a comentar las librerías de terceros utilizadas y dónde han sido usadas en el proyecto. Diseño, desarrollo y funcionamiento de la aplicación 66 ❖ React Navigation 13 : a la hora de crear una aplicación móvil con React Native, la gestión de la navegación de pantallas es un aspecto crucial para proporcionar una experiencia de usuario intuitiva y coherente. En este proyecto, se ha hecho uso de la biblioteca React Navigation, que es una solución extendida y robusta que facilita la creación de rutas y navegación entre las distintas pantallas de una aplicación. Se hace uso de ella en el componente principal App.js donde se exponen las pantallas que componen la aplicación. Para ello, primero se importa la función createNativeStackNavigator() del paquete @react-navigation/native-stack, con la que se va a invocar al objecto Stack que permite la creación de la pila de navegación y la declaración de las pantallas que van dentro. Esta es la que permite al usuario navegar hacia adelante y atrás a través de las pantallas, similar al funcionamiento de las webs en un navegador. Por último, se importa el componente NavigationContainer del paquete @reactnavigation/native, que envuelve toda la estructura de navegación y es responsable de gestionar su estado. Aquí también se personaliza el tema, definiendo colores específicos para los elementos de la interfaz de la barra superior de navegación. ❖ React Native Elements 14 : esta es una biblioteca que ofrece una colección de componentes de interfaz de usuario listos para usar y personalizables para React Native. En este caso, el elemento importado es Overlay, cuyo papel es el de ventana emergente y entre los parámetros ajustables que posee, se ha usado el de isVisible, para mostrarse en pantalla solo cuando su valor es true, y el de onBackdropPress, que ejecuta una función al pulsar fuera de la ventana emergente, en este caso, para cambiar la variable de estado a false usada para indicar el isVisible, y que así desaparezca. Este Overlay es usado en la pantalla ProtocolScreen.js para desplegar una ventana emergente con un texto de información al pulsar los botones de información que aparecen a veces en la instrucción y las opciones de cada paso del protocolo. Figura 3-42. Capturas de Overlay con el botón de información en la instrucción. 13 Página web oficial de React Navigation 14 Página web oficial de React Native Elements 67 Figura 3-43. Capturas de Overlay con el botón de información en las opciones. ❖ React Native Picker Select 15 : este componente se utiliza para proporcionar menús desplegables interactivos que permiten al usuario seleccionar opciones específicas. Para ello, se ha importado el componente RNPickerSelect que se ha utilizado de nuevo en la pantalla ProtocolScreen.js en la sección de anamnesis para recoger la información del paciente: el sexo, la edad y enfermedades previas, mostrando las opciones disponibles en cada campo. El componente ofrece distintos parámetros configurables, pero en este caso se han usado el placeholder, donde se indica el valor por defecto que tiene el campo y un texto descriptivo, ítems, donde se dicen los distintos valores a seleccionar, onValueChange, que ejecuta una función cuando se selecciona uno de los valores, en este caso para guardarlo en una variable de estado que contiene la información de la anamnesis del paciente, y style, donde se indican los estilos que debe usar el componente. 15 React Native Picker Select en el portal de npmjs Diseño, desarrollo y funcionamiento de la aplicación 68 Figura 3-44. Capturas de RNPickerSelect en el campo de sexo. Figura 3-45. Capturas de RNPickerSelect en el campo de edad. 69 Figura 3-46. Capturas de RNPickerSelect en el campo de enfermedad previa. 3.3.4 Uso de hooks Los hooks son elementos de React que se introdujeron a partir de la versión 16.8, que vinieron a sustituir el enfoque tradicional de creación de componentes clases, para hacer uso del estado y otras características propias de React, como los efectos secundarios 16 , ahora desde componentes funcionales, ofreciendo una alternativa más simple y eficiente. Con su uso se simplifica considerablemente la sintaxis y estructura del código, ofreciendo un código más legible. El propio paquete de React provee unos cuantos hooks por defecto, pero además da la posibilidad de crear y hacer uso de hooks propios. En el caso de este proyecto, se ha optado por la opción más común actualmente en el desarrollo de aplicaciones React Native, que es el uso de hooks y creación de componentes funcionales, en vez de clases. Concretamente, se han utilizado dos de lo más recurrentes, como son useState y useEffect, y otro algo menos común, useLayoutEffect. ❖ useState: devuelve un valor con un estado mantenido y una función que es necesaria para poder actualizarlo. El valor inicial del estado en el primer renderizado es el que se le pasa por parámetros. Cada vez que su estado cambia de valor haciendo uso de la función, se realiza otro renderizado. Por ejemplo, uno de los usos que se han dado a este hook en el proyecto ha sido en el componente CardMenu, donde se ha declarado uno cuyo valor inicialmente es false y que cada vez que se pulsa sobre una de las tarjetas con los grupos de las dolencias, pasa a ser true, consiguiendo así que se renderice ahora la tarjeta mostrando el conjunto de dolencias correspondientes. ❖ useEffect: permite agregar efectos secundarios y realizar modificaciones en la lógica una vez se haya realizado el renderizado. Su uso permite prescindir de los métodos de ciclo de vida componentDidMount (ejecutado cuando el componente se añadía al DOM), componentDidUpdate (ejecutado cuando el estado del componente se actualizaba) y componentWillUnmount (ejecutado cuando el componente se desmonta del DOM) de los componentes de clase. Este hook se utiliza en el código de la pantalla protocolo para llamar a la función encargada de calcular las probabilidades de 16 En el contexto de componentes funcionales en React, los efectos secundarios se refieren a cualquier operación que ocurre fuera del flujo de renderizado puro de la interfaz de usuario, ya sean llamadas a APIs, manipulación del DOM o limpieza de recursos, entre otras. Diseño, desarrollo y funcionamiento de la aplicación 70 pacientes anteriores que cumplían cada una de las opciones mostradas en el paso actual del protocolo, realizando las operaciones previas necesarias. Tal y como está configurado el hook, esta función se ejecuta por primera vez al renderizar el componente y después, cada vez que cambia el valor de estados como el que almacena los parámetros a tener en cuenta para el cálculo de probabilidades o el que va cambiando de true a false al ir avanzando o retrocediendo por el protocolo (ambos creados con useState), consiguiendo así que se vayan actualizando los porcentajes mostrados. ❖ useLayoutEffect: su funcionamiento es similar al de useEffect, con la diferencia de que su contenido, en vez de ejecutarse tras añadir el componente al DOM, se hace justo antes de que esto suceda. De esta forma, se evita el parpadeo que se da en algunas situaciones a la hora de actualizar un componente. Normalmente, se recomienda evitar su uso siempre que sea posible, pues puede provocar problemas de rendimiento y empeorar la experiencia del usuario, ya que la aplicación no renderiza el componente hasta que no ha terminado de ejecutar su contenido. En el proyecto, ha sido necesario hacer uso de este hook en la pantalla protocolo para que, en la barra superior de navegación que contiene el botón para ir a la pantalla anterior, aparezca de primeras el nombre de la dolencia seleccionada. Utilizando useEffect en su lugar, el cambio de nombre se produce ya habiendo mostrado en pantalla esta barra de navegación en la parte superior, provocando el efecto óptico de parpadeo en el componente. 3.3.5 Estructura y organización del código El código se ha estructurado en distintos directorios con el fin de tener el proyecto lo más organizado posible y así, facilitar el desarrollo, mantenimiento y escalabilidad del proyecto. Desde el directorio raíz, se distinguen los siguientes directorios y ficheros: ❖ /assets: este directorio contiene todos los recursos usados por los componentes y pantallas, como imágenes, iconos, fuentes o colores, los cuales se encuentran organizados en sus respectivas carpetas. También, dentro de este directorio se encuentran los elementos visuales que contribuyen a mejorar la apariencia y experiencia del usuario en la aplicación. Estos son: o Pantalla Splash: es la imagen que se muestra mientras se carga la aplicación. Proporciona una experiencia de usuario más fluida al mostrar una pantalla intermedia en lugar de una pantalla en blanco. Suele incluir el logotipo de la aplicación. o Icono de la aplicación: es la imagen que representa a la aplicación en la pantalla de inicio del dispositivo móvil y en el cajón de aplicaciones. Por tanto, es crucial para la identidad visual de la aplicación. o Favicon: es el icono pequeño que representa a la aplicación en la pestaña del navegador web y en los marcadores. No obstante, en este caso no es relevante ya que la aplicación se ha desarrollado con el fin de ejecutarse en dispositivos móviles y no en web. o Icono adaptativo: es una característica específica de Android que permite que el icono de la aplicación se ajuste a diferentes formas según la configuración del dispositivo. Su contenido es una capa de fondo y otra de primer plano, que al combinarse pueden formar el icono final en diferentes formas, como circular, cuadrada, etc. Siguiendo con los directorios que hay dentro de assets: o /icons: contiene los distintos iconos que se usan en las pantallas de la aplicación, normalmente para darle forma a los botones. Algunos de ellos son el icono de la lupa, usado en botones destinados a lanzar una búsqueda, o el de la flecha hacia atrás, para ir a la pantalla anterior. Figura 3-47. Colección de iconos utilizados en la aplicación. o /images: contiene las imágenes que se muestran dentro de las tarjetas del componente creado CardMenu y en la pantalla de menú inicial. Por ejemplo, para la pantalla de menú inicial hay dos imágenes, una para representar los protocolos y otra para el historial de diagnósticos. 71 Figura 3-48. Imágenes usadas para rellenar los botones del menú de inicio. ❖ /components: en este directorio se guardan los componentes que se han creado: CardMenu y CardDiagnosis. o CardMenu.js: este componente en forma de tarjeta se utiliza en la pantalla de lista de protocolos para mostrar los distintos grupos de protocolos y los que los componen, dando paso a la pantalla de protocolos, indicando cuál se ha seleccionado. o CardDiagnosis.js: este, también con forma de tarjeta, es mostrado en la pantalla de historial de diagnósticos para mostrar la información del diagnóstico buscado y además, contiene botones para indicar si finalmente resultó ser correcto o incorrecto. o /styles: en este directorio se guardan los dos archivos que contienen los estilos importados y utilizados en cada componente: CardMenuStyles.js y CardDiagnosisStyles.js ❖ /db: este directorio contiene los archivos relacionados con la base de datos. o FirebaseAccess.js: esta función es la responsable de conectarse a la base de datos Firestore y devolver un objeto con la instancia a la base de datos para poder realizar las distintas operaciones deseadas. Esta es importada en los archivos de las pantallas que realizan consultas a la base de datos, como la pantalla de protocolos. ❖ /screens: contiene los archivos con las distintas pantallas de la aplicación. o DiagnosisHistoryScreen.js: encargada de la búsqueda de diagnósticos guardados y de establecer su estado como correcto o incorrecto. La información del diagnóstico buscado la muestra con el componente creado CardDiagnosis. o MainMenuScreen.js: la primera pantalla mostrada en la aplicación, cuya función es de menú para acceder a la pantalla de historial de diagnósticos o la de la lista de protocolos. o ProtocolListScreen.js: en esta se muestran los distintos protocolos disponibles, organizados en grupos. Hace uso del componente CardMenu mencionado anteriormente. o ProtocolScreen.js: pantalla donde se van a ir mostrando los pasos del protocolo seleccionado hasta su final, junto con el resto de las funcionalidades. o /styles: directorio que contiene los ficheros con los estilos importados en los códigos de las pantallas: DiagnosisHistoryScreenStyle.js, MainMenuScreenStyle.js, ProtocolListScreenStyle.js y ProtocolScreenStyle.js. ❖ App.js: contiene el código del componente raíz que define la estructura principal de la aplicación. En este caso, se configura y gestiona la navegación de la aplicación por las distintas pantallas. Para ello, se hace uso de la biblioteca React Navigator, a través de un Stack.Navigator, para definir la pila de pantallas a las que se puede navegar. ❖ app.json: en este archivo se definen las propiedades de Expo como el nombre de la aplicación, la versión de esta o la ruta en la que encontrar la imagen que se usa de icono. ❖ package-lock.json: este registra las versiones exactas de cada paquete instalado, incluyendo subdependencias, para asegurar que las instalaciones sean consistentes en todos los equipos en los que se ejecute. ❖ package.json: contiene información del proyecto como el nombre, versión y el fichero de entrada, el Diseño, desarrollo y funcionamiento de la aplicación 72 cual es el fichero AppEntry.js que se encuentra en la librería de Expo, en vez del clásico index.js. Además, también incluye scripts de Expo para arrancar el servicio. Por último, alberga las dependencias en uso. Figura 3-49. Estructura de directorios del proyecto. 3.3.6 Estrategias diseñadas para la implementación de funcionalidades Durante el desarrollo de la aplicación, aparecen una serie de desafíos que deben ser abordados garantizar que las diversas funciones cumplan con sus objetivos de manera efectiva. Si bien existen múltiples enfoques posibles para resolver estos problemas, a continuación, se detallan las soluciones específicas que se han adoptado y merece la pena mencionar. 3.3.6.1 Método para el cálculo de probabilidades en cada opción A la hora de ejecutar el protocolo de actuación, la funcionalidad encargada de mostrar la probabilidad de pacientes anteriores, con características similares al paciente que está siendo atendido, que cumplían las distintas opciones mostradas en el paso actual, necesitaba ser diseñada desde cero y que se crearan distintas estrategias para poder llevarla a cabo. En primer lugar, mostrar las probabilidades en base a todos los diagnósticos llevados a cabo con ese protocolo, no tenía mucho sentido sin tener en cuenta características que coincidieran con el paciente que se está atendiendo, por lo que se introdujo, un formulario en forma de anamnesis, antes de comenzar con el protocolo, que recopila el rango de edad del paciente, el sexo y si padeció alguna enfermedad anteriormente que tenga relevancia con la 73 dolencia que sufre ahora. Además de lo anterior, para poder calcular estas probabilidades era necesario diseñar un proceso capaz de ir recopilando los pasos del protocolo por los que se va pasando hasta llegar al diagnóstico final. Para ello, se crea una variable de estado en la pantalla protocolo, cuyo valor es una cadena de caracteres que sigue el formato “0- x-y-z-…”. Inicialmente, al comenzar el protocolo, el valor de esta es “0”. Al elegir una de las opciones mostradas como respuesta, el valor cambia y se concatena el número del orden que esta ocupa. De esta forma, si se elige la segunda opción de las tres que se muestran, el valor de la variable de estado pasaría a ser “0-2”. Así sucede hasta que se llega al final del protocolo, pudiendo resultar el valor de la variable “0-2-1-1”, por ejemplo. En este punto, al guardar el diagnóstico este valor se salva en la base de datos con el nombre de “ruta”. Figura 3-50. Diagrama que representa cómo se recopilan los pasos que se han tomado durante el protocolo. Una vez guardados los diagnósticos en la base de datos, la próxima vez que se acceda al mismo protocolo de actuación, se procede a hacer las solicitudes correspondientes para recibirlos. Las llamadas a la base de datos se hacen una vez se rellena la anamnesis, se avanza o retrocede pasos en el protocolo y al cambiar los parámetros a tener en cuenta para calcular las probabilidades (edad, sexo, enfermedades previas). Una vez se reciben los diferentes diagnósticos de la dolencia que se está tratando, comienza el proceso de obtención de probabilidades. Para ello, se van a tomar las rutas de todos ellos y mediante un bucle, se va a comprobar si coinciden con la ruta actual que formaría cada opción mostrada. Como seguramente, la ruta actual sea más corta (p.ej. “0-2-x”), pues no ha terminado el protocolo aún, es necesario hacer la comprobación seccionando las rutas recibidas para que tengan el mismo tamaño (p.ej. “0-2-1||-2”). Siempre que se cumpla la coincidencia, se incrementa una variable y cuando ya se ha hecho la comprobación con todas, la probabilidad se obtiene dividiendo dicha variable entre el total de rutas y se guarda el resultado en un array. Al ir añadiendo en orden los resultados, se sabe qué porcentaje corresponde a cada opción. 3.3.6.2 Estructuración e interpretación de protocolos en formato JSON Para poder ejecutar cada protocolo era necesaria la creación de un sistema capaz de interpretarlos, mostrando los pasos y las opciones correspondientes. Para ello, el sistema ideado contiene los protocolos en formato JSON, siguiendo la estructura determinada que la pantalla Protocolos se ha programado para interpretar. La estructura es la siguiente: ❖ En primer lugar, está formado por un objecto con dos componentes. El primero tiene como clave el nombre de la dolencia y contiene un objeto con los pasos del protocolo, formando las distintas ramas Diseño, desarrollo y funcionamiento de la aplicación 80 pueda publicar los suyos. Otro de los factores que la hacen destacar frente al resto es la posibilidad de instalar multitud de extensiones para interpretar una amplia variedad de lenguajes y frameworks y otras herramientas que facilitan el proceso de desarrollo de código. ❖ Herramientas de depuración y de pruebas: ofrece un conjunto de funcionalidades que ayudan a depurar los programas de forma ágil y otras enfocadas a ejecutar pruebas unitarias de manera integrada, sin la necesidad de salir del editor. ❖ Integración nativa de control de versiones: incorpora soporte con Git, permitiendo usarlo directamente a través de la interfaz gráfica, lo cual agiliza el flujo de trabajo para aquellos que no están habituados a usar Git por línea de comandos. [12] Figura 3-59. Captura de Visual Studio Code con el proyecto abierto. 3.4.2 React Native y Expo usados La versión de React Native que está corriendo la aplicación es la 0.68.2, mientras que la versión de Expo SDK es la 45.0.0. Existen dos formas de comprobar las versiones que se están usando en un proyecto React Native. La primera es ejecutando los comandos npm list react-native y npm list expo, ambos desde el directorio raíz del proyecto. La segunda es buscando directamente en las dependencias del fichero package.json las versiones de react-native y expo: 81 Figura 3-60. Captura del fichero package.json con las versiones de Expo y React Native usadas. Para poder arrancar Expo con el empaquetador Metro y ejecutar la aplicación, se hace uso del comando npm start desde el directorio raíz del proyecto. Las versiones de npm y Node.js usadas para poder ejecutar dicha versión de Expo, son la 8.3.1 y la v16.14.0, respectivamente. Basta con instalar esa versión de Node.js para obtener la de npm también. Para ello, como en este caso se ha usado un equipo Windows para desarrollar la aplicación, lo más cómodo es usar NVM (Node Version Manager), el administrador de versiones de Node.js, cuyo instalador se puede obtener desde el repositorio coreybutler/nvm-windows 18 de Github. Una vez instalado, ejecutando desde la terminal de comandos nvm install 16.14.0 se descargaría el paquete y para comenzar a usarlo, ejecutando nvm use 16.14.0 se cambian automáticamente las variables de entorno necesarias para ello. Por último, las versiones que deben aparecer tras ejecutar node -v y npm -v, deberían ser v16.14.0 y 8.3.1. 3.4.3 Cómo ejecutar la aplicación La aplicación se ha estado probando y ejecutando a través del emulador Android que Android Studio ofrece, pues, personalmente, resulta más cómodo tener en la misma pantalla el código que se va escribiendo y el dispositivo Android con el resultado al lado. 3.4.3.1 Descarga e instalación del emulador Android De esta forma, para poder usar el emulador Android es necesario instalar Android Studio. El proceso no tiene complicación alguna, usando Windows basta con descargar el instalador desde la página oficial 19 y ejecutar el archivo .exe, prestando atención cuando muestre la ventana para seleccionar los componentes a instalar, ya que se debe marcar la casilla de Android Virtual Device, que es el que contiene el emulador. 18 GitHub con las versiones publicadas de nvm-windows 19 Portal oficial de Android Studio Diseño, desarrollo y funcionamiento de la aplicación 82 Figura 3-61. Captura del instalador de Android Studio con la ventana para seleccionar los componentes a instalar. Una vez, se marca Android Virtual Device para ser instalado, se continúa con el proceso normal de instalación, indicando la dirección de memoria en la que instalarlo, dónde crear el acceso directo, etc., hasta llegar a la ventana final con el botón “Finish”. Figura 3-62. Captura del instalador de Android Studio con la ventana para indicar la ruta de instalación. 83 Figura 3-63. Captura del instalador de Android Studio con la última ventana para finalizar la instalación. Una vez completado el proceso de instalación de Android Studio, lo siguiente es crear un dispositivo virtual. Para ello, hay que abrir el administrador de dispositivos o Device Manager, cuyo botón se encuentra en el menú lateral derecho, y seguidamente pulsar en el botón con el símbolo “+” para descargar el emulador del dispositivo Android que se desee. Figura 3-64. Captura de Android Studio que señala el botón para abrir el administrador de dispositivos. Diseño, desarrollo y funcionamiento de la aplicación 84 Figura 3-65. Captura de Android Studio que señala el botón para añadir un nuevo dispositivo desde el administrador de dispositivos. A continuación, se despliega una ventana con los distintos dispositivos Android disponibles para emular. Al seleccionar uno de ellos, en principio es necesario instalar una versión de Android que el dispositivo emulado corra. Tras descargarla y configurar algunos parámetros adicionales, como el nombre que se le va a dar al dispositivo o si se quiere ejecutar en vertical u horizontal (la aplicación solo puede ser ejecutada con el dispositivo en vertical), debe aparecer en el administrador de dispositivos. Ya solo queda ejecutarla pulsando en el botón de inicio. Figura 3-66. Captura del Device Manager de Android Studio con el listado de dispositivos disponibles. 85 Figura 3-67. Captura de Android Studio que señala el botón para iniciar el emulador del dispositivo. 3.4.3.2 Ejecución de la aplicación en el emulador Android Una vez obtenido el dispositivo virtual que se va a usar como emulador Android, el siguiente paso es utilizar Expo Go desde este para conectarse al servicio Expo que estamos ejecutando en nuestro equipo, y así, recibir y ejecutar la aplicación. En primer lugar, es necesario instalar Expo Go en el emulador. Para ello, hay que acceder desde el navegador del ordenador a la página oficial, seleccionar la versión del SDK de Expo que va a ejecutar (en este caso es necesario el SDK 46) y pulsar en el botón de instalar en emulador Android. Figura 3-68. Captura de la web de Expo Go que señala la versión a seleccionar y el botón a pulsar para iniciar el proceso de instalación. A continuación, se despliega una ventana que proporciona dos formas posibles de realizar la instalación. Se va a seguir el proceso de instalación manual y, para ello, simplemente hay que pulsar en el botón de descarga para obtener un archivo .apk que contiene la aplicación Expo Go. Por último, para instalarla en el emulador basta con arrastrar el archivo hasta la pantalla del dispositivo virtual. Diseño, desarrollo y funcionamiento de la aplicación 86 Figura 3-69. Captura de la web de Expo Go que señala el botón a pulsar para descargar el archivo apk. Ya instalada la aplicación Expo Go en el emulador, lo siguiente es conectarse al servicio Expo que se está ejecutando en el equipo. Lo primero es tener arrancado este servicio, lo cual se puede hacer desde el propio Virtual Studio Code desde el terminal. Al ejecutar el comando npm start desde el directorio raíz del proyecto, Expo arrancará y mostrará la dirección a la que conectarse, en la línea que deber decir algo como “Metro waiting on exp://192.168.1.156:19000”. Figura 3-70. Captura del terminal con Expo arrancado que señala la dirección a la que conectarse desde Expo Go. Por último, hay que pegar esta dirección en Expo Go donde dice “Introducir URL manualmente” y pulsar en el botón de conectar. Esto descargará el paquete con la aplicación y la ejecutará directamente en el emulador. 87 Figura 3-71. Capturas de Expo Go en el emulador Android con la pantalla donde introducir la URL y ya con la aplicación ejecutándose tras pulsar en conectar. 89 4 CONCLUSIONES Y TRABAJOS FUTUROS asta este punto, se ha detallado cómo se ha llevado a cabo el alcance actual de la aplicación desarrollada. Sin embargo, existe un margen para mejorarla mediante la implementación de funcionalidades adicionales en el futuro. En este capítulo, se expone tanto el estado actual de la aplicación como algunas de las posibles mejoras, acompañadas de una breve explicación sobre cómo podrían realizarse. 4.1 Conclusiones En resumen, este trabajo de fin de grado ha resultado en la creación de una aplicación móvil, usando React Native y Expo como tecnologías de desarrollo, cuyo fin está destinado a asistir la atención de pacientes en consultas de urgencias en hospitales o centros médicos. Para ello, la aplicación brinda las siguientes funcionalidades: ❖ Listado de las distintas dolencias, clasificadas en grupos. ❖ Muestra guiada de los pasos del protocolo seleccionado, con las posibles opciones resultantes tras llevar a cabo la instrucción. ❖ Muestra de probabilidades de pacientes anteriores con mismo sexo, rango de edad o enfermedad previa, que cumplían cada opción desplegada en cada paso del protocolo. ❖ Guardar datos del diagnóstico final como la información del paciente (sexo, rango de edad y enfermedades previas) y las opciones que se han elegido durante la ejecución del protocolo. ❖ Búsqueda de diagnóstico guardado a través del código de identificación, con la posibilidad de establecerle el estado exitoso o incorrecto, en función de si finalmente resultó ser correcto. 4.2 Trabajos futuros Como se ha comentado anteriormente, a pesar de tener una aplicación que podría comenzar a usarse ya, aún tiene margen de mejora con la implementación de algunas funciones más. En primer lugar, la funcionalidad que actualmente existe para buscar diagnósticos guardados y establecerlos como correctos o incorrectos, no tiene realmente mucha utilidad tal y como está planteada ahora, más allá de la recopilación de esta información. Sin embargo, se convierte en una funcionalidad muy interesante si se crea un sistema que, mediante el uso de inteligencia artificial, es capaz de interpretar el acierto de los resultados de los H Que algo no haya salido como hayas querido, no significa que sea inútil. Thomas Edison