Data flow
How data moves from the EHR to the patient's screen in EDFlow, what crosses each boundary and what never does, and the data inventory by privacy class with retention.
Cette page n'est pas encore offerte en français; elle est affichée en anglais.
From the EHR to the screen
sequenceDiagram
participant EHR
participant Engine as Integration engine
participant Ingest
participant Pipeline
participant DB as Database
participant Views as Projections
EHR->>Engine: ADT, orders, results (HL7 v2 or FHIR)
Engine->>Engine: Filter to ED visits, ACK the EHR
Engine->>Ingest: HTTPS, signed or OAuth, from a queue
Ingest->>Ingest: Authenticate, size limits, parse in memory
Ingest->>Pipeline: Drop or reject prohibited fields; hash identifiers
Pipeline->>DB: Facts by precedence, derived stage, ledger entry (30 days)
DB-->>Views: Live queries
Views-->>Views: Patient, family, staff, display, API projections- The engine filters to ED visits and acknowledges the EHR as soon as it has stored the message. EDFlow is a separate, queued destination: its outage can't block EHR feeds.
- Ingest authenticates the sender, checks size and parses in memory. Raw messages are never stored or logged.
- Prohibited fields (result values, notes, diagnoses, medications, allergies, health card numbers, addresses, phones, emails) reject the event before anything is stored. The HL7 and FHIR adapters drop these elements before mapping.
- EHR identifiers (visit number, record number, order numbers) are hashed with a site-scoped key on receipt. Family name and date of birth are used only for a sign-in match key and discarded.
- Each audience reads through its own allow-listed projection.
Data inventory
| Data | Source | Stored as | Who sees it | Retention (default) |
|---|---|---|---|---|
| Record number, visit number | EHR | Keyed hash | Nobody (matching only) | While records exist |
| Given or preferred name, family initial | EHR or patient | Plain | Patient, care team | 30 days after departure, then removed |
| Family name, date of birth | EHR | Not stored (match key and age only) | Nobody | — |
| Health card, address, phone, email from the EHR | — | Never received | — | — |
| Patient or family phone for texts | Patient, verified with a code | Encrypted; last 2 digits shown | The patient or family member | Until access or the link ends |
| CTAS, times, disposition | EHR or staff | Plain | Staff; patients see the stage only | 30 days, then de-identified |
| Chief complaint | EHR, opt-in | Plain | Clinical staff only | 30 days |
| Care-team names and roles | EHR or staff | Plain | Patient: name and role; family: first name and role | 30 days |
| Test names and status times | EHR or staff | Plain; sensitive tests shown generically | Patient and staff, never family | 30 days, then de-identified samples |
| Result values, notes, diagnoses | — | Never received | — | — |
| Requests, tasks, feedback | Patient or staff | Structured types; no free text | Care team, admins | 30 days, except safety records |
| Safety records (urgent and high requests, summaries, delay notices, call-backs, pauses) | The service | Identifiable | Privacy office | 10 years (hospital schedule) |
| Questions notepad | Patient | On the patient's device only, encrypted | The patient | Deleted at access end |
| Audit log | The service | Append-only | Privacy office | 2 years (up to 10) |
| Event ledger | Ingest | Minimized, names and date of birth removed | Integration analysts | 30 days |
Minimal data profile
Hospitals can choose a minimal profile: the EHR sends no names and no date of birth, patients sign in with a longer visit code and type the name they want to be called, and the staff board shows bed and initials.
What never leaves
- No PHI in push, SMS or email: lock screens say "You have a new update." Payloads are lint-tested in CI.
- No PHI in URLs: patient and family tokens travel only in the URL fragment, which browsers never send to a server, and are removed from the address bar at once.
- No PHI in logs: the backend logger accepts only allow-listed keys (ids, event types, counts, durations, error codes).
- No PHI in analytics: product telemetry has no patient data; ED analytics use de-identified facts with small-cell suppression.
Related
- PHIPA
- Subprocessors
- Privacy, the patient's version
Dernière mise à jour le
Cette page vous a-t-elle été utile?
Architecture
EDFlow system context and runtime containers for hospital reviewers: the web tier, the Convex backend, the mobile apps, the integration engine link, optional providers, environments and what runs where.
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.