Availability and incidents
EDFlow service levels: the support severity matrix with 24/7 P1 response within 30 minutes, the 24-hour breach notice, maintenance windows and notice, SLOs and the HA topology they depend on, RPO and RTO, DR drills and the status page.
Service level objectives
- Availability: 99.5% monthly for live ingest and read until the high-availability topology is in production and has passed a failover drill; 99.9% after that.
- Latency: p95 under 500 ms for single-event ingest and reads; under 3 s for 100-event batches; the first webhook attempt within 5 s at p95; every accepted event applied within 60 s.
Engines store and forward, so a short outage delays patient-facing updates but loses no data; patients see "updates may be delayed".
The HA topology behind 99.9%
RDS PostgreSQL Multi-AZ with a synchronous standby; the backend spread over two Availability Zones with health-checked replacement and a single-writer lock; S3 file storage; the edge tier and egress proxy with at least two instances in two zones.
Recovery
| Tier | RPO | RTO |
|---|---|---|
| Live, instance or zone failure | 0 | 30 minutes (4 hours until HA is live) |
| Live, regional disaster | 15 minutes | 4 hours (recovery into ca-west-1) |
| Customer test | 24 hours | 1 business day |
| Sandbox | Reseedable | 1 business day |
Quarterly restore tests, semi-annual zone failover drills and an annual regional exercise. Results go into the monthly service report and the security package.
Support and severity
| Severity | Definition | Hours | First response | Updates | Target |
|---|---|---|---|---|---|
| P1 | Live ingest or the patient or staff app unavailable at a site; a feed outage caused by the service; a suspected privacy or security breach | 24/7 | 30 minutes, by phone to the integration on-call and privacy contact | Every 60 minutes | Workaround within 4 hours |
| P2 | Degraded service: webhook delays over 15 minutes, partial ingest failure, a quarantined roster, the developer portal down | 24/7 | 2 hours | Every 4 hours | 1 business day |
| P3 | A defect with a workaround; non-urgent configuration | Mon–Fri 08:00–18:00 Toronto | 1 business day | Weekly | Next release |
| P4 | Questions, documentation, feature requests | Business hours | 2 business days | — | Roadmap |
Every response carries a Request-Id; quote it in tickets.
Breach and incident notice
- Suspected privacy breach involving the custodian's data: the privacy office is notified within 24 hours of discovery by phone and email; a preliminary written report within 72 hours; a final report with root cause and corrective actions within 30 days.
- Security incidents without PHI impact that affect the service: within 72 hours.
Maintenance
EDs run 24/7, so maintenance happens in lower-volume time: Tuesday or Wednesday 02:00–05:00 Toronto time, announced at least 10 business days ahead on the status page and to each site's contacts, and never taking the patient app or ingest fully offline for more than 15 minutes. Emergency changes (security fixes, P1 remediation) may happen any time, with notice before the change when possible and otherwise within 1 hour. Hospitals may declare freeze periods, honoured except for emergencies.
Status page and reports
The status page covers live ingest, live read and write, webhook delivery, customer test, sandbox, the web app, the patient app and notifications, with email, RSS and webhook subscriptions. Each custodian receives a monthly service report: availability against the SLO, incidents, P1 and P2 response times, changes made and DR evidence.
Related
Dernière mise à jour le
Cette page vous a-t-elle été utile?
Devices and device management
Devices for EDFlow: staff phones under MDM and the managed-device requirement, shared workstations, print and big-board stations, the waiting-room kiosk, and patients' own phones.
Audit logging
What EDFlow records in its audit log, the record format, append-only storage with a daily hash chain, proactive monitoring rules, per-patient access reports and SIEM export.