Data residency
Where EDFlow stores hospital data: AWS ca-central-1 with disaster recovery in ca-west-1, backups in Canada, RPO and RTO, the web tier in Montréal, and which environments hold synthetic data only.
Hospital data stays in Canada
| Component | Location |
|---|---|
| Database and backend (self-hosted Convex, RDS PostgreSQL, S3, KMS) | AWS ca-central-1 (Montréal) |
| Disaster recovery | AWS ca-west-1 (Calgary) |
| Backups and point-in-time recovery | Canada |
| Audit archive (S3 Object Lock) | ca-central-1 |
| Web server functions | Vercel yul1 (Montréal), or a container in the hospital's Canadian account |
| Static web assets | Global CDN (no patient data) |
Patient and staff data travel from the browser or app straight to the Canadian backend over a WebSocket. The web tier never renders patient data on the server.
PHIPA itself has no data-localization rule, but Ontario hospital policies usually require Canadian residency for PHI. Hospital production and customer test are therefore always in Canada.
Recovery objectives
| Scenario | RPO | RTO |
|---|---|---|
| Instance or Availability Zone failure | 0 (synchronous standby) | 30 minutes (4 hours until the HA topology is live) |
| Regional disaster | 15 minutes | 4 hours |
| Customer test | 24 hours | 1 business day |
Restores are tested quarterly, AZ failover twice a year, and a regional DR exercise once a year. Results are in the monthly service report.
Synthetic-only environments
These run on Convex Cloud in the US and never hold hospital data:
- development and preview deployments;
- the showcase (fictional hospitals);
- the docs capture deployment;
- the integration sandbox, which actively refuses real-looking data.
Providers outside Canada
Push, SMS and email providers are in the US but receive only generic text and opaque links, and each is optional per site. AI processing in the US happens only for sites whose privacy office approves it. See Subprocessors.
Related
Last updated on