Controls
The EDFlow controls matrix: authentication and MFA, server-side authorization and projections, token hashing, encryption, rate limits, audit, log redaction, security headers and CSP, supply chain, vulnerability management and penetration testing.
Controls matrix
| Area | Control |
|---|---|
| Staff authentication | Invite-only; passwords of 12+ characters with a strength check and a breached-password list; MFA (TOTP) required in production; optional Microsoft Entra ID (OIDC with PKCE, guest accounts refused); lockout after 5 failures in 15 minutes from unknown devices; idle lock after 15 minutes; 12-hour sessions; fresh sign-in for sensitive actions |
| Patient and family access | 128-bit random card and link tokens in the URL fragment only; a second device needs the date of birth or the first device's approval; staff-assisted sign-in by reverse pairing, so staff never hold a usable credential; at most 5 patient devices per visit and 3 per family link; access ends automatically after departure |
| Authorization | Server-side only: identity is derived on the server, never from client-supplied ids, roles or sites. Each staff function checks a permission at the active site. Cross-site ids return "not found". Every read goes through an allow-listed projection per audience, with tests that forbidden fields are absent |
| Audit before read | A staff member must open a visit (recorded) before reading or acting on it. Board views recorded every 15 minutes |
| Token storage | Tokens, visit codes and API secrets stored only as keyed HMAC hashes; a copy of the database opens nothing |
| Encryption | TLS 1.2+ (1.3 preferred) with HSTS preload; AES-256 at rest with KMS customer-managed keys; phone numbers and MFA secrets encrypted with AES-256-GCM; per-organization KMS keys for integration secrets, with a hospital-held key option |
| Rate limits | Per network, per visit, per account, per app, per endpoint; never a global lockout that would let an attacker lock staff out |
| Audit | Append-only log with a daily hash chain; per-patient access report; monitoring rules; SIEM export |
| Log redaction | The backend logger accepts only allow-listed keys; console is banned by lint; HTTP handlers never log bodies, headers or token paths; parser errors carry positions, not values |
| Notifications | Generic templates only; payload lint in CI |
| Web security | Nonce-based CSP, frame-ancestors 'none', X-Content-Type-Options: nosniff, strict referrer policy, no-store and no-referrer on token routes, no third-party scripts on patient and family pages, self-hosted fonts |
| API security | OWASP API Top 10 controls: site-scoped queries, short-lived tokens, network binding, allow-listed projections, rate limits, SSRF policy for webhooks, strict schemas, no CORS |
| Integration | HMAC or OAuth; replay window; idempotency; prohibited-field tripwire; IP allowlists; per-source keys with rotation overlap |
| Supply chain | Lockfile integrity, dependency audit, secret scanning (including the service's credential prefixes), SBOM, pinned CI actions, signed build artefacts with provenance, two-person production deployments |
| Vulnerability management | Critical vulnerabilities fixed within 72 hours; forced app updates for security fixes |
| Penetration testing | External test of the API, edge, portal and patient web before live; annually and after major changes; summary letter shared |
| Privileged access | No standing vendor access to production data; just-in-time break glass with approval and session recording. See Privileged access |
| Resilience | See Availability and incidents |
Security headers
| Header | Value |
|---|---|
Strict-Transport-Security | 2 years, includeSubDomains, preload |
Content-Security-Policy | Nonce-based scripts, connect-src limited to the backend, frame-ancestors 'none' (the display only for configured origins) |
Referrer-Policy | strict-origin-when-cross-origin; no-referrer on token routes |
Permissions-Policy | Camera only on sign-in and staff scan routes |
Cache-Control | no-store on token routes and API responses |
Verification
Every public backend function has tests for the happy path, an authorization denial and a validation failure, and an authorization matrix is generated from the permission catalogue. Projection tests assert forbidden fields are absent. Storage and log scans run over end-to-end test runs.
Related
Dernière mise à jour le
Cette page vous a-t-elle été utile?
PHIPA roles and privacy
EDFlow under Ontario's PHIPA: the hospital as custodian, the vendor as agent and electronic service provider, voluntary HINP duties, minimum necessary, consent for family sharing, patient access, breach notification, and PIA and TRA support.
Threat model
A summary of the EDFlow threat and risk assessment: attacker models, STRIDE threats per component, the top risks and their mitigations, and residual risks.