Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar

Equation Chapter 1 Section 1 Proyecto Fin de Grado Ingeniería de las Tecnologías de Telecomunicación Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar Autor: Antonio Ariza Llamas Tutor: José Manuel Fornés Rumbao José Manuel Fornés Rumbao Dpto. Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2019 iii Proyecto Fin de Carrera Ingeniería de Telecomunicación Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar Autor: Antonio Ariza Llamas 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, 2019 v Proyecto Fin de Carrera: Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar Autor: Antonio Ariza Llamas 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, 2019 El Secretario del Tribunal vii A mis padres A mis abuelos A mis hermanos ix Agradecimientos Con este trabajo pongo la guinda final a mi época universitaria. Ha sido un duro camino y como siempre digo, la persona que entró aquí y la que sale, son muy distintas. Esta carrera me ha enseñado a valorar, aún más, el trabajo duro, la perseverancia y la dedicación. Entré aquí sin saber qué eran las telecomunicaciones, y me voy sin seguir sabiéndolo, porque las telecomunicaciones, sobre todo en esta era, lo son todo. Esta etapa, a base de palos, me ha demostrado lo dura que es la vida. Y es que, para llegar a la meta, te tienes que tropezar muchas veces antes. Por eso a los primeros que tengo que dar las gracias son a mis principales baluartes, mis padres, que han hecho un esfuerzo enorme porque yo esté aquí y me han demostrado el potencial que dentro de mí encierro. Muchos han sido los consejos que me han dado, algunos los he escuchado, otros menos, pero siempre entendiendo que lo han hecho por mi bien y por el futuro que me espera. Perdonadme por haber sido un poco cabezota y travieso, pero hay cosas que me va a costar trabajo corregir. A mis hermanos, a mis abuelos y a mi familia, también quiero dar las gracias, por estar ahí cuando los he necesitado y por ayudarme mientras estudiaba. No todo ha sido sufrimiento en esta carrera, es obvio, y quién diga lo contrario, miente. Admito que tal vez haya faltado a alguna que otra clasecilla para irme con mis amigos, que he tenido alguna que otra escapada nocturna y que he visto amanecer en el puente de Triana más de una vez. ¿Pero quién no lo ha hecho? Hasta usted, que estás leyendo esto alguna vez has sido joven. Una de las cosas que he aprendido en este tiempo, es que la vida se mide en vivencias y no en años, y de Sevilla me llevo como para escribir un libro. He tenido la suerte de coincidir con un grupo de personas excelentes, compañeros que se han convertido en hermanos, que me han servido de apoyo cuando el tiempo traía tormenta y me han enseñado que lo importante no es el lugar, sino la compañía. Por ello tengo que dar las gracias a mis machos, por sacar mi mejor versión, a mis tabernícolas, porque juntos hemos descubierto que mucha solera y buena ensaladilla es signo de confianza, a mis amigos de toda la vida, porque no somos muy numerosos, pero lo nuestro es amistad de verdad, a pesar de nuestros pequeños conflictos, al Perdón, por recordarme que las tradiciones no deben de morir nunca y al Betis, porque pasará el tiempo y me seguirá demostrando que el “manquepierda” siempre será un lema de vida, una forma de sentir y de vivir. Por último quisiera dar las gracias a mi tutor y a los médicos que me han ayudado a que esto sea posible, porque la verdad, la medicina nunca fue lo mío. Y para acabar, lo haré con una cita de Alberto García Reyes (pregonero de la Semana Santa 2017), que dice así: “Y ante Dios, cuando Dios quiera, mis dos palabras postreras serán Sevilla y amén” Antonio Ariza Llamas Sevilla, 2019 xvii ÍNDICE DE FIGURAS Ilustración 2-1. Causas primarias y secundarias del dolor lumbar 4 Ilustración 2-2. Algoritmo de la evolución natural del dolor lumbar 5 Ilustración 2-3. Escala Visual Analógica (EVA) 6 Ilustración 2-4. Distribución de aplicaciones móviles de salud. Año 2015 7 Ilustración 2-5. Icono Android Studio 7 Ilustración 2-6. Interfaz gráfica de Android Studio 8 Ilustración 2-7. Creación de un usuario MySQL 9 Ilustración 2-8. Pantalla de inicio de sesión en phpMyAdmin 9 Ilustración 2-9. Pantalla principal de phpMyAdmin 10 Ilustración 2-10. Esquema tipo del modelo MVC 10 Ilustración 2-11. Vista general de Gii 11 Ilustración 2-12. Esquema general de funcionamiento de una API REST 12 Ilustración 2-13. Controlador tipo REST 12 Ilustración 2-14. Icono de Google Firebase 13 Ilustración 3-1. Escenario de funcionamiento 15 Ilustración 4-1. Funcionamiento general del algoritmo 18 Ilustración 4-2. Algoritmo para el grado de dolor bajo 19 Ilustración 4-3. Algoritmo para el grado de dolor medio 20 Ilustración 4-4. Algoritmo para el grado de dolor alto 21 Ilustración 4-5. Algoritmo para el grado de dolor muy alto 22 Ilustración 4-6. Lista de ficheros de la aplicación móvil 23 Ilustración 4-7: Pantalla Autenticacion.xml 24 Ilustración 4-8: Pantalla SplashScreen.xml 24 Ilustración 4-9: Pantalla MainActivity.xml 25 Ilustración 4-10: Pantalla PreguntaEjercicio.xml 26 Ilustración 4-11: Pantalla MensajeFormativo.xml 26 Ilustración 4-12: Pantalla EscuelaEspalda.xml 27 Ilustración 4-13: Pantalla PautaAnalgesica.xml 28 Ilustración 4-14: Pantalla MoriskyGreen.xml 29 Ilustración 4-15: Pantalla PautaRescate.xml 29 Ilustración 4-16: Ejemplo de notificación creada 30 Ilustración 4-17: Pantalla MenuInicial.xml 30 Ilustración 4-18: Pantalla MuestraHistorico.xml 31 Ilustración 4-19: Pantalla MuestraConsejos.xml 31 Ilustración 4-20: Pantalla MuestraMedicacion.xml 32 Ilustración 4-21: Pantalla MuestraEjercicio.xml 32 Ilustración 5-1. Estructura de la base de datos 35 Ilustración 5-2. Valores de la tabla “n_actividad_física” 35 Ilustración 5-3. Valores de la tabla “n_estudios” 36 Ilustración 5-4. Valores de la tabla “n_renta” 36 Ilustración 5-5. Valores de la tabla “sexo” 37 Ilustración 5-6. Valores de la tabla “valores_var” 38 Ilustración 5-7. Valores de la tabla “valores_var” 39 Ilustración 5-8. Valores de la tabla “nivel_ejercicio” 39 Ilustración 5-9. Valores de la tabla “valores_medic” 40 Ilustración 5-10. Directorios dentro de la carpeta basic 41 Ilustración 5-11. Ficheros que componen el directorio config 42 Ilustración 5-12. Configuración del fichero db.php 43 Ilustración 5-13. Activación del módulo gii 43 Ilustración 5-14. Creación de un modelo usando gii 44 Ilustración 5-15. Generación de código CRUD usando gii 44 Ilustración 5-16. Vista del modelo Paciente 45 Ilustración 5-17. Ejemplo de uso 45 Ilustración 5-18. Controlador REST 46 Ilustración 5-19. Activación JSONParser 46 Ilustración 5-20. Configuración de web.php 46 Ilustración 5-21. Ejemplo de servicio REST 47 Ilustración 5-22. Modelos creados. 47 Ilustración 5-23. Controladores creados 48 Ilustración 5-24. Vistas creadas 48 Ilustración 5-25: Apariencia de la pantalla inicial 57 Ilustración 5-26: Lista de pacientes 57 Ilustración 5-27: Histórico de dolor 58 Ilustración 5-28: Medicación de los pacientes 58 Ilustración 5-29: Credenciales de autenticación 59 Ilustración 5-30: Listado de tokens 59 Ilustración 5-31: Aspecto general de Firebase 60 Ilustración 5-32: Herramienta Cloud Messaging 60 Ilustración 5-33: Ejemplo de notificación 61 xix 1 1 INTRODUCCIÓN 1.1 Objetivos a lumbalgia es el motivo de consulta más frecuente para un médico de Atención Primaria en relación con la patología del aparato locomotor y está considerada la principal causa de limitación de la actividad en personas menores de 45 años. Es la segunda causa de incapacidad laboral transitoria y una de las causas más frecuentes de invalidez permanente. Por todo ello, la lumbalgia constituye una de las principales causa de consumo de recursos sanitarios y sociales. Estudios demuestran que un 80% de la población tendrá dolor lumbar en algún momento de su vida, lo que, trasladándolo a cifras, en el caso de un país de España con más de 46 millones de habitantes supone que más de 36 millones de personas lo sufrirán al menos una vez. Pero esto no acaba aquí. Hablando del impacto económico que tiene la mencionada patología, esta cuesta a la sanidad española unos 16000 millones de euros, lo que supone un 1,7% del PIB. En resumen, hay pocas patologías con la transcendencia individual, social y económica del dolor lumbar. A esto hay que añadir ya no solo el crecimiento exponencial en el número de usuarios que hacen uso de terminales móviles para realizar sus labores más cotidianas, sino también de aplicaciones móviles del entorno sanitario, conocido como salud móvil. Dentro de la medicina, una de las cosas más importantes es la relación que existe entre médico y paciente, pero también es cierto que, alrededor del paciente, se ponen miles de opciones que refuerzan la labor de los especialistas. Y es aquí donde entran las aplicaciones para el móvil. Las nuevas tecnologías ayudan al paciente, pero también ayuda al médico a diagnosticar y a informarse Teniendo en cuenta todo lo referido, el objetivo principal es crear una aplicación móvil que de manera interactiva y dinámica permita al usuario tener un mayor grado de autonomía en cuanto a la gestión de esta enfermedad se refiere, pero con la seguridad de que la misma le va a aportar formación para el automanejo, conocimiento sobre la enfermedad, recordatorios para disminuir el incumplimiento del tratamiento recomendado y contacto con el profesional sanitario de referencia para abordar adecuadamente las exacerbaciones o crisis. La propia aplicación, le permite al usuario identificar de manera objetiva el grado de dolor mediante una escala analógica visual (EVA) y compararla con los días previos, permitiendo un juicio evolutivo del síntoma principal de este proceso, el dolor. Según el grado de dolor se aconsejarán medidas higiénico-dietéticas, tratamiento farmacológico o incluso gestionar una cita con el profesional responsable si el dolor alcanza un cierto nivel de severidad o se incrementa de forma importante sin causa aparente. En resumen, esta aplicación móvil permite que el paciente aprenda a convivir con el dolor lumbar, mejorando su percepción de su calidad de vida y adecuando el uso de recursos farmacológicos, sanitarios y sociales; a la par que disminuir los eventos adversos relacionados con el consumo de fármacos para controlar el dolor. L Introducción 2 1.2 Estructura del trabajo fin de grado En los siguientes puntos se pone de manifiesto de manera resumida el contenido de los capítulos y anexos que componen este trabajo:  Capítulo 1 – Introducción Capítulo actual, en el mismo se ponen de manifiesto los motivos y causas que han llevado a la realización del mismo así como los objetivos que se quieren conseguir.  Capítulo 2 – Estado del Arte En este capítulo se describen y desarrollan todos los conceptos y entornos necesarios para llevar a cabo la comprensión del documento y el trabajo que en el mismo se desarrolla.  Capítulo 3 – Escenario de funcionamiento Se muestra una visión global y una breve descripción del funcionamiento del conjunto de elementos que componen el proyecto.  Capítulo 4 - Aplicación móvil Dentro de este capítulo se explica desde el algoritmo de funcionamiento de la aplicación móvil hasta el aspecto final de la misma, pasando por la estructura de los ficheros que conforman el proyecto.  Capítulo 5 – Servidor Web Aquí se habla de la configuración de la base de datos así como su estructura y de la configuración y los ficheros que conforman el entorno de trabajo Yii2 así como la aplicación web creada para facilitar al médico las labores de administración de la información del paciente. 3 2 ESTADO DEL ARTE ntes de empezar con el desarrollo de todo lo que incumbe al trabajo fin de grado propiamente, es necesario situarse en un punto de partida para conocer el entorno en el que se va a desarrollar el mismo. Es por ello que es necesario explicar algunos de los conceptos que serán repetidos con asiduidad a lo largo de este documento, así como las distintas herramientas de trabajo para facilitar al lector la total comprensión de este trabajo fin de grado. En este capítulo se explica por una parte todos aquellos conceptos del ámbito sanitario que se van a tratar debido a que el objetivo principal del mismo es controlar el dolor lumbar, luego es competencia del proyectante hacer una descripción del dolor lumbar, explicar cómo se mide y como la tecnología puede ayudar a través de la telefonía móvil. Por otra parte se explican cuáles serán los entornos de desarrollo de la aplicación y que herramientas se usarán para permitir una conectividad entre la aplicación y la base de datos dónde se almacenan todos los datos de pacientes que se usarán para llevar a cabo un estudio que mida la eficacia e impacto de dicha aplicación, aunque esto último está fuera de la competencia de dicho trabajo fin de grado. Luego los conceptos que se van a desarrollar en este capítulo son los siguientes: - Dolor lumbar - Medida del dolor lumbar (EVA) - Salud móvil - Android Studio - MySQL + phpMyAdmin - Yii2 - REST - Firebase 2.1 Dolor lumbar Se conoce lumbalgia como la sensación dolorosa circunscrita a la columna que impide su movilidad con normalidad. En función de la duración puede ser aguda si dura al menos 3 meses y crónica una vez superado ese límite temporal y además se acompaña de intolerancia al esfuerzo. Esta última será objeto de estudio durante este trabajo. En el caso de pacientes con dolor lumbar, la sensación dolorosa puede bien ceñirse únicamente a la región lumbar, o incluir una o ambas extremidades inferiores. Esto recibe el nombre de síndrome lumbar. Si la lumbalgia se acompaña de dolor genital, perianal, anestesia en silla de montar, afección de la micción y/o defecación, recibe el nombre de cola de caballo. Generalmente en el dolor lumbar la sintomatología es mecánica, es decir, aparece con la movilización de la columna y desaparece con el reposo. La segunda sintomatología más frecuente es la inflamatoria, es decir, un dolor continuo, persistente e intenso que a pesar de la inmovilidad no mengua. En la siguiente tabla podemos A Estado del arte 4 ver una tabla con las causas primarias y secundarias del dolor lumbar: Ilustración 2-1. Causas primarias y secundarias del dolor lumbar Referido al dolor lumbar, se tienen 3 grandes síndromes: - Lumbalgia mecánica aguda: también conocida como lumbar, es aquella que se da en periodos inferiores a 3 meses con crisis que pueden ser aisladas o repetidas. Aparece en individuos mayores de 18 años y menores de 50 años. - Lumbociática aguda: es la sensación dolorosa radicular que sigue el trayecto del nervio ciático que puede tener afección motora (ciática) y/o sensitiva (ciatalgia). - Estenosis lumbar: presenta síntomas crónicos, como retención urinaria, anestesia perianal, progresiva debilidad en extremidades inferiores, impotencia sexual (varones) o incontinencia fecal. Como se menciona en el anterior capítulo, el dolor lumbar es una de las principales causa de consulta en atención primaria [1] y una de las causas más frecuentes de absentismo laboral. En España representa la primera causa de baja por incapacidad temporal (IT). Según estudios, se ha relacionado esa incapacidad laboral debido al dolor lumbar con insatisfacción laboral, por tipo de trabajo (rutinario), el lugar de trabajo y el ambiente laboral. La duración de incapacidad laboral se retroalimenta. Es decir, conforme crece el tiempo que una persona está de baja, menos son las posibilidades de que el mismo vuelva en un futuro al puesto laboral que ocupaba. En el siguiente esquema se aprecia la evolución natural del dolor lumbar: 5 5 Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar Ilustración 2-2. Algoritmo de la evolución natural del dolor lumbar Para tratar el dolor lumbar se puede recurrir al tratamiento médico o al tratamiento quirúrgico. Este último no es recomendable pues es extremadamente delicado y sólo está recomendado para procesos que afectan de manera irreversible a la médula espinal o raíces de la misma. En este proyecto el tratamiento que usan los pacientes es médico (excepto aquellos pacientes que puedan tener severas complicaciones). En cuanto al tratamiento médico recomendado se basa en analgesia mediante fármacos orales, que generalmente son antiinflamatorios no esteroideos (AINE) y métodos físicos, y realizar ejercicio físico mientras sea posible. No es recomendable superar los 2 días de reposo absoluto, pues además de no mejorar los problemas lumbares puede empeorar la situación. La medicación más prescrita son los AINE (por ejemplo, Ibuprofeno) y pueden combinarse junto con relajantes musculares durante 7-14 días. Los narcóticos u opiáceos pueden usarse durante un escaso intervalo de tiempo debido a los efectos secundarios de los mismos, tales como debilidad, somnolencia o riesgo de adicción. Se ha demostrado de la eficacia de las escuelas de espalda en la reducción de paciente con lumbalgias temporales y crónicas. Para finalizar, hay que decir que en el caso de pacientes que sufren alguna de las manifestaciones de dolor lumbar, lo más importante devolverlos a su vida habitual con la mayor rapidez posible para evitar que la incapacidad lumbar se vuelva crónica. En este trabajo se van a estudiar pacientes que ya tienen un dolor lumbar crónico. 2.2 Medida del dolor lumbar (EVA) Dado que en general, los pacientes que se tratan no tienen el conocimiento necesario para conocer cuáles son los síntomas reales que sufre en su dolor lumbar, es necesario buscar una manera de medir el grado de dolor lumbar. Para valorar la intensidad del dolor lumbar, se pueden bien recurrir a dibujos visuales que puedan expresar el grado de dolor o bien (como es el caso) a una Escala Visual Analógica (EVA). La EVA, permite medir la intensidad del dolor que describe el paciente con la máxima reproducibilidad entre observadores. Se trata de una línea en cuyos extremos se encuentran las expresiones extremas de un síntoma. El extremo izquierdo es el grado de menor intensidad y el extremo derecho el de máxima intensidad. En el caso de este proyecto se usa una EVA modificada. Donde se tienen 4 grados de dolor: - Dolor bajo: 0-3 Estado del arte 12 En el siguiente esquema se puede apreciar el funcionamiento general de una API REST: Ilustración 2-12. Esquema general de funcionamiento de una API REST Yii ofrece todo un conjunto de herramientas para simplificar la tarea de implementar un servicio web APIs RESTful. Esto es de ayuda no sólo para facilitar la labor de obtener, crear, modificar o borrar recursos, sino también porque aumenta la seguridad e integridad de todos los datos contenidos en la base de datos. Dicho controlador tiene la siguiente estructura: Ilustración 2-13. Controlador tipo REST En el capítulo X se explica con más profundidad los tipos de controladores, modelos y vistas que van a ser usados en Yii. 2.8 Firebase La idea de la aplicación móvil es que el paciente pueda interactuar hasta cierto grado con el médico. Una de las medidas que se implantan son las notificaciones. Para llevar a cabo dicha tarea se hace uso de Firebase. 13 13 Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar Fibase [8] es una potente plataforma de Google cuya finalidad es ayudar a desarrollar apps para que cualquier persona, a pesar de no ser un desarrollar, pueda crear sus aplicaciones móviles de manera sencilla. De entre todas las herramientas que posee, en este trabajo únicamente se va a hacer uso de una de ellas, la Cloud Messaging. Ilustración 2-14. Icono de Google Firebase Cloud Messaging permite enviar mensajes a cualquier dispositivo móvil. Estos mensajes pueden enviarse bien personalizados únicamente a una persona o bien a un grupo de usuarios que se han suscrito a un determinado tema. También puede programarse de manera que se envían mensajes a modo recordatorio. En el caso de esta aplicación, por ejemplo, se programan envíos de mensajes para recordar al paciente que tome su medicación. Lo mejor de todo es que permite todo esto sin necesidad de programar absolutamente nada y de manera bastante interactiva para facilitar la labor al médico. En el próximo capítulo se detalla cómo se produce este envío desde la plataforma a la aplicación móvil. Estado del arte 14 15 15 Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar 3 ESCENARIO DE FUNCIONAMIENTO ara empezar con el desarrollo del trabajo, en este capítulo se va a mostrar un esquema general de todo lo que el trabajo implica para que el lector pueda tener una visión en conjunto de los distintos componentes que engloban el escenario de trabajo. En el siguiente esquema se puede tener una visión global del escenario de funcionamiento que en los próximos capítulos se detalla con más profundidad: Ilustración 3-1. Escenario de funcionamiento En el esquema se distinguen dos partes, cliente y servidor web: - Cliente: está formado por el dispositivo móvil, que contiene la aplicación móvil. - Servidor web: (en el que corre CentOS 7) contiene por una parte el entorno de trabajo Yii2 que contiene una aplicación web y dentro de esta una API REST y la base de datos dónde se guardan todos los datos de los pacientes. El funcionamiento es el siguiente: 1) La aplicación móvil que ha sido desarrollada en Android Studio y posteriormente instalada en el terminal móvil, lanza una petición HTTP con el método que se desee (GET, POST, PUT, DELETE) junto con los parámetros que sean necesarios para completar dicha petición a una dirección URL que depende del servicio REST del que se vaya a hacer uso. P Escenario de funcionamiento 16 2) Como vimos en el capítulo anterior, Yii2 tenía un componente que permitía con relativa facilidad montar un servicio REST. Cuando se recibe una petición por parte de la aplicación móvil, dicho servicio REST contiene la lógica necesaria para hacer la consulta que usuario ha pedido a la base de datos (MySQL). 3) La base de datos recibe una petición por parte del controlador, la procesa y manda la respuesta competente. 4) El controlador recibe esa respuesta de la base de datos. Para que el cliente (aplicación) pueda leer e interpretar el contenido, la misma necesitar pasarse a formato JSON. 5) El cliente recibe una respuesta con formato JSON, que interpreta y actúa en situación. Cómo se puede apreciar, a priori, parece muy sencillo el funcionamiento básico. Hay que tener en cuenta que cuando se hace una petición HTTP, la aplicación móvil se olvida por completo de la lógica de consultas directas a la base de datos, eso es tarea del servicio REST, lo que simplifica el trabajo de manera importante. Es por esto último por lo que actualmente la gran mayoría de empresas de ámbito internacional (Twitter, Amazon, Facebook), implementan servicios REST en sus aplicaciones. Además de esto, se dispone de una app web (cuya apariencia aparece en el capítulo 5), que es usada por el médico para disponer de las funcionalidades básicas que son necesarias para administrar tanto datos como el funcionamiento de sus pacientes. Esta se comunica con Firebase (a través de un enlace web), cuya funcionalidad “Cloud Messasing” es usada, cómo vimos anteriormente, para enviar notificaciones al paciente. Para conseguir enviar una notificación a un determinado paciente se hace uso del token. Un token es un identificador único que, en este caso, da Google para identificar a un usuario que usa una determinada aplicación. Este puede ir cambiando bien cuando se instala o desinstala o cuando pasa un período de tiempo determinado. La aplicación móvil registra cuando ese token cambia y, a través de un servicio REST, lo modifica en la base de datos a fin de que el médico disponga de la información actualizada. En los próximos capítulos se va a mostrar todo lo relacionado con el algoritmo, funcionamiento y visualización de la aplicación móvil así como la configuración del servidor web ya sea tanto de la base de datos como del entorno de trabajo Yii2. 17 17 Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar 4 APLICACIÓN MÓVIL n este capítulo se va a desarrollar en profundidad todo lo que envuelve a la aplicación móvil, desde el algoritmo, pasando por la estructura de los ficheros que conforman el proyecto hasta el aspecto final de que tiene la aplicación una vez está en ejecución. Para organizar este capítulo a fin de clarificar todos los conceptos que se van a explicar a lo largo del mismo y que de esa forma el lector pueda tener una mejor compresión del mismo, se va a dividir el mismo en 2 apartados: - Algoritmo: dónde se va a explicar con profundidad cual es el algoritmo general que está detrás de la aplicación. - Estructura de ficheros: dónde se muestra cuáles son y cuál es la estructura de los ficheros más relevantes que conforman la aplicación móvil. Además se muestran capturas de las distintas pantallas que conforman la aplicación móvil a fin de que se pueda ver visualmente lo que en los dos apartados anteriores se explica. 4.1 Algoritmo Cómo se ha dicho en capítulos anteriores el objetivo principal del trabajo es crear una aplicación para que los pacientes con dolor lumbar crónico diagnosticado tengo un mejor autoconocimiento de su dolencia y de esa manera puedan llevar un seguimiento diario de la misma. La base de todo el algoritmo se apoya sobre la Escala Visual Analógica (EVA) modificada, es decir, a diario se pregunta al paciente cuál es su grado de dolencia en ese mismo día. En función de su dolor, la aplicación va a actuar en consecuencia a fin de conseguir que la dolencia sea la mínima posible. Dado que el grado de dolor del paciente (usuario), puede cambiar de un día a otro, es necesario establecer una lógica de actuación. En primer lugar hay que resaltar que existen 4 grados (grupos) de dolor: - Dolor bajo: Desde el valor 0 hasta el valor 3 - Dolor medio: Desde el valor 4 hasta el valor 5 - Dolor alto: Desde el valor 6 hasta el valor 7 - Dolor muy alto: Desde el valor 8 hasta el valor 10 Los valores son números enteros e indican el nivel de dolor que el paciente tiene ese día. Establecido los grados de dolor, se necesita también una serie de variables generales que nos permitan definir un comportamiento, que se encuentran guardadas en la base de datos. Ya que todavía no se ha explicado la estructura que tiene la base de datos debido a que forma parte del servidor, es posible que al principio exista algo de confusión, es por ello que se van a usar nombres para las variables muy indicativos, evitando que exista algún tipo de malentendido. Las variables que se van a usar dentro del programa son las siguientes: - Día: es una variable que indica los días que una persona se ha encontrado en el nivel de dolor más bajo. Está estrechamente relacionada con la siguiente variable. - Ejercicio: indica los días que el paciente (durante una semana) ha realizado los ejercicios físicos. Cómo se explicó en el apartado 3.1, el ejercicio físico es clave en la recuperación del paciente. E Aplicación Móvil 18 - Nivel ejercicio: dado que existen distintos programas de entrenamiento, el paciente puede tener una serie de ejercicios con mayor o menor intensidad. Esta variable indica dicho nivel de entrenamiento. - Pauta analgésica: el médico generalmente va a tener 3 tipos de medicaciones en función del grado de dolor que la persona sienta a fin de calmar su dolor. Esos 3 tipos de medicaciones son una basal (para tomar día a día), otra analgésica cuando el dolor crece y por última una pauta de rescate, cuando el dolor es alto. Con esta variable se indica los días que un paciente lleva tomando dicha pauta analgésica. - Pauta rescate: similar a la variable anterior, pero en este caso se indican los días que un paciente lleva tomando una pauta de rescate. - Nivel alto: aunque ahora no tiene sentido, cuando se explique el siguiente apartado sí que lo tendrá. Es una bandera que indica si el paciente está en el nivel de dolor alto. Sabiendo esto, la estructura general del algoritmo es la siguiente: Ilustración 4-1. Funcionamiento general del algoritmo El esquema anterior muestra a grande rasgos cual es el funcionamiento que va a tener el algoritmo en general. En los siguientes sub-apartados se explica detallado todos los procesos que involucran cada uno de los 4 grados de dolor. Hay que tener una cosa en cuenta y es que cada vez que se entra en un grado de dolor, las variables de los otros niveles se ponen a cero. Estas son las siguientes: 19 19 Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar - Grado de dolor bajo: día, ejercicio y nivel de ejercicio. - Grado de dolor medio: pauta analgésica y pauta rescate. - Grado de dolor alto: nivel alto. 4.1.1 Grado de dolor bajo En el grado de dolor bajo, el paciente está en condiciones de realizar ejercicio físico, esto es un factor fundamental pues sobre el mismo se va a definir el comportamiento del algoritmo en este nivel. El comportamiento para dicho grado de dolor es el siguiente: Ilustración 4-2. Algoritmo para el grado de dolor bajo Como se ha mencionado anteriormente, el ejercicio físico es determinante para mejorar la dolencia lumbar. En este grado de dolor, se da por supuesto que el paciente está en condiciones de realizar ejercicio físico. Luego siempre que se entra en este nivel lo primero que se hace es preguntar por el ejercicio físico. En función de si lo ha realizado o no, la variable ejercicio aumentará o no. La variable día aumenta cada vez que se pregunta sobre la realización del ejercicio físico hasta llegar a 7, es decir, una semana. Pasado una semana pueden pasar dos cosas: - El paciente ha realizado ejercicio físico al menos 3 días durante esa semana, lo que implica que se puede aumentar la intensidad de los ejercicios para la próxima semana. - El paciente no ha realizado ejercicio físico al menos 3 días. En este caso se muestra un mensaje motivador para incitar al paciente a llevarlos a cabo. Para favorecer dicha labor, se baja la intensidad de los ejercicios para la próxima semana. Además de esto, todas las veces que se entra en este nivel se muestra un mensaje formativo para, valga la redundancia, formar al paciente en todo lo relacionado con su dolencia. Para finalizar, y es una constante que se va a repetir en todos los niveles, es que tras realizar todo lo anterior Aplicación Móvil 20 mencionado, se muestra un menú inicial dónde el paciente puede: - Consultar un histórico de su dolor. - Consultar su mediación actual. - Consultar consejos sobre medicación, alimentación y ejercicio físico. - Consultar su entrenamiento actual. 4.1.2 Grado de dolor medio En este grado, la persona ha visto aumentado el dolor. Para paliar dicho dolor, se recurre a subir la analgesia, ya sea a través de una pauta analgésica o bien, si pasados unos días la sensación dolorosa no aminora, con una pauta de rescate. En el siguiente diagrama de flujo se muestra dicho comportamiento: Ilustración 4-3. Algoritmo para el grado de dolor medio El funcionamiento en este grado de dolor es el siguiente. Lo primero que se hace es comprobar si el paciente tiene ya puesta una pauta analgésica, es decir, si no es la primera vez que el paciente ha entrado a este grado de dolor. Pueden pasar tres cosas: - El paciente no tiene una pauta analgésica, luego hay que poner una nueva pauta. Cabe recordar que en este nivel aparece una variable llamada “Pauta analgésica” cuyo valor es el número de días que un paciente lleva con la misma. Cada día que pasa con la misma, se incrementa el valor de la misma. - El paciente tiene ya puesta una pauta pero lleva menos de 3 días con ella. En este caso se muestra por 21 21 Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar pantalla un mensaje informativo para un mejor conocimiento de su dolencia. - El paciente tiene ya puesta una pauta y lleva 3 días con la misma. En este caso aparece el conocido test de Morisky-Green. El test de Morisky-Green es una serie de 4 preguntas para comprobar que el paciente cumple con la toma de medicación indicada. Las preguntas que se hacen son las siguientes: - ¿Olvida alguna vez tomar los medicamentos para tratar su enfermedad? - ¿Toma los medicamentos a las horas indicadas? - Cuando se encuentra bien, ¿deja de tomar la medicación? - Si alguna vez le sienta mal, ¿deja usted de tomarla? Las respuestas posibles son “SI” o “NO”. Se consideran pacientes que cumplen el tratamiento a quienes contestan NO a las cuatro preguntas y no cumplidores a quienes contestan SI a una o más. Tras hacer dicho test, el resultado puede arrojar dos resultados: - Positivo. Si esto es así se considera que el paciente es cumplidor y que por lo tanto la medicación no está funcionando adecuadamente. En este caso se procede a poner una pauta de rescate (si no la tenía ya puesta). Al igual que con el caso de la variable “Pauta analgésica”, la variable “Pauta rescate” indica el número de días que el paciente lleva con su pauta de rescate. - Negativo. En este caso el paciente se considera no cumplidor y por lo tanto se muestra un mensaje recordatorio para que tome la medicación y se pone a cero la variable “Pauta analgésica”, pues esto quiere indicar que no está haciendo caso de las recomendaciones médicas. Si el paciente lleva 2 días con la pauta de rescate sin encontrar mejora, se procede a dar cita con el médico que lleve el historial de dicho paciente. Tras esto se ponen las dos variables que se han mencionado a cero. 4.1.3 Grado de dolor alto En este nivel, el dolor ya es bastante severo. El funcionamiento es el siguiente: Ilustración 4-4. Algoritmo para el grado de dolor alto Aplicación Móvil 28 Ilustración 4-13: Pantalla PautaAnalgesica.xml - MoriskyGreenX: hay 4 ficheros Morisky-Green, 1 por cada pregunta que se va a realizar. El fichero MoriskyGreen1, MoriskyGreen2 y MoriskyGreen3, muestran una estructura prácticamente similar. Muestra por pantalla una pregunta y el paciente puede elegir entre seleccionar “Sí” o “No”. Si el paciente en alguna de las preguntas responde “Sí” significa que es no cumplidor y por lo tanto se muestra por pantalla un mensaje recordatorio (MensajeRecordatorio). Si responde “No” se pasa a la pantalla inmediatamente superior. El fichero MoriskyGreen4, además de tener integrado este funcionamiento, añade otro más. Se consulta el valor de “Pauta Rescate” y de “Nivel alto”. En función de los valores pueden pasar tres cosas: A. Si “Pauta Rescate” es igual a 0 y “Nivel alto” es igual a 0, significa que el paciente necesita una nueva pauta de rescate (Pauta Rescate). B. Si “Pauta Rescate” esta entre 0 y 3 y además “Nivel alto” es igual a 0, significa que el paciente está siguiendo el tratamiento que le ha sido impuesto, luego se muestra por pantalla un mensaje informativo (Mensaje Informativo). C. Si “Pauta Rescate” es igual a 3 y además “Nivel alto” es igual a 0, significa que la pauta de rescate no está siendo efectiva y el paciente necesita ser visto por el médico, luego se da cita con el mismo (Cita Médico). D. Si “Nivel alto” es igual a 1, significa que estamos en el grado de dolor alto y por lo tanto hay que proceder a subir la analgesia al paciente (PautaAnalgesica). Todo esto se hace para que de alguna manera se puedan reutilizar ficheros, ya que el test de Morisky- Green se puede preguntar tanto en el grado de dolor medio como en el grado de dolor alto. 29 29 Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar Ilustración 4-14: Pantalla MoriskyGreen.xml - PautaRescate: muestra por pantalla la pauta de rescate que el paciente tiene asignada. Ilustración 4-15: Pantalla PautaRescate.xml - Recordatorio: cuando el resultado de Morisky-Green es negativo, es decir, el paciente no cumple con la toma de su medicación y por lo tanto se muestra por pantalla un mensaje recordando de la importancia de cumplir con las indicaciones médicas. - MyFireBaseMessasingService: la aplicación móvil puede recibir notificaciones que el médico puede mandar desde el servicio de Google Firebase. Para controlar dichas notificaciones y que se puedan mostrar por pantalla, se crea esta clase Java. Aplicación Móvil 30 Ilustración 4-16: Ejemplo de notificación creada - MenuInicial: este fichero muestra un menú donde se dan 4 posibles opciones: A. Consultar un histórico de su dolor (MuestraHistorico). B. Consultar su mediación actual (MuestraMedicacion). C. Consultar consejos sobre medicación, alimentación y ejercicio físico (MuestraEjercicio). D. Consultar su entrenamiento actual (MuestraConsejos). Este es el punto final de todo el algoritmo, es decir, cuando se acaban todos los procesos de los distintos grados de dolor, la pantalla final a la que se va es a la que muestra este fichero. Ilustración 4-17: Pantalla MenuInicial.xml - MuestraHistorico: su función es tomar los datos que han sido registrados en la base de datos del histórico de dolor de un paciente para un determinado mes (que el paciente puede elegir) y mostrar por pantalla dos gráficas: A. Una gráfica lineal en la parte superior con todos los niveles (valores) de dolor registrados para ese mes. B. Una PieChart que contiene el tanto por ciento que representa cada uno de los 4 grados de 31 31 Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar dolor durante el mes seleccionado. En caso de que el mes seleccionado no se encuentre registrado, se lanza un aviso por pantalla avisando de lo mismo. Ilustración 4-18: Pantalla MuestraHistorico.xml - MuestraConsejos: la idea es que el paciente al acceder a este fichero, pueda consultar de manera aleatoria uno de los múltiples consejos que han sido introducido en la base de datos. Ilustración 4-19: Pantalla MuestraConsejos.xml - MuestraMedicacion: con este fichero el paciente puede consultar cual es a día de hoy su medicación actual para no perder nunca referencia. Aplicación Móvil 32 Ilustración 4-20: Pantalla MuestraMedicacion.xml - MuestraEjercicio: el ejercicio es fundamental en la recuperación del dolor de espalda. En esta pantalla se muestra una lista con enlaces a vídeos (que generalmente serán de Youtube) que muestran una serie de ejercicios que el paciente puede realizar (siempre que esté en condiciones de ello). Por cada video se le asigna un objeto de la clase YoutubeVideos. Ilustración 4-21: Pantalla MuestraEjercicio.xml - VideoAdapter: contiene toda la lógica necesaria para mostrar por pantalla una lista con todos los vídeos que han sido tomado de la base de datos. - YoutubeVideos: contiene la clase YoutubeVideos que se usa en MuestraEjercicio para asignar a cada vídeo un objeto del tipo anterior. 33 33 Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar Estos son todos los ficheros .java que se usan en el programa, en el próximo capítulo se muestra cada uno de los layout asociados a cada clase y cuál es el aspecto final de los mismos una vez ejecutada la aplicación. Servidor Web 34 5 SERVIDOR WEB En el capítulo anterior se explicó el algoritmo que hay detrás de la aplicación móvil, contenido de los ficheros que la componen así como la vista final de la misma. No se hizo mención aún de como la aplicación móvil se comunica con el servidor web y de cómo y dónde este guarda toda la información que recoge de la misma. En este capítulo se explica con detalle todo aquello relacionado con el servidor web, es decir, la estructura, descripción y campos de cada una de las tablas que componen la base de datos, la configuración del entorno de trabajo Yii2 y una descripción de cada uno de los servicios REST que la aplicación móvil usa a fin de obtener los datos necesarios para su correcto funcionamiento. El capítulo se divide en los siguientes apartados: - Base de datos - Configuración de Yii2 - Servicios REST - Aplicación web Antes de empezar cabe mencionar que el servidor corre en una máquina virtual (VMWare Workstation 15 Player) de CentOS7. Tras arrancarlo por primera vez se ha instalado el servidor Apache, el programa MySQL y phpMyAdmin, y por último el entorno de trabajo Yii2. Una vez todo está configurado, se comprueba desde un ordenador que se encuentre en la misma red privada (esto es debido a que la versión de CentOS 7 utilizada no posee interfaz gráfica) que tanto Yii2, MySQL y phpMyAdmin corren correctamente. A partir de este punto, ya se está en disposición de configurar todo lo necesario para conseguir el objetivo principal del trabajo. 5.1 Base de datos Cómo se explicó en el apartado 2.5, para facilitar la labor de creación de la base de datos, que recibe el nombre de appache (del ingés, app + ache, en español, aplicación + dolor) se ha hecho uso de MySQL y de phpMyAdmin. La siguiente figura muestra las tablas y relaciones de dicha base de datos: 35 35 Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar Ilustración 5-1. Estructura de la base de datos Las tablas que componen la base de datos son las siguientes: - municipios: contiene los municipios a los que los pacientes pertenecen: 1. id_municipio (int, 11, clave primaria): identificador único de municipio. 2. Nombre_municipio (varchar, 30): contiene el nombre del municipio. - n_actividad_fisica: dado que cada paciente puede realizar con mayor o con menor frecuencia ejercicio físico ya sea por cuestiones meramente físicas o bien por cuestiones laborales, se hace una clasificación del nivel de actividad física al que se somete cada paciente: 1. id_actividad (int, 11, clave primaria): identificador único de nivel de actividad física. 2. nivel (varchar, 20): contiene una descripción de dicho nivel. Ilustración 5-2. Valores de la tabla “n_actividad_física” Servidor Web 36 - n_estudios: cada paciente puede tener un menor o mayor formación académica. Es interesante recoger dicha información, es por ello que se hace una distinción por niveles de estudio. Sus campos son los siguientes: 1. id_estudio (int, 11, clave primaria): identificador único de nivel de actividad física. 2. nivel_estudios (varchar, 20): contiene una descripción para dicho nivel de estudios. Ilustración 5-3. Valores de la tabla “n_estudios” - n_renta: el nivel de renta también puede influir en el dolor de espalda, pues se asocia a trabajos más físicos con mayores probabilidades de aparición de dolores lumbares. Los campos que componen esta tabla son los siguientes: 1. id_renta (int, 11, clave primaria): identificador único de nivel de renta. 2. nivel_renta (varchar, 15): descripción de dicho nivel de renta. Ilustración 5-4. Valores de la tabla “n_renta” - sexo: contiene los sexos de los pacientes. 1. id_sexo (int, 11, clave primaria): identificador único del sexo. 2. sexo (varchar, 6): nombre del sexo. 37 37 Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar Ilustración 5-5. Valores de la tabla “sexo” - paciente: esta tabla es fundamental, pues contiene todos los datos de relevancia de un paciente. Los campos que lo componen son los siguientes: 1. NID (int, 11, clave primaria): es un identificador único de paciente. Es fundamental en muchas otras tablas, pues identifica al paciente de manera unívoca. 2. NUHSA (varchar, 14): dado que un principio, este proyecto está pensado para Andalucía, es importante el Número Único de Historia de Salud de Andalucía. 3. Apellido1 (varchar, 20): contiene el primer apellido del paciente. 4. Apellido2 (varchar, 20): contiene el segundo apellido del paciente. 5. Nombre (varchar, 20): contiene el nombre del paciente. 6. Fech_nacimiento (date): fecha de nacimiento del paciente. 7. sexo (int, 11): sexo del paciente. Su valor depende de la tabla “sexo”. 8. municipio (int, 11): municipio del paciente. Su valor depende de la tabla “municipio”. 9. a_fisica (int, 11): nivel de actividad física. Su valor depende de la tabla “n_actividad_fisica”. 10. n_renta (int, 11): nivel de renta. Su valor depende de la tabla “n_renta”. 11. num_telef (varchar, 45): número de teléfono del paciente. 12. correo_E (varchar, 45): correo electrónico del paciente. 13. n_estudios (int, 11): nivel de estudios. Su valor depende de la tabla “n_estudios”. - hist_eva: una de las tablas más importantes, pues contiene el nivel de dolor de un paciente para un determinado día. Sus campos son: 1. NID (int, 11, clave primaria): identificador único de paciente. 2. Valor (tinyint, 4): nivel de dolor del paciente. 3. Fecha (date): fecha de registro de dicho nivel de dolor. 4. Num_hist (int, 11, clave primaria): número que representa dicho registro. - v_clinicas: contiene variable clínicas propias del paciente que es interesante registrar para tener en cuenta. Está formada por: 1. NID (int, 11, clave primaria): identificador único del paciente. 2. Peso (varchar, 45): contiene el peso del paciente. 3. Talla (varchar, 45): contiene la altura del paciente. 4. IMC (varchar, 45): contiene el valor Índice de Masa Corporal del paciente. 5. T_art_sistolica (varchar, 45): valor de la tensión arterial sistólica del paciente. 6. T_art_diastólica (varchar, 45): valor de la tensión arterial diastólica del paciente. - antecedentes: para sacar conclusiones finales es importante conocer los antecedentes médicos del Servidor Web 44 La creación de un modelo usando gii es bastante intuitiva como se puede ver en la siguiente imagen: Ilustración 5-14. Creación de un modelo usando gii Además de modelos, gii permite generar código CRUD (Create, Read, Update, View) para qué, directamente, a través del navegador web se pueda crear una vista dónde se puedan ver, crear, actualizar y leer, todos los registros de una determinada tabla de la base de datos creada: Ilustración 5-15. Generación de código CRUD usando gii - Model Class: se introduce la ruta del modelo que se va a usar app\models\Country - Search Model Class: el módulo de búsqueda se genera automáticamente si no ha sido creado previamente app\models\CountrySearch - Controller Class: se introduce la ruta del controlador de dicha vista, en este caso app\controllers\CountryController - View Path: se introduce la dirección de la vista que se va a usar para visualizar dicho modelo. 45 45 Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar Si se introduce en el navegador “http://hostname/paciente” se muestra de la siguiente forma: Ilustración 5-16. Vista del modelo Paciente Haciendo click en “Create Nombre_de_la_vista” o en algunos de los iconos que aparecen al final de cada fila se puede crear, ver, editar o borrar un determinado elemento (en este caso, un registro de dolor): Ilustración 5-17. Ejemplo de uso Además de esto, en el apartado 2.7 se mencionó y explicó que la aplicación móvil iba a hacer uso de servicios REST. Yii2 permite crear controladores REST [11] de tal manera que, desde la aplicación móvil no sea necesario programar cada una de las consultas a la base de datos. El contenido de dicho controlador (1 por modelo que vaya a ser usado) es el siguiente: Servidor Web 46 Ilustración 5-18. Controlador REST Además de crear cada uno de estos controladores, es necesario modificar (de nuevo) el fichero de configuración web.php. En este caso lo primero que se hace es habilitar el “JSONParser”, ya que la aplicación móvil está programada en Java y va a manejar objetos tipo JSON: Ilustración 5-19. Activación JSONParser Por último, es necesario activar el urlManager para que a través del navegador web se pueda obtener una vista de lo que el servicio REST muestra. Hay que añadir una línea por cada controlador REST que vaya a ser usado: Ilustración 5-20. Configuración de web.php 47 47 Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar Desde el navegador ya se puede acceder a ver el contenido de alguno de los servicios que ofrece las APIs REST creadas: Ilustración 5-21. Ejemplo de servicio REST Todos los modelos, controladores y vistas que se han creado se muestran en las siguientes capturas: - Modelos: Ilustración 5-22. Modelos creados. Servidor Web 48 - Controladores: Ilustración 5-23. Controladores creados - Vistas: Ilustración 5-24. Vistas creadas Para tener una visión general de la relación de cada modelo con sus controladores y vista, se suministra al lector la siguiente tabla (en la misma no aparecen los controladores REST, puesto que se le va a dedicar un apartado entero para su explicación en profundidad): Tabla 5-1. Relaciones Modelo-Vista-Controlador (CRUD) Modelo Vista Controlador Medicacion.php medic MedicController.php HistEva.php hist HistController.php Rest.php srest SrestController.php Paciente.php paciente PacienteController.php Sexo.php sexo SexoController.php Consejos.php consej ConsejController.php Antecedentes.php Ejercicio.php Mensajefor.php Mensajeinfor.php Municipios.php antecedentes ejer menfor meninfor municipios AntecedentesController.php EjerController.php MenforController.php MeninforController.php MunicipiosController.php 49 49 Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar Tomamedic.php ValoresRest.php ValoresVar.php NivelEjercicio.php VClinicas.php Autenticacion.php Register.php tomamedic valrest valvar nejercicio vclinicas autenti reg TomamedicController.php ValrestController.php ValvarController.php NejercicioController.php VclinicasController.php AutentiController.php RegController.php Todas las vistas anteriores han sido generadas con Gii haciendo uso de CRUD. No se ha mencionado nada de REST, pues se va a realizar una descripción con más detenimiento en el siguiente apartado cada uno de los servicios REST que la app móvil va a usar. 5.3 Servicios REST En este apartado se va a mostrar una descripción detallada de cada uno de los servicios REST que son usados. Cada vez que es usado alguno de estos servicios REST, en la tabla “rest” que aparece en el apartado 5.1, se crea una nueva entrada en la que aparece un número identificativo del servicio REST junto con el NID (identificador único del paciente) y el momento en el que se ha accedido a él (Timestamp). Esto se hace por el mero hecho de sacar estadísticas o analizar comportamientos que puedan ser de utilidad en un futuro. Al igual que en el apartado anterior, se va a mostrar una tabla. En este caso con los controladores REST que son usados para dar todos los servicios REST (que se describen más adelante): Tabla 5-2. Relaciones Modelo-Vista-Controlador (REST) Modelo Vista Controlador Medicacion.php medicacion MedicacionController.php HistEva.php historico HistoricoController.php Rest.php rest RestController.php Paciente.php pacientes PacientesController.php Consejos.php consejos ConsejosController.php Ejercicio.php Mensajefor.php Mensajeinfor.php Variable.php Autenticacion.php Register.php ejercicio mensajefor mensajeinfor variable autenticación register EjercicioController.php MensajeforController.php MensajeinforController.php VariableController.php AutenticacionController.php RegisterController.php Cada uno de estos controladores se puede usarse en más de una ocasión para dar distintos servicios en función del objetivo que se quiere conseguir. En el caso de Yii, las operaciones que se permiten son las siguientes (se pone como ejemplo el controlador users): - GET: /users: una lista de todos los usuarios página por página; - HEAD: /users: muestra la información general de la lista de usuarios; - POST: /users: crea un nuevo usuario; Servidor Web 50 - GET: /users/123: devuelve los detalles del usuario 123; - HEAD: /users/123: muestra la información general del usuario 123; - PATCH: /users/123 y PUT /users/123: actualiza el usuario 123; - DELETE: /users/123: elimina el usuario 123; - OPTIONS: /users: muestra los verbos compatibles respecto al punto final /users; - OPTIONS: /users/123: muestra los verbos compatibles respecto al punto final /users/123. Es importante saber que Yii2 tiende a pluralizar (añadir una –s) de manera automática los controladores para usarlo en los puntos finales. En los siguientes sub-apartados se hace una descripción de cada uno de los servicios REST que van a ser usados. En la figura 5-6 se puede apreciar un listado en el que aparecen los mismos. 51 51 Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar 5.3.1 Registro EVA Tabla 5-3. Servicio “Registro EVA” Identificativo del servicio REGISTRO EVA Descripción breve Mediante este servicio se registra el nivel de dolor de un paciente en un determinado día URL http://localhost/historicos Método POST Parámetros de entrada  NID (identificador único de paciente)  Valor (nivel de dolor del paciente)  Fecha (fecha actual) Formato respuesta JSON Notas Se añade una –s al final de la URL debido a que Yii pluraliza los controladores. Este servicio es fundamental, pues al final uno de los objetivos principales que se quiere conseguir es llevar un seguimiento de los niveles de dolor durante un determinado tiempo. 5.3.2 Registra Ejercicio Tabla 5-4. Servicio “Registra Ejercicio” Identificativo del servicio REGISTRA EJERCICIO Descripción breve Gracias a este servicio, la respuesta a URL http://localhost/variables Método POST Parámetros de entrada  NID (identificador único de paciente)  Valor (nivel de dolor del paciente)  Fecha (fecha actual) Formato respuesta JSON Notas Se añade una –s al final de la URL debido a que Yii pluraliza los controladores. Este servicio es fundamental, pues al final uno de los objetivos principales que se quiere conseguir es llevar un seguimiento de los niveles de dolor durante un determinado tiempo. Servidor Web 52 5.3.3 Consulta nombre Tabla 5-5. Servicio “Consulta nombre” Identificativo del servicio CONSULTA NOMBRE Descripción breve Con este servicio se puede obtener el nombre del paciente para que sea mostrado en el layout MainActivity.xml URL http://localhost/pacientes/ Método GET Parámetros de entrada  NID (identificador único de usuario) Formato respuesta JSON Notas Únicamente se obtiene el nombre de pila del Paciente 5.3.4 Consulta histórico Tabla 5-6. Servicio “Consulta histórico” Identificativo del servicio CONSULTA HISTÓRICO Descripción breve Mediante este servicio se obtienen todos los registros de dolor de un determinado paciente en un determinado mes. Con estos datos la aplicación móvil crea dos gráficas: - Una con todos los niveles de dolor registrados en ese mes. - Otra con el tanto por ciento que representa cada grado de dolor URL http://localhost/historico/ Método GET Parámetros de entrada  NID (identificador único de paciente)  Mes (mes para el que se quiere obtener el histórico de dolor) Formato respuesta JSON Notas Este servicio es fundamental, puesto que cumple con el objetivo principal del trabajo que es que el paciente lleve un control (seguimiento) sobre la evolución de su dolor 53 53 Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar 5.3.5 Consulta ejercicio Tabla 5-7. Servicio “Consulta ejercicio” Identificativo del servicio CONSULTA EJERCICIO Descripción breve Dado que el paciente puede tener asignado un tipo de entrenamiento en función de su estado actual y del cumplimiento del mismo, se debe consultar el entrenamiento actual del mismo. Se devuelve una serie de URL que son mostradas en la aplicación móvil gracias a una Recycled View. URL http://localhost/ejercicio/ Método GET Parámetros de entrada  Nivel (dificultad de los ejercicios recomendados) Formato respuesta JSON Notas Para conocer con más exactitud cuáles son los grados de dificultad que se han tenido en cuenta, consultad el apartado 5.1. 5.3.6 Consulta consejos Tabla 5-8. Servicio “Consulta consejos” Identificativo del servicio CONSULTA CONSEJOS Descripción breve Mediante este servicio se pueden consultar los consejos disponibles en la base de datos “appache”. URL http://localhost/ consejos Método GET Parámetros de entrada - Formato respuesta JSON Notas Los consejos se muestran de manera aleatoria cada vez que se pincha en el botón “Consejos” del menú inicial de la aplicación móvil. Servidor Web 60 - Notificaciones: está relacionada con la funcionalidad anterior. Es un enlace a Firebase, donde el médico va a poder hacer uso de la herramienta Cloud Messasing, para mandar notificaciones a un paciente o grupos de pacientes. En las siguientes ilustraciones se puede ver cuál es el aspecto del mismo. Ilustración 5-31: Aspecto general de Firebase Ilustración 5-32: Herramienta Cloud Messaging 61 61 Herramienta de autocontrol y seguimiento por parte del paciente de dolor lumbar Ilustración 5-33: Ejemplo de notificación Referencias 62 REFERENCIAS [1] Artículo sobre el dolor lumbar, https://www.elsevier.es/es-revista-medicina-familia-semergen-40-articulo- el-dolor-lumbar-13025464 [2] Ventajas de la salud móvil, https://www.sivsa.com/site/salud-movil-mhealth-ventajas/ [3] ¿Qué es mhealth?, http://blog.diagnostrum.com/2015/08/21/que-es-mhealth-2/ [4] Página principal de Android Studio, https://developer.android.com/studio/intro?hl=es-419 [5] Información sobre MySQL, https://neoattack.com/neowiki/mysql/ [6] Introducción a Yii2, https://www.yiiframework.com/doc/guide/2.0/es/intro-yii [7] Ventajas de API REST, https://bbvaopen4u.com/es/actualidad/api-rest-que-es-y-cuales-son-sus-ventajas- en-el-desarrollo-de-proyectos [8] Página principal de Firebase, https://firebase.google.com/?hl=es-419 [9] Configuración de base de datos en Yii2, https://www.yiiframework.com/doc/guide/2.0/es/start-databases [10] Generador de código en Yii2, https://www.yiiframework.com/doc/guide/2.0/es/start-gii [11] Servicio RESTFUL en Yii2, https://www.yiiframework.com/doc/guide/2.0/es/rest-quick-start 11