Monitoring & Wearables
Your 3rd device vendor just changed their API. Again.
You've already built custom parsers for the pulse oximeter, the glucose monitor, and the activity tracker. Each one has its own schema, its own quirks, its own on-call incident at 2am when the format changes without warning.
Your analytics team wants to correlate sleep quality with glucose levels. They can't — the data lives in three different tables with three different timestamp formats. That report will take a sprint to build and break the next time any vendor pushes an update.
Sound familiar?
❌ Without Atomik
Your wearable app stores readings in a proprietary format. Three months later, your analytics team can't correlate sleep data with vitals because they live in different schemas. Every new device integration requires custom ETL. Alerts are hardcoded. Adding a new sensor model breaks existing queries.
✅ With Atomik
All biometric streams — BLE sensors, smartphones, medical monitors — map to openEHR archetypes once. Every downstream query, alert, and report runs against the same standardized store. Add a new device type by uploading a template, not rewriting your pipeline.
Are you building a physical activity monitor, sleep tracker, weight control app, or remote patient monitoring platform? Atomik acts as the canonical data aggregator backend — simplifying ingestion, standardizing storage, and powering automated alerts and recommendations through smart queries.
Architecture & Data Flows
The most common architecture for monitoring devices include a physical monitor, that generates raw data from vital signs, analyzing chemicals, sleep status, exercise and other kinds of measurements. The monitoring device then communicates the raw data to a nearby device, which is commonly called "gateway". In general that communication happens through BLE (Bluetooth Low Energy) or similar PAN (Personal Area Network) protocol.
The gateway has connection to the Internet and can communicate the raw data, maybe pre-processed, to a cloud service. That could be a direct communication (Native API) or via a broker/integration engine. A broker would transform the data coming from the gateway into a format the cloud service can understand.
In this context, Atomik acts as the cloud service, where data is stored in a standardized format, and the goal of the broker is to transform raw or raw-processed data into openEHR data, since the Native API is openEHR-compliant.
The final piece of the puzzle is the data analysis and visualization. To support this, Atomik provides a visual Query Builder that allows users to create complex queries without programming skills, which can be executed via API calls. This allows to create any number of "data services", to access data in a standardized way, and feed any analytics or visualization solution.
The goal of Atomik is to sit in the middle of the data collection / processing, and how the final data will be used for analytics / visualization, simplifying data management and access in a standardized an vendor-neutral way.