--- title: "Health Data Residency in Singapore" description: "Public health sector contracts can bar a vendor from processing data outside Singapore. What that means for a hosted wearable API, and what self-hosting changes." canonical_url: "https://openwearables.io/data-residency/singapore" --- # When the contract bars offshore processing. Data residency ยท Singapore Some public healthcare contracts in Singapore can bar a vendor from processing data abroad. Open Wearables runs in your own account, in a Singapore region, so nothing is processed abroad. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book) 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. ### Contractual, not statutory. The bar comes from public health sector agreements, which require written approval before a vendor processes data abroad. ### It binds the vendor. The clause is about who processes the data, so the fix is taking the vendor out of the data path, not moving the data. ### Self-hosting removes the question. Open Wearables runs in your own cloud account, in a Singapore region. Nothing is processed outside Singapore, so there is nothing to approve. ### 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. ### Provable rather than promised. You evidence residency by pointing at your own cloud account, not at a vendor's policy page or a contract clause. The detail ## Three ways to build it. What each approach looks like under a clause that bars a vendor from processing data abroad. | | Hosted wearable API | Build it in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Who processes the data | The vendor, wherever its servers are | You | You, in your own account | | [02] Under the clause | Approval needed wherever the vendor processes outside Singapore | Works | Works | | [03] The integrations | Written by the vendor | Yours to write and maintain | Already written, MIT licensed | | [04] What it takes | An approval step, if its servers are abroad | Integration work and ongoing maintenance | A deployment in your own account | ## How it works in practice. Residency is settled when the deployment is set up, not negotiated afterwards. ### The cloud and the region You choose both, in the account you already have. AWS, Azure and Google Cloud all run Singapore regions. ### Credentials in your name Provider credentials are issued to you, so the relationship with each wearable provider is yours. ### In writing When we set up the deployment for you, the cloud account and the region it runs in are stated in writing. ### 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. [See the platform](https://openwearables.io/platform) 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 Singapore 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 in a Singapore region. [Book a call](https://openwearables.io/book) FAQ ## Common questions. ### Does this clause apply to us? It appears in public health sector agreements in Singapore. If you sell into that side of the market, your own contract will say. If you do not, your customers may still ask for the same standard. ### Could we just ask for written approval? You could. It adds an approval step to your timeline and a dependency you do not control. Taking the vendor out of the data path avoids the question rather than answering it. ### Is there a law that keeps health data in Singapore? The bar on this page is contractual. Singapore's general data protection law allows transfers abroad under conditions, and health-specific legislation is changing, so what applies to you is a question for your counsel. ### Which Singapore regions can we deploy in? AWS, Azure and Google Cloud all run regions in Singapore, so whichever you use. The deployment goes into your account rather than ours. ### We also sell into the UK. Is that a different answer? Often a similar one. NHS-facing buyers usually ask who can reach the data, and the answer is the same: it runs in your cloud account, under your credentials, and when we work on your system, we do it under a DPA you sign. [More for health data platforms](https://openwearables.io/for/health-data-platforms). ### Do you give legal advice? No. We tell you what the architecture does. Whether a clause reaches your contract is for your counsel.