Beyond HIPAA: GDPR, PIPEDA, and Global Health-Data Law

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

The moment your telemedicine product enrolls its first patient in Toronto, London, or Berlin, HIPAA stops being the rulebook — and the rules that replace it are stricter in some places, looser in others, and differently shaped almost everywhere. Teams that treat "HIPAA-compliant" as a worldwide pass discover the gaps at the worst time: during an enterprise procurement review, a regulator's questionnaire, or a 72-hour breach clock they thought was 60 days. This article is for founders, product managers, and compliance leads planning a launch outside the US — or selling a US-built platform to a buyer with European or Canadian users. It maps the regimes that matter (GDPR, UK GDPR, PIPEDA and the provincial acts, plus a tour of Brazil, India, Australia, and Switzerland), translates each into product decisions, and ends with the architecture pattern that satisfies several regimes from one codebase.

One product, many rulebooks: sectoral vs omnibus law

HIPAA is a sectoral law. It applies to a defined cast — health plans, clearinghouses, providers who bill electronically (covered entities), and the vendors who handle patient data for them (business associates) — and to one data type, protected health information (PHI). If you are outside that cast, HIPAA simply does not see you. The full mechanics are in our HIPAA overview.

Most of the world took the opposite path: one omnibus law that covers every organization processing any personal data, with health data flagged as a category deserving extra protection. The GDPR calls it "special category" data (Article 9); Canada's federal law treats health information as sensitive, demanding the highest level of consent and safeguards; Brazil's LGPD calls it "sensitive personal data" (Article 11). The law follows the data, not the industry.

That single design difference explains most of the surprises ahead. Under an omnibus law there is no "we're just a tech vendor" escape hatch — a video platform, an analytics tool, and a hospital are all regulated, just in different roles. There is also no equivalent of HIPAA's "not a covered entity, not my problem" wellness-app gap: a consumer symptom tracker that never touches a doctor is fully regulated in the EU and Canada. And because the law is general-purpose, the health-specific detail often lives one level down — in member-state law, provincial acts, or sector codes layered on top.

Figure 1. One product, four rulebooks. The same telemedicine platform answers to a different law — with different contracts, clocks, and hosting rules — in each market.

