This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.
Why this matters
Where your patient data physically lives is no longer just an infrastructure detail — it is a legal boundary that can stop a launch, fail an audit, or trigger a fine in another country. Founders building for the US often assume "HIPAA means keep it in America," which is wrong in both directions: HIPAA does not require US storage, and HIPAA is not the only law that will apply once you cross a border. This article is for founders, product managers, and engineering leads deciding which cloud regions to run in, where to place real-time video servers, and how to store recordings and medical records for a telemedicine product that may serve more than one country. Getting the map right early is cheap; re-architecting data location after launch is not.
Three words people mix up: residency, sovereignty, localization
Most confusion in this area comes from using three different ideas as if they were one. Pull them apart and the rest gets easier.
Data residency is simply where your data physically sits — which country's data centers hold it. It is a fact about your infrastructure: "our recordings live in a Frankfurt region." Residency is a choice you make until a law takes the choice away.
Data sovereignty is whose laws govern the data because of where it is, where it came from, or who it describes. Data does not escape a country's rules just by being copied to a server elsewhere; the law of the patient's country often follows the data. Sovereignty is the reason a US company can be subject to European rules: the rule attaches to the person, not the postcode of the disk.
Data localization is the hard version — a legal requirement that certain data be kept inside a specific country or region. This is the rule that actually removes your choice of residency. Most health-privacy laws are not strict localization laws; a few are becoming so. Knowing which is which tells you whether you have a design preference or a legal constraint.
A quick analogy. Residency is which house you store a box in. Sovereignty is which country's police can knock on the door because of what is in the box or who it belongs to. Localization is a law that says the box may not leave the country at all. Throughout this article, the unit inside the box is protected health information (PHI) — any health detail tied to an identifiable person, the same definition we use across this section.
Figure 1. Residency, sovereignty, and localization are three different questions. Mixing them up is the root of most data-location mistakes.
The HIPAA answer: safeguards, not borders
Start with the rule most US telemedicine teams already live under, because its answer surprises people. HIPAA does not require protected health information to stay inside the United States.
The clearest statement comes from the Office for Civil Rights — the part of the US Department of Health and Human Services that enforces HIPAA — in its official guidance on HIPAA and cloud computing. Asked directly whether a covered entity may use a cloud provider that stores patient data on servers outside the US, the guidance answers: "Yes, provided the covered entity (or business associate) enters into a business associate agreement (BAA) with the [cloud service provider] and otherwise complies with the applicable requirements of the HIPAA Rules." HIPAA is a safeguards law, not a geography law.
There is an important "but" in the same guidance. The Office for Civil Rights adds that the risks to that data "may vary greatly depending on its geographic location," that storing it overseas "may increase the risks and vulnerabilities to the information or present special considerations with respect to enforceability of privacy and security protections," and that you must account for this in the risk analysis the HIPAA Security Rule already requires (45 CFR §164.308(a)(1)(ii)(A)). In plain terms: you may store PHI abroad, but you must be able to show you thought about whether that location is safe and whether your protections are actually enforceable there.
Two things carry the weight here, and neither is the map. The first is the Business Associate Agreement (BAA) — the contract that lets an outside vendor handle patient data and binds it to HIPAA's rules. Remember the rule we repeat across this section: a vendor either has a signed BAA covering your use of patient data or it does not, and "encrypted" is never the same as "compliant." A cloud provider holding your data is a business associate and needs a BAA even if it only stores encrypted data it cannot read. The second is your risk analysis — the documented assessment of threats to the data. Location is one input to that analysis, not a separate rulebook.
So for a US-only telemedicine product, the honest summary is: keep the safeguards strong and the BAAs signed, and you have wide latitude on region. Most teams still choose US regions — for latency, for customer expectations, and to keep the enforceability question simple — but that is a design decision, not a HIPAA command.
The catch: other countries' rules travel with the patient
The simplicity ends the instant a patient sits in another country, because that country's law can attach to their data and follow it wherever you move it. This is sovereignty in action, and the European Union is the example everyone meets first.
The EU's privacy law — the General Data Protection Regulation (GDPR), Regulation (EU) 2016/679 — treats health data as a special category that gets the strongest protection (Article 9). You generally cannot process it at all without a specific legal basis, such as the patient's explicit consent or the provision of healthcare. That is before location even enters the picture.
Location enters through Chapter V of the GDPR, which governs sending personal data outside the EU (a "transfer to a third country"). The rule is not "you may never send it abroad"; it is "you may only send it abroad through one of a few approved channels." There are three you will actually use:
| Transfer mechanism | What it is | When you use it | Effort |
|---|---|---|---|
| Adequacy decision (Art. 45) | The EU has formally judged a country's protection "adequate," so data flows freely | The destination country (or framework) is on the EU's approved list | Lowest — treat like an EU-internal transfer |
| Standard Contractual Clauses / Binding Corporate Rules (Art. 46) | Pre-approved contract terms (SCCs) or internal group rules (BCRs) that carry GDPR protection to the destination | The destination is not adequate, but you can contract for protection and assess the local legal risk | Medium — sign SCCs and run a transfer impact assessment |
| Derogations (Art. 49) | Narrow exceptions, e.g. the patient's explicit consent to the specific transfer | One-off or exceptional transfers with no other channel available | High caveats — not a basis for routine, bulk transfers |
Figure 2. Walk the GDPR transfer decision top to bottom: adequacy first, then Standard Contractual Clauses with an assessment, then a narrow derogation — otherwise keep the data in-region.
For transfers to the United States specifically, there is a current adequacy route: the EU-US Data Privacy Framework (DPF), an adequacy decision adopted in July 2023 under which a US company can self-certify and then receive EU data much like an EU-internal transfer. Treat it as real but watch it: an annulment challenge (the Latombe case) was dismissed by the EU's General Court on 3 September 2025, which upheld the framework — but that ruling has been appealed to the EU's top court, so the framework's long-term stability is not guaranteed. The engineering lesson is to keep a fallback: many teams sign Standard Contractual Clauses in addition to relying on the DPF, so that if adequacy is struck down, the data flow does not stop overnight. The deep treatment of GDPR, Canada's law, and the rest of the world lives in our global health-data law article; here the point is narrower — these rules decide where the data may live and travel, and that decision lands directly in your architecture.
Canada works on a different principle worth knowing. Its federal private-sector law, PIPEDA, follows an accountability model: it does not forbid sending personal data abroad, but the organization stays responsible for protecting it through comparable contractual safeguards wherever it goes. Quebec's Law 25 is stricter, requiring a privacy impact assessment before personal data leaves the province. Same pattern as the EU at a higher level: not "never," but "only with protection and assessment."
Sovereignty's hard edge: when the law actually pins data to a region
Some regimes have crossed from "transfer with safeguards" into genuine localization — the data must physically stay in-region. For a telemedicine architecture, these are the rules that remove your choice and force a regional deployment.
The sharpest current example is France. A decree of 24 March 2026 ties into France's health-data hosting certification (known as "HDS," for Hébergeur de Données de Santé) and introduces a requirement that certified health data be hosted exclusively within the European Economic Area (EEA), with the sovereignty provisions taking effect in September 2026. Hosting providers must also publish a map of any transfers outside the EEA and the associated access risks. If you host French patients' health data, "we'll put it in our US region" stops being an option. (This is a fast-moving rule read partly through legal-firm summaries — confirm the current text with French counsel before you rely on it.)
Layered on top of the EU regime is the European Health Data Space (EHDS) — Regulation (EU) 2025/327, which entered into force in March 2025. The EHDS builds an EU-wide framework for using health data both for direct care ("primary use") and for research and policy ("secondary use"), with its own infrastructure and governance and a phased rollout in which most secondary-use provisions apply around 2029. It does not replace the GDPR; it adds a health-specific layer with its own residency and access expectations. If your roadmap includes the EU, the EHDS is the regime to track even though its biggest obligations are a few years out.
Many countries outside our main scope run their own localization rules for health or personal data, which is why a global telehealth product cannot assume one region fits all. The table below is a planning orientation, not legal advice — the controlling detail is always the current rule in the patient's jurisdiction.
| Jurisdiction | Governing rule | Must health data stay in-region? | Practical implication for placement |
|---|---|---|---|
| United States | HIPAA (45 CFR Parts 160/164) | No — safeguards + BAA, location is a risk-analysis input | Region is your choice; most teams pick US regions anyway |
| European Union (general) | GDPR (Reg. (EU) 2016/679) | Not strictly, but transfers out need an Art. 45/46/49 channel | Prefer an EU region; keep SCCs as a DPF fallback |
| France | HDS framework + 24 Mar 2026 decree | Yes — EEA-only hosting from Sept 2026 | A dedicated EEA region for French patients |
| Canada | PIPEDA (federal); Quebec Law 25 | No federally; Quebec needs a transfer assessment | Contractual safeguards; assess before moving out of Quebec |
| EU (health-specific) | EHDS (Reg. (EU) 2025/327) | Adds a health-data layer; major duties ~2029 | Track for roadmap; design for EU governance |
Where this lands in your architecture
All of this becomes concrete in four places in a telemedicine platform, and they do not all carry the same residency weight. The trick is to separate data that moves through a region from data that lives in one.
Real-time video and audio is mostly transient. During a live consultation, media flows from the patient through a media server — in WebRTC architectures, a Selective Forwarding Unit (SFU), the server that receives each participant's stream and forwards it to the others — and out to the clinician. That media is in motion, not at rest; it is held only momentarily to be relayed. From a residency standpoint, the live stream is the lighter-weight part, but its path still matters: routing a European patient's call through a US media server means their data transits US infrastructure, which a strict regime may treat as a transfer. The fix is regional media routing — placing an SFU in the patient's region so the call stays local — which also happens to cut latency. We cover the scaling and routing mechanics in scaling clinical video across regions.
Recordings, records, and backups are persistent — and they are where residency bites. A saved consultation recording, the clinical notes written during the visit, the medical-record data you store, and every backup and disaster-recovery copy are data at rest. These are the assets a localization rule actually pins to a region. A common and costly mistake is to route live video regionally but quietly ship all recordings and backups to a single home-region bucket — re-creating the exact cross-border transfer you avoided in the call. Backups count. Replicas count. Analytics exports count.
The design principle is to place at-rest PHI by the patient's governing region and keep the transient media path in that region too, while letting region-agnostic, non-PHI parts of your platform (marketing site, de-identified product analytics, the application code itself) run wherever is convenient. Remember that de-identified data — stripped of identifiers under the rules — is no longer PHI and falls outside these residency constraints, which is exactly why proper de-identification is such a useful pressure valve for analytics.
Figure 3. Keep the live media path and all at-rest PHI inside the patient's region; let non-PHI services run anywhere. Backups and analytics exports are at-rest data — they count.
One platform, many regimes: the segmentation pattern
You do not need a separate company per country, and you should not duplicate your entire platform per region. The workable pattern is one global control plane, several regional data planes.
The control plane is the part with no PHI in it: your application code, deployment pipeline, feature flags, and the routing logic that decides — based on the patient's jurisdiction — which regional data plane handles their visit. Each data plane is a region (a US region, an EU region, and so on) that holds the PHI for patients governed by that region's rules: its own media servers, its own recording and record storage, its own backups, all inside a per-region compliance boundary with the right contracts for that jurisdiction.
The single most important engineering decision in this pattern is the routing key: how you determine, at sign-up or scheduling, which regime governs a patient, and therefore which data plane they belong to. Usually it is the patient's location and the provider's jurisdiction, not the patient's nationality or where they happen to be travelling. Get this classification right and the rest is plumbing; get it wrong and you have PHI in the wrong region with the wrong contracts — a residency violation that no amount of encryption fixes.
Let me make the cost concrete, because regional duplication is not free. Suppose your single-region setup runs media servers, recording storage, and backups at a baseline monthly infrastructure cost. Adding a second region to serve EU patients roughly duplicates the data-plane pieces — call it the media, storage, and backup tier — while the shared control plane is not duplicated. If the data plane is, say, 60% of your infrastructure cost:
Second region added cost ≈ 60% of one region's data-plane cost
Two regions ≈ 1 region + 0.6 region (data plane only) = 1.6× baseline, not 2×
The lesson is not the exact multiplier — it depends entirely on your stack — but the shape: you pay mainly to duplicate the PHI-holding data plane, not the whole platform, which is the financial argument for keeping as much as possible region-agnostic and out of the PHI boundary. Open a region when a real obligation (French patients, an EU customer) requires it, not speculatively.
Common mistakes
A short gallery of the data-residency errors we see most in telemedicine builds, each avoidable:
- Believing "HIPAA requires US storage." It does not — it requires safeguards and a BAA. The real constraints abroad come from other countries' laws, not HIPAA.
- Treating residency as one problem instead of three. Decide separately: where data sits (residency), whose law applies (sovereignty), and whether a law forces in-region storage (localization).
- Routing live video regionally but shipping recordings and backups home. At-rest copies are exactly what localization rules pin. A regional call with a US backup is still a cross-border transfer.
- Relying on the EU-US Data Privacy Framework with no fallback. It is valid today but under appeal — sign Standard Contractual Clauses alongside it so a future ruling does not halt your data flow.
- Routing by nationality or current travel location. The governing regime usually follows the patient's place of care and the provider's jurisdiction, not a passport.
- Forgetting that vendors have residency too. Your transcription, analytics, recording, and storage sub-processors must also keep regional PHI in-region and hold the right contract — a BAA in the US, GDPR-compliant terms in the EU.
Where Fora Soft fits in
Telemedicine is one of the verticals Fora Soft has built since 2005, alongside video conferencing, streaming, e-learning, and surveillance, and data residency is where our real-time-video work meets the compliance layer most directly. We design the data map around the requirement first — HIPAA's safeguards-and-BAA stance under the Security Rule risk analysis, the GDPR transfer rules and the DPF's uncertain status, France's EEA-only hosting rule, and the EHDS on the horizon — then place media routing, recording storage, and backups so each patient's data lives where the strictest applicable rule says it must. In practice that means a regional media path for latency and residency at once, per-region at-rest storage with the right contracts, and a clean routing key that classifies each patient's governing regime. The goal is one platform an auditor in any of your markets can sign off on, without a separate build per country.
What to read next
- GDPR, PIPEDA, and global health-data law — the full cross-border legal map.
- Scaling clinical video across regions and surges — the media-routing mechanics behind regional placement.
- The telemedicine video reference architecture — how the per-region data plane fits the whole platform.
Call to action
- Talk to a telemedicine engineer — book a 30-minute scoping call to talk through your telemedicine data residency plan.
- See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
- Download the Data Residency & PHI Location Decision Worksheet — One page, two columns: classifying each patient's governing regime (HIPAA, GDPR, France HDS, Canada), separating residency from sovereignty from localization, and placing media routing, recordings, records, and backups in the right….
References
- HHS Office for Civil Rights, Guidance on HIPAA & Cloud Computing, Q9 (servers outside the United States) and Q1/Q2/Q3 (cloud providers are business associates; BAA required) — confirms HIPAA permits overseas storage of ePHI with a BAA and risk analysis; location is a risk factor, not a prohibition. https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html (Tier 1 — agency guidance)
- 45 CFR §164.308(a)(1)(ii)(A), Risk analysis (HIPAA Security Rule) — requires assessment of risks to all ePHI, the standard into which geographic location feeds. https://www.ecfr.gov/current/title-45/section-164.308 (Tier 1 — CFR)
- 45 CFR §164.502(e) and §164.308(b), Business associate contracts — a cloud provider maintaining ePHI is a business associate and requires a BAA regardless of location. https://www.ecfr.gov/current/title-45/section-164.502 (Tier 1 — CFR)
- Regulation (EU) 2016/679 (GDPR), Article 9 (special-category health data) and Chapter V, Articles 44–49 (transfers to third countries: adequacy, safeguards/SCCs/BCRs, derogations). https://eur-lex.europa.eu/eli/reg/2016/679/oj (Tier 1 — EU regulation)
- European Commission, Adequacy decision for the EU-US Data Privacy Framework (adopted 10 July 2023) — the self-certification route for EU→US transfers. https://commission.europa.eu/document/fa09cbad-dd7d-4684-ae60-be03fcb0fddf_en (Tier 1 — EU decision)
- General Court of the EU, Latombe v Commission (T-553/23), judgment of 3 September 2025 dismissing the annulment action and upholding the DPF; appeal pending before the Court of Justice. https://curia.europa.eu/ (Tier 2 — court ruling / press summary)
- Regulation (EU) 2025/327, European Health Data Space (EHDS) — entered into force March 2025; primary- and secondary-use framework with phased application toward 2029. https://eur-lex.europa.eu/eli/reg/2025/327/oj (Tier 1 — EU regulation)
- France, decree of 24 March 2026 on health-data hosting (HDS) and sovereignty — EEA-only hosting requirement effective September 2026 (read via legal-firm summaries; confirm against the published decree). https://www.insideprivacy.com/health-privacy/france-publishes-updated-certification-standard-for-the-hosting-of-health-data/ (Tier 3 — legal-firm analysis of a primary decree; flagged for verification)
- Office of the Privacy Commissioner of Canada, Guidelines for processing personal data across borders (PIPEDA accountability model) — transfers abroad permitted with comparable protection; organization remains accountable. https://www.priv.gc.ca/en/privacy-topics/airports-and-borders/gl_dab_090127/ (Tier 1 — regulator guidance)
- Commission d'accès à l'information du Québec / Law 25 — privacy impact assessment required before transferring personal data outside Quebec. https://www.cai.gouv.qc.ca/ (Tier 2 — regulator)
Where popular guidance disagreed with the rule, the rule won. Many vendor pages and listicles assert that "HIPAA requires PHI to be stored in the United States"; the controlling HHS Cloud Computing guidance (Tier 1, ref 1) states the opposite — overseas storage is permitted with a BAA and a risk analysis. The France EEA-only requirement (ref 8) is read through legal-firm summaries of a recent decree and is flagged for verification against the published text.
