Every number traceable to the data behind it.
Open Wearables runs in your own cloud account and keeps the raw provider payload under every value, so a reviewer's question has an answer you can point at.
Built on Open Wearables
What you get
What Open Wearables gives a regulated team.
Reviewers, ethics boards and notified bodies all ask where a number came from. Open Wearables is built so the answer is a file you can open, not a vendor you have to ask.
Scores with their validation.
Scores come with what they measure and how they were validated. They are designed by our science team and computed inside your deployment.
- Validated
- Part of Pro
A pipeline you can cite.
The data pipeline is MIT-licensed open source, so how a raw payload becomes a standard value can go into a paper, a technical file or an ethics submission.
- Open pipeline
- Citable
- MIT license
Raw payloads kept.
Original provider responses are retained under the standard schema, so a value can be re-derived years later and a reviewer's question has an answer in your own database.
- Raw payloads kept
- Re-derivable
Your region, provably.
You choose where it runs when it is deployed. Where participant data sits stops being a clause you negotiate and becomes a fact you can point at.
- Your region
- eu-central-1
The boundary stays yours.
Which features exist and where they run is yours to decide, because the data layer runs inside your deployment rather than behind somebody else's roadmap.
- Your deployment
- Your scope
Credentials in your name.
Each source issues developer credentials to your organisation, so the data relationship sits between you and them, with nobody in the middle to disclose.
- Your credentials
- Your account
How it works
From protocol to first dataset.
- 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
Enrol participants.
Participants authorise through each provider's own consent screen, inside your interface, so consent is recorded where the rest of your study documentation lives.
- 04
Query the dataset.
Standardised data lands in your own database with the raw responses underneath, so analysis runs against data you hold rather than an export you requested.
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] Scoring logic | Proprietary, not published | Build and validate it yourself | Part of Pro, with what it measures and how it was validated |
| [03] Where a number came from | Ask the vendor | Whatever you documented | Source kept per value, raw payload underneath |
| [04] Where participant data sits | Their cloud, their regions | Yours | Your cloud account, your region |
| [05] Third-party risk assessment | Yours to write and defend | Not applicable | Not applicable when you run it |
| [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 algorithms stay in your account, whoever runs it.
Sovereignty
Participant 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 participant data, under your own credentials. Your analysis and your own logic are yours.
Your own reasons
Before a reviewer or a notified body asks, the raw data behind every number is in your account.
Who it is for
The teams this fits.
Two shapes, one job: produce outputs that survive somebody else's review.
Clinical AI and SaMD teams
Heading for a DiGA, CE or FDA decision, where the technical file has to explain every computation in the product.
Academic research platforms
Working under ethics approval, where the provenance of a measure has to be documented and the dataset has to outlive the grant.
Digital biomarker and endpoint developers
Where the measure is the product, so its derivation is the thing being scrutinised.
Decentralised trial teams
Collecting from participants' own devices, where provenance and completeness decide whether the data is usable.
What you can build
What teams build on it.
The data lands in your database with its origin intact, so what you build on top is analysable from day one.
A validated measure
Your own measure, built with your own logic on the data in your deployment, and documented by your team for anybody who asks.
A study dataset
Continuous data per participant with the raw responses kept underneath, so a question raised at review can be answered against what actually arrived.
A cohort view
The same measure across a study population, computed in your own database rather than exported from a vendor on their schedule.
Connect the devices your participants already own.
Every device arrives in the same schema, so participants keep the watch or ring they wear and your analysis reads one shape of data.
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 clinical service. How do we start?
With one site first: wearable data in your health records, with a source on every value, within about three months. See Open Wearables for hospitals and telemedicine.
Will you get our device certified?
No, and nobody can do that for you. We provide auditable inputs and documented validation. The clearance, the technical file and the claims are yours, and a vendor who implies otherwise is worth a second look.
Our score is not a medical device today. Does this change that?
That depends on your claims and your intended purpose, not on us. What we can say is that which features exist and where they run stays your decision, because the data layer runs inside your deployment rather than behind somebody else's roadmap.
Can we read how a score is computed?
You get what each score measures and how it was validated. The method itself belongs to our science team, and health scores are part of Pro. The data pipeline underneath is MIT licensed and readable, and your team can build its own measures on the same data.
Can we cite it in a paper?
Yes. The source is MIT licensed, so the pipeline can be referenced in a publication or an ethics submission without asking us. For a health score, you cite what it measures and how it was validated.
Is a computed score personal health data?
That is your DPO's call for your product, not ours. What we can say is that the score is computed and stored inside your own account, so whatever the answer is, the protections are yours to apply rather than a vendor's to promise.
Where does participant 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 an ethics committee is asking for.
What happens to the dataset when the grant ends?
It stays where it is, in your own account, because there is no vendor tenant holding it and no retention window set by somebody else.
Do you hold SOC 2 or ISO 27001?
No. The deployment runs inside your certified environment, which is how most teams 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.