Two vocabulary shifts will save you confusion in every meeting that follows. First, GDPR-family laws speak of controllers (who decides why and how data is processed — usually the clinic or the telehealth operator) and processors (who handles data on the controller's instructions — usually you, the platform, and your cloud). Second, "PHI" is a HIPAA term; in Europe you will say personal data and data concerning health — defined in GDPR Article 4(15) as personal data relating to a person's physical or mental health that reveals information about their health status. The category is broad on purpose: an appointment booking with a dermatologist reveals health information, exactly as the fact of being a patient is PHI under HIPAA.

GDPR: the two locks on health data

Think of processing health data under GDPR as a door with two locks. The first lock is Article 6: every act of processing any personal data needs one of six lawful bases — consent, contract, legal obligation, vital interests, public task, or legitimate interests. The second lock is Article 9: for health data, processing is prohibited by default (Article 9(1)), and you must also fit one of the ten exceptions in Article 9(2). Both locks must open. A lawful basis without an Article 9 condition — or the reverse — is not compliance.

For a telemedicine product, two Article 9(2) conditions do nearly all the work:

Article 9(2)(h) — provision of care. Processing "necessary for medical diagnosis, the provision of health or social care or treatment or the management of health or social care systems" is permitted, on the basis of EU or member-state law or a contract with a health professional. There is a catch that shapes your architecture: Article 9(3) requires the data to be processed "by or under the responsibility of" a professional bound by professional secrecy, or another person under an equivalent secrecy duty. In practice the consultation itself, the clinical notes, and the prescription ride on 9(2)(h) — and your staff who can touch that data need contractual secrecy obligations.

Article 9(2)(a) — explicit consent. The patient explicitly consents to processing for specified purposes. This is the condition for everything beyond care: optional recordings, research, marketing, secondary analytics on identifiable data. GDPR consent is a high bar — freely given, specific, informed, unambiguous, and withdrawable at any time (Article 7). Build the withdrawal path before you build the feature.

Here is the trap most US-built products walk into: they bolt a consent checkbox onto everything, because consent feels like the safe choice. It is the fragile choice. If your only legal footing for storing clinical records is consent, a patient who withdraws it can demand the processing stop — awkward when a member-state law obliges the clinic to retain records for a decade or more. The sturdy pattern is 9(2)(h) for care, legal-obligation grounds for mandated retention, and explicit consent reserved for the truly optional. The same logic governs recordings, which our consent and retention article covers for the US side.

Figure 2. Both locks must open. The care pathway rides Article 9(2)(h) with the Article 9(3) secrecy safeguard; explicit consent under 9(2)(a) is reserved for what is truly optional.

The DPA: GDPR's answer to the BAA

HIPAA's Business Associate Agreement has a direct GDPR cousin: the data processing agreement (DPA) required by Article 28(3) whenever a processor handles personal data for a controller. Like a BAA, it is non-negotiable plumbing: written terms binding the processor to documented instructions, confidentiality, security measures, sub-processor approval, breach assistance, and deletion or return of data at contract end. Unlike a BAA, it covers all personal data, not just health data — and it must name sub-processors and flow the same duties down the chain (the BAA article maps the HIPAA side). If you sell into the EU as a platform, you are the processor and your customer will hand you their DPA; every cloud, CPaaS, transcription, and analytics vendor under you needs one too, plus a transfer mechanism if they process outside the EU (next section).

Three more GDPR mechanisms have no HIPAA equivalent and routinely surprise US teams:

• DPIA — data protection impact assessment (Article 35). A documented risk analysis, mandatory before "large scale" processing of special-category data (Article 35(3)(b)). A telemedicine platform launch is a textbook trigger. Budget 2–4 weeks of structured work, not a checkbox.
• DPO — data protection officer (Article 37). Mandatory where core activities involve large-scale processing of special categories (Article 37(1)(c)). Most telehealth operators — and many platform vendors — need one; the role can be outsourced.
• EU representative (Article 27). A non-EU company offering services to people in the EU (the extraterritorial reach of Article 3(2)) must appoint a representative inside the EU as the regulator's local contact. A US telehealth startup serving German patients needs one even with zero EU offices.

Patient rights and the 72-hour clock

GDPR grants data subjects rights HIPAA does not: erasure (Article 17), portability in machine-readable form (Article 20), and objection (Article 21), alongside access and rectification. In a clinical context erasure is qualified — Article 17(3) preserves processing needed for health purposes under 9(2)(h) and for legal obligations like record-retention laws — but the request still must be handled, answered within a month, and logged. Your data model needs per-purpose deletion: wipe the marketing profile and the optional recording, retain the medical record, and prove which is which.

Breach notification is where the clocks diverge dramatically. Walk the arithmetic once:

Your SFU recording bucket is found exposed on a Friday at 18:00. GDPR (Article 33): notify the supervisory authority without undue delay and within 72 hours of awareness → deadline Monday 18:00, weekend included. High-risk breaches also go to the affected patients (Article 34). HIPAA (45 CFR §164.404): notify affected individuals without unreasonable delay, at the latest 60 days after discovery → Friday June 12 discovery means an August 11 outer limit. 72 hours vs 60 days·24 hours = 1,440 hours — the GDPR clock is 20× shorter. Your incident runbook must be written for the shortest clock you operate under.

Penalties scale differently too. Article 83(5) puts violations of the Article 9 rules in the top fine tier: up to €20 million or 4% of total worldwide annual turnover, whichever is higher. For a $50M-revenue company, 4% is 0.04 × $50,000,000 = $2,000,000 — and the floor of the tier is €20M, so the theoretical maximum exposure is €20M. Real enforcement is calibrated but not hypothetical: France's CNIL fined Dedalus Biologie, a medical-lab software vendor, €1.5 million in 2022 after a migration error exposed the records of nearly 500,000 patients — citing, among others, Article 28 (no proper DPA terms) and Article 32 (security).

A common mistake: the two GDPR myths

Myth 1 — "GDPR means asking consent for everything." As above: consent is one condition of ten, and the wrong one for the care pathway. Regulators have fined companies for relying on consent where it could not be freely given.

Myth 2 — "GDPR requires storing data in the EU." GDPR contains no data-localization rule. Chapter V (Articles 44–49) regulates transfers out of the EEA and gives you legal routes to make them. The localization rules that do exist are national and sectoral — France's HDS regime is the loudest example — or belong to other laws entirely (Russia's localization statute, India's pending sector rules). Conflating "GDPR" with "EU hosting required" leads teams to over-build in some markets and under-build in France.

Data residency and cross-border transfers

So how does an EU patient's video consult legally touch a US cloud? Chapter V offers three working routes, in descending order of comfort:

Route 1 — adequacy (Article 45). The European Commission declares a destination country "adequate," and data flows as if inside the EU. The EU–US Data Privacy Framework (DPF) is the adequacy decision for the US (July 2023): transfers to US companies certified under the DPF need no further mechanism. Status as of June 2026: the EU General Court dismissed the first annulment challenge (Latombe, T-553/23) on 3 September 2025; an appeal is pending at the Court of Justice (C-703/25 P). After two predecessor frameworks died in court (Schrems I and II), prudent teams treat the DPF as valid but keep SCCs as a documented fallback. Other adequacy decisions cover the UK, Switzerland, Japan, South Korea, Canada (commercial organizations under PIPEDA) — and, since 26 January 2026, Brazil, the first mutual EU adequacy.

Route 2 — Standard Contractual Clauses (Article 46(2)(c)). The Commission's 2021 model contract (Implementing Decision (EU) 2021/914) signed between exporter and importer, plus — since the Schrems II judgment (C-311/18, 2020) — a documented transfer impact assessment (TIA) of the destination's surveillance law and any supplementary measures (encryption with EU-held keys is the classic one). This is the workhorse for vendors not on the DPF list.

Route 3 — keep it in-region. No transfer, no transfer problem. Every major cloud offers EEA regions; the residency engineering — region pinning, key location, support-access boundaries — is its own discipline, covered in our data-residency article.

Figure 3. Three legal routes out of the EEA — and the French branch where routes 1 and 2 stop working for hosting.

Then comes the national layer GDPR explicitly permits (Article 9(4): member states may add conditions for health data). The sharpest example is France. Hosting health data collected in French care pathways requires a state-certified HDS (hébergeur de données de santé) hosting provider under Public Health Code Article L.1111-8. The regime was tightened twice recently: certified hosts must migrate to the HDS V2 certification standard by 16 May 2026, and a decree of 24 March 2026 adds sovereignty obligations — health data under HDS must be hosted exclusively within the European Economic Area from September 2026, with any remote access from outside the EEA disclosed and safeguarded. AWS, Microsoft Azure, Google Cloud, and OVHcloud hold HDS certification for specific services; your French deployment must sit on those services and your architecture must prove the EEA boundary. Germany layers its own controls: statutory health insurance, digital health apps (the DiGA reimbursement scheme), and telematics-infrastructure integrations carry BSI-grade security requirements and effectively expect EU processing.

One more EU development belongs on your radar rather than your backlog: the European Health Data Space (EHDS, Regulation (EU) 2025/327), in force since 26 March 2025 and applying in stages — general application from March 2027, the first cross-border exchange categories (patient summaries, e-prescriptions) and most secondary-use rules from around March 2029, with imaging and lab results following by 2031. For an EHR-adjacent telemedicine product it will eventually standardize record formats and unlock cross-border interoperability; for now it means EU buyers will start asking about EHR-system conformance years before the deadlines bite.

The United Kingdom: same skeleton, its own keys

Post-Brexit Britain kept the GDPR structure: the UK GDPR plus the Data Protection Act 2018 (DPA 2018), supervised by the Information Commissioner's Office (ICO). Article 9's two-lock logic, DPAs, DPIAs, the 72-hour clock, and fines up to £17.5M or 4% all carry over. Health data conditions live in DPA 2018 Schedule 1, and the EU currently recognizes the UK as adequate, so EU↔UK flows are unconstrained.

The first divergence arrived with the Data (Use and Access) Act 2025 (DUAA, 2025 c. 18), in law since 19 June 2025. For health-tech builders the relevant edits are pragmatic: a new "recognised legitimate interests" lawful basis for a short list of purposes, looser rules for broad-consent scientific research, and a clarified automated-decision-making regime (meaningful human involvement, new Article 22A). Nothing in DUAA loosens the special-category rules for health data — your Article 9 analysis stands.

What actually gates a UK health deal is rarely the statute — it is NHS process. Two artifacts come up in nearly every procurement. The Data Security and Protection Toolkit (DSPT) is the annual self-assessment any organization touching NHS patient data must complete; since the 2024–25 cycle it is aligned to the National Cyber Security Centre's Cyber Assessment Framework, and the 2025–26 edition adds mandatory independent audits for the largest organization categories. The DTAC (Digital Technology Assessment Criteria) is the NHS's procurement gate for digital health products — clinical safety (DCB0129/0160), data protection, security, interoperability, and usability evidence bundled into one reviewable package. Treat DSPT and DTAC readiness as engineering deliverables with owners and dates, not paperwork to backfill after the pilot is won.

Canada: a federation of privacy laws

Canada looks deceptively simple from the US — one neighbor, one law? In practice you will navigate three layers.

Layer 1 — PIPEDA, the federal Personal Information Protection and Electronic Documents Act, covers commercial activity. It is principles-based: ten fair-information principles rather than prescriptive articles. Health information is consistently treated as sensitive, which under PIPEDA's consent framework means express consent (not implied) for most collection and sharing, plus safeguards proportionate to sensitivity. Breach rules differ from both GDPR and HIPAA: report to the Privacy Commissioner and notify individuals "as soon as feasible" whenever a breach creates a real risk of significant harm (RROSH) — no fixed hour count, and a mandatory internal record of every breach, reportable or not, kept for 24 months.

Layer 2 — provincial health-information acts. Where a province has a health-privacy law declared substantially similar, it governs the clinical layer: Ontario's PHIPA (Personal Health Information Protection Act, 2004) is the model — your platform typically acts as an agent or "electronic service provider" to the custodian (the clinic), with duties that look a lot like a business associate's. Alberta (HIA), and others have siblings. A telemedicine platform serving Ontario clinics signs PHIPA-shaped agreements, supports patient access requests, and logs access like an audit-logging chapter prescribes.

Layer 3 — Quebec. Quebec's Law 25 rebuilt its private-sector privacy law into the closest thing North America has to GDPR: mandatory privacy officers, PIAs, consent rules, and fines up to CAD $25M or 4% of worldwide turnover. The clause that bites architecture is the transfer rule: before communicating personal information outside Quebec — to Toronto as much as to Virginia — you must run a privacy impact assessment and conclude the destination offers adequate protection, with contractual safeguards. A separate 2023 act modernized health- and social-services information rules on the public side. If you host Quebec patient data in a US region without that assessment and contract, you are offside even though federal PIPEDA permits cross-border processing under the accountability principle.

Two timing notes. The federal modernization bill (C-27, with the proposed Consumer Privacy Protection Act) died when Parliament was prorogued in January 2025; as of June 2026 PIPEDA remains the law, with a successor bill expected — design to PIPEDA today, but assume GDPR-grade duties (deletion, portability, monetary penalties) are coming. And no federal Canadian law requires data residency for private-sector health data — but public-sector procurement often expects Canadian hosting, and Quebec's PIA requirement plus some provincial e-health policies push the same direction. A Canadian region is frequently the path of least resistance.

The rest of the map: a tour in one table

You will not memorize every regime, and you do not need to. You need the deltas that change product decisions.

Three rows deserve a sentence each. Brazil: the January 2026 mutual adequacy makes EU↔Brazil flows the easiest of any large non-EEA market; LGPD's sensitive-data rules still apply locally. India: the DPDP Rules were notified in November 2025 with the substantive duties phasing in by mid-2027, and health platforms are prime candidates for "significant data fiduciary" designation — watch the localization power held in reserve. Australia: the Privacy Act is general, but the My Health Records Act 2012 contains a hard localization rule for the national record system — a reminder that residency mandates hide in sector statutes, not privacy laws.

One platform, many regimes: the architecture pattern

Here is the question every multi-market founder eventually asks: do we need a separate product per jurisdiction? No — you need one product with the variability isolated. Four moves do most of the work.

Move 1 — split the control plane from regional data planes. The control plane — build pipeline, feature flags, config, fleet monitoring, aggregated non-identifiable metrics — is global and never touches patient data. Each market gets a data plane: application servers, media servers (SFU/TURN), recording storage, database, and clinical integrations pinned to a region — US, EU (Frankfurt/Paris on HDS-certified services for France), Canada, UK. A patient's media and records are processed and stored in their region; only de-identified aggregates cross (the discipline the de-identification article describes).

Move 2 — one control set, mapped many ways. Encryption in transit and at rest, role-based access, audit logging, MFA, key management — you build each control once and cite it to many masters: HIPAA Security Rule safeguards, GDPR Article 32, PIPEDA safeguards, DSPT evidence. The encryption and audit-logging chapters of this course are the build specs; per-region key stores (EU keys held in the EU) double as a Schrems-II supplementary measure.

Move 3 — make legal text and clocks configuration, not code. Consent screens, lawful-basis records, retention schedules, and breach runbooks differ per region; model them as policy objects. Retention is the clearest example: the same encounter record might face a 6-year HIPAA documentation rule, a member-state 10-year medical-records law, and a PIPEDA "as long as necessary" standard — so retention must be a per-record-class, per-region parameter with deletion jobs to match (the framework from the consent and retention article).

Move 4 — run one vendor matrix with two contract columns. Every sub-vendor (cloud, CPaaS, transcription, e-mail, monitoring) gets a row: BAA available? DPA with SCCs/DPF? EU region? HDS where France matters? A vendor missing the column you need is excluded from that data plane — the same binary discipline the BAA article applies, doubled.

Verify each vendor's current terms, certified-service scope, and DPF status at contract time — all four change.

Figure 4. One codebase, regional data planes. Patient data, keys, consent text, and breach clocks live per region; only configuration and de-identified aggregates are global.

What the second region costs

Walk the arithmetic with the cost-model categories from the telemedicine cost model. Suppose your US deployment runs $4,500/month: $1,300 of control plane (CI/CD, monitoring, staging) and $3,200 of data plane (SFU fleet $1,400 + recording storage $600 + database $700 + TURN $500). Adding an EU data plane duplicates only the data plane: $4,500 + $3,200 = $7,700/month, a 71% increase — not 100% — because the control plane is shared. Add a one-time engineering block for region routing, per-region KMS, and residency tests (typically 6–10 weeks), plus recurring compliance overhead per market: DPIA upkeep, an EU representative (≈ $1,500–3,000/year), a DSPT submission, a Quebec PIA. The pattern's payoff is that market three and four reuse everything but the region itself. These are planning figures, not quotes — your media volumes dominate the variance.

Where Fora Soft fits in

We have built video products since 2005 — 239+ shipped projects across telemedicine, video conferencing, streaming, surveillance, and e-learning — and the multi-regime pattern above is one we implement, not just describe. The requirement comes first: we map which regimes a product faces, then design the region split, the Article 28/BAA vendor chain, the consent and retention configuration, and the WebRTC media path so that patient video never leaves its legal region. Because we build the video layer ourselves — SFU selection, TURN topology, recording pipelines — the compliance boundary is drawn around real components, not a slide. If your roadmap says "launch in the EU next year," that sentence belongs in the architecture review now.

What to read next

• The compliance architecture pattern: how to wrap a video stack in HIPAA — the single-region boundary this article regionalizes.
• Data residency, sovereignty, and where PHI lives — the engineering of region pinning, keys, and support access.
• Business Associate Agreements: the contract that makes or breaks your stack — the US half of the two-column vendor matrix.

Call to action

• Talk to a telemedicine engineer — book a 30-minute scoping call to talk through your gdpr health data plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Global Health-Data Law Launch Checklist — One page: regime mapping, GDPR launch checks (Art.

References

1. Regulation (EU) 2016/679 (GDPR) — Art. 4(15) "data concerning health"; Art. 6 lawful bases; Art. 9(1)–(4) special categories; Art. 17 erasure and 17(3) health carve-outs; Art. 27 representative; Art. 28(3) processor contracts; Art. 33–34 breach notification (72 hours); Art. 35(3)(b) DPIA; Art. 37(1)(c) DPO; Arts. 44–49 transfers; Art. 83(4)–(5) fine tiers. Official text via EUR-Lex, read 2026-06-11. https://eur-lex.europa.eu/eli/reg/2016/679/oj (Tier 1)
2. European Commission, Adequacy decision for the EU–US Data Privacy Framework (Implementing Decision of 10 July 2023); EU General Court, Latombe v Commission, T-553/23, judgment of 3 September 2025 (dismissal); appeal pending as C-703/25 P (as of 2026-06-11). https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers_en (Tier 1 — decision; Tier 2 — case status)
3. Commission Implementing Decision (EU) 2021/914 — Standard Contractual Clauses for transfers; CJEU, Schrems II, C-311/18 (16 July 2020) — transfer impact assessments and supplementary measures. https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj (Tier 1)
4. Regulation (EU) 2025/327 — European Health Data Space (EHDS); entered into force 26 March 2025; staged application 2027/2029/2031. EUR-Lex and European Commission EHDS overview, read 2026-06-11. https://eur-lex.europa.eu/eli/reg/2025/327/oj (Tier 1)
5. UK Data (Use and Access) Act 2025 (2025 c. 18), royal assent 19 June 2025 — amendments to UK GDPR/DPA 2018 (recognised legitimate interests; research consent; automated decision-making). legislation.gov.uk, read 2026-06-11. https://www.legislation.gov.uk/ukpga/2025/18 (Tier 1)
6. NHS England, Data Security and Protection Toolkit (2025–26 edition; CAF-aligned since 2024–25; independent audits for Categories 1–2). https://www.dsptoolkit.nhs.uk/ (Tier 2 — issuing body)
7. Personal Information Protection and Electronic Documents Act (PIPEDA), S.C. 2000, c. 5 — Schedule 1 principles; s. 10.1 breach reporting (real risk of significant harm); OPC, Guidelines for processing personal data across borders (accountability principle). https://laws-lois.justice.gc.ca/eng/acts/P-8.6/ (Tier 1)
8. Personal Health Information Protection Act, 2004, S.O. 2004, c. 3, Sched. A (Ontario PHIPA) — custodians, agents, electronic service providers. https://www.ontario.ca/laws/statute/04p03 (Tier 1)
9. Quebec Law 25 (Act to modernize legislative provisions as regards the protection of personal information, S.Q. 2021, c. 25) — private-sector act s. 17: PIA and contract required before communicating personal information outside Quebec; penalty ceiling CAD $25M / 4%. https://www.legisquebec.gouv.qc.ca/en/document/cs/P-39.1 (Tier 1)
10. France, Code de la santé publique Art. L.1111-8 (HDS certification); HDS V2 referential (renewal deadline 16 May 2026); decree of 24 March 2026 on sovereignty requirements — EEA-only hosting effective September 2026. Agence du Numérique en Santé; summarized in Privacy World (May 2026), cross-checked 2026-06-11 — re-verify decree text before publication. https://esante.gouv.fr/produits-services/hds (Tier 1 statute / Tier 4 summary)
11. CNIL deliberation SAN-2022-009 (15 April 2022) — Dedalus Biologie fined €1.5M; breaches of GDPR Arts. 28, 29, 32 after a health-data leak affecting ~491,000 patients; EDPB national-news record. https://www.edpb.europa.eu/news/national-news/2022/health-data-breach-dedalus-biologie-fined-15-million-euros_en (Tier 1/2)
12. European Commission, adequacy decision for Brazil (adopted 26 January 2026) and ANPD Resolution CD/ANPD No. 32/2026 (mutual recognition); Brazil LGPD, Law No. 13,709/2018, Art. 11 (sensitive health data). https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/adequacy-decisions_en (Tier 1/2)
13. India, Digital Personal Data Protection Act, 2023 and DPDP Rules, 2025 (notified 13–14 November 2025; phased application to 13 May 2027; SDF obligations and reserved localization powers). MeitY/PIB notification record. https://static.pib.gov.in/WriteReadData/specificdocs/documents/2025/nov/doc20251117695301.pdf (Tier 1)
14. Australia, My Health Records Act 2012 (Cth), Part 4 Div. 2 (s 77) — prohibition on holding or processing My Health Record system data outside Australia; Privacy Act 1988 (Cth), APP 8 (cross-border disclosure accountability). https://www.legislation.gov.au/C2012A00063/latest/text (Tier 1)
15. ICO, Special category data guidance (UK GDPR Art. 9; DPA 2018 Sch. 1 conditions for health and social care). https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/special-category-data/ (Tier 2 — supervisory authority)

Where popular secondary sources disagreed with the rule text, the rule won: several US-oriented guides state that "GDPR requires EU data storage" — Chapter V says otherwise (transfers are regulated, not forbidden), and this article says so explicitly while flagging the genuine national localization rules (France HDS; Australia's My Health Records Act; Russia's localization statute in the RU edition).