The attestation belongs to your host.
Healthcare providers and insurers in Germany may only process health data in cloud services with a C5 attestation. Run Open Wearables in your own cloud account, and that attestation is your host's.
Why it runs in your cloud
The layer has to be yours before what you build on it can be.
A hosted API keeps the data, and every score computed from it, in a vendor's account. Running the layer yourself keeps it where HIPAA, GDPR and your own policy say it belongs.
Sovereignty
Your regulator, your board or your own policy says health data does not sit in a third party's cloud.
Residency
The data has to stay in a country or region you choose, and you have to prove where it is.
Control
You run the deployment under your own credentials and decide who gets access. What you build on top of Open Wearables is yours.
Your own reasons
No regulator forcing it and no security review coming. You want the data in your own account anyway.
The short answer.
The rule sits on the cloud layer.
Healthcare providers and insurers may only process health data in cloud services that hold a current C5 attestation.
A hosted API is another cloud service.
If a vendor processes the data on its own infrastructure, that service needs an attestation of its own, and a review.
Self-hosting keeps it to one layer.
Open Wearables runs in your own cloud account, so the attestation question lands on the provider you already document.
No vendor tenant in the path.
Self-hosted, the data goes from the provider or the phone straight into your own account, in the region you chose.
Your host, your choice.
A hyperscaler's German region, a domestic provider or your own servers. The deployment goes where you already host.
The detail
Three ways to build it.
What your buyer reviews under each approach, when health data may only sit in attested cloud services.
| Hosted wearable API | Build it in-house | Open Wearables, self-hosted | |
|---|---|---|---|
| [01] Attestations in the review | Your host's and the vendor's | Your host's | Your host's |
| [02] What your buyer reviews | Two hosting postures, one you do not control | Your hosting only | Your hosting only |
| [03] The integrations | Written by the vendor | Yours to write and maintain | Already written, MIT licensed |
| [04] What it takes | A second supplier to defend | Integration work and ongoing maintenance | A deployment in your own account |
How it works in practice.
The hosting question is settled when the deployment is set up, not negotiated afterwards.
The host and the region
AWS, Azure and Google Cloud all run regions in Germany. Prefer a domestic provider? Say so early, it shapes the setup.
Inside the attested scope
An attestation lists the services and regions it covers, so the deployment uses the ones inside your provider's scope.
Credentials in your name
Provider credentials are issued to you, so the relationship with each wearable provider is yours.
Moving later
Where we set it up, the infrastructure is code in your repository, so a region change is engineering work.
The data path
Where the data goes, step by step.
Every step runs inside your deployment, in the region you chose. Nothing passes through a Momentum tenant on the way.
- 01
Collect
Cloud providers connect server to server, and the mobile SDKs read the stores that live on the phone. Every source ends up in the same deployment, in your account.
- 02
Store
Everything lands in one schema in your own database, in your German region, with the original payload kept underneath if you switch that on.
- 03
Compute
With Pro, health scores from our science team, computed inside your deployment.
- 04
Use
Your product reads it over the REST API, reacts to webhooks, or asks questions through the MCP server, all against the same deployment.
Tell us what you are building
We will tell you what it takes to run it on German infrastructure.
FAQ
Common questions.
Do you hold a C5 attestation?
No. C5 attests cloud services, so self-hosted it is your host's to hold. AWS, Azure and Google Cloud all publish one, and we run inside whichever you choose.
Is a C5 attestation mandatory?
For healthcare providers and insurers, and the processors working for them, using cloud services for health data: yes, a current C5 Type 2 attestation since July 2025, with a shorter Type 1 window for new systems. Whether that reaches your product is for your counsel.
Our buyer asks which cloud providers we use. What do we say?
The ones you chose, because the deployment is in your account. That is usually a shorter answer than naming a wearable vendor and explaining their infrastructure alongside your own.
Can we deploy on a German provider rather than a hyperscaler?
Open Wearables runs as standard containers with PostgreSQL and Redis, so a provider that runs those can host it. Tell us which one on the first call, because it shapes the setup work.
We are building a DiGA. Does this help?
It addresses the data layer, not the approval. Where your data comes from, where it sits and who can reach it are questions a DiGA submission raises, and self-hosting gives you a simpler answer to all three. It does not shorten the certification itself.
Does this apply to us if we are not selling into statutory healthcare?
Less directly, but enterprise buyers may apply the same standard. If a security review is coming, it is worth answering before it arrives.
Do you give legal advice?
No. We tell you what the architecture does. Whether a requirement reaches your product is for your counsel.