Procesador de eventos en entorno IoT de FIWARE para la supervisión
remota de la actividad físicaTrabajo Fin de Grado
Telecomunicación
Autor: Pablo Romero Escot
Tutor: Jorge Calvillo Arbizu
Universidad de Sevilla
Autor:
Universidad de Sevilla
v
Trabajo Fin de Grado: Procesador de eventos en entorno IoT de
FIWARE para la supervisión remota de la
actividad física
Autor: Pablo Romero Escot
Tutor: Jorge Calvillo Arbizu
El tribunal nombrado para juzgar el Proyecto arriba indicado,
compuesto por los siguientes miembros:
Presidente:
Vocales:
Secretario:
Sevilla, 2020
ix
Agradecimientos
Antes de comenzar con mi Trabajo de Fin de Grado, quiero agradecer
a todas las personas que han estado
junto a mí estos cuatro años, las cuales han sido un gran apoyo
siempre y han contribuido a que esta etapa de
mi vida sea inolvidable.
En primer lugar, quiero dar las gracias a mi familia, a mi padre, a
mi madre, a mis hermanos. Las personas que
más han influido en que sea como soy hoy en día. No tengo palabras
para expresar como me siento al pensar
en cómo me habéis apoyado, animado y ayudado siempre. Estos años,
más alejado de casa, me han hecho
madurar y darme cuenta de todo el esfuerzo que hacéis para que mi
única preocupación sea formarme. Gracias
por siempre creer y confiar en mí.
En segundo lugar, quiero agradecer a todos los amigos que me ha
dado esta carrera, a Jesús, Fernando, Ana,
Daniel, Sergio, José… y muchos otros que dejo sin nombrar, pero
están en mi cabeza al recordar estos años.
Personas fantásticas, con las que he compartido estos increíbles
años, apoyándonos, ayudándonos y
animándonos siempre. Personas con las que primero compartía clases,
con las que charlaba entre una clase y
otra, luego compartíamos un rato tomando café o comiendo juntos,
con las que haces planes una vez acaban
las clases, con las que he compartido tantísimas risas y buenos
momentos… Personas que echaré de menos en
mi día a día… Recordar todas las cosas que hemos pasado juntos me
provoca un poco de añoranza, pero sé
que siempre encontraremos un hueco para reunirnos todos y
pasárnoslo genial, como siempre hemos hecho.
Por otro lado, quiero agradecer a Irene el inmeso apoyo que me ha
dado siempre, animándome y motivándome
cuando más lo necesitaba, empujándome a dar siempre lo mejor de mí,
aunque yo mismo pensara que no
podía más. Capaz de sacarme una sonrisa hasta en los peores
momentos. Te has convertido en un modelo a
seguir para mí y me has convertido en una mejor persona.
Por último, me gustaría agradecer a todos los profesores que me han
aportado algo durante este proceso, de
cada uno de ellos he aprendido algo, y han contribuido a formarme
un poco más, tanto personal como
profesionalmente. En especial, a mi tutor Jorge Calvillo, por
ayudarme a cerrar esta etapa de la mejor manera
posible, cuyos consejos y ayuda han sido fundamentales para la
realización de este trabajo.
Gracias por estos años tan especiales, a todos, gracias.
Pablo Romero Escot
xi
Resumen
La realización de actividad física moderada con cierta regularidad
es uno de los tratamientos clave de diversas
enfermedades, tales como la enfermedad pulmonar obstructiva
crónica, así como ayuda a prevenir muchas
otras patologías, como por ejemplo cardiovasculares. Pero,
normalmente, su realización se lleva a cabo en un
entorno sin supervisión, lo que dificulta el seguimiento de la
evolución del paciente.
Ante esta situación, sería conveniente disponer de un sistema de
monitorización que obtenga información del
paciente durante el ejercicio físico, la procese de manera
automática y permita que ésta sea accesible para el
personal sanitario. También, debido al alto volumen de información
a manejar, sería adecuado un sistema
automático de generación de alertas, el cual permita potenciar la
adherencia a los tratamientos a través de
mensajes de refuerzo y la detección más temprana de eventos de
riesgo. Además, ya que el almacenamiento
persistente de toda la información que se genera mediante la
monitorización de pacientes es inviable desde un
punto de vista tecnológico y de recursos, sería apropiado que
cuando ocurren eventos de interés, además de
actuar al instante alertando de esto, cierta información quedase
registrada en un servicio de historia clínica.
En los últimos años, el sector sanitario se está beneficiando de la
incorporación de las nuevas capacidades que
ofrecen las tecnologías de IoT, ya que, entre otras
funcionalidades, permiten obtener más información sobre el
estado del paciente y de la evolución de este, mediante el uso de
sensores inteligentes que recopilan datos en
tiempo real de una forma no invasiva; permitiendo, además,
monitorizar a los pacientes fuera del ámbito
hospitalario.
El Grupo de Ingeniería Biomédica de la Universidad de Sevilla ha
desarrollado una camiseta inteligente que
recoge datos de la actividad física del paciente, y un Agente IoT
desarrollado en una aplicación móvil, el cual
lleva a cabo la transmisión de información de monitorización del
paciente a la plataforma de IoT FIWARE.
Este Agente IoT recibe información de la camiseta inteligente, la
procesa para que siga el formato adecuado a
dicha plataforma, y la envía.
Para mejorar la situación actual, donde no se facilita que la
información que se capta esté disponible para el
personal sanitario, ni se ejerce ningún análisis sobre ella; en
este proyecto se desarrolla un sistema de gestión
de alarmas que, a partir de la información enviada por el Agente
IoT a la plataforma FIWARE, detecta eventos
de riesgo y actúa en consecuencia, haciendo uso de la herramienta
Perseo de FIWARE. Además, se ha
realizado una interfaz visual que permite el seguimiento remoto por
parte de los profesionales sanitarios,
haciendo uso de la herramienta Freeboard. Para el almacenamiento de
eventos de interés en la historia clínica
del paciente, se ha desplegado un servidor FHIR, conectado con
Perseo, el cual permite mantener un registro
de observaciones periódicas, con muestras del trabajo que está
realizando el paciente en su domicilio, que
puedan ser de interés para revisiones futuras por parte de los
profesionales sanitarios.
xiii
Abstract
Performing moderate physical activity regularly is a key treatment
for various diseases, such as chronic
obstructive pulmonary disease, and it also helps to prevent many
other pathologies, such as cardiovascular
diseases. But, usually, it is carried out in unsupervised
environments, which makes it difficult to monitor the
performance and evolution of the patient.
In this situation, it would be convenient to have a monitoring
system that obtains information from the patient
during physical exercise, processes it automatically and makes it
accessible to healthcare personnel. Also, due
to the high volume of information that may be handled, an automatic
alert generation system would be
appropriate, which would allow adherence to treatments to be
enhanced through reinforcing messages and the
earlier detection of risk events. In addition, since persistent
storage of all the information generated by
monitoring patients is unfeasible from a technological and resource
point of view, it would be appropriate to
register certain information in a electronic health record when
events of interest occur, in addition to trigger
actions or alerts.
In recent years, the healthcare sector has benefited from the
incorporation of the new capabilities offered by
IoT technologies, since, among other features, they allow obtaining
more information about the patient's
condition and evolution, through the use of smart sensors that
collect real-time data in a non-invasive way;
allowing, in addition, to monitor patients outside the hospital
setting.
The Biomedical Engineering Group of the University of Seville has
developed a smart shirt which collects
data about the patient's physical activity, and an IoT Agent
developed in a mobile application, which carries
out the transmission of patient monitoring information to the IoT
FIWARE platform. This IoT Agent receives
information from the smart shirt, processes it to comply with the
platform format, and sends it.
To improve the current situation, where the captured information is
not available to health personnel, nor is
any analysis carried out on it; in this project, an alarm
management system is developed that, based on the
information sent by the IoT Agent to the FIWARE platform, detects
risk events and acts accordingly, using the
FIWARE Perseo tool. In addition, a visual interface has been made
that allows remote monitoring by
healthcare professionals, using the Freeboard tool. For the storage
of events of interest in the patient's medical
record, an FHIR server has been deployed, connected to Perseo,
which allows keeping a record of periodic
observations, with samples of the work that the patient is doing at
home, which can be of interest for future
reviews by healthcare professionals.
Índice de Tablas xvii
Índice de Figuras xix
1 Introducción 1 1.1 Motivación 1 1.2 Objetivos 2 1.3 Antecedentes
3 1.4 Descripción de la solución 3 1.5 Organización del proyecto y
plan de trabajo 5
2 Estado del arte 9 2.1 Internet of Things 9 2.2 FIWARE 10
2.2.1 NGSIv2 11 2.2.2 Orion Context Broker 13 2.2.3 Perseo 15
2.3 MongoDB 20 2.4 Historia clínica 20 2.5 FHIR 21
2.5.1 Recursos 21 2.5.2 HAPI FHIR 28
2.6 Freeboard 29 2.6.1 Configuración Datasources 30
2.7 Recursos software 30 2.7.1 VMware Workstation 14 player y
máquina virtual “Ubuntu/Debian” 30 2.7.2 Docker 31 2.7.3 Postman 32
2.7.4 Otras herramientas 33
3 Resultados 35 3.1 Diseño de la plataforma 35 3.2 FHIR 36
3.2.1 Despliegue del servidor FHIR 36 3.2.2 Creación de recurso
Patient 37
3.3 FIWARE 39 3.3.1 Despliegue de MongoDB 40 3.3.2 Despliegue de
OCB 40
3.3.3 Entidades FIWARE 40 3.3.4 Procesador de eventos 45
3.4 Visualización 48 3.4.1 Despliegue y configuración de Freeboard
48 3.4.2 Configuración de las fuentes de datos 49 3.4.3
Configuración de los widgets 52 3.4.4 Dashboard 55
3.5 Escenarios 57
4 Conclusiones y líneas futuras 79 4.1 Conclusiones 79 4.2 Líneas
futuras 80
Anexo A: Instalación y despliegue de los componentes fiware 83 A.1
Instalación de Docker 83 A.2 Instalación de MongoDB 85 A.3
Instalación de Orion Context Broker 86 A.4 Instalación de Perseo
87
Anexo B: Instalación y despliegue de Freeboard 91 B.1 Instalación
de Freeboard 91
Anexo C: Instalación y despliegue del servidor FHIR 95 C.1
Instalación de Apache Tomcat 95 C.2 Instalación del servidor FHIR
97
Referencias 99
Glosario 101
Tabla 1-2. Análisis y diseño del procesador de eventos 5
Tabla 1-3. Implementación del procesador de eventos 6
Tabla 1-4. Implementación de la interfaz visual 6
Tabla 1-5. Implementación del sistema de historia clínica 7
Tabla 1-6. Pruebas y validación 7
Tabla 1-7. Documentación 7
Tabla 2-7. Definición Patient.deceased[x] 24
Tabla 2-8. Definición Patient.address 25
Tabla 2-9. Definición Patient.managingOrganization 25
Tabla 2-10. Definición Observation.identifier 26
Tabla 2-11. Definición Observation.basedOn 26
Tabla 2-12. Definición Observation.parOf 26
Tabla 2-13. Definición Observation.status 26
Tabla 2-14. Definición Observation.category 27
Tabla 2-15. Definición Observation.code 27
Tabla 2-16. Definición Observation.subject 27
Tabla 2-17. Definición Observation.effective[x] 27
Tabla 2-18. Definición Observation.value[x] 28
Tabla 2-19. Definición Observation.note 28
Tabla 2-20. Definición Observation.device 28
xix
Figura 1-1. Arquitectura del sistema 4
Figura 2-1. Evolución del número de dispositivos IoT conectados en
todo el mundo. Fuente: [9] 10
Figura 2-2. Logo de FIWARE 10
Figura 2-3. Esquema básico del procedimiento de una Smart Solution
11
Figura 2-4. Estructura de una entidad de contexto. Fuente: [12]
12
Figura 2-5. Representación JSON de una entidad NGSI 12
Figura 2-6. Representación JSON de una entidad NGSI en modo
“keyValues” 13
Figura 2-7. Estructura-comunicación del Orion Context Broker.
Fuente: [13] 13
Figura 2-8. Estructura de una notificación por defecto 15
Figura 2-9. Estructura de funcionamiento de Perseo. Fuente: [14]
16
Figura 2-10. Estructura de una regla en Perseo. Fuente: [14]
17
Figura 2-11. Logo de MongoDB 20
Figura 2-12. Logo de FHIR 21
Figura 2-13. Estructura de un recurso FHIR 22
Figura 2-14. Logo de HAPI FHIR 29
Figura 2-15. Logo de Freeboard 29
Figura 2-16. Logo de VMware Workstation 30
Figura 2-17. Logo de Ubuntu 18.04 LTS 30
Figura 2-18. Logo de Docker 31
Figura 2-19. Comparativa estructura contenedores Docker frente a
máquina virtual. Fuente: [32] 31
Figura 2-20. Logo de Postman 32
Figura 2-21. Interfaz gráfica de Postman 33
Figura 3-1. Esquema de la plataforma 36
Figura 3-2. Página principal del servidor FHIR 37
Figura 3-3. Solicitud de creación de un recurso Patient 38
Figura 3-4. Recurso Patient obtenido del servidor FHIR 39
Figura 3-5. Cabecera HTTP de las peticiones a componentes FIWARE
41
Figura 3-6. Modelo de entidad tipo “PhysicalActivity” 41
Figura 3-7. Ejemplo de entidad de tipo “Alert” 43
Figura 3-8. Ejemplo de entidad de tipo “PhysicalActivity” 44
Figura 3-9. Actualización de una entidad de tipo “PhysicalActivity”
45
Figura 3-10. Suscripción de Perseo-FE a OCB 47
Figura 3-11. Modificación para recibir notificaciones
correspondientes a entidades concretas 47
Figura 3-12. Configuración fuente de datos correspondiente a la
entidad “PhysicalActivity” 50
Figura 3-13. Configuración fuente de datos correspondiente a un
tipo de alertas 51
Figura 3-14. Panel de control de Freeboard 52
Figura 3-15. Widget tipo “Text” correspondiente al nombre completo
del paciente 52
Figura 3-16. Widget tipo “Gauge” correspondiente a la frecuencia
cardíaca 53
Figura 3-17. Widget tipo “Time series” correspondiente a la
frecuencia cardíaca 54
Figura 3-18. Widget tipo “HTML” correspondiente a la descripción de
una clase de alarma 54
Figura 3-19. Representación mediante combinación de HTML y una
fuente de datos 55
Figura 3-20. Dashboard 56
Figura 3-21. Regla para detectar una situación de riesgo leve a
través de la frecuencia cardíaca 57
Figura 3-22. Actualización correspondiente a una situación de
riesgo leve 58
Figura 3-23. Email enviado a un paciente que se encuentra en una
situación de riesgo leve 58
Figura 3-24. Entidad actualizada debido a la activación de la regla
“FrecCardiacaRiesgoLeve” 58
Figura 3-25. Regla 1 para detectar una situación de riesgo grave a
través de la frecuencia cardíaca 60
Figura 3-26. Actualizaciones correspondientes a una situación de
riesgo grave 61
Figura 3-27. Email enviado al paciente – Regla
“FrecCardiacaRiesgoGraveConsecutivo” 61
Figura 3-28. Email enviado al médico responsable – Regla
“FrecCardiacaRiesgoGraveConsecutivo” 61
Figura 3-29. Recurso creado por la activación de la regla
“FrecCardiacaRiesgoGraveConsecutivo” 62
Figura 3-30. Consulta realizada en el servidor FHIR 63
Figura 3-31. Resultado de la consulta en el servidor FHIR 63
Figura 3-32. Entidad actualizada por la activación de la regla
“FrecCardiacaRiesgoGraveConsecutivo” 63
Figura 3-33. Regla 2 para detectar una situación de riesgo grave a
través de la frecuencia cardíaca 64
Figura 3-34. Serie de actualizaciones correspondientes a una
situación de riesgo grave 66
Figura 3-35. Email enviado al paciente – Regla
“FrecCardiacaRiesgoGraveVentana” 67
Figura 3-36. Email enviado al médico responsable – Regla
“FrecCardiacaRiesgoGraveVentana” 67
Figura 3-37. Recurso creado por la activación de la regla
“FrecCardiacaRiesgoGraveVentana” 67
Figura 3-38. Entidad actualizada por la activación de la regla
“FrecCardiacaRiesgoGraveVentana” 68
Figura 3-39. Regla para detectar una tendencia a un posible riesgo
68
Figura 3-40. Serie de actualizaciones que indican una tendencia a
un posible riesgo 69
Figura 3-41. Email enviado a un paciente para alertar sobre una
tendencia a un posible riesgo 70
Figura 3-42. Entidad actualizada debido a la activación de la regla
“FrecCardiacaRiesgoTendencia” 70
Figura 3-43. Regla para detectar un posible riesgo mediante el
gasto calórico instantáneo 71
Figura 3-44. Actualizaciones que indican una situación de riesgo
ligada al gasto calórico instantáneo 72
Figura 3-45. Email enviado al paciente para alertar sobre el
incremento de gasto calórico instantáneo 72
Figura 3-46. Recurso creado por la activación de la regla
“GastoCaloricoInstantaneo” 73
Figura 3-47. Entidad actualizada debido a la activación de la regla
“GastoCaloricoInstantaneo” 73
Figura 3-48. Regla para la monitorización diaria del gasto calórico
acumulado 74
xxi
Figura 3-49 Actualizaciones que darían lugar a la activación de la
regla “GastoCaloricoAcumulado” 75
Figura 3-50. Email enviado al paciente para notificarle que no ha
cumplido su objetivo diario de kcal 75
Figura 3-51. Recurso Observation creado por la activación de la
regla “GastoCaloricoAcumulado” 75
Figura 3-52. Entidad actualizada debido a la activación de la regla
“GastoCaloricoAcumulado” 76
Figura 3-53. Regla para detectar comportamiento anómalo en un
dispositivo 76
Figura 3-54. Actualizaciones con valores anómalos 77
Figura 3-55. Email enviado al paciente para informar sobre errores
en el dispositivo 77
Figura 3-56. Email enviado al servicio técnico para informar sobre
fallos en un dispositivo 78
Figura A-1. Comprobación de la correcta instalación de Docker
84
Figura A-2. Arranque del cliente mongo de MongoDB 85
Figura A-3. Logs generados por MongoDB 86
Figura A-4. Comprobación del correcto arranque de OCB 87
Figura A-5. Configuración necesaria para el email correspondiente a
Perseo 89
Figura A-6. Comprobación del correcto arranque de Perseo Core
89
Figura A-7. Comprobación del correcto arranque de Perseo-FE
89
Figura B-1. Pantalla de inicio de Freeboard 92
Figura B-2. Agregación de un plugin a Freeboard 93
Figura B-3. Visualización del nuevo plugin en Freeboard 94
Figura C-1. Página de inicio de Tomcat 97
Figura C-2. Pantalla de inicio del servidor FHIR 98
1 INTRODUCCIÓN
n este primer capítulo se podrá conocer la motivación que promovió
la realización de este trabajo, así
como los objetivos que se pretenden alcanzar con éste. También, se
comentará la solución que se ha
llevado a cabo, así como la planificación que ha tenido lugar,
junto con una comparación entre la
estimación temporal realizada para cada actividad y el tiempo real
que ha conllevado finalmente.
1.1 Motivación
La práctica regular de actividad física juega un papel fundamental
para el mantenimiento y mejora de la salud,
aportando beneficios fisiológicos, psicológicos y sociales. Además,
reduce el riesgo de padecer enfermedades
como hipertensión arterial, diabetes mellitus y diversos tipos de
cáncer [1]. No solo eso, también se aplica
como tratamiento en la lucha contra diversas enfermedades como por
ejemplo el deterioro cognitivo. Por el
contrario, la inactividad física es el cuarto factor de riesgo de
mortalidad en todo el mundo, estando
relacionada con el desarrollo de enfermedades como la obesidad,
problemas cardiovasculares y sus factores de
riesgo [2].
Una de las características de la actividad física como tratamiento,
es que su realización se suele llevar a cabo
principalmente fuera del entorno médico y depende del propio
paciente. Esto puede conllevar una peor
adherencia a los tratamientos, así como complicar el seguimiento
por parte de los profesionales sanitarios.
Ante esta situación, sería conveniente disponer de un sistema de
monitorización el cual capte información de
la actividad que está realizando el paciente, la procese de forma
automática y permita que esté a disposición
del personal sanitario para su consulta de una forma sencilla. Esto
permitiría monitorizar a los pacientes en
tiempo real y seguir la evolución que están teniendo a lo largo del
tratamiento.
El Grupo de Ingeniería Biomédica de la Universidad de Sevilla ha
desarrollado una camiseta inteligente para
la monitorización de la actividad física de los pacientes y un
Agente IoT, implementado en el teléfono móvil,
que hace de intermediario entre el dispositivo sensor y la
plataforma IoT FIWARE. FIWARE es una
plataforma de código abierto que permite manejar y analizar en
tiempo real, cantidades masivas de
información de cualquier tipo, automatizando procesos y haciéndolo
de manera escalable. Permite que dicha
información se encuentre disponible en cualquier momento y que el
acceso a ella sea controlado. También
dispone de una amplia biblioteca de componentes, llamados Generic
Enablers (GE), que proporcionan
capacidades muy diversas y además son compatibles entre ellos. La
solución desarrollada, si bien recoge la
E
preocuparse. Si no tiene solución, preocuparse no sirve
de nada.
- Proverbio chino -
Introducción
2
información de actividad del paciente y la envía a la plataforma,
no facilita aún que dicha información esté
disponible para el personal sanitario o sea procesada de manera
automática.
Por ello, partiendo de la situación actual donde nos encontramos,
en la que la información del paciente es
recogida y enviada a FIWARE, con este proyecto se busca
desarrollar, ante la gran cantidad de información a
manejar por parte de los profesionales sanitarios, un sistema de
monitorización que alerte de forma automática
en caso de que tengan lugar una serie de eventos. Este sistema,
además, permitirá registrar observaciones
periódicas, de la actividad que está realizando el paciente en su
domicilio, en un servicio de historia clínica, de
forma que puedan ser de interés para revisiones futuras por parte
de profesionales. Esto evitaría la acumulación
de grandes cantidades de información, que se pueden producir
durante la monitorización, permitiendo tener un
almacenamiento persistente sólo con la información realmente
importante.
Por otra parte, otra motivación del proyecto es facilitar el
seguimiento del tratamiento en el paciente, por parte
del personal sanitario, mediante una interfaz visual, haciendo
accesible dicha información, de forma sencilla,
en cualquier momento y lugar.
Por último, una motivación extra de este trabajo ha sido poder
averiguar y aprender más sobre unas
tecnologías que están teniendo un impacto muy importante en la
actualidad y van a tener un impacto incluso
mayor en un futuro cercano.
1.2 Objetivos
El primer objetivo de este proyecto es la creación de un sistema
que permita procesar una gran cantidad de
datos de monitorización de actividad, comparándolos con una serie
de reglas, para así conseguir una detección
temprana de eventos de interés. Se incluye la opción de que
cualquier usuario autorizado puede acceder a la
información, y acceder/modificar los patrones de detección de una
forma segura y simple.
Este objetivo puede ser desglosado en:
Análisis de la plataforma FIWARE y sus diferentes componentes: Ya
que va a ser la plataforma sobre
la que se van a manejar los datos, es importante conocer bien cómo
funciona, como interactúan sus
componentes y qué servicios pone a nuestra disposición.
Análisis de la solución de partida, tanto de la camiseta
inteligente como del agente IoT.
Modelado de datos: Mapeo de los datos a manejar en entidades, cuyos
campos deben ser conocidos
por los diferentes componentes del sistema para poder acceder a su
contenido.
Diseño de comportamientos de interés: Definición de patrones que
van a constituir un evento de
interés, el cual va a conllevar una acción.
Diseño de las acciones a realizar como consecuencia de la sucesión
de eventos.
Desarrollo de la solución completa: despliegue de los diversos
componentes e interconexión de ellos.
Evaluación de la solución con diferentes escenarios.
Como segundo objetivo, se llevará a cabo el desarrollo de una
interfaz visual (que denominaremos dashboard)
que permita el seguimiento remoto y supervisado de la información
de monitorización por parte del personal
autorizado. Este podrá observar todos los parámetros de interés del
paciente y ver cómo varían a lo largo del
tiempo.
Estudio y comparación de las diferentes tecnologías disponibles
para el desarrollo del dashboard.
Desarrollo del dashboard y los componentes que lo forman.
Integración con la plataforma FIWARE para poder recolectar los
datos.
El dashboard permitirá al usuario visualizar los datos que va
recibiendo el sistema desde el dispositivo de
actividad física, realizar análisis de forma más sencilla y poder
tomar decisiones en base a estos.
Como tercer objetivo, se realizará un análisis del estándar FHIR
(Fast Healthcare Interoperability Resources),
con el fin de registrar en un sistema de historia clínica, los
eventos de interés que han sido captados por el
procesador de eventos remotos.
Este objetivo se puede dividir en:
Análisis de los recursos que pone a nuestra disposición FHIR y de
sus características.
Mapeo de los datos que se manejan en FIWARE en dichos
recursos.
Despliegue del servidor FHIR e interconexión con la plataforma
FIWARE.
1.3 Antecedentes
El punto de partida de este proyecto es el Trabajo Fin de Grado:
“Agente IoT de FIWARE para el control de
un dispositivo de monitorización de actividad física” de Rafael
Díaz Fernández [3], realizado en 2019. En este
proyecto se desarrolla un Agente IoT en una aplicación móvil, el
cual recibe datos de seguimiento del estado
de un paciente, de una camiseta inteligente, y los envía a Orion
Context Broker. La camiseta inteligente realiza
una monitorización de la actividad física, obtiene una estimación
del gasto metabólico y la frecuencia cardíaca.
Además, se desarrollaba un servicio web mediante Angular, para
poder observar la información almacenada
en FIWARE.
En este proyecto, se han realizado una serie de mejoras con
respecto al sistema anteriormente comentado, y se
han añadido nuevas funcionalidades, mediante el uso de un
procesador de eventos complejos, el cual permite
analizar, de manera automática, la gran cantidad de datos que se
manejan, y actuar rápidamente en caso de que
se den eventos de interés, marcados por una serie de reglas.
Ciertos eventos quedarán registrados en un sistema
FHIR, para poder llevar a cabo un control de la evolución del
paciente. Además, se ha sustituido el servicio
web por una interfaz visual desarrollada en Freeboard, la cual
permite una monitorización más clara de los
datos, así como una representación que facilita la obtención de
conclusiones de una forma más sencilla.
1.4 Descripción de la solución
La arquitectura de la solución escogida es la siguiente:
Introducción
4
Como podemos ver en la Figura 1-1, nuestro sistema está formado,
principalmente, por cuatro partes:
1. La información es recogida y almacenada mediante la plataforma
FIWARE, en particular, por uno de
sus principales componentes llamado Orion Context Broker (OCB), el
cual es un servidor que
implementa una API de tipo REST, permitiendo la consulta y
suscripción a los datos que maneja [4].
Este recibe la información del Agente IoT, el cual hace uso del
protocolo de comunicación HTTP,
utilizando peticiones PATCH para la actualización de los datos.
Previamente, las entidades que
reciben las actualizaciones han sido creadas mediante peticiones
POST.
2. Mediante el uso de un componente de FIWARE, llamado Perseo, se
lleva a cabo el procesamiento de
los datos, con la función de detectar eventos de interés y actuar
en base a estos. Este componente
estará suscrito a la información de interés que maneja Orion y
recibirá de este todos los cambios que
se realicen sobre dicha información mediante peticiones POST [5].
En caso de que se active alguna
regla, es decir, que se detecte un evento de interés, se llevará a
cabo una serie de acciones, como
pueden ser el envío de un correo electrónico al paciente y a su
profesional sanitario responsable o el
envío de la información correspondiente, en forma de recurso
Observation, mediante un POST al
servidor FHIR.
3. Con el fin de llevar a cabo un sistema de historia clínica, se
ha desplegado un servidor FHIR [6], el
cual recibirá peticiones de Perseo con la información a almacenar.
Este sistema permitirá poder
observar de un vistazo, el registro de eventos que le han sucedido
a un determinado paciente con
respecto a una patología, entre otras funcionalidades.
4. Para la visualización de los datos, se ha optado por Freeboard,
una aplicación que permite crear
fuentes de datos para así obtener la información almacenada en OCB
utilizando peticiones GET, y
diseñar dashboards a medida, mediante la unión de distintos widgets
[7]. Esto permitirá llevar a cabo
una monitorización en tiempo real de los parámetros a seguir,
mediante la representación más
adeacuada a cada uno de ellos.
Figura 1-1. Arquitectura del sistema
PUBLICADORES
1.5 Organización del proyecto y plan de trabajo
En esta sección se expondrán las diferentes actividades que se han
ido llevando a cabo para la realización de
este trabajo, incluyendo tareas tanto de diseño, investigación,
estudio de las diferentes posibilidades
disponibles, formación, puesta en funcionamiento de los diversos
componentes, interconexión entre ellos y
diferentes pruebas. Las actividades que se han llevado a cabo son
las siguientes:
Actividad 1: Análisis y búsqueda de información. En primer lugar,
se realizó un análisis de las
funcionalidades que se deseaban que implementara el proyecto. A
partir de esto, se llevó a cabo una
investigación entre la documentación que ofrece FIWARE,
enfocándonos en los componentes que
pone a nuestra disposición, su modo de funcionar y las capacidades
que ofrecen. Se llevó a cabo un
análisis más profundo de los Generic Enablers que componen la
sección de “Procesamiento, análisis
y visualización de información de contexto”.
Tabla 1-1. Análisis y búsqueda de información
Análisis y búsqueda de información Tiempo estimado Tiempo
real
Análisis de funcionalidades 3 horas 3 horas
Investigación documentación FIWARE 30 horas 35 horas
Total 33 horas 38 horas
Actividad 2: Análisis y diseño del procesador de eventos. Se llevó
a cabo un estudio de los requisitos
que se quería que cumpliera el proyecto y un estudio de posibles
soluciones. Se realizó el diseño de
las entidades que se van a manejar, así como de sus atributos. Se
definió qué modelo de suscripción
iba a tener lugar. Posteriormente, entre todas las opciones
disponibles de Generic Enablers, se
seleccionaron las más convenientes. Una vez realizado esto, se
llevó a cabo el diseño de las reglas que
iban a marcar la invocación de una alerta, y en qué iban a
consistir dichas alertas.
Tabla 1-2. Análisis y diseño del procesador de eventos
Análisis y diseño del procesador de eventos Tiempo estimado Tiempo
real
Estudio de posibles soluciones 5 horas 5 horas
Diseño de entidades y sus atributos 4 horas 5 horas
Análisis y definición de las suscripciones 3 horas 3 horas
Estudio/elección Generic Enablers 10 horas 10 horas
Diseño de reglas y alertas 35 horas 40 horas
Total 57 horas 63 horas
Introducción
6
Actividad 3: Implementación del procesador de eventos. Primero se
estudiaron los diferentes métodos
de instalación disponibles para los distintos componentes de la
plataforma FIWARE y se decidió por
utilizar el sistema operativo Linux, llevando a cabo la instalación
de una máquina virtual
“Ubuntu/Debian”. A continuación, se decidió llevar a cabo la
instalación de los diversos componentes
mediante el uso de la tecnología Docker, es decir, mediante el uso
de contenedores, lo que conllevó su
instalación en primer lugar. Posteriormente, se continuó con la
instalación de MongoDB, una base de
datos necesaria para que el resto de los componentes de la
plataforma FIWARE puedan funcionar. A
continuación, se llevó a cabo la instalación de Orion Context
Broker y su conexión con MongoDB.
Por último, se realizó la instalación de las dos partes que
componen Perseo, Perseo FE y Perseo Core,
así como la conexión entre ellos, y la conexión de Perseo FE con
OCB, con MongoDB y con el
servidor SMTP de Gmail.
Implementación del procesador de eventos Tiempo estimado Tiempo
real
Estudio de los métodos de instalación disponibles 2 horas 2
horas
Instalación máquina virtual y Docker 2 horas 2 horas
Instalación MongoDB y Orion Context Broker 8 horas 10 horas
Instalación Perseo Core 12 horas 14 horas
Instalación Perseo FE 16 horas 22 horas
Conexión entre los distintos componentes 22 horas 28 horas
Total 62 horas 78 horas
Actividad 4: Implemetación de la interfaz visual. En primer lugar,
se realizó una investigación sobre
las opciones disponibles para realizar un dashboard de acuerdo con
las necesidades del proyecto,
realizando una comparativa entre los más destacados, seleccionando
finalmente Freeboard. Se llevó a
cabo su instalación y su conexión con Orion Context Broker,
componente del cual obtendrá la
información. A continuación, se llevó a cabo la configuración del
dashboard y de las fuentes de datos,
incluyendo para ello diversos plugins a Freeboard, que en principio
no incluía.
Tabla 1-4. Implementación de la interfaz visual
Implementación de la interfaz visual Tiempo estimado Tiempo
real
Investigación y comparación de las distintas posibilidades 8 horas
8 horas
Instalación Freeboard y plugins 7 horas 8 horas
Conexión Freeboard con Orion Context Broker 5 horas 7 horas
Diseño y configuración dashboard y fuentes de datos 12 horas 12
horas
Total 32 horas 35 horas
Actividad 5: Implementación del sistema de historia clínica. Para
esto, primero se comenzó
analizando los diferentes recursos que proporciona el estándar FHIR
para modelar la información.
Una vez seleccionados y analizados en profundidad los recursos a
emplear y los atributos que los
componen, se continuó desplegando un servidor FHIR y realizando su
conexión con la plataforma
FIWARE. En particular, se analizó su conexión con Perseo, ya que es
el componente el cual le va a
proporcionar la información que dicho sistema debe almacenar de
forma persistente.
Tabla 1-5. Implementación del sistema de historia clínica
Implementación del sistema de historia clínica Tiempo estimado
Tiempo real
Investigación y análisis de los recursos FHIR 10 horas 10
horas
Instalación y despliegue del servidor FHIR 8 horas 12 horas
Conexión con Perseo 8 horas 10 horas
Total 26 horas 32 horas
Actividad 6: Pruebas y validación. Se llevaron a cabo una serie de
pruebas para verificar que los
componentes, de forman individual, presentaban un funcionamiento
adecuado. Posteriormente, una
vez realizadas estas pruebas y corregidos diversos errores, se
realizaron una serie de pruebas de
integración, para comprobar que los distintos componentes que
interactúan entre sí funcionaban
correctamente. Por último, se llevó a cabo una corrección de los
errores que habían surgido, para
obtener un correcto funcionamiento del sistema.
Tabla 1-6. Pruebas y validación
Pruebas y validación Tiempo estimado Tiempo real
Pruebas de componentes 4 horas 4 horas
Pruebas de integración 5 horas 5 horas
Corrección de errores 15 horas 22 horas
Total 24 horas 31 horas
Actividad 7: Documentación. Consta de la redacción de la memoria
del proyecto.
Tabla 1-7. Documentación
Redacción de la memoria del proyecto 100 horas 135 horas
Total 100 horas 135 horas
Introducción
8
2 ESTADO DEL ARTE
n este capítulo se describen las diferentes tecnologías y
herramientas empleadas para la realización de
este proyecto. Se expondrá una descripción de las características
más importantes de cada una de ellas,
así como el contexto actual en el que se encuentran. Además, se
hará hincapié en los componentes
principales que han sido utilizados durante el proyecto.
2.1 Internet of Things
El Internet de las Cosas, en inglés Internet of Things (IoT), es un
concepto que gira en torno a la posibilidad de
extender la capacidad de cómputo y la conectividad de red, a
objetos, sensores y artículos de uso diario, que
normalmente no las tienen, permitiendo que estos dispositivos
generen, intercambien y consuman datos con
una mínima intervención humana [8].
El concepto de combinar sensores, computadores y redes para
monitorear y controlar diferentes sistemas ha
existido desde hace décadas. Sin embargo, el auge de diferentes
tendencias en el mercado tecnológico está
permitiendo que el IoT esté cada vez más extendido, siendo ya una
realidad y no sólo una visión de futuro.
Estas tendencias incluyen la conectividad omnipresente, el aumento
de la capacidad de cómputo, la
miniaturización de los sensores, los avances en el análisis de
datos y la computación en la nube.
E
Figura 2-2. Logo de FIWARE
Figura 2-1. Evolución del número de dispositivos IoT conectados en
todo el mundo. Fuente: [9]
Entre las grandes ventajas que aporta esta tecnología podemos
mencionar la automatización de procesos,
ahorrando tiempo y esfuerzo. Por otra parte, permite la recolección
de datos, en tiempo real, de forma que
dicha información esté al alcance de cualquier persona en cualquier
parte del mundo. Además, permite
aumentar la velocidad en el análisis de datos y facilitar su
seguimiento, lo que junto a la gran cantidad de datos
que nos ofrece, nos permite llevar a cabo mejores tomas de
decisiones.
Debido a sus grandes ventajas, el IoT se está extendiendo en todos
los ámbitos de la vida cotidiana, por
ejemplo, con el uso de smartwatches o en la domótica de casas
automatizadas. El ámbito empresarial es el
principal consumidor de esta tecnología, ya que sectores como el
transporte o la agricultura se ven
beneficiados por las características que IoT les ofrece a través
del despliegue de sensores en los procesos o
vehículos. En el sector sanitario su uso está aumentando
considerablemente, ya que se está utilizando para
conocer el estado de los pacientes de forma más precisa, incluso
cuando están fuera del hospital, facilitando su
seguimiento y permitiendo automatizar ciertos procesos.
En la actualidad exiten diferentes plataformas que implementan el
paradigma IoT, una de las más importantes
es FIWARE.
2.2 FIWARE
FIWARE es una plataforma de software abierto, surgida de la
colaboración público-privada entre la Comisión
Europea y la industria europea, iniciada en 2011, y que sigue en
continuo crecimiento. Su principal objetivo es
construir un ecosistema abierto y sostenible en torno a estándares
de plataformas de software públicas, e
impulsadas por la implementación de herramientas que faciliten el
desarrollo de nuevas aplicaciones
inteligentes, en múltiples sectores. FIWARE apuesta por el
desarrollo colaborativo de “Smart-solutions” y por
tecnologías como Internet de las Cosas (IoT), Cloud Computing y
Open Data [10].
Figura 2-3. Esquema básico del procedimiento de una Smart
Solution
FIWARE quiere impulsar un estándar que describa cómo recopilar,
gestionar y publicar información de
contexto, y adicionalmente aporta elementos que permiten explotar
esta información una vez recopilada.
También resuelve, de manera sencilla, cómo capturar información
procedente de redes de sensores, aunque se
comuniquen usando diferentes protocolos y lenguajes IoT. En ese
sentido es capaz de resolver la complejidad
de tratar la información recogida por los sensores y traducirlos a
un lenguaje común [11].
Esta plataforma se basa en el uso de componentes estándar de
dominio público llamados Generic Enablers. El
más importante es el Orion Context Broker, el cual brinda una
función fundamental en cualquier solución
inteligente: permite administrar la información de contexto,
realizar actualizaciones, y brinda acceso a dicha
información. El resto de Generic Enablers están desarrollados en
torno a este componente, englobados en las
siguientes categorías [11]:
Interfaz con Internet de las Cosas (IoT), robots y sistemas de
terceros, para capturar actualizaciones
sobre infomación de contexto y traducir las actuaciones
requeridas.
Gestión, publicación y monetización de datos de contexto/API,
brindando soporte para el control de
uso y la oportunidad de publicar y monetizar parte de los datos de
contexto administrados.
Procesamiento, análisis y visualización de información de contexto
implementando el
comportamiento inteligente esperado de las aplicaciones y/o
ayudando a los usuarios finales a tomar
decisiones inteligentes.
2.2.1 NGSIv2
NGSI (Next Generation Service Interface) es un protocolo
desarrollado por la OMA (Open Mobile Alliance),
que se basa en una API RESTful para comunicarse mediante peticiones
HTTP. Su principal aplicación es
administrar todo el ciclo de vida de la información de contexto,
incluidas las actualizaciones, consultas,
registros y suscripciones [12]. Se entiende por información de
contexto aquella información relevante sobre
algún parámetro en un instante dado, procedente de diferentes
fuentes de datos.
La comunicación entre los distintos componentes que forman parte de
la plataforma FIWARE se lleva a cabo
mediante NGSI. Actualmente, en FIWARE funcionan conjuntamente dos
versiones de esta API: NGSIv1 y
NGSIv2. La versión 2 incorpora más funcionalidades, además, está
sustituyendo progresivamente a la versión
1, siendo compatible en los componentes donde funciona esta primera
versión. Además, los nuevos
componentes se están desarrollando para la segunda versión. Por
estos motivos, se ha decidido realizar este
proyecto haciendo uso de NGSIv2. Este protocolo define:
Estado del arte
Figura 2-4. Estructura de una entidad de contexto. Fuente:
[12]
Figura 2-5. Representación JSON de una entidad NGSI
Un modelo de datos para la información de contexto, basado en el
concepto de “entidades de
contexto”.
Una interfaz de datos de contexto para intercambiar información,
por medio de operaciones de
consutas, suscripciones y actualizaciones.
Una interfaz de disponibilidad de contexto, para intercambiar
información sobre cómo obtener la
propia información de contexto.
2.2.1.1 Modelado de la información de contexto
Los principales elementos que componen el modelo de datos NGSI son
las entidades, los atributos y los
metadatos.
Primero tenemos las entidades. Una entidad puede representar
cualquier cosa, ya sea física o lógica, como por
ejemplo un sensor o una persona. Cada entidad tiene un campo type,
tipo, el cual está pensando para describir
el tipo de cosa representado por la entidad. Además, tiene un campo
id, que junto a type, permite identificar de
forma única una entidad.
Cada entidad esta formada por una serie de atributos. Cada uno de
ellos tiene un nombre, un tipo, un valor y un
conjunto opcional de metadatos asociados. El nombre describe que
propiedad representa dicho atributo. El tipo
del atributo representa el tipo de valor NGSI correspondiente al
valor del atributo. Por último, encontramos su
valor actual y, opcionalmente, metadatos que describen propiedades
del atributo, como puede ser su precisión
o quién es el proveedor de dicha información.
Los metadatos están formados por 3 campos: un nombre, que describe
el papel del metadato, un tipo, que
proporciona que tipo de valor NGSI se está usando, y el propio
valor actual de dicho metadato.
Una entidad se representa por un objeto JSON, mediante la siguente
sintaxis:
Figura 2-7. Estructura-comunicación del Orion Context Broker.
Fuente: [13]
Figura 2-6. Representación JSON de una entidad NGSI en modo
“keyValues”
Existen otros tipos de representaciones, como la simplificada o la
parcial. Además, la especificación de cada
operación incluye detalles sobre qué representación se espera como
entrada, o qué representación se
proporcionará como salida.
En este proyecto se hace uso, en la parte correspondiente a la
interfaz gráfica, de un tipo de representación
llamada representación simplificada modo “keyValues”. En este modo
se representan los atributos de la
entidad en parejas nombre-valor, excluyendo información sobre el
tipo y los metadatos. También incluye
información sobre el identificador y tipo de la entidad.
2.2.2 Orion Context Broker
El principal y único componente obligatorio de cualquier plataforma
o solución “Powered by FIWARE” es
Orion Context Broker (OCB). Como se ha comentado anteriormente,
Orion implementa la API REST
NGSIv2, la cual permite administrar todo el ciclo de vida de la
información de contexto, incluidas
actualizaciones, consultas, registros y suscripciones, basando su
comunicación con otros componentes del
sistema en mensajes HTTP [13].
OCB permite la publicación de información de contexto por elementos
llamados “productores de contexto”, de
forma que dicha información publicada se encuentre disponible para
otros elementos, llamados “consumidores
de contexto”, las cuales están interesados en recibir esta
información.
El servidor OCB siempre está escuchando en un puerto, que por
defecto es el 1026, pero se puede modificar.
Para almacenar el estado actual de sus entidades, OCB usa la base
de datos MongoDB, pero no se almacena
información histórica de sus cambios. Si se quisiera conseguir
esto, habría que utilizar una base de datos
externa.
14
El principio fundamental en el que se basa el Context Broker es el
de lograr una disociación total entre
productores y consumidores de contexto. Los productores de contexto
publican datos sin saber ni quién, ni
dónde, ni cuándo consumirán dichos datos publicados. Por otro lado,
los consumidores de contexto obtienen
información de su interés sin saber qué productor ha sido quien lo
ha publicado. Por ello, no se necesita una
conexión entre ambas partes. Además, los consumidores pueden
suscribirse a la información de contexto, para
que cuando ocurra alguna condición, como por ejemplo una
actualización de los valores de los atributos de
una entidad, reciban una notificación con dicha
actualización.
2.2.2.1 Suscripción
Una petición de suscripción se representa mediante un objeto JSON
con los siguientes campos:
description: se emplea para que el cliente introduzca una breve
descripción de la suscripción. Su uso
es opcional.
subject: describe qué entidades se ven afectadas por dicha
suscripción y bajo qué condiciones. A su
vez, está formado por los campos: entities y condition.
entities define qué entidades están involucradas en la suscripción
y se compone de:
• id o idPattern: identificador de la entidad afectada, o patrón de
entidades afectadas. Son
incompatibles, es decir, no se pueden usar ambos en la misma
suscripción.
• type o typePattern: tipo de la entidad, o patrón de tipo al que
afectará. Al igual que el campo
anterior, no se pueden usar ambos en el mismo objeto.
condition define el “disparador” para la suscripción. Contiene el
campo attrs, el cual almacena una
lista de nombres de atributos. Una modificación en el valor de
alguno de estos atributos activaría una
notificación. Si este campo está vacío significa que, cualquier
cambio en un atributo de las entidades
afectadas, desencadenaría una notificación.
notification: describe la notificación que va a ser enviada por OCB
en caso de que se cumplan las
condiciones de la suscripción. Está compuesto de:
• http: contiene el subcampo url, donde se indica a qué URL se van
a enviar las notificaciones.
Solo se puede incluir una URL por suscripción.
• attrs o exceptAttrs: attrs define el conjunto de atributos que
serán incluidos en el mensaje de
notificación. En caso de que este vacío, significa que todos los
atributos de la entidad serán
incluidos. exceptAttrs define el conjunto de atributos que serán
excluidos del mensaje de
notificación, es decir, se incluirán todos los atributos de la
entidad menos los que aparezcan
en esta lista.
• attrsFormat: especifica cómo deben ser representadas las
entidades en las notificaciones. Es
opcional y por defecto su valor es “normalized”.
• metadata: define el conjunto de metadatos que se deben incluir en
los mensajes de
notificación.
expires: indica la fecha de vencimiento de la suscripción, a partir
de la cual se ignora, manteniéndose
aún almacenada en la base de datos, ya que es posible modificar su
duración, actualizando este
campo. Se especifica en formato ISO 8601. Si este campo no aparece,
significa que la suscripción no
tiene fecha de vencimiento, es decir, es permanente.
throttling: indica el tiempo mínimo que debe pasar entre dos
notificaciones consecutivas. Se mide en
segundos.
2.2.2.2 Notificación
subscriptionId: referencia al identificador de la suscripción que
originó dicha notificación.
data: es un vector con los datos de la notificación en sí, es
decir, los datos a enviar que han sido
configurados en la suscripción, la cual ha provocado dicha
notificación. Cada elemento del vector se
corresponde a una entidad diferente. Como se ha comentado en el
apartado de las suscripciones, la
representación de las entidades depende del valor configurado en
attrsFormat.
En la Figura 2-8 se muestra un ejemplo de notificación.
2.2.3 Perseo
Perseo [14] es un software de procesamiento de eventos complejos
(CEP) basado en Esper, diseñado para ser
totalmente compatible con NGSIv2. Al utilizar NGSIv2 como protocolo
de comunicación para eventos,
Perseo puede trabajar conjuntamente con Orion Context Broker.
El principio de funcionamiento de Perseo se basa en escuchar
eventos que provienen de la información de
contexto, para así poder identificar patrones descritos por reglas,
con el fin de reaccionar de inmediato a ellos
mediante diversas acciones.
Estado del arte
Figura 2-9. Estructura de funcionamiento de Perseo. Fuente:
[14]
Perseo recibe los eventos a través de un POST, el cual contiene la
representación JSON del evento, y le aplica
las reglas, expresadas en EPL, lenguaje de reglas de Esper. Esper
es la biblioteca Java que contiene el motor de
reglas y la lógica de procesamiento de eventos. Cuando un evento
entrante activa una regla, los valores
seleccionados por la expresión EPL se emplean para llevar a cabo la
acción desencadenada.
Perseo necesita interactuar con OCB, ya que es la fuente de eventos
de las entidades que Perseo gestiona.
Además, una de las posibles acciones que puede desencadenar Perseo,
consiste en la actualización de una
entidad de Orion, como detallaremos más adelante. Además, necesita
de conexión con una base de datos
MongoDB, ya que es donde almacenará las reglas configuradas, con
las ejecuciones de acciones asociadas.
Perseo está formado por dos componentes (ver Figura 2-9):
Perseo-FE: es el “front-end” del procesador de eventos complejos.
Es la parte encargada de procesar
los eventos y reglas entrantes, almacenar las reglas y ejecutar las
acciones. Además, registra la
ejecución de acciones, para así controlar la frecuencia con la que
se realizan dichas acciones.
Perseo Core: es el “back-end” del CEP, el “motor de reglas”. Se
encarga de comprobar los eventos
entrantes de acuerdo con las reglas en EPL y de invocar a Perseo-FE
si se debe llevar a cabo una
acción. No tiene almacenamiento persistente. Las reglas se guardan
en memoria y son actualizadas
periódicamente por Perseo-FE.
Las notificaciones enviadas por Orion Context Broker son procesadas
por Perseo-FE antes de ser enviadas a
Perseo Core como eventos.
2.2.3.1 Regla
Mediante la aplicación de reglas, Perseo genera eventos “complejos”
a partir de un evento entrante. En general
consiste en una condición a cumplir y una acción resultante. Esta
acción es siempre elegida de un conjunto
preestablecido de acciones, como veremos en el siguiente
apartado.
Figura 2-10. Estructura de una regla en Perseo. Fuente: [14]
Las reglas siguen una estructura JSON compuesta de tres campos
obligatorios:
name: define el nombre de la regla, y se utiliza como identificador
de esta. Debe comenzar por una
letra, y puede contener dígitos, guiones bajos y guiones. Su
longitud máxima es de 50 caracteres.
action: establece que acción debe realizar Perseo cuando se activa
la regla. Se pueden establecer más
de una acción en la misma regla, evitando así tener que duplicar
una regla si queremos ejecutar más de
una acción.
text: contiene la declaración EPL que se enviará a Perseo Core, es
decir contiene la regla propiamente
dicha.
Las reglas se expresan como una oración EPL. EPL (lenguaje de
procesamiento de eventos) [15] es un
lenguaje de dominio de Esper [16], el motor para procesar eventos
utilizado en Perseo Core, que implementa y
extiende del estándar SQL. EPL es un lenguaje declarativo creado
para poder tratar con datos de eventos de
alta frecuencia, que permite la consulta y el procesamiento de
eventos en tiempo real, así como la posibilidad
de añadir una “dimensión temporal” a esto.
A continuación, se van a explicar algunas de las principales
cláusulas que se utilizan en este lenguaje, con el
fin de que más adelante se puedan entender mejor las expresiones
EPL empleadas durante el desarrollo de este
proyecto:
select: se utiliza para especificar las propiedades a seleccionar
de los eventos. Es obligatorio su uso.
Mediante el símbolo “*” se indica que queremos seleccionar todas
las propiedades.
from: especifica la fuente de datos de la que va a provenir el
evento. Se pueden indicar más de una
fuente de datos, separándolas por comas, pero siempre debe aparecer
al menos una, es decir, es
obligatorio que aparezca en la expresión EPL.
where: esta cláusula permite establecer las condiciones que deben
cumplir los eventos entrantes para
que se active la regla. Permite el uso de operadores como =. <,
>, <=, >=, ¡=, <>, IS NULL, IS NOT
NULL, y de combinaciones lógicas AND y OR.
pattern: comprueba si se satisfacen una serie de condiciones sobre
eventos de flujos de entrada, los
cuales han de ser identificados de forma unívoca. Aparece en
conjunto con la cláusula from,
escribiéndose justo después de esta.
and: operador lógico que requiere que tanto la expresión de su
izquierda, como la de su derecha, se
cumplan, para que este devuelva un valor verdadero.
or: operador lógico que requiere que al menos una de las dos
expresiones que aparecen a su lado se
cumpla, para que este devuelva un valor verdadero.
not: operador que retorna un valor verdadero si la expresión no se
cumple.
every: operador que se utiliza para controlar la coincidencia
contínua de patrones. El patrón se dispara
cada vez que se encuentre con un evento del tipo especificado. Si
no se especifica este operador el
patrón no seguirá buscando una vez se haya detectado la primera
ocurrencia de ese tipo de evento.
Estado del arte
18
win:length(size): esta cláusula permite llevar a cabo reglas que
impliquen a un número de eventos,
especificado dentro del paréntesis. Es decir, conforma una ventana
de longitud móvil, deslizante, que
extiende un número de elementos, obtenidos a partir de un flujo de
eventos de entradas, permitiendo
realizar cálculos a partir de ellos.
win:time(time period): esta cláusula es similar a la anterior, pero
la ventana en lugar de basarse en
elementos, se basa en un intervalo de tiempo. Es decir, proporciona
una ventana de tiempo móvil, que
se extiende el intervalo de tiempo especificado hacia el pasado, en
función de la hora del sistema,
permitiendo realizar operaciones según los eventos obtenidos dentro
de dicha ventana.
regexp: comprueba si la expresión proporcionada coincide con el
patrón configurado en el operador,
devolviendo un valor verdadero en caso de que así sea, o un valor
falso en caso contrario.
Perseo funciona con cualquiera de las cláusulas EPL, pero con
algunos matices:
El nombre de la secuencia de la que vendrán los eventos es
iotEvent.
Es obligatorio el uso de la condición “type=<…>”, con el fin
de evitar mezclar los diferentes tipos de
entidades.
Los atributos de la entidad se deben convertir a float en caso de
que sean numéricos, o a string en el
caso contrario.
Todos los atributos de la notificación están disponibles como
propiedades dinámicas del objeto de
evento, ev.
Es necesario un signo de interrogación para que EPL se refiera a
valores dinámicos.
Los metadatos también están disponibles para su uso.
2.2.3.2 Acción
Cuando a Perseo le llega un evento que coincide con alguna de las
reglas almacenadas en el motor de reglas,
esa regla se activa. Perseo Core genera un evento complejo,
utilizando para ello los parámetros añadidos en la
instrucción select de la cláusula del EPL, y se lo envía a
Perseo-FE, el cual ejecutará una acción, utilizando el
evento generado como parámetro
Como se ha comentado en el apartado anterior, las acciones a
realizar se establecen mediante el campo action
de la regla. Dentro del este campo, encontramos, obligatoriamente,
el subcampo type, que puede tener uno de
los siguientes valores [17]:
update: actualiza uno o más atributos de una entidad dada, en el
OCB especificado en la
configuración de Perseo.
sms: envía un SMS a un número establecido como parámetro de la
acción, con un cuerpo de mensaje
creado.
email: envía un correo electrónico al destinatario establecido en
los parámetros, con el cuerpo del
correo configurado.
post: realiza una solicitud HTTP a una URL proporcionada, con un
cuerpo establecido en la
configuración de la regla.
twitter: envia un tweet, a través de una cuenta para la cual tiene
permiso de acceso.
Una acción, opcionalmente, puede tener un campo llamado interval,
que representa el tiempo mínimo que
debe transcurrir entre ejecuciones consecutivas. Se expresa en
milisegundos y su objetivo es limitar la
frecuencia con la que se ejecuta la acción. Es decir, una vez que
se ejecuta la acción con éxito, no se volverá a
ejecutar hasta que haya transcurrido ese período de tiempo como
mínimo, descartando todas las solicitudes de
ejecución que puedan llegar durante ese intervalo.
Dentro de las posibles acciones que Perseo puede realizar, vamos a
entrar en más detalle en tres de ellas, las
que hemos aplicado durante el proyecto: email, post y update.
Si la acción a realizar es de tipo email, tendremos que rellenar
los diferentes campos que conforman el correo
electrónico a enviar en caso de que se active:
template: en este campo se introduce el cuerpo del email.
parameters: dentro de este campo encontramos:
• to: establece cuál es la dirección destino del correo
electrónico.
• from: establece el correo electrónico desde el cual va a ser
enviado el email.
• subject: indica el asunto del propio email.
En cambio, si la acción a realizar es de tipo post, los campos que
nos encontramos son:
template: cuerpo de la solicitud HTTP.
parameters: dentro de este campo se encuentran:
• method: método HTTP a utilizar. Por defecto su valor es
POST.
• url: URL destino que va a tener la solicitud HTTP.
• headers: objeto con los campos y valores, de los diferentes
encabezados que se desea que
tenga la solicitud.
• qs: objeto con campos y sus correspondientes valores, para
construir la cadena de consulta de
la URL.
• json: objeto que se enviará, en formato JSON, como cuerpo de la
solicitud realizada. En caso
de que esté presente, anula el valor del campo template.
Por último, si la acción a realizar es de tipo update debemos
cumplimentar los siguientes campos, localizados
dentro del campo parameters:
id: identificador de la entidad cuyos atributos se van a
actualizar. Si no se indica, por defecto se usa el
identificador de la entidad que activó la regla.
type: tipo de la entidad a modificar. Por defecto se utiliza el
tipo de la entidad que llevó a cabo la
activación de la regla.
version: versión NGSI a utilizar para llevar a cabo la
actualización. Por defecto se utiliza NGSIv1.
Para utilizar el formato NGSIv2 habría que establecer el valor de
este atributo a 2.
isPattern: indica si el id especificado es una expresión regular,
con la que poder seleccionar más de un
elemento. Por defecto su valor es “false”. Este campo sólo tiene
efecto para NGSIv1, siendo ignorado
si se aplica NGSIv2.
attributes: conjunto de atributos que se van a modificar. Cada
elemento de la lista debe contener los
siguientes campos:
• value: nuevo valor que se desea establecer para dicho
atributo.
• type: tipo del atributo. Este campo es opcional, si no se indica,
el tipo del atributo a actualizar
no cambia.
actionType: tipo de acción a realizar. Dispone de tres
posibilidades:
• APPEND: actualiza los atributos, si ya existen en la entidad, o
los anexa a dicha entidad en el
caso de que no existan. Es el tipo de acción establecida por
defecto.
Estado del arte
20
• UPDATE: actualiza los atributos, si ya exiten en la entidad. De
lo contrario, la operación de
actualización falla en el OCB.
• DELETE: elimina los atributos indicados, pudiendo llegar a
eliminar la propia entidad si su
lista de atributos está vacía.
service: permite indicar si la entidad a actualizar se encuentra en
un “service” diferente al de la
entidad que activó la acción, es decir en un ámbito de primer nivel
diferente.
subservice: permite indicar si la entidad a actualizar se encuentra
en un “subservice” distinto al de la
entidad que activó la acción, es decir en un ámbito de segundo
nivel diferente. Los ámbitos de
segundo nivel están definidos dentro de un ámbito de primer
nivel.
La combinación de los campos service y subservice marcan el ámbito
dónde es visible y accesible la
entidad.
2.3 MongoDB
MongoDB es un sistema de base de datos NoSQL, de código abierto y
orientado a documentos, es decir,
almacena datos en documentos flexibles, similares a JSON, lo que
significa que los campos pueden variar de
un documento a otro y la estructura de los datos se puede cambiar
con el tiempo. Este modelo de manejar los
datos permite esquemas más flexibles y dinámicos, además de una
representación más natural y expresiva. El
modelo de los documentos se puede mapear a objetos en el código de
aplicación, lo que facilita el manejo de
los datos [18].
Entre sus características destaca que es una base de datos
distribuida, facil de aprender y usar, con alto
rendimiento, escalado automático y alta funcionalidad.
Se ha empleado MongoDB debido a que Orion Context Broker necesita
de esta para el almacenamiento de su
información [19]. De igual manera, Perseo exige tener una base de
datos MongoDB para el almacenamiento
de las reglas que maneja [20].
2.4 Historia clínica
La historia clínica es el conjunto de documentos relativos a la
atención sanitaria prestada a un paciente, que
incluye los datos, valoraciones e informaciones sobre su situación
y evolución clínica, así como la
identificación de los médicos y de los demás profesionales que han
intervenido. Además, incorpora datos
relacionados con sus antecedentes personales y familiares, sus
hábitos y todo aquello vinculado con su salud
biopsicosocial [21].
La función principal de la historia clínica es facilitar el trabajo
de los profesionales sanitarios que tengan que
tratar a un paciente, conociendo de forma inmediata toda la
información relativa a su salud. Por otra parte,
permite la posibilidad de aprender y mejorar de los tratamientos
pasados, gestionar y administrar los servicios
médicos de las instituciones sanitarias o permitir al médico
ofrecer un tratamiento más personalizado al propio
paciente.
Figura 2-11. Logo de MongoDB
Figura 2-12. Logo de FHIR
Debido a la necesidad de sistemas interoperables en el ámbito de la
salud, ya que la información está en
continuo intercambio entre los profesionales sanitarios, pacientes
y diferentes instituciones; es necesario que la
información que se maneja siga un determinado estándar, que ofrezca
un modelo que permita la interacción
entre ellos. Hay una gran variedad de estándares en el sector
sanitario, pero uno de los más importantes es el
empleado en este proyecto, el estándar FHIR.
2.5 FHIR
FHIR (Fast Healthcare Interoperability Resources) [22] es un
estándar desarrollado por la organización
internacional HL7 (Health Level Seven), organización responsable
del desarrollo de estándares para facilitar el
intercambio electrónico de información clínica. FHIR trata de
combinar lo mejor de cada uno de los estándares
que se encuentran actualmente en uso, en particular de HL7 v2, HL7
v3 y CDA, con estándares web
modernos, de forma de que se mejore la implementación de los
estándares de interoperabilidad.
FHIR está diseñado para permitir el intercambio de información
relacionada con la atención médica, con el fin
de apoyar la provisión de dicha atención en una amplia variedad de
entornos. Su alcance es amplio, abarca
aspectos humanos y veterinarios, salud pública, atención clínica,
ensayos clínicos, administración y aspectos
financieros. El estándar está diseñado para uso global y en una
amplia variedad de contextos.
Este estándar proporciona una especificación “RESTful”, es decir,
utilizan el protocolo REST basado en
HTTP para el intercambio de la información. La información se
maneja en estructuras XML, JSON o RDF.
2.5.1 Recursos
Las soluciones de FHIR se crean a partir de un conjunto de
componentes modulares llamados “Recursos”. Un
recurso representa un concepto dentro del mundo sanitario, como
puede ser un paciente, un médico, una
observación, un problema de salud, etc. Es la unidad básica más
pequeña que tiene sentido intercambiar.
Actualmente hay 145 tipos de recuros diferentes definidos.
Los recursos tienen una serie de campos comunes:
Una URL que identifica al recurso, a partir de la cual puede ser
registrado, localizado y recuperado.
Un conjunto de campos de datos, definidos en la estructura del
propio recurso. Cada tipo de recurso
tiene un conjunto de campos diferentes que lo compone.
Metadatos comunes.
Un resumen XHTML legible para humanos, denominado elemento
narrativo, el cual permite una
visión legible de los datos almacenados en el recurso, para que
cualquier persona pueda comprender la
información clínica esencial, descrita en el recurso.
Un marco de extensibilidad para soportar la variación en la
asistencia sanitaria, que permite a los
implementadores añadir nuevas propiedades de manera sencilla.
Estado del arte
22
Todos los recursos presentan un identificador único, dentro del
espacio de recursos pertenecientes al mismo
tipo en el servidor. Este identificador es asignado por el propio
servidor y no puede ser modificado nunca. Es
decir, cada recurso presenta una combinación de resourceType e id
única.
Es interesante remarcar la diferencia entre el campo id y el campo
identifier. El campo id es el identificador
lógico del recurso. Este identificador cambia si el recurso es
trasladado de un servidor a otro. En cambio,
identifier¸es el identificador de negocio del recurso, y este se
mantiene invariante independientemente de si el
recurso se mueve a otro servidor o si se realiza una copia de dicho
recurso, lo que permite mantener la
consistencia en todos los contextos de uso [23].
FHIR define la estructura que tiene cada tipo de recurso, la cual a
su vez define los campos que lo conforman,
en los cuales se va a almacenar la distinta información que maneja.
Además, define para cada campo, el tipo
de datos que admite.
Entre los diferentes campos que conforman la estructura de un
recurso, conviene destacar reference. Este
campo permite crear dentro de un recurso una referencia a otro,
permitiendo crear mediante su uso, una red de
información, donde existen relaciones entre los distintos recursos.
Contiene la dirección del recurso contenido,
ya sea en forma de URL o a través de su identificador de
recurso.
Elemento narrativo
Figura 2-13. Estructura de un recurso FHIR
A continuación, vamos a explicar dos de los recursos más
importantes que expone este estándar, Patient y
Observation, los cuales han sido utilizados en este proyecto, junto
sus principales funcionalidades y la
estructura que lo conforman.
2.5.1.1 Recurso Patient
Un recurso de tipo Patient [24] contiene información sobre “quién”
es el paciente, datos demográficos e
información administrativa, sobre la persona o animal que recibe
algún tipo de servicio relacionado con la
salud, incluyendo, actividades sanitarias, cuidados psiquiátricos,
servicios sociales, enfermería y de vivienda
asistida, seguimiento de la salud personal y del ejercicio,
servicios dietéticos y cuidados durante el embarazo.
Principalmente, se centran en aportar la información demográfica
necesaria, para así poder respaldar los
procedimientos administrativos, financieros y logísticos.
Entre los atributos que pueden formar parte de la estructura de
este tipo de recurso, destacan [25]:
Tabla 2-1. Definición Patient.identifier
Cardinalidad 0..*
Tipo Identifier
Descripción Identificador de negocio único asignado al paciente.
Hay que tener en cuenta la diferencia
entre el identificador de negocio y el identificador lógico,
comentada en el punto “2.5.1
Recursos”.
Cardinalidad 0..1
Tipo boolean
Descripción Indica si dicho registro del paciente está activo. Se
suele usar para marcar como pacientes
inactivos aquelllos registros que no han sido actualizados por un
periodo de tiempo
marcado por las reglas de la organización que lo gestiona.
Tabla 2-3. Definición Patient.name
Cardinalidad 0..*
Tipo HumanName
Descripción Nombre asociado al paciente. Un paciente puede tener
varios nombres con diferentes usos
o periodos aplicables.
Estado del arte
Cardinalidad 0..*
Tipo ContactPoint
Descripción Información mediante la cual se puede contactar con el
paciente, como por ejemplo una
dirección de correo electrónico o un número de teléfono.
Tabla 2-5. Definición Patient.gender
Cardinalidad 0..1
Tipo code
Descripción Género que se considera que tiene el paciente, para
fines de administración y
mantenimiento de registros.
Cardinalidad 0..1
Tipo date
Descripción Fecha de nacimiento del individuo, ya que la edad
impulsa muchos procesos clínicos.
Tabla 2-7. Definición Patient.deceased[x]
Patient.deceased[x]
Cardinalidad 0..1
Tipo boolean | dateTime
Descripción Indica si el paciente ha fallecido o no, ya que esto
influye tanto en el proceso clínico,
como en la comunicación humana y la gestión de relaciones con el
individuo.
Tabla 2-8. Definición Patient.address
o periodos aplicables.
Tipo Reference (Organization)
Descripción Referencia a la organización que custodia el registro
del paciente, quién reconoce dicho
registro, lo administra y lo actualiza.
2.5.1.2 Recurso Observation
Un recurso de tipo Observation [26] contiene mediciones y
afirmaciones simples hechas sobre un paciente,
dispositivo u otro tema.
En el ámbito de la salud, las observaciones son un elemento
importante para apoyar un diagnóstivo,
monitorear el progreso, determinar líneas de base y patrones, e
incluso capturar características demográficas.
Este recurso está destinado a capturar mediciones y evaluaciones
subjetivas, en un instante de tiempo, pero,
aunque no es su objetivo, también puede transmitir cualquier tipo
de información deseada. Su fin no es ser
utilizado para contextos específicos ni para casos de uso ya
cubiertos por otros recursos de este estándar, como
pueden ser las alergias de un paciente, de las que se encarga el
recurso AllergyIntolerance. Observation no
debe utilizarse para registrar el diagnóstico clínico sobre un
paciente o sujeto, para los cuales existen otros
recursos. Su enfoque es proporcionar datos subjetivos y objetivos
específicos, con los que poder repaldar
futuras afirmaciones.
Los principales usos para los que está pensado este recurso
son:
Signos vitales, como temperatura, frecuencia cardíaca y presión
arterial.
Datos de laboratorio, como glucosa en sangre o tasa de filtración
glomerular.
Hallazgos clínicos, como sensibilidad abdominal.
Historia social, como consumo de tabaco o estado cognitivo.
Mediciones de un dispositivo, como un pulsioxímetro.
Reflejar características personales, como el color de los
ojos.
A continuación, vamos a comentar los principales atributos que
componen su estructura [27]:
Estado del arte
Descripción Identificador de negocio único asignado a la
observación. Destacamos la diferencia entre
el identificador de negocio y el identificador lógico, comentada en
el punto “2.5.1
Recursos”.
MedicationRequest | NutritionOrder | ServiceRequest)
Descripción Refencia a un plan, propuesta u orden que, de formar
parcial o total, cumple este recurso.
Tabla 2-12. Definición Observation.parOf
Procedure | Immunization | ImagingStudy)
Descripción Referencia a un recurso “mayor”, del cual la
observación es un componente de este.
Tabla 2-13. Definición Observation.status
Cardinalidad 1..1
Tipo code
Descripción Indica el estado del valor de dicha observación. Los
estados posibles son: “registered”,
“preliminary”, “final” y “amended”.
Tabla 2-14. Definición Observation.category
Cardinalidad 0..*
Tipo CodeableConcept
Descripción Código que clasifica, de forma general, la observación
que se realiza según su tipo
Tabla 2-15. Definición Observation.code
Cardinalidad 1..1
Tipo CodeableConcept
Descripción Describe qué aspecto se representa mediante este
recurso, es decir, que se observó.
Tabla 2-16. Definición Observation.subject
Descripción Referencia al paciente, o grupo de pacientes, ubicación
o dispositivo, del que trata la
observación, y en cuyo registro se va a colocar esta. Este campo es
importante, ya que una
observación carece de valor si no se sabe de quién o de qué se
trata.
Tabla 2-17. Definición Observation.effective[x]
Observation.effective[x]
Cardinalidad 0..1
Tipo dateTime | Period | Timing | instant
Descripción Tiempo, o periodo de tiempo, en el que la observación
se ha llevado a cabo. Al menos una
fecha debe estar presente, a no ser que la observación sea un
informe histórico.
Estado del arte
Observation.value[x]
Cardinalidad 0..1
time | dateTime | Period
Descripción Información extraída como resultado de hacer la
observación, en el caso de que la
información tenga un valor simple
Tabla 2-19. Definición Observation.note
Descripción Comentarios sobre los resultados obtenidos con la
observación. Puede incluir
declaraciones generales sobre dicha observación, información sobre
la fuente de esta, si es
un dato relevante para poder interpretarla, o declaraciones sobre
valores de resultados
significativos, inesperados o poco confiables.
Tabla 2-20. Definición Observation.device
Tipo Reference (Device | DeviceMetric)
Descripción Referencia al dispositivo utilizado para obtener los
datos de la observación.
2.5.2 HAPI FHIR
HAPI (Health Application Programming Interface) FHIR [28] es una
implementación completa del estándar
HL7 FHIR, para la interoperabilidad de la atención médica, basada
completamente en lenguaje de
programación Java. Es una biblioteca Java de código abierto, que
facilita un mecanismo incorporado para
agregar las funcionalidades RESTful Server de FHIR a una aplicación
software.
Figura 2-14. Logo de HAPI FHIR
Figura 2-15. Logo de Freeboard
Su intención principal es proporcionar una forma flexible de
agregar las capacidades que ofrece FHIR a todo
tipo de aplicaciones. Para ello proporciona herramientas para crear
servidores conforme a este estándar, para
analizar, codificar y decodificar recursos FHIR, o para configurar
un cliente, el cual permita recuperar y
registrar recursos en un servidor FHIR externo.
El servidor HAPI RESTful se basa en un servlet, por lo que se puede
implementar con facilidad en cualquier
contenedor compatible con servlet 3.0 +, como por ejemplo Jetty o
Apache Tomcat.
2.6 Freeboard
Freeboard [29] es una plataforma OpenSource, que nos permite la
creación de paneles interactivos y
visualizaciones en tiempo real, mediante una intuitiva interfaz. La
creación de dashboards se lleva a cabo
mediante la unión de diferentes widgets, los cuales son los
encargados de mostrar los datos en tiempo real, de
acuerdo con un tipo de representación.
Además, presenta una arquitectura de complementos para crear
fuentes de datos, de las cuales se van a obtener
la información, y widgets, los cuales van a representar los datos.
Freeboard, internamente, se encarga de
conectar ambas partes.
Una de sus principales características, es la capacidad de
ejecutarse complemente en el navegador como una
aplicación web estática de una sola página, sin la necesidad de un
servidor.
Freeboard proporciona un panel de configuración compuesto por una
parte dedicada a Datasources donde se
pueden agregar nuevas fuentes de datos al dashboard, así como
ver/configurar las previamentes añadidas. Los
widgets configurados podrán obtener los datos de las fuentes de
datos que aquí aparezcan.
Por otra parte, en el panel de configuración tenemos una parte
dedicada a la agregación y configuración de
paneles de visualización, con l