Healthcare data residency in 2026: US/EU regions and VA hosting limits
TL;DR
Healthcare data residency in 2026 is set less by HIPAA or GDPR than by the buyer: HIPAA has no location rule, GDPR governs transfers, and the hard limits come from France, Germany, the VA and hospital IT.
- France's HDS framework requires health data hosting inside the European Economic Area, with new certificates due by May 16, 2026.
- Germany's § 393 SGB V has required a C5 Type 2 attestation for cloud processing of health data by covered providers since July 1, 2025.
- A VA memo dated July 28, 2026 says bidders no longer need FedRAMP authorization to win, yet every system still needs a VA Authorization to Operate.
- One codebase with a region-pinned tenant record and deployment automation serves US, EU and customer-hosted installs. A fork does not.
- Hosting moves the estimate through environments and evidence, so decide it before you price.
Where healthcare data residency rules come from
Start with what the two big laws do not say. HHS answers the offshore question directly in its cloud computing guidance: a covered entity may use a cloud provider that stores ePHI outside the United States, provided a business associate agreement is signed and the rest of HIPAA is met. OCR adds that risk varies by location and belongs in your risk analysis.
GDPR is about movement. Article 44 lets personal data leave the EU only under the conditions of Chapter V, and Article 9 puts health data in the special categories. Neither article names a country where the database must sit.
The location rules are national. France's HDS certification, per Microsoft's summary of the April 2024 framework, now mandates that providers locate data within the EEA, with new certificates required by May 16, 2026. Germany's § 393 SGB V lets care providers and insurers process health data in the cloud only in Germany, the EU, an equivalent state or an adequate third country, with a domestic branch and a current C5 attestation, Type 2 since July 1, 2025.
The HIPAA side of the build, from the PHI boundary to the BAAs, is in our guide to HIPAA compliant app development.
July 2026: the VA dropped FedRAMP as a bidding gate
On July 28, 2026 Zack Schwartz, the VA's Principal Deputy Assistant Secretary for Information and Technology, signed a FedRAMP and cloud procurement clarification. Solicitations shall not state or imply that existing FedRAMP certification is required for an award. The bar did not move: NIST SP 800-53 Revision 5 and a VA Authorization to Operate still apply, and providers hand over security and privacy documentation after award.
FedScoop reported that a VA ATO could be granted in 60 days. You can now win before you are authorized, so the evidence package becomes a post-award deliverable with a clock on it.
How we put this guide together
Every rule here links to a primary source read in October 2026. The patterns come from healthcare requirement records in our scoping notes, never published as counts. Any group with fewer than three data points is not published.
Mercury Development sells the work described here, so read this as an interested engineering view. We are engineers, not lawyers: take national rules to counsel.
Four hosting models at a glance
| Model | Who runs it | Where data sits | Typical trigger |
|---|---|---|---|
| Shared SaaS, one region | You | One public cloud region | US-only launch |
| Regional cells | You | One stack per jurisdiction | Selling in the US and the EU |
| Single tenant in your cloud | You, per customer | Dedicated account or subscription | Hospital security review |
| Customer hosted | Customer IT | Customer cloud tenant or data center | VA facility, hospital that bans public cloud |
Split US and EU data without forking the product
Use a cell per jurisdiction: one codebase and one release train, with a full stack in each region, logs and backups included. A thin global layer holds only what must be global, and no health data.
Three design rules make it work.
- Pin the region at tenant creation, store it with the organization record and route every request by it. Never infer it from an IP address.
- Keep logs and support tools inside the cell. A US crash reporter receiving EU stack traces with patient identifiers is a transfer under Article 44.
- Separate keys per cell. Each region holds its own encryption keys, so one cell's operators cannot read another's data.
A transfer mechanism exists for the gaps. The EU-US Data Privacy Framework adequacy decision of July 10, 2023 covers US organizations that self-certify. The General Court upheld it on September 3, 2025, and the challenger appealed to the Court of Justice on October 31, 2025, WilmerHale reported. Appeal C-703/25 P, was still pending in October 2026. An architecture that needs the DPF to function inherits that appeal.
Location is not the whole question. Under the CLOUD Act, a US provider must disclose data in its control regardless of whether it is located within or outside the United States. EU hospital buyers will ask who holds the keys, which a region setting cannot answer.
What VA cloud restrictions mean for your architecture
A device maker in our records put it plainly: the VA is "very strict with cloud and what would be in the cloud." The rule set behind that sentence is concrete. VAAR 839.101 pulls VA Handbook 6500.6 into contracts and applies it to VA information on cloud services, whether it resides on a VA or a contractor system.
Your system runs either in the VA's environment, which according to a 2021 FedScoop report relied on Microsoft Azure and Amazon Web Services, or in yours. Either way it needs a VA ATO, and the second option makes your whole stack the subject of it. The VA Inspector General estimated in 2023 that 123 of 148 systems on the VA Enterprise Cloud lacked proof of continuous monitoring,. Expect to prove monitoring.
GovCloud is mostly about who can touch the infrastructure. Microsoft says Azure Government meets FedRAMP requirements, and its service overview adds physically isolated datacenters in the US, a contractual commitment to store customer data in the US, and access to systems limited to screened US persons. AWS GovCloud (US) is administered by AWS personnel who are US citizens only. Pick it when the contract asks who can touch the infrastructure.
When a hospital says no public cloud
Hospital IT rarely bans the cloud outright. It bans your cloud. The request usually arrives as a security questionnaire, then as a demand to run inside the hospital's own tenant, where its identity provider, logging and network rules apply.
Build for that from the start. Package the system as infrastructure as code plus container images, keep each cloud service behind an interface, and make identity pluggable through SAML or OpenID Connect. Give support a way to work without production access, because in a customer-hosted install you will not have it.
Whether to run the FHIR server yourself or rent it is compared in managed vs self-hosted HIPAA hosting.
How hosting limits change your estimate
Hosting rarely changes the screens. It changes what sits around them, and that is where estimates drift.
- Environments multiply. Each region or customer-hosted install carries its own deployment, monitoring, backups and upgrade path.
- Evidence becomes a deliverable. A VA ATO package, a C5 report from your provider, architecture and data flow diagrams, an asset inventory.
- Managed services get swapped. A service missing from GovCloud or from a hospital's approved list means a replacement and a second test pass.
- Support changes shape. Without access to production, diagnostics must ship inside the product.
- Upgrades slow down. Customer IT schedules your release, so the code must tolerate older versions in the field.
Ask vendors to price these lines separately.
Where these lines sit next to the rest of the quote is covered in our guide to software project estimation.
What our requirement records show
We went through our healthcare requirement records for any constraint on where data lives or who hosts it.
In every record that named one, the constraint came from outside the product team: EU regulation, a federal buyer, the institution's own IT department, or a research partner whose recommendation would decide storage. None of those records named a cloud provider when the constraint appeared, so the hosting decision was still open while scope was being priced.
In the federal case the constraint arrived late, as an adoption objection in the decision stage, after scope had grown from a device app to a cloud backend. We had proposed a web admin console for therapist accounts, and the question became where it could run.
The university case shows the better sequence. Its program lead asked for IT to be involved early this time, while architecture and hosting were being sorted out.
Which hosting model fits your buyer
- US clinics and digital health buyers only: shared SaaS in one US region, BAA with the cloud provider.
- US and EU patients: regional cells from the first release, with logs and support tooling inside each cell.
- French or German care providers as customers: an EU cell on a provider holding HDS or a C5 Type 2 attestation, confirmed per contract.
- VA facilities: plan for a VA ATO and a deployable package, and ask early whether the system runs in VA's environment or yours.
- Hospitals with strict IT: single tenant or customer hosted, with pluggable identity and diagnostics that work without vendor access.
Design for the strictest buyer on day one
Our view: decide the hosting model before the first estimate, and build for the strictest buyer on your roadmap even if you launch with the easiest one. Region pinning, per-cell keys and an installable package are cheap in the first sprint and expensive as a retrofit.
We have shipped inside other people's walls. On EyeIC, a 510(k) cleared imaging application moved from Windows desktop to the web with HIPAA-compliant online access, and load tests set when to schedule cloud capacity expansion. On Precision Practice Management, a client-server system on MS SQL and C#.NET ran in secure data centers, and later releases moved the architecture to cloud and SaaS technologies. For HSBC we built a test server with obfuscated data that simulated the bank's environment, then integrated with its servers toward the end of the project. Our AI agent work deploys inside a customer VPC or on premises when required, and we build to HIPAA and GDPR requirements.
Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder. The requirement records and architecture notes behind this article's hosting patterns come from scoping work in the practice he leads.
Send us your target buyers and we will map the hosting model
Tell us who you sell to: US clinics, EU patients, a VA facility or a hospital with its own IT rules. We will map which hosting model each buyer forces, what has to be built once for all of them, and which lines of the estimate depend on that choice.