IT and security
The EDFlow trust overview for hospital IT, security and privacy reviewers: hosting, Canadian residency, encryption, identity, audit, PHI boundaries and AI, in one table, and how to request the confidential security package.
This section is for hospital IT, information security and privacy teams reviewing EDFlow for a PIA and TRA. Every statement here comes from the same specifications as the product and the security review pack, so the answers don't disagree.
At a glance
| Topic | Summary | Details |
|---|---|---|
| Hosting | Hospital production on self-hosted Convex in AWS behind a WAF and an edge tier; web delivery on Vercel with server functions in Montréal; no patient data rendered on the server | Architecture |
| Residency | Production data in Canada (ca-central-1, disaster recovery in ca-west-1). The demo and sandbox hold synthetic data only | Data residency |
| Minimum necessary | No result values, notes, diagnoses, health card numbers, addresses or phones are ever received; family name and date of birth are never stored | Data flow |
| Encryption | TLS 1.2+ with HSTS; AES-256 at rest with customer-managed KMS keys; tokens and identifiers stored only as keyed hashes | Controls |
| Identity | Staff invite-only, MFA, optional Microsoft Entra ID; idle lock; quarterly access review; patients sign in with a high-entropy card token | Identity and SSO |
| Authorization | Server-side only, per role and site, with allow-listed projections per audience; every staff read of a patient audited before the read | Controls |
| Audit | Append-only, daily hash chain, per-patient access report, proactive monitoring, SIEM export | Audit logging |
| Notifications | Generic text only: never names, tests or hospital names in push, SMS or email | Data flow |
| PHIPA | EDFlow is the custodian's agent and electronic service provider, and meets the HINP duties voluntarily | PHIPA |
| AI | Off by default. Patient-derived data reaches a model only after the privacy office approves it; zero data retention; no training | AI governance |
| Operations | No standing vendor access to production data; audited, time-boxed support access; two-person deployments | Privileged access |
| Availability | Published SLOs, 24/7 P1 response within 30 minutes, 24-hour breach notice | Availability and incidents |
Confidential security package
Architecture and data-flow diagrams, the data inventory, PIA and TRA inputs, the controls matrix mapped to SOC 2 criteria, the questionnaire master answers (CAIQ v4, SIG Lite), the penetration test summary, the SBOM policy, sub-processors, incident response and DR evidence. See Compliance documents to request it.
All pages
Architecture
Data flow
PHIPA
Controls
Threat model
Data residency
Subprocessors
Accessibility
Identity and SSO
Network requirements
Devices
Availability and incidents
Audit logging
AI governance
Vulnerability disclosure
Compliance documents
Privileged access
Frequently asked questions
Hospital production runs in Canada, in AWS ca-central-1 with disaster recovery in ca-west-1. The demo and the sandbox hold synthetic data only. See Data residency.
The product acts as the hospital's agent and electronic service provider. See PHIPA.
No. Lock screens say only that there is a new update, texts carry no names or health details, and patient tokens travel only in the URL fragment. See Data flow.
Two-step sign-in or Microsoft Entra ID, session limits and idle locks, and privileged roles that need a second approver. See Identity and SSO and Privileged access.
Request it from compliance documents: the architecture, the controls matrix, the TRA summary, the sub-processors and the questionnaire answers.
No. AI features answer from the same information patients and staff already see, stay off until a site approves them, and never give clinical advice. See AI governance.
Last updated on