The data layer under your monitoring platform.
You are building what the clinician looks at. Open Wearables is the wearable data underneath it, running in your own cloud account, so readings from a patient's own device land in your database rather than somebody else's.
Built on Open Wearables
What you get
What Open Wearables gives a monitoring team.
Consumer wearables authorise differently and each returns its own shape. Open Wearables absorbs that inside infrastructure you own, so every reading a clinician acts on has a known origin.
A reading you can trace.
Every value keeps the provider it came from and the raw response it arrived in, so when a clinician asks where a number came from, the answer is in your own database.
- Source per reading
- Provenance kept
One schema, next to the chart.
Query a patient, not a provider. Activity, sleep, heart rate and body measurements in one shape, joinable with the record your platform already holds.
- One schema
- Time series
- Webhooks
Raw payloads kept.
Original provider responses are retained under the standard schema, so a reading can be re-examined later 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. Where patient data sits stops being a clause you negotiate and becomes a fact you can point at.
- Your region
- eu-central-1
Access you control.
It runs in your cloud account, under your credentials, so patient data does not reach a vendor tenant. When we work on your system, we do it under a DPA you sign.
- Your account
- Your credentials
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 reading.
- 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.
Patients 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 putting last night's readings in front of a clinician is a query rather than an integration project.
See 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] Where patient data sits | Their cloud, their regions | Yours | Your cloud account, your region |
| [03] 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 |
| [04] Where a reading came from | Normalised, provenance varies | Whatever you built | Source kept per reading |
| [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 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 patient data, under your own credentials. What you build on top of Open Wearables is yours.
Your own reasons
Before a regulator or a health system asks, the record and its provenance sit in your account.
Who it is for
The monitoring products this fits.
This page is written for the team building the platform, not for the clinic buying one. These are the shapes where owning the data layer changes the deal.
Remote monitoring platforms
You sell to health systems and insurers, whose security review reaches every vendor behind you.
Chronic care and disease management
Months of continuous data per patient, where the history is the product and a retention window set by somebody else is a risk.
Digital therapeutics
The data feeding an intervention has to be traceable, because the evidence behind the product depends on it.
Telemedicine platforms
You deliver care on behalf of a controller, so their rules on where patient data sits reach your vendor choices.
What you can build
What teams build on it.
The data arrives in the background, so what the clinician opens is already current.
A clinician view
Last night's readings next to the history your platform already holds, with the device each value came from shown alongside it.
Alerts your clinicians define
A resting heart rate or a sleep pattern that crosses a threshold your team sets, raised in your own platform rather than a vendor's dashboard.
Adherence at a glance
Which enrolled patients are syncing and which have gone quiet, so a care team follows up before a gap becomes a missed week.
Connect the devices your patients already own.
Each connected source arrives in the same schema, so a patient who switches watch or adds a ring changes nothing in your code.
Care and clinical
Two paths for care providers, hospitals and telemedicine platforms
Care providers, hospitals and telemedicine platforms run the same platform, set up for their patients, their team and their records.
Care providers and programmes
Continuous remote monitoring for care programmes, clinics and senior care: a patient app, a view for your care team and support.
Learn moreHospitals and telemedicine
Wearable data in your patients' app and in your health records, with a source on every value and an SLA per site.
Learn more
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.
FAQ
Do you have more questions?
We run a care programme. How do we start?
Open Wearables for care providers covers it, from the first cohort to the whole programme: a patient app, a view for your care team and support. See Open Wearables for care providers.
Is this a remote patient monitoring platform?
No. It is the wearable data layer underneath one. If you are a clinic looking for a monitoring service to buy, this is not that. If you are building the platform, this is the part that connects the devices and standardises what comes back.
Does it work with clinical-grade devices?
It connects the consumer wearables patients already own, through each provider's own API or on-device SDK. Regulated devices with their own certified pipelines are a separate question, and the honest answer depends on the device and what its maker exposes.
Our health system customer's security review asks who can reach patient data. What do we say?
Your team. It runs in your cloud account, under your credentials, so patient 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 covers both.
Where does patient data physically live?
In the cloud account and region you choose at deployment. You can point at the account rather than describing a policy.
Can we use this for a HIPAA workload?
The deployment runs on your infrastructure, so access, encryption, retention and audit logging are yours to control and to evidence. A BAA depends on your cloud provider and your scope.
Can a clinician see where a reading came from?
Yes. The provider each value came from is kept with the value, and the original payload is retained underneath, so provenance is a property of the record rather than something reconstructed later.
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.
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, at consumer app scale, with the deployment running in the adopter's own infrastructure. Customers has the named adopters and what each of them built.
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.