--- { "title": "Dispositivos IoT médicos y ponibles en FHIR: Una guía", "description": "Cómo modelar datos de dispositivos ponibles e IoT como recursos FHIR Device + Observation. Arquitectura, ejemplos de mapeo y una demostración de código abierto con Aidbox.", "date": "2024-03-24", "author": "Mike Ryzhikov", "reading-time": "5 min read", "tags": [ "Aidbox", "Integrations" ], "seo-tags": [ "fhir", "fhir-backend", "fhir-platform", "fhir-server", "fhir-time-series", "fhir-device", "fhir-wearable", "fhir-database", "fhir-first" ] } --- > For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt). > Use it to discover all available pages before guessing URLs. --- ## ¿Por qué construir IoT sanitario sobre FHIR? Los dispositivos IoT médicos y los dispositivos ponibles generan grandes volúmenes de datos que contribuyen a mejorar los resultados de salud. Estos datos solo son útiles si se integran en los historiales médicos de los pacientes y están disponibles para análisis exhaustivos, sistemas de alertas en tiempo real y soporte a la decisión clínica (CDS). El reto es que estos datos de series temporales tienen una naturaleza y estructura diferente a la de otros [datos FHIR](https://www.hl7.org/fhir/resourcelist.html) como los datos del paciente, las alergias, los diagnósticos, etc. Los datos de series temporales requieren un enfoque especial para su gestión y almacenamiento. Esta entrada muestra cómo integrar de forma eficaz los datos producidos por dispositivos médicos en una solución FHIR basada en [la plataforma FHIR Aidbox](https://www.health-samurai.io/aidbox). Aquí encontrará el modelo FHIR, una guía sobre cómo configurar la plataforma Aidbox y un enlace al proyecto de código abierto que ilustra este concepto. ## Dispositivos ponibles en FHIR: arquitectura de la solución Imaginemos que necesitamos integrar datos de un smartwatch y un monitor de ECG en los [historiales médicos FHIR](https://www.hl7.org/fhir/resourcelist.html) que ya gestionamos con nuestra [solución basada en Aidbox](https://www.health-samurai.io/aidbox). Vamos a recibir las siguientes mediciones: frecuencia cardíaca (FC), frecuencia respiratoria (FR), SpO2 y resultados diagnósticos de ECG. [![iot wearables devices](image-1.avif)](https://www.health-samurai.io/aidbox) Los datos brutos tienen este aspecto: ![medical wearable iot development](image-2.avif) ### 1. De datos brutos a datos FHIR En primer lugar, necesitamos convertir los datos brutos a FHIR. [HL7 FHIR](https://www.hl7.org/fhir/resourcelist.html) recomienda utilizar el [recurso Observation](https://www.hl7.org/fhir/observation.html) para intercambiar constantes vitales, ECG y otros datos mensurables del paciente. Una solución posible es modelar los datos producidos por los dispositivos según el [recurso FHIR Observation](https://www.hl7.org/fhir/observation.html) con los siguientes atributos de componente: ![iot wearables for health](image-3.avif) ### 2. De PostgreSQL genérico a PostgreSQL híbrido En segundo lugar, Aidbox está construido sobre PostgreSQL y almacenamos los recursos FHIR como JSONB. Para nuestro caso, necesitamos convertir el potente Postgres en un almacenamiento híbrido capaz de trabajar de forma eficaz tanto con JSONB como con datos de series temporales. La clave está en la extensión [TimescaleDB](https://www.timescale.com/) para Postgres. Esta extensión añade un tipo especial de tabla denominado [Hypertable](https://docs.timescale.com/use-timescale/latest/) para datos de series temporales y varias opciones adicionales, como [compresión](https://docs.timescale.com/use-timescale/latest/compression/), [agregados continuos](https://docs.timescale.com/use-timescale/latest/continuous-aggregates/) y otras más. Como resultado, podemos seguir almacenando los datos FHIR básicos como JSONB y las Observations como datos de series temporales en [hypertables](https://docs.timescale.com/use-timescale/latest/). Estos datos estarán referenciados y funcionarán como un conjunto de datos único para necesidades externas. ![devices on fhir](image-4.avif) ### 3. De Aidbox estándar a Aidbox optimizado para series temporales El tercer paso consiste en enseñar a nuestro Aidbox a gestionar y almacenar las Observations como datos de series temporales en hypertables, y el resto de datos FHIR como JSONB mediante el mecanismo predeterminado. Para lograrlo, podemos sustituir el manejador del endpoint `/Observation` por defecto por uno personalizado. Los clientes de Aidbox pueden hacerlo mediante [el mecanismo Aidbox Apps](https://www.health-samurai.io/docs/aidbox/tools/aidbox-sdk/aidbox-apps) y construir un manejador personalizado en el lenguaje de programación de su elección. También existen [SDK para Aidbox](https://www.health-samurai.io/docs/aidbox/tools/aidbox-sdk) y [APIs adicionales](https://www.health-samurai.io/docs/aidbox/api-1/reactive-api-and-subscriptions). ![iot wearables healthcare](image-5.avif) > > [Explore nuestra documentación completa del SDK](https://hubs.ly/Q02y4Vsz0) para aprender a crear aplicaciones personalizadas y adaptar la plataforma a sus necesidades específicas. ### 4. Aproveche el potencial de TimescaleDB para las alertas Voilà: su interfaz de usuario o sus sistemas externos pueden recuperar y visualizar los historiales médicos y los datos de observación a través de la API FHIR estándar. Pero la guinda del pastel es la capacidad de utilizar eficazmente los datos de series temporales vinculados a datos FHIR para alertas y soporte a la decisión clínica (CDS). [TimescaleDB](https://www.timescale.com/) ofrece numerosos motores sobre hypertables, y [el motor de agregados continuos](https://docs.timescale.com/use-timescale/latest/continuous-aggregates/create-a-continuous-aggregate/#create-a-continuous-aggregate) es uno de ellos. Por ejemplo, puede monitorizar y generar alertas en tiempo real cuando la FC aumenta o la SpO2 disminuye. Las condiciones de las alertas pueden basarse no solo en datos de series temporales, sino también en cualquier dato FHIR de su solución. Para hacer que estas alertas estén disponibles para su interfaz de usuario o sistemas/módulos externos, puede ampliar [la API de Aidbox mediante operaciones personalizadas](https://www.health-samurai.io/docs/aidbox/tools/aidbox-sdk/aidbox-apps#operations). Los manejadores de estos endpoints pueden estar basados en SQL o residir en su [Aidbox App](https://www.health-samurai.io/docs/aidbox/tools/aidbox-sdk/aidbox-apps) junto al manejador del endpoint `/Observation`. ![wearable api](image-6.avif) ### 5. Visión general de la solución extremo a extremo Reunamos todas estas ideas en la solución extremo a extremo. **#1** - Los dispositivos generan datos brutos de series temporales, **#2** - El conversor FHIR recibe este flujo, lo convierte a FHIR Observations y los envía a Aidbox, **#3** - Aidbox gestiona las Observations a través del endpoint `/Observation` sobreescrito mediante la [Aidbox App](https://www.health-samurai.io/docs/aidbox/tools/aidbox-sdk/aidbox-apps), **#4** - Los recursos Observation recibidos se almacenan en una [hypertable](https://docs.timescale.com/use-timescale/latest/hypertables/) y tienen una asociación mediante referencia al paciente, **#5** - El motor [TimescaleDB](https://www.timescale.com/) genera alertas basadas en condiciones predefinidas, **#6** - Aidbox proporciona [datos FHIR](https://www.hl7.org/fhir/resourcelist.html) a través de la [API FHIR](https://www.hl7.org/fhir/http.html) y alertas a través de endpoints personalizados, **#7** - La interfaz web visualiza estos datos y muestra las alertas a los usuarios finales. ![medical wearable iot development](image-7.avif) ## Bonus Nos gusta reforzar las palabras con la práctica y [hemos publicado el código fuente del proyecto](https://github.com/Aidbox/timeseries) con la implementación de este concepto, desarrollado por uno de los miembros de nuestro equipo durante el hackathon interno de Navidad en 48 horas. Si tiene experiencia técnica, puede consultar este código e interactuar con las ideas en la práctica sin ninguna barrera. ![wearable health data integration](image-8.avif)*Proyecto de código abierto: https://github.com/Aidbox/timeseries* ## Beneficios En esta entrada hemos descrito una solución muy básica sobre cómo integrar dispositivos ponibles y médicos en el ecosistema FHIR-first basado en la plataforma FHIR Aidbox. Todas las partes de este pipeline pueden ajustarse y mejorarse para soportar las cargas reales de su sistema. Por ejemplo, puede añadir colas para los flujos de datos de los dispositivos u optimizar una API similar a FHIR para las Observations, etc. Para explorar cómo Aidbox puede facilitar la integración de datos de dispositivos ponibles y médicos, pruebe la [versión gratuita de Aidbox](https://www.health-samurai.io/aidbox#run). Proporciona un entorno completo para probar y desarrollar estas integraciones, ofreciendo todas las herramientas necesarias sin ninguna limitación de funcionalidades. ### Resumen de beneficios **# Simplicidad** - solución monolítica con potente almacenamiento híbrido basado en PostgreSQL, **# Todo en un solo lugar** - datos FHIR y datos de series temporales como un único conjunto de datos, **# FHIR-first** - transformaciones internas mínimas, con FHIR utilizado para intercambiar y almacenar datos, **# Personalizable** - todas las partes de la solución pueden personalizarse gracias al paradigma orientado a datos, **# Rendimiento** - los almacenamientos y motores están fuertemente optimizados para ambos tipos de datos. Autor:[ **Mike Ryzhikov**](https://www.linkedin.com/in/fhir-solutions/) COO en Health Samurai [![Aidbox FHIR Platform Free Trial](image-9.avif)](https://www.health-samurai.io/aidbox) Véase también: [Suscripciones basadas en temas: los 5 principales casos de uso](/blog/topic-based-subscriptions-top-5-use-cases-for-digital-health) y [Uso de FHIR para simplificar el desarrollo en sanidad](/blog/using-fhir-to-simplify-healthcare-application-development).