Security and privacy
Private by design, under PHIPA
EDFlow is built so that the safest thing is also the default: the minimum data in, identifiers stored only as keyed hashes, nothing identifying in notifications or links, every access logged, and hospital data kept in Canada.
Version 1.0Effective September 24, 2026
At a glance
Minimum necessary
No result values, notes, diagnoses, health card numbers, addresses or phone numbers are ever received from the EHR.
Canadian residency
Hospital tenants run in AWS Canada (Central) with encrypted storage and customer-managed keys.
Audit before read
Every read of a visit, by a patient, a family member or staff, is written to an append-only log the privacy office can review.
Tested and open to reports
Yearly third-party penetration tests, OWASP ASVS Level 2, and a safe-harbour disclosure policy.
Roles under PHIPA
| Party | Role |
|---|---|
| The hospital | Health information custodian: accountable, decides purposes, settings and retention within the ranges offered |
| EDFlow | Agent and electronic service provider to the hospital, under a written agreement[1] |
| Family members | Recipients of a disclosure made with the patient's express consent, recorded for each link and withdrawable at any time |
Each hospital is a separate, isolated tenant: EDFlow never lets one custodian disclose information to another. We still meet the duties PHIPA sets for health information network providers voluntarily: a written privacy impact and threat risk summary for each hospital, a log of every access and transfer available on request, breach notice at the first reasonable opportunity, and flow-down terms for sub-processors.[2]
The minimum necessary, by construction
The hospital's integration engine strips messages down to the fields the contract names before anything leaves the hospital network, and our ingest refuses any payload that carries prohibited fields.
| Data | Stored as | Who sees it |
|---|---|---|
| Medical record and visit numbers | Keyed hash only | Nobody (used for matching) |
| Family name and date of birth | Not stored: only a keyed match hash and age in years | Nobody |
| Given name and family initial | Plain text, for the operational window | Patient, care team, staff board |
| Test names and status times | Plain text; sensitive tests shown generically | Patient and staff, never family |
| Result values, notes, diagnoses, health card numbers | Never received | Nobody |
| Phone numbers a patient adds | Encrypted; last two digits shown | The patient |
| Access and audit logs | Append-only | Hospital privacy office |
Finished visits stay identifiable for an operational window set by the hospital (30 days after departure by default), then become de-identified analytic facts. Records of care, such as urgent requests and delay notices, follow the hospital's own health-records schedule. A minimal profile removes names and dates of birth from the feed altogether.
Who can see what
- Patients open their visit from the visit card's QR code or code. Tokens travel only in the URL fragment, are random, are stored as HMAC hashes and are rate-limited and audit-logged on every use.
- Family see the stage, a waiting estimate and first names and roles, only if the patient shares, and never tests or results. The patient can revoke a link at any time.
- Notifications say only "You have a new update.": no hospital, no names, no tests, no locations, on the lock screen or anywhere else.
- Staff sign in with multi-factor authentication or hospital single sign-on; opening a patient's details writes the audit record before the data is read. Visit cards print only at registered stations, and staff screens show a masked code, never a credential a patient could use.
Controls
- Residency. Hospital tenants run on self-hosted infrastructure in AWS ca-central-1 (Montréal) with ca-west-1 (Calgary) for disaster recovery; server functions run in Vercel's Montréal region. Health information is never rendered on a server outside Canada.[3]
- Encryption. TLS 1.2 or later with HSTS in transit; encrypted storage with customer-managed keys at rest; AES-GCM for phone numbers, MFA secrets and pending links.
- Application security. A strict content security policy, host-only cookies, server-side authorization on every function with an audited access grant for staff reads, and rate limits at the network, visit and site level.
- Backups. Encrypted, kept in Canada for 35 days; a restore re-applies retention before traffic resumes.
Testing and responsible disclosure
- A third-party penetration test before the first hospital go-live and every year after, covering web, native, EHR ingest and the authorization matrix.
- Verification baselines: OWASP ASVS Level 2 for the web and MASVS for the apps.
- Every public function ships with tests for its happy path, an authorization denial and a validation failure.
- Responsible disclosure: write to security@edflow.space. Good-faith research that follows the policy is welcome and safe-harboured. Machine-readable details are at /.well-known/security.txt.
Technical documentation
Frequently asked questions
Who is responsible for the data under PHIPA?
The hospital is the health information custodian under PHIPA. EDFlow acts as the hospital's agent and electronic service provider, under a written agreement with a privacy and security schedule, and uses personal health information only as the hospital directs.[1][2]
Where is hospital data hosted?
In Canada. Hospital tenants run on a dedicated backend in AWS Canada (Central), with a second Canadian region for disaster recovery, and the web server functions run in Vercel's Montréal region. The public showcase and development environments use synthetic data only.[3]
How do I report a vulnerability?
Email security@edflow.space. We acknowledge reports quickly, don't pursue good-faith research that follows the disclosure policy, and credit reporters who want it. The machine-readable contact is at /.well-known/security.txt.
What do you provide for our PIA and TRA?
The privacy office receives the security and privacy documentation, the data inventory with privacy classes, the sub-processor list, the authorization matrix, the latest penetration test summary, and test and supply-chain evidence, ready for its privacy impact and threat risk assessments.[4][5]
Keep reading
- TrustPrivacy noticeWhat EDFlow collects during an emergency visit, who sees it, what it never shows, how long it is kept, how AI is used and your rights, in plain language.
- TrustAI with safety: what it does, what it never doesHow EDFlow uses AI safely in the emergency department: a patient assistant that never gives medical advice or results, staff digests and handover summaries, analytics questions, and eight tested guarantees including zero data retention and a kill switch.
- ArticleDesigning family updates under PHIPAHow to design emergency department family updates under Ontario's PHIPA: express consent, a minimum-necessary scope, revocable links and the safety cases that are easy to miss.
Talk to us
See it with your own emergency department in mind
We'll walk through the patient, family and staff views with synthetic data, then map them to your EHR, your workflows and what you want a pilot to prove.
Sources
- [1]Personal Health Information Protection Act, 2004 (opens in a new tab) · Government of Ontario
- [2]Digital Health under PHIPA: Selected Overview (opens in a new tab) · Information and Privacy Commissioner of Ontario
- [3]Introducing the Montréal, Canada region (yul1) (opens in a new tab) · Vercel
- [4]Planning for Success: Privacy Impact Assessment Guide (opens in a new tab) · Information and Privacy Commissioner of Ontario
- [5]Harmonized TRA Methodology (TRA-1) (opens in a new tab) · Canadian Centre for Cyber Security