--- title: "Wearable Data for Health Data Platforms" description: "Wearable data inside your platform, in your own cloud account and under your credentials. Self-hosted, in your region, MIT licensed." canonical_url: "https://openwearables.io/for/health-data-platforms" --- # Wearable data inside your platform, in your own cloud account. Health data platforms You are already a processor for somebody else. Open Wearables runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo What you get ## What Open Wearables gives a platform team. Once you are a processor yourself, every system in the data path gets re-examined in governance reviews. Open Wearables keeps the wearable layer inside your own account. ### Access you control. It runs in your cloud account, under your credentials. When we work on your system, we do it under a DPA you sign. - Your account - No lock-in ### One schema, next to your record. Query a user, not a provider. Activity, sleep, heart rate and body measurements in one shape, in the same database as the rest of your platform. - One schema - Time series - Webhooks ### Raw payloads kept. Original provider responses are retained under the standard schema, so anything you need later can be re-derived without going back to the provider or to us. - Raw payloads kept - Re-derivable ### Your region, provably. You choose where it runs when it is deployed. Residency stops being a clause you negotiate and becomes a fact you can point at. - Your region - eu-central-1 ### Credentials in your name. Each source issues developer credentials to your organisation. The data relationship is between you and them, with nobody in the middle. - Your credentials - Provider apps in your name ### Costs you can see. Running it costs your own cloud bill, paid to your provider. Deployment and Integration are one-off services, and health scores and the other licensed modules come with Pro. - Your cloud bill - One-off services How it works ## From decision to first query. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) 01 ### Deploy it. Production and staging in your own cloud account, in the region you choose, defined as infrastructure code in your repository. Either your team stands it up, or you buy a deployment and we do it inside your account. 02 ### Get your own provider credentials. Each source issues developer credentials in your name, and you apply for them directly. Approval timelines vary and this is the slowest step, so it starts on day one. 03 ### Wire it into your platform. Your users authorise through each provider's own consent screen, inside your interface. The mobile SDK handles on-device sources in the background, behind the login your platform already has. 04 ### Query the record. Standardised data lands in your own database, so joining a night of sleep to the rest of a patient record is a query rather than an integration project. [See pricing](https://openwearables.io/pricing) The honest comparison ## Hosted API, in-house, or self-hosted. Where each one wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables | | --- | --- | --- | --- | | [01] First API call | Hours | Months | Minutes, with Docker Compose | | [02] Who can reach the data | The vendor and its sub-processors | Your team | Your team, and us under a DPA you sign when we work on it | | [03] Where the data sits | Their cloud, their regions | Yours | Your cloud account, your region | | [04] The data model | Theirs. You build against their schema | Yours | Yours, in your database | | [05] Raw provider payloads | Varies by vendor | Whatever you keep | Kept in your own bucket when you turn it on | | [06] Provider credentials | Theirs, handled for you | Yours to obtain | Yours, in your own name | | [07] Certifications | Theirs | Yours to earn | Yours, in your certified environment | | [08] Cost shape | Scales with monthly active users | Salaries and infrastructure | Fixed. Flattens as you grow | What stays yours ## The deployment, the data and the schema stay in your account, whoever runs it. ### Sovereignty Patient and member data does not sit in a third party's cloud. ### Residency It stays in the region you chose, provable by pointing at an account. ### Control You decide who reaches the data, under your own credentials. What you build on top of Open Wearables is yours. ### Your own reasons Before a regulator or customer asks, the schema and the data are in your account. Who it is for ## Platforms that are already somebody's processor. The argument on this page only works if somebody outside your company is asking where the data goes. These are the shapes where they are. ### EHR and clinical record platforms Wearable data next to the record you already hold, in the same account and under the same access controls. ### Telemedicine platforms You deliver care on behalf of a controller, so their governance rules reach your vendor choices. ### Health data aggregators You are the integration layer for somebody else, and a hosted aggregator underneath you is a dependency your customers can see. ### NHS-facing and public sector suppliers The driver is the governance review rather than residency. A wearable layer in your own account, under your credentials, is a shorter answer in that review than a faster first call. What you can build ## What teams build on it. Wearable data stops being a separate system and becomes part of the record you already show people. ### A fuller record Last night's sleep and this month's resting heart rate next to the notes, results and history already in your platform, on one timeline rather than in a separate tab. A patient record with a visit note, a result and a dose change, and today's sleep and resting heart rate from Apple Health filed into it. ### Between-visit context What happened in the weeks between appointments, summarised for the clinician who has ten minutes and a question about adherence. A brief before a 10:30 follow-up: sleep down 35 minutes a night and resting heart rate up 4 bpm since the last visit. ### Population views The same metric across a cohort, computed in your own database, so reporting to the organisation you act for does not depend on a vendor's export. A cardiac rehab cohort of 42: resting heart rate against each patient's baseline, three flagged, beside a monthly report. ## The devices your patients and members already wear. Each connected source arrives in the same schema, next to the record you already hold. [Browse integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Withings integration](https://openwearables.io/integrations/withings) - [Strava integration](https://openwearables.io/integrations/strava) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [SensorBio integration](https://openwearables.io/integrations/sensorbio) - [Google Health API integration](https://openwearables.io/integrations/google-health) - [Fitbit integration](https://openwearables.io/integrations/fitbit) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) ## Deploy Open Wearables in your own cloud. The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account with the providers connected and validated on real accounts. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) FAQ ## Do you have more questions? ### We are a processor for our customers. Who can reach the data? Your team. It runs in your cloud account, under your credentials, so wearable data does not pass through a vendor tenant. When we work on your system, we do it under a DPA you sign. [The sub-processors page](https://openwearables.io/sub-processors) covers both. ### Our customer's governance board asks who is in the data path. What changes? The wearable layer sits in your own account, under your credentials, rather than in a vendor's tenant. When we work on it, we do it under a DPA you sign. In an NHS-facing or public sector review, that counts for more than a faster first API call. ### Where does the data physically live? In the cloud account and region you choose at deployment. You can point at the account rather than describing a policy, which is usually what a residency question is really asking for. ### Can we run it ourselves, or do you have to? Either. Your team self-hosts it, or we deploy it into your cloud and, under Enterprise, maintain it there under a DPA you sign. In both cases it runs in your account, and the data stays there. ### Do you hold SOC 2 or ISO 27001? No. The deployment runs inside your certified environment, which is how most platforms answer this in their own audit. ### Will you sign a DPA? Yes, whenever our people can reach your deployment: under Pro support, during a Deployment or Integration service, and for as long as Enterprise runs. Where you self-host on Core, there is no processing for us to agree to, because we never touch it. ### What about historical data we already hold? It stays where it is. This is usually a re-integration rather than a data migration: what changes is where new data lands from the switch onwards. Most teams run both in parallel while they validate, then cut over. ### Does it speak FHIR? Not natively today. Open Wearables keeps wearable data in its own standard schema, with the raw provider payloads underneath. It is not a FHIR server, and EHR-ready FHIR output is on the roadmap. In a hospital or telemedicine rollout, we map the readings to FHIR resources (Observation, Device, Provenance and Consent) and write them into your record as part of the rollout. Otherwise the mapping is work your team does against a stable schema. ### Is it running in production anywhere? Yes. Heart Monitor runs Open Wearables in production at around 90,000 monthly active users, and their own engineer did the integration in a week. [The case study](https://openwearables.io/case-study/heart-monitor) has the stack, the timeline and what it took. ### Who maintains Open Wearables? Momentum, a healthcare software development company. The project is MIT licensed and developed in the open, with a public roadmap and public issues, so the source does not depend on us continuing to fund it.