Integración de FHIR en la Plataforma Web de prescripción de ejercicio físico “MyTraining”

1 Equation Chapter 1 Section 1 Trabajo Fin de Máster Máster en Ingeniería de las Tecnologías de Telecomunicación Integración de FHIR en la Plataforma Web de prescripción de ejercicio físico “MyTraining” Autor: Pablo Carmona Rebollo Tutor: María Teresa Ariza Gómez Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2020 2 3 Trabajo Fin de Máster Máster en Ingeniería de las Tecnologías de Telecomunicación Integración de FHIR en la Plataforma Web de prescripción de ejercicio físico “MyTraining” Autor: Pablo Carmona Rebollo Tutor: María Teresa Ariza Gómez Profesor titular Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2020 4 5 Trabajo Fin de Máster: Integración de FHIR en la Plataforma Web de prescripción de ejercicio físico “MyTraining” Autor: Pablo Carmona Rebollo Tutor: María Teresa Ariza Gómez El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2020 El Secretario del Tribunal 6 7 A mi familia A mis maestros A mis amigos 8 9 Resumen A lo largo de este documento, se explicará de manera detallada todos aquellos aspectos relevantes que forman parte del proyecto y procesos que han sido llevados a cabo para la realización de este, así como, influencias que han motivado su desarrollo. El proyecto consiste en la integración de un estándar para el intercambio de datos de atención médica llamado FHIR (Fast Healthcare Interoperability Resources) en la Plataforma “MyTraining” basada en la e-Salud, una aplicación Web de prescripción de rutinas de ejercicios que permite a las personas con necesidades especiales obtener entrenamiento personalizado, monitorizado y guiado de manera remota. La arquitectura de este proyecto se basa, de manera general, en un servidor FHIR, ejecutado en un contenedor, sobre el que se realizan las acciones y peticiones desde la Plataforma “MyTraining”. Esta aplicación da la oportunidad a un usuario externo de seguir una rutina de ejercicios dada por un especialista, con su correspondiente monitorización, sin tener que desplazarse a un centro especializado en ello con las molestias que eso conlleva. Es tanto, una forma de favorecer un estilo de vida saludable de una forma práctica y sencilla sin tener que moverse de casa para aquellas personas con características especiales, como un avance hacia la normalización y globalización de los datos médicos de las personas en el sistema sanitario. 16 Figura 3.3: Logo de XML Figura 3.4: Logo de Spring Framework Figura 3.5: Módulos de Spring Usados en este proyecto. Figura 3.6: Logo de Spring Boot. Figura 3.7: Logo de Spring Security. Figura 3.8: Logo de Spring Data Figura 3.9: Logo de JDBC Figura 3.10: Logo de Java Beans. Figura 3.11: Logo de Maven. Figura 3.11.1: pom.xml Figura 3.12: Logo de MySQL. Figura 3.13: Esquema del Modelo MVC. Figura 3.14: Logo de BootStrap. Figura 3.15: Logo de HTML5. Figura 3.16: Logo de Youtube. Figura 3.16.1: Código de Youtube. Figura 3.17: Logo de CSS3 Figura 3.18: Logo de JavaScript. Figura 3.19: Logo de DOM. Figura 3.20: Logo de JQuery. Figura 3.21: Logo de AJAX. Figura 3.22: Logo de JQuery AJAX. Figura 3.23: Ejemplo de sintaxis de una consulta simple en AJAX. Figura 3.24: Logo de JQuery Plugin Validation. Figura 3.25: Logo HAPI FHIR Figura 3.26: Logo Docker Figura 3.27: YAML Figura 4.1: Logo de Spring Tool Suite. Figura 4.2: Interfaz Gráfica de STS. Figura 4.3: Visual Studio Code Figura 4.4: Interfaz Visual Studio Code 17 Figura 4.5: Insomnia Figura 4.6: Interfaz Insomnia Figura 4.7: Docker Desktop Figura 4.8: Interfaz Docker Desktop Figura 4.9: Logo de XAMPP. Figura 4.10: Logo de phpMyAdmin. Figura 4.11: Wireshark. Figura 5.1: Diagrama de clases. Figura 5.2: Diagrama crear recurso. Figura 5.3: Diagrama modificar recurso. Figura 5.4: Diagrama eliminar recurso. Figura 5.5: Estructura archivos HAPI FHIR. Figura 5.6: Diagrama de acción de Spring Security. Figura 5.7: SQL Authentication Figura 5.8: Authentication Method Figura 5.9: Filter Method Figura 5.10: RESTAuthenticattionSuccessHandler Figura 5.11: RESTAuthenticattionFailureHandler Figura 5.12: RESTAuthenticattionEntryPoint Figura 5.13: Diagrama ER Base Datos local Figura 6.1: Dar de alta especialista Figura 6.2: Página de Inicio de Sesión. Figura 6.3: Mensaje de Aviso de Credenciales Introducidas Correctamente Figura 6.4: Página principal Figura 6.5: Página principal con menú lateral desplegado de Usuario Especialista. Figura 6.6: Pestaña ‘Usuarios’. Figura 6.7: Página ‘Usuarios’ Figura 6.8: Dar de alta paciente Figura 6.9: Modificar datos de paciente Figura 6.10: Pestaña ‘Observaciones’ Figura 6.11: Observaciones especialistas Figura 6.12: Modificar observación Figura 6.13: Observaciones pacientes 18 Figura 6.14: Pestaña ‘Rutinas ’ Figura 6.15: Página ‘Rutinas’ Figura 6.16: Página ‘Añadir rutina’ Figura 6.16.1: Lista usuarios Figura 6.17: Rutinas de otros usuarios Figura 6.18: Página Rutinas de otros usuarios. Figura 6.19: Página Rutinas asociar rutina a paciente. Figura 6.20: Pestaña Modificar Rutina Figura 6.21: Pestaña Ejercicios Figura 6.22: Página Ejercicios Figura 6.23: Página Añadir Ejercicio Figura 6.24: Ejercicios de otros usuarios Figura 6.25: Página Ejercicios de otros usuarios Figura 6.26: Página Modificar Ejercicio Figura 6.27: Eliminar Ejercicio Figura 6.28: Página Añadir vídeo Figura 6.29: Página Ver vídeo Figura 6.30: Eliminar vídeo Figura 6.31: Página Añadir Ejercicio a Rutina Figura 6.32: Ejercicio asociado Figura 6.33: Ejercicio sin Vídeo. Figura 6.34: Página Ver Ejercicios de Rutina Figura 6.35: Eliminar rutina 1 Figura 6.36: Eliminar rutina 2 Figura 6.37: Descargar rutina Figura 6.38: JSON rutina Figura 6.39: Pestaña Ajustes Figura 6.40: Pestaña Ajustes 2. Figura 6.41: Página Datos de Especialista Figura 6.42: Página Darse de Baja Figura 6.43: Perfil borrado 19 Figura 6.44: Página Ayuda Figura 6.45: Correo. Figura 6.46: Cerrar sesión Figura 6.47.1: Observación paciente Figura 6.47.1: Crear observación paciente Figura 6.48: Rutinas de paciente Figura 6.49: Ejercicios de rutinas de paciente Figura 6.50: Ejercicios de paciente Figura B.1: JDK Figura B.2: MAVEN Figura B.3: Variables de entorno Figura B.4: versión Maven/java Figura B.5: Descarga STS Figura B.6: Inicio STS Figura B.7: Workspace Figura B.8: Descarga de XAMPP Figura B.9: Interfaz XAMPP Figura B.10: phpMyAdmin XAMPP Figura B.11: Docker Desktop Figura B.12: Ubuntu TLS Figura B.13: Paquete kernel linux Figura B.14: Visual studio code Figura B.15: Importar BD Figura B.16: Importar proyecto Figura B.17: Root Directory Figura B.18: Proyecto importado 20 21 1. INTRODUCCIÓN “Cualquier tecnología suficientemente avanzada es equivalente a la magia.” Arthur C. Clarke ctualmente, cada vez se digitalizan más datos médicos, datos que deben estar disponibles y ser comprendidos por entidades médicas de diferentes regiones geográficas y diferentes campos de la medicina. Esto hace necesaria la implementación de una normalización de estos datos, de manera que, sean legíbles y puedan ser explotados por los diferentes sistemas de gestión existentes en los hospitales, etc. FHIR (Fast Healthcare Interoperability Resources) es una norma médica creada por la necesidad de disponer de un conjunto de especificaciones para el intercambio riguroso de datos entre aplicaciones médicas. 1.1. Motivación y Objetivos Existe en la actualidad una fuerte demanda de sistemas que sean interoperables entre sí. Sin embargo, todos conocemos que dicha interoperabilidad no es sencilla con los protocolos y sistemas actuales, muy dependientes de negociaciones, configuraciones o adaptaciones hasta el punto de que dos sistemas que pueden parecer a primera vista casi idénticos son incapaces de comunicarse. FHIR ha sido diseñado desde el punto de vista de las necesidades de las implantaciones y con la idea de que sea sencillo, dentro de lo que cabe, de aprender y utilizar. El principal objetivo de este proyecto es la migración de los mecanismos de gestión de datos médicos o historia clínica de los pacientes de la aplicación Web REST llamada MyTraining a FHIR, así como, la implementación de nuevas funcionalidades a dicha plataforma de prescripción de ejercicio físico. Dicha aplicación pretende favorecer un estilo de vida saludable desde casa mediante rutinas de ejercicios de entrenamiento personalizadas dadas por especialistas a todas aquellas personas con características especiales que necesitan realizar ejercicio físico. MyTraining permitirá tener dos tipos de usuarios, el usuario ‘paciente’ y el usuario ‘especialista’. Los ‘especialistas’ serán los encargados de la gestión de rutinas, ejercicios y ‘pacientes’, mientras que el resto serán atendidos por ellos recibiendo rutinas de entrenamiento personalizadas con videos explicativos y asesoramiento si lo requieren a través de un correo electrónico. Destacar que, también, se podrán registrar observaciones, tanto por parte del especialista para realizar un mejor tratamiento, dejando constancia de valoraciones respecto al paciente, como por parte del paciente para dejar constancia de cómo se ha sentido al realizar cierta rutina. A 22 Mi principal motivación a la hora de realizar este proyecto fue la oportunidad de aprender acerca de los estándares HL7, entre ellos FHIR, que actualmente se encuentra en continuo crecimiento y comienza a asentar las bases de la normalización de la historia clínica de las personas. Además, de la oportunidad de facilitar el tratamiento y cuidado de la salud de pacientes vía telemática. 1.2. Antecedentes Como antecedente principal a nuestro proyecto, debemos destacar principalmente la siguiente línea de trabajo: Plataforma web de prescripción de ejercicios usando Spring Este es un trabajo final de grado que desarrollé en la Escuela Técnica Superior de Ingeniería de Sevilla en el año 2018. En este proyecto se desarrolló una aplicación Web REST que permite gestionar rutinas de entrenamiento para usuarios que quieren realizar ejercicio físico y llevar un estilo de vida saludable de una manera sencilla y sin moverse de casa. La finalidad de este proyecto es la creación de dichas rutinas y su personalización por los especialistas que las crean, para su posterior uso por los usuarios. Dicho trabajo final de grado y las tecnologías utilizadas en él han sido utilizados como base para alcanzar el objetivo deseado. 1.3. Contexto “La práctica de actividad física constituye uno de los pilares fundamentales de un estilo de vida saludable y de una verdadera protección y promoción de la salud.… Aunque existe una gran cantidad de aplicaciones móviles para realizar ejercicio físico …. estas aplicaciones no están adaptadas para colectivos con características especiales que necesitan realizar ejercicio físico, ya sea como prevención o como mejora de determinados problemas en relación con el aparato locomotor (artrosis, dolores musculares…), cardiovascular (hipertensión) o metabólicos (diabetes, colesterol, obesidad...). “ – Artículo: Arquitectura software para la prescripción de ejercicio físico personalizado / Software Architecture for Customized Physical Exercise Prescription (rediris.es) [1][14] Sobre el artículo anteriormente nombrado se establecen las bases de funcionalidad principal de este proyecto. Son muchos los artículos existentes sobre un tema candente hoy dia como es la eSalud. La integración de las tecnologías TIC en el ámbito sanitario es abordada cada vez más asiduamente. A continuación, se mencionan algunos de ellos con una breve descripción: En el artículo“Use of an eHealth tool for exercise training and online contact in people with severe chronic obstructive pulmonary disease on long-term oxygen treatment: A feasibility study” [1][23], se expresa como el uso de eHealth tiene efectos positivos en personas con enfermedad pulmonar obstructiva crónica. Por lo tanto, se evalúa la viabilidad de una herramienta de eSalud utilizada para el entrenamiento de ejercicios y los contactos en línea para personas con enfermedad pulmonar obstructiva crónica grave. 23 En el artículo “Interoperable and discrete eHealth Data Exchange between Hospital and Patient” [1][22], se propone una arquitectura que permita el intercambio seguro de datos entre la aplicación móvil del paciente y la infraestructura del hospital basado en HL7 FHIR. En el artículo “Healthcare in the Age of Interoperability: The Promise of Fast Healthcare Interoperability Resources” [1][2], desde un punto de vista general, se habla acerca de algunas de las características de HL7 FHIR, tales como su interoperabilidad y sus recursos. A continuación, se explican algunos de los conceptos más importantes relacionados para una mejor comprensión del ámbito del proyecto. 1.3.1. HL7 HL7 (Health Level Seven) es una organización internacional nacida en EEUU de desarrollo de estándares globales para facilitar el intercambio electrónico de información sanitaria. En definitiva, su misión es lograr una interoperabilidad clínica real entre los diferentes sistemas de información presentes en las organizaciones de salud. 1.3.2. Estándares HL7 HL7 ha desarrollado un conjunto de estándares que se utilizan en la mayoría de los actuales sistemas. Los estándares HL7 o protocolos HL7 indican cómo se organiza y comunica la información entre dos partes. Estos estándares definen el idioma, la estructura y los tipos de datos requeridos para una integración fluida entre sistemas de salud. Miles de hospitales en todo el mundo utilizan a diario estos estándares para intercambiar información entre sus sistemas. Si hablamos de estándares HL7, hablamos de interoperabilidad en salud. Además de los estándares HL7, existen muchos otros que aparecen a menudo junto a ellos. Los estándares HL7 más importantes son HL7 V2, HL7 V3, CDA, HL7 FHIR y CCOW. Estos cinco son los que se conocen como estándares primarios (HL7 primary standards) y son los más usados para la integración de sistemas y la interoperabilidad. Se muestran a continuación en la figura 1.1. 24 Figura 1.1: Estándares HL7 primarios. A continuación, se procede a mencionar de manera breve las características de cada uno de ellos. 1.3.2.1. HL7 V2 El estándar HL7 V2 es el más usado pero tiene algunos inconvenientes. HL7 V2 tiene una gran flexibilidad y es adaptable a casi todos los casos, pero esta flexibilidad tiene un coste. Este coste es que las diferencias entre distintas implementaciones requieren profundos análisis y mucha negociación para conseguir la integración y, además, hace que sea complicado testear y llevar a cabo pruebas de conformidad. Esta situación impulsó el desarrollo del estándar HL7 V3. 1.3.2.2. HL7 V3 El enfoque de este nuevo estándar es mucho más formal y pretende solucionar algunos de los inconvenientes de su versión anterior. Una de las principales características del estándar HL7 V3 es que está basado en RIM (Reference Information Model), un amplio modelo de objetos de referencia de los datos clínicos. RIM es un modelo de toda la información de los servicios sanitarios, que identifica el ciclo de vida de la mensajería dentro de la actividad clínica. Este modelo es la referencia que se usa para el desarrollo de todo el estándar. Sin embargo, debido a su complejidad y extensión hace que no sea sencillo de implementar. Por ello, la versión 2 está más extendida. 25 1.3.2.3. HL7 CDA El estándar HL7 CDA (Clinical Document Architecture) es un estándar de documento clínico basado en el modelo de datos RIM y en la metodología de trabajo de HL7 V3. Esta especificación tiene el objetivo de facilitar el intercambio de información en forma de documentos entre proveedores de salud y pacientes. CDA puede contener cualquier tipo de información clínica, por ejemplo: informes de alta, informes de radiología, etc. 1.3.2.4. CCOW CCOW (Clinical Context Object Workgroup) es un estándar de interoperabilidad que pretende facilitar la integración de aplicaciones a nivel de uso mediante una técnica denominada Context Management. Esta técnica permite sincronizar y unificar a nivel de interfaz de usuario la información de distintos sistemas que contienen información referida al mismo paciente, procedimiento o usuario. 1.3.2.5. FHIR Por último, y objeto de este proyecto, HL7 FHIR, un estándar de interoperabilidad que combina lo mejor de HL7 V2, HL7 V3 y CDA y se enfoca en facilitar su implementación. Además, usa los estándares web más frecuentes, como XML, JSON y HTTP. FHIR es la abreviatura de Fast Healthcare Interoperability Resources (Recursos de Interoperabilidad Sanitaria Rápida). Los resources o recursos son las piezas clave de FHIR. Más adelante, en el apartado 2 de este documento, nos dedicaremos a comentar FHIR detenidamente. 1.3.3. E-Salud La eSalud (eHealth en su terminología en inglés) es el término con el que se define al conjunto de Tecnologías de la Información y la Comunicación (TICs) que, a modo de herramientas, se emplean en el entorno sanitario en materia de prevención, diagnóstico, tratamiento, seguimiento, así como en la gestión de la salud, ahorrando costes al sistema sanitario y mejorando la eficacia de este. Engloba diferentes productos y servicios para la salud, como aplicaciones móviles, la telemedicina, los dispositivos wearables (para la monitorización que se integran en ropa y accesorios), el Big Data (grandes cantidades de datos), los sistemas de apoyo a la decisión clínica, el Internet de las cosas o los videojuegos de salud, entre otros. 1.3.4. Historia clínica y HCE (Historia Clínica Electrónica) La historia clínica es el conjunto de documentos que contienen los datos, valoraciones e informaciones de cualquier índole, sobre la situación y la evolución clínica de un paciente a lo largo del proceso asistencial. 32 ▪ Los recursos deben ser muy comunes y utilizados en diferentes transacciones de negocio. ▪ Los recursos no deben ser lo suficientemente específicos o detallados como para impedir el apoyo a una amplia gama de transacciones de negocio. ▪ Los recursos deben ser mutuamente excluyentes. ▪ Los recursos deben utilizar otros recursos, pero deben ser más que simples composiciones de otros recursos; cada recurso debe introducir un contenido novedoso. ▪ Los recursos deben organizarse en un marco lógico basado en los elementos comunes del recurso y en lo que éste vincula. ▪ Los recursos deben ser lo suficientemente grandes como para proporcionar contexto; los recursos que contienen sólo unos pocos atributos son probablemente demasiado pequeño para proporcionar un valor significativo. 2.4.1 Recursos empleados A continuación, se proceden a mostrar los recursos que se han empleado para dar forma a este proyecto. 2.4.1.1 Patient Los datos del recurso “Patient” cubren la información sobre el paciente: sus atributos se centran en la información demográfica necesaria para apoyar los procedimientos de cuidado de salud. 2.4.1.1.1 Estructura A continuación, en la figura 2.2, se muestra la estructura de atributos disponibles en el recurso “Patient”. 33 Figura 2.2: Estructura recurso Patient 2.4.1.1.2 Uso Este recurso se genera en la Base de Datos FHIR cada vez que un especialista da de alta a un nuevo paciente. Contiene la siguiente información del paciente: ▪ Identificador ▪ Nombre ▪ Teléfono móvil ▪ Email ▪ Correo electrónico ▪ Fecha de nacimiento ▪ Si está dado de baja o no (activo) 34 2.4.1.1.3 UML Figura 2.3: UML recurso Patient 35 2.4.1.1.4 JSON general Figura 2.4: JSON general recurso Patient 36 2.4.1.1.5 Ejemplo práctico Figura 2.5: Ejemplo recurso Patient 2.4.1.2 Practitioner El recurso “Practitioner” cubre a todas las personas que participan en el proceso de atención médica. 2.4.1.2.1 Estructura A continuación, en la figura 2.2, se muestra la estructura de atributos disponibles en el recurso “Patient”. 37 Figura 2.6: Estructura recurso Practitioner 2.4.1.2.2 Uso Este recurso se genera en la Base de Datos FHIR cada vez que un administrador da de alta a un nuevo especialista. Contiene la siguiente información del especialista: ▪ Identificador ▪ Nombre ▪ Teléfono móvil ▪ Email ▪ Correo electrónico ▪ Fecha de nacimiento ▪ Cualificación 38 2.4.1.2.3 UML Figura 2.7: UML recurso Practitioner 2.4.1.2.4 JSON general Figura 2.8: JSON general recurso Patient 39 2.4.1.2.5 Ejemplo práctico Figura 2.9: Ejemplo recurso Practitioner 40 2.4.1.3 Observation Este recurso recoge mediciones y afirmaciones simples sobre un paciente. 2.4.1.3.1 Estructura A continuación, en la figura 2.10, se muestra la estructura de atributos del recurso “Observation”. 41 Figura 2.10: Estructura recurso Observation 2.4.1.3.2 Uso Este recurso se genera en la Base de Datos FHIR cada vez que un especialista o un paciente crea una nueva observación de un paciente o de la realización de una rutina respectivamente. En el caso del especialista, la observación contiene la siguiente información: ▪ Código que referencia el tipo de observación (Dato biomédico, historia clínica, …) ▪ Descripción ▪ Paciente asociado 48 2.4.1.4.3 UML Figura 2.15: UML recurso CarePlan 49 2.4.1.4.4 JSON general 50 Figura 2.16: JSON general recurso CarePlan 51 2.4.1.4.5 Ejemplo práctico Figura 2.17: Ejemplo recurso CarePlan 52 2.4.1.5 Task Este recurso describe un ejercicio o tarea a realizar. 2.4.1.5.1 Estructura A continuación, en la figura 2.18, se muestra la estructura de atributos del recurso “Task”. Figura 2.18: Estructura recurso Task 53 2.4.1.5.2 Uso Este recurso se genera en la Base de Datos FHIR cada vez que un especialista crea un nuevo ejercicio físico. Contiene la siguiente información del ejercicio: ▪ Identificador ▪ Descripción ▪ Creador/Propietario del ejercicio ▪ Repeticiones o periodicidad del ejercicio ▪ URL de vídeo asociado al ejercicio ▪ Estado de forma recomendado para su realización Parámetros opcionales ▪ Paciente o grupo de pacientes asociados (si el ejercicio está destinado para ser asociado a una rutina, este campo no es necesario) 2.4.1.5.3 UML Figura 2.19: Estructura recurso Task 54 2.4.1.5.4 JSON general 55 56 Figura 2.20: JSON general recurso Task 57 2.4.1.5.5 Ejemplo práctico Figura 2.21: Ejemplo recurso Task 64 aplicaciones independientemente de la plataforma o lenguaje en el que hayan sido desarrolladas. JSON nació como una alternativa a XML, debido a su gran facilidad de uso con JavaScript. Se destaca principalmente porque este formato puede ser leído por cualquier lenguaje de programación, lo cual nos proporciona mayor integridad y flexibilidad. Figura 3.2: Logo de JSON. 3.2.2 Otros formatos (XML) XML ,usado para algunos ficheros de configuración de Spring, es un lenguaje de marcado que define un conjunto de reglas para codificar información de forma que sea legible por un ser humano o por un ordenador. Gracias a la flexibilidad que proporciona, carece de las limitaciones que tiene HTML y puede ser usada para representar cualquier estructura de datos. Como ventaja principal de este lenguaje, cabe destacar que proporciona soporte Unicode, lo cual permite escribir la información en cualquier idioma del mundo. Figura 3.3: Logo de XML 3.3 Tecnologías en el Servidor: Java Spring Framework 3.3.1 Introducción: Spring Este es un framework que se usa para el desarrollo de Servicios y aplicaciones, y como contenedor de inversión de control de código abierto para la plataforma Java. Spring fue escrito para la plataforma J2EE de Java, plataforma orientada al desarrollo de aplicaciones web, y ha ido evolucionando rápidamente hasta el día de hoy, donde podemos encontrar diferentes ramas de desarrollo de la mano de SpringSource y todo su equipo de desarrolladores. Figura 3.4: Logo de Spring Framework 65 Figura 3.5: Módulos de Spring Usados en este proyecto. 3.3.2 Spring Boot Spring Boot es un módulo de Spring que nos permite crear diferentes tipos de aplicaciones autónomas de una manera rápida y sencilla, donde simplemente hay que ejecutarlas, simplificando la creación de dependencias y el despliegue en un servidor de aplicaciones. Principalmente se trata de un mecanismo centrado en una clase principal, la cual tiene una configuración por defecto y que podemos personalizar. Este es compatible con Maven y Gradle, y su formato por defecto para el despliegue es “.JAR”, aunque también soporta “.WAR”. Figura 3.6: Logo de Spring Boot. 3.3.3 Spring Security Spring Security es un módulo que permitirá gestionar todo lo relativo a la seguridad de nuestra aplicación web, desde el protocolo de seguridad, hasta los roles que necesitan los usuarios para acceder a los diferentes recursos de la aplicación. Desde el punto de vista de la autenticación, nos permite comprobar que un usuario exista y permitir el acceso a los recursos de la aplicación, dando autorización a unos recursos u otros según sus credenciales y sus privilegios. Este módulo consta de una serie de elementos, como clases y parámetros en Java, los cuales hay que personalizar para que se adapte de la mejor manera posible al comportamiento y finalidad que queremos llegar a conseguir en nuestra aplicación Web. Figura 3.7: Logo de Spring Security. 3.3.4 Spring Data Spring Framework ya proporcionaba soporte para el acceso a bases de datos como JDBC, Hibernate o JPA, simplificando la implementación de la capa de acceso a datos, unificando la configuración y creando una jerarquía de excepciones común para todas ellas. 66 Spring Data permite cubrir el soporte necesario para todas las tecnologías de persistencia y, además, integra las tecnologías de acceso tradicionales, simplificando el trabajo a la hora de crear las implementaciones concretas. Figura 3.8: Logo de Spring Data 3.3.4.1 Patrón DAO (Data Access Object) Este patrón de diseño software pertenece al catálogo de Core J2EE Patterns de Java, por lo que no es un patrón exclusivo de Spring, aunque es el utilizado para realizar aplicaciones con este framework que hagan uso de la persistencia. El patrón DAO muestra una forma de envolver el conocimiento sobre el acceso a datos, mediante el uso de objetos de acceso a datos para conseguir abstraer y encapsular el acceso a dichos datos. Un objeto DAO permite obtener y guardar datos, manejando la conexión con el sistema de persistencia que se haya implementado. Todo ello lo realiza mediante operaciones atómicas (Creación, actualización, borrado, obtención de registros) en la base de datos, por lo que nunca son necesarias las transacciones. Normalmente, se crea un objeto DAO por cada Objeto que tengamos en nuestra aplicación. 3.3.4.2 JDBC (Java Database Connectivity) JDBC es una API que describe o define una librería estándar para el acceso a Fuentes de datos desde el lenguaje de programación Java, independientemente del Sistema operativo donde se ejecute o de la base de datos a la que se acceda, principalmente orientado a bases de datos relacionales. Figura 3.9: Logo de JDBC Esta API consiste en un conjunto de interfaces y clases escritas en Java. Con estas interfaces y clases estándar, los programadores pueden escribir aplicaciones que conecten con la base de datos, enviar consultas escritas en el lenguaje de consulta estructurada “SQL” y posteriormente procesar los resultados obtenidos. 67 3.3.5 Spring Beans Un bean se define como un componente de software que tiene la particularidad de ser reutilizable. Estos deben cumplir ciertos criterios en java: • Implementación serializable. • Poseer todos sus atributos privados (private). • Poseer métodos “set” y “get” públicos de los atributos privados que nos interese. • Poseer un constructor público por defecto. Figura 3.10: Logo de Java Beans. A diferencia de los beans convencionales que representan una clase, la particularidad de los beans en Spring es que son objetos creados y manejados por el contenedor de Spring. 3.3.6 Construcción y Gestión de Software (Maven) Maven utiliza un Project Object Model (POM) para describir el proyecto de software a construir, sus dependencias de otros módulos y componentes externos, y el orden de construcción de los elementos. Viene con objetivos predefinidos para realizar ciertas tareas claramente definidas, como la compilación del código y su empaquetado. Una característica clave de Maven es que está listo para usar en red. El motor incluido en su núcleo puede dinámicamente descargar plugins de un repositorio, el mismo repositorio que provee acceso a muchas versiones de diferentes proyectos Open Source en Java, de Apache y otras organizaciones y desarrolladores. Maven provee soporte no solo para obtener archivos de su repositorio, sino también para subir artefactos al repositorio al final de la construcción de la aplicación, dejándola al acceso de todos los usuarios. Figura 3.11: Logo de Maven. Todo ello se hará de forma automática sin que el usuario tenga que hacer nada más que definir las dependencias en el formato que mostramos a continuación: 68 Figura 3.11.1: pom.xml 3.4 Persistencia: Base de datos 3.4.1 Introducción: Modelo Relacional El modelo relacional es una alternativa para la organización y representación de la información que se pretende almacenar en una base de datos. Se trata de un modelo teórico matemático que, además de proporcionarnos los elementos básicos de modelado (las relaciones), incluye un conjunto de operadores (definidos en forma de un álgebra relacional) para su manipulación, sin ambigüedad posible. Este modelo, hace relativamente sencilla su representación y gestión por medio de herramientas informáticas, siendo elegido como referencia para la gran mayoría de los sistemas de Gestión de Bases de Datos disponibles en el mercado. Además, también es seleccionado como referencia para la elaboración del esquema lógico de una base de datos en su diseño, junto con herramientas como el álgebra relacional. 69 3.4.2 Gestor MySQL Es un sistema de gestión de bases de datos relacional desarrollado por Oracle Corporation, considerado como el más popular del mundo, además de ser desarrollado y distribuido libremente (Open Source). MySQL es multiplataforma, lo cual da soporte a una amplia lista de sistemas operativos y trae soporte para aproximadamente diez motores de almacenamiento, en los cuales se encuentran InnoDB que es el motor predeterminado, que soporta transacciones y bloqueo de registros. Esto hace de este gestor que posea un alto rendimiento comparado con sistemas similares. Figura 3.12: Logo de MySQL. Por último, este sistema de gestión de bases de datos provee de varias herramientas de gestión y de diseño de bases de datos de forma interactiva y gráfica, como son XAMPP y MySQLWorkbench. Estas herramientas nos han facilitado el diseño y montaje de la base de datos, además de su gestión. 3.5 Tecnologías para la interfaz web de usuario 3.5.1 Patrón Modelo-Vista-Controlador (MVC) El objetivo principal de este patrón es el de realizar una separación de los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones. Para ello, este patrón define tres componentes o módulos básicos: ➢ Modelo: el modelo representa la parte de la aplicación que implementa la lógica de negocio. Esto significa que es responsable de la recuperación de datos convirtiéndolos en conceptos significativos para la aplicación, así como su procesamiento, validación, asociación y cualquier otra tarea relativa a la manipulación de dichos datos. ➢ Vista: es una presentación de los datos del modelo al usuario, estando separada de los objetos del modelo. Es responsable del uso de la información de la cual se dispone para producir cualquier interfaz de presentación de cualquier petición que se presente. ➢ Controlador: gestiona las peticiones de los usuarios. Es responsable de responder a la información solicitada con la ayuda tanto del modelo como de la vista. 70 Figura 3.13: Esquema del Patrón MVC. 3.5.2 Bootstrap (HTML5 + CSS3 + JavaScript) Este es un framework o conjunto de herramientas de código abierto para el diseño de sitios y aplicaciones Web. Contiene plantillas de diseño de tipografía, formularios, botones, cuadros, menús de navegación y otros elementos de diseño basados en HTML y CSS, así como extensiones de JavaScript adicionales. Además es compatible con la mayoría de los navegadores web. Figura 3.14: Logo de BootStrap. 3.5.2.1 HTML5 HTML es un lenguaje de marcado utilizado para definir la estructura y contenido de una página o documento Web. La idea es utilizar un lenguaje para hacer referencia a otros documentos, como archivos, imágenes, videos, audio, etc. Es por tanto que HTML5 se trata de una nueva versión de HTML en la cual se especifican nuevos elementos, atributos y comportamientos. Además, contiene un conjunto más amplio de tecnologías que permite a los sitios Web y a las aplicaciones ser más diversas y de gran alcance. 71 Figura 3.15: Logo de HTML5. A través de HTML5 hemos conseguido alojar videos de Youtube en nuestra aplicación web sin necesidad de subirlos y alojarlos en el servidor físicamente, lo que hubiera supuesto una gran necesidad de recursos para ello. El propio Youtube te proporciona el código para ello. Figura 3.16: Logo de Youtube El código se obtiene pulsando en la opción de en cualquier vídeo de Youtube que quieras y escogiendo . Figura 3.16.1: Código de Youtube 3.5.2.2 CSS3 CSS es un lenguaje usado para definir el estilo o apariencia de las páginas Web, escritas con HTML o de los documentos XML. Este lenguaje se creó para separar el contenido de la forma, a la vez que permite a los diseñadores mantener un control mucho más preciso sobre la apariencia de las páginas. 72 Figura 3.17: Logo de CSS3. 3.5.2.3 JavaScript JavaScript es un lenguaje de programación interpretado, dialecto del estándar ECMAScript. Este estándar es también un lenguaje de programación interpretado, definido como orientado a objetos y basado en prototipos, imperativo y dinámico. Se utiliza principalmente en su forma del lado cliente, implementado como una parte de un navegador web permitiendo mejoras en la interfaz de usuario y páginas web dinámicas. Figura 3.18: Logo de JavaScript. Para interactuar con una página Web se provee al lenguaje JavaScript de una implementación del Document Object Model (DOM). El modelo DOM es esencialmente una interfaz de plataforma que proporciona un conjunto estándar de objetos para representar documentos HTML, XHTML y XML, un modelo estándar sobre cómo pueden combinarse dichos objetos, y una interfaz estándar para acceder a ellos y manipularlos. A través del DOM, los programas pueden acceder y modificar el contenido, estructura y estilo de los documentos HTML y XML, que es para lo que se diseñó principalmente. Figura 3.19: Logo de DOM. Tradicionalmente, JavaScript se venía utilizando en páginas Web HTML para realizar operaciones y únicamente en el marco de la aplicación del cliente, sin acceso a funciones del servidor. Actualmente es ampliamente utilizado para enviar y recibir información del servidor junto con la ayuda de otras tecnologías como AJAX. JavaScript se interpreta en el agente de usuario al mismo tiempo que las sentencias van descargándose junto con el código HTML. 73 3.5.3 Controlador de cliente: JQuery/Ajax 3.5.3.1 JQuery JQuery es la biblioteca ECMAScript más extendida y usada en el mundo. Esta biblioteca de software libre y de código abierto permite simplificar la forma de interactuar con los documentos HTML, manipular el árbol DOM, manejar eventos, desarrollar animaciones y agregar interacción mediante AJAX a páginas Web. Figura 3.20: Logo de JQuery. 3.5.3.2 AJAX, Asynchronous JavaScript And XML AJAX, acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML), es una técnica de desarrollo web para crear aplicaciones interactivas. Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios, mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas completamente, lo que significa aumentar la interactividad, velocidad y usabilidad en las aplicaciones. Figura 3.21: Logo de AJAX. 3.5.3.3 JQuery AJAX JQuery facilita el trabajo con AJAX mediante métodos que simplifican todo el proceso anterior. La más importante es “.ajax()”, que realiza una petición asíncrona y tiene multitud de opciones. Figura 3.22: Logo de JQuery AJAX. En nuestro caso, usaremos AJAX a través del método $.ajax() que es la implementación de dicha tecnología a través de JavaScript, concretamente de la biblioteca JQuery, que es configurado a través de un objeto, el cual contiene todas las instrucciones que necesita JQuery para completar una petición de este tipo. Dicho método es muy útil debido a que ofrece la posibilidad de especificar acciones en caso de que la petición haya fallado o no. Además, al estar configurado a través de un objeto, es posible definir sus propiedades de forma separada, haciendo que sea más fácil la reutilización del código. 80 En este proyecto, se ha empleado para realizar peticiones al servidor HAPI FHIR a modo de pruebas para verificar la correcta comunicación con este y para comprobar que las acciones realizadas en Frontend, tenían su correspondiente efecto en la Base de Datos. Figura 4.5: Insomnia Figura 4.6: Interfaz Insomnia 4.4 Docker Desktop Docker Desktop es una aplicación para Windows y MacOs para la creación y uso compartido de aplicaciones en contenedores. Figura 4.7: Docker 81 Figura 4.8: Docker Desktop 4.5 XAMPP XAMPP es un paquete de instalación independiente de plataforma, software libre, que consiste en el sistema de gestión de bases de datos MySQL, el servidor web Apache y los intérpretes para lenguajes de script: PHP y Perl. El nombre proviene del acrónimo de X (Multiplataforma), Apache, MariaDB, PHP, Perl. Desde la versión "5.6.15", XAMPP cambió la base de datos de MySQL a MaríaDB. El cual es un fork de MySQL con licencia GPL. El programa se distribuye bajo la licencia GNU y actúa como un servidor web libre, fácil de usar y capaz de interpretar páginas dinámicas. Actualmente XAMPP está disponible para Microsoft Windows, GNU/Linux, Solaris y Mac OS X. XAMPP se diseñó para su uso como una herramienta de desarrollo, para permitir a los diseñadores de sitios webs y programadores testear su trabajo en sus propios ordenadores cuando no tienen ningún acceso a Internet. En la práctica, sin embargo, XAMPP se utiliza actualmente como servidor de sitios web, ya que, con algunas modificaciones, es generalmente lo suficientemente seguro para serlo. Con el paquete se incluye una herramienta especial para proteger fácilmente las partes más importantes en una página. Figura 4.9: Logo de XAMPP. 82 phpMyAdmin es una herramienta escrita en PHP con la intención de manejar la administración de MySQL a través de páginas web, utilizando Internet. Actualmente puede crear y eliminar Bases de Datos, crear, eliminar y alterar tablas, borrar, editar y añadir campos, ejecutar cualquier sentencia SQL, administrar claves en campos, administrar privilegios, exportar datos en varios formatos y está disponible en 72 idiomas. Se encuentra disponible bajo la licencia GPL Versión 2. Figura 4.10: Logo de phpMyAdmin. 4.6 Wireshark Wireshark, antes conocido como Ethereal, es un analizador de protocolos utilizado para realizar análisis y solucionar problemas en redes de comunicaciones. Añade una interfaz gráfica y muchas opciones de organización y filtrado de información. Así, permite ver todo el tráfico que pasa a través de una red (usualmente una red Ethernet, aunque es compatible con algunas otras) estableciendo la configuración en modo promiscuo. Permite examinar datos de una red viva o de un archivo de captura salvado en disco. Se puede analizar la información capturada, a través de los detalles y sumarios por cada paquete. Wireshark incluye un completo lenguaje para filtrar lo que queremos ver y la habilidad de mostrar el flujo reconstruido de una sesión de TCP. Wireshark es software libre, y se ejecuta sobre la mayoría de sistemas operativos Unix y compatibles, incluyendo Linux, Solaris, FreeBSD, NetBSD, OpenBSD, Android, y Mac OS X, así como en Microsoft Windows. En este proyecto se ha empleado para capturar el tráfico de la interfaz ‘loopback’ para observar que las peticiones al servidor HAPI FHIR se realizaban correctamente. Figura 4.11: Wireshark 83 5. Diseño del servicio web 5.1 Clases A continuación, se explican brevemente las distintas clases java que hacen que la aplicación web funcione: • UriConstants: En esta clase definimos como variables estáticas las URIs que se emplean para solicitar al servidor a través de AJAX los recursos necesarios. • SQLConstants: En esta clase definimos como variables estáticas las sentencias SQL que ejecuta el servidor en la Base de Datos a través de la implementación del modelo DAO. • UsuarioController, FHIRController, RutinaController, EjercicioController y VideoController: Estas son las clases “Controlador”. Dichas clases poseen una serie de funciones que son llamadas a través de las peticiones realizadas a las URIs y del método utilizado (GET, POST, PUT, DELETE). • UsuarioDaoImpl, ObservacionDaoImpl, RutinaDaoImpl, EjercicioDaoImpl y VideoDaoImpl: Estas clases poseen funciones que son llamadas por la clase “Controlador” correspondiente. Dichas funciones se encargan de ejecutar el código asociado para obtener los datos deseados y mapearlos en un objeto java el cual es devuelto al controlador. Estas clases son implementaciones de las siguientes interfaces: UsuarioDao, ObservacionDao, RutinaDao, EjercicioDao y VideoDao. • Usuario, Observacion, UsuarioLogin, UsuarioRol, Rutina, Ejercicio y Video: Estas clases definen los objetos que maneja el servicio Web, y en ellas se define el constructor, los atributos y métodos correspondientes a cada objeto. • UsuarioRowMapper,UsuarioRowLoginMapper,UsuarioRolRowMapper, RutinaRowMapper, EjercicioRowMapper y VideoRowMapper: Estas clases permiten la realización de un mapeo entre los datos obtenidos de la BBDD a través de un objeto DAO a un objeto Java determinado. • SecurityConfiguration,RESTAuthenticattionSuccessHandler, RESTAuthenticationFailureHandler, RESTAuthenticationEmtryPoint: Estas clases son las que configuran el módulo de Spring Security. • MyTrainingApplication: Clase principal del servicio web. 84 5.2 Diagrama de clases Figura 5.1: Diagrama de clases 5.3 Diagramas de secuencia Creación nuevo recurso Figura 5.2: Diagrama crear recurso 85 Modificación recurso Figura 5.3: Diagrama modificar recurso Eliminación recurso Figura 5.4: Diagrama eliminar recurso 86 5.4 Códigos ejemplo de implementación de FHIR en la aplicación web En este apartado, se mostrarán breves extractos del código que ha sido necesario implementar en la aplicación web para establecer la comunicación con el servidor HAPI FHIR y reflejar las acciones realizadas sobre la app web en la base de datos FHIR. Creación de contexto y cliente para la comunicación con el servidor HAPI FHIR Dicho servidor se encuentra en la dirección “http://localhost:8888”. Esta dirección es configurable, como veremos en el apartado “5.6 Configuración del docker”. Creación de un nuevo recurso y asignación de atributos Transacción para la creación de un recurso en el servidor HAPI FHIR 87 Obtención de un recurso existente en base a un criterio o condición Obtención de un recurso existente en base a su identificador en el servidor HAPI FHIR Obtención de atributos de un recurso obtenido Actualización de los atributos de un recurso obtenido Transacción para la actualización de un recurso en el servidor HAPI FHIR Eliminación de un recurso del servidor HAPI FHIR 88 5.5 Configuración del servidor HAPI FHIR En este apartado, hablaremos del fichero “hapi.properties”, que contiene la configuración del servidor HAPI FHIR. Este fichero es un poco extenso, por lo que se mencionarán las líneas más destacables. Pero primero, en la figura 5.5, se muestra la estructura de ficheros del servidor HAPI FHIR que mencionaremos, tanto en este apartado, como en el 5.6. Figura 5.5: Estructura archivos HAPI FHIR Hapi.properties ▪ Atributo “fhir_version”: Permite especificar la versión de FHIR soportada por el servdiro HAPI FHIR. La versión R4 es la última existente. ▪ Atributo “server address”: Permite especificar la dirección IP del servidor. 89 ▪ Atributo “default_encoding”: Permite especificar la codificación por defecto de los datos. ▪ Atributo “datasource.driver” y “datasource.url”: Permiten especificar el tipo de driver para la base de datos FHIR (en este caso Mysql) y la URL a la que comunicarse para acceder a esta. ▪ Atributo “datasource.username” y “datasource.password”: Permite especificar la dupla usuario/contaseña de acceso a la base de datos. ▪ Atributo hibernate.dialect: Permite especificar el dialecto para la comunicación entre el servidor HAPI FHIR y la base de datos. 96 y una externa, que sería la asociada al servidor HAPI FHIR. En la Base de Datos FHIR, se encuentran y almacenan los mismos datos que en la local y los datos referentes a las observaciones de pacientes y especialistas con el formato propio del estándar FHIR. La Base de Datos local se emplea para la autenticación de usuario a la hora de acceder a la app, y para la lectura de datos y la impresión de estos en la aplicación web, exceptuando las observaciones, que se leen directamente de la Base de Datos FHIR. 97 6 INTERFAZ DE USUARIO Y FUNCIONALIDAD 6.1 Introducción En este apartado se va a proceder a mostrar dos de los aspectos más importantes para el usuario como son la interfaz gráfica y la funcionalidad de la aplicación. La interfaz gráfica debe ser amigable al usuario, intuitiva y fácil de comprender. Las funciones que puede realizar cada usuario difieren según el rol que posean dentro de la aplicación. 6.2 Registro de especialista Del registro de especialistas se encarga el administrador. El administrador, tras acceder a la aplicación, dispondrá de la siguiente página para introducir los datos personales y cualificación del especialista a dar de alta. Figura 6.1: Dar de alta especialista. 98 6.2 Inicio de Sesión El usuario tras acceder a la página de inicio de sesión deberá acreditarse con sus credenciales, que en este caso son su correo y su contraseña. También, desde aquí, podrá descargarse la app para móvil de MyTraining. Figura 6.1: Página de Inicio de Sesión. Figura 6.2: Mensaje de Aviso de Credenciales Introducidas Erróneas. 5.3 Vistas y funciones de la web A continuación, procederemos a mostrar las diferentes vistas de la aplicación: 99 Figura 6.3: Página principal. Este es el aspecto de la página principal para ambos usuarios. En la esquina superior izquierda hay un botón cuya función es desplegar un menú lateral que difiere según el rol del usuario. Dicho menú solo se encontrará oculto inicialmente en la página principal, en el resto de páginas podremos encontrarlo ya desplegado con oportunidad de ocultarlo. . 100 Figura 6.4: Página principal con menú lateral desplegado de Usuario Especialista. En la imagen anterior se muestran las opciones del menú lateral de un usuario Especialista. Si pinchamos sobre “Página principal” desde cualquier pestaña seremos redirigidos a la página de Bienvenida que se muestra. Procedemos a ver cada una de las pestañas. Figura 6.5: Pestaña ‘Usuarios’. 101 Figura 6.6: Página ‘Usuarios’ En esta página el usuario Especialista puede: ▪ Ver un listado de los pacientes existentes y filtrarlos mediante búsqueda. ▪ Gestionar dichos pacientes (Modificar sus datos o darlos de baja) ▪ Dar de alta a un nuevo paciente. Para dar de alta a un paciente, solo hay que pulsar el botón 102 Figura 6.7: Dar de alta paciente Para modificar los datos de algún paciente, debe clicarse sobre Figura 6.8: Modificar datos de paciente 103 Figura 6.9: Pestaña Observaciones En esta pestaña, el especialista podrá listar todas las observaciones del resto de especialistas y las propias, pudiendo filtrar estas solo por paciente o por paciente y por código de clasificación. Cada especialista podrá modificar o eliminar solo sus propias observaciones. El especialista también podrá listar las observaciones que hayan generado los pacientes, seleccionándolo en el desplegable de la esquina superior izquierda. Figura 6.10: Observaciones especialistas 104 Figura 6.11: Modificar observación Figura 6.12: Observaciones pacientes 105 Figura 6.13: Pestaña ‘Rutinas’ Figura 6.14: Página ‘Rutinas’ En esta página, el usuario Especialista puede ver las rutinas que él mismo ha creado y las que han creado el resto de Especialistas mediante . Dichas rutinas están compuestas de un nombre y una descripción. El usuario Especialista puede asociar dicha rutina a un usuario , modificar la rutina y los usuarios asociados a esta , añadir ejercicios a dicha rutina , ver los ejercicios que posee la rutina , descargar un json con la información de la rutina y sus ejercicios y eliminar la rutina . Con el filtro “paciente” pueden obtenerse las rutinas relativas a un paciente determinado. Las rutinas pueden buscarse a través de su nombre mediante el cuadro de búsqueda. Y pueden añadirse nuevas mediante el botón 112 Ver vídeo En esta página podrá visualizarse el vídeo de Youtube asociado al ejercicio. No es necesario salir de MyTraining a Youtube para ello ya que el vídeo se encuentra embebido en la aplicación web. Figura 6.28: Página Ver vídeo Eliminar vídeo Figura 6.29: Eliminar vídeo Una vez explicados los ejercicios y las acciones que pueden realizarse sobre ellos, retomamos las rutinas. Añadir ejercicio a rutina Figura 6.30: Página Añadir Ejercicio a Rutina 113 Se muestran todos los ejercicios disponibles de todos los usuarios Especialistas para añadir. Aquellos ya añadidos a esa rutina no aparecerán en la lista. Los ejercicios se añaden pulsando . Figura 6.31: Ejercicio asociado Si el ejercicio que se va a añadir a la rutina no tiene vídeo aparecerá el siguiente mensaje Figura 6.32: Ejercicio sin vídeo Ver ejercicios de rutina Figura 6.33: Página Ver Ejercicios de Rutina Desde esta página, aparte de ver los ejercicios que tiene una rutina, así como sus datos y acceder a su vídeo asociado, se pueden quitar dichos ejercicios y añadir nuevos . 114 Eliminar rutina Figura 6.34: Eliminar rutina 1 Figura 6.35: Eliminar rutina 2 Descargar rutina La descarga de la rutina en un json tiene como finalidad su uso en la aplicación móvil homóloga a esta aplicación Web. Figura 6.36: Descargar rutina Figura 6.37: JSON rutina Figura 6.38: Pestaña Ajustes 115 Figura 6.39: Pestaña Ajustes 2 En esta página el usuario puede modificar sus datos personales Figura 6.40: Página Datos de Especialista En esta página el usuario podrá darse de baja borrándose de esta manera todos los datos relacionados con este de la aplicación. 116 Figura 6.41: Página Darse de Baja Figura 6.42: Perfil borrado En esta página se puede contactar mediante un mensaje de correo con personal que resolverá las dudas de los usuarios. Figura 6.43: Página Ayuda Figura 6.44: Correo 117 Figura 6.45: Cerrar sesión Ahora procedemos a revisar la vista del paciente. La vista del paciente es similar a la del Especialista, exceptuando algunas funciones que vamos a detallar: Este es el menú lateral de un usuario. Como puede observarse, la pestaña “Usuarios” y “Ajustes” no se encuentra ya que esas acciones conciernen al Especialista. Un paciente solo podrá ver, modificar y eliminar las observaciones que él mismo genere acerca de las rutinas que tenga asociadas. Así como, crear nuevas. Figura 6.46.1: Observación paciente 118 Figura 6.46.2: Crear observación paciente Campos de la página ‘Añadir Observación de paciente” • Rutina a la que hace referencia dicha observación • Clasificación de la observación (fija) • Descripción • Estado anímico del paciente relacionado con la realización de la rutina (basado en un valor numérico del 1 al 5 que se verá representado gráficamente con caritas) De igual manera, solo podrá ver las rutinas y ejercicios que le asignen los Especialistas, así como descargar las rutinas, ver los ejercicios que posea cada una de ellas y los videos de los respectivos ejercicios. 119 Figura 6.47: Rutinas de paciente Figura 6.48: Ejercicios de rutinas de paciente 120 Figura 6.49: Ejercicios de paciente 121 7. Conclusiones y líneas futuras inalmente, tras tiempo de dedicación a entender y aprender a utilizar el estándar HL7 FHIR, se ha conseguido que la plataforma interactúe correctamente con el servidor HAPI FHIR y que los datos generados se almacenen según estipula dicho estándar. Se ha logrado la migración de las acciones generadoras de datos de la plataforma “MyTraining” de manera que, se produce una comunicación establecida mediante creación de un contexto con el servidor HAPI FHIR a través de java y se almacenan y mapean los datos en la Base de Datos FHIR con transacciones y objetos en formato JSON. Este proyecto ofrece la posibilidad de obtener un entrenamiento o tratamiento personalizado, asistido por especialistas de una forma cómoda y virtual, para aquellas personas con características y necesidades especiales, facilitándoles mejorar su salud. Durante el proceso de realización de este proyecto he aprendido mucho acerca de los estándares existentes que buscan la interoperabilidad en el ámbito sanitario. La creciente necesidad de un estándar que permita la globalización de los datos médicos en los diferentes sistemas hospitalarios ha impulsado el desarrollo y mi interés por este proyecto. En definitiva, HL7 FHIR, es un fuerte candidato para solventar dicha necesidad. Parece dispuesto a quedarse y a seguir creciendo al ser un estándar optimizado y relativamente fácil de aprender e implementar. 7.1 Líneas futuras 7.1.1 OAuth 2.0 Una interesante línea futura para este proyecto sería la de implementar junto a FHIR el framework OAuth2, que separa el rol de autenticación y autorización. OAuth2 permite a una aplicación tener acceso a los datos de un usuario sin que esta necesite tener una copia de las credenciales de los usuarios en su sistema. La arquitectura de nuestra aplicación se vería de la siguiente manera en un esquema simple: Si se implementara OAuth2, la arquitectura quedaría de la siguiente manera: F 128 A.2 Recurso Rutina Método URI Parámetros Descripción POST "/Rutina_app/rutinas/{reset_group:.+}/{rut_id:.+}" Reset_group: Bandera para modificar el grupo de pacientes asociados a la rutina. Atributos de una Rutina.: Nombre, descripción, responsable rut_id:Identificador único de una rutina. Modificar una rutina. POST "/Rutina_app/rutinas/{user_id:.+}//" user_id: Identificador único del usuario. Atributos de una Rutina Crear una nueva rutina con sus datos en la BD local POST "/Rutina_app/rutinas/FHIR/{user_id:.+}//" user_id: Identificador único del usuario. Atributos de una Rutina Crear una nueva rutina con sus datos en BD FHIR GET "/Rutina_app/rutinas/{rut_id:.+}" rut_id:Identificador único de una rutina. Obtener los datos de una rutina. GET "/Rutina_app/rut/{user_id:.+}/" user_id: Identificador único de un usuario. Atributos de una Rutina. Obtener el identificador de una rutina. POST "/Rutina_app/rut/add/{user_id:.+}/" user_id: Identificador único de un usuario. Asociar una rutina a un paciente. 129 GET "/Rutina_app/rutinas_user/{user_id:.+}//" user_id: Identificador único de un usuario. Elemento de búsqueda (opcional) Obtener las rutinas asociadas a un paciente que accede. GET "/Rutina_app/rutinas_user_filter/{esp_id:.+}//" esp_id: Identificador único de un usuario. Obtener las rutinas asociadas a un paciente por especialista que accede. GET "/Rutina_app/rutinas/{user_id:.+}//" user_id: Identificador único de un usuario. Elemento de búsqueda (opcional) Bandera de rutinas: propias/Del resto Obtener las rutinas relacionadas. DELETE "/Rutina_app/rutinas/{user_id:.+}/{rut_id:.+}" user_id: Identificador único de un usuario. Eliminar una rutina junto a sus datos. POST "/Rutina_app/downloads/{rut_id:.+}" rut_id:Identificador único de una rutina. Descargar la rutina en un json A.3 Recurso Ejercicio Método URI Parámetros Descripción POST "/Rutina_app/ejercicios/{user_id:.+}//" user_id: Identificador único de un usuario. Atributos de un Ejercicio: Nombre, descripción, periodicidad, estado de forma Crear un ejercicio 130 recomendado, pacientes asociados GET "/Rutina_app/ejercicios/{user_id:.+}/{ej_id:.+}" user_id: Identificador único de un usuario. ej_id:Identificador único de un ejercicio. Obtener los datos de un ejercicio GET "/Rutina_app/ejercicios/{user_id:.+}//" user_id: Identificador único de un usuario. Elemento de búsqueda (opcional) Bandera de ejercicios: propias/Del resto Obtener los ejercicios relacionados GET "/Rutina_app/ej/{user_id:.+}/" Atributos de un Ejercicio user_id: Identificador único de un usuario. Obtener el identificador del ejercicio POST "/Rutina_app/ej/add/{user_id:.+}/" user_id: Identificador único de un usuario. Atributos de un Ejercicio Asociar un ejercicio a un usuario GET "/Rutina_app/ejercicios_user/{user_id:.+}//" user_id: Identificador único de un usuario. Elemento de búsqueda (opcional) Obtiene los ejericicios asociados a un usuario DELETE "/Rutina_app/ejercicios/{user_id:.+}/{ej_id:.+}" user_id: Identificador único de un usuario. Eliminar un ejercicio 131 ej_id:Identificador único de un ejercicio DELETE "/Rutina_app/rutinas/asociaciones/{rut_id:.+}/{ej_id:.+}" ej_id:Identificador único de un ejercicio rut_id:Identificador único de una rutina Eliminar asociación de ‘y’ ejercicio asociado ‘x’ a rutina POST "/Rutina_app/ejercicios/{user_id:.+}/{ej_id:.+}" user_id: Identificador único de un usuario. ej_id:Identificador único de un ejercicio Atributos de un Ejercicio Modificar un ejercicio DELETE "/Rutina_app/rutinas/asociaciones/{rut_id:.+}//" rut_id:Identificador único de una rutina Eliminar las asociaciones de todos los ejercicios asociados a una rutina ‘x’ GET "/Rutina_app/rutinas/noasociaciones/{rut_id:.+}//" rut_id:Identificador único de una rutina Elemento de búsqueda (opcional) Obtener los ejercicios que no están asociados a ‘x’ rutina POST "/Rutina_app/rutinas/asociaciones/{rut_id:.+}/{ej_id:.+}" user_id: Identificador único de un usuario. ej_id:Identificador único de un ejercicio Asociar ejercicios a rutinas GET "/Rutina_app/rutinas/asociaciones/{rut_id:.+}//" rut_id:Identificador único de una rutina Obtener los ejercicios asociados a una rutina 132 A.4 Recurso Vídeo Método URI Parámetros Descripción GET "/Rutina_app/videos/{user_id:.+}/{ej_id:.+}" user_id: Identificador único de un usuario. ej_id:Identificador único de un ejercicio Obtener video POST "/Rutina_app/videos/{ej_id:.+}" ej_id:Identificador único de un ejercicio Atributos de un Video: Nombre, URL Añadir video DELETE "/Rutina_app/videos/{user_id:.+}/{ej_id:.+}" user_id: Identificador único de un usuario. ej_id:Identificador único de un ejercicio Eliminar video A.5 Recurso Observación Método URI Parámetros Descripción POST "/Rutina_app/FHIR/create" Atributos de la observación: creador, clasificación, descripción, unidad, medida Crear una observación POST "/Rutina_app/update/FHIR/{obs_id:.+}" obs_id: Identificador único de la rutina. Atributos de una Observación Modificar observación de especialista POST "/Rutina_app/update/FHIR/user/{obs_id:.+}" obs_id: Identificador único de la rutina. Modificar observación de paciente 133 Atributos de una Observación GET "/Rutina_app/modify/FHIR/{obs_id:.+}" obs_id: Identificador único de la rutina. Obtener datos de la observación a modificar por especialista GET "/Rutina_app/modify/FHIR/user/{obs_id:.+}" obs_id: Identificador único de la rutina. Obtener datos de la observación a modificar por paciente POST "/Rutina_app/update/FHIR/user/{obs_id:.+}" obs_id: Identificador único de la Observación. Atributos de una Observación Modificar observación de paciente GET "/Rutina_app/FHIR/observation/{patientId:.+}" patient_id:Identificador único de un paciente. Obtener los datos de observaciones de un paciente que accede GET "/Rutina_app/FHIR/all_observation/{patientId:.+} /{obs_id:.+}" patient_id:Identificador único de un paciente. practitionerId_id: Identificador único de la Observación Obtener los datos de las observaciones disponibles por especialista DELETE "/Rutina_app/FHIR/delete/{obsId:.+}" obs_id: Identificador único de la Observación. Eliminar una observación 134 135 ANEXO B: MANUAL DE INSTALACIÓN Y DESPLIEGUE DE LA APLICACIÓN En este anexo se explicará el proceso de instalación y despliegue de la aplicación sobre el sistema operativo sobre el que se ha desarrollado el proyecto, Windows 10 de 64 bits. B.1 Instalación de Java JDK 8 1. Descargar JDK para Windows a través de la página http://www.oracle.com/technetwork/java/javase/downloads/jdk10-downloads-4416644.html 2. Ejecutar el .exe para instalarlo y escoger una ruta para la instalación. Debemos recordar dicha ruta para un paso posterior. Figura B.1: JDK 136 B.2 MAVEN 1. Descargamos el archivo .zip de Maven de la página https://maven.apache.org/download.cgi Figura B.2: MAVEN 2. Lo descomprimimos con WinRar o similar y lo ubicamos en la ruta que escojamos, a ser preferible una cercana a la raíz C:\, que tendremos que recordar más adelante para su uso. B.3 Creación de variables de entorno En caso de no tener configuradas las variables de entorno necesarias para que Maven funcione correctamente, habrá que seguir estos pasos: 1. Acceder a “Este equipo->Configuración avanzada del sistema->variables de entorno Figura B.3: Variables de entorno 137 2. Ahora necesitaremos crear la variable de entorno ‘JAVA_HOME’ que contendrá la ruta que escogimos al instalar el JDK. 3. Incluimos la ruta de ‘JAVA_HOME’ y la ruta de Maven a la variable de entorno ‘Path’. A la ruta de Maven deberá añadirse \bin, es decir, ‘tu_ruta_de_maven\bin’. B.4 Comprobación en cmd e instalación Abrimos la consola de Windows y ejecutamos el comando “mvn -version”. Si la salida es parecida a la siguiente todo está correcto. Figura B.4: versión Maven/java Acto seguido ejecutamos “mvn install” para que se se instale y configure nuestro repositorio local. B.5 Instalación de Spring Tools Suite (STS) Descargamos el zip correspondiente de la página de Spring https://spring.io/tools/sts/all Figura B.5: Descarga STS Una vez ejecutado e instalado, iniciamos la aplicación. 144 Y escogemos el directorio “SERVIDOR_VISUASTUDIOCODE_DOCKER” VI. Activar Docker Desktop iniciando la aplicación VII. Ejecutar el servidor HAPI FHIR ejecutando en Visual Studio Code lo siguiente El resultado final debe ser similar al siguiente VIII. Ejecutar aplicación web en Spring