Research Platform

Wearable Hub

Wearables are an obvious source of continuous physiological data for research — and a recurring source of engineering work, because every vendor authorizes, delivers, and sunsets its data differently. Wearable Hub absorbs that difference so a study team does not have to.

In development

What it does

Enroll a device once. Collect for the whole study.

Participant-authorized enrollment
Participants join with a study entry code and authorize their own device through the vendor's standard consent flow. Access tokens are refreshed automatically, so collection does not silently stop weeks into a protocol.
Continuous ingestion
Heart rate, sleep, and heart rate variability arrive through provider webhooks and are consolidated into normalized daily records — a stable schema regardless of which vendor produced the data.
Researcher console
A single view of study enrollment, per-participant data coverage, and export — so a missing week is visible while the participant is still enrolled, not at analysis.
Design

One integration seam per vendor.

Each provider is implemented as a self-contained authorization and ingestion module behind a common interface, because vendor integrations are not merely different — they are differently shaped, and they change without warning. Fitbit is supported through Google's Health API, replacing the legacy Fitbit Web API that Google is retiring in September 2026; Garmin support is next. Studies already collecting through the retiring interface are the reason this exists.

Status
Fitbit ingestion implemented via the Google Health API; Garmin in progress.
Technology
FastAPI backend with per-provider OAuth modules; React researcher console; containerized deployment.
Data collected
Heart rate, sleep, and heart rate variability, subject to what each participant authorizes and each vendor exposes.

Losing data to a deprecated API?

If your study collects wearable data through an interface that is being retired, we have already had that problem.

admin@omnikog.com