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