Healthcare data residency: PIPEDA + HIPAA + provincial — a survival guide

The four-framework problem

A Canadian healthcare organisation operating in 2026 likely touches at least four distinct privacy regimes:

• PIPEDA — federal floor for personal information held by private-sector organisations
• Provincial health-information acts — Ontario's PHIPA, Quebec's health information regime, BC's E-HIA, Alberta's HIA — each with residency expectations that overlap but do not perfectly align
• HIPAA — when the organisation handles US residents' protected health information, or operates US-based services
• Emerging AI compliance — provincial AI governance (e.g., Quebec Law 25 extensions), federal AIDA when enacted, sector-specific clinical AI standards

For most healthcare organisations, the cost of reconciling these per-system is enormous. Architectures that satisfy the union of all four — rather than picking one and back-fitting — compound their advantage.

Where most healthcare stacks break down

• Cross-border AI inference. Clinical decision-support tools that route to OpenAI or Azure OpenAI cross both jurisdictional and protected-health boundaries simultaneously.
• Hyperscaler regions that don't satisfy provincial residency. Ontario PHIPA's expectation of in-province residency is met by "Canadian region" only when the region is genuinely province-aware.
• Backup and DR replication patterns that silently cross borders. A primary in ca-central-1 with DR in us-east-1 (a common AWS pattern) breaches residency by design.
• Vendor data-handling that exceeds clinical operational need. Telemetry, audit logs, and support-portal data often leak content that should be siloed.

Provincial residency, in detail

Ontario PHIPA

The Personal Health Information Protection Act sets out a strong expectation that personal health information remains in Ontario or under Ontario's protective regime. Cross-border transfers require additional consent or notification. PHIPA's IPC has produced multiple guidance documents emphasising the importance of in-province storage where operationally feasible.

Quebec — Loi modifiant des dispositions législatives en matière de protection des renseignements personnels (Law 25) + health regime

Quebec's Law 25 (formerly Bill 64) requires a privacy impact assessment for any cross-border transfer, with explicit attention to the receiving jurisdiction's legal protections. For health information specifically, additional in-province requirements apply.

BC E-HIA, Alberta HIA

Both provinces have health-information acts with residency expectations and breach-notification thresholds. BC's E-HIA emphasises Canadian-only processing as a default; Alberta's HIA provides for cross-border with appropriate safeguards but invites scrutiny.

The AI compliance overlay

Beyond residency, healthcare AI is increasingly subject to provincial-level governance. Quebec's framework leads in formality. Federal AIDA (Artificial Intelligence and Data Act) provisions, expected to come into force in stages, will add national obligations. For RAG-style clinical decision support, the practical implication: the embedding and inference layers must remain within the same residency envelope as the underlying records.

This rules out — for many use cases — RAG pipelines that route to OpenAI, Anthropic, or Azure OpenAI. Even where contractual data-handling assurances exist, the architectural exposure (CLOUD Act reach, AI provider's home jurisdiction) is not eliminated.

The architecture that compounds compliance

SkyeConnex's architecture turns the residency problem into a configuration problem:

• Allow-list enforcement: configure your tenant's geo-policy to admit only Ontario-resident providers (or BC, or Quebec, or whatever set applies). Out-of-policy uploads fail rather than degrade silently.
• Reed-Solomon spread within province: even within a provincial allow-list, files spread across multiple distinct providers — no single provider holds enough to decrypt.
• Sovereign AI via SkyeGXU: embeddings on customer GPU. Documents and queries never leave the customer network. RAG over PHI without OpenAI exposure.
• Per-file residency evidence: SkyeMap shows where each record's shards reside. Compliance audits answer "where is record X?" with a screenshot.
• Dual-signed audit log: HMAC-SHA-256 + ML-DSA-87. Provincial IPC inspections can verify the log offline.

Operational use cases

• Electronic Health Records storage: EHRs distributed across in-province providers, with per-record audit trail for residency compliance.
• Clinical research data: Audited share links for inter-institutional data exchange, with external identity capture and expiry. REB compliance built in.
• Pathology and imaging archives: Multi-TB datasets with resumable upload protocol — field-conditions-tolerant.
• Clinical decision support / RAG: SkyeGXU embeddings + retrieved chunks fed to a sovereign LLM, all within the residency envelope.
• Patient portal documents: Encrypted secure sharing with patients, audit log per access.

What to do this quarter

• Audit your residency posture. For each system holding PHI, document the residency claim and the supporting architectural evidence.
• Identify which provincial regimes apply to each patient cohort. Build the allow-list intersection.
• Inventory AI tooling that touches PHI. For each tool, verify the residency of inference and embedding.
• Where exposure exists, prioritise architectures that make residency a property of the data, not a property of the contract.

For a healthcare-specific briefing covering PIPEDA, provincial overlays, HIPAA-BAA, and sovereign AI, book 45 minutes. We bring the relevant compliance packs pre-configured.

---

Published February 28, 2026 · Written by SkyeConnex Inc. · More from the SkyeConnex blog