Monitoreo y Wearables
Tu tercer proveedor de dispositivos acaba de cambiar su API. Otra vez.
Ya construiste parsers a medida para el oxímetro de pulso, el monitor de glucosa y el rastreador de actividad. Cada uno tiene su propio esquema, sus propias particularidades, su propio incidente de guardia a las 2am cuando el formato cambia sin aviso.
Tu equipo de analítica quiere correlacionar la calidad del sueño con los niveles de glucosa. No puede — los datos viven en tres tablas distintas con tres formatos de marca de tiempo distintos. Ese informe tomará un sprint construirlo y se romperá la próxima vez que cualquier proveedor publique una actualización.
¿Te suena familiar?
❌ Sin Atomik
Tu app de wearables almacena las lecturas en un formato propietario. Tres meses después, tu equipo de analítica no puede correlacionar los datos de sueño con los signos vitales porque viven en esquemas distintos. Cada nueva integración de dispositivo requiere ETL a medida. Las alertas están codificadas de forma fija. Agregar un nuevo modelo de sensor rompe las consultas existentes.
✅ Con Atomik
Todos los flujos biométricos — sensores BLE, smartphones, monitores médicos — se mapean a arquetipos openEHR una sola vez. Cada consulta, alerta e informe posterior corre contra el mismo almacén estandarizado. Agrega un nuevo tipo de dispositivo subiendo una plantilla, no reescribiendo tu pipeline.
¿Estás construyendo un monitor de actividad física, un rastreador de sueño, una app de control de peso o una plataforma de monitoreo remoto de pacientes? Atomik actúa como el backend agregador canónico de datos — simplificando la ingesta, estandarizando el almacenamiento e impulsando alertas y recomendaciones automatizadas mediante consultas inteligentes.
Arquitectura y flujos de datos
La arquitectura más común para dispositivos de monitoreo incluye un monitor físico que genera datos crudos a partir de signos vitales, análisis de sustancias químicas, estado del sueño, ejercicio y otros tipos de mediciones. El dispositivo de monitoreo comunica luego los datos crudos a un dispositivo cercano, comúnmente llamado "gateway". En general esa comunicación ocurre a través de BLE (Bluetooth Low Energy) o un protocolo PAN (Personal Area Network) similar.
El gateway tiene conexión a Internet y puede comunicar los datos crudos, tal vez preprocesados, a un servicio en la nube. Eso puede ser una comunicación directa (API Nativa) o vía un broker/motor de integración. Un broker transformaría los datos que llegan del gateway a un formato que el servicio en la nube pueda entender.
En este contexto, Atomik actúa como el servicio en la nube, donde los datos se almacenan en un formato estandarizado, y el objetivo del broker es transformar los datos crudos o parcialmente procesados en datos openEHR, ya que la API Nativa es conforme con openEHR.
La última pieza del rompecabezas es el análisis y la visualización de datos. Para dar soporte a esto, Atomik proporciona un Constructor de Consultas visual que permite a los usuarios crear consultas complejas sin habilidades de programación, las cuales pueden ejecutarse vía llamadas a la API. Esto permite crear cualquier cantidad de "servicios de datos", para acceder a datos de forma estandarizada, y alimentar cualquier solución de analítica o visualización.
El objetivo de Atomik es situarse en el medio entre la recolección/procesamiento de datos, y cómo se usarán finalmente esos datos para analítica/visualización, simplificando la gestión y el acceso a los datos de forma estandarizada y neutral respecto al proveedor.