Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado

Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado Autor: Gonzalo Caballero Lora Tutor: Jorge Calvillo Arbizu Dpto. Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2024 iii Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado Autor: Gonzalo Caballero Lora Tutor: Jorge Calvilo Arbizu Profesor Permanente Laboral Dpto. Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2024 v Trabajo Fin de Grado: Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado Autor: Gonzalo Caballero Lora Tutor: Jorge Calvillo Arbizu El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2024 El Secretario del Tribunal vii A mi familia A mis maestros ix Agradecimientos Escribo estas líneas con la emoción de haber llegado al final de una etapa significativa en mi vida. Este Trabajo Fin de Grado no solo marca el cierre de mi etapa universitaria, sino también el fin de un camino que comenzó mucho antes, lleno de momentos inolvidables y personas que han sido fundamentales en mi recorrido. En primer lugar, quiero expresar mi más profundo agradecimiento a mi familia, quienes siempre han confiado en mí, y hacer mención especial a mis padres, quienes me han estado apoyando en todo momento, brindandóme su ayuda y atención. A mis amigos de siempre, que aunque cada uno de nosotros escogiéramos caminos distintos, siempre hemos estado ahí los unos para los otros para cuando necesitábamos despejar nuestra mente y pasar un buen rato entre amigos. Gracias por estar tanto en los buenos y malos momentos. A la familia que encontré en Sevilla: Carlos, Moreno, Marta, Álvaro, Alejandro, Lucía, Antonio y Rafa. A mi otra familia que encontré en mi querida R.U. Pinomontano. Gracias a ti Juanjo, el mejor compañero de habitación que se puede tener, por tu forma de ser tan peculiar que ha alegrado muchos de mis días universitarios. A mi gran descubrimiento, Teresa, gracias por haber formado parte de mi vida en Sevilla y continuarla en nuestro pueblo. Y gracias a todos aquellos que no he mencionado pero que tienen un espacio reservado en mi corazón. Y como no, gracias a ti Sara, por ser la persona que se ha convertido en mi pilar todos estos años, y la que más apoyo y confianza a mostrado hacia mí. Por esos paseos por Sevilla, que nos servían para alejarnos un poco de la universidad. Por haber estado en los buenos momentos, pero sobretodo en los malos, y a pesar de ello simpre has estado ahí. Gracias de corazón. Por último, pero no menos importante, quiero agradecer a todos los profesores que me han guiado y enseñado a lo largo de estos años, desde mis maestros de infantil hasta los profesores de universidad. En especial, agradecer a Jorge Calvillo, mi tutor en este proyecto, por su paciencia, atención, apoyo constante y confianza en mí. Gonzalo Caballero Lora Sevilla, 2024 3.5.1 Comprobación de la gestión de datos 44 3.5.2 Ejecución 44 3.5.3 Comprobación del correcto almacenamiento en la base de datos 45 3.5.4 Comprobación del correcto almacenamiento en el servidor FHIR 46 4 Conclusiones y líneas futuras 50 4.1 Conclusiones 50 4.2 Líneas futuras 51 Referencias 52 xvii ÍNDICE DE TABLAS Tabla 1–1. Plan de trabajo 5 Tabla 3–1 Método “main” de Aplicación.java 36 Tabla 3–2 Método “leer_fichero” de Lectura_Fichero.java 37 Tabla 3–3 Método “removeTrailingQuotes” de Lectura_Fichero.java 39 Tabla 3–4 Método “configurarRecursos”de Gestion_Fhir.java 40 Tabla 3–5 Método “configurarObservation”de Gestion_Fhir.java 41 xix ÍNDICE DE FIGURAS Figura 1-1. Funcionamiento general del sistema 2 Figura 1-2. Funcionamiento de una metodología incremental 3 Figura 2-1. Impedancia (Z) 7 Figura 2-2. Modelo de circuito de un tejido biológico 8 Figura 2-3. Expresión más detallada de la impedancia (Z) 8 Figura 2-4. Gráfica Cole-Cole 9 Figura 2-5. Expresión de la impedancia en 1941 (Z) 9 Figura 2-6. Expresión final de la impedancia (Z) 9 Figura 2-7. Contenido del recurso básico “Resource” 12 Figura 2-8. Contenido del recurso “Meta” 12 Figura 2-9. Lista de recursos 13 Figura 2-10. Tipos de datos en los recursos FHIR 14 Figura 2-11. Estructura del recurso Patient 15 Figura 2-12. Estructura del recurso Observation 16 Figura 2-13. Estructura del recurso Device 17 Figura 2-14. Estructura del recurso Bundle 18 Figura 2-15. Logo HAPI FHIR 19 Figura 2-16. Logo Eclipse IDE 20 Figura 2-17. Eclipse IDE 20 Figura 2-18. Archivo build.gradle 21 Figura 2-19. Logo SQLite 21 Figura 3-1. Descripción general del sistema 24 Figura 3-2. Diagrama de secuencia 25 Figura 3-3. Modelo Entidad-Relación 26 Figura 3-4. Tabla “Paciente” 26 Figura 3-5. Tabla “Medición” 27 Figura 3-6. Tabla “Tripleta” 27 Figura 3-7. Tabla “Par_Bioimp” 28 Figura 3-8. Tabla “Par_Comp_Cor” 29 Figura 3-9. Código referente a la conexión con la base de datos 30 Figura 3-10. Código referente a la consulta a la base de datos 30 Figura 3-11. Código referente a la ejecución de sentencias SQL 31 Figura 3-12. Código referente a la inserción de datos en la BD 31 Figura 3-13. Parámetros de composición corporal en el recurso Observation 33 Figura 3-14. Uso del recurso Bundle 34 Figura 3-15. Paquetes de la aplicación 35 Figura 3-16. Fichero “build.gradle” 35 Figura 3-17. Fichero “Aplicación.java” 36 Figura 3-18. Métodos constructores de la clase “Lectura_Fichero.java” 37 Figura 3-19. Método “leer_fichero” de la clase “Lectura_Fichero.java” 38 Figura 3-20. Método “removeTrailingQuotes” de la clase “Lectura_Fichero.java” 39 Figura 3-21. Código referente a la conexión con el servidor FHIR 39 Figura 3-22. Creación o recuperación del recurso Patient 40 Figura 3-23. Creación del recurso Observation 41 Figura 3-24. Diagrama de flujo UML representando el proceso de la aplicación 43 Figura 3-25. Datos de pacientes en el fichero CSV 44 Figura 3-26. Base de datos vacía 44 Figura 3-27. Ejemplo de ejecución 45 Figura 3-28. Base de datos completa 45 Figura 3-29. Primera ejecución de la aplicación 46 Figura 3-30. Instancia del recurso Patient 46 Figura 3-31. Instancia del recurso Device 47 Figura 3-32. Instancia del recurso Observation 47 Figura 3-33. Respuesta del servidor FHIR del recurso Patient 48 Figura 3-34. Respuesta del servidor FHIR del recurso Device 48 Figura 3-35. Respuesta del servidor FHIR del recurso Observation 49 Figura 3-36. Segunda ejecución de la aplicación 49 xxi Notación API Application Programming Interface BBDD Bases de Datos CDA Clinical Document Architecture CSV Comma Separated Values FHIR Fast Healthcare Interoperability Resources HL7 Health Level Seven HTTP Hypertext Transfer Protocol IDE Integrated Development Environment JSON JavaScript Object Notation LOINC Logical Observation Identifiers Names and Codes REST Representational State Transfer SQL Structured Query Language UML Unified Modeling Language XML Extensible Markup Language 1 1 INTRODUCCIÓN n este capítulo se ofrece una visión general del trabajo realizado, abordando desde la motivación que originó el proyecto hasta la metodología adoptada y el tiempo empleado en su desarrollo. También se muestran los objetivos a cumplir tras el conocimiento de la motivación y el plan de trabajo propuesto para ello. 1.1 Motivación y objetivos Los avances en la tecnología están transformando todos los sectores de la sociedad, permitiendo nuevos servicios y capacidades que antes eran inimaginables. En concreto, en el dominio sanitario, los dispositivos de monitorización van a permitir la atención continuada de los pacientes, el registro de información de salud a lo largo del tiempo y con gran detalle, además de poder actuar ante eventos de riesgo en tiempo real. Pero una problemática que nos encontramos actualmente es que los dispositivos van a ser capaces de registrar grandes cantidades de información (en tiempo real a lo largo del tiempo y de muchos pacientes) que tiene que ser integrada con la historia clínica de los pacientes para poder ser utilizada en la práctica clínica. Existe por tanto un salto (por ahora no resuelto) entre los dispositivos y los sistemas de información de la organización sanitaria, que frecuentemente implementan estándares para el intercambio de datos de salud. La motivación de este trabajo surge de un caso particular de esta problemática: la necesidad de abordar la falta de una herramienta intermediaria capaz de recoger, almacenar y mapear a un estándar sanitario los datos generados por dispositivos de bioimpedancia, facilitando así su integración en el ámbito clínico. Actualmente, los datos de bioimpedancia son valiosos para la evaluación de la composición corporal, el estado nutricional y la salud general de los pacientes. Sin embargo, existe una brecha debido a la ausencia de una aplicación que pueda tomar estos datos, persistirlos de manera segura y estructurada, y hacerlos accesibles para los sistemas clínicos que los necesitan para el seguimiento y control de los pacientes. El Grupo de Ingeniería Biomédica de la Universidad de Sevilla [1] ha desarrollado un dispositivo de bioimpedancia multifrecuencia que envía los datos a través del protocolo Bluetooth siguiendo un formato de datos propietario. El objetivo principal de este trabajo es desarrollar una aplicación que funcione como intermediario entre dicho dispositivo de bioimpedancia y los sistemas de información sanitaria estandarizados. Como ya se ha comentado anteriormente, la aplicación debe ser capaz de recoger los datos generados por estos dispositivos, almacenarlos en una base de datos estructurada y mapearlos a un servidor FHIR (Fast Healthcare Interoperability Resources), permitiendo así su integración con otros registros médicos y facilitando su uso en la práctica clínica diaria. Si bien contamos con el dispositivo de bioimpedancia desarrollado, para el diseño y desarrollo de este trabajo se ha simulado su comportamiento a través de la lectura de un fichero CSV que almacena los datos de bioimpedancia. “Nunca consideres el estudio como una obligación, sino como una oportunidad para penetrar en el bello y maravilloso mundo del saber.” - Albert Einstein - E Introducción 2 Así, el objetivo principal se desglosa en los siguientes subobjetivos:  Diseño y desarrollo de un sistema de lectura de datos: capaz de leer y procesar datos de bioimpedancia desde un fichero CSV generado por el dispositivo de bioimpedancia.  Diseño e implementación de una base de datos: para almacenar de manera estructurada los datos de bioimpedancia, asegurando su integridad y accesibilidad.  Estudio del estándar FHIR: para comprender sus especificaciones y cómo puede ser aplicado en la integración de datos de bioimpedancia con sistemas clínicos.  Integración con un servidor FHIR: a través del mapeo de los datos de bioimpedancia a recursos FHIR, permitiendo su integración y compatibilidad con otros sistemas de salud que utilicen el estándar FHIR.  Creación y gestión de recursos clínicos: Implementación de funcionalidades para la creación de recursos clínicos en el servidor FHIR, asegurando que los datos de bioimpedancia se registren adecuadamente y sean accesibles.  Validación y pruebas: Realización de pruebas exhaustivas para asegurar que la aplicación funciona correctamente y cumple con los requisitos establecidos. En cuanto a FHIR [2], es un estándar desarrollado por HL7 para facilitar el intercambio de información sanitaria entre diferentes sistemas. FHIR utiliza una estructura basada en recursos, donde cada recurso representa un concepto específico de la información sanitaria, como pacientes (Patient), observaciones (Observation) y diagnósticos (Diagnostic Report). En este trabajo, utilizaremos FHIR para estructurar y mapear los parámetros de bioimpedancia a recursos clínicos que puedan ser fácilmente integrados y utilizados en los sistemas de información sanitaria. En la Figura 1-1 se muestra un diagrama que representa el funcionamiento general del sistema cuyos elementos que lo componen son la aplicación móvil, que va a desarrollar el papel de intermediario entre el Dispositivo de bioimpedancia y el Servidor FHIR, los cuáles intercambiarán información entre ellos, y la BD en la que se cargarán y recuperarán los datos de bioimpedancia a través de la Aplicación móvil. Figura 1-1. Funcionamiento general del sistema 3 3 Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado 1.2 Metodología empleada La metología empleada para el desarrollo del trabajo está basada en el modelo incremental, que ha permitido abordar el proyecto en fases sucesivas, iterativas y acumulativas. Esta elección se debe a la necesidad de ir construyendo la aplicación de manera gradual, asegurando en cada fase la correcta implementación y funcionamiento, y permitiendo realizar ajustes y mejoras continuas a medida que se avanza hacia el producto final. Figura 1-2. Funcionamiento de una metodología incremental En la Figura 1-2 se pueden apreciar las fases genéricas que se suelen seguir usando en esta metodología. El primer incremento representa el desarrollo del núcleo del proyecto. Al finalizar esta etapa, se produce una retroalimentación que permite aprovechar los conocimientos y la experiencia adquiridos para progresar de forma más eficiente en la siguiente iteración. Este ciclo de retroalimentación es fundamental, ya que nos permite aprender y adaptarnos a los problemas encontrados en cada fase, facilitando así el avance en cada nueva iteración. Finalmente, el proceso iterativo culmina cuando el cliente está completamente satisfecho con la solución, garantizando un producto final con todas sus expectativas y necesidades. Estado del arte 10  Modelo de bioimpedancia: - R0 (Ω) - R∞ (Ω) - Re (Ω) - Ri (Ω) - C (nF) - α - TD (ns) Con los parámetros antropométricos, los parámetros de bioimpedancia y el modelo de bioimpedancia podemos obtener los parámetros de composición corporal.  Parámetros de composición corporal: - Masa celular corporal (BCM, del inglés Body Cell Mass) (kg) - % BCM (%) - Volumen de agua extracelular (ECW, del inglés Extra-Cellular Water) (l) - Volumen de agua intracelular (ICW, del inglés Intra-Cellular Water) (l) - Agua corporal total (TBW, del inglés Total Body Water) (l) - Masa libre de grasa (FFM, del inglés Fat-Free Mass) (kg) - % FFM (%) - Índice de masa libre de grasa (FFMI, del inglés Fat Free Mass Index) (kg/m2) - Masa grasa (FM, del inglés Fat Mass) (kg) - % FM (%) - Índice de masa grasa (FMI, del inglés Fat Mass Index) (kg/m2) 2.2 Interoperabilidad en el ámbito sanitario La interoperabilidad en el ámbito sanitario es esencial para garantizar que los datos de salud se puedan compartir y utilizar de manera eficaz entre diferentes sistemas y organizaciones. Este aspecto es crucial para mejorar la calidad de la atención al paciente, facilitar la investigación y optimizar la eficiencia del sistema de salud. Podemos definir la “interoperabilidad en el ámbito sanitario” como la capacidad de los sistemas de información y los procedimientos que soportan, de compartir datos y permitir el intercambio de información y conocimiento entre ellos [9]. Esta interoperabilidad es crucial hoy en día, ya que cada organización puede tener sus sistemas implementados de diversas maneras, lo que complica la comunicación entre ellos. Por lo tanto, se necesita un marco de referencia que unifique esta información, facilitando la comunicación. Aquí es donde entran los estándares. Estos estándares proporcionan un denominador común para los componentes utilizados en el ámbito sanitario y para la forma en que se transmiten, asegurando que sean útiles para terceros. En nuestro caso, nos vamos a centrar en el estándar FHIR. 11 11 Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado 2.2.1 El estándar FHIR El estándar FHIR combina las mejores características de los estándares HL7 v2 [10], HL7 v3 [11] y CDA [12]. HL7 es el ejemplo perfecto de la fusión de la tecnología y la sanidad. Es un promotor que hace más sencillo la interoperabilidad entre todas las partes del mundo. Es una organización de desarrollo de estándares para el ámbito de la salud, fundada en 1987 que opera a nivel internacional y su misión es proveer estándares globales para los dominios clínicos, asistencial, administrativo y logístico para conseguir una comunicación entre los diferentes sistemas de información en el área de la salud. HL7 fue quien dio forma y definió FHIR. FHIR es una especificación de plataforma que describe formatos y elementos de datos, también conocidos como recursos. Estos (los recursos) son la unidad básica de interoperabilidad y la más pequeña que se puede intercambiar de manera significativa. Todos los recursos, salvo excepciones, contienen un identificador a través del cual puede ser registrado, localizado y recuperado. Además, los recursos disponen de extensiones que permite a los implementadores agregar fácilmente nuevas propiedades. Por otro lado, FHIR se caracteriza como una especificación “RESTful” porque utiliza el protocolo REST para la comunicación. Esto implica que se emplean mensajes HTTP request/response para el envío y recepción de información, la cual se transmite en estructuras JSON o XML. Además, la API RESTful [13] define un conjunto de operaciones conocidas como interacciones para gestionar los diferentes recursos. Una interacción particularmente destacada es Search, que permite buscar el recurso deseado. En cuanto a la seguridad de FHIR [14], es importante señalar que FHIR no es un protocolo de seguridad ni define funciones específicas relacionadas con la seguridad. Sin embargo, sí establece una serie de protocolos de intercambio y modelos de contenido que deben ser utilizados junto con varios protocolos de seguridad para garantizar un uso seguro. Los protocolos de intercambio y los modelos de contenido que se utilizan para garantizar la seguridad incluyen:  HTTPS (HTTP Secure)  OAuth 2.0  SMART on FHIR  AuditEvent  Consent  Provenance  Security Labels Protocolos de intercambio Modelos de contenido Estado del arte 12 2.2.2 El recurso FHIR Un recurso FHIR es la unidad fundamental de intercambio en el estándar FHIR. Representa una pieza de información clínica o administrativa, estructurada de manera que pueda ser fácilmente compartida y entendida por diferentes sistemas de salud. Cada recurso contiene una estructura de datos definida, con atributos específicos que describen una entidad del mundo real, como un paciente, una observación, una receta, etc. Según se define en la página oficial de FHIR, una instancia de recurso es una entidad que:  tiene una identidad conocida (una URL) por la que se puede dirigir  se identifica como uno de los tipos de recurso definidos en la presente especificación  contiene un conjunto de elementos de datos estructurados según se describe en la definición del tipo de recurso  tiene una versión identificada que cambia si el contenido del recurso cambia La Figura 2-7 muestra los campos comunes a los recursos FHIR. Estos son:  Un identificador con el que podremos recuperar el recurso a posteriori. Este podrá ser una “Uniform Resource Locator” (URL) que cambiará a medida que cambie la localización del recurso o podrá formar parte del mismo recurso de tal forma que no cambiará.  Metadatos para describir al propio recurso cuyos campos podemos observar en la Figura 2-8.  Una referencia a una guía de implementación que describa cómo se está usando el recurso.  Puede tener un elemento de lenguaje que especifica el idioma que tendrán los datos del recurso. Si este se usa, también deberá especificarse en el elemento narrativo. Figura 2-7. Contenido del recurso básico “Resource” Figura 2-8. Contenido del recurso “Meta” 13 13 Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado En la Figura 2-9 podemos observar la gran variedad de recursos existentes, que se definen y van desarrollando con diferentes grados de mandurez en el que el mínimo es “0” y el máximo es “N” (“normative”) [15]. Cuando poseen un grado “N” quiere decir que el recurso en cuestión no va a sufrir más modificaciones. Figura 2-9. Lista de recursos Estado del arte 14 Además de los elementos anteriores, los recursos poseen otros elementos que almacenan información. Cada tipo de recurso tendrá una serie de campos que aportarán la información por la que usamos un recurso determinado. Estos campos se podrán completar con un tipo de dato concreto. La especificación define 4 categorías en las que clasifica estos tipos [16]:  Simples o primitivos (string o integer)  Complejos (CodeableConcept o ContactPoint)  Metadatos (Contributor o UsageContext)  De uso especial (Reference o Extension) En la Figura 2-10 podemos observar los tipos de cada categoría: Figura 2-10. Tipos de datos en los recursos FHIR 2.2.2.1 Recursos usados Para el desarrollo de la aplicación de bioimpedancia, se han utilizado varios recursos FHIR clave para gestionar y compartir la información de bioimpedancia: Patient, Observation, Device y Bundle.  Recurso Patient El recurso Patient [17] es uno de los más fundamentales en FHIR y se utiliza para representar información sobre un individuo que recibe atención médica. Incluye detalles como el nombre, la fecha de nacimiento, el género, los identificadores únicos, y otros datos demográficos relevantes. En la Figura 2-11 tenemos la estructura del recurso con todos los campos de información que el estándar aporta. 15 15 Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado Figura 2-11. Estructura del recurso Patient En nuestro caso se usará el recurso Patient para identificar cada paciente mediante el DNI del ciudadano e identificarlo, y para registrar datos demográficos como el género y la fecha de nacimiento del paciente, ya que son cruciales para contextualizar las observaciones clínicas y personalizar la atención médica.  Recurso Observation El recurso Observation [18] se usa para registrar y almacenar datos de observaciones y mediciones clínicas realizadas sobre un paciente. Puede incluir cualquier tipo de información clínica, como signos vitales, resultados de laboratorio, y otros datos cuantitativos y cualitativos. La mayoría de los campos de este recurso son simples aserciones de pares de nombre/valor con algunos metadatos, salvo algunas observaciones que agrupan otras observaciones. En la Figura 2-12 tenemos parte de la estructura del recurso Observation con todos los campos de información que el estándar aporta. Estado del arte 16 Figura 2-12. Estructura del recurso Observation Este recurso se utilizará para el registro de mediciones de bioimpedancia, incluyendo parámetros como la masa celular corporal (BCM), el porcentaje de masa corporal (BCM%), el agua extracelular (ECW), el agua intracelular (ICW), y otros datos derivados de los dispositivos de bioimpedancia. Además, se usará el recurso Observation para el almacenamiento de valores específicos, como la altura del paciente, capturando no solo el valor númerico sino también el contexto, como la unidad de medida (cm) y el sistema de codificación utilizado (LOINC [19] o SNOMED [20]). LOINC y SNOMED CT son dos sistemas de terminología médica ampliamente utilizados a nivel mundial para estandarizar y codificar información clínica. LOINC es un sistema de codificación desarrollado para identificar de manera única las observaciones y los resultados de laboratorio, y SNOMED es un sistema de terminología integral que cubre todos los aspectos de la atención médica. Ambos sistemas son esenciales para la interoperabilidad en la atención sanitaria, ya que permiten que los datos clínicos sean compartidos, comprendidos y utilizados de manera eficiente a nivel global. Como podemos observar en la Figura 2-12, los datos de información clínica mencionados anteriormente no existen literalmente en la estructura del recurso, por lo que para almacenar este tipo de información haremos uso del campo “Value” de dicha estructura, el cual nos permite guardar distintos valores médicos según el formato.  Recurso Device Este recurso describe un dispositivo médico utilizado en la atención al paciente, y puede incluir detalles como el tipo de dispositivo, el fabricante, el número de serie, y otra información relevante. En la Figura 2-13 tenemos la estructura del recurso Device [21] con todos los campos de información que el estándar aporta. 17 17 Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado En nuestro proyecto, usaremos el recurso Device para gestionar el registro de dispositivos de bioimpedancia, identificando los dispositivos utilizados para capturar las mediciones de los pacientes, asegurando así la trazabilidad y el contexto de las observaciones. Además, aparte de la identificación de los dispositivos, se configurará el estado del mismo. Para ello se usarán los campos “identifier” y “status” que podemos observar en la estructura del recurso de la Figura 2-13. Figura 2-13. Estructura del recurso Device Estado del arte 18 El recurso Bundle [22] es una colección de recursos relacionados que se agrupan para ser procesados de manera conjunta. Los Bundle son útiles para realizar transacciones, intercambiar conjuntos de datos, o representar una colección de recursos en una sola unidad. Esto en FHIR se denomina “agrupación” de recursos. Bundle es un recurso FHIR que se encuentra dentro del grupo “Otros” en la zona de “Fundación”, cuyo grado de madurez es el máximo, es decir, el grado “Normative”. Dado que un paquete en sí mismo es un recurso, este recurso Bundle tiene los mismos metadatos comunes que todos los recursos, incluyendo afirmaciones de perfiles, etiquetas y etiquetas de seguridad. En la Figura 2-14 podemos ver la estructura de este recurso con todos los campos correspondientes que FHIR nos aporta. Figura 2-14. Estructura del recurso Bundle 19 19 Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado En nuestro caso el recurso Bundle se utilizará para comprobar la existencia de pacientes y dispositivos específicos en la base de datos de FHIR. Esto lo realizaremos mediante una consulta que buscará pacientes por su identificador único (DNI) y dispositivos por su identificador de dispositivo correspondiente. Finalmente el Bundle resultante contendrá los recursos Patient y Device que coincidan con los criterios de búsqueda. Con esto nos aseguraremos de que si existe un paciente con un DNI concreto en los servidores FHIR o un dispositivo clínico con un identificador específico se use la referencia ya existente de esos recursos Patient o Device, en caso contrario habrá que crear dichos recursos y solicitar la referencia de estos al servidor FHIR. 2.3 Materiales y herramientas software Para el desarrollo de este proyecto, se han utilizado diversas herramientas software que facilitan la implementación y el manejo de los recursos FHIR, así como la gestión de los datos de bioimpedancia. 2.3.1 HAPI FHIR (Librería externa) Una biblioteca Java de código abierto para el estándar FHIR que facilita la creación, manipulación y transmisión de recursos FHIR. HAPI FHIR [23] proporciona una API RESTful que simplifica la integración con servidores FHIR. En nuestro proyecto, HAPI FHIR se ha utilizado para configurar los recursos Patient y Observation, y posteriormente ser enviados mediante la API RESTful al servidor que HAPI FHIR ofrece [24] para realizar pruebas de este estilo. Figura 2-15. Logo HAPI FHIR 2.3.2 HAPI FHIR Public Test Server La API de FHIR también ofrece un servidor público [24] para la realización de pruebas así como una base de datos FHIR pública. En este caso, se ha utilizado este servidor de FHIR público para simular las organizaciones sanitarias a las que se envían los datos de bioimpedancia de los pacientes. No se ha usado un servidor FHIR propio debido a la limitación de tiempo para este proyecto. Este servidor FHIR propio sería el resultado de un servidor que implementaría el estándar FHIR y los métodos necesarios para la escucha y respuesta a las peticiones por parte de los clientes, como ya lo hace el servidor de FHIR público. Resultados 26 Figura 3-3. Modelo Entidad-Relación A continuación se explicará en detalle cada una de las tablas con sus parámetros correspondientes. Las tablas que forman parte de la base de datos son:  Tabla “Paciente” Almacena información básica de los pacientes, incluyendo su identificador único, fecha de nacimiento, y otros datos relevantes. - “ID_Pac”: Identificador único del paciente, que en este caso se ha utilizado el DNI del paciente. - “Fec_Nac”: Fecha de nacimiento del paciente. - “Sexo”: Género del paciente. - “Estatura”: Estatura del paciente, medida en centímetros. Figura 3-4. Tabla “Paciente” 27 27 Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado  Tabla “Medición” Almacena información referente a las mediciones realizadas sobre los pacientes, como la fecha de realización de la medición, el identificador del paciente y del dispositivo, y el peso del paciente. - “ID_Pac”: Identificador único del paciente, que en este caso es el DNI del paciente. - “Peso”: Pesaje del paciente a estudio, medido en kilogramos. - “ID_Disp”: Identificador único del dispositivo de bioimpedancia con el que se realiza la observación. - “ID_Med”: Identificador único de la observación realizada al paciente. Figura 3-5. Tabla “Medición” Un paciente puede tener varias mediciones (Figura 3-3), por lo que en la tabla “Medición” un paciente podría tener varias entradas con distintos identificadores de medición pero con el mismo identificador de paciente.  Tabla “Tripleta” Tabla que se utiliza para almacenar las distintas frecuencias con sus respectivos módulo y fase en las que se realiza las mediciones de la observación. - “ID_Med”: Identificador único de la observación realizada al paciente. - “Frecuencia”: Frecuencia de la impedancia medida en kHz. - “Módulo”: Módulo de la impedancia medido en ohmios. - “Fase”: Fase de la impedancia medida en grados. Figura 3-6. Tabla “Tripleta” Disponemos de 22 frecuencias distintas para obtener el modelo de bioimpedancia que calcula los datos de bioimpedancia que se necesitan. Por tanto, por cada entrada en la tabla “Medición” tenemos 22 entradas en la tabla “Tripleta”, una por cada frecuencia (Figura 3-3). Resultados 28  Tabla “Par_Bioimp” Tabla que almacena los parámetros de bioimpedancia obtenidos a partir de la frecuencia, módulo y fase para formar el modelo de bioimpedancia. - “ID_Med”: Identificador único de la observación realizada al paciente. - “R0”: Resistencia a frecuencia cero, medida en ohmios. - “R_inf”. Resistencia a frecuencia infinita, medida en ohmios. - “Re”: Resistencia extracelular, medida en ohmios. - “Ri”: Resistencia intracelular, medida en ohmios. - “C”: Capacidad asociada a las membranas celulares, medida en nanofaradios. - “alpha”: Parámetro característico de la distribución de las frecuencias de relajación. Es un parámetro adimensional. - “Td”: Retraso temporal invariante con la frecuencia, medido en nanosegundos. Figura 3-7. Tabla “Par_Bioimp” La tabla “Par_Bioimp” tiene una relación 1:1 con la tabla “Medición” (Figura 3-3), es decir, por cada medición realizada a un paciente se tendría una entrada en la tabla “Par_Bioimp”.  Tabla “Par_Comp_Cor” Almacena los distintos parámetros de composición corporal obtenidos gracias a los parámetros de bioimpedancia como resultado de las mediciones de la observación a los pacientes. - “ID_Med”: Identificador único de la observación realizada al paciente. - “BCM”: Masa celular corporal. - “%BCM”: Porcentaje de masa celular corporal. - “ECW”: Volumen de agua extracelular. - “ICW”: Volumen de agua intracelular. - “TBW”: Agua corporal total. - “FFM”: Masa libre de grasa. - “%FFM”: Porcentaje de masa libre de grasa. - “FFMI”: Índice de masa libre de grasa. 29 29 Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado - “FM”: Masa grasa. - “%FM”: Porcentaje de masa grasa. - “FMI”: Índice de masa grasa. - “Sobre_Hidr”: Sobrehidratación. Figura 3-8. Tabla “Par_Comp_Cor” La relación de la tabla “Par_Comp_Cor” con la tabla “Medición” es la misma que tiene la tabla “Par_Bioimp”, una relación 1:1 (Figura 3-3). 3.2.2 Implementación de la Base de Datos El manejo de la base de datos en este proyecto se ha implementado a través de código Java utilizando el IDE de Eclipse. La interacción con la base de datos SQLite se realiza mediante consultas SQL, que son gestionadas por clases y métodos dedicados dentro del proyecto. A continuación, se describe cómo se ha estructurado el código y los principales métodos utilizados para la gestión de la base de datos.  Conexión a la Base de Datos: - El primer paso para interactuar con la base de datos es establecer una conexión. Para ello, se utiliza la clase “SQLiteConnection”, que configura la conexión a la base de datos SQLite a través de la ruta del archivo que contiene la base de datos. Esta función se ha implementado en el método constructor de la clase “GestionBBDD”: Resultados 30 Figura 3-9. Código referente a la conexión con la base de datos  Consulta y Recuperación de Datos: - Se han implementado métodos para realizar consultas a la base de datos, como la búsqueda de un paciente o dispositivo específico. Estos métodos devuelven los datos solicitados y se utilizan para verificar si los registros ya existen antes de insertar nuevos datos. Para ello se ha utilizado el método “consultarRegistros”: Figura 3-10. Código referente a la consulta a la base de datos  Ejecución de sentencias SQL: - Uno de los componentes clave del sistema es un método genérico que permita ejecutar sentencias SQL, que podría ser utilizado tanto para la consulta de registros como para la inserción de datos. Este método centraliza la ejecución de operaciones SQL, facilitando la reutilización del código y mejorando la mantenibilidad del sistema. A continuación, se muestra el método “ejecutarSentenciaSQL” creado para dicha función: 31 31 Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado Figura 3-11. Código referente a la ejecución de sentencias SQL  Inserción de datos: - Los datos obtenidos del fichero CSV se insertan en las correspondientes tablas mediante sentencias “INSERT”. Estas operaciones están encapsuladas en métodos específicos dentro de la clase que gestiona cada entidad. Para ejecutar estas sentencias “INSERT” se ha utilizado el método “ejecutarSentenciaSQL” mencionado anteriormente. Para dicha función se ha creado el método “insertarBBDD”: Figura 3-12. Código referente a la inserción de datos en la BD Resultados 32 3.3 Recursos FHIR A continuación se van a describir los campos de los recursos FHIR usados en detalle. Con ello, se comprobará cúales han sido usados para el desarrollo del proyecto. 3.3.1 Recurso Patient El recurso Patient [17] representa a una persona que recibe atención médica en un contexto clínico. En este proyecto, se utiliza para almacenar la información básica de los pacientes cuyos datos de bioimpedancia están siendo gestionados. Los campos utilizados en este recurso son: - “Identifier”: Este campo se usa para asignar un identificador único al paciente, basado en el ID extraído del fichero CSV que como ya se mencionó anteriormente es su DNI. - “Gender”: Se configura el género del paciente utilizando el campo “Gender”, que acepta valores como “MALE”, “FEMALE”, y “UNKNOWN”. Esta información se extrae del fichero CSV, que simula la recepción de datos desde el dispositivo de bioimpedancia. - “BirthDate”: Este campo almacena la fecha de nacimiento del paciente, también obtenida del fichero CSV. El uso de estos campos es crucial para identificar al paciente y gestionar su información en el sistema FHIR [2], facilitando su localización y manipulación en operaciones posteriores. 3.3.2 Recurso Device El recurso Device [21] se utiliza para representar el dispositivo de bioimpedancia que recopila los datos del paciente. Este recurso permite gestionar los dispositivos involucrados en las mediciones. Los campos utilizados en este recurso son: - “Identifier”: Similar al recurso Patient, este campo se utiliza para asignar un identificador único al dispositivo, basado en el ID del dispositivo que se extrae del fichero CSV. Esto asegura que cada dispositivo sea único en la base de datos. - “Status”: El estado del dispositivo se configura utilizando el campo “Status”, que se establece como “ACTIVE”. Este campo indica que el dispositivo está operativo y en uso para realizar mediciones. La correcta configuración de este recurso garantiza que los datos de bioimpedancia se asocien adecuadamente con el dispositivo que realizó la medición, lo cual es esencial para el seguimiento y trazabilidad en el contexto clínico. 3.3.3 Recurso Observation El recurso Observation [18] se utiliza para almacenar las mediciones de bioimpedancia obtenidas de los pacientes, en concreto solo se almacenan en este recurso los parámetros de composición corporal. En el contexto del proyecto, este recurso es fundamental para registrar y manejar los datos biométricos. Los campos utilizados son: - “Status”: El estado de la observación se configura como “FINAL”, indicando que la medición ha sido completada y no es provisional. - “Code”: Este campo se utliza para especificar el tipo de medición realizada, como “Body height” para la estatura, ya que ni en el recurso Patient ni en el recurso Observation existe un campo específico para indicar la estatura del paciente. Los códigos se extraen de sistemas estándar como LOINC [19] o SNOMED [20]. - “Value”: Aquí se almacena el valor de la medición anterior (por ejemplo, la estatura en centímetros). Se utiliza el campo “Quantity” para almacenar el valor numérico y su unidad de medida. - “Effective”: Este campo almacena la fecha y hora en que se realizó la observación, utilizando el tipo de datos “DateTimeType”. 33 33 Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado - “Subject”: Se establece una referencia al recurso Patient que corresponde al paciente asociado con la observación. - “Device”: Se configura una referencia al recurso Device que representa el dispositivo utilizado para realizar la medición. Adicionalmente, se utiliza el campo “Component” para almacenar mediciones detalladas de bioimpedancia. En concreto se incluyen los parámetros de composición corporal como la Masa Corporal Magra (FFM), Agua Corporal Total (TBW), y el resto de parámetros corporales, todos ellos configurados dentro del recurso Observation. Para ello se ha hecho uso de los campos como ya hemos mencionado “Component”, y además los campos “Code”, “Value” y “Quantity”. Podemos observar en la Figura 3-13 como se ha llevado a cabo este proceso: Figura 3-13. Parámetros de composición corporal en el recurso Observation Resultados 34 Como se puede apreciar en la Figura 3-13, varios parámetros de composición corporal tienen configurado los campos “System” y “Code” con valores reales. En este caso se ha usado SNOMED como sistema de terminología médica, ya que LOINC no dispone de algunos códigos relacionados a parámetros de composición corporal. Aquellos parámetros de composición corporal que sí disponen de código en SNOMED CT [30]: Extracellular Water (ECW) con el código 55450009, Intracellular Water (ICW) con el código 20125000, Total Body Water (TBW) con el código 251837008, Fat-Free Mass (FFM) con el código 248363008, Fat Mass (FM) con el código 5941000237109, y Overhydration (Sobrehidratación) con el código 61688009. Algunos de estos parámetros de composición corporal también disponen de código en LOINC pero por unicidad se ha decicido utilizar SNOMED, ya que era el sistema que disponía de más parámetros de composición corporal. 3.3.4 Recurso Bundle El recurso Bundle [22] se utiliza principalmente para manejar conjuntos de recursos relacionados, y en nuestro proyecto ha sido utilizado para la búsqueda de pacientes y dispositivos ya existentes o no en la base de datos de FHIR. Se realizan consultas sobre los recursos Patient y Device, asegurando que no se creen duplicados. Los campos utilizados en este recurso son: - “Entry”: Contiene una lista de recursos encontrados durante la búsqueda. Este campo es útil para identificar si un paciente o dispositivo ya existe en la base de datos. - “Type”: Especifica el tipo de operación realizada, como una búsqueda o creación de recursos. En la Figura 3-14 podemos observar el uso de este recurso para este proyecto. Figura 3-14. Uso del recurso Bundle 3.4 Implementación de la aplicación En este apartado se detallará la implementación de la aplicación. Se comenzará describiendo la estructura de esta aplicación junto a los paquetes en los que se ha dividido para después entrar en el código usado para lograr su correcto funcionamiento. 3.4.1 Estructura del proyecto El servicio está dividido en dos paquetes. El primer paquete incluye los códigos referentes a la implementación de la aplicación junto con el código que realiza la lectura de los ficheros CSV, y el código que se encarga de toda la gestión de recursos y parámetros de FHIR. El segundo paquete se utiliza para implementar el código referente a la base de datos ya que es un sistema externo que no pertenece a FHIR, es por eso la razón de la división de la aplicación en dos paquetes. 35 35 Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado Figura 3-15. Paquetes de la aplicación 3.4.1.1 Paquete “com.mycompany.dispositivo_Bioimpedancia_App” El paquete está formado por las siguientes clases Java:  “Aplicación.java”: Este archivo contiene el punto de entrada principal de la aplicación. Aquí se inicializa el proceso de lectura del archivo CSV, la gestión de los datos obtenidos y la interacción con el sistema FHIR.  “Gestion_Fhir.java”: Esta clase es responsable de la comunicación con el servidor FHIR para realizar operaciones como la creación, lectura y actualización de recursos (explicado en el apartado 3.3).  “Lectura_Fichero.java”: Esta clase se encarga de la lectura y procesamiento del archivo CSV o cualquier otro formato que se utilice para la entrada de datos en la aplicación. 3.4.1.2 Paquete “com.mycompany.dispositivo_Bioimpedancia_App.BBDD” El paquete está formado por la clase “GestionBBDD.java”:  Como se explicó en el apartado 3.2, esta clase se encarga de la conexión y las operaciones de base de datos, como la inserción, actualización y consulta de registros. 3.4.2 Implementación del código En este subapartado se describe el resto de código de la aplicación que aunque se ha mencionado no ha sido detallado anteriormente. A continuación, en la Figura 3-16 se puede observar el fichero “build.gradle”, fichero necesario para cargar las dependencias necesarias para poder trabajar con la especificación FHIR. Figura 3-16. Fichero “build.gradle” Resultados 42 Para cada tipo de medición (por ejemplo, BCW, ECW, ICW, etc.), se añade un componente al recurso Observation que incluye el código del sistema de terminología médica (como SNOMED o LOINC), la unidad de medida y el valor correspondiente (Figura 3-13). 3.4.3 Resumen del proceso de la aplicación A continuación, se presenta un resumen de todo el proceso por el que pasa la aplicación hasta llegar al resultado final. Además, el proceso está representado en el diagrama de flujo UML [29] de la Figura 3-24. 1. Se inicia “Aplicación.java” y establece la conexión con la base de datos SQLite a través del constructor de la clase “GestionBBDD.java”. En caso de que se establezca la conexión correctamente aparecería un mensaje por el terminal confirmando la conexión establecida, en caso contrario nos mostraría un mensaje de error de conexión. La aplicación seguiría funcionando hasta insertar los datos en la base de datos, lo cual daría error y la aplicación terminaría. 2. Se declaran las variables correspondientes a las clases “Lectura_Fichero.java” y “Gestion_Fhir.java”, y mediante el método “leer_fichero()” de la clase “Lectura_Fichero.java” se comienza a leer el archivo CSV por la primera línea. En caso de error o fin de fichero, este método devolvería null y la aplicación terminaría. En caso contrario, se procesaría la primera línea y se seguiría con el programa. 3. Todas los campos leídos se guardarían en variables de la clase “Lectura_Fichero.java” y se insertarían en la base de datos mediante el método “insertarBBDD()” de la clase “GestionBBDD.java”. En caso de existir un error en la inserción de datos en la base de datos se imprimiría por terminal un error informando de ello y la aplicación terminaría. 4. El siguiente paso es configurar los recursos FHIR mediante el método “configurarRecursos()” de la clase “Gestion_Fhir.java”. En primer lugar, se comprueba si en la base de datos de FHIR existe un paciente con identificador de paciente igual al leído en el fichero CSV. Si existe se guarda la referencia del paciente ya existente, y si no existe se crea el recurso Patient configurando todos sus parámetros necesarios y se guarda la referencia del recurso que se acaba de crear. Posteriormente, se hace lo mismo para el recurso Device y se guarda su referencia correspondiente, pasando a configurar los campos necesarios del recurso Observation. Si todo ha ido correctamente, se imprime por pantalla que todo ha sido configurado correctamente. 5. Por último, se vuelve a leer una nueva línea del fichero CSV. En caso de no existir ninguna línea más en el fichero, devolveríamos null, saldría del bucle y terminaríamos la aplicación. A continuación, en la Figura 3-24 se puede observar el diagrama de flujo UML que representa gráficamente lo explicado anteriormente. 43 43 Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado Figura 3-24. Diagrama de flujo UML representando el proceso de la aplicación Resultados 44 3.5 Pruebas A continuación, se muestra el funcionamiento de la aplicación realizando una prueba con datos pertenecientes a tres pacientes. 3.5.1 Comprobación de la gestión de datos En la Figura 3-25 se pueden observar los datos de tres pacientes distintos, que se reciben por parte de los dispositivos de bioimpedancia, pero que en este caso se simulan mediante la lectura de datos del fichero CSV. Figura 3-25. Datos de pacientes en el fichero CSV En la siguiente figura, se puede comprobar cómo antes de la ejecución de la aplicación todas las tablas creadas en la base de datos se encuentran vacías. Figura 3-26. Base de datos vacía 3.5.2 Ejecución Una vez todo preparado para la ejecución, se lanza la aplicación y durante el transcurso de la misma se puede monitorizar su ejecución mediante los mensajes que se imprimen en la terminal. La aplicación finalizará cuando la recepción de datos haya llegado a su fin, es decir, cuando el lector de ficheros llegue al final del fichero CSV. En la Figura 3-27, se puede ver un ejemplo de la salida por pantalla una vez se ha ejecutado la aplicación. 45 45 Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado Figura 3-27. Ejemplo de ejecución La razón por la que en pantalla se imprime que los recursos Patient y Device de los tres pacientes ya existen es debido a las ejecuciones realizadas anteriormente para comprobar el correcto funcionamiento de la aplicación, por lo que esto indica que ya existen las referencias de los pacientes y dispositivos en la base de datos FHIR con sus correspondientes identificadores. 3.5.3 Comprobación del correcto almacenamiento en la base de datos En la Figura 3-28, se puede comprobar que se han persistido correctamente los datos recibidos por los dispositivos de bioimpedancia (sólo se muestran algunas tablas de la base de datos, debido a la larga extensión de alguna de ellas). Figura 3-28. Base de datos completa Resultados 46 3.5.4 Comprobación del correcto almacenamiento en el servidor FHIR A continuación se va a mostrar la comprobación de que los datos de un paciente a través de los recursos se almacenan correctamente en el servidor FHIR. En la Figura 3-29 se puede observar el resultado de la primera ejecución de la aplicación con un paciente cuyo ID de paciente no existe aún en la base de datos FHIR. Figura 3-29. Primera ejecución de la aplicación Al no existir el recurso Patient en la base de datos de FHIR, lo crea, y así sucede también con el recurso Device. Si se introduce el enlace que nos proporciona la salida de la aplicación, se puede corroborar que los datos han sido almacenados correctamente en el servidor FHIR (Figura 3-30, Figura 3-31, Figura 3-32). Figura 3-30. Instancia del recurso Patient 47 47 Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado Figura 3-31. Instancia del recurso Device Figura 3-32. Instancia del recurso Observation Resultados 48 Además, se puede comprobar en la interfaz gráfica que nos ofrece HAPI FHIR del servidor FHIR cómo las instancias de los recursos Patient, Device y Observation se han guardado en dicho servidor (Figura 3-33, Figura 3-34, Figura 3-35). Figura 3-33. Respuesta del servidor FHIR del recurso Patient Figura 3-34. Respuesta del servidor FHIR del recurso Device 49 49 Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado Figura 3-35. Respuesta del servidor FHIR del recurso Observation Por último, si se vuelve a realizar una nueva ejecución con los mismos datos de los pacientes y dispositivos de la anterior ejecución, estos deberían de estar ya almacenados en el servidor FHIR, por tanto no debería crear nuevos recursos según el código implementado en la aplicación. En la Figura 3-36, se pude ver esta confirmación. Figura 3-36. Segunda ejecución de la aplicación 50 4 CONCLUSIONES Y LÍNEAS FUTURAS n este último capítulo vamos a mostrar las conclusiones que hemos extraído del desarrollo de este proyecto, los resultados obtenidos tras los objetivos que nos hemos ido marcando, y propondremos una serie de líneas de trabajo futuras que se pudieran desarrollar a partir de este trabajo realizado. 4.1 Conclusiones El desarrollo de este Trabajo Fin de Grado nos ha permitido explorar la estandarización FHIR, así como su integración en el ámbito sanitario y tecnológico, en nuestro caso con datos obtenidos a partir de mediciones a pacientes para obtener sus parámetros de bioimpedancia. A lo largo de este proyecto, hemos ido consiguiendo el cumplimiento de los objetivos planteados dividiendo el objetivo principal (desarrollar una aplicación intermediaria entre dispositivos de bioimpedancia y organizaciones sanitarias), en distintos subobjetivos, los cuales nos han tomado su tiempo ya que queríamos asegurarnos de que se cumplieran de forma correcta. Finalmente, hemos conseguido desarrollar una aplicación capaz de procesar los datos de bioimpedancia, persistirlos en una base de datos, y posteriormente mapearlos al formato FHIR para poder ser enviados y gestionados por los sistemas de información sanitaria. Al comienzo, nos decantamos por la utilización de un IDE como Apache NetBeans, pero este entorno de desarrollo era difícil de manejar a la hora de organizar el proyecto en paquetes, actualización de dependencias (ya sean mediante Maven o Gradle), importación de librerías FHIR, etc. Por tanto, decidimos usar como entorno de desarrollo Eclipse IDE para el desarrollo de la aplicación y SQLite para la gestión de la base de datos. Estas herramientas han demostrado ser adecuadas para la complejidad del proyecto, proporcionando un entorno de desarrollo fácil de manejar. No obstante, también hemos identificado ciertos desafíos, como la complejidad de la manipulación de datos de bioimpedancia y la necesidad de comprender en profundidad el estándar FHIR y su API (HAPI FHIR) para un mapeo y uso de los datos adecuado. Este estándar, para aquellas personas que nunca lo hayan manipulado o investigado es complejo al inicio, debido a la poca documentación que existe para lograr entender el manejo de recursos FHIR. A pesar de estos desafíos, podemos concluir que las soluciones implementadas han sido satisfactorias en su mayoría. La estructura de la aplicación, junto con los métodos y clases desarrollados, han demostrado ser eficaces para el procesamiento y almacenamiento de datos. Sin embargo, a pesar de haber intentado ser lo más eficientes posible en este aspecto, algunos procesos podrías haberse optimizado más, en especial en lo que respecta a la eficiencia en la gestión de los datos de bioimpedancia. “Cada final es un nuevo comienzo.” - TS Eliot - E 51 51 Aplicación para la integración de un dispositivo de bioimpedancia en un entorno sanitario estandarizado 4.2 Líneas futuras El proyecto es solo el comienzo de lo que podría ser una solución más amplia y completa para la integración de datos de bioimpedancia en sistemas sanitarios. Dada la naturaleza limitada de este trabajo y el cumplimiento de los objetivos propuestos al comienzo del mismo, consideramos que hay varias líneas de trabajo futuras que podrían desarrollarse a partir de esta base:  Implementación de un servicio de escucha de datos en tiempo real: Una de las primeras extensiones que podrían realizarse es la implementación de un servicio que esté constantemente a la escucha de peticiones para recibir los datos de los pacientes en tiempo real, directamente desde el dispositivo de bioimpedancia a través de la tecnología Bluetooth que dispone el mismo. Esto permitiría una mayor automatización del proceso, eliminando la necesidad de intervenciones manuales y facilitando el flujo de datos en tiempo real hacia la organización sanitaria.  Incluir mecanismos de seguridad en el sistema: Actualmente, la aplicación utiliza el servidor público de FHIR para la transmisión de datos. Una línea futura crucial sería el desarrollo e implementación de un servidor propio de FHIR (privado), que permita controlar mejor la seguridad y la privacidad de los datos transmitidos. Esto incluiría la implementación de cifrado en las comunicaciones y autenticación segura de usuarios, garantizando que los datos de los pacientes se transmiten de forma segura y cumpliendo con las normativas de protección de datos. Los mecanismos que propone el estándar FHIR son: - Intercambio de datos cifrado mediante TLS/SSL. - Autenticación de usuarios así como control de autorización/acceso de los usuarios. - Uso de firmas digitales.  Optimización del mapeo de datos a FHIR: Aunque el mapeo actual de los datos a recursos FHIR ha sido efectivo, existe margen para mejorar la precisión y eficiencia de este proceso. Esto podría implicar una revisión más exhaustiva del estándar FHIR para identificar otros recursos y perfiles que podrían utilizarse para representar mejor los datos de bioimpedancia, así como la automatización del mapeo para reducir posibles errores.