Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado

Equation Chapter 1 Section 1 Autor: Pablo Aguilera Bonet Tutor: Javier Payán Somet Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Dpto. Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado Sevilla, 2024 Autor: Álvaro Rangel Belmonte Tutor: Jorge Calvillo Arbizu iii Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado Autor: Álvaro Rangel Belmonte Tutor: Jorge Calvillo 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 sensor de frecuencia cardíaca en un entorno sanitario estandarizado Autor: Álvaro Rangel Belmonte 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 mis padres, mi hermana, mis abuelos y mis amigos cercanos. Todos han hecho este camino un poquito más fácil. ix Agradecimientos Abril de 2020. Ese fue el momento en que decidí abandonar la carrera que estaba estudiando previamente, Ciencias de la Actividad Física y del Deporte, para dar un giro de 180 grados y empezar Ingeniería de Telecomunicaciones. Fueron momentos difíciles y de muchas dudas, pero cuatro años después y estando ya a un paso de terminarla, puedo decir con certeza que es la mejor decisión que he tomado en la vida. Comunicarlo a mis seres más cercanos fue complicado, pero todos depositaron total confianza en mi y me apoyaron sabiendo que cualquier reto que me pusiera entre manos lo iba a conseguir. Y aquí estoy, escribiendo estas palabras a punto de cerrar una de las etapas más duras y a la vez gratificantes de mi vida. Gracias a mis padres por haberme brindado siempre su apoyo y por hacerme la vida un poquito más fácil. Gracias a mi hermana por su alegría y por aguantarme todas las quejas de lo agobiado que estaba o lo mucho que tenía que estudiar. Gracias a mis abuelos por haber sido tan buenos conmigo y por ser mi mayor motivación para sacarme este título. Gracias a mis amigos, a los de verdad, a los que puedo contar con los dedos de una mano: Álvaro, Pedro, Mendo y María. Gracias a mis compañeros de carrera, que han hecho todo el camino más llevadero. Gracias a la Universidad y a todos los profesores que han puesto de su parte para enseñarme todo el conocimiento que tenían. Y, por último, gracias a Jorge por el buen trato y la facilidad que tiene para explicar las cosas. Sabía que no me iba a equivocar en mi elección del tutor. Álvaro Rangel Belmonte Sevilla, 2024 ÍNDICE DE TABLAS Tabla 1. Temporización de tareas 5 Tabla 2. Método "obtener" 28 Tabla 3. Método "persistir" 29 Tabla 4. Método "sendData" 30 xvii ÍNDICE DE FIGURAS Figura 1. Esquema general del sistema 3 Figura 2. Metodología incremental 3 Figura 3. Electronic Health Record 7 Figura 4. Health Level 7 9 Figura 5. Representación de un conjunto de recursos FHIR interrelacionados 10 Figura 6. Elementos de un recurso FHIR 11 Figura 7. Significado de iconos 11 Figura 8. Significado de los Flags 12 Figura 9. Tipos primitivos 12 Figura 10. Tipos de datos de uso general 13 Figura 11. Tipos de metadatos 13 Figura 12. Tipos de datos de propósito especial 13 Figura 13. Recurso Observation I 15 Figura 14. Recurso Observation II 15 Figura 15. Recurso Patient 16 Figura 16. Recurso Device 17 Figura 17. Interfaz Eclipse 18 Figura 18. Función MySQL 19 Figura 19. HAPI FHIR Test Server 19 Figura 20. Composición del sistema proxy 21 Figura 21. Datos de las mediciones de frecuencia 22 Figura 22. Datos en el modo de frecuencia instantánea 22 Figura 23. Datos en el modo de frecuencia media 23 Figura 24. Diagrama de la base de datos 23 Figura 25. Tabla "Pacientes" 24 Figura 26. Tabla "Frecuencia" 24 Figura 27. Estructura en Eclipse 25 Figura 28. Clases de la aplicación 25 Figura 29. Dependencias I 26 Figura 30. Dependencias II 26 Figura 31. Dependencias III 26 Figura 32. Dependencias IV 27 xix Figura 33. Dependencias V 27 Figura 34. Dependencias VI 27 Figura 35. Diagrama de flujo del proceso de lectura del fichero de entrada 29 Figura 36. Diagrama de flujo del proceso de persistencia 30 Figura 37. Diagrama de flujo del proceso de mapeo a FHIR y envío al servidor 32 Figura 38. Diagrama de flujo del proceso principal 33 Figura 39. Instancia de recurso Device 34 Figura 40. Conversión tipo Date 34 Figura 41. Ejemplo de instancia del recurso Patient 35 Figura 42. Código con la creación de las instancias Observation para peso y estatura 36 Figura 43. Ejemplo de instancia del recurso Observation para el peso 36 Figura 44. Ejemplo de instancia del recurso Observation para la estatura 37 Figura 45. Ejemplo de instancia del recurso Observation para frecuencia media 38 Figura 46. Ejemplo de instancia del recurso Observation para frecuencia instantánea 39 Figura 47. Datos del fichero de simulación 40 Figura 48. Menú principal I 40 Figura 49. Menú principal II 41 Figura 50. Paciente A I 41 Figura 51. Paciente B I 42 Figura 52. Paciente C I 42 Figura 53. Instancia del recurso Observation para la primera medida del paciente A 43 Figura 54. Instancia del recurso Observation para a primera medida del paciente C 44 Figura 55. Paciente A II 44 Figura 56. Paciente B II 45 Figura 57. Paciente C II 45 Figura 58. Paciente D 45 Figura 59. Instancia del recurso Patient para el paciente A 45 Figura 60. Instancia del recurso Patient para el paciente B 46 xxi Notación FHIR Fast Healthcare Interoperability Resources HL7 Health Level Seven EHR API IDE UML XML ANSI POM IA LOINC Electronic Health Record Application Programming Interface Integrated Development Environment Unified Modelling Language Extensible Markup Language National Standards Institute Project Object Model Inteligencia Artificial Logical Observation Identifiers Names and Codes 1 1 INTRODUCCIÓN n el primer apartado vamos a hablar de la motivación, los objetivos, la metodología y las tareas de este proyecto. Abordaremos el plan de trabajo llevado a cabo y la temporización que ha requerido las diferentes partes. 1.1 Motivación La motivación de este proyecto viene de la urgencia crítica de mejorar la interoperabilidad y eficacia a la hora de administrar los datos médicos. Actualmente sigue ocurriendo que estos datos se encuentran en sistemas específicos en cada organización sanitaria que los gestiona. Esto va a ocasionar dificultad cuando sea necesario el intercambio de ellos, lo cual puede generar errores, duplicidad e incoherencias y, en general, una atención sanitaria menos eficiente para los pacientes. La pandemia del COVID-19 ha puesto en evidencia la necesidad de una mejora continua en los sistemas sanitarios, así como de disponer de mecanismos para tratar toda la información médica con robustez y precisión. Es por ello que estos sistemas deben ser capaces de realizar la compartición de datos de forma rápida y segura, lo cual posibilitará una mejor coordinación entre los distintos actores implicados. Aquí entra en juego la Historia Clínica electrónica (o EHR) [1], un sistema para manejar y gestionar en formato electrónico historiales médicos. EHR colecciona una gran cantidad de datos, ya pueden ser diagnósticos, prescripciones médicas, vacunas, y lo que nos interesa en nuestro caso, mediciones de frecuencia cardiaca. Puede funcionar independientemente o integrarse con otros sistemas, además de seguir protocolos estrictos en cuanto a seguridad. Aunque no existe un formato obligatorio para el almacenamiento de los datos en los sistemas de EHR, existen diversos estándares que promueven soluciones normalizadas para facilitar la interoperabilidad entre los sistemas y el intercambio de datos de salud. El estándar FHIR [2] elaborado por HL7 [3] brinda una solución a estos problemas al proporcionar un marco estandarizado para facilitar la interoperabilidad de los datos sanitarios. FHIR estandariza el formato de las entidades de información que se utilizan en el dominio sanitario y nos ofrece diferentes posibilidades para la compartición de dicha información, asegurando que los datos de salud sean accesibles de forma eficiente y segura. La importancia de una estandarización de los datos sanitarios puede ser resumida en los siguientes puntos: • Cualquier profesional de la salud podrá acceder a información de un paciente de manera rápida y sencilla independientemente del sistema u organización que la haya generado. • La posibilidad de concentrar un historial médico completo va a resultar en una mejora en la toma de decisión por parte de los profesionales. E Be the change you want to see in the world. - Mahatma Ghandi - Introducción 2 • Se evita la duplicidad de información al compartir diferentes recursos entre sistemas. • Recopilar y analizar datos de distintas organizaciones con un formato único va a suponer un avance en la monitorización en la salud pública. Además del desafío de la interoperabilidad de los datos médicos, es crucial considerar la monitorización continua de pacientes. Los datos generados por dispositivos de monitorización, como los signos vitales, los niveles de glucosa, etc., también deben estar estandarizados. Al normalizarlos, se facilita su integración en los ya mencionados sistemas EHR, permitiendo una visión más completa y precisa del estado de salud del paciente. Esto no solo mejora la coordinación y la toma de decisiones por parte de los profesionales sanitarios, sino que también garantiza que la información relevante esté siempre disponible y actualizada, independientemente del dispositivo o sistema que la haya generado. Al automatizar el procesamiento de EHR, se pueden convertir todos los datos del paciente en un formato estructurado y estandarizado que se puede utilizar, comúnmente, entre instituciones u organizaciones. Además, también se pueden desarrollar sistemas utilizando la IA, la cual cada vez está más extendida, para que marquen cualquier información faltante o errores en los datos, asegurando que toda la información médica del paciente sea correcta, coherente y esté actualizada. Esto libera muchas tareas manuales del personal clínico y aumenta el tiempo disponible para que los médicos se centren en el paciente y sus necesidades. Dentro de este ámbito de interoperatividad y estándares, el presente trabajo se centra en la estandarización de datos de un sensor de frecuencia cardíaca conforme al estándar FHIR. Este trabajo cubre la recogida de datos provenientes de un sensor de frecuencia cardíaca, su persistencia, mapeo al estándar y envío a un servidor FHIR para su almacenamiento. Los datos del sensor serán simulados debido a la imposibilidad de contar con uno real. 1.2 Objetivos El objetivo principal va a ser el diseño e implementación de un sistema que actúe como proxy o intermediario entre un sensor de frecuencia cardíaca y el servidor FHIR al cual mandaremos los datos obtenidos. Este objetivo principal puede ser dividido en los siguientes subobjetivos: • Comprensión del estándar FHIR: realización de un estudio del estándar FHIR para el almacenamiento y comunicación de datos sanitarios. Entre los recursos que ofrece el estándar, nos centraremos en los recursos Patient (el cual va a representar la información de un paciente), Device (el cual va a representar la información de un dispositivo de medida) y Observation (que representará los diferentes parámetros significativos correspondientes a una medida de frecuencia cardiaca realizada). • Diseño de la aplicación que servirá de sistema proxy que se encargue de recibir los datos de frecuencia cardíaca proveniente del sensor de frecuencia cardiaca. En nuestro caso, ante la imposibilidad de la utilización de un dispositivo real, vamos a simular la recepción de los datos mediante la lectura de un archivo de texto. • Persistencia de los datos. Aquellos datos recibidos referentes a las mediciones de frecuencia cardíaca deberán ser correctamente persistidos en una base de datos. • Mapeo de datos al estándar FHIR. Realizar el diseño del mapeo de datos entre los datos recogidos y el estándar sanitario FHIR • Envío de los datos al servidor HAPI FHIR, el cual proporciona una implementación completa de las especificaciones de FHIR. • Pruebas y validación. Realizar una comprobación exhaustiva de la correcta implementación de nuestro sistema proxy, asegurándonos de que todos nuestros datos han sido correctamente obtenidos y enviados. A continuación, en la Figura 1 se puede observar un pequeño esquema del funcionamiento completo de todo el 3 3 Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado sistema proxy que vamos a desarrollar. Figura 1. Esquema general del sistema Donde cada número indica lo siguiente: 1. Envío de la información por parte del sensor de frecuencia cardíaca y recepción de los datos por parte de nuestro sistema proxy. 2. Persistencia de los datos en la base de datos. 3. Envío de datos al servidor de FHIR 1.3 Metodología En nuestro caso vamos a utilizar una metodología incremental. Vamos a ir realizando un proceso iterativo donde iremos mejorando el proyecto poco a poco. Esto nos va a permitir tener mayor flexibilidad para realizar cambios en los requisitos a lo largo del desarrollo. Además, podemos ir corrigiendo errores en las primeras etapas gracias a las comprobaciones parciales del sistema, lo que nos va a permitir no arrastrar fallos en etapas más tardías. Figura 2. Metodología incremental La revisión del proyecto al acabar cada incremento nos va a permitir diferenciar qué está funcionando bien, qué está provocando errores y cuál es el camino a seguir en la siguiente fase. Así, cada vez que terminemos una, tendremos un sistema cada vez más funcional y cercano a la meta final. Estado de la técnica 10 manipularse a través de las URL propias de recursos. 2.2.2.1 Arquitectura FHIR FHIR tiene una organización basada en recursos (p. ej., Observation, Patient). Además, se pueden definir perfiles haciendo que se vinculen a una terminología más específica, lo cual hará estos recursos más específicos a su vez. Está implementado sobre el protocolo HTTPS, es por ello que las plataformas de análisis pueden recuperar estos recursos y analizarlos haciendo la recopilación en tiempo real. Los recursos se pueden mandar a una gran base de datos donde se podrán relacionar con otros datos informáticos. Las posibilidades en cuanto a casos de uso son muy variadas, ya sean perseguir los fraudes de medicamentos, posibles interacciones adversas entre fármacos y también reducir la espera en las salas de emergencia. Figura 5. Representación de un conjunto de recursos FHIR interrelacionados 2.2.2.2 Recursos FHIR Un recurso se puede definir como una entidad que cumple con los siguientes puntos: • Tiene una identidad conocida a partir de la cual puede ser manejado. • Entra dentro de uno de los tipos de recursos que se definen en la especificación FHIR. • Comprende una variedad de elementos de datos con una estructura que sigue la definición de su propio tipo. • Está identificado por una versión que va a cambiar si el contenido del recurso cambia. En la siguiente imagen se muestra el contenido de un recurso, cuyos campos definiré posteriormente. 11 Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado Figura 6. Elementos de un recurso FHIR Podemos observar que para cualquier recurso se definen: • Un identificador, bajo el nombre de id. Se trata del id lógico de la instancia recurso, usado en la URL para referirnos a la instancia del recurso. Una vez asignado, este valor nunca va a cambiar. • Metadatos, bajo el nombre de meta. Este es el contenido que es mantenido por la infraestructura. Cuando se producen cambios en el contenido no siempre tiene que estar relacionado con un cambio de versión del recurso. • Una referencia a las reglas implícitas, bajo el nombre de implicitRules. Se trata de una referencia al conjunto de reglas que fueron seguidas cuando el recurso fue construido, y las cuales deben ser seguidas al procesar el contenido. • Un lenguaje base, bajo el nombre de language. Se trata del lenguaje base en el cual está escrito el recurso. Podemos observar que al lado de cada elemento aparecen iconos, los cuales nos van a dar información acerca del propio elemento. En la siguiente imagen obtenido de la documentación oficial se muestran todos los iconos existentes y qué significa cada uno. Figura 7. Significado de iconos La columna de Flags indica un conjunto de información acerca del elemento que va a tener impacto a la hora de cómo se va a manejar en la implementación. Las diferentes flags que pueden aparecer vienen resumidas en la siguiente imagen. Estado de la técnica 12 Figura 8. Significado de los Flags Por último, la columna de Cardinality nos va a indicar la mínima y máxima cantidad de veces que algún elemento puede aparecer en el recurso. Esta especificación define las siguientes cardinalidades: 0..1, 0..*, 1..1 y 1..*. Para definir los elementos de dichos recursos, la especificación FHIR tiene definido un conjunto de Datatypes. Tenemos 5 categorías: 1. Los tipos abstractos básicos que proporcionan la base para todos los tipos. 2. Tipos simples/primitivos, que son elementos únicos con un valor primitivo. 3. Tipos complejos de uso general, que son grupos de elementos reutilizables. 4. MetaDatatypes: Un conjunto de tipos para usar con recursos de metadatos. 5. Tipos de datos de propósito especial: definidos en otras partes de la especificación para usos específicos: Referencias, Meta, Narrativa, etc. Figura 9. Tipos primitivos 13 Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado Figura 10. Tipos de datos de uso general Figura 11. Tipos de metadatos Figura 12. Tipos de datos de propósito especial Estado de la técnica 14 2.2.2.3 Recursos FHIR utilizados Ahora nos vamos a centrar en los 3 recursos principales con los que hemos trabajado en el desarrollo de nuestro sistema. Estos serían Patient, Observation y Device. Recurso Observation [7] Las observaciones juegan un papel fundamental en la atención médica, ya que se utilizan para respaldar diagnósticos, seguir el progreso de los pacientes, establecer puntos de referencia y patrones, y registrar características demográficas, además de los resultados de pruebas en productos y sustancias. La mayoría de las observaciones son simples pares de nombre/valor con algunos metadatos, pero algunas pueden agrupar otras observaciones de manera lógica o consistir en múltiples componentes. Es importante destacar que el recurso DiagnosticReport proporciona un contexto clínico o de flujo de trabajo (se trata de un recurso de evento desde una perspectiva de flujo de trabajo de FHIR), para un conjunto de observaciones, y el recurso Observation es referido por DiagnosticReport para representar datos de laboratorio, imágenes y otros datos clínicos y de diagnóstico, formando así un informe completo. Los usos del recurso Observation incluyen: • Signos vitales como peso corporal, presión arterial y temperatura. • Datos de laboratorio como glucosa en sangre o una tasa de filtración glomerular estimada (TFG). • Resultados de imágenes como densidad ósea o mediciones fetales. • Hallazgos clínicos como sensibilidad abdominal. • Mediciones de dispositivos como datos de ECG o datos de oximetría de pulso. • Configuraciones de dispositivos como parámetros de ventiladores mecánicos. • Herramientas de evaluación clínica como APGAR o una puntuación de Glasgow. • Características personales como el color de ojos. • Historia social como el uso de tabaco, el apoyo familiar o el estado cognitivo. • Características básicas como el estado de embarazo o una afirmación de muerte. • Pruebas de calidad de productos como pH, ensayos, límites microbianos, etc., en productos y sustancias. En las siguientes imágenes se muestra todo el contenido de este recurso. 15 Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado Podemos observar la gran cantidad de campos que tiene este recurso. Algunos de los más importantes pueden ser el Identifier, el cual asigna identificadores únicos a la observación; Status, que va a indicar el estado de la observación (Registrada, Final, Preliminar, etc.); Category, que clasifica la observación (vitales, imagen, laboratorio, etc...); Subject, mediante el cual podemos hacer referencia al recurso Patient al cual está referida; Value[x], el cual contiene el valor que hemos obtenido de la observación, pudiendo presentarse en diferentes formatos (cantidad, concepto, cadena de texto, etc.); Interpretation, que va a ofrecer una interpretación del resultado obtenido anteriormente; y Component, con el cual se pueden añadir sub-observaciones adicionales, muy útil para cuando obtienes numerosos valores en la observación debido a que es algo más compleja. Recurso Patient [8] Este recurso trata datos sobre pacientes involucrados en un gran número de actividades relacionadas con la salud, incluyendo: • Actividades curativas • Atención psiquiátrica • Servicios sociales • Atención durante el embarazo • Servicios de enfermería y vida asistida • Servicios dietéticos Figura 13. Recurso Observation I Figura 14. Recurso Observation II Estado de la técnica 16 • Seguimiento de datos de salud personal y ejercicio En nuestro caso va a servir para tratar al paciente que va a realizarse la medición de frecuencia cardíaca. Los datos en el recurso abordan la información del "quién" sobre el paciente. Sus atributos se centran en la información necesaria para apoyar los procedimientos administrativos, financieros y logísticos de las organizaciones. Un registro de paciente generalmente es creado y mantenido por cada organización que presta atención a un paciente. Por lo tanto, un paciente que recibe atención en múltiples organizaciones podría llegar a tener su información en múltiples instancias del recurso Patient. En la siguiente imagen se puede observar el contenido del recurso Patient. Figura 15. Recurso Patient 17 Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado De nuevo, podemos observar que existen una gran cantidad de campos disponibles que nos va a asegurar tener bien definido al paciente del cual esté relacionado este recurso Patient. Volvemos a tener un Identifier, que asigna identificadores únicos al paciente; Active, que indica si el registro del paciente está en uso activo; Name, que asocia nombres con el paciente; Gender, que registra el género; BirthDate, que indica la fecha de nacimiento; y Link, que proporciona enlaces a recursos relacionados con el mismo individuo. Estos atributos van a permitir gestionar eficientemente la información del paciente. Recurso Device [9] El recurso Device trata dispositivos individuales y su ubicación, registrando acciones realizadas, gestión de inventarios, y solicitudes de dispositivos específicos. Incluye dispositivos médicos y no médicos, desde simples hasta complejos. También documenta el Identificador Único del Dispositivo (UDI) y categoriza los dispositivos en múltiples categorías, como activo, reutilizable, implantable y software. En nuestro caso, va a servir para identificar el dispositivo de frecuencia cardíaca que ha realizado la medición sobre el paciente. En la siguiente imagen se muestra un resumen de sus elementos. Figura 16. Recurso Device Estado de la técnica 18 2.3. Herramientas Software En este apartado vamos a hablar de todas las aplicaciones y herramientas de software adicionales que hemos usado para el desarrollo de nuestro sistema proxy. 2.3.1. Eclipse 2023-12 Eclipse IDE es un entorno de desarrollo integrado [10] que hemos utilizado para desarrollar nuestra aplicación en Java, la cual va a ser la parte fundamental de nuestro sistema proxy. Además, hemos utilizado el gesto de dependencias Maven, integrado en este entorno para facilitar la tarea del uso de las librerías Java relacionadas con FHIR. Figura 17. Interfaz Eclipse 2.3.2. Gestor de dependencias Maven Maven es una herramienta de gestión y construcción de proyectos en Java [11]. Facilita la administración de dependencias, la compilación, la prueba y el despliegue de aplicaciones. Maven está basada en POM [9] y utiliza un archivo de configuración llamado pom.xml para definir las dependencias del proyecto, las configuraciones de construcción y otros detalles del proyecto. Gracias a esto, es más sencillo obtener las librerías que necesitaremos para la comunicación con el servidor FHIR. 2.3.3. MySQL Workbench 8.0 CE MySQL Workbench es una herramienta visual unificada para arquitectos de bases de datos, desarrolladores y administradores de bases de datos (DBAs) [12]. MySQL Workbench proporciona modelado de datos, desarrollo SQL y herramientas completas de administración para configuración del servidor, administración de usuarios, copias de seguridad y más. 19 Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado Se ha utilizado para el diseño de una base de datos relacionales orientado a objetos, la cual almacenará la información referente a los pacientes que se han realizado mediciones y a las propias mediciones de frecuencia cardíaca. Figura 18. Función MySQL 2.3.4. HAPI FHIR Test Server Hemos utilizado una API de código abierto para todo lo relacionado con la implementación de FHIR [13]. Además, la API tiene un servidor público dedicado a realizar pruebas. En nuestro caso, hemos utilizado la versión más reciente, R5, de este servidor para enviar la información mapeada al estándar FHIR. Esta información incluye diversas observaciones relacionadas con los pacientes. Figura 19. HAPI FHIR Test Server Resultados 26 dependencias de Maven, el cual se basa en un archivo pom.xml A continuación, tenemos una imagen de las distintas dependencias utilizadas y la explicación de para qué nos va a servir cada una. Primero tenemos la dependencia base de HAPI FHIR, la cual nos va a proporcionar las clases fundamentales y el soporte necesario para el trabajo con FHIR en Java. Esta sería la base de todas las estructuras y funcionalidades de HAPI FHIR. Figura 29. Dependencias I En segundo lugar tenemos la dependencia del cliente de HAPI FHIR, la cual permite interactuar con los servidores de FHIR, proporciona las herramientas necesarias para realizar las operaciones CRUD (Crear, Leer, Actualizar y Eliminar) y buscar recursos FHIR. Figura 30. Dependencias II También debemos incluir la dependencia de las estructuras de R5, la cual va a proporcionar el modelo de datos que se sigue en esta versión del estándar para poder trabajar con ellos. Figura 31. Dependencias III La dependencia de SLF4J (Simple Logging Facade for Java): se trata de una API de registro de log que va a permitir a nuestra aplicación Java la utilización de marcos de registro sin cambiar el código de la aplicación. Esta va a necesitar de una implementación de registro. Nosotros hemos escogido la dependencia SLF4J Simple, la cual va a permitir que los mensajes de registro se puedan redirigir a la consola y es recomendada para configuraciones que no sean muy complejas 27 Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado Figura 32. Dependencias IV Las dependencias StAX y Woodstox. La primera de ellas se trata de una API que proporciona características para el procesamiento de XML, que es como vienen representados los recursos en FHIR. La segunda se trata de una implementación de alto rendimiento de dicha API. Figura 33. Dependencias V Por último, tenemos la dependencia de MySQL, necesaria para realizar la conexión a la base de datos y llevar a cabo todas las operaciones necesarias de persistencia. Figura 34. Dependencias VI 3.3.3 Clases y Métodos En este subapartado vamos a explicar las diferentes clases que tenemos en el código, los métodos utilizados y como interactúan entre ellas. 3.3.3.1 DatosPaciente.java Esta clase se va a encargar de representar y manejar toda la información relacionada con las mediciones de frecuencia cardiaca realizadas a los pacientes. Resultados 28 Va a tener los siguientes atributos: • idDisp: Identificador del dispositivo de medición de frecuencia cardíaca. • idPac: Identificador del paciente al que se ha realizado la medición. Va a ser representado por el DNI. • peso: Peso del paciente • estatura: Altura del paciente • fechaNac: Fecha de nacimiento del paciente • fechaMedicion: Fecha en la que se ha registrado la medición. Va a tener el formato YYYY-MM-DD HH:mm:ss • frecInst: Valor de la frecuencia cardíaca instantánea cuando se realice la medición en el modo pulso a pulso. • frecMedia: Valor de la frecuencia cardíaca media cuando se realice la medición en el modo de frecuencia media. • tiempoMedicion: Tiempo en segundos que ha durado la medición en el modo de frecuencia media. • modo: Modo en el que se ha realizado la medición de los datos de frecuencia cardíaca recibidos. En la siguiente tabla tenemos el método que utilizaremos para la obtención de los datos a partir del archivo de texto. Tabla 2. Método "obtener" Método obtener Descripción Este método será llamado cuando se intente leer el archivo donde se encuentran las líneas simulando los datos a recibir de las distintas medidas de frecuencia cardíaca. Parámetros de entrada String archivo: Será el nombre del fichero de texto que contiene los datos. Parámetros de salida List<DatosPaciente>: Devolverá una lista de instancias de la propia clase. Cada una de ellas será un paciente con sus respectivos datos de la medición que se le ha realizado. Además, tendrá un constructor que asignará los valores obtenidos del archivo a los atributos privados por cada línea que se lea. También contiene los métodos Setters y Getters que, posteriormente, serán utilizados en otra parte del código para obtener ciertos valores y mapearlos al estándar FHIR. En el siguiente diagrama de flujo se observa el comportamiento cada vez que se lee una nueva línea del fichero. 29 Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado Figura 35. Diagrama de flujo del proceso de lectura del fichero de entrada 3.3.3.2 Database.java Esta clase se encargará de realizar la conexión a la base de datos y persistir aquellos datos obtenidos del archivo de las mediciones de frecuencia cardíaca. En la siguiente tabla tenemos el método que utilizaremos para la obtención de los datos a partir del archivo de texto. Tabla 3. Método "persistir" Método persistir Descripción Este método será llamado cuando se haya obtenido la lista de DatosPaciente con los datos correspondientes de las mediciones de frecuencia cardiaca. Parámetros de entrada DatosPaciente datos: Este método aceptará como entrada uno de los DatosPaciente de la lista. Más tarde, en el Main.java se explicará por qué se hace uno a uno y no todos a la vez. Parámetros de salida Void: No tiene parámetros de salida. En el siguiente diagrama de flujo se puede observar el comportamiento cada vez que se procesa una nueva medición de frecuencia cardíaca en la base de datos. Resultados 30 Figura 36. Diagrama de flujo del proceso de persistencia 3.3.3.3 Fhir.java Esta clase será la encargada de realizar el mapeo de datos al estándar FHIR y, posteriormente, realizar la conexión al servidor FHIR para enviarlos. El mapeo de los datos será abordado en mayor profundidad en el siguiente apartado, el 3.4. En la siguiente tabla tenemos el método que utilizaremos para la realización de lo explicado en el apartado anterior. Tabla 4. Método "sendData" Método sendData Descripción Este método será llamado cuando se hayan persistido los datos de un paciente y su correspondiente medición de frecuencia cardiaca en la base de datos. Este método va a crear un contexto FHIR, buscar la existencia del paciente y enviar la información obtenida. Parámetros de entrada DatosPaciente datos: Este método, de nuevo, aceptará como entrada uno de los DatosPaciente de la lista. Parámetros de salida Void: No tiene parámetros de salida. 31 Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado En el diagrama de flujo de la Figura 36 podemos ver el comportamiento cada vez que vamos a enviar una nueva medición de frecuencia cardíaca al servidor FHIR. 3.3.3.4 Main.java Esta será la clase principal, desde la cual se va a llamar al resto de clases y métodos. Nos va a mostrar por pantalla del terminal un pequeño menú en el que vamos a elegir entre dos opciones: la de realizar la simulación de la recepción de datos mediante la lectura de un archivo y posterior envío al servidor FHIR o salir. Una vez escogida la primera, tendremos la oportunidad de introducir por pantalla el nombre del archivo de texto en el que tenemos los datos simulados de las mediciones. Este se pasará como parámetro al método obtener de la clase DatosPaciente.java, la cual nos devolverá una lista de pacientes con todos los datos de las mediciones del archivo. Una vez aquí, entraremos en un bucle for recorriendo esta lista de pacientes. En este, lo primero que se hará es llamar al método persistir de la clase Database.java con el paciente actual como parámetro, persistiendo así la información obtenida. A continuación, se llamará al método sendData de la clase Fhir.java, al que se le pasa como parámetro este mismo paciente. Se mapearán los datos, se harán las comprobaciones pertinentes de su existencia, que más tarde comentaremos con más detenimiento, y se enviarán los datos al servidor FHIR. Antes de volver a entrar en el bucle tenemos programada una pequeña pausa de 20 segundos debido a que el servidor FHIR público que estamos utilizando tarda un pequeño tiempo en actualizar la información que recibe. Por tanto, para asegurar la funcionalidad de nuestra aplicación, y que compruebe correctamente cuando un paciente ya existe en la base de datos o no, debemos esperar este margen de tiempo. En el diagrama UML de la figura 37 se puede ver el comportamiento de la clase principal de nuestra aplicación. Resultados 32 Figura 37. Diagrama de flujo del proceso de mapeo a FHIR y envío al servidor 33 Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado Figura 38. Diagrama de flujo del proceso principal 3.4 Mapeo de datos a recursos FHIR En este apartado vamos a abordar los atributos obligatorios y opcionales de los recursos FHIR que hemos utilizado y cómo los hemos relacionado con los del fichero de texto para que toda la información obtenida a partir de él se persista en el servidor FHIR. 3.4.1 Recurso Device Para el recurso que va a representar a nuestro dispositivo, nos encontramos, revisando la documentación [9], que no tiene ningún atributo obligatorio. En nuestro caso, el dispositivo empleado no es la parte central de nuestro proyecto por lo que, aunque tiene bastantes atributos como ya vimos en el apartado anterior, tan solo vamos a utilizar el llamado identifier. Este atributo es de tipo Identifier, el cual tiene diferentes campos. Nosotros vamos a rellenar el campo value, el cual es de tipo String, con el identificador que hemos obtenido del fichero de texto. En la siguiente imagen Resultados 34 podemos observar el cuerpo de un recurso Device que hemos creado. Figura 39. Instancia de recurso Device 3.4.2 Recurso Patient Para el recurso que va a representar a nuestro paciente tampoco vamos a encontrar ningún atributo obligatorio. Sin embargo, vamos a utilizar algunos de los opcionales para completar con la información que vamos a obtener de nuestra medición de frecuencia cardíaca. Los atributos que vamos a utilizar son los siguientes: • Identifier: Al igual que en el recurso anterior vamos a usar el campo value, que es de tipo String, asignándole el identificador del paciente que obtenemos en el fichero de texto, que se va a corresponder con el DNI de la persona. • BirthDate: Vamos a utilizar la fecha de nacimiento, que es de tipo Date. Para ello vamos a necesitar hacer una conversión de tipo en nuestro código como se puede observar en la siguiente imagen. Figura 40. Conversión tipo Date En la siguiente imagen podemos observar un recurso Patient que hemos creado en el servidor FHIR. 35 Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado Figura 41. Ejemplo de instancia del recurso Patient 3.4.3 Recurso Observation Este recurso va a representar la medición de frecuencia cardíaca que se ha realizado a nuestro paciente. Aquí podemos encontrar campos que son obligatorios, como por ejemplo: Status, que nos va a decir si es una observación final, preliminar, etc., y Code, el cual tiene, a su vez, varios campos: system, code, display, etc. Otros campos que no son obligatorios y que usaremos son: Component, Value, Subject, etc. También vamos a utilizarlo para la información del peso y la estatura. Por tanto, podemos explicar los dos casos por separado: el peso y la estatura, y la medición de frecuencia cardíaca. Peso y estatura Vamos a crear estos dos recursos Observation la primera vez que se registre a un nuevo paciente en el servidor de FHIR, ya que no es necesario que por cada medición de frecuencia cardíaca se creen recursos como el peso y la estatura que no suelen variar en una misma persona. Vamos a utilizar los siguientes atributos: • Status: Vamos a introducir el valor FINAL, ya que es una observación con un valor final obtenido. • Code: En el campo System utilizaremos el sistema de terminologías LOINC [14], la cual es una base de datos universal para la identificación de mediciones, observaciones, etc.; En el campo Code, introduciremos el número correspondiente al peso o la estatura de esta organización; En el campo Display, introduciremos el texto que queremos que aparezca en el recurso FHIR. • Value: Introduciremos la medida del peso o estatura, y en el campo Unit la unidad de medida. • Subject: Vamos a introducir la referencia al paciente del cual estamos realizando la medición para que esté referenciada en el recurso y poder acceder a él dentro del propio recurso Observation de FHIR. En la siguiente imagen podemos ver un extracto de código donde se realiza todo lo mencionado. Resultados 42 Figura 51. Paciente B I Figura 52. Paciente C I 43 Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado Figura 53. Instancia del recurso Observation para la primera medida del paciente A Resultados 44 Figura 54. Instancia del recurso Observation para la primera medida del paciente C Ahora vamos a observar qué ocurre en el caso de la cuarta medición, que en este caso es con un dispositivo nuevo pero un paciente que ya hemos procesado antes. Como podemos ver en la siguiente imagen, el dispositivo se crea como uno nuevo en el servidor de FHIR, mientras que, para el paciente, se realiza una búsqueda por su DNI, y se encuentra que ya hay un recurso Patient creado para él, por lo que solamente se creará el recurso Observation con la medición de frecuencia cardiaca, en este caso en modo frecuencia media. Figura 55. Paciente A II Para las dos siguientes mediciones, tanto el dispositivo como el paciente ya han sido creados en el servidor FHIR, por lo que tan solo se va a crear una instancia del recurso Observation con la medición de frecuencia cardíaca relacionada a ellos. 45 Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado Figura 56. Paciente B II Figura 57. Paciente C II En la última medición va a ocurrir lo contrario que en el segundo caso, se va a utilizar un dispositivo ya registrado pero un nuevo paciente. En la siguiente imagen podemos observar la salida que obtenemos. Figura 58. Paciente D Por último, se muestran los recursos Patient de los pacientes A y B registrados en el servidor FHIR para comprobar que, efectivamente, el sistema está funcionando como debe. Figura 59. Instancia del recurso Patient para el paciente A Resultados 46 Figura 60. Instancia del recurso Patient para el paciente B 3.6. Problemas y soluciones En esta sección resumimos los principales problemas que hemos encontrado durante el desarrollo de nuestra aplicación y como los hemos solucionado. • Incompatibilidad de librerías JAVA: Al ser un proyecto grande con un gran número de recursos y librerías utilizadas, al principio del desarrollo se encontraron muchos problemas de incompatibilidades de versiones entre ellas. Para solucionar este problema decidimos utilizar el gestor de dependencias Maven, el cual se basa en un archivo llamado “pom.xml”, el cual, mediante la inclusión de los nombres de las librerías y sus versiones, se encarga de descargar los archivos .jar necesarios para no obtener ningún tipo de incompatibilidad al iniciar la aplicación. • Tipo de dato “Date”: Cada paciente tiene asignado una fecha de nacimiento, la cual se lee como un String desde el archivo de texto donde se encuentra guardada la información. Al persistir los datos en nuestra base de datos MySql local obteníamos errores de incompatibilidad cuando realizábamos el cambio de tipo String a tipo Date. Finalmente logramos solucionarlo realizando un cambio de formato forzado para que se ajustara a la forma en que Java leía la fecha desde el archivo de texto. • Versión del servidor de FHIR: Las primeras pruebas realizadas realizando envíos de datos al servidor FHIR se hicieron utilizando las librerías de la versión R4 del servidor, por lo que se obtenían errores durante la creación del contexto FHIR para posteriormente crear el cliente y hacer el envío. Tras consultar la documentación, encontramos la forma que había que hacerlo para la versión R5, que es la más actualizada. También estábamos usando los atributos de los recursos en su versión R4, con la suerte de que ninguno de ellos cambiaba en la nueva versión, pudiendo seguir con el trabajo a partir de ahí. 47 Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado 4 CONCLUSIONES Never too high, never too low - Ricky Rubio - n este proyecto dedicado al diseño e implementación de un sistema proxy para lograr la integración de un sensor de frecuencia cardiaca en un entorno sanitario estandarizado ha habido tres pilares claves. El primero de ellos es el sensor de frecuencia cardiaca que, debido a la imposibilidad de conseguir uno, ha tenido que ser simulado mediante datos en un archivo de texto. En el siguiente punto de líneas futuras comentaremos con más detalle este aspecto. El segundo ha sido la construcción de la base de datos relacional para lograr una persistencia de los datos obtenidos. El tercero, y más importante, es el uso de la especificación de FHIR para enviar los datos clínicos al servidor. El estándar FHIR nos ha permitido una mayor facilidad para modelar los datos gracias a los objetos que tiene definidos. La disponibilidad de recursos específicos como pueden ser Patient, Device u Observation ha simplificado la tarea de mapear estos datos de los diferentes pacientes, dispositivos y mediciones clínicas. Además, la documentación de los atributos de cada recurso viene muy bien explicada, haciendo fácil la tarea de rellenar los atributos correspondientes a cada uno de los recursos mencionados anteriormente. El conjunto de todo esto ha permitido que sea más fácil la adaptación de la información obtenida directamente del sensor a dicho estándar sanitario y ha permitido un mejor funcionamiento del sistema. La especificación utilizada nos permite utilizar HAPI FHIR, una API de código abierto que nos permite actuar como servidor y como cliente en cualquier aplicación que creemos. En nuestro caso hemos utilizado los recursos que tiene en la parte del cliente para realizar la conexión al servidor de pruebas de FHIR y poder así realizar las pruebas que verifiquen que nuestro sistema está funcionando correctamente. Durante toda la realización del proyecto se contemplaron dos modos de recepción de datos: frecuencia media y frecuencia instantánea. En el primero, se está simulando una medición continua de la frecuencia cardíaca del paciente y una recepción del valor medio final obtenido. En el segundo, nuestro sistema recibe pulso a pulso las mediciones de frecuencia cardíaca durante un intervalo de tiempo definido, recibiendo así una mayor cantidad de datos que en el primer caso. Esto ha implicado que nuestro sistema se ha desarrollado bajo la premisa de diferenciar el tratamiento de la información del paciente dependiendo del modo de recepción que se esté usando. 4.1 Líneas futuras de desarrollo El proyecto se ha finalizado tras la realización del diseño, desarrollo e implementación de nuestro sistema proxy en el IDE Eclipse, la cual recibe datos, los persiste en una base de datos local y, bajo el estándar sanitario de FHIR, los envía al servidor de pruebas de FHIR. No obstante, tiene mucho margen de mejora en varios aspectos que comentamos a continuación. • Utilizar un sensor de frecuencia cardiaca real: Lamentablemente no hemos podido disponer de uno durante el desarrollo de nuestro sistema por lo que los datos han tenido que ser simulados. Consideramos que añadir un sensor real a nuestro sistema es totalmente posible y enriquecería mucho la calidad del proyecto. Se pueden utilizar librerías para realizar las conexiones por Bluetooth en Java ya que se estuvieron probando al principio del proyecto cuando aún se consideraba la posibilidad de incorporar algún sensor. El siguiente paso a seguir sería el desarrollo de una clase Java donde se realizará la conexión bluetooth al sensor de frecuencia cardiaca y permitiera estar a la escucha para recibir los datos. Una vez obtenidos los datos, habría que ver el formato en el que se obtienen para adaptarlo al formato que ha ido siguiendo nuestro sistema. Una vez aquí, el funcionamiento sería E Conclusiones 48 análogo al actual. • Añadir nuevos recursos FHIR: Nosotros hemos utilizado los recursos Patient, Observation y Device. Se podrían aumentar el número de atributos utilizados en estos recursos. Esto nos permitiría utilizar bases de datos de pacientes más completas con muchísima cantidad de información, haciendo así que nuestra aplicación maneje una mayor cantidad de información. Otra posible mejora relacionada es la ampliación de la información que se puede manejar pudiendo así utilizar nuevos recursos tales como Organization, Coverage, Citation, CarePlan. Todo esto haría que nuestro sistema se encargara de más tareas, además de la recolección de datos de un paciente. • Adición de seguridad: Debido a la limitación del alcance propuesto como trabajo fin de grado, el sistema no es todo lo seguro que debería ser. Siempre viene bien incluir algún mecanismo de seguridad en el intercambio de datos como el cifrado TLS/SSL, la autenticación de un usuario cuando se inicia la aplicación, etc. • Añadir una interfaz gráfica: Al ser un sistema proxy no hemos querido ahondar en el tema de la interfaz, pero siempre resulta más agradable la experiencia al usuario cuando existe alguna interfaz sencilla y comprensible en vez de usar la terminal de Eclipse. • Base de datos en la nube: Una posible mejora sería tener nuestra base de datos donde guardamos los datos que recibimos del sensor en la nube, como por ejemplo en AWS. 49 Aplicación para la integración de un sensor de frecuencia cardíaca en un entorno sanitario estandarizado REFERENCIAS [1] Historia clínica electrónica [Internet]. Wikipedia. [consultado el 25 de marzo de 2024]. Disponible en: https://es.wikipedia.org/wiki/Historia_cl%C3%ADnica_electr%C3%B3nica [2] Estándar FHIR [Internet]. Wikipedia. [consultado el 27 de marzo de 2024]. Disponible en: https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources [3] HL7 [Internet]. Wikipedia. [consultado el 30 de marzo de 2024]. Disponible en: https://es.wikipedia.org/wiki/HL7 [4] Sistemas EHR [Internet]. ekon.es. [consultado el 31 de marzo de 2024]. Disponible en: https://www.ekon.es/blog/sistema-ehr-hospitales/ [5] Web HL7 [Internet]. HL7.org. [consultado el 10 de abril de 2024]. Disponible en: https://www.hl7.org/index.cfm [6] Web FHIR [Internet]. HL7.org. [consultado el 18 de abril de 2024]. Disponible en: https://hl7.org/fhir/ [7] Recurso Observation [Internet]. HL7.org. [consultado el 20 de abril de 2024]. Disponible en: https://hl7.org/fhir/observation.html [8] Recurso Patient [Internet]. HL7.org. [consultado el 20 de abril de 2024]. Disponible en: https://hl7.org/fhir/patient.html [9] Recurso Device [Internet]. HL7.org. [consultado el 20 de abril de 2024]. Disponible en: https://hl7.org/fhir/device.html [10] Eclipse [Internet]. Eclipse.org. [consultado el 3 de marzo de 2024]. Disponible en: https://www.eclipse.org/ [11] Maven [Internet]. Maven.apache.org. [consultado el 17 de marzo de 2024]. Disponible en: https://maven.apache.org/ [12] MySQL Workbench [Internet]. MySQL.com. [consultado el 15 de marzo de 2024]. Disponible en: https://www.mysql.com/products/workbench/ [13] HAPI FHIR Test Server [Internet]. hapi.fhir.org. [consultado el 20 de mayo de 2024]. Disponible en: https://hapi.fhir.org/ [14] LOINC [Internet]. loinc.org. [consultado el 31 de agosto de 2024]. Disponible en: https://loinc.org/ Referencias 50 11