# OAuth authorization server metadata (https://docs.edflow.space/developers/api/oauth/getAuthorizationServerMetadata) RFC 8414 authorization server metadata. Lists every client authentication method this deployment supports. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Token signing keys (https://docs.edflow.space/developers/api/oauth/getTokenSigningKeys) Public keys of the access-token signing keys (ES256). Two keys are published during a rotation. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Revoke an access token (https://docs.edflow.space/developers/api/oauth/revokeAccessToken) RFC 7009. Always answers 200, even for unknown tokens. The next request with a revoked token gets `401 token_revoked`. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Get an access token (https://docs.edflow.space/developers/api/oauth/createAccessToken) Issues a short-lived (≤ 300 s) ES256 access token (RFC 9068). Cache it and refresh 30 s before `expires_in`. Errors use RFC 6749 bodies; failed client authentication is rate-limited per (client id, source address). OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Signed ingest: events (https://docs.edflow.space/developers/api/signed-ingest/signedIngestEvents) Normalized events signed with the source key (`EDFlow-Source`, `EDFlow-Timestamp`, `EDFlow-Delivery-Id`, `EDFlow-Signature`). An exact replay of a processed delivery returns the stored 200 result. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Signed ingest: FHIR (https://docs.edflow.space/developers/api/signed-ingest/signedIngestFhir) A FHIR R4 Bundle signed with the source key; `EDFlow-Site-Code` names the site. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Signed ingest: health (https://docs.edflow.space/developers/api/signed-ingest/signedIngestHealth) Unauthenticated health of the signed ingest: `status`, `time` and `specVersions`. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Signed ingest: HL7 v2 (https://docs.edflow.space/developers/api/signed-ingest/signedIngestHl7v2) JSON-wrapped HL7 v2 messages (≤ 50) signed with the source key; ACKs follow the ACK table. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Signed ingest: validate (https://docs.edflow.space/developers/api/signed-ingest/signedIngestValidate) Dry run of any of the three inputs (`EDFlow-Input`); persists nothing. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # List code alerts (https://docs.edflow.space/developers/api/codes/listCodeAlerts) Department code alerts (default: active). `area` is omitted when the site turns `integration.api.includeCodeArea` off. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Get a visit document (https://docs.edflow.space/developers/api/documents/getDocument) Fetch a visit document by id (Phase 3). Requires `documents:read` and a token obtained with `private_key_jwt` or mTLS; documents are available for 72 hours. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # List encounters (https://docs.edflow.space/developers/api/encounters/listEncounters) Encounters ordered by `(updatedAt, id)`. `updatedSince` gives incremental sync; items updated in the last 10 seconds are held back (settle window). OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Look up an encounter by visit number (https://docs.edflow.space/developers/api/encounters/lookupEncounter) Resolves an EHR visit number to an encounter without EDFlow storing the number. A miss is `200` with `found: false`. Rate-limited (`lookup`) and audited without the identifier. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Get an encounter (https://docs.edflow.space/developers/api/encounters/getEncounter) One encounter. `404` for unknown ids, other sites and archived encounters. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Get an encounter's care team (https://docs.edflow.space/developers/api/encounters/getCareTeam) The current care team. Zone-derived nurses are computed at read time (`id: null`, `source: zone`). Staff hidden from patients are listed with `hiddenFromPatients: true`. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # List ingest events (https://docs.edflow.space/developers/api/ingest/listIngestEvents) The ingest ledger of the app's source (30 days), ordered by `(updatedAt, id)`. Metadata only, never payloads. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Ingest one event (https://docs.edflow.space/developers/api/ingest/ingestEvent) One normalized event (≤ 32 KiB). `accepted`, `duplicate`, `ignored` and `superseded` answer 200; `buffered` and `quarantined` answer 202; a data rejection is `422 event_rejected`; a reused id with another payload is `409 idempotency_conflict`; a processing error is `503` (retry the same event). OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Ingest a batch of events (https://docs.edflow.space/developers/api/ingest/ingestEventBatch) 1 to 100 normalized events, applied in array order, each atomically and independently. The 200 body is byte-compatible with `/ehr/v1/events`, so an engine can switch transports without changing response handling. A per-event `processing_error` is `retryable`: resend that event (same id). OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Dry-run any input (https://docs.edflow.space/developers/api/ingest/validateInput) Dry run for any input: nothing is persisted, notified or ledgered. The input kind comes from `Content-Type` (`application/json` events, `application/fhir+json`, `application/hl7-v2`, or JSON `{ messages }` with `?input=hl7v2`). The environment checks (processing id, sandbox tripwire) apply. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Get an ingest event (https://docs.edflow.space/developers/api/ingest/getIngestEvent) One ledger row of the app's source by the source event id (URL-encoded). Metadata only. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Ingest a FHIR batch Bundle (https://docs.edflow.space/developers/api/fhir/ingestFhirBundle) A FHIR R4 `batch` Bundle only (each entry processed independently). A `transaction` Bundle is refused with `422 transaction_not_supported`; other Bundle types go to `$ingest`. `Accept: application/fhir+json` answers a `batch-response` Bundle. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Ingest another Bundle type ($ingest) (https://docs.edflow.space/developers/api/fhir/ingestFhirCustom) `$ingest`: Bundle types FHIR does not allow at the base (`collection`, `searchset`, `history`), including Subscriptions Backport notifications. Handshakes and heartbeats produce no events. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Process a FHIR message (https://docs.edflow.space/developers/api/fhir/processFhirMessage) `$process-message`: a `message` Bundle whose first entry is a `MessageHeader`. Synchronous; duplicates (`Bundle.id` + `MessageHeader.id`, 30 days) replay the stored response. Data rejections answer 200 with `fatal-error`; transient failures answer 503 with `Retry-After`. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # SMART configuration (https://docs.edflow.space/developers/api/fhir/getSmartConfiguration) SMART Backend Services configuration: asymmetric client authentication (`private_key_jwt`) for token requests to the push endpoints only. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # $ingest OperationDefinition (https://docs.edflow.space/developers/api/fhir/getFhirIngestOperationDefinition) The OperationDefinition of `$ingest` (canonical `https://edflow.space/fhir/OperationDefinition/ingest`). OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # FHIR CapabilityStatement (https://docs.edflow.space/developers/api/fhir/getFhirCapabilityStatement) FHIR R4 CapabilityStatement (`kind: instance`). Declares only `batch`, `$process-message` and `$ingest`; there is no FHIR read API. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Health (https://docs.edflow.space/developers/api/metadata/getHealth) Public liveness. Compare `time` with your own clock. `down` answers HTTP 503. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Identity and configuration (https://docs.edflow.space/developers/api/metadata/getMeta) Who the caller is and how the platform is configured for it: app, organization, sites, scopes, pinned version, credential, limits and webhook egress addresses. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # OpenAPI document (https://docs.edflow.space/developers/api/metadata/getOpenApi) The OpenAPI 3.1 document of this deployment, generated from the operation registry. Identical to the published document except `servers`. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Ingest HL7 v2 (https://docs.edflow.space/developers/api/hl7-v2/ingestHl7v2) Raw mode (`application/hl7-v2`, `x-application/hl7-v2+er7` or `text/plain`, optional `charset` that must agree with MSH-18): one ER7 message, answered with an ACK per the ACK table. JSON mode (`application/json`): `{ messages }` (≤ 50). Transient failures are `503`/`429` with `Retry-After` and no ACK. Site: `?site=`, else resolved from MSH-4 through the mapping profile. Engines must never hold their queue on a EDFlow ACK. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # List requests (https://docs.edflow.space/developers/api/requests/listRequests) The requests feed, ordered by `(updatedAt, id)`, with the 10-second settle window. Only requests past the patient's undo window appear. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Get a request (https://docs.edflow.space/developers/api/requests/getRequest) One request. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Acknowledge a request from the EMR (https://docs.edflow.space/developers/api/requests/acknowledgeRequest) Marks an open request as seen when a clinician handles it in the EMR. The patient sees the same result as a console acknowledgement: "Seen by {name}" for a linked practitioner, otherwise the generic care-team copy. Already acknowledged answers 200 with the current state; resolved or cancelled answers `409 conflict`. Requires the site's request write-back switch. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Resolve a request from the EMR (https://docs.edflow.space/developers/api/requests/resolveRequest) Resolves a request from the EMR (acknowledging it first when open). Already resolved answers 200 with the current state; cancelled answers `409 conflict`. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Start a conformance run (https://docs.edflow.space/developers/api/sandbox/sandboxStartConformance) Starts a go-live conformance run: `ingest`, `webhooks`, `writeback`, `outage_recovery` (turns on a 30-minute `unavailable` fault), `clock_skew` (±90 s), `backfill_10k`. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Get a conformance run (https://docs.edflow.space/developers/api/sandbox/sandboxGetConformance) A conformance run and its checks with evidence. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Get fault settings (https://docs.edflow.space/developers/api/sandbox/sandboxGetFaults) The app's active fault settings. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Set fault injection (https://docs.edflow.space/developers/api/sandbox/sandboxSetFaults) Makes this app's own requests fail or slow down (`503` with `Retry-After`, `429`, latency, token endpoint down) for ≤ 24 h. Other apps are unaffected. At most 5 faults. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Create a patient request (https://docs.edflow.space/developers/api/sandbox/sandboxCreateRequest) Creates a patient request on a synthetic encounter as if the patient tapped it (skipping the undo window), to test `request.created` webhooks and write-back. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Reset the sandbox (https://docs.edflow.space/developers/api/sandbox/sandboxReset) Resets the org's sandbox sites: deletes the app's ledger rows and webhook history for those sites. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Run a simulator scenario (https://docs.edflow.space/developers/api/sandbox/sandboxRunScenario) Runs a simulator scenario (for example `chest_pain_admit`, `lwbs`) through the chosen transport. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # List sites (https://docs.edflow.space/developers/api/sites/listSites) The sites bound to the app, with feed state, volume and the site's capability switches. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # List tasks (https://docs.edflow.space/developers/api/tasks/listTasks) Patient tasks ordered by `(updatedAt, id)`, with the 10-second settle window. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Get a delivery (https://docs.edflow.space/developers/api/webhooks/getWebhookDelivery) One delivery with its thin payload and ≤ 10 attempts. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Redeliver a message (https://docs.edflow.space/developers/api/webhooks/redeliverWebhook) A new delivery of the same message (same `webhook-id`). An expired sensitive event needs `allowExpired`. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # List webhook endpoints (https://docs.edflow.space/developers/api/webhooks/listWebhookEndpoints) The app's endpoints (≤ 20). OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Create a webhook endpoint (https://docs.edflow.space/developers/api/webhooks/createWebhookEndpoint) Creates an endpoint. The URL must pass the destination policy (HTTPS, public host, no private ranges). The `whsec_` signing secret is returned **once**. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Get a webhook endpoint (https://docs.edflow.space/developers/api/webhooks/getWebhookEndpoint) One endpoint. Secrets and header values are never returned. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Update a webhook endpoint (https://docs.edflow.space/developers/api/webhooks/updateWebhookEndpoint) Updates an endpoint. Re-enabling an auto-disabled endpoint is `status: enabled`; then `recover`. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Delete a webhook endpoint (https://docs.edflow.space/developers/api/webhooks/deleteWebhookEndpoint) Deletes an endpoint and cancels its pending deliveries. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # List deliveries (https://docs.edflow.space/developers/api/webhooks/listWebhookDeliveries) Deliveries of an endpoint, newest first (without payloads). OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Recover failed deliveries (https://docs.edflow.space/developers/api/webhooks/recoverWebhookDeliveries) Redelivers every failed delivery since a time (≤ 14 days). Expired events are skipped unless `includeExpired`. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Rotate the signing secret (https://docs.edflow.space/developers/api/webhooks/rotateWebhookSecret) Adds a new secret version; both sign during the overlap (1–168 h, default 24 h). The new secret is shown once. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Send a test message (https://docs.edflow.space/developers/api/webhooks/sendWebhookTest) Posts a `webhook.test` message synchronously and returns the attempt. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # List webhook event types (https://docs.edflow.space/developers/api/webhooks/listWebhookEventTypes) The event catalogue with each type's data schema, sensitivity, expiry and `liveFrom`. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # A code was called (https://docs.edflow.space/developers/api/webhooks/webhook-code.called) A department code is active (after the two-step confirmation). No patient data. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # A code ended (https://docs.edflow.space/developers/api/webhooks/webhook-code.cleared) A code was cleared, cancelled or expired. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # A code changed (https://docs.edflow.space/developers/api/webhooks/webhook-code.updated) A code was extended or its patient notice changed. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # A patient opened the visit (https://docs.edflow.space/developers/api/webhooks/webhook-encounter.access_activated) The first patient session on the visit. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # The visit stage changed (https://docs.edflow.space/developers/api/webhooks/webhook-encounter.stage_changed) The derived stage changed. Expires after 6 hours or when a newer stage change exists. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Feed state changed (https://docs.edflow.space/developers/api/webhooks/webhook-feed.state_changed) A site's feed moved between healthy, delayed and down. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # An event was dead-lettered (https://docs.edflow.space/developers/api/webhooks/webhook-ingest.dead_lettered) A buffered event expired or a data rejection was dead-lettered; fix the mapping and replay it. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # A roster was quarantined (https://docs.edflow.space/developers/api/webhooks/webhook-ingest.roster_quarantined) The roster circuit breaker held a department roster for a person to confirm or discard. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # A credential is expiring (https://docs.edflow.space/developers/api/webhooks/webhook-integration.credential_expiring) Sent 30, 7 and 1 days before a credential expires. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # A request was acknowledged (https://docs.edflow.space/developers/api/webhooks/webhook-request.acknowledged) From the staff console, the companion app or the API. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # A request was cancelled (https://docs.edflow.space/developers/api/webhooks/webhook-request.cancelled) The patient cancelled the request. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # A patient sent a request (https://docs.edflow.space/developers/api/webhooks/webhook-request.created) The request passed the patient's 5-second undo window. Expires after 2 hours, or at once when it is no longer open. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # A request was escalated (https://docs.edflow.space/developers/api/webhooks/webhook-request.escalated) A step of the escalation ladder. Expires after 1 hour, or when it is no longer open. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # A request was resolved (https://docs.edflow.space/developers/api/webhooks/webhook-request.resolved) Resolved by staff, by the API, or closed at departure. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # A patient completed a task (https://docs.edflow.space/developers/api/webhooks/webhook-task.completed) The patient marked a task done. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Staff confirmed a task (https://docs.edflow.space/developers/api/webhooks/webhook-task.confirmed) Staff confirmed a patient-completed task. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # A communication log is ready (https://docs.edflow.space/developers/api/webhooks/webhook-visit.communication_log_ready) At departure when document write-back (Phase 3) is on. Fetch it with `GET /v1/documents/{documentId}` within 72 hours. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # Test message (https://docs.edflow.space/developers/api/webhooks/webhook-webhook.test) Sent by the portal's Send test button or `POST /v1/webhook-endpoints/{id}/test`. OpenAPI: https://docs.edflow.space/openapi/edflow-v1.json # AI (https://docs.edflow.space/admin/ai) Turn EDFlow AI features on per site: the six layers that must all allow a feature, the governance gates G-AI-1 to G-AI-6, budgets, conversation retention, the kill switch, and where flagged conversations go. AI features are **off by default** in production. Each one runs only when every layer below allows it; if any layer is unknown or off, the feature stays off and the normal screen works as usual. ![AI settings: each AI feature with its governance gates, on or off per site, the monthly budget and the kill switch.](https://docs.edflow.space/screenshots/web/admin-ai-settings.png) ## The layers [#the-layers] | Layer | Who controls it | Effect | | ----------------------------- | ------------------------------------------------- | ------------------------------------------------------------- | | Hard switch on the deployment | Platform engineers | Every AI function refuses; entry points hidden | | Platform kill switch | Platform administrators, audited | Entry points disappear within seconds; in-flight answers stop | | Platform flags | Platform administrators, per environment and site | Per feature | | **Site settings** (this page) | Managers with `settings.manage`, audited | Per feature, languages, budget, retention | | **Governance gates** | See below | Patient- and family-facing features in production | | Budget | Automatic | Features pause when the monthly budget is used up | ## Site settings [#site-settings] | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | ai.enabled | false | boolean | AI features at this site (F-35.3 layer 4). (Reduces privacy) | | ai.features.patientAssistant | false | boolean | AI feature: patientAssistant. (Reduces privacy) | | ai.features.familyHelper | false | boolean | AI feature: familyHelper. (Reduces privacy) | | ai.features.familyCatchUp | false | boolean | AI feature: familyCatchUp. (Reduces privacy) | | ai.features.testExplainers | false | boolean | AI feature: testExplainers. (Reduces privacy) | | ai.features.machineTranslation | false | boolean | AI feature: machineTranslation. (Reduces privacy) | | ai.features.voiceNative | false | boolean | AI feature: voiceNative. (Reduces privacy) | | ai.features.voiceWeb | false | boolean | AI feature: voiceWeb. (Reduces privacy) | | ai.features.requestDigest | false | boolean | AI feature: requestDigest. (Reduces privacy) | | ai.features.quickReplies | false | boolean | AI feature: quickReplies. (Reduces privacy) | | ai.features.handover | false | boolean | AI feature: handover. (Reduces privacy) | | ai.features.patientMessageDrafts | false | boolean | AI feature: patientMessageDrafts. (Reduces privacy) | | ai.features.askData | false | boolean | AI feature: askData. (Reduces privacy) | | ai.features.insights | false | boolean | AI feature: insights. (Reduces privacy) | | ai.features.weeklyReport | false | boolean | AI feature: weeklyReport. (Reduces privacy) | | ai.features.anomalies | false | boolean | AI feature: anomalies. (Reduces privacy) | | ai.features.mappingAssistant | false | boolean | AI feature: mappingAssistant. (Reduces privacy) | | ai.features.catalogChecks | false | boolean | AI feature: catalogChecks. (Reduces privacy) | | ai.features.contentAuthoring | false | boolean | AI feature: contentAuthoring. (Reduces privacy) | | ai.features.feedbackThemes | false | boolean | AI feature: feedbackThemes. (Reduces privacy) | | ai.features.commandAssistant | false | boolean | AI feature: commandAssistant. (Reduces privacy) | | ai.features.auditExplainer | false | boolean | AI feature: auditExplainer. (Reduces privacy) | | ai.patientLanguages | [] | array | Machine-translated patient languages (each enabled in aiLanguages). (Reduces privacy) | | ai.monthlyBudgetUsd | 500 | 0–100000 usd | Site AI budget per month (AI_DEFAULT_SITE_BUDGET_USD). | | ai.conversationRetentionDays | 7 | 0–30 days | Days AI conversations are kept after the session ends. (Reduces privacy) | | ai.safetyReviewSampleRate | 0 | 0–1 ratio | Random sampling of unflagged conversations; > 0 only with randomSampleApproval. (Reduces privacy) | | ai.selfHarmAutoAlert | true | boolean | Self-harm sends a structured urgent alert; off only with selfHarmAlertWaiver (D-AI-03). (Reduces privacy) | | ai.distressAutoAlertSeconds | 60 | 30–120 seconds | Red-flag distress alert delay (D-AI-03). | | ai.showAssistantByDefault | true | boolean | Show the assistant entry point by default. | | ai.crossSitePeerRanges | false | boolean | Cross-site peer ranges (AI-15, Q-AI-06). (Reduces privacy) | | ai.governance.privacyApproval | — | object | Governance gate record: privacyApproval. (Reduces privacy) | | ai.governance.regulatoryMemo | — | object | Governance gate record: regulatoryMemo. (Reduces privacy) | | ai.governance.evalSignoff | — | object | Governance gate record: evalSignoff. (Reduces privacy) | | ai.governance.piaTra | — | object | Governance gate record: piaTra. (Reduces privacy) | | ai.governance.hazardLog | — | object | Governance gate record: hazardLog. (Reduces privacy) | | ai.governance.staffBriefing | — | object | Governance gate record: staffBriefing. (Reduces privacy) | | ai.governance.mappingAssistantPrivacyApproval | — | object | Governance gate record: mappingAssistantPrivacyApproval. (Reduces privacy) | | ai.governance.randomSampleApproval | — | object | Governance gate record: randomSampleApproval. (Reduces privacy) | | ai.governance.selfHarmAlertWaiver | — | object | Governance gate record: selfHarmAlertWaiver. (Reduces privacy) | | ai.governance.safetyReviewers | [] | array | The designated AI safety review group (§2.4 footnote 8). (Reduces privacy) | * **Features** are switched one by one: patient assistant, family helper, test explainers, machine translation, voice, request digest, handover summary, message drafts, Ask your data, insights, weekly report, anomaly alerts, mapping assistant, catalogue checks, content authoring, and more. * **Patient languages** for the assistant: each must be reviewed first. * **Monthly budget** in US dollars. * **Conversation retention**: 0 to 30 days after the session ends (default 7). * **Self-harm auto-alert** is on by default and can be turned off only with the ED clinical lead's recorded waiver. ## Governance gates [#governance-gates] A patient- or family-facing feature can't be turned on in production until every gate is recorded: | Gate | Evidence | Recorded by | | ------ | ------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | G-AI-1 | Privacy office approval of the data flows, including processing outside Canada with zero data retention | Privacy officer | | G-AI-2 | Regulatory memo confirming the non-device intended use | Site manager records receipt of the signed memo | | G-AI-3 | Clinical lead sign-off of the current evaluation report | A clinical approver | | G-AI-4 | PIA addendum and TRA update | Privacy officer | | G-AI-5 | Hazard log reviewed for this release | Clinical lead | | G-AI-6 | Staff briefing done | Site manager | Staff-only and aggregate features (digest, handover, drafts for staff, Ask your data, insights, reports, mapping, catalogue checks) need G-AI-1 and G-AI-4 only. The mapping assistant with real hospital feed samples also needs G-AI-1. ## Flagged conversations [#flagged-conversations] Conversations where the safety layer flagged distress, self-harm or misuse go to a small safety review group outside the care team. Privacy officers see how that works in [AI review](/admin/privacy/ai-review). Random sampling of unflagged conversations is off unless the privacy office approves it. ## The kill switch [#the-kill-switch] If something looks wrong, ask the platform team to use the kill switch: every AI entry point disappears within seconds across all sites. Your site-level switches stay as they were. ## Related [#related] * [AI governance](/security/ai) for reviewers * [AI assistance](/staff/ai-assistance) and [Ask the assistant](/patients/ask-the-assistant) # Announcements (https://docs.edflow.space/admin/announcements) Post, schedule and expire EDFlow site announcements for the entry page, patients, family, the waiting-room display and staff, with approved templates, a 280-character limit and link rules. Announcements are short, practical notices, like "Parking lot B is closed for repairs. Please use lot C." ![Announcements: messages for the entry page, the patient app and the waiting-room display, with start and end times.](https://docs.edflow.space/screenshots/web/admin-announcements.png) ## Create an announcement [#create-an-announcement] 1. **Announcements → New**. 2. Choose the audience: entry page, patients, family, the waiting-room display, or **staff** (an incident or downtime banner in the console). 3. Write the title and body in English and French, up to 280 characters each. 4. Choose the tone (info or warning) and the start and end times. ## Rules [#rules] * Never clinical content. * Links and phone numbers are removed unless they match the site's trusted domains or official phone numbers. * The author's role is shown. * A patient-facing announcement uses an approved template, or waits for a second person's approval before it starts. * Announcements disappear at their end time on their own. ## Where patients see it [#where-patients-see-it] In the notice area of the Visit screen (after safety notices and the busy banner), on the hospital entry page and on the display, depending on the audience you chose. ## Related [#related] * [Hospital information](/admin/settings/hospital-information) # Administrators (https://docs.edflow.space/admin) The EDFlow admin overview for ED managers, and the go-live checklist: EHR gates, content approval, staff training, signage and the AI gates. The admin area is for ED managers, privacy officers and integration analysts. Each role sees only its own pages. This section starts with the manager's view. ## The overview [#the-overview] ![Admin overview: today's volume, median waits by segment, open requests, feed health and the go-live checklist.](https://docs.edflow.space/screenshots/web/admin-overview.png) The overview shows, for today and the last 7 days, with the change against the previous period: * census now, waiting to be seen now, door-to-doctor p50 and p90 against the site target; * LOS p90 by Ontario group with the share meeting target, ambulance offload p90, LWBS rate; * boarding count, boarder-hours, median time to an inpatient bed, stretchers occupied by boarders; * results to disposition, open requests and first-response time, SLA compliance; * active codes, activation rate, feedback top box, feed state. **Live bottlenecks** list active visits past p90 in their current segment, next to capacity drivers (boarders, occupancy, physicians on shift), so access block isn't mistaken for an ED problem. **Arrivals today by hour** compare with the same weekday over the last 8 weeks. ## Your pages [#your-pages] | Area | Pages | | -------------------- | -------------------------------------------------------------------------------------------------------------------------- | | People | [Users and access](/admin/users-and-access) | | Configuration | [Settings](/admin/settings), [Announcements](/admin/announcements), [AI](/admin/ai), [EDFlow Mail](/admin/mail) (platform) | | Measurement | [Analytics](/admin/analytics), [Reports and exports](/admin/reports-and-exports) | | Running a pilot | [Pilot playbook](/admin/pilot-playbook) | | Privacy officers | [Audit and access reports](/admin/privacy) | | Integration analysts | [Feed health](/admin/integration) | ## Go-live checklist [#go-live-checklist] Before a site goes live, every item below is complete. The EHR gates are enforced by the platform: nobody can override them. ### EHR and integration [#ehr-and-integration] * Conformance run with every fixture passing. * 14-day shadow run with at least 98% milestone agreement against the site's audit sample. * 95th-percentile EHR-to-screen time of 60 s or less; rejected events below 0.5%. * No unmapped codes in the last 30 days; roster reconciliation closing every test discharge. * Or, for a manual site: the manual console process agreed with the charge nurses. ### Safety and privacy [#safety-and-privacy] * Clinical safety case signed off for the site's configuration. * PIA and TRA recorded as approved. * Privacy officer accounts in place, with the second approver for exports. ### Content [#content] * Hospital information complete in English and French. * Education sheets, going-home templates, task templates and FAQ approved by a clinical approver and published. See [Patient content](/admin/settings/patient-content). * Safety locales translated and reviewed. ### People [#people] * Staff invited, roles assigned, privileged roles approved. * Staff in the pilot zones trained in training mode. * Zones, pools and the physician in charge assigned for the first shift. ### Places [#places] * Print stations registered and tested at triage and registration. * Posters and QR signage up; the waiting-room display running. See [Hospital communications](/brand/hospital-communications). ### AI (only if the site will use AI features) [#ai-only-if-the-site-will-use-ai-features] Each AI feature passes its gates G-AI-1 to G-AI-6 before it's turned on. See [AI](/admin/ai). ## Frequently asked questions [#frequently-asked-questions] Some settings are locked in production, and changes that reduce privacy need a second approver. Every change is kept in the history and can be reverted. See [Site settings](/admin/settings). Per-clinician step metrics are a private self view for the clinician, shown against blinded peer ranges and never as ranks. See [Analytics](/admin/analytics). Every AI feature is off by default and must pass its governance gates before a site can enable it, with a kill switch per site. See [AI](/admin/ai). The feed health page shows the delay, patients see that updates may be delayed, and staff keep visits current from the manual console. See [Feed health](/admin/integration). The privacy officer runs an access report for the visit and follows the access-request workflow. See [Access requests and retention](/admin/privacy/access-requests-and-retention). When every go-live gate on the checklist above is met. Nobody can override them. See the [pilot playbook](/admin/pilot-playbook). Background reading on the product site: [Measuring ED flow](https://edflow.space/learn/measuring-ed-flow). ## Related [#related] * [For hospitals](/start/for-hospitals) * [Go live](/developers/go-live) for integration teams # EDFlow Mail (https://docs.edflow.space/admin/mail) EDFlow Mail for the company team: shared mailboxes, AI triage of every inbound email, rules, hybrid search, support tickets with auto-acknowledgement, and the rule that mail never carries patient health information. EDFlow Mail is the team email system of the company that runs EDFlow, at https\://mail.edflow\.space. It is for company correspondence (support, partnerships, hospital IT, integration requests), never for patients and never for patient information. Hospital staff don't use it. Mail must never contain personal health information. The info and support mailboxes show a banner and add an automatic footer asking senders not to send personal health information by email. ## Who can use it [#who-can-use-it] Only platform administrators and mail agents (company staff), and only for the mailboxes they are members of. Patient, staff and hospital roles have no access, and anyone else gets "not found" on the mail host. Every read of a message body and every send is audited. ## Mailboxes [#mailboxes] Shared mailboxes for admin, info and support at `edflow.space`. The list comes from configuration, so more can be added without code. Each mailbox has a display name, a signature, members, and an optional auto-acknowledgement. ## The inbox [#the-inbox] A three-pane layout: mailboxes and folders on the left, the message list in the middle, the reading pane on the right. * **Folders**: Inbox, Important, Assigned to me, Snoozed, Sent, Drafts, Archive, Spam, Trash. * **Smart folders** by AI category: Support, Leads, Hospital IT, Integration requests, Security, Notifications, each with a count. * **List rows**: sender, subject, snippet, a one-line AI summary, category chip, importance star (you can override it), priority, ticket number, assignee and time. Tabs: All, Unread, Important. * **Keyboard**: `j`/`k` move, `e` archive, `#` trash, `s` star, `r` reply, `/` search, `g` then `i` inbox. ## Triage [#triage] Every inbound email is parsed and triaged automatically: category, important or not, priority (P1 to P4), spam or phishing, sentiment, language, a summary, extracted organisations, people and products, a suggested reply and proposed actions. SPF, DKIM and DMARC results appear as a badge; failures lean toward spam. **Important** means a real person needs a human response soon, or it concerns security, legal, billing or a hospital partner, or the sender is on the VIP list. Notifications, newsletters, cold outreach and spam are not important. If the triage agent is unavailable, a built-in classifier with the same output takes over, so triage never silently stops. Each result records which path produced it. ## The reading pane [#the-reading-pane] * The message rendered safely (sanitised HTML in a sandbox, remote images blocked until you choose **Load images**), the authentication badge and attachments (executables blocked; downloads through short-lived links). * The **AI panel**: summary, entities, why it's important, proposed actions as buttons (create ticket, assign, label, mark as spam) and a suggested reply. * The reply composer, with **Draft with AI**, the mailbox signature and **Send**. The AI never sends email on its own, never follows instructions inside an email, and never opens links or attachments. A draft always needs a person to send it. ## Rules [#rules] **Settings → Rules** is a visual builder. Conditions: from, to, subject or body patterns, category, important, authentication failure. Actions: label, move, assign, mark important, send the auto-acknowledgement template, create a ticket, notify internally. Rules run before AI triage, in order. **Test against the last 50 emails** previews what a rule would do. ## Search [#search] One search bar with a hybrid AI and keyword toggle. Ask in plain language, for example "emails from a hospital about HL7 last week", and get results plus an **Ask your inbox** answer card that cites the messages it used. ## Tickets and auto-acknowledgement [#tickets-and-auto-acknowledgement] For the support mailbox, a rule can create a ticket number (for example `EDF-000123`) and send the fixed auto-acknowledgement template with it. Ticket status, first response and closing times are tracked. Auto-acknowledgements come only from fixed templates, never from model output. ## Retention [#retention] Spam and trash are purged after 30 days. Everything else is kept per configuration (2 years by default). Admins receive a daily digest at 08:00 Toronto time. ## Related [#related] * [Vulnerability disclosure](/security/vulnerability-disclosure) for security reports * [Subprocessors](/security/subprocessors) # Pilot playbook (https://docs.edflow.space/admin/pilot-playbook) Run a EDFlow pilot in your emergency department: baseline measurement, staff briefing and training mode, posters and QR signage, the first week, the weekly review and the success metrics. A practical plan for the first three months. Adapt it with your pilot sponsor and charge-nurse champions. ## Before go-live (4 to 6 weeks) [#before-go-live-4-to-6-weeks] ### Measure the baseline [#measure-the-baseline] Collect the success-metric baseline with the same definitions you'll use after: the patient survey questions (told why about a long wait, top box, information for after leaving), door-to-doctor, results to decision, LOS, LWBS, family calls to the desk (a sampled tally). See [For hospitals](/start/for-hospitals). ### Configure [#configure] Hospital information, zones and beds, request and code types, the test catalogue, languages and safety locales, notification channels, print stations and the display. Work through the [go-live checklist](/admin). ### Approve content [#approve-content] Your clinical approver reviews and publishes education sheets, going-home templates, task templates and the FAQ. ### Train in training mode [#train-in-training-mode] **Admin → Training** turns training mode on and creates fictional training visits from scenarios. Training visits never notify anyone, never appear on the real board or in analytics, and are marked "Training" everywhere. Every staff member in the pilot zones practises: the queue, the urgent path, codes, cards, pairing, pause updates and call-backs. ### Brief staff [#brief-staff] A 10-minute briefing per shift: what patients see and don't see, "I feel worse" always goes to a person first, never photograph the board, where help is. Use [What patients see](/staff/what-patients-see) and the role quick-reference cards. ## Signage [#signage] * Posters in the waiting room and triage with the QR code to learn more, and the not-an-emergency message. * Card stock at every print station. * The waiting-room display running. See [Hospital communications](/brand/hospital-communications). _Screenshot pending: waiting-room-display_ ## The first week [#the-first-week] * Charge-nurse champion on every shift. * Check daily: cards printed, activation rate, urgent response times, any safety concern reported. * Keep a log of patient questions to improve the FAQ. ## The weekly review [#the-weekly-review] ![Admin overview: today's volume, median waits by segment, open requests, feed health and the go-live checklist.](https://docs.edflow.space/screenshots/web/admin-overview.png) | Look at | Where | | ----------------------------------------------------------- | -------------------------------------------------------------------- | | Activation and the equity gap | [Adoption and equity](/admin/analytics/adoption-and-equity) | | Urgent in-person response, SLA compliance, alerts per nurse | [Requests](/admin/analytics/requests) | | Main bottleneck and results to decision | [Flow and bottlenecks](/admin/analytics/flow-and-bottlenecks) | | Estimate coverage | [Estimate quality](/admin/analytics/estimate-quality) | | Survey answers and comments | [Feedback](/admin/analytics/feedback) | | Safety concerns, data issues | Admin safety concerns; [Data issues](/admin/integration/data-issues) | Balancing measures (LWBS, 72-hour returns) are checked against the stop rule agreed with the research ethics board. ## Success metrics [#success-metrics] ## Related [#related] * [For hospitals](/start/for-hospitals) * [Measuring ED flow](https://edflow.space/learn/measuring-ed-flow) # Reports and exports (https://docs.edflow.space/admin/reports-and-exports) De-identified exports from EDFlow (visit facts, test turnaround, request facts, feedback, code log), how they are de-identified, the export log, single-use downloads and scheduled reports. ![Exports and scheduled reports: de-identified exports and weekly reports with recipients.](https://docs.edflow.space/screenshots/web/admin-reports.png) ## Exports [#exports] With `analytics.export`, request a CSV of: * visit facts; * test turnaround samples; * request facts; * feedback answers (comments only once reviewed); * the code log. ## How exports are de-identified [#how-exports-are-de-identified] * No names, identifiers or hashes. * Dates shifted or reduced to weekday and hour; ages in bands. * Any cell with fewer than 5 visits suppressed. * A random study id per export, so two exports can't be joined. ## The export log [#the-export-log] Who, what, when, and status (queued, running, ready, failed, expired). Files are deleted after 24 hours. Downloads use a single-use link after you sign in. Every export is audited. ## Scheduled reports [#scheduled-reports] Scheduled weekly summaries are part of release 1.1. A weekly PDF summary of the key metrics by email, with no patient information. Where the site turns on AI, a draft weekly narrative can accompany it; a manager reviews it before it's shared. ## Audit and visit-record exports [#audit-and-visit-record-exports] These are privacy exports, not analytics: see [Privacy officers](/admin/privacy). # Users and access (https://docs.edflow.space/admin/users-and-access) Manage EDFlow staff accounts: invites, roles and the full permission matrix, approvals for privileged roles, deactivation, unlock and MFA reset, bulk import and SCIM, and the quarterly access review. ## Users [#users] ![Users: staff with roles, status and last sign-in, with filters and Invite.](https://docs.edflow.space/screenshots/web/admin-users.png) The users list shows name, email, roles, clinician type, status (invited, pending approval, active, deactivated, locked), sites, last sign-in, MFA status, SSO link, provisioning source and flags. Search by name or email prefix; filter by role and status. With `users.manage` you can: * edit roles and clinician type (privileged roles need approval); * deactivate or reactivate (deactivation revokes sessions and unused credentials the user issued at once); * **unlock** a locked account, **reset MFA**, force a password reset, sign out all sessions; * edit EHR identity links (with confirmation; alerts the privacy officer); * mark someone **hidden from patients**, approve a photo or display-name change, and mark a **clinical approver**. ![User detail: roles, site memberships, MFA status and sessions, with Deactivate and Reset MFA.](https://docs.edflow.space/screenshots/web/admin-user-detail.png) You can't remove your own manager role if you're the site's last manager. Every change is audited with before and after values. ## Invites [#invites] ![Invites: pending staff invites with role, expiry and Resend or Cancel.](https://docs.edflow.space/screenshots/web/admin-invites.png) Invite up to 20 emails at once with roles, clinician type and an optional message (500 characters, no links or phone numbers). Invites expire after 72 hours; **Resend** invalidates the previous link. Addresses outside the site's staff email domains need a second manager's approval before anything is sent. ## Roles and permissions [#roles-and-permissions] The full matrix, generated from the product's permission catalogue: | Permission | R-TRIAGE | R-NURSE | R-PHYSICIAN | R-CHARGE | R-CLERK | R-SUPPORT | R-MANAGER | R-PRIVACY | R-INTEGRATION | R-INTEGRATION-DEVELOPER | R-SUPER | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | board.view | Granted | Granted | Granted | Granted | Conditional | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | patient.view | Granted | Granted | Granted | Granted | Conditional | Not granted | Granted | Conditional | Not granted | Not granted | Not granted | | patient.unmask | Granted | Granted | Granted | Granted | Granted | Not granted | Granted | Granted | Not granted | Not granted | Not granted | | patient.register | Granted | Not granted | Not granted | Granted | Granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | patient.state | Granted | Granted | Granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | patient.override | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | patient.lifecycle | Not granted | Not granted | Not granted | Granted | Conditional | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | careteam.assign | Granted | Granted | Granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | zones.assign | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | results.release | Not granted | Not granted | Granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | tasks.manage | Granted | Granted | Granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | avs.compose | Not granted | Granted | Granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | avs.medications | Not granted | Not granted | Conditional | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | access.card | Granted | Granted | Granted | Granted | Granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | access.revoke | Not granted | Not granted | Not granted | Granted | Granted | Not granted | Granted | Granted | Not granted | Not granted | Not granted | | share.manage | Granted | Granted | Granted | Granted | Not granted | Not granted | Granted | Granted | Not granted | Not granted | Not granted | | privacy.flag | Granted | Not granted | Not granted | Granted | Granted | Not granted | Granted | Granted | Not granted | Not granted | Not granted | | patient.restrict | Granted | Granted | Granted | Granted | Not granted | Not granted | Granted | Granted | Not granted | Not granted | Not granted | | updates.pause | Not granted | Not granted | Granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | patient.callback | Granted | Granted | Granted | Granted | Granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | request.view | Granted | Granted | Granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | request.act | Granted | Granted | Granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | request.bulk | Granted | Granted | Not granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | code.call | Not granted | Not granted | Granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | code.clear | Not granted | Not granted | Granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | code.notice | Granted | Granted | Granted | Granted | Granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | support.queue | Not granted | Not granted | Not granted | Granted | Not granted | Granted | Granted | Not granted | Not granted | Not granted | Not granted | | volume.set | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | analytics.view | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | analytics.self | Not granted | Conditional | Conditional | Conditional | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | analytics.clinician_blinded | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Conditional | Not granted | Not granted | Not granted | Not granted | | analytics.clinician_named | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Conditional | Not granted | Not granted | Not granted | Not granted | | analytics.export | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Granted | Not granted | Not granted | Not granted | | users.view | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Granted | Granted | Not granted | Not granted | Not granted | | users.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | users.import | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | settings.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | config.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | stations.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | approvals.decide | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Conditional | Conditional | Not granted | Not granted | Conditional | | training.manage | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | content.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | content.approve | Not granted | Not granted | Conditional | Conditional | Not granted | Not granted | Conditional | Not granted | Not granted | Not granted | Not granted | | announcements.manage | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | integration.view | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Granted | Not granted | Granted | Conditional | Not granted | | integration.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | | audit.view | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Granted | Not granted | Not granted | Not granted | | audit.export | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | | privacy.legal_hold | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | | privacy.incident | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | | privacy.emergency_revoke | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Granted | Not granted | Not granted | Not granted | | outbox.view | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Granted | Granted | Not granted | Not granted | | access_review.run | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Granted | Not granted | Not granted | Not granted | | simulator.use | Not granted | Not granted | Not granted | Conditional | Not granted | Not granted | Conditional | Not granted | Conditional | Not granted | Conditional | | seed.reset | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Conditional | Not granted | Not granted | Not granted | Conditional | | platform.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | | developers.view | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Conditional | Granted | Granted | Not granted | | developers.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Granted | Not granted | | developers.credentials | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Conditional | Not granted | | developers.approve | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Not granted | Granted | Not granted | Not granted | | developers.attest_pia | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | | developers.accept_affiliation | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Granted | Not granted | Granted | Not granted | Not granted | | ai.safety_review | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | Conditional | Not granted | Not granted | Not granted | **Separation of duties**: a privacy officer can't also hold a manager or clinical role. Granting manager, privacy or integration roles creates an approval request that a different eligible person approves. ## Approvals [#approvals] **Approvals** lists pending, approved, rejected and expired two-person requests: privileged role grants, external-domain invites, audit and visit-record exports, trust-anchor changes (like the main phone), patient-facing announcements and tenant offboarding. Requests expire after 72 hours. Nobody can approve their own request, and approving needs a fresh sign-in check. ## Bulk import and directory provisioning [#bulk-import-and-directory-provisioning] * **Import**: upload a CSV (email, given name, family name, roles, clinician type, zone). Every row is validated; if any row fails, nothing is created. * **Provisioning**: a SCIM 2.0 endpoint for Microsoft Entra ID or another IdP, with a site-scoped token revealed once. A user disabled in the directory is deactivated within 5 minutes. ## Quarterly access review [#quarterly-access-review] ![Quarterly access review: each user with roles and last sign-in, and Keep or Remove decisions recorded.](https://docs.edflow.space/screenshots/web/admin-access-review.png) Review every active membership (roles, last sign-in, MFA, source), mark each keep, change or remove, then attest with your name and date. The page shows **Overdue** 90 days after the last attestation. ## Related [#related] * [Sign-in and security](/staff/sign-in-and-security) * [Identity and SSO](/security/identity-and-sso) # Hospital communications (https://docs.edflow.space/brand/hospital-communications) Posters, QR signage, visit cards, the waiting-room display and co-branding rules for hospitals running EDFlow, with the safety messages every piece must carry. Patients learn about EDFlow from what they see in the waiting room. Every piece has the same two safety messages. ## Every piece must say [#every-piece-must-say] 1. **Check in with the triage nurse first.** EDFlow starts after registration. 2. **EDFlow isn't for emergencies. If you feel worse, tell staff now.** Never promise a wait time, a place in line or results. ## Posters and QR signage [#posters-and-qr-signage] * Place posters at triage, registration and in the waiting room at eye level for seated people. * A poster's QR code links to the hospital's public entry page, which explains how to follow a visit and, before registration, leads with "check in with the triage nurse first". It never signs anyone in: only the visit card does. * Protect posters from tampering (framed or laminated, checked each shift). A replaced QR is a phishing risk; the app only accepts EDFlow codes. * English and French, plus the site's safety languages where space allows. ## Visit cards [#visit-cards] _Screenshot pending: visit-card-print_ Cards print at registered print stations: wallet card (85 × 55 mm), thermal label (4 × 2 in) or full sheet. They carry the QR code, the visit code, the hospital name, the patient's initials only, bilingual instructions and the not-an-emergency line. Keep card stock at every print station. Staff never see the code in clear. See [Visit cards](/staff/clerks/visit-cards). ## Waiting-room display [#waiting-room-display] _Screenshot pending: waiting-room-display_ The display shows department-level information only: how busy it is in calm words, how a visit works, how to join, and "Feel worse? Tell the triage nurse now." See [Waiting-room display](/admin/settings/waiting-room-display). ## Co-branding [#co-branding] "EDFlow at \[your hospital]": * the EDFlow lockup, a thin divider, then the hospital's own approved logo, at the same height as the square, with clear space on each side of the divider; * in the product, the hospital name appears as text, never as a second logo competing with the patient's information; * co-branding is production-only and needs a second approver in the admin; * never merge the two logos into one shape. ## Words to use [#words-to-use] | Use | Avoid | | -------------------------------------- | ---------------------------------- | | "Follow your visit on your phone" | "Track your wait", "skip the line" | | "See how long this step usually takes" | "Know exactly when you'll be seen" | | "Share updates with family" | "Your family can see everything" | | "Results are back" (never the results) | "Get your results" | ## Related [#related] * [Pilot playbook](/admin/pilot-playbook) * [Press kit](/brand/press-kit) # Brand (https://docs.edflow.space/brand) EDFlow brand at a glance for hospital communications teams: the name, the logo and mark, colours, fonts, voice, and links to the full brand book and the live design language. This section is for hospital communications and patient-education teams who put EDFlow on posters, cards, websites and patient materials. ## At a glance [#at-a-glance] | | | | ------------ | --------------------------------------------------------------------- | | Name | EDFlow | | Tagline | Every step of your ED visit, in view. | | Product line | EDFlow | | Legal name | EDFlow | The name, logo and web addresses on this page come from the brand configuration, so they're always current. ## The logo [#the-logo] * Use the supplied files; never retype the logo in a font. * Use the dark version on dark or mid-tone backgrounds; never recolour it by hand. * Keep clear space of at least one unit (the height of the square's corner radius) around it, and more next to another logo. * Don't pair it with medical clichés (crosses, heartbeats, stethoscopes, pills), add effects, or use it as a bullet or a status indicator. ![Brand page: the product name, logo, colours and fonts from the brand configuration.](https://docs.edflow.space/screenshots/web/brand-page.png) ## Colours and type [#colours-and-type] Paper by day, night after dark: calm neutrals with one warm signal for "you are here". Status is never shown by colour alone, and results are never styled as good news. The full palette, type scale and components are in the live design language. ![Design language gallery: tokens, status colours and components in light and dark.](https://docs.edflow.space/screenshots/web/design-gallery.png) ## Voice [#voice] Calm, clear (grade 6 to 8 for patients), honest about uncertainty, kind, actionable and brief. See [Writing patient content](/brand/writing-patient-content). ## Full references [#full-references] * The brand book: [https://edflow.space/brand](https://edflow.space/brand) * The live design language: [https://edflow.space/design](https://edflow.space/design) ## Related [#related] * [Hospital communications](/brand/hospital-communications) * [Press kit](/brand/press-kit) # Press kit (https://docs.edflow.space/brand/press-kit) EDFlow logos, a curated screenshot pack captured from fictional sample data, and boilerplate text for articles, hospital newsletters and announcements. ## Logos [#logos] | File | Use | | ----------------------------------------------------------------- | ------------------------------- | | [Lockup, light](https://docs.edflow.space/brand/lockup-light.svg) | On light backgrounds | | [Lockup, dark](https://docs.edflow.space/brand/lockup-dark.svg) | On dark or mid-tone backgrounds | More formats (PNG, the mark alone, the app icon) are in the brand book at [https://edflow.space/brand](https://edflow.space/brand). ## Screenshots [#screenshots] The screenshot pack is built from the entries marked for the press kit in the screenshot manifest: the patient's Visit screen, the family view, the staff board and the analytics overview, in light and dark. Every image comes from the fictional docs data set and carries a "Sample data" watermark. Don't crop the watermark, and never present a screenshot as a real patient's visit. ![Visit screen: the current step is Tests under way, with what happens next, the care team card, a usual wait range and the I feel worse button.](https://docs.edflow.space/screenshots/web/patient-visit-home.png) ![Live board: patients by zone with stage, time in department, assigned clinician, tests, open requests and bottleneck flags, with filters and saved views.](https://docs.edflow.space/screenshots/web/staff-board.png) ## Boilerplate [#boilerplate] **Short.** EDFlow helps emergency department patients and their families follow the visit on their phone: where they are, who is caring for them, and how long each step usually takes. Every step of your ED visit, in view. **Long.** EDFlow is a live, plain-language companion to an emergency department visit. Patients scan the QR code on their wristband or visit card to see their step in the visit, their care team, their tests and the usual waits for this day and hour, with no app and no account. They can ask their care team for things and share a short version of their visit with family. They never see results. Care teams get a live board, a request queue and flow analytics, and the product works with or without an EHR feed. Hospital data stays in Canada. ## Rules for media use [#rules-for-media-use] * Use the supplied logos unchanged. * Don't show a real patient's screen or a real hospital's staff board. * Say that it isn't an emergency channel whenever you describe the "I feel worse" button. ## Related [#related] * [Brand](/brand) * [Hospital communications](/brand/hospital-communications) # Writing patient content (https://docs.edflow.space/brand/writing-patient-content) Voice, tone and word choices for hospital authors writing EDFlow patient content (education sheets, going-home templates, FAQ, announcements), with French typography rules and the words never to use. Everything a hospital writes for patients in EDFlow (education sheets, going-home templates, task templates, FAQ, hospital information, announcements) goes through clinical review. Writing it well first makes review faster. ## Principles [#principles] | Principle | Write | Don't write | | ------------------------ | ------------------------------------------------------------------- | -------------------------------------------- | | Calm | "Your blood work is in the lab." | "Tests pending!!" | | Clear (grade 6 to 8) | "A CT scan is a detailed X-ray." | "CT w/ contrast ordered, pending protocol." | | Honest about uncertainty | "Usually 30 to 55 minutes at this time on a Tuesday." | "Results in 30 minutes." | | Kind, never blaming | "Thank you for your patience. The department is very busy tonight." | "Waits are longer due to non-urgent visits." | | Actionable | "Give a urine sample when you can. Ask your nurse for a cup." | "Urinalysis required." | | Brief | One idea per sentence. Put the answer first. | "Please be advised that…" | ## For patients [#for-patients] * Second person, present tense, active voice. * Explain a medical word in brackets the first time it appears. * No exclamation marks (except a genuine welcome) and no emoji. * Never say or interpret results. Say they're back and who will explain them. * Every sheet ends with the reminder that it doesn't replace talking with the care team. ## For family [#for-family] Even shorter. The step, a rough wait, first names and roles at most. Never tests, results or clinical detail. ## Word list [#word-list] | Use | Avoid | | ----------------------------------------------------------------- | -------------------------------------------------------------------- | | doctor (physicians only); nurse practitioner; physician assistant | MD, provider; "doctor" for someone who isn't a physician | | care team | treatment team | | test, blood work, scan | investigation, labs | | results are back | results are complete, final, normal, fine | | usually; most people (9 in 10) within | guaranteed, expected by, at the longest, up to, you're next, average | | waiting room, your spot | bay, pod, zone codes | | going home | dispo, D/C | | request, ask for | ticket, order | The admin's content editor warns on banned words and shows a reading-level score. ## French [#french] * Canadian French, written by a human translator and reviewed clinically. Machine drafts are never published unreviewed. * Inclusive forms that stay readable: « une infirmière ou un infirmier », « l'équipe de soins ». Avoid the median dot in patient text: screen readers stumble on it. * Times `14 h 30`; durations `20 à 40 min`; numbers `1 250,5` with a narrow no-break space. * A no-break space before `:` and inside « guillemets »; no space before `;`, `!` or `?`. * Sentence case for titles. * Plan for French running 20 to 30% longer than English. ## Sensitive moments [#sensitive-moments] For delays, "I feel worse", results back, a busy department, paused updates and offline states, use the product's own canonical wording. Don't write your own versions. See [Safety](/start/safety). ## Related [#related] * [Patient content](/admin/settings/patient-content) * [What patients want to know](https://edflow.space/learn/what-patients-want-to-know) # AI mapping assistant (https://docs.edflow.space/developers/ai-mapping-assistant) Use the EDFlow mapping assistant to draft a site mapping profile from sample HL7 v2, FHIR or CSV: synthetic samples only in the sandbox, allow-list scrubbing, a proposed profile validated against the event schema, and nothing applied without review. The mapping assistant helps you write or fix a [mapping profile](/developers/mapping-profiles) from a sample message. It proposes a change, proves it with the real adapter, and waits for you to save it. ![Mapping assistant: a sample HL7 v2 message with a suggested mapping profile, each field checked against the event schema and waiting for review.](https://docs.edflow.space/screenshots/web/dev-ai-mapping-assistant.png) ## Where it runs [#where-it-runs] * **Sandbox**: synthetic samples only. The sandbox's synthetic-only checks run first; the page says "Synthetic samples only. Real messages are refused." * **Customer test and live**: off until the hospital's privacy office records its approval for this feature, because a sample from a hospital feed is personal health information until proven otherwise. ## Steps [#steps] ### Paste a sample [#paste-a-sample] HL7 v2, a FHIR R4 Bundle, or CSV (for a catalogue or historical benchmark import), up to 64 KB. ### See what was kept [#see-what-was-kept] The sample is scrubbed **by allow-list** before anything else: only the fields a mapping profile can use are kept (message header, event times, patient class, location components, disposition, arrival and departure times, order codes and status, timing, specimen codes, role codes). Every identifier, name, date of birth and all free text becomes a typed placeholder; timestamps are shifted. If anything still looks like personal information, the whole sample is refused. A notice shows what was kept and replaced. ### Review the proposal [#review-the-proposal] The current profile runs through the real adapter first. The assistant then proposes a change to the profile, explains each part, and re-runs the adapter with it: every resulting event is validated against the event schema and the prohibited-field tripwire. It shows the diff, the events by type with pass or fail, and the gaps (codes with no catalogue entry, triggers not handled, fields missing for a milestone). ### Save as a testing version [#save-as-a-testing-version] **Save as new profile version (testing)** needs `integration.manage` and your explicit approval. It never activates a profile. A proposal that produces any invalid event can't be saved. ## From the unmapped codes list [#from-the-unmapped-codes-list] On [Unmapped codes](/admin/integration/unmapped-codes), the assistant can suggest a catalogue entry for a code from its code system and display text. Nothing is mapped until you accept it. ## What it doesn't do [#what-it-doesnt-do] * Read real patient data in the sandbox. * Activate a profile, map a code or change the catalogue without you. * Open links or follow instructions contained in a sample. ## Related [#related] * [AI governance](/security/ai) * [HL7 v2](/developers/hl7v2), [FHIR R4](/developers/fhir) # Authentication (https://docs.edflow.space/developers/authentication) Authenticate to the EDFlow Integration API: OAuth 2.0 client credentials with private_key_jwt, client secret or mTLS, short-lived JWT access tokens, scopes, network binding, HMAC source keys for the signed ingest profile, clock skew, lockouts and signing at send time. There are two credential families: * **API credentials** for the REST API (`/v1/*`): OAuth 2.0 client credentials that return a 5-minute JWT access token, or (in limited cases) a static API key. * **HMAC source keys** for the signed ingest profile (`/ehr/v1/*`), for engines already built to it. ## Methods [#methods] | Method | How | Recommended for | Live policy | | ------------------------------------------------------- | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------- | -------------------------------------------------------------------------- | | `private_key_jwt` | Sign a JWT assertion with your private key; register a JWKS URL or public keys | EMR vendors, Epic and Oracle system accounts, anyone who can sign JWTs | Always allowed. **Recommended** | | `client_secret_basic` / `client_secret_post` | Client id and secret | Engines that can't sign JWTs | Only with an enforced IP allowlist or mTLS, and never for sensitive scopes | | mTLS (`tls_client_auth`, `self_signed_tls_client_auth`) | Client certificate on the mTLS host; the token is bound to it | Hospitals that mandate mutual TLS | Always allowed | | Static API key | `Authorization: Bearer edf_{env}_sk_…` | Prototypes, simple reads, FHIR subscription rest-hooks | Off by default; IP allowlist and ≤ 90-day expiry when allowed | | HTTP Basic with an API key | `client_id:api_key` | HL7-over-HTTP senders that only do Basic | As static keys, `/v1/hl7v2` only | | HMAC source key | Per-request signature over the raw body | Engines built to `/ehr/v1/*` | IP allowlist required; key versions expire within 365 days | _Screenshot pending: dev-console-create-credential_ ## Get a token [#get-a-token] `POST /oauth/token` with `grant_type=client_credentials`. Optional `scope` narrows the token. ### private\_key\_jwt [#private_key_jwt] The assertion: header `alg` RS384, ES384, RS256 or ES256 and a `kid` from your registered keys; `iss` and `sub` equal your client id; `aud` is **exactly** the token endpoint URL (`https://api.edflow.space/oauth/token` in live); `exp` at most 5 minutes ahead; a unique `jti`. ```ts import { importPKCS8, SignJWT } from "jose"; const tokenUrl = `${process.env.EDFLOW_API_BASE_URL}/oauth/token`; const key = await importPKCS8(process.env.EDFLOW_PRIVATE_KEY_PEM ?? "", "ES384"); const assertion = await new SignJWT({}) .setProtectedHeader({ alg: "ES384", kid: process.env.EDFLOW_KEY_ID ?? "", typ: "JWT" }) .setIssuer(process.env.EDFLOW_CLIENT_ID ?? "") .setSubject(process.env.EDFLOW_CLIENT_ID ?? "") .setAudience(tokenUrl) .setJti(crypto.randomUUID()) .setIssuedAt() .setExpirationTime("4m") .sign(key); const res = await fetch(tokenUrl, { method: "POST", headers: { "content-type": "application/x-www-form-urlencoded" }, body: new URLSearchParams({ grant_type: "client_credentials", client_assertion_type: "urn:ietf:params:oauth:client-assertion-type:jwt-bearer", client_assertion: assertion, scope: "requests:read requests:write", }), }); const { access_token, expires_in } = await res.json(); ``` The portal can generate a key pair in your browser and download the private key; only the public key is sent. Prefer a JWKS URL: you rotate by publishing a new `kid`. ### Access tokens [#access-tokens] JWTs (RFC 9068) signed by EDFlow, valid 60 to 300 s (default 300). They carry your organization, sites, scopes, environment, the credential used and your pinned API version. Every request re-checks the app, the credential and the site, so revocations and scope reductions apply immediately, not at expiry. Cache the token and refresh 30 s before it expires. Discovery: `/.well-known/oauth-authorization-server` (RFC 8414), `/oauth/jwks.json`, and `/v1/fhir/.well-known/smart-configuration` for SMART Backend Services clients. ## Scopes [#scopes] | Scope | Grants | Sensitive | | ------------------------------------------- | ------------------------------------------------ | ------------ | | `events:write`, `fhir:write`, `hl7v2:write` | Ingest | | | `events:validate` | Dry-run validation | | | `events:read` | Ingest results (metadata only) | | | `encounters:read` | Encounter workflow state, lookup by visit number | ✓ | | `careteam:read` | Current care team | ✓ | | `requests:read`, `requests:write` | Patient requests feed; acknowledge and resolve | ✓ | | `tasks:read` | Patient tasks | ✓ | | `codes:read` | Department code alerts | | | `documents:read` | Visit documents | ✓ | | `webhooks:read`, `webhooks:write` | Webhook management | | | `sandbox:write` | Sandbox simulation and reset | Sandbox only | **Sensitive scopes** need `private_key_jwt` or mTLS, a four-eyes approval and the privacy office's PIA attestation in live, and the site's capability switch. A token obtained with a client secret never carries them. ## Network binding [#network-binding] In customer test and live every app must have at least one of: `private_key_jwt` with registered keys, mTLS, or an IP allowlist. A leaked client secret is useless from any address outside the allowlist. ## The signed ingest profile [#the-signed-ingest-profile] Requests to `/ehr/v1/*` carry `EDFlow-Source`, `EDFlow-Delivery-Id` (new for each attempt), `EDFlow-Timestamp` and `EDFlow-Signature`: ```text signedPayload = "v2." + timestamp + "." + deliveryId + "." + METHOD + " " + path + "." + (siteCode or "-") + "." + (input or "-") + "." + lowercase_hex(SHA-256(raw body)) signature = lowercase_hex(HMAC-SHA256(sourceKey, signedPayload)) header = "EDFlow-Signature: v2=" + signature ``` The key is the 32 raw bytes of the 64-hex key revealed once in the admin console, not the ASCII of the hex. Sign the exact bytes you send. During a rotation you may send two signatures separated by a comma. Verify your implementation against the [conformance test vector](/developers/sdks-and-snippets#test-vector). ## Sign and authenticate at send time [#sign-and-authenticate-at-send-time] Engines retry from queues that can hold hours of messages. **Compute the signature and fetch or refresh the token in the step that sends the request** (a Mirth/OIE JavaScript Writer or destination pre-send script; a Rhapsody or Cloverleaf send-time script), never in the transformer, whose output queued retries replay unchanged. | Response | What it means | Do this | | -------------------------------------------------------------------------- | ------------------------------------------ | --------------------------------------------------------------------- | | `401 token_expired` (`retryAction: reauthenticate`) | Token expired while queued | Fetch a new token, resend the same request | | `401 timestamp_out_of_window`, `delivery_replayed` (`retryAction: resign`) | Signed too long ago, or delivery id reused | Re-sign with a new timestamp and delivery id; event ids stay the same | | `401 invalid_client`, `invalid_token` | Wrong credential | Fix it; don't loop | An exact replay of a signed delivery that was already processed returns the stored result, so a client that timed out learns what happened. ## Clock skew [#clock-skew] Timestamps more than 5 minutes from EDFlow's clock are refused. Keep engine clocks on NTP and compare with `GET /ehr/v1/health` at startup. ## Lockouts [#lockouts] Ten failed authentications in 5 minutes from one `(client id, IP)` pair lock that pair for 15 minutes; 50 from one IP lock that IP. A lockout never blocks a valid credential, an allowlisted address or a registered mTLS certificate, so nobody can lock your integration out by guessing. _Screenshot pending: dev-console-secret-reveal_ ## Related [#related] * [Credentials](/developers/credentials): lifecycle, rotation and what to do if a key leaks * [Errors](/developers/errors) # Build with AI (https://docs.edflow.space/developers/build-with-ai) Point Claude Code, Cursor or another coding assistant at the EDFlow docs: llms.txt, llms-full.txt, a Markdown version of every page, the docs MCP server, and the rules to give your agent. These docs are built to be read by coding assistants as well as people. ## Machine-readable docs [#machine-readable-docs] | Resource | What it is | | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`/llms.txt`](/llms.txt) | An index of every page with a one-line description | | [`/llms-full.txt`](/llms-full.txt) | Every page in one Markdown file (under 5 MB) | | Any page + `.md` | The Markdown version of that page, for example [`/developers/quickstart.md`](/developers/quickstart.md). Requests with `Accept: text/markdown` get Markdown too | | [OpenAPI document](/openapi/edflow-v1.json) | The API contract the handlers validate against | | Event JSON Schemas | Linked from every [event page](/developers/events) | Generated tables (event types, errors, settings, roles) are rendered as real Markdown tables in these versions. ## The docs MCP server [#the-docs-mcp-server] The docs expose a stateless MCP endpoint at `https://docs.edflow.space/api/mcp` (Streamable HTTP, JSON responses) with three tools: `list_pages`, `get_page` and `search`. Everything it returns is public documentation. Claude Code: ```bash claude mcp add --transport http docs https://docs.edflow.space/api/mcp ``` Cursor (`.cursor/mcp.json`): ```json { "mcpServers": { "docs": { "url": "https://docs.edflow.space/api/mcp" } } } ``` ## Rules to give your agent [#rules-to-give-your-agent] Paste these into your agent's instructions when it writes integration code: * Use only synthetic data. In the sandbox, identifiers start with `SYN` and names are synthetic. * Never send result values, notes, diagnoses, medications, allergies, health card numbers, addresses, phones or emails: they are prohibited fields. * Event ids are deterministic and never contain patient identifiers. * Sign requests and fetch tokens at send time, not in a transformer. * Retry only `5xx`, `429`, `token_expired` and re-sign errors, with backoff and `Retry-After`. * Verify webhooks with a Standard Webhooks library against the raw body; deduplicate on `webhook-id`; keep the highest `version`. * Never paste real messages, credentials or patient data into an AI tool. ## Ask the docs [#ask-the-docs] The **Ask the docs** button answers questions from these pages and cites them. It can't see any hospital's data. Never paste real HL7, FHIR or patient data into it; it refuses those. ## Related [#related] * [SDKs and snippets](/developers/sdks-and-snippets) * [AI mapping assistant](/developers/ai-mapping-assistant) # Concepts (https://docs.edflow.space/developers/concepts) How the EDFlow integration model works: sites, sources, encounters and events, facts and derived stages, projections and minimum necessary data, idempotency, ordering and precedence, and the early-arrival buffer. ## The data flow [#the-data-flow] ```mermaid flowchart LR EHR[EHR: Epic, Oracle Health, MEDITECH] -->|HL7 v2, FHIR| ENG[Hospital integration engine] ENG -->|events, FHIR, HL7 over HTTPS| ING[Ingest: /v1 or /ehr/v1] CON[Staff console] -->|manual events| PIPE SIM[Simulator, sandbox only] --> PIPE ING --> PIPE[One pipeline: validate, tripwire, idempotency, apply] PIPE --> FACTS[(Facts by precedence)] FACTS --> STAGE[Derived stage, tasks, care team, results state] STAGE --> PROJ[Projections] PROJ --> PT[Patient view] PROJ --> FAM[Family view] PROJ --> STAFF[Staff board] PROJ --> API[Integration API and webhooks] ``` Every ingest path (normalized events, FHIR, HL7 v2, the signed profile, the staff console and the simulator) ends in the same pipeline. Transport and authentication differ; semantics don't. ## Sites and sources [#sites-and-sources] * A **site** is one emergency department, addressed by its code (for example `kb-main-ed`). * A **source** is one sender, usually one engine channel. It is bound to the sites and event types it may send, and to a versioned **mapping profile**. * An **app** (for the REST API) belongs to one organization and one environment, and is bound to up to 50 sites. An app with ingest scopes is linked to one source. ## Encounters and events [#encounters-and-events] * An **encounter** is one ED visit, identified by your EHR's visit identifier (Epic CSN, Oracle FIN, MEDITECH account or visit number). EDFlow hashes it on receipt and returns its own opaque id (`enc_…`). * An **event** asserts current state: "the patient arrived at 08:02", "the triage was CTAS 3 at 08:15", "this order is in the lab". Events are not deltas. * 23 event types cover arrival, triage, location, assessment, disposition, departure, cancellation, patient updates, merges, care team, orders and their status, consults, admission, codes, census, roster and heartbeat. See [Events](/developers/events). ## Facts, stages and projections [#facts-stages-and-projections] 1. Accepted events update **facts**, grouped (arrival, triage, location, assessments, disposition, lifecycle, each order, each consult, care-team members). 2. EDFlow re-derives the **stage**, tasks, care team and results state from the facts. 3. Each audience reads through its own **projection**: patients, family, staff, the waiting-room display and API clients each get an allow-listed view. API clients never receive names, dates of birth, CTAS, chief complaint, free text or result content. ## Minimum necessary [#minimum-necessary] * Result values, notes, diagnoses, medications, allergies, health card numbers, addresses, phones and emails are **prohibited fields**: an event containing any of them, at any depth, is rejected before anything is stored. * Family name and date of birth are used only to build a match key for patient sign-in, then discarded. * The FHIR and HL7 adapters drop these elements before mapping. ## Idempotency [#idempotency] * The key is `(source, event id)`, kept for 30 days. * Same id and same payload: `duplicate`, nothing changes. * Same id, different payload: `idempotency_conflict`, unless the mapping profile changed or it's a dead-letter replay, in which case the new payload **supersedes** through normal precedence. * Ids must be deterministic from source data, so retries and replays produce the same ids, and must never contain patient identifiers. ## Ordering and precedence [#ordering-and-precedence] Events can arrive in any order. For each fact group, the assertion with the greatest precedence wins: record time, then status rank (orders only), then sequence, then receive time. * An older assertion that arrives late never overwrites newer state, but can fill a missing timestamp. * A later-recorded correction wins, even if it "goes backwards" (for example a corrected triage time). * Order status only moves forward unless the event is a correction, a cancellation or an explicit reversal. * Terminal states (departed, cancelled) are reversed only by an explicit event or a staff reopen. * Patient notifications fire once per milestone, on the first transition. Corrections update what's shown without notifying again. ## The early-arrival buffer [#the-early-arrival-buffer] An event for an encounter or order EDFlow doesn't know yet is **buffered** for up to 6 hours (at most 500 per encounter) and applied when the parent arrives. After 6 hours it is dead-lettered and you're alerted. Result events that carry the order's code and category create the order, so result feeds never depend on the order feed. ## Live and backfill [#live-and-backfill] * `live` (default): state updates and notifications. Live events more than 30 minutes old update state silently. * `backfill`: for the go-live census sync and outage recovery. State and analytics update; **nothing is ever notified**. ## Feed health and reconciliation [#feed-health-and-reconciliation] * Send `system.heartbeat` every 60 s per feed. After 5 minutes of silence the feed is **delayed**, after 15 minutes **down**. * Send `department.roster_reported` every 15 minutes. An active encounter missing from two consecutive complete rosters is closed quietly. A roster that would close too many encounters at once is quarantined for review. ## Related [#related] * [Event reference](/developers/events) * [Engine configuration](/developers/engine-configuration) * [Data flow](/security/data-flow) for reviewers # Credentials (https://docs.edflow.space/developers/credentials) Manage EDFlow API credentials: self-serve in the developer portal or issued by the hospital or the vendor, shown once, rotation with overlap, expiry reminders, revocation, and what to do if a key leaks. ![Credentials and keys: each credential with its type, prefix, created date and last use.](https://docs.edflow.space/screenshots/web/dev-console-credentials.png) ## Where credentials come from [#where-credentials-come-from] | Path | Who | Notes | | ---------------------------------------------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Self-serve** in the developer portal | Integration developers | Sandbox apps are active at once. Customer-test and live apps need approval by a different person first | | **Issued to an EMR team** by the platform operator | Your EDFlow contact | Zero-knowledge: no secret exists until the recipient signs in and presses **Reveal**. Or the team registers a public key and no secret is ever created | | **HMAC source keys** by the hospital's integration analyst | Integration analysts | For `/ehr/v1/*`. See [Sources and keys](/admin/integration/sources-and-keys) | ![Sources and keys: registered sources with status, key versions and last use, and Rotate and Disable.](https://docs.edflow.space/screenshots/web/admin-integration-sources.png) ## Formats [#formats] | Credential | Format | Secret? | | ---------------------- | -------------------------------- | --------------- | | Client id | `edf_{env}_cli_…` | No, public | | Client secret | `edf_{env}_cs_…` with a checksum | Yes, shown once | | API key | `edf_{env}_sk_…` with a checksum | Yes, shown once | | Webhook signing secret | `whsec_…` | Yes, shown once | | Access token | JWT | Yes, 5 minutes | `{env}` is `test` (sandbox), `uat` (customer test) or `live`. The prefix and checksum let secret scanners detect leaked credentials with almost no false positives. ## Lifecycle [#lifecycle] ```mermaid stateDiagram-v2 [*] --> active: create (shown once) [*] --> pending_reveal: issued by the platform pending_reveal --> active: recipient reveals active --> expiring: rotate (overlap starts) expiring --> expired: overlap ends active --> expired: expiry date reached active --> revoked: revoke (immediate) expiring --> revoked: revoke ``` * **Shown once.** The reveal dialog offers Copy and **Download .env** and asks you to confirm you've stored it. Afterwards only the prefix and last 4 characters are visible, everywhere. * **Rotate with overlap**: a new credential; the old one keeps working for the overlap you choose (1 hour, 24 hours, 7 days by default, or 30 days). **Last used** for each shows when the old one goes quiet, so you can end the overlap early. * **Expiry**: live client secrets 365 days, API keys 90 days. Reminders by email and by the `integration.credential_expiring` webhook at 30, 7 and 1 days. * **Revoke**: immediate. Every token minted with it fails on its next use. * **Public keys**: a JWKS URL (recommended) or up to 5 uploaded keys (RSA 2048+ or EC P-256/P-384). * **mTLS**: up to 4 certificate thumbprints, or a subject DN with your organization's CA bundle. Revealing and rotating in customer test and live needs a fresh sign-in check, an approved app, and a person who isn't the app's approver. ## If a key leaks [#if-a-key-leaks] ### Revoke [#revoke] Revoke the credential in the portal (or ask the integration analyst to disable the source for an HMAC key). It stops working at once. ### Rotate [#rotate] Create a replacement and update your engine's secret store. ### Review [#review] Check the portal's request log for the credential's IP addresses and operations since the leak. ### Notify [#notify] The hospital's privacy office has already received an automatic alert. Export the audit trail they ask for and follow their incident process. Never paste a credential into a ticket, a chat or these docs' assistant. ## Related [#related] * [Authentication](/developers/authentication) * [Privileged access](/security/privileged-access) # EHR write-back (https://docs.edflow.space/developers/ehr-write-back) Options for sending EDFlow activity back to the EHR: request write-back through the API, an optional end-of-visit communication log document, and why the pilot stays read-only. EDFlow doesn't write clinical data into the EHR during a pilot. Requests and tasks live in EDFlow, where staff already see them in real time, and they are kept as safety records the hospital can export. ## What exists today: acknowledge and resolve from the EMR [#what-exists-today-acknowledge-and-resolve-from-the-emr] The EMR side can mark a EDFlow request as seen or done when a clinician handles it there. This doesn't write into the EHR: it runs the same actions as the staff console, and the patient sees the same result. * `POST /v1/requests/{requestId}/acknowledge` and `…/resolve` (scope `requests:write`, the site's write-back switch, and an `Idempotency-Key`). * `by.practitioner` is resolved to a staff membership through its EHR identity. If linked, the patient sees "Seen by" and the name; otherwise "Your care team has seen your request". _acknowledgeRequest: https://docs.edflow.space/openapi/edflow-v1.json_ Engines that want to forward requests themselves subscribe to the `request.*` webhooks. Mapping a EDFlow visit back to your visit number needs either the site's option to keep the visit number encrypted (exposed as `externalRef`) or your own map from the `edflowEncounterId` returned at ingest. ## Options for later phases [#options-for-later-phases] | Mechanism | Epic | Oracle Health | Notes | | ------------------------------------------------------------------------------ | --------------------------------------------------------------- | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **End-of-visit document**: one communication log per visit, filed at departure | HL7 `MDM^T02` through the engine, or `DocumentReference.Create` | `DocumentReference.Create` | One write per visit, only EDFlow's own activity (requests with times, call-backs, pauses), never clinical content. Delivered as `visit.communication_log_ready` + `GET /v1/documents/{documentId}` | | Embedded view (SMART) | EHR launch | SMART launch | Nothing is written. See [SMART on FHIR](/developers/smart-on-fhir) | | Real-time clinician message | Epic-specific APIs and build | `Communication.Create` to a practitioner or group | Never the only alert | ## Why the pilot stays read-only [#why-the-pilot-stays-read-only] * Write-back widens the PIA and adds interface build at the hospital. * It can clutter the chart. * Requests are non-urgent by design, and "I feel worse" always tells patients to speak to staff in person. ## Related [#related] * [Webhooks](/developers/webhooks) * [Concepts](/developers/concepts) # Engine configuration (https://docs.edflow.space/developers/engine-configuration) Configure your integration engine for EDFlow: store and forward, a queued destination that never holds the queue on AE or AR, signing and token refresh at send time, surviving a 30-minute outage, heartbeats and rosters, dead letters, and Mirth Connect / OIE templates with Rhapsody and Cloverleaf notes. These rules keep a hospital's EHR feeds safe no matter what happens to EDFlow. They apply to every engine. ## The rules [#the-rules] 1. **Store and forward.** Your source connector acknowledges the EHR as soon as the message is persisted. EDFlow is a separate, **queued** destination. The EHR-facing ACK never waits for EDFlow. 2. **Never hold the queue on `AE` or `AR`.** Data problems come back as `AA` with warnings and are dead-lettered in EDFlow; `AE` (structural) and `AR` (channel configuration) go to your error channel and alert. Mark the message sent. See the [ACK table](/developers/hl7v2#acknowledgements). 3. **Transient failures pause, they don't error.** `503` and `429` carry `Retry-After`: keep the message queued and retry after the delay, with no hot retry loop. 4. **Sign and authenticate at send time.** Fetch or refresh the access token, and compute any HMAC signature, in the destination step that sends, never in the transformer. Queued retries hours later then carry a fresh token and signature. 5. **Idempotency.** Derive event ids from the feed and `MSH-10` (or send a per-message UUID), and send an `Idempotency-Key` per message, so a resend after a timeout returns the stored result. 6. **One queue per feed**, single-threaded, so events for a visit arrive roughly in order. 7. **Minimum necessary.** Filter to ED visits (`PV1-2 = E` and ED locations). Encrypt message storage, remove content on completion, and never log a token, a secret or a message body. ## Surviving an outage [#surviving-an-outage] The `outage_recovery` conformance profile makes EDFlow unavailable to your app for 30 minutes. Your engine keeps queueing; after recovery, every queued message must arrive with no `401`, no `idempotency_conflict` and no gap. This works only if rules 3 to 5 hold. Run it in the sandbox before go-live. ## Scheduled channels [#scheduled-channels] * `system.heartbeat` every 60 seconds per feed. * `department.roster_reported` every 15 minutes, from the engine's census table or a census query the site already runs. * At go-live, a census sync as `mode: "backfill"` events. ## Dead letters [#dead-letters] Rejected and expired events land in EDFlow's dead-letter queue, not yours. You're told through the `ingest.dead_lettered` webhook and `GET /v1/events?status=dead_lettered`. The integration analyst fixes the cause (usually the mapping) and replays from EDFlow; the replay supersedes the earlier result. ## Mirth Connect and Open Integration Engine templates [#mirth-connect-and-open-integration-engine-templates] Channel exports for Mirth Connect 4.x and OIE implement every rule above. Import the code templates first and link them to every channel. | File | What it does | | ----------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Code templates](https://docs.edflow.space/downloads/engine-templates/mirth-oie/code-templates.xml) | Configuration-map access, the client-credentials token cache, the dispatch-time send, the `Retry-After` pause, ACK classification and response mapping | | [Raw HL7 sender](https://docs.edflow.space/downloads/engine-templates/mirth-oie/raw-hl7-sender.channel.xml) | MLLP listener → queued JavaScript Writer → `POST /v1/hl7v2` (raw). **Recommended** | | [Normalized events](https://docs.edflow.space/downloads/engine-templates/mirth-oie/normalized-events.channel.xml) | MLLP listener → transformer building normalized events for ADT A01/A04/A02/A03/A11, ORM O01 and ORU R01 → `POST /v1/events/batch`. For sites that map at the engine | | [Webhook receiver](https://docs.edflow.space/downloads/engine-templates/mirth-oie/webhook-receiver.channel.xml) | HTTP listener that verifies Standard Webhooks signatures (every signature, every configured secret, ±5 min), deduplicates on `webhook-id`, answers quickly and forwards | | [Error handler](https://docs.edflow.space/downloads/engine-templates/mirth-oie/error-handler.channel.xml) | Receives `AE`/`AR` ACKs and rejected events, keeps codes and positions only, raises an engine alert | ### Configuration map [#configuration-map] | Key | Example | Notes | | --------------------------- | -------------------------------- | ---------------------------------------------------------------------------- | | `ingest.api.baseUrl` | the base URL shown in the portal | Each environment has its own host | | `ingest.api.clientId` | `edf_test_cli_…` | From the portal | | `ingest.api.clientSecret` | (secret store) | Revealed once. Live apps with sensitive scopes use `private_key_jwt` or mTLS | | `ingest.api.scope` | `hl7v2:write events:write` | | | `ingest.api.site` | `your-site-sbx` | Optional; otherwise `MSH-4` maps through the profile | | `ingest.api.userAgent` | `Mirth-4.5.0 ADT-sender/1.0` | Identifies your engine in the request log | | `ingest.webhook.secrets` | `whsec_…,whsec_…` | Current and, during a rotation, previous | | `ingest.webhook.downstream` | channel id | Where verified webhook events go | `AR` with `ERR-3` `202` means the processing id isn't accepted in this environment: send `T` in the sandbox and `P` in live. ## Rhapsody, Cloverleaf and InterSystems [#rhapsody-cloverleaf-and-intersystems] The same rules apply: * **Rhapsody**: an HTTP communication point in a separate output route with its own queue; compute the token and signature in a send-time JavaScript filter, not in the mapping; route `AE`/`AR` to an error route. * **Cloverleaf**: an outbound thread with store-and-forward recovery; do token and signature work in the TPS procedure attached to the send, and handle replies in the reply TPS without blocking the inbound thread. * **InterSystems HealthShare/Ensemble**: an HTTP business operation with its own queue and a retry interval honouring `Retry-After`; build headers in the operation's `OnMessage`, not in a DTL. ## Related [#related] * [Authentication](/developers/authentication) * [Rate limits and retries](/developers/rate-limits-and-retries) * [Go live](/developers/go-live) # Errors (https://docs.edflow.space/developers/errors) Every EDFlow error code: request-level HTTP status on the signed ingest profile, per-event result codes, and REST API problem details (RFC 9457) with retryable flags and the retry action to take first. ## REST API: problem details [#rest-api-problem-details] Every non-2xx response on `/v1/*` is `application/problem+json` (RFC 9457): ```json { "type": "https://…/problems/insufficient_scope", "title": "Insufficient scope", "status": 403, "detail": "This operation needs the requests:write scope. Your token has: requests:read encounters:read.", "code": "insufficient_scope", "requestId": "rid_01J8ZQ4M2B7V6T1K9C3X5N0P8R", "retryable": false, "requiredScopes": ["requests:write"] } ``` * Switch on `code`, never on the text. * `retryable` says whether a retry can succeed; `retryAction` says what to do first: `reauthenticate` (new token), `resign` (new timestamp, delivery id and signature) or `wait` (honour `Retry-After`). * Validation failures add `errors[]` with JSON Pointer paths. * `detail` never echoes secrets, tokens, visit numbers or payload values. * FHIR routes return an `OperationOutcome` when you ask for `application/fhir+json`; raw HL7 returns an ACK (see [HL7 v2](/developers/hl7v2)); the OAuth endpoints use RFC 6749 error bodies. * Quote `requestId` in support tickets. ## Request-level errors [#request-level-errors] | HTTP | Codes | Retryable | Do this | | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------- | ------------------------------------------------------------- | | 400 | `invalid_request`, `malformed_json`, `invalid_cursor`, `idempotency_key_required`, `site_required`, `batch_too_large` | No | Fix the request | | 401 | `unauthenticated`, `invalid_token`, `token_revoked`, `wrong_environment`, `mtls_required` | No | Fix the credential or host | | 401 | `token_expired` | Yes, `reauthenticate` | New token, same request | | 401 | `missing_signature`, `invalid_signature`, `unknown_source` (signed profile) | No | Check the key, version and body bytes | | 401 | `timestamp_out_of_window`, `delivery_replayed` (signed profile) | Yes, `resign` | Re-sign with a new timestamp and delivery id | | 403 | `insufficient_scope`, `site_not_allowed`, `capability_disabled`, `ip_not_allowed`, `client_disabled`, `org_suspended`, `source_disabled` | No | See `detail` | | 404 | `not_found` | No | Unknown route or resource, or a resource at another site | | 405, 406 | `method_not_allowed`, `not_acceptable` | No | | | 409 | `idempotency_in_progress` | Yes, after a short wait | The same key is still running | | 409 | `idempotency_conflict`, `conflict` | No | Event id reused with a different payload; or a state conflict | | 410 | `gone` | No | Past its sunset date | | 413, 415 | `payload_too_large`, `unsupported_media_type` | No | Split or fix the content type | | 422 | `validation_failed`, `idempotency_key_reused`, `event_rejected`, `processing_id_not_allowed`, `phi_suspected`, `transaction_not_supported`, `unsupported_encoding` | No | Fix and resend | | 429 | `rate_limited` | Yes, `wait` | Honour `Retry-After` | | 500 | `internal_error` | Yes, with backoff | Quote the `requestId` | | 503 | `unavailable` | Yes, `wait` | Keep it queued; honour `Retry-After` | ## Per-event result codes [#per-event-result-codes] Inside a `200` batch response, each event has its own result. Rejected events carry one of these codes and a path: | Code | Retryable | Cause | | ----------------------------------------------------------------------- | --------- | ---------------------------------------------------------------------- | | `invalid_envelope` | No | Envelope field missing or malformed, or an id containing an identifier | | `unsupported_spec_version` | No | `specVersion` isn't supported | | `unknown_event_type` | No | Not in the catalogue | | `event_type_not_allowed`, `site_not_allowed`, `source_kind_not_allowed` | No | Your source isn't allowed to send it | | `simulator_disabled` | No | Simulator events outside a synthetic deployment | | `encounter_required` | No | The type needs `encounter` | | `invalid_data` | No | `data` failed validation; `path` points at the field | | `prohibited_field` | No | A prohibited key anywhere in the event | | `idempotency_conflict` | No | The id was used with a different payload | | `occurred_at_in_future`, `occurred_at_too_old` | No | More than 10 minutes ahead, or more than 90 days old | | `processing_error` | **Yes** | Transient; resend that event (same id) later | ## The product's error catalogue [#the-products-error-catalogue] Errors raised by the product itself, with the text people see: | Code | Group | What people see | | --- | --- | --- | | unauthenticated | Core | — | | forbidden | Core | You don't have access to this page. Ask your ED manager if you need it. | | not_found | Core | We couldn't find this page. | | not_opened | Core | — | | invalid_argument | Core | — | | out_of_range | Core | — | | rate_limited | Core | — | | conflict | Core | Someone else changed this. Review their changes and try again. | | access_ended | Core | — | | read_only | Core | — | | identity_unconfirmed | Core | — | | mfa_required | Core | — | | mfa_enrolment_required | Core | — | | session_locked | Core | — | | reauth_required | Core | — | | forbidden_in_production | Core | — | | sharing_unavailable | Core | — | | limit_reached | Core | — | | code_category_cannot_notify | Core | — | | invalid_transition | Core | — | | undo_expired | Core | — | | last_manager | Core | — | | approver_is_editor | Core | — | | content_not_ready | Core | — | | key_version_limit | Core | — | | key_already_revealed | Core | — | | provider_not_configured | Core | — | | password_policy | Core | — | | invalid_code | Core | — | | flow_disabled | Core | — | | forbidden_demo | Core | — | | approval_required | Core | — | | self_approval | Core | — | | verification_required | Core | — | | verification_failed | Core | — | | device_limit | Core | — | | owner_only | Core | — | | updates_paused | Core | — | | station_required | Core | — | | budget_exhausted | Core | — | | conflict_of_interest | Core | — | | policy_violation | Integration platform | — | | sod_violation | Integration platform | — | | affiliation_pending | Integration platform | — | | attestation_required | Integration platform | — | | app_not_approved | Integration platform | — | | in_use | Integration platform | — | | ai_disabled | AI features | — | | ai_unavailable | AI features | — | | ai_rate_limited | AI features | — | | ai_budget_exhausted | AI features | — | | ai_input_too_long | AI features | — | | ai_blocked | AI features | — | | ai_approval_invalid | AI features | — | | ai_approval_expired | AI features | — | | ai_region_violation | AI features | — | | ai_language_not_ready | AI features | — | | ai_governance_incomplete | AI features | — | | ai_sample_unscrubbable | AI features | — | | ai_sample_not_synthetic | AI features | — | | ai_audio_too_long | AI features | — | | ai_opted_out | AI features | — | | ai_query_refused_differencing | AI features | — | | ai_review_conflict | AI features | — | | ai_brand_mismatch | AI features | — | ## Related [#related] * [Rate limits and retries](/developers/rate-limits-and-retries) * [Authentication](/developers/authentication) # FHIR implementation guide (https://docs.edflow.space/developers/fhir-implementation-guide) The EDFlow ED Visit Workflow FHIR implementation guide: base profiles on CA Baseline, must-support and prohibited elements, terminology and canonical URLs, the $ingest operation, examples, and validating with the HL7 FHIR validator. The FHIR routes are backed by a small implementation guide (IG), built with the HL7 IG Publisher and published with the API. This page summarizes it; the IG is the normative reference. ## Base [#base] Profiles derive from **CA Baseline** (the pan-Canadian baseline), with CA Core+ where the pilot EHRs already conform. | Profile | Used for | | -------------------------------- | ---------------------------------------------------------- | | `Encounter` | Arrival, triage history, location, participants, departure | | `ServiceRequest` | Orders: category, priority, status | | `DiagnosticReport` | Result **status** only | | `Observation` | Triage acuity only | | `Task` | Fulfilment hints | | `PractitionerRole`, `Location` | Enrichment and mapping | | Subscription notification Bundle | Subscriptions Backport rest-hooks | Each profile lists its must-support elements and says which elements EDFlow reads, which it ignores, and which are **prohibited** (result values, conclusions, presented forms, narrative, notes). Prohibited elements are dropped unread by the adapter. ## Terminology [#terminology] * Bindings for encounter class, order and report status (`request-status`, `diagnostic-report-status`), practitioner roles and locations. * **CTAS**: until a pan-Canadian FHIR code system for CTAS is confirmed, the IG publishes its own CTAS code system with a concept map to what each EHR sends, and records the decision. ## Canonical URLs [#canonical-urls] Every code system, value set, profile and operation has a canonical URL on the API's domain (for example `…/fhir/CodeSystem/service`, `…/fhir/CodeSystem/api-error`, `…/fhir/NamingSystem/site-orderable`), and site-local order codes use `…/fhir/CodeSystem/site/{siteCode}/orderable`. These don't change with branding. ## Operations [#operations] | Operation | Definition | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | `$ingest` | `GET /v1/fhir/OperationDefinition/ingest`. Input `resource` (a Bundle); output a `batch-response`-shaped Bundle or an `OperationOutcome` | | `$process-message` | Standard FHIR messaging | The CapabilityStatement at `GET /v1/fhir/metadata` comes from the same build. ## Examples and validation [#examples-and-validation] Examples for every profile are generated from the synthetic fixtures and checked with the HL7 FHIR validator in CI. Validate your own resources the same way: ```bash java -jar validator_cli.jar your-bundle.json -version 4.0.1 -ig ``` Then dry-run them against the sandbox with `POST /v1/events/validate` and `Content-Type: application/fhir+json`. ## Related [#related] * [FHIR R4](/developers/fhir) * [Mapping profiles](/developers/mapping-profiles) # FHIR R4 (https://docs.edflow.space/developers/fhir) Send FHIR R4 to EDFlow: batch Bundles, the $ingest operation for collection, searchset and Subscriptions Backport notifications, $process-message, how each resource maps to events, Epic and Oracle Health notes, and a worked example. The FHIR adapter maps FHIR R4 resources to the same normalized events as HL7 v2, following the HL7 V2-to-FHIR concept maps where they apply, so HL7 and FHIR sites get the same behaviour. Raw resources are never stored. ## Endpoints [#endpoints] | Endpoint | Accepts | Notes | | ---------------------------------------------- | --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | `POST /v1/fhir` | `batch` Bundles (up to 200 entries) | Each entry processed independently. `transaction` is refused (`422 transaction_not_supported`) | | `POST /v1/fhir/$ingest` | `collection`, `searchset` and `history` Bundles, including **Subscriptions Backport** notifications | Handshakes and heartbeats produce no events; heartbeats keep the feed healthy | | `POST /v1/fhir/$process-message` | `message` Bundles with a `MessageHeader` | Duplicates detected by `Bundle.id` + `MessageHeader.id` for 30 days | | `GET /v1/fhir/metadata` | CapabilityStatement | Public | | `GET /v1/fhir/.well-known/smart-configuration` | SMART Backend Services discovery | `private_key_jwt` only | `Accept: application/fhir+json` returns a `batch-response` Bundle with an `OperationOutcome` per entry; `Accept: application/json` returns the normalized results. A transient failure returns `503` with `Retry-After` for the whole request; entries already committed return `duplicate` on retry. _ingestFhirBundle: https://docs.edflow.space/openapi/edflow-v1.json_ ### Subscription rest-hooks [#subscription-rest-hooks] Backport rest-hook channels send static headers, so a 5-minute token doesn't fit. Use a static API key scoped to `fhir:write` only in `Subscription.channel.header`. In customer test and live it needs an IP allowlist and expires within 90 days; update the Subscription before it expires. ### Sandbox test marker [#sandbox-test-marker] In the sandbox, Bundles must carry the `HTEST` tag (`http://terminology.hl7.org/CodeSystem/v3-ActReason#HTEST`) in `meta.tag`; in live it's refused. ## Resource mapping [#resource-mapping] | Resource | Condition | Events | | ---------------------------------------------- | -------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Encounter` | `class` = `EMER`, or an ED location | First `arrived`/`in-progress` → `encounter.arrived` (`period.start`); a `triaged` status history entry → `encounter.triaged`; active `location` → `encounter.location_changed`; `participant` → `careteam.snapshot`; `onleave` → out of department; `finished` → `encounter.departed` with the discharge disposition; `cancelled` → `encounter.cancelled` | | `Observation` | Code is one of the profile's CTAS codes | `encounter.triaged`. **Every other Observation is ignored** | | `ServiceRequest` | Linked to an ED encounter; laboratory, imaging or ECG category | `order.placed` / `order.status_changed`: `active` → placed, `on-hold` → on hold, `revoked`/`entered-in-error` → cancelled. Consult categories → `consult.status_changed` | | `Specimen` | References a known order | Collected, received | | `ImagingStudy` | `basedOn` an order | Started → in progress; `available` → performed | | `DiagnosticReport` | `basedOn` an order | `registered` → in the lab; `partial`/`preliminary` → preliminary; `final` → resulted; `amended`/`corrected`/`appended` → corrected. **`result`, `conclusion`, `conclusionCode` and `presentedForm` are dropped unread** | | `Appointment` | `basedOn` an order | Scheduled, with `start` | | `CareTeam` | Encounter-level team (Oracle) | `careteam.snapshot` | | `Task` | `focus` is an order | Optional hints for in-progress and performed | | `Practitioner`, `PractitionerRole`, `Location` | | Enrichment only | Event ids are `{sourceId}:fhir:{resourceType}/{id}/_history/{versionId or meta.lastUpdated}:{n}`; `recordedAt` comes from `meta.lastUpdated`. ## Vendor notes [#vendor-notes] **Epic.** The ED treatment team comes back as `Encounter.participant`, not `CareTeam`. Encounter search is scoped per patient in the public catalogue, and a general FHIR Subscription API isn't published, so most Epic sites send HL7 v2 (Bridges) for the real-time feed and use FHIR for enrichment or a SMART launch. Backend services use `client_credentials` with a `private_key_jwt` assertion signed with RS384 or ES384. **Oracle Health Millennium.** `CareTeam` supports encounter-level teams with roles and periods, which fits the ED well. R4 Subscriptions aren't in the public documentation, so real-time events usually come from HL7 v2 outbound through Oracle's interface tooling. **Any vendor.** A FHIR relay or subscription product in front of the EHR works with `$ingest`. ## Worked example (synthetic, sandbox) [#worked-example-synthetic-sandbox] ```json { "resourceType": "Bundle", "type": "batch", "meta": { "tag": [{ "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason", "code": "HTEST" }] }, "entry": [{ "resource": { "resourceType": "Encounter", "id": "syn-enc-1", "meta": { "versionId": "1", "lastUpdated": "2026-09-14T12:02:14Z" }, "status": "arrived", "class": { "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "EMER" }, "identifier": [{ "system": "urn:example:visit", "value": "SYN3000123" }], "period": { "start": "2026-09-14T08:02:11-04:00" }, "location": [{ "location": { "reference": "Location/edwr", "display": "Waiting room" }, "status": "active" }] }, "request": { "method": "PUT", "url": "Encounter/syn-enc-1" } }] } ``` This produces `encounter.arrived` at 08:02:11 in the waiting room. ## Related [#related] * [FHIR implementation guide](/developers/fhir-implementation-guide) * [SMART on FHIR](/developers/smart-on-fhir) * [HL7 v2](/developers/hl7v2) # Go live (https://docs.edflow.space/developers/go-live) Take a EDFlow integration live: sandbox conformance, the customer-test shadow run and the 98% milestone agreement gate, promotion with four-eyes approval and the PIA attestation, cut-over, and monitoring after go-live. An integration moves **sandbox → customer test → live**. Nothing is copied between environments: you create a separate app in each, and the portal's **Promote** checklist records the evidence. ## The checklist [#the-checklist] ### Sandbox conformance [#sandbox-conformance] Run the conformance profiles your integration needs: `ingest` (every event type you declare, idempotent retries, out-of-order delivery, a prohibited-field rejection, heartbeat and roster), `webhooks`, `writeback`, and the operational profiles `outage_recovery`, `clock_skew` and `backfill_10k`. See [Sandbox](/developers/sandbox). ### Customer-test shadow run [#customer-test-shadow-run] Send the hospital's test-domain feed through customer test for at least 5 days. Check your engine's ACK handling against the [ACK table](/developers/hl7v2#acknowledgements): no queue holds on EDFlow ACKs. ### Mapping reviewed [#mapping-reviewed] The mapping profile diff is reviewed and there are zero unmapped codes over the last 7 customer-test days. ### Webhook receiver verified [#webhook-receiver-verified] The delivery log shows your receiver verifying signatures, deduplicating a redelivery, dropping an expired event and, if configured, authenticating EDFlow with OAuth or mTLS. ### PIA attestation [#pia-attestation] For sensitive scopes (`encounters:read`, `careteam:read`, `requests:read`, `requests:write`, `tasks:read`), the organization's privacy officer records the PIA/TRA section in the system, referencing the signed document. ### Live app approved [#live-app-approved] Create the live app with the same scopes or fewer. An approver who didn't create or submit it approves it, and a developer who isn't the approver reveals the credentials. ## The site's go-live gates [#the-sites-go-live-gates] The integration gates join the site's gates: * a 14-day shadow run with at least 98% milestone agreement against the site's audit sample; * p95 EHR-to-screen latency of 60 s or less; * rejected events below 0.5%; * zero unmapped codes in the last 30 days; * roster reconciliation closing every test discharge; * the clinical safety case, PIA and TRA signed off, staff trained. ![Integration health: the feed state, last event and heartbeat, error rates and alerts.](https://docs.edflow.space/screenshots/web/admin-integration-health.png) ## Cut-over [#cut-over] 1. Send the current ED census as `mode: "backfill"` events (arrival, triage, location, current team). Backfill never notifies anyone. 2. Start the live feed, the 60-second heartbeat and the 15-minute roster. 3. Watch the integration health page: feed state, events per minute, rejections by code, roster discrepancies. ## After go-live [#after-go-live] * **Alerts**: feed delayed and down, dead letters, quarantined rosters and credential expiry reach the integration on-call and your webhook endpoints (`feed.state_changed`, `ingest.dead_lettered`, `ingest.roster_quarantined`, `integration.credential_expiring`). * **Data issues** reported by staff land on the integration health page. See [Data issues](/admin/integration/data-issues). * **Changes**: test engine changes in customer test first. Rotate credentials before they expire. ## Related [#related] * [Engine configuration](/developers/engine-configuration) * [For hospitals](/start/for-hospitals) # HL7 v2 (https://docs.edflow.space/developers/hl7v2) Send HL7 v2 to EDFlow over HTTPS: supported versions and vendors (Epic Bridges, Oracle Health Millennium, MEDITECH), triggers and the events they produce, result and order status maps, the field map, character sets and escapes, the ACK table, and a worked example stream. EDFlow accepts HL7 v2 over HTTPS, not MLLP. Keep MLLP inside the hospital: your engine acknowledges the EHR as soon as it has persisted a message, and forwards to EDFlow from a separate, queued destination. A EDFlow slowdown can never back up your EHR's queues. ## Endpoints and modes [#endpoints-and-modes] | Mode | Endpoint | `Content-Type` | Response | | ------------------------------------- | -------------------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | **Raw (HL7 over HTTPS)**, recommended | `POST /v1/hl7v2` | `application/hl7-v2`, `x-application/hl7-v2+er7`, or `text/plain` (Mirth default), optional `charset` matching `MSH-18` | One ACK per the table below, in the inbound message's version and character set; or `503`/`429` with `Retry-After` | | JSON-wrapped batch | `POST /v1/hl7v2` | `application/json` with `{ "messages": [{ "er7": "MSH…" }] }` (up to 50) | JSON with an ACK and the derived events per message | | Signed profile | `POST /ehr/v1/hl7v2` | JSON-wrapped | As the signed ingest profile | The site comes from `?site=`, otherwise from `MSH-4` through the mapping profile. Authenticate with a bearer token, an API key, or HTTP Basic with `client_id:api_key`. _ingestHl7v2: https://docs.edflow.space/openapi/edflow-v1.json_ ## Versions and vendors [#versions-and-vendors] Accepted `MSH-12` versions: 2.3, 2.3.1, 2.4, 2.5, 2.5.1, 2.6, 2.7 and 2.8, with vendor profiles for **Epic Bridges**, **Oracle Health Millennium** (ESO/COI), **MEDITECH Expanse** and a generic profile. Before v2.5 there is no `TQ1` or `SPM`; timing falls back to `OBR-27`/`ORC-7` and `OBR-7`, specimen to `OBR-15`. ## Processing id by environment [#processing-id-by-environment] | Environment | `MSH-11` accepted | | ------------- | -------------------------------------------------------- | | Sandbox | `T` or `D` only. `P` is refused with `AR`, `ERR-3` `202` | | Customer test | `T` or `P` | | Live | `P` only | ## Triggers [#triggers] | Message / trigger | Events produced | | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ADT^A04 Register (ED class and location) | `encounter.arrived`; plus `encounter.triaged` if a CTAS OBX is present, `careteam.snapshot` if `PV1-7` or `ROL` is present | | ADT^A01 Admit/visit | As A04 for sites that use A01 for ED arrival; as A06 when an ED encounter becomes inpatient | | ADT^A08 Update | Only the mappers whose fields are present: location (`PV1-3`), care team (`PV1-7/9/52`, `ROL`), triage (CTAS OBX), patient updates (`PID-5/7/15`, `PD1-12`, `PV2-22`) | | ADT^A02 Transfer | `encounter.location_changed`; to an inpatient unit: `encounter.departed` (admit) | | ADT^A03 Discharge | `encounter.disposition_decided` (if not yet recorded) + `encounter.departed` | | ADT^A06 | `encounter.disposition_decided` (admit) | | ADT^A11 Cancel visit | `encounter.cancelled`, or left without being seen, per the profile's `a11Semantics` | | ADT^A12 / A13 | Location restored / `encounter.departure_cancelled` | | ADT^A14 / A27 | `admission.status_changed` bed requested / cancelled | | ADT^A21 / A22 | Location `out_of_department` and back | | ADT^A40 (A34/A18 in older versions) | `patient.merged` | | ORM^O01, OMG^O19, OML^O21, OMI^O23 | `order.placed` (`NW`, `XO`), `order.status_changed` (`SC`), cancelled (`CA`, `OC`, `DC`, `OD`, `CR`); consult codes become `consult.status_changed`; NPO diet codes become a diet order | | ORU^R01 | `order.status_changed` per OBR from `OBR-25` and `OBR-22`. **OBX segments are ignored and never parsed for values** | | SIU^S12/S13/S14, S15 | Scheduled with `scheduledFor`; schedule removed | | MDM, DFT, BAR, VXU, others | Acknowledged `AA` with an "ignored" warning. Filter them at the engine | Identifier-change triggers (A44, A45, A47, A50, A37, A35, A46, A49) are acknowledged with a warning and raise an alert so an analyst reconciles the visit. ## Result status (`OBR-25`, table 0123) [#result-status-obr-25-table-0123] | `OBR-25` | Status | | -------- | ------------------------------------- | | `O` | placed | | `S` | scheduled | | `I` | lab: in the lab; imaging: in progress | | `R` | lab: in the lab; imaging: performed | | `A`, `P` | preliminary | | `F` | resulted | | `C` | corrected | | `X` | cancelled | ## Order status (`ORC-5`, table 0038, used only when `OBR-25` is empty) [#order-status-orc-5-table-0038-used-only-when-obr-25-is-empty] | `ORC-5` | Status | | ---------- | --------------------------------------- | | `SC` | placed (scheduled if a time is present) | | `IP` | in the lab or in progress | | `A` | preliminary | | `CM` | resulted | | `CA`, `DC` | cancelled | | `HD` | unchanged, on hold | Order status only moves forward, unless the message is a correction, a cancellation or an explicit reversal (`ORC-1 = CR`, `OBR-25 = X`). ## Field map [#field-map] | Field | Target | Handling | | -------------------------------------------------- | --------------------------------------------- | ---------------------------------------------- | | `MSH-3/4` | Source system, feed, site | | | `MSH-7` | `recordedAt` fallback | No offset: the profile time zone | | `MSH-10` | Message id, part of the event id | | | `EVN-2` / `EVN-6` | `recordedAt` / `occurredAt` | | | `PID-3` (type `MR`) | Record number | Hashed on receipt | | `PID-3` (type `JHN`, health card) | **Dropped** | | | `PID-5`, `PID-7` | Name, birth date | Only for the sign-in match key, then discarded | | `PID-11`, `PID-13/14`, `PID-19` | **Dropped** | Address, phones, SIN | | `PID-15` | Preferred language | Mapped to BCP-47 | | `PD1-12`, `PV2-22` | Confidential flag | | | `PV1-2` | Filter | `E` = emergency | | `PV1-3` | Location → area | Via the profile | | `PV1-7/9/17/52`, `ROL` | Care team | `ROL-2` `DE` releases a member | | `PV1-19` | Visit identifier | Hashed at rest | | `PV1-36` | Disposition | Via the profile | | `PV1-44` / `PV1-45` | Arrived / departed | | | `PV2-3` | Chief complaint | Dropped unless the site opts in | | `OBX` in ADT | CTAS, only for the profile's CTAS codes | Every other OBX ignored | | `ORC`, `OBR-4/7/14/22/24/25/27/36`, `TQ1-9`, `SPM` | Order code, times, category, status, priority | Order ids hashed | | `OBX` in ORU | **Never read** | | An **empty** field means "no change"; `""` means "clear". An A08 carries only the fields present, so it never releases a care-team member that arrived through `ROL`. ## Character sets and escapes [#character-sets-and-escapes] * `MSH-18`: `ASCII`, `8859/1` or `UNICODE UTF-8`. When empty, the mapping profile's required default applies. An HTTP `charset` that disagrees, or invalid bytes, return `AE` `unsupported_encoding`. * Escape sequences (`\F\`, `\S\`, `\T\`, `\R\`, `\E\`, `\Xhh\`, `\.br\`) are decoded and values normalized before mapping, so accented names produce the same match key in every encoding. * `FHS`/`BHS` batch files aren't supported. Send messages one by one, or up to 50 per JSON request. ## Acknowledgements [#acknowledgements] Original mode only: every message gets one application ACK in the HTTP response. | Outcome | HTTP | `MSA-1` | What your engine does | | -------------------------------------------------------------------------- | --------------------------------- | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | All derived events accepted, duplicate, buffered or superseded | 200 | `AA` | Next message | | Message type EDFlow doesn't use | 200 | `AA` with an "ignored" `ERR` | Next message; filter it at the engine | | Data problem (unknown code, invalid value) | 200 | `AA` with warning `ERR` segments | **Next message. Never hold the queue.** The event goes to the dead-letter queue; the analyst fixes the mapping and replays it | | Structural error (bad `MSH`, encoding, missing segment, batch) | 200 | `AE` | Route to your error queue and alert. Don't resend unchanged | | Environment or version mismatch (processing id, sandbox tripwire, version) | 200 | `AR` | Channel configuration error: stop and fix. `AR` means only this | | Transient failure | 503 or 429, `Retry-After`, no ACK | — | Keep it queued; retry after the delay. Already-committed events return `duplicate` | | Authentication | 401 / 403 | — | Fix the credential or re-authenticate | ```text MSH|^~\&|DEST|DEST|EHR|HOSP|20260914080215.402-0400||ACK^A08^ACK|rid_01J8…|P|2.5.1 MSA|AA|ADT000124 ERR||PV1^1^3|103^Table value not found^HL70357|W|unknown_location^Location code not in the mapping profile^99LNT||||Location ED^HALL^7 is not mapped; the location update was dead-lettered. ``` ## Worked example (synthetic, sandbox) [#worked-example-synthetic-sandbox] ```text MSH|^~\&|EHR|DEMOHOSP|DEST|DEST|20260914080214-0400||ADT^A04^ADT_A01|ADT000123|T|2.5.1|||||||UNICODE UTF-8 EVN|A04|20260914080214-0400||||20260914080211-0400 PID|1||SYN0000123^^^DEMOHOSP^MR||ZZTEST^BIRCH||19900101|U PV1|1|E|EDWR^WR01^^DEMOHOSP|E|||||||||||||||SYN3000123^^^DEMOHOSP^VN|||||||||||||||||||||||||20260914080211-0400 ``` produces `encounter.arrived` (waiting room, arrival 08:02:11). Then: ```text MSH|^~\&|EHR|DEMOHOSP|DEST|DEST|20260914081602-0400||ADT^A08^ADT_A01|ADT000131|T|2.5.1 EVN|A08|20260914081602-0400||||20260914081530-0400 PID|1||SYN0000123^^^DEMOHOSP^MR PV1|1|E|EDWR^WR01^^DEMOHOSP|E|||||||||||||||SYN3000123^^^DEMOHOSP^VN OBX|1|CWE|11283-9^Acuity assessment at first encounter^LN||3^CTAS 3^L||||||F|||20260914081530-0400 ``` produces `encounter.triaged` (CTAS 3 at 08:15:30). An `ORM^O01` for a urinalysis produces `order.placed` and the patient's urine-sample task; the `ORU^R01` with `OBR-25 = F` produces `order.status_changed` resulted, and its OBX value is never read; the `ADT^A03` produces the disposition and departure. Try your own messages with **Validate** in the developer console or `POST /v1/events/validate?input=hl7v2`: you get the events, a field-by-field trace, the fields dropped, unmapped codes and the exact ACK. ## Related [#related] * [Mapping profiles](/developers/mapping-profiles) * [Engine configuration](/developers/engine-configuration) * [FHIR R4](/developers/fhir) # Developers (https://docs.edflow.space/developers) Build with the EDFlow Integration API: send an inbound EHR feed as normalized events, FHIR R4 or HL7 v2 over HTTPS, read what the ED app holds, and receive signed webhooks. Sandbox, customer test and live environments. The EDFlow Integration API is how a hospital's integration engine, EMR team or an approved vendor connects to EDFlow: * **Push** ED workflow data in: normalized JSON events, FHIR R4 Bundles and messages, or HL7 v2 over HTTPS. * **Read** what EDFlow holds that the EMR doesn't: patient requests, patient-completed tasks, activation, the derived stage, department code alerts, ingest results. * **Write back** a small set of actions from the EMR side: acknowledge or resolve a patient request. * **Subscribe** to signed webhooks: a request was created, a code was called, the feed went quiet. ![Developer console home: your apps, the sandbox environment and links to the quickstart.](https://docs.edflow.space/screenshots/web/dev-console-home.png) ## Choose your path [#choose-your-path] | You are | Start with | Then | | -------------------------------------------------------------------------- | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | | An integration-engine team (Mirth/OIE, Rhapsody, Cloverleaf, InterSystems) | [Quickstart](/developers/quickstart) | [Engine configuration](/developers/engine-configuration), [HL7 v2](/developers/hl7v2), [Go live](/developers/go-live) | | An EHR vendor or EMR team | [Concepts](/developers/concepts) | [FHIR R4](/developers/fhir), [Authentication](/developers/authentication), [Webhooks](/developers/webhooks) | | Hospital IT reviewing the integration | [Trust overview](/security) | [Network requirements](/security/network-requirements), [Data flow](/security/data-flow) | ## Three environments [#three-environments] | | Sandbox | Customer test | Live | | ------------ | ------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | --------------------------- | | For | Development against the simulator and fictional hospitals | Your hospital's own test-domain feeds before go-live | Hospital production | | Data | **Synthetic only, enforced**: real-looking identifiers and production HL7 are refused | Treated as real patient data (test domains are often copied from production) | Real patient data | | Where | US East | Canada (AWS `ca-central-1`) | Canada (AWS `ca-central-1`) | | Credentials | `edf_test_…` | `edf_uat_…` | `edf_live_…` | | App approval | None | Four eyes | Four eyes | A credential only works in its own environment; using it elsewhere returns `401 wrong_environment` with the right base URL. ## What the API never returns [#what-the-api-never-returns] Patient names, dates of birth, raw EHR identifiers (unless the site opted in to encrypted visit numbers), CTAS, chief complaint, free text or result content. Responses carry EDFlow ids, workflow state and catalogue keys only. ## Get sandbox credentials [#get-sandbox-credentials] ### Get access to the developer portal [#get-access-to-the-developer-portal] Your hospital's integration analyst or your EDFlow contact invites you as an integration developer. Vendor developers are affiliated with the hospital first. ### Create a sandbox app [#create-a-sandbox-app] Pick a preset (for example **Integration engine**), then create a client secret or register a public key. ### Follow the quickstart [#follow-the-quickstart] [Send your first events in 15 minutes](/developers/quickstart). ## Reference [#reference] * [API reference](/developers/api), generated from the OpenAPI document * [Event reference](/developers/events) for every event type * [Errors](/developers/errors), [Rate limits and retries](/developers/rate-limits-and-retries), [Versioning](/developers/versioning-and-deprecation), [Changelog](/developers/changelog) * [Build with AI](/developers/build-with-ai): `llms.txt`, Markdown pages and the docs MCP server Further reading: [Integrating Epic and Oracle Health](https://edflow.space/learn/integrating-epic-and-oracle-health). ## Frequently asked questions [#frequently-asked-questions] No. Create a sandbox app in the developer portal: it is active immediately and only ever sees fictional hospitals. See [Sandbox](/developers/sandbox) and the [quickstart](/developers/quickstart). Use what your integration engine already produces. HL7 v2 ADT and ORM/ORU and FHIR R4 are mapped by the platform; normalized events give you full control. See [HL7 v2](/developers/hl7v2), [FHIR R4](/developers/fhir) and [Concepts](/developers/concepts). No. The event contract forbids them, and events with prohibited fields are rejected before anything is stored. See [Errors](/developers/errors). Deliveries follow Standard Webhooks: verify the signature, deduplicate on the webhook id and order by version. An endpoint with no success for 5 days and 10 or more failures is disabled and its owners are emailed. See [Webhooks](/developers/webhooks). You get a 429 response with RateLimit headers. Retry with exponential backoff and jitter, and use idempotency keys. See [Rate limits and retries](/developers/rate-limits-and-retries). New enum values and event types are announced 60 days ahead and breaking changes 12 months ahead, and `/v1` stays supported for at least 12 months after a `/v2`. See [Versioning](/developers/versioning-and-deprecation). # Mapping profiles (https://docs.edflow.space/developers/mapping-profiles) The versioned EDFlow site mapping profile: encounter filters and identifiers, locations and beds, CTAS codes, roles and practitioner ids, dispositions, order and consult codes, NPO diet codes, result thresholds, privacy options, and unmapped-code governance. Every source has a versioned **mapping profile**. Your engine's transformer (if you map at the engine) and EDFlow's HL7 and FHIR adapters use the same profile. Every event records the profile version that produced it. ## Example [#example] The values are illustrative, not real hospital codes. ```json { "profileId": "demo-epic", "version": 3, "siteCode": "demo-ed", "timezone": "America/Toronto", "defaultCharset": "UNICODE UTF-8", "encounterFilter": { "patientClass": ["E"], "pointOfCarePrefixes": ["ED"] }, "encounterId": { "hl7Field": "PV1-19.1", "idSystem": "epic-csn" }, "locations": { "EDWR": "waiting_room", "EDTRI": "triage", "EDACU": "treatment_space", "EDRES": "resuscitation", "EDFT": "fast_track", "EDIW": "internal_waiting", "EDHALL": "hallway", "RAD": "imaging" }, "ctas": { "hl7ObxCodes": ["11283-9^LN"], "fhirObservationCodes": ["http://loinc.org|11283-9"] }, "roles": { "ATND": "attending_physician", "RES": "resident_physician", "NP": "nurse_practitioner", "PA": "physician_assistant", "RN": "primary_nurse", "TRN": "triage_nurse", "CON": "consultant_physician" }, "dispositions": { "01": "discharge", "02": "admit", "03": "transfer", "04": "observation", "LWBS": "left_without_being_seen", "AMA": "left_against_medical_advice" }, "a11Semantics": "cancel", "piaSource": "attending_assigned", "orders": { "catalog": { "LAB123": "urinalysis", "LAB100": "cbc", "IMG4410": "ct-abdomen-pelvis" }, "categoryBySection": { "LAB": "lab", "CT": "imaging", "US": "imaging", "RAD": "imaging", "EC": "cardiology" }, "contrastPattern": "\\bW(ITH)?/? ?(IV )?CONTRAST\\b", "npoDietCodes": ["DIET_NPO"], "consultCodes": { "CONS_IM": "internal_medicine", "CONS_GS": "general_surgery" } }, "resultComplete": { "lab": "resulted", "imaging": "preliminary", "cardiology": "performed" }, "privacy": { "acceptChiefComplaint": false, "maskConfidentialNamesOnBoard": true } } ``` ## Sections [#sections] | Section | What it decides | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | `encounterFilter` | Which visits are ED visits (patient class and location prefixes). Filter the rest at the engine too | | `encounterId` | Where the visit identifier comes from and its id system | | `locations` | Location code → area (waiting room, triage, treatment space, resuscitation, fast track, internal waiting, hallway, imaging). Beds map to zones in the admin | | `ctas` | Which OBX or Observation codes carry the triage level | | `roles` | Role codes → care-team roles. Practitioner ids link to staff accounts through their EHR identities | | `dispositions` | Disposition codes → decisions, including left before treatment complete and NACRS codes | | `a11Semantics` | Whether an A11 means cancel or left without being seen | | `piaSource` | NACRS PIA at the attending assignment or at the first explicit assessment (analytics only) | | `orders` | Order code catalogue, category by section, the contrast pattern, NPO diet codes, consult codes (with the sensitive flag from the consult catalogue) | | `resultComplete` | When a test counts as "back": per category, and per imaging modality (preliminary by default; performed where ED physicians read their own films) | | `privacy` | Whether chief complaint is accepted (staff only), confidential masking | | Care-flag mappings | EHR codes for must-not-leave, custody, isolation, fall risk | | Reassessment mappings | Signed notes or procedure-area moves that count as a reassessment | | `defaultCharset` | Required when `MSH-18` is empty | ## Versions [#versions] Every edit creates a new version with a diff against any earlier one, in **Sources and keys**. A replay after a profile change **supersedes** earlier results for the same event id. ## Unmapped codes [#unmapped-codes] A code not in the profile or catalogue doesn't block ingest: the patient sees "Other test" and the code lands in [Unmapped codes](/admin/integration/unmapped-codes). Go-live needs zero unmapped codes over the last 30 days of test traffic. ![Unmapped codes: test and location codes the EHR sent that have no mapping yet, with suggested mappings to review.](https://docs.edflow.space/screenshots/web/admin-integration-unmapped.png) ## Related [#related] * [AI mapping assistant](/developers/ai-mapping-assistant) * [HL7 v2](/developers/hl7v2), [FHIR R4](/developers/fhir) # Quickstart (https://docs.edflow.space/developers/quickstart) Create a sandbox app, get an OAuth token, check health, send a heartbeat, an arrival and a triage event, watch the patient appear on the sandbox board, and receive your first webhook, in about 15 minutes. This quickstart takes about 15 minutes. You'll create a sandbox app, authenticate with OAuth 2.0 client credentials, send three events and watch a fictional patient appear on the sandbox staff board. The sandbox holds synthetic data only and refuses anything that looks real. ## Before you start [#before-you-start] * Access to the developer portal as an integration developer (ask your hospital's integration analyst or your EDFlow contact). * `curl`, Node.js 20+ or Python 3.10+. * The sandbox base URL: `https://api.sandbox.edflow.space`. ## 1. Create a sandbox app and a client secret [#1-create-a-sandbox-app-and-a-client-secret] ### Create the app [#create-the-app] In the developer portal, **Apps → New app**, environment **Sandbox**, preset **Integration engine** (scopes `events:write fhir:write hl7v2:write events:validate events:read`). Add `webhooks:read webhooks:write` for step 7. ### Create a client secret [#create-a-client-secret] **Credentials → Create client secret**. It is shown **once**: copy it, or download the `.env` file, and tick "I have stored it". ![Credentials and keys: each credential with its type, prefix, created date and last use.](https://docs.edflow.space/screenshots/web/dev-console-credentials.png) ```bash export EDFLOW_API_BASE_URL="https://api.sandbox.edflow.space" export EDFLOW_CLIENT_ID="edf_test_cli_…" export EDFLOW_CLIENT_SECRET="edf_test_cs_…" ``` For production-style authentication with a private key instead of a secret, see [Authentication](/developers/authentication). ## 2. Get an access token [#2-get-an-access-token] Tokens last 5 minutes. Cache one and refresh it 30 seconds before it expires, not on every request. ```bash TOKEN=$(curl -sS "$EDFLOW_API_BASE_URL/oauth/token" \ -u "$EDFLOW_CLIENT_ID:$EDFLOW_CLIENT_SECRET" \ -d grant_type=client_credentials \ -d "scope=events:write events:validate events:read" | jq -r .access_token) ``` ## 3. Check health and find your site code [#3-check-health-and-find-your-site-code] _getHealth: https://docs.edflow.space/openapi/edflow-v1.json_ ```bash curl -sS "$EDFLOW_API_BASE_URL/v1/sites" -H "Authorization: Bearer $TOKEN" ``` Your sandbox organization has one fictional site per real site, with a code ending in `-sbx`. Use it as `siteCode` below. ## 4. Send a heartbeat [#4-send-a-heartbeat] A heartbeat every 60 s keeps the feed **healthy**. Without it, the site shows "feed delayed" after 5 minutes. _ingestEventBatch: https://docs.edflow.space/openapi/edflow-v1.json_ ## 5. Send an arrival and a triage [#5-send-an-arrival-and-a-triage] Event ids must be deterministic and stable across retries; a retry with the same id is harmless. Patient identifiers in the sandbox must start with `SYN` and names must be synthetic (for example start with `ZZTEST`), or the event is refused as `phi_suspected`. ```bash curl -sS "$EDFLOW_API_BASE_URL/v1/events/batch" \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ --data @- <<'JSON' { "events": [ { "specVersion": "1.0", "id": "quickstart:ADT0001:0", "type": "encounter.arrived", "siteCode": "your-site-sbx", "occurredAt": "2026-09-14T08:02:11-04:00", "source": { "kind": "ehr", "system": "other", "feed": "adt", "messageType": "ADT^A04" }, "encounter": { "externalId": "SYN3000001", "idSystem": "visit-number" }, "data": { "arrivedAt": "2026-09-14T08:02:11-04:00", "arrivalMode": "walk_in", "patient": { "mrn": "SYN0000001", "givenName": "ZZTEST-Birch", "familyName": "ZZTEST-Sample", "birthDate": "1990-01-01", "administrativeGender": "unknown", "preferredLanguage": "en", "identityStatus": "confirmed", "privacy": { "confidential": false } }, "location": { "code": "EDWR/WR01", "area": "waiting_room", "display": "Waiting room" } } }, { "specVersion": "1.0", "id": "quickstart:ADT0002:0", "type": "encounter.triaged", "siteCode": "your-site-sbx", "occurredAt": "2026-09-14T08:15:30-04:00", "source": { "kind": "ehr", "system": "other", "feed": "adt", "messageType": "ADT^A08" }, "encounter": { "externalId": "SYN3000001", "idSystem": "visit-number" }, "data": { "triagedAt": "2026-09-14T08:15:30-04:00", "ctas": 3 } } ] } JSON ``` The response has one result per event: ```json { "results": [ { "id": "quickstart:ADT0001:0", "status": "accepted", "edflowEncounterId": "enc_…" }, { "id": "quickstart:ADT0002:0", "status": "accepted" } ], "summary": { "accepted": 2, "duplicate": 0, "buffered": 0, "ignored": 0, "rejected": 0 } } ``` Timestamps are for the example; use recent ones (events more than 30 minutes old update state silently, and more than 90 days old are refused). ## 6. Watch it arrive [#6-watch-it-arrive] * Sign in to the sandbox staff console with the sandbox staff account from your organization's welcome email. The patient appears on the board as "Waiting to be seen". * The integration **Event log** shows both events as accepted. ![Live board: patients by zone with stage, time in department, assigned clinician, tests, open requests and bottleneck flags, with filters and saved views.](https://docs.edflow.space/screenshots/web/staff-board.png) ![Event log: each inbound event with type, status (accepted, duplicate, buffered, ignored or rejected) and time.](https://docs.edflow.space/screenshots/web/admin-integration-events.png) ## 7. Receive a webhook [#7-receive-a-webhook] 1. Expose an HTTPS endpoint (for example with a tunnel) and create a webhook endpoint in the portal for `request.created`. Copy the `whsec_…` signing secret. 2. Create a sandbox patient request: `POST /v1/sandbox/requests` with the encounter id. 3. Verify the delivery with a Standard Webhooks library. See [Webhooks](/developers/webhooks). ## Alternative: the signed `/ehr/v1` profile [#alternative-the-signed-ehrv1-profile] Engines already built to the signed ingest profile send the same `{ "events": [...] }` body to `/ehr/v1/events`, signed with an HMAC source key instead of a bearer token. Sign and authenticate **at send time**, never in the transformer, so queued retries are re-signed. See [Authentication](/developers/authentication). ## Mirth Connect and Open Integration Engine [#mirth-connect-and-open-integration-engine] Import the channel templates from [Engine configuration](/developers/engine-configuration). They fetch and cache the token in a JavaScript Writer destination at dispatch time, queue on `503` and `429`, and never hold the queue on `AE` or `AR`. ## Next steps [#next-steps] * [Concepts](/developers/concepts): facts, stages, idempotency and ordering * [HL7 v2](/developers/hl7v2) or [FHIR R4](/developers/fhir) if your engine sends those * [Go live](/developers/go-live): conformance, shadow run and promotion # Rate limits and retries (https://docs.edflow.space/developers/rate-limits-and-retries) EDFlow rate limits per bucket, the RateLimit headers, which errors to retry and how, exponential backoff with jitter, idempotency keys, and batching and size limits. ## Rate limits [#rate-limits] Token buckets, keyed by app unless stated. The platform can raise them for your app on request. | Bucket | Applies to | Rate | Burst | | ------------ | ------------------------------------------------------------------------ | ------------- | ----- | | `ingest` | `/v1/events*`, `/v1/fhir*`, `/v1/hl7v2`, signed `/ehr/v1/*` (per source) | 20 requests/s | 40 | | `read` | `GET /v1/*` | 20/s | 60 | | `write` | Write-back and webhook management | 5/s | 20 | | `sandbox` | `/v1/sandbox/*` | 1/s | 5 | | `org` | Everything, per organization | 100/s | 200 | | `oauthToken` | `/oauth/token` per client | 30/min | 30 | A busy ED produces tens of events per minute, so these limits are for backfills and runaway loops, not normal traffic. Every response carries the IETF headers: ```http RateLimit-Policy: "read";q=60;w=3 RateLimit: "read";r=47;t=1 ``` `q` is the bucket size and `w` the seconds to refill it; `r` is what's left and `t` the seconds until at least one more request is allowed. A `429` has `Retry-After`. ## Retry or not [#retry-or-not] | Response | Retry? | First | | -------------------------------------------------- | ------ | --------------------------- | | `5xx`, network error, timeout (use 30 s) | Yes | Backoff | | `429` | Yes | Wait `Retry-After` | | `401 token_expired` | Yes | Get a new token | | `401 timestamp_out_of_window`, `delivery_replayed` | Yes | Re-sign (same event ids) | | `409 idempotency_in_progress` | Yes | Wait a moment | | Per-event `processing_error` | Yes | Resend that event (same id) | | Any other `4xx`, per-event `retryable: false` | **No** | Fix something first | ## Backoff [#backoff] Exponential, starting at 1 s, doubling, capped at 300 s, with ±20% jitter. Keep retrying for up to 72 hours, then dead-letter locally and alert. Transient failures are always `503` or `429` with `Retry-After`, on every path, including raw HL7 (never an `AR`). ## Idempotency [#idempotency] * **Events** are idempotent by `(source, event id)` for 30 days. A retry with the same ids is always safe. * **Other writes** (write-back, webhook management, sandbox operations) require an `Idempotency-Key` header (1–255 characters; a UUID is recommended; never patient data). Keys last 24 hours. * Same key while the first is still running: `409 idempotency_in_progress`. * Same key with a different request: `422 idempotency_key_reused`. * Completed: the stored response is replayed with `Idempotent-Replayed: true`. * Errors before the handler ran (authentication, validation, 429) release the key so you can fix the request and retry with the same key. ## Ordering [#ordering] Send each feed through a single-threaded queue so events for a visit arrive roughly in order. EDFlow doesn't depend on it: events are applied by precedence, and events within one batch in array order. ## Size and count limits [#size-and-count-limits] | Limit | Value | | ----------------------- | ----------------------------------------------- | | Request body | 512 KiB (HL7 JSON mode: 13 MiB) | | `POST /v1/events` | 1 event, 32 KiB | | `POST /v1/events/batch` | 1–100 events | | FHIR Bundle | 200 entries | | HL7 | JSON mode 50 messages; raw mode 1; each 256 KiB | | List `limit` | 100 | | Webhook endpoints | 20 per app, 50 per organization per environment | | Apps | 50 per organization per environment | | Credentials per app | 2 client secrets, 10 API keys, 5 public keys | | IP allowlist | 50 CIDR entries | | Roster entries | 1,000 | ## Related [#related] * [Errors](/developers/errors) * [Engine configuration](/developers/engine-configuration) # Sandbox (https://docs.edflow.space/developers/sandbox) Create a sandbox app and develop against the EDFlow sandbox: synthetic-only enforcement, fictional hospitals, simulator scenarios, dry-run validation, fault injection, conformance profiles including outage_recovery, and resetting, plus how customer test differs. The sandbox is where you build and test your integration against fictional hospitals. It is a separate deployment from customer test and live, so sandbox credentials can never reach real data. ## Create a sandbox app [#create-a-sandbox-app] In the developer portal: **Apps → New app**, environment **Sandbox**. Sandbox apps are active immediately, with no approval. Then follow the [quickstart](/developers/quickstart). ## Your sandbox organization [#your-sandbox-organization] When your organization is onboarded, it gets a sandbox organization with: * one fictional site per real site, with the same time zone and languages and a code ending in `-sbx`; * 20 active visits and 10 weeks of history, so estimates and analytics work; * a simulator source and sandbox staff accounts, so you can watch your events arrive on the staff board. ## Synthetic data only, enforced [#synthetic-data-only-enforced] The sandbox runs in the US and must never receive real patient data. It checks every ingest path: | Check | Rule | | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | Processing id | HL7 `MSH-11` must be `T` or `D`; FHIR Bundles must carry the `HTEST` tag | | Identifiers | Patient identifiers must start with `SYN`. A valid-checksum Ontario health card number, a site record-number pattern or a Canadian postal code is refused | | Names | Must come from the synthetic-name dictionary or start with `SYN` or `ZZTEST` | A refusal is `phi_suspected` (HL7: `AR` with `ERR-3` `202`). Nothing is stored. Your app's contacts are alerted, and after 3 hits in 24 hours the app is disabled until reviewed. **Hospital test-domain feeds go to customer test, never to the sandbox**, because test domains are often copied from production. _Screenshot pending: dev-console-tripwire_ ## The test console [#the-test-console] The portal's console sends events, HL7 or FHIR to the sandbox and shows the response, the derived events, a field trace and the event log entry. ![Test console against the sandbox: send an event and see the response and the event log entry.](https://docs.edflow.space/screenshots/web/dev-console-sandbox.png) Dry-run anything with `POST /v1/events/validate`: nothing is stored or notified. _validateInput: https://docs.edflow.space/openapi/edflow-v1.json_ ## Simulator scenarios [#simulator-scenarios] Run a scripted visit at up to 60× speed, delivered directly, signed, as HL7 v2 or as FHIR: _sandboxRunScenario: https://docs.edflow.space/openapi/edflow-v1.json_ Scenarios include walk-in discharge, chest pain admitted, CT with contrast, a child's fever with a urine sample, left without being seen, serial troponin, observation after anaphylaxis, codes, a feed outage with backfill and surge. See [Simulator](/admin/integration/simulator). ![EHR simulator (sandbox and showcase only): scenarios, arrival rate and the events it will send.](https://docs.edflow.space/screenshots/web/staff-simulator.png) ## Test webhooks and write-back [#test-webhooks-and-write-back] `POST /v1/sandbox/requests` creates a patient request on a synthetic visit, so you can receive `request.created` and try acknowledge and resolve. ## Fault injection [#fault-injection] Make your own app's requests fail or slow down, to test retries, queues and circuit breakers. Other apps are unaffected. | Fault | Effect | | --------------------- | ------------------------- | | `unavailable` | `503` with `Retry-After` | | `rate_limited` | `429` | | `latency` | Added delay, up to 20 s | | `token_endpoint_down` | `503` from `/oauth/token` | | `slow_ack` | Slow HL7 acknowledgements | _Screenshot pending: dev-console-faults_ _sandboxSetFaults: https://docs.edflow.space/openapi/edflow-v1.json_ ## Conformance profiles [#conformance-profiles] | Profile | Proves | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | `ingest` | Your declared event types, idempotent retries, out-of-order delivery, a prohibited-field rejection, heartbeat and roster | | `webhooks` | Your receiver verifies signatures, deduplicates a redelivery and drops an expired event | | `writeback` | Acknowledge and resolve with idempotency keys | | `outage_recovery` | EDFlow unavailable for 30 minutes: every message your engine queued lands afterwards with no `401`, no `idempotency_conflict` and no gap | | `clock_skew` | Timestamps judged against ±90 s | | `backfill_10k` | 10,000 events at the rate limit | _sandboxStartConformance: https://docs.edflow.space/openapi/edflow-v1.json_ ## Reset [#reset] `POST /v1/sandbox/reset` resets your organization's sandbox sites to the seed, deleting ledger rows and webhook history for them. ## Customer test [#customer-test] | | Sandbox | Customer test | | ------------------------ | -------------- | ------------------------------------------------------------ | | Data | Synthetic only | Your hospital's test-domain feeds, treated as real | | Location | US East | Canada | | Simulator, faults, reset | Available | Not available (reset only on the hospital's written request) | | Approval | None | Four eyes, like live | ## Related [#related] * [Go live](/developers/go-live) * [Sandbox and demo data](/start/demo) # SDKs and snippets (https://docs.edflow.space/developers/sdks-and-snippets) Code snippets in cURL, TypeScript and Python for every EDFlow API operation, signing helpers for the signed ingest profile with the conformance test vector, the OpenAPI document, Postman collection and typed clients. ## Snippets on every operation [#snippets-on-every-operation] Every page of the [API reference](/developers/api) shows cURL, TypeScript (fetch) and Python (httpx) for that operation, generated from the same OpenAPI document the API validates requests against. The quickstart and the developer portal use the same generators, and CI runs them against the sandbox. _validateInput: https://docs.edflow.space/openapi/edflow-v1.json_ ## Downloads [#downloads] | File | Where | | -------------------------------------------------- | ------------------------------------------------------------------------------------------ | | OpenAPI 3.1 document | [`/openapi/edflow-v1.json`](/openapi/edflow-v1.json), or `GET /v1/openapi.json` on the API | | Postman collection with a token pre-request script | [`/openapi/edflow-v1.postman.json`](/openapi/edflow-v1.postman.json) | | JSON Schemas for every event type | [Event reference](/developers/events) | | Mirth Connect and OIE channel templates | [Engine configuration](/developers/engine-configuration) | ## Typed clients [#typed-clients] Generate a client from the OpenAPI document with your usual tools (for example `@hey-api/openapi-ts` for TypeScript, `openapi-python-client` for Python, or Kiota for C# and Java). A published TypeScript SDK follows the document's version; Python, C# and Java SDKs are planned. ## Webhook verification [#webhook-verification] Use a Standard Webhooks library (TypeScript, Python, C#, Java, Go, PHP, Ruby, Rust, Elixir). No EDFlow SDK is needed. See [Webhooks](/developers/webhooks). ## Signing helper for the signed ingest profile [#signing-helper-for-the-signed-ingest-profile] TypeScript (WebCrypto, runs in Node 20+, Deno, Bun and browsers): ```ts const enc = new TextEncoder(); const hex = (b: ArrayBuffer) => [...new Uint8Array(b)].map((x) => x.toString(16).padStart(2, "0")).join(""); export async function signRequest( keyHex: string, req: { timestamp: number; deliveryId: string; method: string; path: string; siteCode?: string; input?: string; body: Uint8Array } ): Promise { const keyBytes = new Uint8Array(keyHex.match(/../g)?.map((h) => Number.parseInt(h, 16)) ?? []); const key = await crypto.subtle.importKey("raw", keyBytes, { name: "HMAC", hash: "SHA-256" }, false, ["sign"]); const bodyHash = hex(await crypto.subtle.digest("SHA-256", req.body)); const payload = `v2.${req.timestamp}.${req.deliveryId}.${req.method} ${req.path}.${req.siteCode ?? "-"}.${req.input ?? "-"}.${bodyHash}`; return `v2=${hex(await crypto.subtle.sign("HMAC", key, enc.encode(payload)))}`; } ``` Python (standard library): ```python import hashlib, hmac def sign_request(key_hex: str, timestamp: int, delivery_id: str, method: str, path: str, body: bytes, site_code: str | None = None, input_kind: str | None = None) -> str: body_hash = hashlib.sha256(body).hexdigest() payload = f"v2.{timestamp}.{delivery_id}.{method} {path}.{site_code or '-'}.{input_kind or '-'}.{body_hash}" return "v2=" + hmac.new(bytes.fromhex(key_hex), payload.encode(), hashlib.sha256).hexdigest() ``` cURL with OpenSSL: ```bash BODY_HASH=$(printf '%s' "$BODY" | openssl dgst -sha256 -r | cut -d' ' -f1) PAYLOAD="v2.$TS.$DELIVERY_ID.POST /ehr/v1/events.-.-.$BODY_HASH" SIG=$(printf '%s' "$PAYLOAD" | openssl dgst -sha256 -mac HMAC -macopt hexkey:"$SOURCE_KEY_HEX" -r | cut -d' ' -f1) curl -sS "$INGEST_URL/ehr/v1/events" -H "Content-Type: application/json" \ -H "EDFlow-Source: $SOURCE_ID" -H "EDFlow-Delivery-Id: $DELIVERY_ID" \ -H "EDFlow-Timestamp: $TS" -H "EDFlow-Signature: v2=$SIG" --data-binary "$BODY" ``` ## Test vector [#test-vector] These values are for conformance testing only. **Never use this secret anywhere.** Your helper must reproduce the expected signature exactly. | Input | Value | | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Deployment secret (test only) | `test-only-ehr-webhook-secret-0123456789abcdef` | | Source id, key version | `demo-epic-bridges`, `1` | | Source salt | `5f0c2a9e7b3d41c8a6e2f19d04b7c3aa` | | Derived source key (hex) | `c60acc8548b1d9ac8ba57abf6fb1fa513703e2787cbc942a3ff15618720fbfdc` | | `EDFlow-Timestamp` | `1789398000` | | `EDFlow-Delivery-Id` | `0b9f5c1e-8d0a-4f64-9a51-2d8c9f3e7a10` | | Body (217 bytes) | `{"events":[{"specVersion":"1.0","id":"demo-epic-bridges:hb:1789398000","type":"system.heartbeat","occurredAt":"2026-09-14T11:00:00-04:00","source":{"kind":"ehr","system":"epic","feed":"adt"},"data":{"queueDepth":0}}]}` | | SHA-256 of the body | `76d9b18a75579fe36228573f389d77904b49520b84a68914a22b3dbf5a2638af` | | Expected for `POST /ehr/v1/events` | `v2=e5eaca410459497d88e031d034aef07ad4e9e2e323631500349660c007573eb4` | | Expected for `POST /ehr/v1/validate` with input `events` | `v2=b44ef01ad218c1df9dc97c30cfaeef977d58b8bb1c82700693c3bff6573c6356` | | Expected for `/ehr/v1/events` with site code `demo-ed` | `v2=9ef2923903e4751138ab685b1ef6c4ca7f12962d97da1d9d94e6208c0d995346` | The last row must **not** verify against the first signature: v2 binds the site code and input kind. ## Related [#related] * [Authentication](/developers/authentication) * [Build with AI](/developers/build-with-ai) # SMART on FHIR (https://docs.edflow.space/developers/smart-on-fhir) The optional SMART on FHIR launch that opens a patient's EDFlow card inside Epic or Oracle Health FirstNet without a second login: the flow, prerequisites per vendor, and why staff access stays invite-only. SMART on FHIR staff launch is planned for release 1.1 and is optional. Microsoft Entra ID sign-in is simpler and should come first. ## Why [#why] Staff can open a patient's EDFlow card and requests from inside the EHR in patient context, without a second sign-in. This helps adoption. Nothing is written to the EHR. ## Flow [#flow] ### EHR launch [#ehr-launch] The EHR opens EDFlow with `launch` and `iss`. ### Authorize [#authorize] EDFlow requests `launch openid fhirUser patient/Encounter.rs patient/Patient.rs` from the site's authorization server (SMART App Launch 2.x). ### Resolve the user [#resolve-the-user] `fhirUser` (a Practitioner) must resolve to an **existing, invited** staff membership through its EHR identities. **SMART never creates accounts.** ### Resolve the visit [#resolve-the-visit] The launch Encounter's identifier (CSN or FIN) is hashed with the site's key and matched to the EDFlow visit. ### Open the card [#open-the-card] Authorization is still enforced by EDFlow with the membership's role and site. Opening is audited like any other. ## Prerequisites [#prerequisites] | Vendor | What's needed | | ------------- | ----------------------------------------------------------------------------------------------------- | | Epic | App registration, activation by the hospital, and a Hyperspace activity or Track Board toolbar button | | Oracle Health | Registration in Oracle's developer console and a Millennium SMART app configuration | | Both | The hospital's security review of redirect URIs and token handling | ## One-tap "Seen again" [#one-tap-seen-again] With the launch in place, a physician can mark "Seen again" from the EHR context in one tap, which improves the results-to-reassessment measure. ## Related [#related] * [Identity and SSO](/security/identity-and-sso) * [FHIR R4](/developers/fhir) # Versioning and deprecation (https://docs.edflow.space/developers/versioning-and-deprecation) How the EDFlow API and event contract are versioned: the URL major version, dated Api-Version pins, specVersion, notice periods for new enum values and event types (60 days) and breaking changes (12 months), Deprecation and Sunset headers, and host migration. Hospital change boards plan in quarters, so EDFlow changes the contract slowly and with notice. ## Four version axes [#four-version-axes] | Axis | Example | Changes when | | ----------------------- | ------------ | --------------------------------------------------------------------------------- | | URL major | `/v1` | A breaking redesign becomes `/v2`; `/v1` stays supported at least 12 months after | | Dated `Api-Version` | `2026-10-01` | A breaking change within v1 ships only behind a new dated version | | Document `info.version` | `1.4.0` | Every published change to the OpenAPI document (semver) | | Event `specVersion` | `1.0` | The normalized event contract, independently | Each app is pinned to the latest dated version when created. Override per request with `Api-Version`; webhooks render in the endpoint's pinned version. `GET /v1/meta` returns the compatibility table: for each dated version, the URL major, the document versions, the event `specVersion` values accepted and emitted, the HL7 support-matrix version, the FHIR IG version, and its deprecation and sunset dates. ## Additive changes [#additive-changes] New endpoints, optional request fields and response fields can ship at any time. Your client must ignore unknown fields. **New enum values in responses, new webhook event types and new error codes** are announced in the changelog at least **60 days** before they reach customer test or live, and appear in the sandbox first. Map enums through lookup tables with a default. Endpoints subscribed to `["*"]` don't receive new event types unless they opt in. ## Breaking changes [#breaking-changes] At least **12 months'** notice for any breaking change: a dated version, an operation or a major version. Deprecated operations send: ```http Deprecation: @1830297600 Sunset: Wed, 01 Mar 2028 00:00:00 GMT Link: <…/developers/changelog#…>; rel="deprecation" ``` After the sunset, the operation returns `410 gone`. The developer portal lists your app's calls to deprecated operations. App contacts are emailed at announcement. ## Host migration [#host-migration] Engine configurations, firewall allowlists and `private_key_jwt` audiences embed hosts, so API hosts don't change with branding and change only under this policy: 1. Announced by email to every app contact and in the changelog at least 12 months ahead. 2. During the migration both hosts serve the API, the token endpoint accepts both audiences and the issuer stays the same until the last app has moved. 3. Egress IP changes have the same notice; new IPs are published in `/v1/meta` 90 days before first use. 4. `/v1/meta` tells apps still calling the old host where to go. ## Related [#related] * [Changelog](/developers/changelog) * [API reference](/developers/api) # Webhooks (https://docs.edflow.space/developers/webhooks) Receive signed EDFlow webhooks (Standard Webhooks): subscribe, verify signatures, deduplicate on webhook-id, order by version, expiry, retries and auto-disable, authenticating to your gateway, event types, and redelivery. EDFlow delivers outbound events with [Standard Webhooks](https://www.standardwebhooks.com/), so you can verify them with an off-the-shelf library. Deliveries are **at least once**, **unordered**, **thin** (ids and structured fields, never free text), **signed** and **time-limited**. ![Webhook endpoints: URL, subscribed event types, status and the signing secret (masked).](https://docs.edflow.space/screenshots/web/dev-console-webhooks.png) ## Subscribe [#subscribe] Create an endpoint in the portal or with the API: an `https` URL, the event types (or `["*"]`), the sites, and optionally how EDFlow authenticates to your gateway. The signing secret (`whsec_…`) is shown once. _createWebhookEndpoint: https://docs.edflow.space/openapi/edflow-v1.json_ Endpoints must use `https`, a DNS name and port 443 or 1024–65535. Private, loopback and cloud-metadata addresses are refused. In customer test and live, deliveries come from fixed egress IP addresses listed by `GET /v1/meta`; expose your receiver through your DMZ or API gateway. ## Event types [#event-types] | Type | When | Sensitive | | --------------------------------------------------------------- | ------------------------------------------------- | --------- | | `request.created` | A patient request passes its 5-second undo window | ✓ | | `request.acknowledged`, `request.resolved`, `request.cancelled` | Staff, API or the patient act on it | ✓ | | `request.escalated` | An escalation step | ✓ | | `task.completed`, `task.confirmed` | Patient marks a task done; staff confirm | ✓ | | `encounter.stage_changed` | The derived stage changes | ✓ | | `encounter.access_activated` | The first patient session on the visit | ✓ | | `code.called`, `code.updated`, `code.cleared` | Department code alerts | | | `feed.state_changed` | Feed healthy, delayed or down | | | `ingest.dead_lettered`, `ingest.roster_quarantined` | Ingest problems to fix | | | `integration.credential_expiring` | 30, 7 and 1 days before expiry | | | `visit.communication_log_ready` | Departure, when document write-back is on | ✓ | | `webhook.test` | The test button | | Sensitive types are delivered only when your app holds the matching read scope and the site's capability switch is on; each delivery is recorded as a disclosure for the patient's access report. New event types are announced at least 60 days before they reach customer test or live. An endpoint subscribed to `["*"]` only gets new types if you opt in with `includeNewEventTypes`. ## The request [#the-request] ```http POST /hooks HTTP/1.1 Content-Type: application/json webhook-id: msg_01J8ZR2K7Q4M9X3B5T1V6N8C0D webhook-timestamp: 1789398764 webhook-signature: v1,K5oZfzN95Z9UVu1EsfQmfVNQhnkZ2pj9o9NDN/H/pI4= {"id":"msg_01J8ZR2K7Q4M9X3B5T1V6N8C0D","type":"request.created","timestamp":"2026-09-14T14:12:44.310Z", "expiresAt":"2026-09-14T16:12:44.310Z","apiVersion":"2026-10-01","environment":"sandbox","site":"your-site-sbx", "data":{"object":"request","id":"req_4f8k2m9q1t7v","version":1,"encounterId":"enc_7k2m9q4t8v3w5x1y", "type":"blanket","category":"need","priority":"low","status":"open", "…": "…"}} ``` ## Verify [#verify] The signature is `base64(HMAC-SHA256(secret, webhook-id + "." + webhook-timestamp + "." + rawBody))`, sent as `v1,`. During a rotation, two space-separated signatures are sent. ```ts import { Webhook } from "standardwebhooks"; const wh = new Webhook(process.env.EDFLOW_WEBHOOK_SECRET ?? ""); // "whsec_…" export async function POST(req: Request) { const body = await req.text(); // raw body, never re-serialized JSON const msg = wh.verify(body, Object.fromEntries(req.headers)) as { id: string; type: string; expiresAt: string; data: { id: string; version: number }; }; if (Date.parse(msg.expiresAt) < Date.now()) return new Response(null, { status: 204 }); if (await alreadyProcessed(msg.id)) return new Response(null, { status: 204 }); await enqueue(msg); // apply only if data.version is newer than what you hold return new Response(null, { status: 204 }); } ``` ```python from standardwebhooks.webhooks import Webhook wh = Webhook(os.environ["EDFLOW_WEBHOOK_SECRET"]) msg = wh.verify(request.get_data(), dict(request.headers)) # raises on a bad signature or stale timestamp ``` ## Receiver checklist [#receiver-checklist] 1. Verify the signature against the **raw** body, in constant time. Reject timestamps more than 5 minutes from now. 2. Drop messages whose `expiresAt` has passed (answer 2xx). 3. Deduplicate on `webhook-id` for at least 7 days. 4. Keep the highest `version` per object `id`; don't rely on arrival order or `updatedAt`. 5. Answer 2xx within 15 s; do the work asynchronously. ## Retries and failure [#retries-and-failure] | Rule | Value | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | Success | Any 2xx within 15 s | | Redirects | Not followed; a 3xx is a failure | | Schedule | Immediately, then +5 s, +5 min, +30 min, +2 h, +5 h, +10 h, +14 h, +20 h, +24 h (about 3 days, with jitter), but never after `expiresAt` | | 429, 502, 503, 504 | Retried; `Retry-After` honoured up to 1 hour | | 410 Gone | The endpoint is disabled immediately | | Auto-disable | No success for 5 days with 10 or more failures; owners are emailed | | Throughput | At most 10 deliveries per second and 4 in flight per endpoint; a circuit breaker pauses a failing endpoint | _Screenshot pending: dev-console-webhook-deliveries_ ## Redelivery and recovery [#redelivery-and-recovery] The delivery log shows every attempt with its status code. **Redeliver** one delivery, or **Recover** everything since a time after an outage (within 30 days). Expired sensitive events are redelivered only if you ask explicitly. ## Authenticating EDFlow to your gateway [#authenticating-edflow-to-your-gateway] Besides the signature, an endpoint can require OAuth 2.0 client credentials (you give EDFlow a client id, secret and token URL) or mutual TLS (EDFlow presents its outbound client certificate). Custom headers are stored encrypted. ## Rotating the secret [#rotating-the-secret] **Rotate secret** issues a new secret; both sign during the overlap (1 to 168 hours, default 24), then the old one retires. ## Related [#related] * [Errors](/developers/errors) * [Versioning](/developers/versioning-and-deprecation) # Docs health (https://docs.edflow.space/meta/docs-health) noindex. Coverage dashboard generated at build: screens documented, screenshot capture state, French coverage and pages past their review date. This page is for the documentation team. It is generated at every build and is not indexed by search engines. ## How to act on it [#how-to-act-on-it] * **Undocumented screens**: add the screen id to the `screens` frontmatter of the page that documents it, or add a waiver with a reason and an expiry date. * **Pending screenshots**: they are captured automatically from the synthetic docs deployment by `pnpm docs:capture` and the screenshot pull request; never commit screenshots from a laptop. * **French coverage**: patient, family and getting-started pages need French versions reviewed by a human translator and a clinical reviewer before a pilot. * **Pages past review**: re-read the page against the current product and update `reviewedAt`. # Release 1.2 (https://docs.edflow.space/releases/1-2-0) EDFlow 1.2: the Integration API and developer portal, signed webhooks, the documentation site with automated screenshots, brand configuration and co-branding, email and SMS delivery, and AI features that stay off until a site approves them. Release 1.2 opens EDFlow to hospital integration teams and adds the documentation you're reading. Nothing changes for patients or staff until a site turns a new capability on. ## For patients [#for-patients] * Clearer going-home summaries, with follow-ups you can add to your calendar and a summary link that asks for your date of birth. * Text updates, and texting the summary link to yourself, where your hospital turns them on. Numbers are confirmed with a 6-digit code first. * Where a hospital approves it: an assistant that answers questions about your visit from the same information you already see. See [Ask the assistant](/patients/ask-the-assistant). ## For family [#for-family] * Text updates for the big steps, from your own phone number, confirmed with a code and deleted when the link ends. * An update history of what you were told. ## For the care team [#for-the-care-team] * The companion app's staff mode on hospital-managed phones: inbox, my patients, patient card, department and on-shift status. * Where a site turns them on: a request queue digest and patient message drafts that you review before sending. See [AI assistance](/staff/ai-assistance). * Quick-reference cards for every role in these docs. ## Public product experience [#public-product-experience] The product carousel keeps its place when switching views. Autoplay and the progress bar share a nine-second timer; hovering does not stop it, and Play resumes from the paused position. The desktop hero uses 64 px side padding. The public website now has photographic product pages and an interactive preview of the patient, family and care-team views. All people, places and visits in the marketing imagery and previews are illustrative. Preview requests and sharing controls use local sample data and do not contact a care team or change a real visit. The Product menu opens with a pointer or touch and spans the page width. Its photographs fade in and out in a subtle sequence that reverses smoothly when the pointer moves away. Scrolling closes it without moving the page back to the menu; reduced motion removes the transitions. Preview tabs and dots also work with a keyboard. Automatic rotation pauses during interaction and respects reduced-motion preferences. ## For administrators [#for-administrators] * Co-branding with your hospital's logo (production only, with a second approver). * Email and SMS channels with generic templates, send-a-test to your own verified contact, and the outbox. * AI settings per site with governance gates and a kill switch; everything is off by default. See [AI](/admin/ai). * Analytics: Ask your data, where enabled. ## For developers [#for-developers] * The Integration API: OAuth 2.0 client credentials (`private_key_jwt`, client secret, mTLS), ingest as normalized events, FHIR R4 and HL7 v2 over HTTPS, reads, request write-back. * Standard Webhooks with 18 event types, redelivery and recovery. * The developer portal, the sandbox with fault injection and conformance profiles, and Mirth Connect / OIE channel templates. * See the [API changelog](/developers/changelog). ## For IT and security [#for-it-and-security] * The [security review pack](/security/compliance-documents), the [sub-processor list](/security/subprocessors) and [AI governance](/security/ai). * Credentials with per-organization KMS keys, and the privileged-access model. # Release notes (https://docs.edflow.space/releases) What changed in each EDFlow release, for patients, family, the care team, administrators, developers and IT, with upgrade notes for self-hosted hospital deployments. Each release has one page with a section per audience and, for self-hosted hospital deployments, upgrade notes. The staff and administrator sections also appear in the app under **What's new**, so the console and these notes say the same thing. ## Releases [#releases] | Release | Highlights | | ---------------------- | ------------------------------------------------------------------------------------------------------------------ | | [1.2](/releases/1-2-0) | Integration API and developer portal, webhooks, these docs, co-branding, email and SMS, AI features off by default | ## Follow releases [#follow-releases] * [RSS feed](/releases/rss.xml) * The API and event contract have their own [changelog](/developers/changelog). ## How release notes are made [#how-release-notes-are-made] At each release cut, a draft is generated from the merged changes and their audience labels, then edited by people. When the release is tagged, the staff and administrator sections are published to the in-app **What's new**. # Accessibility (https://docs.edflow.space/security/accessibility) EDFlow accessibility conformance for hospital reviewers: WCAG 2.2 AA on every surface, how it is tested (axe in CI, keyboard, screen readers, Dynamic Type and font scale), the conformance report, and known issues. Every patient, family, staff, admin and display screen targets **WCAG 2.2 level AA**, and so do these docs. ![Visit screen: the current step is Tests under way, with what happens next, the care team card, a usual wait range and the I feel worse button.](https://docs.edflow.space/screenshots/web/patient-visit-home.png) ## How it's tested [#how-its-tested] | Method | Where | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | axe (WCAG 2.2 AA rules) | Every web end-to-end test, light and dark, English and French; build fails on a violation | | Keyboard | Every flow operable without a mouse; visible focus; shortcuts documented | | Screen readers | VoiceOver (macOS, iOS), TalkBack, NVDA and JAWS on release candidates | | Text size | Web at 200% on a 360-pixel phone with no horizontal scroll or clipping; iOS Dynamic Type to the largest accessibility sizes; Android font scale 200% | | Colour | Status never by colour alone (greyscale snapshot tests); contrast checked on tokens | | Motion | Reduced motion honoured; no flashing; notices fade in 200 ms at most | | Target size | Controls at least 44 px (48 px for patient request tiles); every swipe action has a button | ## Patient-specific design [#patient-specific-design] * Plain language at grade 6 to 8, checked in CI. * The "I feel worse" screen and delay notices take focus and announce their title. * Stage changes are announced politely without moving focus. * English and French everywhere, plus safety messages in up to five community languages. ## Conformance report [#conformance-report] An Accessibility Conformance Report in VPAT 2.5 INT format is part of the security package, with the known issues from the latest CI run. Request it from [Compliance documents](/security/compliance-documents). ## Reporting a problem [#reporting-a-problem] Report accessibility problems through the contact page on the product site; they are triaged like defects. ## Related [#related] * [Languages and accessibility](/start/languages-and-accessibility) # AI governance (https://docs.edflow.space/security/ai) How EDFlow governs AI: models and providers, zero data retention and no training, data classes C0 to C3, what leaves the tenant, human approval, the medical-device boundary, enablement gates G-AI-1 to G-AI-6, the kill switch and opting a visit out. AI features are **off by default** for hospital tenants and are turned on one by one, per site, after the gates below. When they're off or unavailable, the normal screens work as usual. ## Principles [#principles] * **The facts come from the product, not the model.** Patient and family answers are cards built from the same data the screens show, with at most a few connecting phrases chosen from a reviewed phrase bank. Free text from the model is never shown to patients or family. * **Same identity, same view.** AI tools run with the caller's own permissions and projection. * **Minimum necessary to the model.** Each feature declares its data class and an allow-listed context. Names are replaced by references before the model and restored after. * **The model is never the last line of defence.** Deterministic filters run before and checks after every call. * **People take actions.** Anything that changes state or reaches another person needs a person's approval. The only automatic action is the deterministic safety alert (self-harm or undismissed distress), triggered by a word list, never by the model. * **Not an emergency channel.** The "I feel worse" button stays on every AI screen, and distress shows the tell-staff-now card even offline. * **Honest about being AI.** Every AI message carries a label; machine translation carries a badge. ## Intended use [#intended-use] EDFlow's AI helps people find and understand information about visit logistics that the product already shows, drafts plain-language text for staff to review, and summarises operational data. It does not interpret symptoms or results, give treatment advice, decide who is seen first, or estimate individual clinical outcomes. A regulatory memo confirming this non-device intended use is one of the enablement gates. ## Data classes [#data-classes] | Class | Meaning | May reach a model | | ----- | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | C0 | No patient information: catalogue, approved content, UI text, synthetic samples, public docs | Yes | | C1 | De-identified aggregates with small-cell suppression | Yes | | C2 | **PHI**: pseudonymised visit state (keys, enums, bucketed times, display strings) | Only after the privacy office's approval, never for confidential visits | | C3 | **PHI**: scrubbed free text or audio from a person | Only after approval, per feature, minimised and scrubbed | **Never sent to any model**: names, dates of birth, health card, record or visit numbers or their hashes, internal ids, tokens or codes, phones, emails, addresses, CTAS, chief complaint, room or bed labels, result content, sensitive tests or consults, or anything about a confidential visit. ## Providers and retention [#providers-and-retention] * Requests go through Vercel AI Gateway to an allow-listed provider (Anthropic, Amazon Bedrock, Google Vertex AI), with **zero data retention** and **prompt training disallowed** on every request and team-wide. Each response's routing is verified; a violation discards the output and raises an alert. * Inference currently runs in the US. For hospital tenants, **phase 1** runs only C0 and C1 features, so no patient-derived data leaves Canada. **Phase 2** (C2, C3) needs the privacy office to accept US processing under zero data retention. * Web voice transcription stays off for hospital tenants until zero retention is confirmed in writing and a PHIPA flow-down agreement exists. Native voice runs on the device. * The hospital's service keeps assistant conversations for 7 days after the session by default (0 to 30); conversations with a safety event are kept for the operational window for review. See [Subprocessors](/security/subprocessors). ## Enablement gates [#enablement-gates] A patient- or family-facing feature can't be turned on in production until each gate is recorded: | Gate | Evidence | | ------ | -------------------------------------------------------------------------------------------------- | | G-AI-1 | Privacy office approval of the data flows, including the written agreement chain | | G-AI-2 | Regulatory memo on the non-device intended use | | G-AI-3 | Clinical lead sign-off of the evaluation report (critical safety suites with no failures observed) | | G-AI-4 | PIA addendum and TRA update | | G-AI-5 | Hazard log reviewed for the release | | G-AI-6 | Staff briefing done | Staff-only and aggregate features need G-AI-1 and G-AI-4. A platform administrator can't bypass the gates. ## Controls you can use [#controls-you-can-use] * **Per-site switches** for every feature, languages, budget and retention. See [AI](/admin/ai). * **Kill switch**: every AI entry point disappears within seconds across all sites. * **Opt a visit out**: staff can turn AI off for a patient's visit at the patient's or substitute decision-maker's request. * **Safety review**: flagged conversations are reviewed by a group outside the care team, with conflict rules and audit. See [AI review](/admin/privacy/ai-review). ## Evaluation [#evaluation] Every prompt or model change runs evaluation suites (safety, scope, style, injection, family scope) before release. The showcase deploys only after the critical suites pass for the exact prompt and model versions. ## Related [#related] * [Ask the assistant](/patients/ask-the-assistant) * [AI assistance](/staff/ai-assistance) # Architecture (https://docs.edflow.space/security/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. ## System context [#system-context] ```mermaid flowchart LR subgraph People PAT[Patient phone] FAM[Family member] STF[Staff workstation and managed phone] TV[Waiting-room display] end subgraph Hospital[Hospital network] EHR[EHR] --> ENG[Integration engine] ENTRA[Microsoft Entra ID, optional] end subgraph Service[The service] WEB[Web tier: Next.js] APP[Mobile apps: iOS, Android] BE[Backend: Convex database, functions, auth, scheduler, HTTP actions] end subgraph Providers[Optional providers, generic content only] PUSH[Push: Expo, APNs, FCM] SMS[SMS] MAIL[Email] end PAT --> WEB PAT --> APP FAM --> WEB STF --> WEB STF --> APP TV --> WEB WEB <-->|WebSocket, auth cookie proxy| BE APP <-->|WebSocket| BE ENG -->|HTTPS, signed or OAuth| BE STF -.->|OIDC| ENTRA BE --> PUSH BE --> SMS BE --> MAIL ``` ## What crosses each boundary [#what-crosses-each-boundary] | Boundary | Carries | Never carries | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Engine → backend | Minimized events, FHIR Bundles or HL7 messages; prohibited fields are dropped or rejected before anything is stored | Result values, notes, diagnoses, health card numbers, addresses, phones | | Browser or app ↔ backend | The signed-in person's projected view only | Anything outside that person's allow-list | | Browser ↔ web tier | Static assets, the app shell, auth cookies | Rendered patient data: the web tier never renders patient data on the server | | Backend → push, SMS, email providers | Generic template text, opaque links | Names, test names, hospital names, clinical words, code types | | Backend → AI gateway | Only what a site's approved AI features need, under zero data retention | Anything before the site's privacy approval | ## Runtime containers [#runtime-containers] | Container | Runs | Region (hospital production) | | --------- | -------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Web tier | Next.js app: token shells, patient and family web, staff console, admin, display, stations; the auth cookie proxy | Vercel functions in `yul1` (Montréal), or a container in the hospital's Canadian account | | Backend | Self-hosted Convex: database, functions, auth, scheduler, crons, HTTP actions (ingest, integration API, provider webhooks) | AWS `ca-central-1`, RDS PostgreSQL with KMS customer-managed keys; DR `ca-west-1` | | Edge | AWS WAF, load balancer and an edge tier that validates client IPs and mTLS for the API | `ca-central-1` | | Mobile | iOS and Android apps; session tokens in the device's secure store | On device | | Docs | This site, public documentation only | Vercel | The demo, development and sandbox run on Convex Cloud (US East) with **synthetic data only**; they are separate deployments that can never reach hospital data. ## Environments [#environments] | Environment | Data | Where | | ----------------------------------- | ----------------------------------------------- | ------------------ | | Development, showcase, docs capture | Synthetic, enforced | Convex Cloud, US | | Integration sandbox | Synthetic, enforced (real-looking data refused) | Convex Cloud, US | | Customer test | Hospital test-domain data, treated as PHI | AWS `ca-central-1` | | Hospital production | PHI | AWS `ca-central-1` | Synthetic-only features (the simulator, seed data, demo sign-in, reset) refuse to run unless the deployment is non-production, marked synthetic and on an allow-list, and they are not built into production bundles. ## Realtime and offline [#realtime-and-offline] Clients subscribe to live queries over WebSocket; there is no polling. When a phone goes offline, the app shows the last known view with its time; the native app keeps it encrypted and deletes it when access ends, even without a network. ## Related [#related] * [Data flow](/security/data-flow) * [Controls](/security/controls) * [Concepts](/developers/concepts) for integration teams # Audit logging (https://docs.edflow.space/security/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. ![Audit log: every access and change with who, what, when and from where, with filters and export.](https://docs.edflow.space/screenshots/web/admin-audit-log.png) ## Coverage [#coverage] | Group | Recorded | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Patient and family access | Sessions created and ended, rejected tokens, failed sign-ins, rate limits, identity confirmed or mismatched, device approvals, family links created, opened and revoked | | Staff authentication | Sign-ins and failures, lockouts, MFA enrolment and resets, password changes, SSO rejections, session revocations | | Staff access to patient data | Board views (per session every 15 minutes), each patient opened with its tab, unmasks with reasons, card issuing and pairing approvals, payload reveals, exports | | State changes | Every manual action, overrides, result holds and releases, care-team changes, tasks, request actions, call-backs, summary publication, privacy flags, updates pauses | | Department | Codes, delay notices, volume changes, imaging service status | | Administration | Settings changes with before and after values, invites and roles, approvals, stations, content status, announcements, access reviews, training mode | | Integration and API | Sources and keys, apps, credentials, scopes, write-back, disclosures to each integration | | Privacy and platform | Audit views and exports, retention runs, legal holds, incidents, emergency revokes, support access, simulator and seed actions | | AI | Safety conversations opened, automatic alerts, governance gates, the kill switch | ## The record [#the-record] Time, site, actor type (patient, family, staff, station, system, integration, platform), actor, membership and roles, action, subject, visit, outcome (success, denied, error), reason, details, device class and any support-access id. **Never** names, tokens, phone numbers, emails, message bodies or free text. Denied authorization attempts inside writes are logged with `denied`. ## Integrity [#integrity] The audit table is append-only: nothing updates or deletes rows except the retention job after the audit period. Each night the previous day's rows are hashed in order and chained with the prior day's digest; exports include the digests so tampering can be detected. Integration request logs are sealed into the same chain and archived with S3 Object Lock. ## Monitoring [#monitoring] Rules raise alerts to the privacy office, for example: more than 30 patients opened by one user in an hour; a confidential visit opened by someone off its care team; more than 3 unmasks in 12 hours; failed sign-ins against one visit; support access started; a privileged role granted; a trust anchor changed; an integration reading far more visits than usual. See [Privacy officers](/admin/privacy). ## Access reports and export [#access-reports-and-export] * **Per-patient access report**: every access to one visit, including each integration that received its data, as CSV or PDF. * **SIEM**: on-request export as CSV or NDJSON, with scheduled delivery to a hospital HTTPS endpoint or bucket in a later release. A site can't take live integration traffic unless the SIEM export or the sealed archive is active. Audit exports need a second privacy officer's approval and are themselves audited. ## Retention [#retention] 2 years by default (site range 2 to 10), deleted with their digests. ## Related [#related] * [PHIPA](/security/phipa) * [Privileged access](/security/privileged-access) # Availability and incidents (https://docs.edflow.space/security/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 [#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% [#the-ha-topology-behind-999] 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 [#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 [#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 [#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 [#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 [#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 [#related] * [Data residency](/security/data-residency) * [When the feed is down](/staff/charge/feed-down) # Compliance documents (https://docs.edflow.space/security/compliance-documents) What EDFlow publishes, what is shared under NDA (the security review pack, PIA and TRA inputs, penetration test summary, questionnaire answers), the SOC 2 position stated accurately, and how to request documents. ## Public [#public] Everything in [IT and security](/security): architecture, data flow, PHIPA roles, controls, threat model summary, residency, sub-processors, accessibility, identity, network requirements, service levels, audit logging, AI governance and privileged access. ## Under NDA: the security review pack [#under-nda-the-security-review-pack] | Document | Status for a pilot | | --------------------------------------------------------------------------------------------- | -------------------------------------------------- | | Architecture and data-flow diagrams | Ready | | Data inventory and classification | Ready | | PIA input (agent, electronic service provider, voluntary HINP duties) | Draft, completed with your privacy office | | TRA input, including the AI statement | Draft, completed with your security team | | Controls narrative mapped to the SOC 2 criteria | Ready | | Questionnaire master answers (CAIQ v4, SIG Lite); hospital-specific sheets answered from them | Ready | | Penetration test summary letter | Before live; then annually and after major changes | | SBOM and dependency policy | Generated in CI | | Accessibility conformance report (VPAT 2.5 INT) | Ready | | Incident response and breach notification | Runbook | | Privileged access and change control | Ready | | Support schedule, SLOs and DR evidence | Ready | ## SOC 2 [#soc-2] **There is no SOC 2 report yet.** A readiness assessment is under way; a Type I report is targeted before live and a Type II after a 6-month observation window. Until then, the pack includes our own control narrative mapped to the SOC 2 criteria, plus the SOC 2 reports of the infrastructure provider that holds live data (AWS). Those are **carve-outs**: they cover AWS's controls, not ours. Convex Cloud's SOC 2 covers only the sandbox and showcase. No bridge letter is offered, because there is no report period to bridge yet. ## Other assurance [#other-assurance] * Cyber and technology E\&O insurance (carrier and limits in the pack). * Background checks, annual privacy and security training, confidentiality agreements and quarterly access reviews for staff with privileged access. ## Request the pack [#request-the-pack] Use the contact page on the product site (https\://edflow\.space/contact) and choose **Security review**. Tell us your organization and role. We share the pack after an NDA is signed, and we answer your own questionnaire from the master answers. ## Related [#related] * [Controls](/security/controls) * [PHIPA](/security/phipa) # Controls (https://docs.edflow.space/security/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 [#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](/security/privileged-access) | | **Resilience** | See [Availability and incidents](/security/availability-and-incidents) | ## Security headers [#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 [#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 [#related] * [Threat model](/security/threat-model) * [Compliance documents](/security/compliance-documents) # Data flow (https://docs.edflow.space/security/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. ## From the EHR to the screen [#from-the-ehr-to-the-screen] ```mermaid 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 ``` 1. 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. 2. Ingest authenticates the sender, checks size and parses in memory. Raw messages are never stored or logged. 3. **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. 4. 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. 5. Each audience reads through its own allow-listed projection. ## Data inventory [#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 [#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 [#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 [#related] * [PHIPA](/security/phipa) * [Subprocessors](/security/subprocessors) * [Privacy](/patients/privacy), the patient's version # Data residency (https://docs.edflow.space/security/data-residency) Where EDFlow stores hospital data: AWS ca-central-1 with disaster recovery in ca-west-1, backups in Canada, RPO and RTO, the web tier in Montréal, and which environments hold synthetic data only. ## Hospital data stays in Canada [#hospital-data-stays-in-canada] | Component | Location | | ------------------------------------------------------------------ | --------------------------------------------------------------------------- | | Database and backend (self-hosted Convex, RDS PostgreSQL, S3, KMS) | AWS `ca-central-1` (Montréal) | | Disaster recovery | AWS `ca-west-1` (Calgary) | | Backups and point-in-time recovery | Canada | | Audit archive (S3 Object Lock) | `ca-central-1` | | Web server functions | Vercel `yul1` (Montréal), or a container in the hospital's Canadian account | | Static web assets | Global CDN (no patient data) | Patient and staff data travel from the browser or app straight to the Canadian backend over a WebSocket. The web tier never renders patient data on the server. PHIPA itself has no data-localization rule, but Ontario hospital policies usually require Canadian residency for PHI. Hospital production and customer test are therefore always in Canada. ## Recovery objectives [#recovery-objectives] | Scenario | RPO | RTO | | ------------------------------------- | ----------------------- | -------------------------------------------------- | | Instance or Availability Zone failure | 0 (synchronous standby) | 30 minutes (4 hours until the HA topology is live) | | Regional disaster | 15 minutes | 4 hours | | Customer test | 24 hours | 1 business day | Restores are tested quarterly, AZ failover twice a year, and a regional DR exercise once a year. Results are in the monthly service report. ## Synthetic-only environments [#synthetic-only-environments] These run on Convex Cloud in the US and **never** hold hospital data: * development and preview deployments; * the showcase (fictional hospitals); * the docs capture deployment; * the integration sandbox, which actively refuses real-looking data. ## Providers outside Canada [#providers-outside-canada] Push, SMS and email providers are in the US but receive only generic text and opaque links, and each is optional per site. AI processing in the US happens only for sites whose privacy office approves it. See [Subprocessors](/security/subprocessors). ## Related [#related] * [Architecture](/security/architecture) * [Availability and incidents](/security/availability-and-incidents) # Devices and device management (https://docs.edflow.space/security/devices) 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. ## Staff phones [#staff-phones] * The companion app's staff mode runs **only on hospital-managed phones**: the MDM app configuration carries the site's managed-device flag. * The app refuses staff mode on a phone with no passcode. * After 5 minutes in the background, it asks for Face ID, fingerprint or the passcode. * Sessions last 12 hours and can be ended remotely by a manager. * Lock-screen actions (for example "Can't go" on an urgent request) require device authentication. * Push payloads contain no patient details. * Recommended MDM settings: required passcode, OS updates within your policy window, managed app configuration, remote wipe. ## Shared workstations [#shared-workstations] The console is designed for shared workstations: the idle lock removes patient data from the screen after 15 minutes (site range 5 to 60), sessions end after 12 hours, and staff can see and end their own sessions. No patient data is cached in browser storage. ## Print and big-board stations [#print-and-big-board-stations] Print stations (visit cards) and big-board stations run under a **station credential** registered by a manager with a one-time code, never under a person's session. A station can only do its one job, has no idle lock, is audited with its id, and is revoked instantly. Put big-board stations only where patients and visitors can't see them. ## Waiting-room display [#waiting-room-display] A kiosk browser showing department-level information only: never a name, a code or an area. See [Network requirements](/security/network-requirements). ## Patients' phones [#patients-phones] Patients' phones are untrusted: they may be shared, lost or observed. The design assumes it: * tokens in URL fragments, removed from the address bar immediately; * generic lock-screen text by default; * optional Face ID or fingerprint lock in the app; * "Sign out and forget this device"; * the offline copy encrypted and deleted when access ends, even with no network; * the questions notepad stored only on the phone, encrypted with a key the server deletes at access end. ## Related [#related] * [Companion app](/staff/companion-app) * [Identity and SSO](/security/identity-and-sso) # Identity and SSO (https://docs.edflow.space/security/identity-and-sso) Staff identity in EDFlow: Microsoft Entra ID setup, MFA policy per role, the session policy table, SCIM provisioning and deprovisioning, and how patient and family access differs. ![Staff sign-in: work email and password, or sign in with Microsoft where the hospital uses it.](https://docs.edflow.space/screenshots/web/staff-sign-in.png) ## Staff accounts [#staff-accounts] * **Invite-only.** No self-registration. Invites expire after 72 hours; addresses outside the site's staff domains need a second manager's approval. * **Roles per site.** A membership links a person to a site with one or more roles. Privileged roles (manager, privacy, integration) need a second person's approval, and a privacy officer can't hold a manager or clinical role. ## Microsoft Entra ID [#microsoft-entra-id] Optional, per site: 1. Register an app in your Entra tenant with the redirect URI your EDFlow contact provides (OIDC authorization code with PKCE). 2. Provide the tenant id; the site restricts sign-in to allowed tenants and domains. 3. An Entra account is linked to a membership only by accepting an invite or while signed in with password and MFA. Guest accounts are refused. 4. The idle-lock unlock and step-up checks force a fresh Microsoft sign-in for the same user. | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | sso.allowedDomains | [] | array | Entra ID sign-in domains. (Reduces privacy) | | sso.allowedTenants | [] | array | Entra ID tenant ids (guests always refused). (Reduces privacy) | ## MFA [#mfa] | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | security.mfaRequiredForAll | true | boolean | MFA for every password sign-in (locked on in production, D-13). (Reduces privacy) | | security.mfaRequiredForAdmins | true | boolean | MFA for manager, privacy and integration roles (locked on everywhere). (Locked, Reduces privacy) | | security.staffIdleLockMinutes | 15 | 5–60 minutes | Staff idle lock. (Reduces privacy) | | security.staffSessionHours | 12 | 8–16 hours | Staff absolute session lifetime. (Reduces privacy) | | security.staffEmailDomains | [] | array | Invite domains that need no approval (D-64). (Reduces privacy) | | security.guestNetworkPrefixes | [] | array | Guest-network prefixes named in breaker alerts, never hard-blocked. (Reduces privacy) | MFA (TOTP) is required for every staff account in production, and for administrators everywhere. Ten recovery codes are shown once and stored only as hashes. Ten wrong codes in 24 hours lock MFA until a manager resets it. ## Session policy [#session-policy] | Principal | Policy | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Patient | Bound to one visit and one device. No idle timeout during the visit; read-only after departure; ends after the grace window. At most 5 concurrent devices and 8 per day; more are refused, never displacing another | | Family | Bound to one link and one device; at most 3 devices; ends with the link | | Staff (web) | Idle lock after 15 minutes (5 to 60); 12-hour lifetime (8 to 16); lockout after 5 failed passwords in 15 minutes from unknown devices | | Staff (companion app) | Hospital-managed phones only; biometric or passcode unlock after 5 minutes in the background; 12 hours; remote sign-out | | Stations (print, big board) | A device credential registered by a manager; one purpose; revoked instantly | | Platform operator | MFA mandatory; 8 hours; idle lock 10 minutes; site data only through audited support access | ## Provisioning and deprovisioning [#provisioning-and-deprovisioning] * **CSV import** with row-by-row validation. * **SCIM 2.0** for Entra ID or another IdP: a user disabled in the directory is deactivated within 5 minutes and their sessions end. * Deactivation revokes every session and every unused credential the user issued, at once. * A quarterly access review with attestation. ## Related [#related] * [Sign-in and security](/staff/sign-in-and-security) for staff * [Users and access](/admin/users-and-access) # IT and security (https://docs.edflow.space/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 [#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](/security/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](/security/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](/security/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](/security/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](/security/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](/security/controls) | | Audit | Append-only, daily hash chain, per-patient access report, proactive monitoring, SIEM export | [Audit logging](/security/audit-logging) | | Notifications | Generic text only: never names, tests or hospital names in push, SMS or email | [Data flow](/security/data-flow) | | PHIPA | EDFlow is the custodian's agent and electronic service provider, and meets the HINP duties voluntarily | [PHIPA](/security/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](/security/ai) | | Operations | No standing vendor access to production data; audited, time-boxed support access; two-person deployments | [Privileged access](/security/privileged-access) | | Availability | Published SLOs, 24/7 P1 response within 30 minutes, 24-hour breach notice | [Availability and incidents](/security/availability-and-incidents) | ## Confidential security package [#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](/security/compliance-documents) to request it. ## All pages [#all-pages] ## Frequently asked questions [#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](/security/data-residency). The product acts as the hospital's agent and electronic service provider. See [PHIPA](/security/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](/security/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](/security/identity-and-sso) and [Privileged access](/security/privileged-access). Request it from [compliance documents](/security/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](/security/ai). # Network requirements (https://docs.edflow.space/security/network-requirements) Hosts and ports to allow for EDFlow: web, the realtime WebSocket, push notifications, integration-engine egress to the API, the waiting-room display kiosk, and guest Wi-Fi guidance for patients. EDFlow needs no inbound access to the hospital network. Everything is outbound HTTPS (TCP 443) from the hospital. ## Staff workstations and the display [#staff-workstations-and-the-display] | Purpose | Host | | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | Web app (console, admin, patient and family web, display) | `https://app.edflow.space` | | Realtime updates | The backend's WebSocket host for your deployment (secure WebSocket on 443), provided at onboarding | | Auth cookie proxy | Same host as the web app (`/api/auth`) | | Documentation | `https://docs.edflow.space` | | Microsoft sign-in (if used) | `login.microsoftonline.com` | Allow secure WebSockets through any proxy that inspects TLS; the board and queue depend on a long-lived connection. ## Hospital-managed staff phones [#hospital-managed-staff-phones] Push notifications use Apple APNs and Google FCM through Expo: | Platform | Hosts | | -------- | ----------------------------------------------------------- | | iOS | `*.push.apple.com` (443, and 5223 where your MDM allows it) | | Android | `fcm.googleapis.com`, `mtalk.google.com` (5228–5230) | | Both | `exp.host` | ## Integration engine egress [#integration-engine-egress] | Purpose | Host | | ---------------------------------------- | ---------------------------------- | | Integration API and signed ingest (live) | `https://api.edflow.space` | | mTLS token endpoint (live) | `https://mtls.api.edflow.space` | | Customer test | `https://api.test.edflow.space` | | Sandbox | `https://api.sandbox.edflow.space` | In customer test and live, your engine's egress addresses go on the source's or app's IP allowlist. Webhooks to your receivers come from fixed egress IPs listed by `GET /v1/meta`; new IPs are published 90 days before first use. ## Waiting-room display [#waiting-room-display] A TV at 1920 × 1080 or larger with a current browser in kiosk mode, on a network that can reach the web app host over HTTPS and WebSocket. If the site uses a display key, it's carried in the URL fragment; rotate it from the admin. _Screenshot pending: waiting-room-display_ ## Patient guest Wi-Fi [#patient-guest-wi-fi] Patients use their own data or the hospital's guest Wi-Fi. Make sure the guest network allows the web app host and the WebSocket over 443, and doesn't block push services. Put the network name and password in [Hospital information](/admin/settings/hospital-information) so patients can copy them. ## Related [#related] * [Devices](/security/devices) * [Engine configuration](/developers/engine-configuration) # PHIPA roles and privacy (https://docs.edflow.space/security/phipa) 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. ## Roles [#roles] | Party | PHIPA role | Notes | | ------------------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | The hospital | Health information custodian | Accountable for the handling of personal health information | | The vendor of EDFlow | **Agent and electronic service provider** (PHIPA s. 17, O. Reg. 329/04 s. 6(1)) | Uses PHI only as the hospital directs, under a written agent/ESP agreement with a privacy and security schedule | | Health information network provider (s. 6(2)–(3)) | Not applicable by design: each hospital is an isolated tenant | The HINP duties are met **voluntarily**: a written TRA and privacy assessment summary for each custodian, an electronic log of all access available on request, breach notice at the first reasonable opportunity, and flow-down terms for sub-processors | | The patient's family | Recipients of a disclosure made with the patient's **express consent** | The consent record keeps who, when, what scope and how it was sent. Withdrawn by stopping sharing | ## Minimum necessary (s. 30) [#minimum-necessary-s-30] * The EHR sends only what the service needs; prohibited fields are rejected. * Each audience sees an allow-listed projection. Family never see tests, results, requests or location. Patients never see CTAS or anything from the chart. * Staff reads of a patient are recorded before the read. * Analytics use de-identified facts after the operational window. ## Consent [#consent] * **Service**: patients choose to activate by scanning their card. * **Family sharing**: express consent on a dedicated screen, with a "They'll see / They won't see" list; revocable any time. * **Texts**: phone numbers confirmed with a 6-digit code and deleted when access ends. * **Research**: a separate, optional consent where a site runs a study. ## Individual access (ss. 52–54) [#individual-access-ss-5254] The privacy office can export a visit record (timeline, care-team names, tests and steps, requests, tasks, the going-home summary, family-link activity, the access log and safety records), with a second privacy officer's approval. The EHR remains the official record. ## Access logging (s. 10.1) [#access-logging-s-101] Every view, handling or change of a patient's information by staff, and every patient and family access, is logged now, ahead of the section coming into force: what, when, who and whose record. See [Audit logging](/security/audit-logging). ## Breach management [#breach-management] * The vendor notifies the custodian's privacy office **within 24 hours** of discovering a suspected breach involving the custodian's data, by phone and email; a preliminary written report within 72 hours; a final report with root cause and corrective actions within 30 days. * The admin includes a privacy incident register with scoping, automatic legal holds, a notification timeline and annual IPC statistics, and a site-wide emergency revoke. ## Retention and destruction (s. 13) [#retention-and-destruction-s-13] Identifiable operational data is de-identified 30 days after departure by default (site range 7 to 90). Safety records follow the hospital's records schedule. On termination, the hospital receives an export within 30 days and data is destroyed within 60 days after confirmation, with a certificate. See [Access requests and retention](/admin/privacy/access-requests-and-retention). ## Safeguards (s. 12(1)) [#safeguards-s-121] Administrative (agreements, training, access reviews), technical (see [Controls](/security/controls)) and physical (AWS data centres in Canada). ## PIA and TRA support [#pia-and-tra-support] The security package includes data-flow diagrams per ingestion path, the data inventory, the legal-authority analysis for the privacy office to confirm, the agent agreement terms, patient notice text in English and French, the handling of minors and substitute decision-makers, the sub-processor table, breach management, and a TRA checklist (STRIDE per flow, identity, cryptography, application security, logging, resilience, supply chain). ## Other obligations [#other-obligations] * **Health Canada SaMD**: administrative support, clinical communication and patient access to their own information are outside the device definition. EDFlow doesn't interpret results, triage patients or give clinical advice. * **Accessibility (AODA)**: WCAG 2.2 AA. See [Accessibility](/security/accessibility). * **French**: the product ships in English and French. ## Related [#related] * [Data flow](/security/data-flow) * [Privacy officers](/admin/privacy) * [Designing family updates under PHIPA](https://edflow.space/learn/designing-family-updates-under-phipa) # Privileged access (https://docs.edflow.space/security/privileged-access) How EDFlow vendor staff can and cannot reach production: no standing access, audited time-boxed support access, break-glass with approval and session recording, two-person deployments, personnel security, and data return and destruction. | Topic | Control | | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Standing access** | **None.** No vendor staff member has standing access to customer-test or live data, the backend admin key, the dashboard, data exports, the database, S3 archives or key decryption. The admin key and database credentials live in AWS Secrets Manager in the customer's environment account, readable only by the deployment pipeline and the break-glass role | | **Support access to site data** | Through the product's audited support access: time-boxed (at most 4 hours), read-only or admin, tied to a ticket, site managers notified in-app and by email, every action audited with the support-access id. See [Vendor support access](/admin/privacy/vendor-support-access) | | **Infrastructure break glass** | Just-in-time elevation with phishing-resistant MFA, a ticket, a second person's approval, a 1-hour maximum, session recording to logs in `ca-central-1`, and an automatic notice to the custodian's privacy office. Every elevation is reviewed within 2 business days and listed in the monthly service report | | **Production environment variables** | Readable only through break glass. They contain no organization key material | | **Keys** | Per-organization KMS keys; nobody holds standing decrypt rights; a hospital may supply its own KMS key and revoke it to disable its integration secrets | | **Deployments** | Only from a controlled pipeline in the Canadian AWS account: built once in CI, signed with provenance, deployed after **two-person approval** (the author can't approve). Backend deploy credentials are never stored in the web host or source control | | **Change calendar** | The maintenance window and notice in [Availability and incidents](/security/availability-and-incidents), and each hospital's change-advisory process. Emergency changes notified before deployment when possible, otherwise within 1 hour | | **Personnel security** | Background checks for staff eligible for break glass; annual privacy and security training on PHIPA agent duties; signed confidentiality agreements; access removed within 24 hours of a role change or departure; quarterly access review | | **Platform administrators** | Can list integration apps across organizations but can't reveal secrets, call the API as an app, approve apps, record PIA attestations or accept vendor affiliations for a hospital, or decrypt organization keys | | **Remote access to the hospital** | None needed. Engines connect outbound; webhook receivers are reached through your DMZ or gateway | | **Data return and destruction** | On termination, an export of the site's data (JSON and CSV, documented schema) within 30 days; destruction within 60 days after confirmation, including backups as they age out (at most 35 days), with a certificate of destruction | ## Related [#related] * [Audit logging](/security/audit-logging) * [Controls](/security/controls) # Subprocessors (https://docs.edflow.space/security/subprocessors) Every EDFlow sub-processor with its purpose, whether health information can reach it, the data categories, its location and when it applies, from the single list shared with the privacy page and the security review pack. This table is generated from the single sub-processor list used by the privacy page, the PIA inputs and the security review pack, so they always agree. ## Notes [#notes] * **Only the database host receives health information by design.** Push, SMS and email carry generic text and opaque links; SMS providers necessarily receive the phone number of a patient or family member who opts in. * **AI providers** receive patient-derived data only for sites whose privacy office has approved AI phase 2, under zero data retention and with no training on the data. Web voice transcription stays off for hospital tenants until its conditions are met. * **Optional and env-gated**: push, SMS, email, SSO and AI can each be turned off per site. Without them, the service falls back to in-app delivery. * **Showcase-only** processors never see hospital data. ## Change notice [#change-notice] New sub-processors, or a change in what one receives, are announced to each custodian in advance, with the updated PIA inputs. Flow-down terms (confidentiality, breach notice, residency where applicable) apply to every sub-processor that can receive personal information. ## Related [#related] * [Data residency](/security/data-residency) * [AI governance](/security/ai) # Threat model (https://docs.edflow.space/security/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. This is a summary. The full threat model is part of the confidential security package. ## Objectives [#objectives] 1. People see only what their role and relationship allow. 2. No health information leaves the custodian's boundary: never in push, SMS, email, URLs, logs, analytics or sub-processors. 3. Every access to a patient's information is attributable and reviewable. 4. A stolen database copy opens no visit, link or account. 5. Guessing a credential is infeasible within a visit's lifetime. 6. A compromise is contained in minutes and scoped for notification in hours. 7. The EHR feed can't be forged, replayed or used to exfiltrate data. 8. The service stays available for staff under attack and fails safe for patients. ## Attackers considered [#attackers-considered] | Attacker | Goal | | -------------------------------------------------------------- | ------------------------------------------------------------------ | | Opportunistic internet attacker | Enumerate tokens and codes, credential stuffing, denial of service | | Someone who knows the patient (for example an abusive partner) | Follow the visit, learn location or care details | | Finder of a lost card | Open the visit | | Another person in the waiting room | Read a screen, phish with a fake QR poster | | Curious or malicious staff member | Snoop on a neighbour, celebrity or colleague | | Compromised staff account | Everything above plus admin actions | | Compromised integration engine | Forge or replay events, push PHI into prohibited fields | | Compromised third party | Read message content, inject code | | Malicious or careless operator | Bulk read, tamper with audit, disable controls | ## STRIDE summary [#stride-summary] | Threat | Main mitigations | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | **Spoofing** a patient or staff member | High-entropy tokens, knowledge factor on second devices, reverse pairing, MFA, SSO, device lock on staff phones | | **Tampering** with events or audit | HMAC or OAuth ingest with a replay window, idempotency, append-only audit with a daily hash chain | | **Repudiation** | Every staff action attributed and audited, with the membership and tab | | **Information disclosure** | Projections per audience, generic notifications, tokens in URL fragments, log redaction, prohibited fields, site isolation | | **Denial of service** | Per-target rate limits, WAF, size limits, queued engines that absorb outages, offline-safe patient screens | | **Elevation of privilege** | Server-side authorization, separation of duties, two-person approvals for privileged roles and exports, step-up for sensitive actions | ## Top risks and mitigations [#top-risks-and-mitigations] | Risk | Mitigation | | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- | | Wrong patient linked to a phone | Tokens with 128 bits of entropy, knowledge factor, rate limits, "Is this you?", staff revoke and reissue, "This wasn't me" | | PHI leaking through adapters or logs | Raw payloads never stored; log allow-list; prohibited-field tripwire; CI payload tests | | Insider browsing | Audit before read, monitoring rules (for example more than 30 patients in an hour, confidential access off the care team), quarterly access review | | "Ghost" patients after a lost discharge message | Roster reconciliation and stale-visit closing, with a circuit breaker for bad rosters | | Code-delay notices cause alarm | Only medical codes, approved generic copy, no location or count, subject and area excluded | | Patients read "results are back" as "about to be seen" | Tested copy, usual reassessment range, never a promise | | Residency requirements | Self-hosted in Canada; US providers optional, env-gated and carrying no PHI | ## Residual risks [#residual-risks] * A patient who shares their screen or phone shares their visit; the app offers a generic lock screen, biometric lock and "Sign out and forget this device". * Text messages reveal that a phone number is associated with an ED visit to the SMS provider; texts are off unless the patient opts in. * A hospital-network host holding a source key can send false events within its allowed types and sites until the key is revoked; IP allowlists and monitoring limit this. ## Related [#related] * [Controls](/security/controls) * [Clinical safety](/start/safety) # Vulnerability disclosure (https://docs.edflow.space/security/vulnerability-disclosure) How to report a security vulnerability in EDFlow: scope, safe-harbour rules, what to include, what never to do with patient data, response times, and security.txt. We welcome reports from security researchers and hospital teams. The contact address and encryption key are published in `/.well-known/security.txt` on the product site (https\://edflow\.space/.well-known/security.txt). ## Scope [#scope] * The web app, patient and family web, staff console and admin. * The iOS and Android apps. * The Integration API and the sandbox. * This documentation site. **Test only against the sandbox and the showcase**, which hold synthetic data. Never test against a hospital's customer-test or live environment. ## Rules [#rules] * Don't access, change or keep data that isn't yours. If you reach real patient data by accident, stop, don't copy it, and tell us right away. * Don't run denial-of-service tests, spam, social engineering or physical attacks. * Don't use automated scanners that send large volumes of requests. * Give us reasonable time to fix before you disclose publicly. If you follow these rules in good faith, we won't pursue legal action and will work with you on disclosure. ## What to include [#what-to-include] * The affected URL, endpoint or app version. * Steps to reproduce, with synthetic data only. * The impact you believe it has. * Any `Request-Id` from responses. ## Our commitments [#our-commitments] | Step | Target | | ---------------------------- | --------------- | | Acknowledge your report | 2 business days | | Initial assessment | 5 business days | | Fix critical vulnerabilities | 72 hours | | Tell you when it's fixed | On release | If a report reveals a possible breach of a hospital's data, we follow the breach process in [Availability and incidents](/security/availability-and-incidents) and notify the custodian within 24 hours. ## Related [#related] * [Controls](/security/controls) # AI assistance (https://docs.edflow.space/staff/ai-assistance) The EDFlow staff AI features: the request queue digest, the handover attention summary and patient message drafts. What each one reads, what you must review, and how they are turned off. Some sites turn on AI features for staff. They save typing and reading. They never change a request's priority, never take an action for you, and never send anything to a patient without your approval. Every AI output carries an "AI" label. ## Request queue digest [#request-queue-digest] A short summary at the top of the queue: how many requests are open by type and area, which are oldest, and which patients have more than one open. It reads only request types, ages, areas and counts from the queue you can already see. ![Copilot panel with the AI request digest: open requests grouped by theme, each linked to its source, labelled as AI and for review.](https://docs.edflow.space/screenshots/web/staff-ai-digest.png) **What you must do:** use the queue itself to act. The digest can be wrong or out of date by a few seconds. ## Handover attention summary [#handover-attention-summary] When a handover list is available, a short list of things to look at for each patient: open requests, pending tests, tasks waiting for confirmation, time past the usual wait. It reads the same fields as the handover list. **What you must do:** check the list against the board. It never contains clinical judgement. ## Patient message drafts [#patient-message-drafts] When you write a call-back or a message to a patient, the drafting help rewrites your text in plain language and in the patient's language. You see the draft and an independent back-translation into your language. _Screenshot pending: staff-ai-message-draft_ **What you must do:** read the draft and the back-translation, edit it, and send it yourself. The patient sees "Written with AI help and reviewed by your care team." Machine-translated messages carry a translation badge. ## What these features never do [#what-these-features-never-do] * Change a request's priority or routing. * Decide who should be seen next. * Suggest clinical actions or interpret results. * Send anything without a staff member's tap. ## Turning them off [#turning-them-off] AI features are off until a site's governance gates are met. Managers turn each feature on or off per site, and a platform-wide kill switch removes every AI entry point within seconds. When a feature is off or unavailable, the normal screen works as usual. See [AI](/admin/ai). ## Related [#related] * [AI governance](/security/ai) * [Requests](/staff/requests) # Board (https://docs.edflow.space/staff/board) The EDFlow live board: stats row, columns, alerts, filters, saved views, bottleneck flags, keyboard shortcuts, the command palette and big-board mode. The board is the department at a glance: every active visit, where it is, what it is waiting on, and who needs something. It updates live; you never refresh it. ![Live board: patients by zone with stage, time in department, assigned clinician, tests, open requests and bottleneck flags, with filters and saved views.](https://docs.edflow.space/screenshots/web/staff-board.png) ## Stats row [#stats-row] Each tile opens a filtered board or its page. | Tile | Shows | | -------------------- | ----------------------------------------------------------- | | Waiting to be seen | Count, longest wait, reassessments overdue | | Incoming EMS | Ambulances not yet offloaded, longest offload time | | In treatment | Seen, tests under way, observation, awaiting consult | | Results back | Count, and how many are past the usual time to reassessment | | Boarding | Count, longest boarding time, boarder-hours today | | Requests | Open by urgent / high / other, oldest age | | Door-to-doctor today | p50 and p90 since 00:00 | | LWBS today | Count and rate since 00:00 | | Codes | Active codes | | Department | Volume level and any pending suggestion | | Feed | EHR live, delayed, down, or manual mode | ## Columns [#columns] | Column | Content | | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Alerts | Urgent request, thinking of leaving, results back, over the usual wait, reassessment overdue, stepped out, call-back sent or not present, updates paused, care flags, possible wrong-patient sign-in, new device, confidential, provisional identity | | Patient | Display name, or **Confidential** with **Show**; age, sex; language badge | | Reassess | Waiting patients: "Due in 6 min" or "Overdue 4 min" with one-tap **Reassessed** | | Location | Zone and bed | | CTAS | 1 to 5 (staff only) | | Stage | Stage chip with provenance (EHR, manual, simulator) | | Time in stage | Toned typical, longer than p75, beyond p90 | | LOS | Since arrival | | Expected total | The projected total time from arrival (p50 to p75) with the Ontario target status: a staff planning aid from site defaults, never shown to patients | | Tests | "Labs 2/4 · Imaging 0/1 · ECG 1/1", **All back** chip | | Bottleneck | The flagged segment, if any | | Care team | Physician and nurse; zone-derived nurses in italics | | Requests | Open count, highest priority, oldest age | | Tasks | Open count; "1 to confirm" when a patient marked one done | | EDFlow | Not activated, Active · devices, Family · links | | Arrived | Arrival time | Registration clerks see only Patient, Location, Stage, LOS, EDFlow and Arrived. ## Filters and views [#filters-and-views] * **Search** by name or bed. * **Filters**: zone, stream, stage, CTAS, Ontario CTAS group, My patients, Has open requests, Bottleneck, Results back, Over the usual wait, Reassessment due, Not activated, Updates paused. * **Saved views** keep columns, filters and sort. Charge nurses can share views. **Longest stay** is built in. * **Recently departed (2 h)** shows visits that just left. * Default sort: zone and bed for treatment areas, time waiting for the waiting room. Your site chooses its default view. ## Bottleneck flags [#bottleneck-flags] Each visit's time is split into segments (for example triage to seen, results to reassessment). A segment beyond p90 for this site, weekday and hour is flagged, and the board names it. See [Flow and bottlenecks](/admin/analytics/flow-and-bottlenecks). ## Acting from the board [#acting-from-the-board] Click a row or press `Enter` to open the patient drawer. The row's action menu has the common console actions in one tap: triage, seen, tests under way, results back, reassessed, disposition, call back. See [Manual console](/staff/manual-console). ## Keyboard shortcuts [#keyboard-shortcuts] | Key | Action | | --------------------- | ----------------------- | | `J` / `K` | Next / previous row | | `Enter` | Open the patient drawer | | `/` | Search | | `?` | Show all shortcuts | | `Cmd` or `Ctrl` + `K` | Command palette | ## Command palette [#command-palette] Search patients by name or bed, jump to pages, and run actions such as Call a code, Set department status, Register a patient or Open requests. It shows only what you are allowed to open, with confidential names masked. ![Command palette over the board: search patients by room or name, jump to a screen, or run an action from the keyboard.](https://docs.edflow.space/screenshots/web/staff-command-palette.png) ## Big-board mode [#big-board-mode] A full-screen board for the staff station, never for public areas: larger type, initials only by default, auto-paging every 15 s, a clock, no actions. It can run in your session or on a registered big-board station. See [Big board and handover](/staff/charge/big-board-and-handover). ![Big-board mode for a wall display: large rows by zone with stage, time in department and open requests, and no patient names by default.](https://docs.edflow.space/screenshots/web/staff-big-board.png) ## Audit [#audit] Opening the board is recorded once per session every 15 minutes. Opening a patient is recorded every time. See [Privacy at work](/staff/privacy-at-work). # Codes and department status (https://docs.edflow.space/staff/codes-and-department-status) See active codes and the department volume level in EDFlow, who can call, clear or post a delay notice for a code, and exactly what patients, family and the waiting-room display see. EDFlow records codes and the department's volume level so patients hear, in calm and generic words, that their wait may be longer. It never replaces overhead paging or hospital emergency management. ## Active codes [#active-codes] Every staff page shows an active-code strip: type with its staff colour, area, elapsed time, **Post delay notice** and **Clear** for those allowed. **Codes** in the header shows the details and the last 24 hours. ![Code alerts: active codes with type, location, time called and who called, with Extend, Clear and Cancel.](https://docs.edflow.space/screenshots/web/staff-codes.png) ## Who can do what [#who-can-do-what] | Permission | R-TRIAGE | R-NURSE | R-PHYSICIAN | R-CHARGE | R-CLERK | R-SUPPORT | R-MANAGER | R-PRIVACY | R-INTEGRATION | R-INTEGRATION-DEVELOPER | R-SUPER | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | code.call | Not granted | Not granted | Granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | code.clear | Not granted | Not granted | Granted | Granted | Not granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | | code.notice | Granted | Granted | Granted | Granted | Granted | Not granted | Granted | Not granted | Not granted | Not granted | Not granted | * **Call a code**: two steps, see [Calling a code](/staff/physicians/calling-a-code). * **Post delay notice**: one tap from the code strip, on the resuscitation team's behalf. Clerks can do this too. * **Extend** (+15 or +30 min), **Clear** or **Cancel (called in error)**. ## What patients see [#what-patients-see] Only medical codes can notify patients, and only visits in the waiting and results-back stages that are outside the affected area. The person the code is about, and anyone in the same zone or bay or in resuscitation, never gets it. _Screenshot pending: patient-code-delay_ | Audience | Text | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Patient | Your wait may be longer. Someone in the emergency department needs urgent care right now, so part of our team is with them. This may add time to your wait. We haven't forgotten you, and we'll be with you as soon as we can. | | Patient push | Your wait may be longer. Tap for an update. | | Family | The care team is helping someone who is very unwell. Waits may be longer for a while. | | Waiting-room display | Our team is caring for people who are very unwell. Waits may be longer. Thank you for your patience. | No code name, colour, area, count or duration ever reaches a patient, family member or the display. No text or email is sent for codes. A second notifying code within 30 minutes updates the same notice. ## Department volume [#department-volume] ![Department volume: normal, busy, very busy or surge, with a suggested level and what patients and the display will see.](https://docs.edflow.space/screenshots/web/staff-volume.png) The level is **Normal**, **Busy**, **Very busy** or **Surge**. Charge nurses set it (`volume.set`); EDFlow suggests a level every 5 minutes from the live census, but a suggestion never changes anything until someone accepts it. See [Department volume](/staff/charge/department-volume). | Level | Patients and family | Display | | ---------------- | ------------------------------------------------------------------ | --------------------------------------------------------------------- | | Normal | Nothing | Thank you for waiting. We see the sickest people first. | | Busy | It's busier than usual today. Waits may be longer. | The department is busy right now. Waits may be longer. | | Very busy, Surge | It's very busy right now. We see the sickest people first, so some waits will be long. We're sorry for the wait. | The department is very busy right now. Some waits will be long. | Volume changes never send push or text messages. ## Related [#related] * [Codes](/staff/charge/codes) for charge nurses * [Delays](/patients/delays), the patient's page * [Communicating code-alert delays without alarming patients](https://edflow.space/learn/communicating-code-delays) # Companion app (https://docs.edflow.space/staff/companion-app) The EDFlow staff companion app on hospital-managed phones: request inbox, my patients, patient card, department, on-shift status, scanning a visit card, and push notifications while on shift. The companion app puts your request inbox and your patients in your pocket. It runs only on hospital-managed phones, in staff mode of the same app patients use. It calls the same functions as the console, with the same permissions and audit. ## Tabs [#tabs] #### iPhone _Screenshot pending: mobile-staff-inbox_#### Android _Screenshot pending: mobile-staff-inbox_ ### Inbox [#inbox] Requests routed to you, your zone, or the triage pool when you're in it, grouped by priority. Filter **Mine**, **My zone** or **All**. * Non-urgent rows: **Acknowledge** and **Resolve** buttons, plus swipe right to acknowledge and left to resolve. * Urgent rows (pinned): **Going now**, **Can't go**, **Handled in person**. ### My patients [#my-patients] Patients where you are on the care team or in your zone: display name (masked if confidential), bed, stage, time in stage, pending tests, open requests and tasks. Search by name or bed. _Screenshot pending: mobile-staff-patients_ ### Patient card [#patient-card] Opening a patient is audited. You see the stage and timeline, tests, tasks, requests, care team and care flags, and quick actions by permission: **Assign me**, **Seen**, **Seen again**, **Add a task**, **Start observation**, **Call back**, **Pause updates**, **Hide from the patient view**, **Approve pairing code**. _Screenshot pending: mobile-staff-patient-card_ ### Department [#department] Active codes, **Call a code** (two separate sheets, so it can't be done in one tap), the volume level and the feed state. _Screenshot pending: mobile-staff-department_ ### Me [#me] Your on-shift status (from zone assignments, with a manual override) and zone, notification settings, biometric lock, switch site, sign out. Going off shift removes you from routing and push within seconds. _Screenshot pending: mobile-staff-me_ ## Scanning a visit card [#scanning-a-visit-card] Tap **Scan** and point the camera at a patient's card. In staff mode the app never signs in as the patient: it opens that patient's card for you, if you're allowed to see patients at that site, and records the access. A card from another site shows "This card is for another hospital." _Screenshot pending: mobile-staff-scan_ ## Push notifications [#push-notifications] You get push only while you're on shift. Payloads never contain patient details: * "Urgent request · Zone B", "Request escalated · Zone A", "Urgent request · Patient OUTSIDE the department" * "Results back · Zone A" (physicians who opt in) * "Code called" (off by default, since you hear the overhead page) * "EHR feed down" (integration roles) Urgent requests use the time-sensitive level on iPhone and a high-importance channel on Android. From the lock screen, the only action for an urgent request is **Can't go**, and it needs Face ID, fingerprint or your passcode. Acknowledging a non-urgent request from the lock screen also needs device authentication. ## Security [#security] * Staff mode needs a phone passcode and a hospital-managed device. * After 5 minutes in the background, the app asks for Face ID, fingerprint or the passcode. * Sessions end after 12 hours, or when your manager signs you out. ## Related [#related] * [Requests](/staff/requests) * [Devices](/security/devices) for IT # Care team basics (https://docs.edflow.space/staff) EDFlow for the ED care team: the staff console and the companion app, what each role can do, and the guides for triage nurses, nurses, physicians, charge nurses, clerks and support staff. EDFlow gives the care team one live view of the department and one queue for patient requests. It shows patients where they are in the visit so you answer fewer "how much longer?" questions. It never shows patients results, CTAS or anything you write in the chart. ![Live board: patients by zone with stage, time in department, assigned clinician, tests, open requests and bottleneck flags, with filters and saved views.](https://docs.edflow.space/screenshots/web/staff-board.png) ## Two tools [#two-tools] | Tool | Where | What it's for | | ----------------- | ---------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | **Staff console** | Any hospital workstation browser | Live board, patient detail, request queue, codes, department volume, cards, zones, the manual console | | **Companion app** | Hospital-managed phones (MDM) only | Request inbox, my patients, patient card, department, on-shift status. See [Companion app](/staff/companion-app). | ## Where the data comes from [#where-the-data-comes-from] Most facts come from the EHR feed through the hospital's integration engine: arrival, triage, assignments, orders and their status, disposition, departure. When there is no feed, or the feed is wrong, staff set the same facts from the console. Patients see both the same way; staff see the provenance (EHR, manual, override). See [Manual console](/staff/manual-console). ## What each role can do [#what-each-role-can-do] Generated from the permission catalogue: | Permission | R-TRIAGE | R-NURSE | R-PHYSICIAN | R-CHARGE | R-CLERK | R-SUPPORT | | --- | --- | --- | --- | --- | --- | --- | | board.view | Granted | Granted | Granted | Granted | Conditional | Not granted | | patient.view | Granted | Granted | Granted | Granted | Conditional | Not granted | | patient.unmask | Granted | Granted | Granted | Granted | Granted | Not granted | | patient.register | Granted | Not granted | Not granted | Granted | Granted | Not granted | | patient.state | Granted | Granted | Granted | Granted | Not granted | Not granted | | patient.override | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | | patient.lifecycle | Not granted | Not granted | Not granted | Granted | Conditional | Not granted | | careteam.assign | Granted | Granted | Granted | Granted | Not granted | Not granted | | zones.assign | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | | results.release | Not granted | Not granted | Granted | Granted | Not granted | Not granted | | tasks.manage | Granted | Granted | Granted | Granted | Not granted | Not granted | | avs.compose | Not granted | Granted | Granted | Granted | Not granted | Not granted | | avs.medications | Not granted | Not granted | Conditional | Not granted | Not granted | Not granted | | access.card | Granted | Granted | Granted | Granted | Granted | Not granted | | access.revoke | Not granted | Not granted | Not granted | Granted | Granted | Not granted | | share.manage | Granted | Granted | Granted | Granted | Not granted | Not granted | | privacy.flag | Granted | Not granted | Not granted | Granted | Granted | Not granted | | patient.restrict | Granted | Granted | Granted | Granted | Not granted | Not granted | | updates.pause | Not granted | Not granted | Granted | Granted | Not granted | Not granted | | patient.callback | Granted | Granted | Granted | Granted | Granted | Not granted | | request.view | Granted | Granted | Granted | Granted | Not granted | Not granted | | request.act | Granted | Granted | Granted | Granted | Not granted | Not granted | | request.bulk | Granted | Granted | Not granted | Granted | Not granted | Not granted | | code.call | Not granted | Not granted | Granted | Granted | Not granted | Not granted | | code.clear | Not granted | Not granted | Granted | Granted | Not granted | Not granted | | code.notice | Granted | Granted | Granted | Granted | Granted | Not granted | | support.queue | Not granted | Not granted | Not granted | Granted | Not granted | Granted | | volume.set | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | | analytics.view | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | | analytics.self | Not granted | Conditional | Conditional | Conditional | Not granted | Not granted | | analytics.clinician_blinded | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | analytics.clinician_named | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | analytics.export | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | users.view | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | | users.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | users.import | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | settings.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | config.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | stations.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | approvals.decide | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | training.manage | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | | content.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | content.approve | Not granted | Not granted | Conditional | Conditional | Not granted | Not granted | | announcements.manage | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | | integration.view | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | | integration.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | audit.view | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | audit.export | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | privacy.legal_hold | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | privacy.incident | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | privacy.emergency_revoke | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | outbox.view | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | access_review.run | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | simulator.use | Not granted | Not granted | Not granted | Conditional | Not granted | Not granted | | seed.reset | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | platform.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | developers.view | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | developers.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | developers.credentials | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | developers.approve | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | developers.attest_pia | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | developers.accept_affiliation | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | ai.safety_review | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | ## Guides by role [#guides-by-role] ## Everyone should read [#everyone-should-read] * [Sign-in and security](/staff/sign-in-and-security) * [Privacy at work](/staff/privacy-at-work) * [What patients see](/staff/what-patients-see) * [Requests](/staff/requests), including the urgent "I feel worse" path * [Troubleshooting](/staff/troubleshooting) ## Help inside the console [#help-inside-the-console] **Help** in the header opens short task guides for each role, printable tip sheets, the first-run tour, **Report a safety concern** and **Report a problem**. Release notes appear under **What's new** on your profile. ## Frequently asked questions [#frequently-asked-questions] No. Patients see stages, test steps, names and roles, tasks from approved templates and the going-home summary you compose from approved templates. Nothing from the chart's free text reaches them. See [What patients see](/staff/what-patients-see). Go to the patient, then answer the urgent request with **Going now** or **Handled in person**. The patient's screen has already told them to alert staff in person. Unanswered urgent requests keep escalating to the charge nurse. See [Requests](/staff/requests). Staff screens show a masked code only, and cards print only at registered print stations. A usable patient credential never appears on a staff screen. See [Visit cards and sign-in help](/staff/visit-cards-and-sign-in-help). Patients see that updates may be delayed and estimates freeze. The charge nurse can keep visits current from the console until the feed recovers. See [When the feed is down](/staff/charge/feed-down). Yes. Opening a patient's detail, unmasking a confidential name and every action on a visit are recorded in the audit log that the privacy office reviews. See [Privacy at work](/staff/privacy-at-work). No. Only a hospital-managed phone can run the companion app's staff mode. See [Companion app](/staff/companion-app). More answers: [Troubleshooting for staff](/staff/troubleshooting) and the general [questions and answers](/start/faq). Background reading on the product site: [What patients want to know during an ED visit](https://edflow.space/learn/what-patients-want-to-know). # Manual console (https://docs.edflow.space/staff/manual-console) Run EDFlow visit states by hand when there is no EHR feed or the feed is wrong: every manual action, the 10-second undo, overrides, back-dating and validation warnings. The manual console is a first-class way to run EDFlow, not a fallback demo. Sites without an EHR feed run entirely from it; sites with a feed use it during downtime and to correct the feed. Every manual action produces the same kind of event as the EHR, so patients, analytics and audit treat it exactly the same. Staff always see which facts are manual. _Screenshot pending: staff-manual-actions_ ## Where to find the actions [#where-to-find-the-actions] * **Board row menu**, one tap: triage, seen, tests under way, results back, reassessed, disposition, call back. * **Patient detail**, quick actions in the header and **Update status** for everything else. * **Companion app** patient card: assign me, seen, seen again, add a task, start observation, call back, pause updates, hide from the patient view, approve pairing. ## The actions [#the-actions] | Action | Permission | | ------------------------------------------------------------------------------------------------- | ------------------- | | Triage (CTAS and time); move to a bed or area; stepped out, back | `patient.state` | | Assign or release a care-team member; Assign me | `careteam.assign` | | Seen; Seen again (reassessment); Reassessed (waiting room) | `patient.state` | | Add a test; set status; cancel or recollect; all results back; results reviewed | `patient.state` | | Tests under way, results back (sites without per-test detail) | `patient.state` | | Hold results status, release results now | `results.release` | | Start or end observation; request, start or finish a consult | `patient.state` | | Decide home, admit, observe or transfer; cleared to leave; bed requested, assigned, ready | `patient.state` | | Left the department; left without being seen; left before treatment complete; against advice | `patient.state` | | Reopen a visit; cancel a visit; correct a time | `patient.lifecycle` | | Confirm identity; set or clear confidential | `privacy.flag` | | Hide an order or consult; restricted view; not appropriate for EDFlow; care flags; card recipient | `patient.restrict` | | Pause or resume updates; family has been informed | `updates.pause` | | Call back | `patient.callback` | | Add, clear, confirm a task; nurse will collect | `tasks.manage` | Every form defaults to now and can be back-dated up to 24 hours. ## Undo [#undo] Each action shows a 10-second **Undo** toast. Undo restores the previous value and cancels any patient notification the action would have sent. After 10 seconds, use **Correct a time** or a new action. _Screenshot pending: staff-undo-toast_ ## Overrides [#overrides] With `patient.override` (charge nurses), you can mark a manual action as an **override**. It wins over the EHR for that fact until someone clears it. The board and the patient page show an **Override** marker, and every override and clear is audited. See [Overrides and corrections](/staff/charge/overrides-and-corrections). ## Validation [#validation] The console blocks impossible actions (for example acting on a cancelled visit) and asks you to confirm unusual ones: seen before triage, departure with pending tests, disposition without seen. ## Registering during EHR downtime [#registering-during-ehr-downtime] When the feed is active, the registration page warns you to register only during downtime. The visit is marked for linking; when the EHR arrival comes in, **Link to EHR visit** merges them, keeping the patient's sign-in, family links, requests and summary. See [Register a patient](/staff/clerks/register-a-patient). ## Related [#related] * [When the feed is down](/staff/charge/feed-down) * [Patient detail](/staff/patient-detail) # Patient detail (https://docs.edflow.space/staff/patient-detail) The EDFlow patient detail page: the header, the tabs (overview, tests, tasks, care team, requests, going home, sharing and access, activity), provenance of each fact, audited opening, and confidential and provisional patients. Open a patient from the board (click or `Enter`) for the drawer, or **Open full page** for every tab. Opening a patient is recorded in the audit log with who, when and which tab. ![Patient detail: stage, care team, tests, requests and tasks, with the source of each fact (EHR, manual or override).](https://docs.edflow.space/screenshots/web/staff-patient-detail.png) ## Header [#header] Display name (masked if confidential), age and sex, language, location, stream, CTAS, arrival and LOS, the expected total length of stay with its target status, imaging orders with their ordered times, stage with provenance, care flags, **Updates paused** chip, card recipient (patient, guardian, substitute decision-maker, youth-confidential), and the patient-app state ("Active · 2 devices · last seen 3 min ago" or "Not activated"). Quick actions, depending on your permissions: **Assign me**, **Seen**, **Seen again**, **Add test**, **Results back**, **Hold results**, **Start observation**, **Disposition**, **Cleared to leave**, **Call back**, **Pause updates**, **Send card to printer**, **Approve pairing code**. **Update status** holds the rest. ## Tabs [#tabs] | Tab | What you see | What you can do | | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Overview | Timeline with provenance (EHR, manual, simulator, actor, time, corrections); segment table with the p50 and p90 for each segment; the expected remaining path (staff projection from site defaults); **What the patient sees**; staff alerts | Correct a milestone time; clear an alert | | Tests | Every order with status, timestamps, scheduled time, counts toward all back, sensitive, hidden, and when the patient sees it | Add from the catalogue, set status, cancel or recollect, results back, hold and release results, results reviewed, hide from the patient view | | Tasks | Open, awaiting confirmation, completed | Add from a template, clear, confirm a patient-completed task | | Care team | Members, source (EHR, manual, zone), since, whether they count for "seen" and NACRS PIA | Assign, release, set primary nurse; request, start and finish consults; hide a consult from the patient view | | Requests | Every request with its times, actors, escalations and reminders; call-backs and their status; a family call-back's last two digits with **Show number** (audited) | Acknowledge, Going now / Can't go, resolve, reassign, call back | | Going home | AVS composer with a live English and French preview, version history | Save, publish, unpublish, **Cleared to leave** | | Sharing & access | Family links, sharing lock, confidential flag, restricted view, card recipient, identity status, masked visit card, pairing, patient devices, updates pause, care flags | Revoke links, lock sharing, set flags, reissue the card, sign out a device, pause or resume updates | | Activity | Access log for this visit, legal holds (privacy officers and managers only) | Export with a second person's approval, legal hold | _Screenshot pending: staff-patient-detail-tests_ ## Provenance [#provenance] Every fact shows where it came from: the EHR feed, a manual console action (with the staff member), the simulator (sandbox only), or an **Override**. Patients see all of these the same way. ## "What the patient sees" [#what-the-patient-sees] The Overview tab shows the patient's stage label, estimate text and the level the estimate came from, produced by the same function as the patient's screen. Use it to answer questions at the bedside. See [What patients see](/staff/what-patients-see). ## Confidential patients [#confidential-patients] Confidential names show as **Confidential** on the board, in the palette and on this page. **Show** asks for a reason (Providing care, Registration, Other) and is recorded as an unmask. Sharing is unavailable for confidential visits. ![A confidential patient on the board and in the detail header: the name is masked and a confidential badge is shown.](https://docs.edflow.space/screenshots/web/staff-confidential-masked.png) ## Provisional identities [#provisional-identities] An unknown or unconfirmed patient (for example an unidentified trauma arrival) has a provisional identity. They can't sign in to EDFlow, and no card can be printed until identity is confirmed. See [Confidential and unknown patients](/staff/clerks/confidential-and-unknown-patients). _Screenshot pending: staff-provisional-identity_ ## Before you act [#before-you-act] Every action on a visit, beyond viewing, needs the visit to be opened (and recorded) in this session. If you see "Open this visit first", open it from the board. # Privacy at work (https://docs.edflow.space/staff/privacy-at-work) PHIPA duties in plain words for EDFlow users: what is audited, confidential patients, never photographing the board, your recent actions, and how to talk to patients about the app. You already follow your hospital's privacy policy. EDFlow doesn't change it. This page explains how the policy applies in EDFlow. ## Your duties in plain words [#your-duties-in-plain-words] * **Look only at patients you are caring for**, or whose visit you need to act on for your job. * **Share only what's needed.** Don't read out a patient's name, stage or tests where others can hear. * **Keep screens private.** Lock the console (or let it lock) when you step away. Never take photos or screenshots of the board or a patient page. * **Don't use EDFlow to message patients about clinical matters.** Talk to them in person. * **Report a concern.** If you think someone looked at a visit without a reason, tell your privacy office. ## What is recorded [#what-is-recorded] | Action | Recorded | | --------------------------- | ------------------------------------------- | | Opening the board | Once per session every 15 minutes | | Opening a patient | Every time, with the tab | | Showing a confidential name | Every time, with your reason | | Every action on a visit | Every time, with the before and after | | Exports | Every time, with a second person's approval | The privacy office reviews these records, and automatic rules flag unusual patterns, such as opening many patients you aren't assigned to. ## Confidential patients [#confidential-patients] A confidential patient shows as **Confidential** everywhere. **Show** asks for a reason: Providing care, Registration or Other. Sharing is unavailable for confidential visits, and their family links stop. ![A confidential patient on the board and in the detail header: the name is masked and a confidential badge is shown.](https://docs.edflow.space/screenshots/web/staff-confidential-masked.png) ## Your recent actions [#your-recent-actions] **My profile → My recent actions** lists your own actions for the last 7 days, so you can check what you did. ## Talking with patients about EDFlow [#talking-with-patients-about-edflow] * "You can follow your visit on your phone. Scan this code on your card." * "It shows where you are, who's looking after you and how long things usually take here. It doesn't show results." * "If you feel worse, tell me or any staff member right away. Don't wait for the app." * "You can share a short version with family. They won't see your tests." * "Your notes stay on your phone. We can't read them." ## What EDFlow does for privacy [#what-edflow-does-for-privacy] * It never stores a patient's last name or date of birth. * Notifications, texts and links never contain health information. * Family never see tests, results or location. * Staff never see a usable patient card code. ## Related [#related] * [Privacy officers](/admin/privacy) * [PHIPA](/security/phipa) # Requests (https://docs.edflow.space/staff/requests) The EDFlow request queue: how patient requests are routed, acknowledging and resolving, service levels and escalation, the urgent I feel worse path (Going now, Can't go), the support queue and desktop notifications. Patients send structured requests from their phone: no free text, one tap. Each request is routed to the right person and escalates if nobody responds. Open the queue from **Requests** in the header. ![Request queue: requests by zone with type, age and status, and Acknowledge and Resolve buttons.](https://docs.edflow.space/screenshots/web/staff-request-queue.png) ## The queue [#the-queue] Four sections by priority, oldest first in each: **Urgent** (first, in the danger tone), **High**, **Normal**, **Low**. Two more lanes: * **Patient updates**: tasks a patient marked done (to confirm), and FYI items like stepped out, back, going to the washroom, "asked when they'll see the doctor". FYI items need no action, have no service level and never make a sound. * **Over the usual wait**: patients whose current step has passed p90. Acknowledging tells the patient "Your care team knows you're waiting." Each row: type, patient display name and location, time in queue (amber at 50% of the target, red once breached), routed to, status, escalation badge, reminders. Filters: **Mine** (me or my zone), **My zone**, **Waiting room**, **All**, plus priority and type. **Recently resolved (2 h)** is collapsed at the bottom. ## Routing [#routing] At creation, EDFlow walks the request type's route list and takes the first that has someone on shift: | Route | Goes to | | ------------------------ | --------------------------------------------------------------------------------------- | | Support pool | On-shift support staff, for comfort requests (blanket, help to the washroom, meal tray) | | Primary nurse | The visit's assigned nurse, if on shift | | Zone | Nurses assigned to the patient's zone or bed | | Triage pool (if waiting) | Triage nurses, while the patient is in the waiting room | | Charge | On-shift charge nurses | | Physician in charge | The on-shift physician lead | If nothing resolves, the request goes to the charge nurse, then the physician in charge, then every on-shift clinician. Everyone with queue access can still see every request under **All**. When a patient moves, their open unacknowledged requests re-route. On-shift status comes from [zone assignments](/staff/charge/zones-and-shifts). ## Acting on a request [#acting-on-a-request] | Priority | Actions | Keys | | ----------------- | ---------------------------------------------------------------------------------------------------------- | -------- | | Low, Normal, High | **Acknowledge**, **Resolve** (Done, Not needed, Handled in person, Duplicate), **Reassign** | `A`, `R` | | Urgent | **Going now** (starts a 5-minute timer), **Can't go, escalate** (reassigns at once), **Handled in person** | `G`, `E` | A **family call-back** (a family member left their number from the family view) sits in the queue like any normal request and shows only the last two digits of the number. **Show number** reveals it once for you to call; every reveal is audited, and the number is deleted when the request is resolved. Acknowledging shows the patient "Seen by" and your display name. You can resolve without acknowledging first. Low requests can be acknowledged in bulk. Every action is also a visible button: nothing depends on swiping or dragging. ## Service levels and escalation [#service-levels-and-escalation] | Priority | First response | Escalation 1 | Escalation 2 | | -------- | -------------- | --------------------------------------- | --------------------------------------------------------------------------- | | Urgent | 2 min | Charge nurse and triage pool, with push | 5 min without an in-person resolution: charge nurse and physician in charge | | High | 5 min | Charge nurse | 15 min: zone nurses | | Normal | 15 min | Highlighted in red | 30 min: charge nurse | | Low | 30 min | Highlighted in red | — | Your site can scale these targets between half and double. Acknowledging cancels escalation for non-urgent requests. For urgent requests, only a resolution stops it. See [Escalations](/staff/charge/escalations). ## The urgent path: "I feel worse" [#the-urgent-path-i-feel-worse] ![An urgent "I feel worse" request at the top of the queue, marked urgent and routed to the patient's nurse and the charge nurse.](https://docs.edflow.space/screenshots/web/staff-request-urgent.png) 1. The patient's phone has already told them to alert staff in person. EDFlow never tells them someone is coming. 2. The request is routed to the primary nurse or zone (the triage nurse as "Re-triage requested" in the waiting room), and the triage pool and charge nurse are also notified. 3. Answer **Going now** or **Can't go, escalate**. There is no plain acknowledge. 4. After "Going now", the patient sees that you know they asked for help. If you don't resolve it within 5 minutes, escalation resumes. 5. Resolve with **Handled in person** once you've seen them. A patient who stepped out shows first as "Patient is OUTSIDE the department (stepped out 14:05)". Their phone tells them to come back or call 911. ## Sounds and notifications [#sounds-and-notifications] * A new urgent request chimes every 30 s until someone answers, sends a desktop notification with no patient details ("Urgent request · Zone B") and prefixes the tab title. You can lower the volume but not mute urgent sounds while on shift. * High requests routed to you chime once. * Low and FYI items never make a sound. **Notifications** in the header lists your staff alerts: urgent and high requests, escalations, over-the-usual-wait, reassessments due, results back (physicians who opt in), unanswered call-backs, possible wrong-patient sign-ins, approvals, feed down (integration roles). ![Staff notifications: urgent requests, escalations and code alerts, and the desktop notification setting.](https://docs.edflow.space/screenshots/web/staff-notifications.png) ## The support queue [#the-support-queue] Support staff see only the support pool: display name, location, request type, age, and "Restriction active: check with the nurse" when the patient has an eating or drinking restriction. Actions: **Taking it**, **Done**, **Needs a nurse** (sends it to the zone nurse). No board and no patient detail. ## Duplicates, reminders and limits [#duplicates-reminders-and-limits] One open request per type per visit. A patient can send a reminder after 10 minutes; it moves the request up and re-alerts you, without creating a new row. Patients are limited to 12 non-urgent requests an hour. Urgent requests are never limited, and repeated taps within 60 s merge. ## At departure [#at-departure] Open requests close automatically with "Closed at departure" and are excluded from service-level measures. # Sign-in and security (https://docs.edflow.space/staff/sign-in-and-security) How staff sign in to EDFlow: accepting an invite, the password policy, two-step sign-in (MFA), Sign in with Microsoft, the idle lock, switching sites, sessions, and the companion app's biometric lock. Staff accounts are invite-only. There is no sign-up page. ## Accept your invite [#accept-your-invite] ### Open the invite link [#open-the-invite-link] The email from your ED manager contains a link that works once and expires after 72 hours. The page shows the site and your email with most letters hidden. ### Create your account, or add the site to your existing account [#create-your-account-or-add-the-site-to-your-existing-account] * **Create my account**: type the invited email in full, your name, how your name is shown to patients, and a password. * **I already have an account**: sign in with your current password (and code). The invite adds this site to your account. Three wrong passwords use up the invite. ### Set up two-step sign-in [#set-up-two-step-sign-in] Scan the QR code with an authenticator app, enter the 6-digit code, then save your 10 recovery codes. They are shown once. _Screenshot pending: staff-invite-accept_ _Screenshot pending: staff-mfa-setup_ Manager, privacy and integration roles need a second person's approval. Until then you see that your access is pending approval. ## Password policy [#password-policy] * At least 12 characters, and a strength score of 3 or more. * Not your email or your name, and not one of the 100,000 most common breached passwords. * Reset links work once and expire after 30 minutes. Resetting signs you out everywhere. If your hospital uses Microsoft sign-in only, the reset page says your hospital manages your password. ## Signing in [#signing-in] ![Staff sign-in: work email and password, or sign in with Microsoft where the hospital uses it.](https://docs.edflow.space/screenshots/web/staff-sign-in.png) 1. Email and password, or **Sign in with Microsoft** when your hospital has turned it on. 2. The 6-digit code from your authenticator app, or a recovery code. _Screenshot pending: staff-mfa-verify_ | Message | Meaning | | --------------------------------------------- | ------------------------------------------------------------------------------------------- | | Email or password is incorrect. | The same message for a wrong password and an unknown account. | | Too many attempts. Try again in 15 minutes. | 5 wrong passwords in 15 min lock the account for 15 min. Your manager can unlock it sooner. | | Your two-step sign-in is locked for 24 hours. | 10 wrong codes in 24 h. Ask your manager to reset it. | | Your Microsoft account can't be used here. | No membership, a guest account, the wrong tenant, or MFA missing for your role. | ## Idle lock [#idle-lock] After 15 minutes without activity (your site may set 5 to 60), the console removes patient data from the screen and shows the lock. Enter your password, or continue with Microsoft as the **same** user, to return to the same page. While locked, urgent requests routed to you still chime, without showing any patient data. ![Idle lock after 15 minutes: the screen is hidden and you unlock with your password.](https://docs.edflow.space/screenshots/web/staff-idle-lock.png) Sessions end after 12 hours (site range 8 to 16). Lock or sign out when you leave a shared workstation. ## Confirming it's you [#confirming-its-you] Some actions (exports, role grants, revealing a key, emergency revoke) ask you to confirm with your password and code if you haven't in the last 10 minutes. ## Switching sites [#switching-sites] If you work at more than one site, pick the site after sign-in or from the header. Everything you see switches to that site. _Screenshot pending: staff-select-site_ ## Your sessions [#your-sessions] **My profile → Security** lists your active sessions with **Sign out** for each, lets you change your password and regenerate recovery codes. Your manager can sign out all your sessions. ## Companion app [#companion-app] #### iPhone _Screenshot pending: mobile-staff-sign-in_#### Android _Screenshot pending: mobile-staff-sign-in_ * Only on hospital-managed phones. The app refuses staff mode on a phone with no passcode. * Sign in with email, password and code, or Microsoft. * After 5 minutes in the background, the app asks for Face ID, fingerprint or the phone's passcode. * Sessions last 12 hours and can be ended remotely. ## Related [#related] * [Privacy at work](/staff/privacy-at-work) * [Identity and SSO](/security/identity-and-sso) for IT # Troubleshooting for staff (https://docs.edflow.space/staff/troubleshooting) Fix common EDFlow problems for staff: the EHR feed is delayed or down, a patient says the app is wrong (report a data problem), sign-in and lock problems, missing sounds, and cards that don't print. ## The EHR feed is delayed or down [#the-ehr-feed-is-delayed-or-down] | Chip or banner | Meaning | What to do | | ------------------------ | ------------------------------------------------ | ---------------------------------------------------------------------------------------------- | | EHR live | Events are arriving | Nothing | | EHR feed delayed · n min | Nothing received for 5 minutes or more | Keep working. Patients see "Updates may be delayed". | | EHR feed down | Nothing for 15 minutes, or every source disabled | Charge nurse follows [When the feed is down](/staff/charge/feed-down). Use the manual console. | | Manual mode | The site has no feed | Normal for this site | _Screenshot pending: staff-feed-down_ The integration team is alerted automatically when the feed goes down. You don't need to call them unless the charge nurse asks. ## A patient says the app is wrong [#a-patient-says-the-app-is-wrong] 1. Check **What the patient sees** on the patient's Overview tab. 2. If a fact is wrong (for example the wrong stage or a test that was cancelled), fix it with a console action, or mark an override if the EHR keeps sending the wrong value. 3. Report it: **Report a data problem** on the patient page. Pick what is wrong. The integration team reviews reports to fix mappings and the feed. _Screenshot pending: staff-report-data-issue_ ## Sign-in problems [#sign-in-problems] | Problem | Fix | | --------------------------------- | --------------------------------------------------------------------------------------- | | "Too many attempts" | Wait 15 minutes, or ask your manager to unlock the account. | | Two-step sign-in locked | Ask your manager to reset it. You'll set it up again. | | Lost phone with the authenticator | Use a recovery code, then set up again. Or ask your manager to reset. | | Microsoft sign-in refused | Your account may not have a membership here, or it's a guest account. Ask your manager. | | Keeps locking | The idle lock is 15 minutes by default. Your site sets the range. | ## No sound for urgent requests [#no-sound-for-urgent-requests] * Check the browser tab isn't muted and the computer volume is up. * Allow desktop notifications for the console when your browser asks. * Make sure you are **on shift**: sounds and push go to on-shift staff for requests routed to them. ## A card didn't print [#a-card-didnt-print] * Check the print station page is open and the printer is online. * From the patient page, send the card again (within 15 minutes it reuses the same card). * After 15 minutes, sending again reissues the card and the old one stops working. ## "Open this visit first" [#open-this-visit-first] Actions on a visit need the visit opened (and recorded) in this session. Open it from the board and try again. ## Still stuck? [#still-stuck] **Help** in the header has task guides, tip sheets, **Report a safety concern** and **Report a problem**. Ask your charge nurse or your site's EDFlow champion. # Visit cards and sign-in help (https://docs.edflow.space/staff/visit-cards-and-sign-in-help) Print a EDFlow visit card at a registered print station, approve staff-assisted sign-in with the patient's pairing code, and reissue a lost card, without staff ever holding a usable patient credential. A patient's card or wristband label is their key to EDFlow. Staff never see the QR code or the visit code in clear, and never sign in on a patient's behalf. That keeps a usable patient credential off every staff screen. ## Printing a card [#printing-a-card] Cards print automatically after triage at most sites. To send one by hand: 1. Open the patient and choose **Send card to printer**. 2. Choose the layout (wallet card, thermal label, full sheet), who gets the card (patient, guardian, substitute decision-maker, youth-confidential), and a registered print station. 3. Send. The page shows the job status and the code masked, like `KB••-••RM`. _Screenshot pending: staff-print-card_ The printed card has the QR code, the visit code, the hospital name, the patient's initials only, bilingual instructions and the not-an-emergency line. _Screenshot pending: visit-card-print_ * A job sent within 15 minutes of issue reuses the same card. * After 15 minutes, sending means **Reissue**: a new code, and the old one stops working at once. Tick **Also sign out devices** if the card was lost or given to the wrong person. * Printing on a confidential visit needs a recorded unmask. ## Who gets the card [#who-gets-the-card] | Recipient | What changes | | -------------------------- | ---------------------------------------------------------------------------------- | | Patient | Standard wording | | Guardian | "Your child" wording; "Is this who you're here with?" | | Substitute decision-maker | "The person you're caring for" wording | | Youth-confidential | The patient's own wording, sensitive tests hidden, sharing off, no guardian access | | Not appropriate for EDFlow | No card; the visit is excluded | ## Staff-assisted sign-in (pairing) [#staff-assisted-sign-in-pairing] When a patient needs help signing in: ### The patient opens "Get help signing in" [#the-patient-opens-get-help-signing-in] On their own phone. It shows a 6-character code and a QR, valid for a few minutes. ### You open the visit [#you-open-the-visit] From the board. Opening is recorded. ### Enter or scan the code [#enter-or-scan-the-code] Choose **Approve pairing code**, enter or scan the code, pick a text size for the patient, and **Approve**. The patient's phone signs in and asks "Is this you?". The code only works on the phone that showed it. _Screenshot pending: staff-assisted-qr_ ## Lost or wrong card [#lost-or-wrong-card] Open the patient, **Sharing & access → Visit card → Reissue**. Choose whether to sign out every device already on the visit (this also ends their family links and text subscriptions). See [Lost cards and access](/staff/clerks/lost-cards-and-access). ## Related [#related] * [Helping patients sign in](/staff/clerks/helping-patients-sign-in) * [Sign in](/patients/sign-in), the patient's side # What patients see (https://docs.edflow.space/staff/what-patients-see) The same visit in the EDFlow staff console and on the patient's phone, side by side, so staff can answer patient questions about stages, estimates, tests and requests. Patients will ask you about what their phone says. This page shows the same visit from both sides, and the rules that decide what reaches the patient. ![Patient detail: stage, care team, tests, requests and tasks, with the source of each fact (EHR, manual or override).](https://docs.edflow.space/screenshots/web/staff-patient-detail.png) ![Visit screen: the current step is Tests under way, with what happens next, the care team card, a usual wait range and the I feel worse button.](https://docs.edflow.space/screenshots/web/patient-visit-home.png) ## How the console maps to the patient screen [#how-the-console-maps-to-the-patient-screen] | Console | Patient screen | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Arrived, not triaged | "Checked in", arrival-to-triage wait when available | | Triaged, waiting | "Waiting to be seen", with the usual wait for their stream and CTAS. **CTAS 1 and 2: no estimate** ("We'll see you as soon as we can. The sickest people are always seen first.") | | Physician assigned (Assign me) | "A doctor has been assigned" (or NP, PA). No estimate | | Seen (PIA) | "Seen by a doctor" (or NP, PA) | | Orders pending | "Tests under way", each test with its steps and usual wait | | All counted results visible | "Results back: waiting to see your care team again", with the usual time to reassessment | | Consult requested | "Waiting for a specialist", the service in plain words unless sensitive | | Observation started | "Treatment and monitoring" with the planned end | | Disposition home | "Getting ready to go home", then "You can go now" after **Cleared to leave** | | Disposition admit | "Staying in hospital: waiting for a bed"; bed requested, assigned, ready | | Disposition transfer | "Moving to another hospital" | ## What never reaches the patient [#what-never-reaches-the-patient] * CTAS, chief complaint, care flags, result values, flags or interpretation. * Anything you write in the EHR chart. * Tests or consults you hide (**Hide from the patient view**), or sensitive tests beyond "Additional test". * Location beyond the area label (unless the site shows room labels). * Any other patient. ## Answering "how much longer?" [#answering-how-much-longer] 1. Open the patient and look at **What the patient sees** on the Overview tab: the stage label, the estimate text and its basis. 2. The segment table shows the raw p50, p75, p90 and the sample count behind it. 3. If the patient is past p90, their screen already says it's taking longer than usual, and a low-priority "Over the usual wait" item is in the queue. Acknowledging it changes their screen to "Your care team knows you're waiting." ## Useful talking points [#useful-talking-points] * "The app shows what usually happens here at this time of day. It isn't a countdown." * "The sickest people are always seen first, so the order changes." * "Your results are back means the team can look at them. We'll go over them with you." * "If you feel worse, tell me or any staff member right away, not just the app." ![Visit screen: the current step is Tests under way, with what happens next, the care team card, a usual wait range and the I feel worse button.](https://docs.edflow.space/screenshots/web/patient-visit-home.png) ## Related [#related] * [How a visit works](/start/how-a-visit-works) * [Wait estimates](/patients/wait-estimates) * [Patient detail](/staff/patient-detail) # Choose your guide (https://docs.edflow.space/start/choose-your-guide) Find the EDFlow guide for your role: patients, family, nurses, physicians, charge nurses, registration clerks, managers, privacy officers, integration analysts, developers and hospital IT. Pick the row that matches what you do. Each reading list is in the order we suggest, and the first link is always the one to read before your first shift or your first visit. ## Patients and family [#patients-and-family] | You are | Start with | Then | | --------------------------------------------- | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A patient in the emergency department | [Sign in](/patients/sign-in) | [Your visit](/patients/your-visit), [If you feel worse](/patients/if-you-feel-worse), [Asking your care team](/patients/requests), [Share with family](/patients/share-with-family) | | A parent or guardian | [Sign in](/patients/sign-in) | [Your visit](/patients/your-visit), [If you feel worse](/patients/if-you-feel-worse) | | A family member or friend who received a link | [Open your link](/family/open-your-link) | [What family can see](/family), [Family questions](/family/faq) | ## The care team [#the-care-team] | Role | Start with | Then | Quick-reference card | | ----------------------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------ | | Nurse | [A nursing shift](/staff/nurses) | [Board](/staff/board), [Requests](/staff/requests), [Tasks](/staff/nurses/tasks), [Family links](/staff/nurses/family-links) | On the nurses page | | Triage nurse | [Triage](/staff/nurses/triage) | [Visit cards and sign-in help](/staff/visit-cards-and-sign-in-help), [Requests](/staff/requests) | On the nurses page | | Physician, resident, NP or PA | [Physicians](/staff/physicians) | [Results and reassessment](/staff/physicians/results-and-reassessment), [Calling a code](/staff/physicians/calling-a-code) | On the physicians page | | Charge nurse | [Running the department](/staff/charge) | [Codes](/staff/charge/codes), [Department volume](/staff/charge/department-volume), [When the feed is down](/staff/charge/feed-down) | On the charge nurse page | | Registration clerk | [Clerks](/staff/clerks) | [Visit cards](/staff/clerks/visit-cards), [Helping patients sign in](/staff/clerks/helping-patients-sign-in) | On the clerks page | | Support worker | [Requests](/staff/requests) | [Companion app](/staff/companion-app) | — | Every staff member should also read [Privacy at work](/staff/privacy-at-work) and [Sign-in and security](/staff/sign-in-and-security). ## Administrators [#administrators] | Role | Start with | Then | | ------------------- | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ED manager | [Admin overview and go-live checklist](/admin) | [Users and access](/admin/users-and-access), [Settings](/admin/settings), [Analytics](/admin/analytics), [Pilot playbook](/admin/pilot-playbook) | | Privacy officer | [Audit and access reports](/admin/privacy) | [Access requests and retention](/admin/privacy/access-requests-and-retention), [Vendor support access](/admin/privacy/vendor-support-access) | | Integration analyst | [Feed health](/admin/integration) | [Sources and keys](/admin/integration/sources-and-keys), [Unmapped codes](/admin/integration/unmapped-codes), [Dead letters](/admin/integration/dead-letters) | ## Technical teams [#technical-teams] | Role | Start with | Then | | -------------------------------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Integration-engine or EMR developer | [Quickstart](/developers/quickstart) | [Concepts](/developers/concepts), [Authentication](/developers/authentication), [Engine configuration](/developers/engine-configuration), [Go live](/developers/go-live) | | Hospital IT, security or privacy reviewer | [Trust overview](/security) | [Architecture](/security/architecture), [Data flow](/security/data-flow), [PHIPA](/security/phipa), [Controls](/security/controls) | | Communications and patient-education authors | [Brand](/brand) | [Hospital communications](/brand/hospital-communications), [Writing patient content](/brand/writing-patient-content) | ## What each staff role can do [#what-each-staff-role-can-do] The table below is generated from the product's permission catalogue, so it is always the current set. | Permission | R-TRIAGE | R-NURSE | R-PHYSICIAN | R-CHARGE | R-CLERK | R-SUPPORT | | --- | --- | --- | --- | --- | --- | --- | | board.view | Granted | Granted | Granted | Granted | Conditional | Not granted | | patient.view | Granted | Granted | Granted | Granted | Conditional | Not granted | | patient.unmask | Granted | Granted | Granted | Granted | Granted | Not granted | | patient.register | Granted | Not granted | Not granted | Granted | Granted | Not granted | | patient.state | Granted | Granted | Granted | Granted | Not granted | Not granted | | patient.override | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | | patient.lifecycle | Not granted | Not granted | Not granted | Granted | Conditional | Not granted | | careteam.assign | Granted | Granted | Granted | Granted | Not granted | Not granted | | zones.assign | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | | results.release | Not granted | Not granted | Granted | Granted | Not granted | Not granted | | tasks.manage | Granted | Granted | Granted | Granted | Not granted | Not granted | | avs.compose | Not granted | Granted | Granted | Granted | Not granted | Not granted | | avs.medications | Not granted | Not granted | Conditional | Not granted | Not granted | Not granted | | access.card | Granted | Granted | Granted | Granted | Granted | Not granted | | access.revoke | Not granted | Not granted | Not granted | Granted | Granted | Not granted | | share.manage | Granted | Granted | Granted | Granted | Not granted | Not granted | | privacy.flag | Granted | Not granted | Not granted | Granted | Granted | Not granted | | patient.restrict | Granted | Granted | Granted | Granted | Not granted | Not granted | | updates.pause | Not granted | Not granted | Granted | Granted | Not granted | Not granted | | patient.callback | Granted | Granted | Granted | Granted | Granted | Not granted | | request.view | Granted | Granted | Granted | Granted | Not granted | Not granted | | request.act | Granted | Granted | Granted | Granted | Not granted | Not granted | | request.bulk | Granted | Granted | Not granted | Granted | Not granted | Not granted | | code.call | Not granted | Not granted | Granted | Granted | Not granted | Not granted | | code.clear | Not granted | Not granted | Granted | Granted | Not granted | Not granted | | code.notice | Granted | Granted | Granted | Granted | Granted | Not granted | | support.queue | Not granted | Not granted | Not granted | Granted | Not granted | Granted | | volume.set | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | | analytics.view | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | | analytics.self | Not granted | Conditional | Conditional | Conditional | Not granted | Not granted | | analytics.clinician_blinded | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | analytics.clinician_named | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | analytics.export | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | users.view | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | | users.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | users.import | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | settings.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | config.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | stations.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | approvals.decide | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | training.manage | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | | content.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | content.approve | Not granted | Not granted | Conditional | Conditional | Not granted | Not granted | | announcements.manage | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | | integration.view | Not granted | Not granted | Not granted | Granted | Not granted | Not granted | | integration.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | audit.view | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | audit.export | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | privacy.legal_hold | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | privacy.incident | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | privacy.emergency_revoke | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | outbox.view | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | access_review.run | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | simulator.use | Not granted | Not granted | Not granted | Conditional | Not granted | Not granted | | seed.reset | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | platform.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | developers.view | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | developers.manage | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | developers.credentials | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | developers.approve | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | developers.attest_pia | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | developers.accept_affiliation | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | | ai.safety_review | Not granted | Not granted | Not granted | Not granted | Not granted | Not granted | The permissions of each role are fixed by the product; hospitals decide who holds which roles, and privileged roles need a second person's approval. See [Users and access](/admin/users-and-access) for the full matrix, including administrator roles. # Demo (https://docs.edflow.space/start/demo) Try EDFlow with two fictional Ontario hospitals: what each sample visit shows, how to open the demo launcher with an invite code, and what the demo will never contain. The showcase is a complete EDFlow deployment filled with **made-up** hospitals, visits and staff. Nothing in it is real, and it refuses real data: it runs only on deployments marked as synthetic, and every screen carries a "Demo" chip for patients and an environment banner for staff. ## The fictional hospitals [#the-fictional-hospitals] | | Kestrel Bay General Hospital | Pine Hollow Community Hospital | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | Setting | A large emergency department with 39 treatment spaces in resuscitation, two acute zones, fast track, internal waiting and hallway spaces | A small community emergency department with 10 spaces | | EHR | A simulated Epic feed, healthy, with heartbeats every minute | None: runs in manual mode from the staff console | | Languages | English by default, French available | French by default, English available | | Data profile | Standard: patients sign in with last name, date of birth and visit code | Minimal: patients sign in with a 10-character visit code and type the first name they want to be called | | History | Ten weeks of visits, so every estimate and every analytics page is populated | Ten weeks at a smaller volume | ## What the sample visits show [#what-the-sample-visits-show] About thirty live visits cover every stage and the situations that are hardest to explain in words: * **Waiting to be seen**, with a busy-department banner, an estimate in French, a patient who stepped out for food and was called back, and a patient past the usual wait who is thinking of leaving. * **Tests under way**, with a CT scan that needs consent and a "check before eating" instruction, a troponin that needs a repeat, a blood culture whose results come later, a child's urine sample, and results held by a physician. * **Results back**, one within the usual wait and one well past it, with the staff alert acknowledged. * **Waiting for a specialist**, **treatment and monitoring**, **getting ready to go home** with a published going-home summary, **staying in hospital** waiting for a bed with a substitute decision-maker signed in by staff-assisted pairing, and **moving to another hospital**. * **Privacy situations**: a confidential patient masked on the board with sharing unavailable, a youth-confidential card, a patient with an unknown identity who cannot sign in, a visit whose updates are paused, and a "must not leave" care flag. * **After the visit**: a read-only visit with its summary, an admitted patient whose access moved to the inpatient unit, and a patient who left without being seen. * **Staff side**: an urgent "I feel worse" request being answered, an escalated request, a code cleared two hours ago with its delay-notice history, volume set to busy, and ten weeks of audit, outbox, integration and analytics history. The Pine Hollow visits show the manual-only experience: "Your tests are under way" instead of a row per test, and a visit code sign-in. ## Opening the demo [#opening-the-demo] ### Get a demo invite code [#get-a-demo-invite-code] Ask your EDFlow contact for a demo invite code. Codes are personal, expire, and are rotated before every presentation. The sample visits are re-created every four hours, so their waits and timestamps always read relative to now. ### Open the launcher [#open-the-launcher] On the web, open the demo launcher from the product site and enter your invite code. On the showcase build of the app, open **Showcase** from the sign-in screen. ### Pick a visit or a role [#pick-a-visit-or-a-role] Each card opens the matching screen as that patient, family member or staff role, in the right language. ![Showcase launcher listing the fictional hospitals and their sample visits by stage, with every visit code, date of birth and QR code replaced by a sample placeholder.](https://docs.edflow.space/screenshots/web/demo-launcher.png) _Screenshot pending: showcase-launcher_ ## What the docs never show [#what-the-docs-never-show] This page and every screenshot in these docs are captured from a separate **docs** profile of the same seed, where every person has an obviously made-up name built from a tree, such as Sample Patient Birch, Demo Cedar or Dr. Demo Elm, and every date of birth is January 1. The docs never list passwords, visit codes, last names with dates of birth, or working QR codes. Every QR code in a screenshot is a non-functional sample. The demo resets every night. Changes you make disappear at the next reset, and demo staff accounts cannot change passwords, invitations or settings. ## Related [#related] * [How a visit works](/start/how-a-visit-works) * [For hospitals](/start/for-hospitals) * [Sandbox](/developers/sandbox) for developers, which uses the same fictional hospitals # Devices (https://docs.edflow.space/start/devices) Which phones, browsers and screens EDFlow supports: iOS 17 and later (designed for iOS 26), Android 8 and later, current browsers with no install, and the waiting-room display. Patients and family never need to install anything: the web version is complete on its own. The app is there for people who prefer it. ## Supported versions [#supported-versions] The table is generated from the same configuration the apps are built with. | Platform | Minimum | | | --- | --- | --- | | iOS, iPadOS | 17.0 | Designed for iOS 26 | | Android | 8.0 (API 26) | Target: the current Android API level | | Chrome | 111 | No installation needed | | Edge | 111 | | | Firefox | 111 | | | Safari (macOS, iOS) | 16.4 | | | Waiting-room display (browser in kiosk mode) | 1920 × 1080 | Any current browser in kiosk mode | ## Web or app? [#web-or-app] | | Web (no install) | App (iPhone, Android) | | -------------------------------- | ------------------------------------------ | -------------------------------------------------------- | | How to start | Scan the QR code with the phone's camera | Download the app, then scan inside it | | Everything a patient needs | Yes | Yes | | Notifications | Text messages if the patient turns them on | Push notifications, and text messages if preferred | | Works offline | Shows the last known view | Shows the last known view, stored encrypted on the phone | | Lock with Face ID or fingerprint | — | Yes | | Stays after the visit | Cleared when access ends | Cleared when access ends, even with no network | #### Web ![Visit screen: the current step is Tests under way, with what happens next, the care team card, a usual wait range and the I feel worse button.](https://docs.edflow.space/screenshots/web/patient-visit-home.png)#### iPhone ![Visit screen: the current step is Tests under way, with what happens next, the care team card, a usual wait range and the I feel worse button.](https://docs.edflow.space/screenshots/web/patient-visit-home.png)#### Android ![Visit screen: the current step is Tests under way, with what happens next, the care team card, a usual wait range and the I feel worse button.](https://docs.edflow.space/screenshots/web/patient-visit-home.png) See [App or browser](/patients/app-or-browser) for the patient's point of view. ## Staff devices [#staff-devices] * **Staff console:** any supported desktop browser on a hospital workstation. Shared workstations are fine: the console locks after 15 minutes of inactivity by default and every session ends after 12 hours. * **Companion app:** hospital-managed phones only (MDM). The app refuses staff mode on a phone with no passcode and asks for Face ID, fingerprint or the passcode after 5 minutes in the background. See [Companion app](/staff/companion-app) and [Devices for IT](/security/devices). * **Print stations** for visit cards and **big-board stations** are registered by a manager and have their own device credential, never a person's session. ## Waiting-room display [#waiting-room-display] A television at 1920 × 1080 or larger, running a current browser in kiosk mode, pointed at the hospital's display page. It shows only department-level information: how busy it is, how a visit works, how to join, and the check-in-first message. See [Waiting-room display](/admin/settings/waiting-room-display) and [Network requirements](/security/network-requirements). # Frequently asked questions (https://docs.edflow.space/start/faq) Answers to common questions about EDFlow from patients, families, staff, hospital leaders and IT: results, wait times, privacy, costs to staff time, and integration. ## For patients and family [#for-patients-and-family] No. You see when a result is back, never what it is. Your care team talks with you about results. After your visit, your hospital's patient portal may show them. See [Tests](/patients/tests). No. The sickest people are always seen first, so the order changes all the time. You see the usual wait for your step at this hospital on this day and hour. See [Wait estimates](/patients/wait-estimates). Tell a staff member in person right away, or go to the triage desk. The "I feel worse" button also lets your care team know, but never wait for a reply on your phone. See [If you feel worse](/patients/if-you-feel-worse). No. Scan the QR code on your wristband or visit card with your phone's camera. The app is optional. See [App or browser](/patients/app-or-browser). Yes, if you choose. You can share a link with up to five people and stop sharing at any time. They see much less than you do: never tests, results or where you are. See [Share with family](/patients/share-with-family). You can see your visit read-only for a limited time after you leave, then access ends and the app clears what it stored on your phone. See [Privacy](/patients/privacy). ## For staff [#for-staff] It is designed to remove questions, not add them. Requests are structured and routed to the right person, "Where I am" messages (stepping out, back, washroom) create no task at all, and duplicates merge. Most states come from the EHR feed. See [Requests](/staff/requests). No free text reaches patients from the chart. Patients see stages, test steps, names and roles, tasks from approved templates, and the going-home summary you compose from approved templates. See [What patients see](/staff/what-patients-see). Patients see that updates may be delayed, estimates freeze, and the charge nurse can run the department from the console until the feed recovers. See [When the feed is down](/staff/charge/feed-down). Yes. Opening a patient's detail, unmasking a confidential name, and every action on a visit are recorded in the audit log that the privacy office reviews. See [Privacy at work](/staff/privacy-at-work). ## For hospital leaders and IT [#for-hospital-leaders-and-it] Any EHR that can send HL7 v2 or FHIR R4 through an integration engine, including Epic, Oracle Health Millennium and MEDITECH, plus normalized JSON events. Sites without a feed run from the manual console. See [For hospitals](/start/for-hospitals). Hospital production runs in Canada, in AWS `ca-central-1` with disaster recovery in `ca-west-1`. The demo and sandbox hold synthetic data only. See [Data residency](/security/data-residency). No. The event contract forbids them: events that contain prohibited fields are rejected before anything is stored. See [Data flow](/security/data-flow). EDFlow does not diagnose, triage, predict clinical outcomes or recommend treatment. It communicates logistics. AI features follow the same boundary and are off until a site approves them. See [AI governance](/security/ai). Request it from [compliance documents](/security/compliance-documents). It includes the architecture, the controls matrix, the TRA summary, subprocessors and the questionnaire answers. ## Still stuck? [#still-stuck] Patients and family: ask any nurse or the registration desk. Staff: ask your charge nurse or your site's EDFlow champion. Hospitals and developers: use the contact page on the product site. # For hospitals (https://docs.edflow.space/start/for-hospitals) Evaluating EDFlow for your emergency department: the pilot model, EHR options (Epic, Oracle Health, MEDITECH or manual), what IT provides, the go-live gates and the success metrics. This page is for ED leaders, clinical informatics, privacy and IT teams deciding whether to run a EDFlow pilot. It explains what a pilot looks like, what your teams provide, how go-live is decided, and how success is measured. ## How a pilot runs [#how-a-pilot-runs] ### Baseline (4 to 6 weeks before go-live) [#baseline-4-to-6-weeks-before-go-live] Measure the success metrics below without EDFlow: patient-experience survey answers, door-to-doctor and results-to-decision times, family calls to the desk, left-without-being-seen rate. The same definitions are used after go-live. ### Integration and shadow run [#integration-and-shadow-run] Your integration team connects the EHR feed in the customer-test environment, runs the conformance fixtures, then runs a 14-day shadow run where EDFlow derives stages without showing them to patients. ### Configuration, content and training [#configuration-content-and-training] Managers set up zones, request types, codes, tests and hospital information. A clinical approver signs off patient education and going-home templates. Staff in the pilot zones complete training in training mode. ### Go-live and weekly review [#go-live-and-weekly-review] Visit cards start printing after triage. A weekly review looks at activation, requests, response times and any hazard reports. See the [pilot playbook](/admin/pilot-playbook). ## EHR options [#ehr-options] | Your EHR | How it connects | Notes | | ------------------------ | -------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | Epic | HL7 v2 ADT and ORM/ORU through your integration engine, or FHIR R4 notifications | See [HL7 v2](/developers/hl7v2) and [FHIR R4](/developers/fhir) | | Oracle Health Millennium | HL7 v2 through the engine, or FHIR R4 | Same adapters, with vendor notes | | MEDITECH and others | HL7 v2 through the integration engine | The support matrix per vendor is on the [HL7 v2](/developers/hl7v2) page | | No feed yet | The staff console runs every state by hand | A first-class mode, not a demo: see [Manual console](/staff/manual-console) | Your engine sends EDFlow a narrow set of events (arrivals, triage, assignments, orders and their status, dispositions, departures). EDFlow never receives result values, diagnoses or clinical notes, and never writes back to the EHR during the pilot. See [Concepts](/developers/concepts). ## What your teams provide [#what-your-teams-provide] | Team | What they provide | | --------------- | ---------------------------------------------------------------------------------------------------------------------------- | | ED leadership | A pilot sponsor, a charge-nurse champion per shift, a clinical approver for patient content | | Integration | An outbound feed from the engine (store and forward), test messages, mapping of test and location codes | | Privacy | The PIA and the agent agreement; review of the security package; a privacy officer account | | IT and security | The TRA, network allow-list for staff workstations and the display, MDM for staff phones, Microsoft Entra ID sign-in if used | | Communications | Posters, QR signage and visit-card stock, using the [hospital communications kit](/brand/hospital-communications) | ## Go-live gates [#go-live-gates] A site moves from pilot preparation to live only when every gate is met. EDFlow shows the state of each gate on the platform page, and no one can override them: * a conformance run with every fixture passing; * a 14-day shadow run with at least 98% milestone agreement against the site's audit sample; * 95th-percentile EHR-to-screen time of 60 seconds or less; * rejected events below 0.5%, and no unmapped codes in the last 30 days; * roster reconciliation closing every test discharge; * the clinical safety case signed off for the site's configuration; * the PIA and TRA recorded as approved; * staff training completed for the pilot zones. Integration API traffic and AI features have their own gates, described in [Go live](/developers/go-live) and [AI](/admin/ai). ## Success metrics [#success-metrics] Targets are pilot targets against the pre-pilot baseline at the same site. "Not worse" means the 95% confidence interval excludes a relative worsening of more than 10%. Analytics definitions follow the Ontario QIP and NACRS conventions. See [Analytics](/admin/analytics). ![Flow and bottlenecks: median time per segment of the visit, with the slowest segments flagged and ranked.](https://docs.edflow.space/screenshots/web/admin-flow-bottlenecks.png) ## Privacy, residency and security [#privacy-residency-and-security] Hospital production runs in Canada (AWS `ca-central-1`, with disaster recovery in `ca-west-1`). EDFlow acts as your agent and electronic service provider under PHIPA. Start with the [trust overview](/security) and request the confidential security package from [compliance documents](/security/compliance-documents). ## What patients and staff will see [#what-patients-and-staff-will-see] ![Visit screen: the current step is Tests under way, with what happens next, the care team card, a usual wait range and the I feel worse button.](https://docs.edflow.space/screenshots/web/patient-visit-home.png) ![Live board: patients by zone with stage, time in department, assigned clinician, tests, open requests and bottleneck flags, with filters and saved views.](https://docs.edflow.space/screenshots/web/staff-board.png) ## Related [#related] * [Demo](/start/demo) with the fictional hospitals * [Pilot playbook](/admin/pilot-playbook) * [Integrating Epic and Oracle Health](https://edflow.space/learn/integrating-epic-and-oracle-health) and [Measuring ED flow](https://edflow.space/learn/measuring-ed-flow) on the product site # Glossary (https://docs.edflow.space/start/glossary) Emergency department terms used in EDFlow (CTAS, PIA, AVS, LWBS, NPO, disposition, code, boarding) with the plain words patients see and the terms staff use. EDFlow uses two registers: plain words for patients and family, and the usual clinical and administrative terms for staff. This glossary maps one to the other. ## Visit terms [#visit-terms] | Staff term | What patients see | Meaning | | ----------------- | --------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | Triage | First check by a nurse | The first nursing assessment on arrival, which sets how urgently the person needs to be seen | | CTAS | Never shown | Canadian Triage and Acuity Scale, levels 1 (most urgent) to 5. Used by staff and analytics only | | PIA | Seen by a doctor, a nurse practitioner or a physician assistant | Physician initial assessment: the first time a physician, NP or PA sees the patient | | Provider assigned | A doctor has been assigned | A clinician has taken the patient but has not yet seen them | | Reassessment | Seen again by your care team | The clinician sees the patient again after results are back | | Consult | Waiting for a specialist | A specialist service is asked to see the patient | | Observation | Treatment and monitoring | A planned period of watching, for example after treatment of an allergic reaction | | Disposition | The plan: going home, staying in hospital, moving to another hospital | The decision on where the patient goes next | | Boarding | Staying in hospital: waiting for a bed | Time between the decision to admit and leaving the ED | | LWBS | Left the department | Left without being seen. The family view never distinguishes it from going home | | AMA | Left the department | Left against medical advice | | LOS | — | Length of stay in the ED | | AVS | Your going-home summary | After-visit summary, written from approved templates. It is not the legal discharge record | | NPO | Please don't eat or drink anything for now | Nothing by mouth. Shown only when the EHR has an NPO order, never inferred | | Medical directive | Some tests have been started while you wait | Tests a nurse can start before a physician sees the patient | | Code | Your wait may be longer | A hospital emergency response. Patients see only the generic delay notice, and only for the codes the hospital allows | ## The stages [#the-stages] | # | Summary | | --- | --- | | 1 | Checked in | | 2 | Waiting to be seen | | 3 | A doctor has been assigned | | 4 | Seen by a doctor | | 5 | Tests under way | | 6 | Results back: waiting to see your care team again | | 7 | Treatment and monitoring | | 8 | Waiting for a specialist | | 9 | Getting ready to go home | | 10 | Moving to another hospital | | 11 | Staying in hospital: waiting for a bed | | 12 | Left the department | ## Care-team roles [#care-team-roles] | Staff role | What patients see | | -------------------------------------------------------------------------- | ------------------------------------------------------------------ | | Attending physician | Doctor | | Resident | Doctor in training | | Nurse practitioner | Nurse practitioner | | Physician assistant | Physician assistant | | Primary or zone nurse | Your nurse | | Triage nurse | Triage nurse | | Consultant | Specialist, with the service in plain words unless it is sensitive | | Respiratory therapist, social worker, pharmacist, support worker, students | Also caring for you | ## Product terms [#product-terms] | Term | Meaning | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Visit card | The card or wristband label with the QR code and visit code a patient uses to sign in | | Owner device | The first phone that signs in with the card and confirms "Is this you?". It can share with family and manage other devices | | Family link | A link the patient shares so up to three devices can follow a reduced view of the visit | | Grace window | How long after leaving the department the patient and family can still see the visit read-only | | Request | A structured message from the patient to the care team, such as a blanket or an interpreter | | Delay notice | The generic message patients see when a code is likely to delay their care | | Volume level | Normal, busy, very busy or surge, set by the charge nurse | | Feed | The stream of events from the hospital's EHR through its integration engine | | Manual console | Staff actions that set the same facts as the feed when there is no feed, or when it is wrong | | Usual wait, "most within" | "Usually" runs from the time half of people finish within to the time three in four finish within; "most within" is the time 9 in 10 finish within. All for this hospital, weekday and hour, rounded up | ## Related [#related] * [How a visit works](/start/how-a-visit-works) * [Wait estimates](/patients/wait-estimates) * Hospital information screens also have a "Words we use" section written by each hospital. # How a visit works (https://docs.edflow.space/start/how-a-visit-works) The emergency department visit from arrival to going home, as patients and family see it in EDFlow: every stage, what changes at each one, and what the family view shows. Every visit moves through the same patient-facing stages, whatever EHR the hospital uses. EDFlow works out the stage from what the care team records (an EHR event or a staff action in the console) and shows it in plain words. The stage never depends on a guess about another patient. ## The journey at a glance [#the-journey-at-a-glance] ```mermaid flowchart LR A[Checked in] --> B[Waiting to be seen] B --> C[A doctor has been assigned] C --> D[Seen by a doctor] B --> D D --> E[Tests under way] E --> F[Results back: waiting to see your care team again] F --> D F --> G[Waiting for a specialist] D --> H[Treatment and monitoring] D --> I[Getting ready to go home] D --> J[Staying in hospital: waiting for a bed] D --> K[Moving to another hospital] I --> L[Left the department] J --> L K --> L ``` Loops are normal. A doctor may order more tests after the first results, and the timeline simply adds new entries; nothing is moved or deleted. A step can also be skipped: a patient seen quickly after triage never shows "A doctor has been assigned". ## The stages [#the-stages] These are the labels patients and family see, straight from the product: | # | Summary | | --- | --- | | 1 | Checked in | | 2 | Waiting to be seen | | 3 | A doctor has been assigned | | 4 | Seen by a doctor | | 5 | Tests under way | | 6 | Results back: waiting to see your care team again | | 7 | Treatment and monitoring | | 8 | Waiting for a specialist | | 9 | Getting ready to go home | | 10 | Moving to another hospital | | 11 | Staying in hospital: waiting for a bed | | 12 | Left the department | ### What changes at each stage [#what-changes-at-each-stage] | Stage | What the patient sees change | What the family sees | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | Checked in | "A nurse will check you soon", and the arrival-to-triage wait when the hospital has enough history. | Checked in | | Waiting to be seen | The usual wait to see a doctor, a nurse practitioner or a physician assistant. Hidden for the most urgent triage levels, where the message is that the sickest people are always seen first. | Waiting to be seen, with the same estimate | | A doctor has been assigned | The name and role of the person assigned. No estimate: they come as soon as they can. | Waiting to be seen | | Seen by a doctor | "Your care team is working on a plan with you." The care-team card fills in. | Seen by an emergency care provider | | Tests under way | Each test with its steps and usual wait, and how many are back. Never the results. | Care in progress (no tests) | | Results back | "Waiting to see your care team again", with the usual time until reassessment. | Care in progress | | Waiting for a specialist | The specialty in plain words, unless the hospital hides it. | Care in progress | | Treatment and monitoring | How long the team would like to watch, without "longer than usual" messages. | Care in progress | | Getting ready to go home | Wait for the nurse to go over instructions and take out the IV. The going-home summary when it is published. | Care in progress, or "Getting ready to go home" only when the patient turns it on | | Staying in hospital | Waiting for a bed upstairs, then "Your bed is ready". | Staying in hospital (no unit or bed) | | Moving to another hospital | The team will say when and how. | Moving for more care (no destination) | | Left the department | A read-only view with the summary and feedback for a limited time. | A short departure message, then the updates end | ## Where each fact comes from [#where-each-fact-comes-from] * **Arrival, triage, the doctor assignment and "seen"** come from the EHR feed, or from the charge nurse or clerk in the console when there is no feed. * **Tests** come from orders and their status in the EHR. Some hospitals delay "results are back" by a few minutes so a clinician sees them first. * **Codes and volume** come from staff in the console. Patients see the same timeline whether a fact came from the EHR or from a staff member. Staff see where each fact came from. ![Timeline of the visit: each step so far with its time, and the steps still to come.](https://docs.edflow.space/screenshots/web/patient-timeline.png) ## How family see the visit [#how-family-see-the-visit] The family view shows much less: the stage in family words, the estimate only while the patient waits to be seen (or for a bed, when the hospital allows it), the first names and roles of the doctor and nurse, and hospital information. It never shows tests, results, requests, where the patient is in the department, or anything the patient wrote. ![Family view: the stage in plain words and when it last changed. No tests, results or location are shown.](https://docs.edflow.space/screenshots/web/family-view.png) ## Related [#related] * [Your visit](/patients/your-visit), [Timeline](/patients/timeline) and [Tests](/patients/tests) for patients * [What family can see](/family) for family members * [What patients see](/staff/what-patients-see) for staff answering questions at the bedside * [Why wait estimates should under-promise](https://edflow.space/learn/why-wait-estimates-should-under-promise) on the product site # What EDFlow is (https://docs.edflow.space/start) EDFlow shows emergency department patients and their families where the visit is, who is caring for them and how long each step usually takes, and gives staff a live board, a request queue and flow analytics. EDFlow is a live, plain-language companion to an emergency department (ED) visit. A patient scans the QR code on their wristband or visit card and sees, on one screen, where they are in the visit, what happens next and roughly how long that step usually takes at this hospital, on this day and at this hour. No install and no account are needed. ## The problem it solves [#the-problem-it-solves] In Ontario, ED patients wait on average close to two hours to be seen by a physician, and one in ten waits more than four hours. About one in twenty leaves before being seen. Most of that time is spent not knowing: * where they are in the visit and what the next step is; * who their doctor and nurse are; * which tests are still pending and how long they usually take; * why things slowed down. Families call the desk for updates that staff cannot give over the phone, and nurses answer "how much longer?" many times a shift. Managers have no live view of where each visit is stalled. EDFlow answers those questions without adding work at the bedside. ## What patients see [#what-patients-see] ![Visit screen: the current step is Tests under way, with what happens next, the care team card, a usual wait range and the I feel worse button.](https://docs.edflow.space/screenshots/web/patient-visit-home.png) * **Their stage** in plain words, with what happens next. The stages are the same for every hospital; see [How a visit works](/start/how-a-visit-works). * **Usual waits** for the current step, as a range ("usually 30 to 55 minutes") and a ceiling most people finish within. There is never a countdown and never a place in line. See [Wait estimates](/patients/wait-estimates). * **Their care team** by first name and role, as soon as the hospital assigns them. * **Their tests** moving through their steps, and when results are back. Never the results themselves. * **Delay notices** in calm, generic words when someone very unwell needs the team, or when the department is very busy. * **Requests** to the care team (a blanket, water, "can I eat or drink?", an interpreter) that staff acknowledge by name. * **A family view** they can share and stop sharing at any time. ## What staff get [#what-staff-get] ![Live board: patients by zone with stage, time in department, assigned clinician, tests, open requests and bottleneck flags, with filters and saved views.](https://docs.edflow.space/screenshots/web/staff-board.png) * A **live board** of every visit with its stage, time in stage, tests and open requests. * A **request queue** routed to the right nurse, zone or support worker, with escalation when nobody responds. * A **manual console** that runs the department's EDFlow states when the EHR feed is down or absent. * **Codes and department volume** in two steps, with generic patient notices only for the codes the hospital allows. * A **companion app** for hospital-managed phones: requests, my patients and the department at a glance. ## What managers and IT get [#what-managers-and-it-get] ![Admin overview: today's volume, median waits by segment, open requests, feed health and the go-live checklist.](https://docs.edflow.space/screenshots/web/admin-overview.png) * Flow analytics built on Ontario definitions: door to doctor, results to decision, length of stay, boarding, request response times, with bottleneck flags. * Settings with ranges, approvals and a full history, content governance for patient education, and an audit log of every access to patient data. * An integration API, a sandbox with fictional hospitals, and adapters for normalized events, FHIR R4 and HL7 v2. See [Developers](/developers). ## What it never does [#what-it-never-does] > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. * **It is not an emergency channel.** "I feel worse" always tells the person to alert staff in person, right away, before anything else. See [Safety](/start/safety). * **It never shows results**, result values, flags or interpretations. Care teams talk with patients about results. * **It never diagnoses, triages or gives medical advice**, and never shows a triage level, a place in line or a comparison with anyone else. * **It never puts health information in notifications**, text messages, links or logs. Lock screens say only "You have a new update." * **It never replaces the EHR, the patient portal or the discharge papers.** ## Where to go next [#where-to-go-next] Further reading on the product site: [What patients want to know during an ED visit](https://edflow.space/learn/what-patients-want-to-know). # Languages and accessibility (https://docs.edflow.space/start/languages-and-accessibility) EDFlow in English and French, safety messages in each hospital's top languages, text up to 200%, screen readers, Dynamic Type and font scale, high contrast, reduced motion and colour-independent status. EDFlow is built to be used by anyone in a waiting room: someone in pain, someone who reads another language first, someone using a screen reader, someone holding a phone at arm's length. Every patient, family, staff and admin screen meets WCAG 2.2 level AA. ## Languages [#languages] * **English and French everywhere.** Patients, family members and staff each choose their own language. A family member can read in French while the patient reads in English. * **Safety messages in more languages.** Each hospital can add up to five safety locales (for example the most common languages in its community). The safety panel, "I feel worse", delay notices and the not-an-emergency footer are translated into those languages and reviewed before use. * **Hospital content** (education sheets, directions, FAQ) is written by the hospital in English and French. A missing French entry is shown in English, marked so screen readers switch voice. * **Interpreters.** Patients can ask for a spoken-language interpreter or a sign-language interpreter (ASL or LSQ) from the requests screen. See [Asking your care team](/patients/requests). ![Visit screen: the current step is Tests under way, with what happens next, the care team card, a usual wait range and the I feel worse button.](https://docs.edflow.space/screenshots/web/patient-visit-home.png) ## Reading and text size [#reading-and-text-size] * Patient and family wording is written for a grade 6 to 8 reading level, with short sentences and no medical jargon. Tests show their plain name first ("Blood count") and the abbreviation after ("CBC"). * **Web:** text size from 100% to 200% in settings, with a live preview. Nothing scrolls sideways or gets cut off at 200% on a 360-pixel-wide phone. * **iPhone:** Dynamic Type up to the largest accessibility sizes. * **Android:** font scale up to 200%. ![Settings: language, text size, high contrast, notifications, device lock, devices on my visit, and sign out.](https://docs.edflow.space/screenshots/web/patient-settings.png) ## Screen readers and keyboards [#screen-readers-and-keyboards] * VoiceOver, TalkBack, NVDA and JAWS are tested on every release. Every control has a label, and every change of stage is announced politely without stealing focus. * The "I feel worse" screen and delay notices take focus and announce their title. * On the web, every action works with a keyboard, focus is always visible, and the staff console has keyboard shortcuts and a command palette. * Swipe actions in the apps always have a visible button too. ## Colour, contrast and motion [#colour-contrast-and-motion] * Status is never shown by colour alone: every chip and step has text and a shape. Result steps use a neutral tone, never a "success" green. * **High contrast** is available on the web and follows the system setting in the apps. * **Reduced motion** follows the device, or can be set on the web. Notices fade in over at most 200 milliseconds and never flash or shake. * Light and dark themes follow the device, or can be chosen. ## Related [#related] * [Settings](/patients/settings) for patients * [Accessibility conformance](/security/accessibility) for hospital reviewers * [Languages](/admin/settings/languages) for administrators # Safety (https://docs.edflow.space/start/safety) The EDFlow safety model: I feel worse always sends people to staff first, delay notices never identify anyone, results are never shown, and what happens when the phone is offline. EDFlow is designed so that what it says, and when it says it, can never delay care. Every rule on this page is built into the product and cannot be turned off by a hospital setting. The wording below is the exact text patients see. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. ## "I feel worse" always sends people to a person first [#i-feel-worse-always-sends-people-to-a-person-first] The **I feel worse** button is on every patient screen. When someone taps it: 1. The phone shows, straight away and without waiting for the network: **Tell a staff member now**. Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. 2. At the same time, it sends an urgent request to the care team. There is no confirmation step, and three taps within a minute still make one request. 3. The screen never says or implies that someone is coming. When a staff member answers, the patient sees that the team knows they asked for help, and the instruction to tell someone in person stays at the top. 4. If the patient has stepped out of the department, the screen says: Come back to the emergency department now. If you can't, call 911. 5. After the visit, no request is sent. The screen says: If this is an emergency, call 911. For health advice, call Health811 at 811. !["I feel worse" screen: tell a nurse or another staff member now, or press your call button; the app also lets your care team know.](https://docs.edflow.space/screenshots/web/patient-feel-worse.png) Staff see the urgent request at the top of the queue and on their phones while on shift. It keeps escalating to the charge nurse until someone answers "Going now" or "Handled in person". See [Requests](/staff/requests). ## Delay notices never identify anyone [#delay-notices-never-identify-anyone] When someone very unwell needs the team, the charge nurse or the resuscitation team can post a delay notice for the patients whose care is likely to be delayed. Patients see: > Your wait may be longer. Someone in the emergency department needs urgent care right now, so part of our team is with them. This may add time to your wait. We haven't forgotten you, and we'll be with you as soon as we can. _Screenshot pending: patient-code-delay_ * The notice never names the code, its colour, the area, how many people are involved or how long it will last. * Only medical codes can notify patients. Security and facility codes (for example fire or a missing person) never reach patients through EDFlow. Hospital emergency management owns those. * The person the code is about, and anyone in the same area, never receives the notice. * A second code within 30 minutes updates the same notice instead of sending another. See [Delays](/patients/delays) and [Codes](/staff/charge/codes). ## Results are never shown [#results-are-never-shown] Patients see that a result is back. They never see a value, a flag or an interpretation, and "back" is never styled as good news. Some hospitals also wait a few minutes before showing "back", so a clinician sees the result first. The product says: You'll hear about your results from your care team, not in this app. ## No triage level, no place in line [#no-triage-level-no-place-in-line] Patients never see their triage level, a queue position, how many people are ahead of them, or a comparison with anyone else. Waits are shown as a usual range and a ceiling, based on past visits at the same hospital on the same day and hour. For the most urgent triage levels, no wait is shown before the patient is seen: We'll see you as soon as we can. The sickest people are always seen first. ## Offline and delayed information [#offline-and-delayed-information] | Situation | What the patient sees | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | The phone loses its connection | You're offline. We'll update this as soon as you reconnect. The last known view stays on screen with its time. Requests are never queued silently for later. "I feel worse" still shows the instruction to tell staff. | | The hospital's EHR feed is delayed | Updates may be delayed. Last updated {time}. Your care continues as usual. | | The feed is down | Estimates freeze and are marked as possibly out of date. Staff keep the visit current from the console. | | Staff pause a visit's updates | Updates are paused. Please speak with the care team or call the hospital. Nothing else changes until staff resume them. | ## Clinical safety management [#clinical-safety-management] Every change to stages, estimates, notifications, requests, tasks or patient wording goes through a hazard-log review before release. Hospitals receive the hazard log summary with the security review pack. See [IT and security](/security). ## Related [#related] * [If you feel worse](/patients/if-you-feel-worse) for patients * [Requests](/staff/requests) and [Escalations](/staff/charge/escalations) for staff * [Communicating code-alert delays without alarming patients](https://edflow.space/learn/communicating-code-delays) on the product site # Family questions (https://docs.edflow.space/family/faq) Answers for family and friends following an emergency visit in EDFlow: why you can't see test results, whether you can call the emergency department, and what to do when the link says too many devices. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. Health information belongs to the person you're following. The family view only shows where they are in their visit, rough waits while they wait to be seen, and who is caring for them. Their care team talks with them about results. You can ask them directly. Staff usually can't give updates over the phone, to protect privacy. The family view is the way to follow the visit. If you're worried about the person right now, call the hospital or speak to staff in person. In an emergency, call 911. Each link works on up to 3 devices. Ask the person who shared for a new link of your own. The person stopped sharing, the time they chose ran out, or they left the department. See [When updates end](/family/when-updates-end). The care team paused updates for now. Please call the hospital or speak with the care team. Many parts of a visit, like tests and waiting for results, show as "Care in progress" in the family view. It doesn't mean anything good or bad. No. Only the person you're following can send requests. You can ask them, or speak with staff in person. The view says, for example, "Times are shown in Toronto time (ET)." That's the hospital's time zone. After the person leaves, you may be asked three short questions about the updates. It's optional. ## Related [#related] * [What family can see](/family) * [Open your link](/family/open-your-link) # For family and friends (https://docs.edflow.space/family) Someone shared their emergency visit with you in EDFlow. What you'll see (their step, rough waits and who is caring for them), what you won't see (tests, results, location), and why. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. Someone you know is in the emergency department, and they chose to share updates with you. This page explains what you'll see. ![Family view: the stage in plain words and when it last changed. No tests, results or location are shown.](https://docs.edflow.space/screenshots/web/family-view.png) ## What you'll see [#what-youll-see] * **Where they are in their visit**, in a few words. For example: "Waiting to be seen", "Care in progress", "Staying in hospital". * **A rough wait**, only while they wait to be seen. Sometimes also while they wait for a bed upstairs. * **Who is caring for them**: first names and roles, like "Doctor" or "Nurse". * **Hospital information**: the address, parking, visitor rules, food and Wi-Fi. * **Notices** when the department is busy or when waits may be longer. * When the last change happened, and which time zone the times are in. If they turn it on, you'll also see when they are getting ready to go home, so you can plan a ride. ## What you won't see [#what-you-wont-see] * Tests or results. * Their requests or notes. * Where they are in the department. * Anything about other patients. ## Why you see less [#why-you-see-less] The person you're following decides what to share. Health information belongs to them. This view shows the minimum needed to know how things are going. If you'd like to know more, ask them directly. ## If you're worried [#if-youre-worried] If you're worried about {displayName} right now, call the hospital or speak to staff in person. In an emergency, call 911. Don't wait for an update on your phone. ## Related [#related] * [Open your link](/family/open-your-link) * [Updates](/family/updates) * [When updates end](/family/when-updates-end) * [Family questions](/family/faq) # Open your link (https://docs.edflow.space/family/open-your-link) How to open the visit updates link someone shared with you in EDFlow: tap View updates, choose your language, the 3-device limit, and using the app instead of the browser. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. You got a link by text, email or a QR code. It lets you follow a short version of someone's visit. ## Open the link [#open-the-link] ### Tap the link [#tap-the-link] It opens in your phone's browser. You don't need to install anything. ### Read who shared it [#read-who-shared-it] {displayName} chose to share these updates with you. You'll see where they are in their visit and who is caring for them. You won't see test details or results. ### Choose your language [#choose-your-language] English, French, or another language the hospital offers. You can choose a different language from the person who shared. ### Tap View updates [#tap-view-updates] Only this tap opens the updates, so link previews in messaging apps don't use up a device. ![Opening a family link on a new device: who shared it, what you will be able to see, and the Continue button.](https://docs.edflow.space/screenshots/web/family-link-entry.png) ## The device limit [#the-device-limit] Each link works on up to 3 phones or computers. If you see this, ask for a new link: > This link has already been opened on the most devices it allows. Ask {displayName} to send you a new link. Please don't forward the link. Ask the person who shared it to send one to each person instead. ## Using the app [#using-the-app] If you have the EDFlow app, the link opens in it. In the app you can get notifications for the big steps. The app shows nothing else in family mode. ## If the link doesn't work [#if-the-link-doesnt-work] You see: These updates have ended. The link may have ended or been stopped. We don't show why, for privacy. See [When updates end](/family/when-updates-end). ## Related [#related] * [What family can see](/family) * [Updates](/family/updates) # Updates (https://docs.edflow.space/family/updates) Get text or app updates when the person you're following reaches a big step, read the update history and hospital information, and use the family helper where the hospital offers it. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. The family view updates by itself while it's open. You can also choose to get a message when there's a big update. ## Text updates [#text-updates] Open **Settings** on the family view and turn on text updates. 1. Type your own phone number. 2. Type the 6-digit code we text you. You'll get a text when there's a big update, like seeing a doctor or going home. Texts never include health details. ![Family settings: language, optional notifications when the stage changes, and remove this device.](https://docs.edflow.space/screenshots/web/family-settings.png) Your number is stored encrypted and deleted when the link ends. To stop, reply STOP or tap **Stop receiving updates** in Settings. That ends updates on your phone only. Others who have the link keep theirs. ## Ask for a call back [#ask-for-a-call-back] On the family view, **Ask for a call back** lets you leave your number for the care team. Type your own number, then the 6-digit code we text you. A nurse calls when they can, and the card tells you when they have seen it. Your number is kept only until the call-back is closed. This is not for emergencies: in an emergency, call 911. In the app's family mode, the same card is on the home screen. ## App notifications [#app-notifications] In the app, you can turn on notifications. They say only: There's a new update. ## Update history [#update-history] Tap **Update history** to see the updates you received, newest first, with times. Before the first one, you see: Updates will show here when there's news. ## Hospital information [#hospital-information] Tap **Hospital info** for the address, directions with **Open in Maps**, parking, visitor and caregiver rules, food and pharmacy hours, Wi-Fi and the main phone number. ![Hospital information for family: parking, the visitor policy and where to wait.](https://docs.edflow.space/screenshots/web/family-info.png) ## Catching up [#catching-up] Some hospitals show a short "since you last looked" note at the top of the view when you come back after a while. It's built from the same steps you already see. ## The family helper [#the-family-helper] Some hospitals offer a helper that answers practical questions, like visiting rules, parking or how the emergency department works. It uses AI and answers from the hospital's information. It can't share health details. It says that only the person you're following and their care team can share those. If you're worried about the person, it tells you to speak to staff in person or call the hospital. In an emergency, call 911. ## Related [#related] * [What family can see](/family) * [When updates end](/family/when-updates-end) # When updates end (https://docs.edflow.space/family/when-updates-end) Why family updates in EDFlow stop: the person stopped sharing, the time they chose ran out, or they left the emergency department. What you see when updates end or are paused. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. Family updates don't last forever. When they end, you see: > These updates have ended. ![Updates ended: this family link has stopped working, either because the patient stopped sharing or because the visit is over.](https://docs.edflow.space/screenshots/web/family-ended.png) ## Why updates end [#why-updates-end] * The person who shared stopped sharing with you. * The time they chose ran out: the end of the visit, 4 hours or 12 hours. * They left the emergency department. Updates end a short time after they leave, 2 hours by default. * You tapped **Stop receiving updates** on your phone. We never show the reason, to protect their privacy. ## When they leave the department [#when-they-leave-the-department] For a short time after they leave, you see one of these: * {displayName} has left the emergency department. * {displayName} is staying in the hospital. * {displayName} is moving to another hospital for more care. You won't see which unit or which hospital. ## When updates are paused [#when-updates-are-paused] Sometimes the care team pauses updates. You then see: > Updates are paused. Please call the hospital or speak with the care team. Nothing else changes on your screen until they resume. A pause isn't the same as updates ending. ## Want to keep following? [#want-to-keep-following] Ask the person who shared for a new link. ## Related [#related] * [What family can see](/family) * [Family questions](/family/faq) # Adoption and equity (https://docs.edflow.space/admin/analytics/adoption-and-equity) Who uses EDFlow in your ED: the activation funnel from card to feedback, broken down by preferred language, age band, arrival mode and platform, and the equity panel that flags gaps over 10 points. ![Adoption and equity: the share of visits that signed in, by language and age band, with gaps highlighted.](https://docs.edflow.space/screenshots/web/admin-adoption.png) ## The funnel [#the-funnel] Eligible visits → card issued → activated → notifications on (push or text) → family link created → family link opened → feedback given, with the rate between each step. Pilot targets: activation 40% or more by month 2 (M-17), family sharing 20% or more of activated visits (M-18). ## Breakdowns [#breakdowns] The same funnel by **EHR preferred language** (every language, not only English and French), app language, age band, arrival mode and platform (web, iPhone, Android). ## Equity panel [#equity-panel] Shows the largest activation-rate gap across preferred language and age band, and flags gaps over 10 points (M-19). ## Closing gaps [#closing-gaps] | Gap | Things that help | | ------------------ | ------------------------------------------------------------------------------------------------------- | | Language | Add a safety locale for the language; posters and cards in that language; interpreter requests promoted | | Older patients | Staff-assisted sign-in with larger text; the guardian or substitute decision-maker card | | Ambulance arrivals | Make sure cards print after triage for stretcher patients too | | No phone | The waiting-room display explains the visit; family can follow for the patient | ## Related [#related] * [Languages](/admin/settings/languages) * [Pilot playbook](/admin/pilot-playbook) # Ask your data (https://docs.edflow.space/admin/analytics/ask-your-data) Ask plain-language questions about ED operations in EDFlow and get charts and reports built from de-identified analytics, with the query shown, plus anomaly alerts. What data it uses and how to review it. Where the site turns it on, **Ask your data** answers operational questions in plain language with a chart, a table and the definitions it used. ![Ask your data: a question about last week's door-to-doctor times answered with a chart and the query it used, labelled as AI and for review.](https://docs.edflow.space/screenshots/web/admin-ask-your-data.png) ## Good questions [#good-questions] * "How did door-to-doctor compare with the same Tuesday last month?" * "Which hours this week had the longest results-to-seen-again times?" * "Show LWBS rate by week since the pilot started." * "Which request types took longest to acknowledge in the waiting room?" ## What it uses [#what-it-uses] * Only the de-identified, aggregate analytics tables and the metric definitions, with the same small-cell suppression as the charts. * Never a patient record, a name or free text. * It shows the definitions and filters it applied, so you can check them and open the same view in the normal charts. ## What it won't do [#what-it-wont-do] * Answer questions about an individual patient. * Rank or compare named clinicians. * Predict outcomes for individual patients. ## Anomaly alerts [#anomaly-alerts] Where enabled, managers get a short explanation when a metric moves far from its usual range (for example a sudden rise in time to reassessment), with links to the charts. Alerts describe what changed; they don't say why. ## Review before you share [#review-before-you-share] AI can be wrong. Check a chart against the regular analytics pages before you share it. Every answer is labelled as AI-generated. ## Related [#related] * [AI](/admin/ai) * [AI governance](/security/ai) # Clinician metrics (https://docs.edflow.space/admin/analytics/clinician-metrics) Per-physician step metrics in EDFlow: attribution, the blinded and named views, case-mix context, the minimum sample size, governance, and why there are never ranks or league tables. Clinician metrics are **off by default**. Turn them on only with the medical leadership's agreement and a written purpose (for example quality improvement, not performance management). ![Clinician metrics in blinded mode: step times per physician shown as coded names and ranges, never a ranking.](https://docs.edflow.space/screenshots/web/admin-clinician-metrics.png) ## The metrics [#the-metrics] Case mix is shown beside every metric: CTAS mix, age bands, ambulance share, night-shift share. ## Attribution [#attribution] Each segment is attributed to the clinician responsible during it, from the care-team history and handover releases. The decision clinician is the one on the disposition, otherwise the attending at that time. Visits handed over before the decision are reported separately ("handed over") and excluded from the default view. Per-hour values use the physician shift schedule. ## Views [#views] | View | Who | What | | ------- | ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | Self | Each physician (`analytics.self`) | Own values against the peer range (p25 to p75 of peers of the same clinician type with n ≥ 20), 6-month trend | | Blinded | Managers (`analytics.clinician_blinded`) | One strip per metric, each clinician a dot labelled "Clinician A, B…", relabelled randomly each month. No sorting by value. Clinicians with n \< 20 hidden | | Named | Only when the site turns on named metrics and the viewer has `analytics.clinician_named` | The same with names. Every view audited | ## Never [#never] Ranks, league tables or any public display. ## Settings [#settings] Turning on named metrics reduces privacy for clinicians: it needs a typed confirmation and is audited, and named metrics can't be on while clinician metrics are off. | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | careTeam.namePolicy | first_last_initial | first_last_initial, first_only | How non-physician staff names show to patients (physicians always "Dr. First Last"). (Reduces privacy) | | careTeam.allowPhotos | true | boolean | Staff may opt in to show photos. (Reduces privacy) | | careTeam.photoApproval | true | boolean | Photos need manager approval. (Reduces privacy) | | careTeam.showOtherRoles | true | boolean | Show roles beyond physician and nurse. (Reduces privacy) | | careTeam.showTriageNurseName | false | boolean | Show the triage nurse's name. (Reduces privacy) | ## Related [#related] * [My metrics](/staff/physicians/my-metrics), the physician's view # Codes and delays (https://docs.edflow.space/admin/analytics/codes-and-delays) Code and volume analytics in EDFlow: the code log, frequency by type and hour, patients notified, the descriptive code impact on waits, and time in each volume level. ![Codes and delays: codes called by type and hour, and how long patient notices ran.](https://docs.edflow.space/screenshots/web/admin-codes-analytics.png) ## Code log [#code-log] Type, category, source (console, paging, EHR), called, cleared or expired, duration, patients notified and push sent. It contains no patient identifiers. ## Frequency [#frequency] By type and by hour of day. ## Impact [#impact] For patients waiting to be seen during a notifying code: the ratio of their wait to their bucket's p50, compared with the same ratio for similar weekday-hour buckets without a code, over the last 12 weeks. Codes often coincide with busy periods; this is descriptive, not causal. ## Volume [#volume] Hours in each volume level per day, and how often suggestions were accepted or dismissed. ## Related [#related] * [Codes](/staff/charge/codes) * [Code types](/admin/settings/code-types) # Estimate quality (https://docs.edflow.space/admin/analytics/estimate-quality) Check that EDFlow wait estimates are honest: coverage of the 9-in-10 ceiling (target 88%), calibration, fallback levels, bucket coverage, the benchmark job and importing historical data. Patients trust estimates only if they're honest. This page measures them against what actually happened. ![Estimate quality: how often "at the longest" held, by test and hour, and calibration of the usual range.](https://docs.edflow.space/screenshots/web/admin-estimates.png) ## Calibration [#calibration] For each metric: * **Coverage**: the share of completed intervals that finished within the "9 in 10" ceiling the patient saw. Target 88% or more (M-20). * The share that finished within the "usually" range. * The median absolute difference from the p50. A metric whose coverage falls below 85% over 4 weeks is flagged **Estimates may be too optimistic**. ## Fallback levels [#fallback-levels] The share of estimates served from each level: same weekday and hour, hour ± 1, weekday or weekend, any day at that hour, any time, the catalogue default, or none. A site with little history leans on defaults; importing history helps. ## Bucket coverage [#bucket-coverage] A map of samples per weekday-hour bucket for each metric, with buckets below the minimum highlighted. ## Benchmark job [#benchmark-job] Runs hourly for metrics with new samples and fully each night. The page shows its history. Each patient's estimate is snapshotted when the step starts, so a recompute never changes what a patient already sees. ## Historical import [#historical-import] Upload de-identified historical intervals (CSV: metric key, dimension, local start, minutes) to calibrate before go-live. Needs `integration.manage` and a fresh sign-in check. Every row is validated and nothing is applied if any row fails. Imports are audited with counts. | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | estimates.hideBeforePiaForCtas | [1,2] | array | CTAS levels whose estimate is hidden before the patient is seen (SR-07). | | estimates.showBoardingEstimate | false | boolean | Show the boarding estimate (D-32). | | estimates.streamDimension | true | boolean | Use the stream in triage-to-seen buckets (D-33). | | estimates.windowWeeks | 12 | 4–26 weeks | Sample window for estimates (F-05.3). | | estimates.minSamples | 20 | 10–100 count | Minimum samples per ladder level. | | estimates.flowDefaults | [{"dimension":"","metricKey":"flow.arrival_to_triage","p50":10,"p75":15,"p90":30},{"dimension":"1","metricKey":"flow.triage_to_seen","p50":0,"p75":0,"p90":5},{"dimension":"2","metricKey":"flow.triage_to_seen","p50":15,"p75":25,"p90":45},{"dimension":"3","metricKey":"flow.triage_to_seen","p50":60,"p75":90,"p90":180},{"dimension":"4","metricKey":"flow.triage_to_seen","p50":90,"p75":120,"p90":240},{"dimension":"5","metricKey":"flow.triage_to_seen","p50":90,"p75":135,"p90":240},{"dimension":"1","metricKey":"flow.triage_to_pia","p50":0,"p75":0,"p90":5},{"dimension":"2","metricKey":"flow.triage_to_pia","p50":15,"p75":25,"p90":45},{"dimension":"3","metricKey":"flow.triage_to_pia","p50":60,"p75":90,"p90":180},{"dimension":"4","metricKey":"flow.triage_to_pia","p50":90,"p75":120,"p90":240},{"dimension":"5","metricKey":"flow.triage_to_pia","p50":90,"p75":135,"p90":240},{"dimension":"","metricKey":"flow.seen_to_first_order","p50":15,"p75":25,"p90":45},{"dimension":"","metricKey":"flow.seen_to_decision_no_tests","p50":30,"p75":45,"p90":90},{"dimension":"","metricKey":"flow.testing","p50":120,"p75":160,"p90":240},{"dimension":"","metricKey":"flow.results_to_reassessment","p50":30,"p75":45,"p90":90},{"dimension":"","metricKey":"flow.boarding","p50":360,"p75":720,"p90":1440},{"dimension":"","metricKey":"flow.discharge_to_cleared","p50":20,"p75":30,"p90":60},{"dimension":"","metricKey":"flow.cleared_to_departure","p50":5,"p75":10,"p90":20}] | array | Default flow benchmarks (Appendix B.4). | ## Related [#related] * [Wait estimates](/patients/wait-estimates) * [Why wait estimates should under-promise](https://edflow.space/learn/why-wait-estimates-should-under-promise) # Feedback (https://docs.edflow.space/admin/analytics/feedback) Patient feedback analytics in EDFlow: the five-question post-visit survey, the in-visit pulse, response rates, top-box shares, comments hidden when they may contain personal information, and family feedback. ![Feedback: patient and family ratings over time and comments, with possible personal details hidden until revealed.](https://docs.edflow.space/screenshots/web/admin-feedback.png) ## The survey [#the-survey] After leaving, patients answer five questions (one submission per visit): 1. If you had a long wait, were you told why? 2. How often did the people caring for you explain things in a way you could understand? 3. Did EDFlow help you know what was happening during your visit? 4. Did you get enough information about what to do if you were worried about your health after you left? (home departures only) 5. Overall, how would you rate your care in the emergency department? (0 to 10) Plus an optional comment and, where the site runs a study, a separate research-contact consent. During the visit, a **pulse** card asks "How well are we keeping you informed?". ## What's on the page [#whats-on-the-page] * Response rate, distribution and trend per question, top-box share. * Filters by language, age band and departure kind. * **Comments**: comments the scrubber flags as possibly containing personal information stay hidden until someone clicks **Show** (audited). Managers can redact a comment permanently. * Family feedback (three questions, release 1.1) in its own tab. ## Related success metrics [#related-success-metrics] M-01 (told why about a long wait), M-02 (helped a lot), M-03 (top box), M-04 (information for after leaving). See [For hospitals](/start/for-hospitals). # Flow and bottlenecks (https://docs.edflow.space/admin/analytics/flow-and-bottlenecks) Find where ED time is lost with EDFlow: flow segments from arrival to departure, the per-visit bottleneck flag, the period bottleneck ranking by excess minutes, heatmaps, trends and capacity drivers. ![Flow and bottlenecks: median time per segment of the visit, with the slowest segments flagged and ranked.](https://docs.edflow.space/screenshots/web/admin-flow-bottlenecks.png) ## Segments [#segments] Every visit is split into segments: | Segment | From | To | Patients see an estimate | | ------------------------------ | ------------------- | ---------------------------------------- | ----------------------------- | | S1 Arrival → triage | Arrival | Triage | Yes | | S2 Triage → seen | Triage | Seen | Yes, by stream and CTAS | | S2n Triage → PIA (NACRS) | Triage | PIA | No | | S3 Seen → first test | Seen | First order | No | | S3b Seen → decision, no tests | Seen | Decision | No | | S4 Testing | Seen or first order | Last result complete before the decision | No | | S5 Results → seen again | Results complete | Reassessment or decision | Yes | | S5o Observation | Start | End | The plan only | | S6 Decision → cleared to leave | Decision (home) | Cleared, or departure | Yes | | S6c Cleared → left | Cleared | Departure | No | | S6a Boarding | Decision (admit) | Departure | Only where the site allows it | | S7 Consult | Requested | Specialist seen | Yes | ## The bottleneck flag (per visit) [#the-bottleneck-flag-per-visit] For each segment, EDFlow divides its duration by the p90 for its start bucket (site, weekday, hour). The visit's bottleneck is the segment with the highest ratio, when that ratio is 1 or more. The board's **Bottleneck** column shows it, and **Time in stage** is toned typical (below p75), longer (p75 to p90) or beyond (above p90). ## The bottleneck ranking (period) [#the-bottleneck-ranking-period] For each segment, excess minutes per visit = the sum of time beyond each visit's bucket p50, divided by the number of visits. The top segment is labelled **Main bottleneck**. Capacity drivers (boarder-hours, occupancy, physician hours) are shown next to it, so access block isn't read as an ED problem. ## Charts [#charts] * p50 and p90 for each segment against its benchmark. * Heatmaps (hour × weekday, 7 × 24 cells) for arrivals, door-to-doctor, LOS and LWBS rate. * Weekly trends for door-to-doctor, LOS by disposition, results to reassessment and boarding. * A histogram for each segment, and a breakdown by CTAS group and disposition. ## Using it well [#using-it-well] * Start with the main bottleneck and its capacity drivers. * Results → seen again (S5) is often where a "Seen again" habit or a results-back digest helps. * Compare with the pre-pilot baseline using the same definitions. ## Related [#related] * [Analytics conventions](/admin/analytics) * [Measuring ED flow](https://edflow.space/learn/measuring-ed-flow) on the product site # Analytics (https://docs.edflow.space/admin/analytics) EDFlow analytics conventions and every metric definition: time zones, T0, percentiles, small-cell suppression, Ontario LOS groups, filters, annotations and exports, generated from the same definitions the computations use. EDFlow analytics follow Ontario QIP and NACRS definitions. Every chart's info button opens the same definition object the computation imports, so the numbers and their definitions can't drift apart. ![Admin overview: today's volume, median waits by segment, open requests, feed health and the go-live checklist.](https://docs.edflow.space/screenshots/web/admin-overview.png) ## Conventions [#conventions] * **Time zone**: the site's. Days start at local midnight; weekday and hour buckets are local and safe across daylight-saving changes. * **Which period a visit belongs to**: the period containing its T0, the earlier of arrival and triage. * **Always excluded**: cancelled visits, training visits, demo sessions (for adoption). * **Percentiles**: linear interpolation, completed intervals only, whole minutes on screen. * **Small cells**: any number from fewer than 5 visits shows "—" ("Fewer than 5 visits"). * **Disposition groups**: discharged; admitted (admit, observation); transferred; left (without being seen, before treatment complete, against advice); other. * **Ontario LOS groups**: admitted; non-admitted CTAS 1–3; non-admitted CTAS 4–5, with site targets (by default 8 h, 8 h and 4 h at p90). | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | analytics.clinicianMetrics | false | boolean | Clinician-level metrics (EHR §12). (Reduces privacy) | | analytics.namedClinicianMetrics | false | boolean | Named clinician metrics; requires clinician metrics (D-20). (Reduces privacy) | | analytics.nurseMetrics | false | boolean | Nurse self-view metrics. (Reduces privacy) | | analytics.minCell | 5 | 5–20 count | Small-cell suppression threshold. (Reduces privacy) | | analytics.ontarioTargets.admitted | 480 | 30–2880 minutes | Ontario target, admitted (D-48). | | analytics.ontarioTargets.nonAdmittedHigh | 480 | 30–2880 minutes | Ontario target, non-admitted CTAS 1–3. | | analytics.ontarioTargets.nonAdmittedLow | 240 | 30–2880 minutes | Ontario target, non-admitted CTAS 4–5. | | analytics.ontarioTargets.emsOffload | 30 | 5–240 minutes | Ontario target, EMS offload. | ## Filters [#filters] Site, date range (today to 12 weeks or custom), compare with the previous period, weekday, hour range, CTAS group, Ontario LOS group, zone, stream, disposition, arrival mode, language (including EHR preferred languages), age band. Filters live in the URL, so a link reproduces the view. ## Annotations [#annotations] Add a dated note ("Pilot start", "HIS downtime") and it appears on every time-series chart for the site. Annotations can exclude their dates from benchmarks. ## Exports [#exports] With `analytics.export`, every chart exports its de-identified aggregate as CSV, with suppression applied. Every export is audited. See [Reports and exports](/admin/reports-and-exports). ## Accessibility [#accessibility] Every chart has a **Show as table** alternative and direct labels; colour is never the only encoding. ## Pages [#pages] | Page | Question it answers | | ------------------------------------------------------------- | -------------------------------------------------------- | | [Flow and bottlenecks](/admin/analytics/flow-and-bottlenecks) | Where is time being lost? | | [Test turnaround](/admin/analytics/test-turnaround) | How long does each test take here, by hour? | | [Requests](/admin/analytics/requests) | How quickly do we respond, and to what? | | [Clinician metrics](/admin/analytics/clinician-metrics) | Per-physician step times, with governance | | [Feedback](/admin/analytics/feedback) | What do patients say? | | [Adoption and equity](/admin/analytics/adoption-and-equity) | Who uses EDFlow, and who doesn't? | | [Codes and delays](/admin/analytics/codes-and-delays) | How often do codes happen, and what do they do to waits? | | [Estimate quality](/admin/analytics/estimate-quality) | Are the estimates patients see honest? | | [Ask your data](/admin/analytics/ask-your-data) | Plain-language questions, where enabled | ## Key metrics [#key-metrics] ## Flow segments [#flow-segments] ![Metric definitions: each metric with its formula, start and end events, and exclusions.](https://docs.edflow.space/screenshots/web/admin-definitions.png) The full definitions, with formulas, inclusions and exclusions, source fields and references, are on **Analytics → Definitions** in the admin, readable by any staff role. # Request analytics (https://docs.edflow.space/admin/analytics/requests) Request analytics in EDFlow: volume by type, zone and hour, time to first response and to resolve, urgent in-person response, service-level compliance, escalations and alerts per nurse per hour. ![Request analytics: requests by type and hour, time to acknowledge and escalations.](https://docs.edflow.space/screenshots/web/admin-requests-analytics.png) ## What's on the page [#whats-on-the-page] * Volume by type, zone, shift and hour. * Time to first response and time to resolve, p50 and p90, by priority and type. * **Urgent time to an in-person response**: "Handled in person", or "Going now" followed by it. Pilot target: p90 5 min or less; first response within 2 min. * Service-level compliance by priority (pilot target 90% or more). * Escalations, reminders per request, cancellation rate. * **Alerts per nurse per hour**: sounds and push per on-shift nursing hour, by role and shift, reviewed monthly with nursing leadership. * A de-identified list of urgent requests: time, zone, first response, in-person response, escalation level. ## Definitions [#definitions] * **First response** is an acknowledgement, "Going now" or "Can't go". A request resolved without one uses the resolve time. * Excluded: FYI items, cancelled, duplicate, and closed at departure without a response. * **Compliance** counts a request closed at departure without acknowledgement as a breach only if it was already past its target. ## Reading it [#reading-it] * Many comfort requests in one zone: consider a support-pool worker on that shift. * Slow high-priority response in the waiting room: check the triage pool assignments. * Rising alerts per nurse: check routing and whether low requests are being escalated. ## Related [#related] * [Requests](/staff/requests) * [Request types](/admin/settings/request-types) # Test turnaround (https://docs.edflow.space/admin/analytics/test-turnaround) Test turnaround analytics in EDFlow: order-to-result and collection-to-result times per test, hour-by-weekday heatmaps, bucket coverage, the estimate level patients get, and the benchmark job. ![Test turnaround: median and 90th percentile time per test and step, by hour of day.](https://docs.edflow.space/screenshots/web/admin-test-turnaround.png) ## The table [#the-table] Each test type: volume, order-to-result p50, p75 and p90, collection-to-result p50, the share over the catalogue default, and n. Priority classes (stat, routine) are separate. ## One test [#one-test] Select a test to see: * its **hour × weekday heatmap** of p50; * **bucket coverage**: samples per weekday-hour bucket, with buckets under the minimum highlighted; * the **level** patients get per bucket (same weekday and hour; hour ± 1; weekday or weekend; any day at that hour; any time; the catalogue default); * the catalogue default next to the observed values; * the benchmark job's last run, next run and duration. ## What's excluded from samples [#whats-excluded-from-samples] Cancelled and recollected orders, timed collections (kept separately), intervals spanning a closed service or recorded downtime, training and demo visits, dates inside "exclude from benchmarks" annotations, and values above the cap. ## When the numbers look wrong [#when-the-numbers-look-wrong] * A test far over its default may be mapped to the wrong code: check [Unmapped codes](/admin/integration/unmapped-codes) and the catalogue. * An imaging modality with long times at night may need service hours configured, so patients see when it opens instead of an estimate. ## Related [#related] * [Tests and benchmarks](/admin/settings/tests-and-benchmarks) * [Estimate quality](/admin/analytics/estimate-quality) # Data issues (https://docs.edflow.space/admin/integration/data-issues) Work the EDFlow Report a data problem queue: what staff report, resolving or closing reports, and how data issues feed the 98% milestone agreement go-live gate. Staff report wrong information from the patient page with **Report a data problem**. The reports land on the integration health page. ![Data issues: problems staff reported with what the app shows, with status and the milestone agreement rate.](https://docs.edflow.space/screenshots/web/admin-data-issues.png) ## What's in a report [#whats-in-a-report] The visit's EDFlow id, what is wrong (stage, test, care team, location, time), and when. No free text about the patient. ## Working a report [#working-a-report] 1. Open the event log for the visit's events around that time. 2. Find the cause: a missing event, an unmapped code, a wrong mapping, an engine filter, or a staff override. 3. Fix it (mapping profile, catalogue, engine routing) and replay dead letters if needed. 4. **Resolve**, or **Not an issue** with a reason. ## The agreement gate [#the-agreement-gate] Before go-live, a 14-day shadow run compares EDFlow's milestones with the site's audit sample; at least 98% must agree. Open data issues and their causes are the usual reasons for disagreement. After go-live, keep the queue near zero. ## Related [#related] * [Go live](/developers/go-live) * [Overrides and corrections](/staff/charge/overrides-and-corrections) # Dead letters (https://docs.edflow.space/admin/integration/dead-letters) Handle EDFlow dead letters: buffered events that expired and processing errors, viewing and revealing payloads (audited), replaying after a fix, discarding, and bulk replay. A dead letter is an event EDFlow couldn't apply: a buffered event whose visit never arrived within 6 hours, or a processing error. ![Dead letters: events that could not be processed, with the error and a Replay button.](https://docs.edflow.space/screenshots/web/admin-integration-dead-letters.png) ## Each row [#each-row] Reason, source, type and received time. The integration on-call is alerted for every new dead letter. ## Actions [#actions] | Action | Notes | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | View | The allow-listed projection, as in the event log | | Reveal payload | Shows the full payload. Audited, and counts toward the privacy office's monitoring rule A-1 | | Replay | After you've fixed the cause (for example mapped a code or the arrival came in). Runs through the normal pipeline; running it twice is safe | | Discard | With a reason | | Bulk replay | For many dead letters with the same cause | ## Common causes [#common-causes] * The arrival was never sent (check the engine's ADT routing). * A roster was quarantined by the circuit breaker. * An identifier change the pipeline couldn't handle (for example a merge sent in an unexpected shape). Dead letters are kept for 30 days. ## Related [#related] * [Engine configuration](/developers/engine-configuration) * [Event log](/admin/integration/event-log) # Event log (https://docs.edflow.space/admin/integration/event-log) Read the EDFlow EHR event ledger: accepted, duplicate, buffered, ignored and rejected events, error codes, the allow-listed payload view, and validating a payload as a dry run. The event log is a searchable view of every event received in the last 30 days. ![Event log: each inbound event with type, status (accepted, duplicate, buffered, ignored or rejected) and time.](https://docs.edflow.space/screenshots/web/admin-integration-events.png) ## Columns [#columns] Received time, source, event id (exact search), type, EDFlow encounter id, status and error code. ## Statuses [#statuses] | Status | Meaning | | --------- | ----------------------------------------------------------------------------------------------------------------------------- | | Accepted | Applied to the visit | | Duplicate | Same event id already accepted; nothing changed (safe retries) | | Buffered | Arrived before its visit existed (for example an order before the arrival); held up to 6 hours, then applied or dead-lettered | | Ignored | Valid but not applied, for example an event for an archived visit | | Rejected | Refused with an error code. See [Errors](/developers/errors) | ## The payload view [#the-payload-view] The payload is shown through an allow-list: names, the family initial and the chief complaint appear only as `[present]`; dates of birth never appear. Your role sees EDFlow ids only and can't open patient pages. ## Validate a payload [#validate-a-payload] Paste normalized JSON, a FHIR Bundle or an HL7 v2 message and see the events it would produce and any errors, from the same validator as `POST /ehr/v1/validate`. Nothing is stored. Use only synthetic or test messages. ## Common rejections [#common-rejections] | Code | Usual cause | | -------------------- | -------------------------------------------------------------------------------------------------------------------- | | Signature invalid | Wrong key version, a body changed after signing, or the engine signed at queue time instead of send time | | Clock skew | The engine's clock is more than 5 minutes off | | Prohibited field | The event contains a field EDFlow never accepts (for example a result value). Nothing is stored beyond the rejection | | Unknown site or type | The source isn't allowed to send for that site or event type | ## Related [#related] * [Events](/developers/events) * [Dead letters](/admin/integration/dead-letters) # Integration analysts (https://docs.edflow.space/admin/integration) EDFlow for integration analysts: feed health states and what each audience sees, per-source status, heartbeats, event counts, rejections by error code, roster discrepancies and feed alerts. The integration analyst keeps the EHR feed healthy. You see EDFlow ids, event types and statuses, never patient pages or names. ![Integration health: the feed state, last event and heartbeat, error rates and alerts.](https://docs.edflow.space/screenshots/web/admin-integration-health.png) ## Feed health [#feed-health] | State | Condition | Patients and family | Staff | | ------- | -------------------------------------------------------------------- | ---------------------------------- | ---------------------------------------------------------------- | | Manual | No active EHR source | Nothing extra | "Manual mode" | | Healthy | An event or heartbeat in the last 5 minutes | "Live" | "EHR live" | | Delayed | Nothing for 5 minutes | "Updates may be delayed" | Amber chip and banner | | Down | Nothing for 15 minutes, every source disabled, or the site suspended | Feed-down banner, frozen estimates | Red banner with links to the manual console and the downtime kit | | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | feed.delayedAfterMinutes | 5 | 1–60 minutes | Feed is "delayed" after this silence (F-16.1). | | feed.downAfterMinutes | 15 | 2–240 minutes | Feed is "down" after this silence. | When the feed goes down, the integration roles and the integration on-call address get push and email alerts. Charge nurses see the banner without a push. ## Per source [#per-source] * Status (testing, active, disabled), kind and EHR system. * Feed state, last event, heartbeat age and the queue depth the engine reports. * Events per minute over the last hour. * Counts over 24 hours: accepted, duplicate, buffered, ignored, rejected, with rejections by error code. * The last roster and its discrepancies (missing arrivals, auto-closed visits). * Alert recipients. * Data issues staff reported. See [Data issues](/admin/integration/data-issues). ## Your pages [#your-pages] | Page | Use it to | | ------------------------------------------------------- | ------------------------------------------------------------------------- | | [Sources and keys](/admin/integration/sources-and-keys) | Register a source, rotate keys, disable a source | | [Event log](/admin/integration/event-log) | Find an event and see why it was accepted or rejected; validate a payload | | [Unmapped codes](/admin/integration/unmapped-codes) | Map test and location codes | | [Dead letters](/admin/integration/dead-letters) | Replay events that expired or failed | | [Data issues](/admin/integration/data-issues) | Staff reports of wrong information | | [Simulator](/admin/integration/simulator) | Sandbox and showcase only | | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | integration.alertEmails | [] | array | Recipients of feed and integration alerts (≤ 10). (Reduces privacy) | | integration.api.reads | false | boolean | Allows encounters, care-team, requests and tasks reads at this site (F-34.4). (Reduces privacy) | | integration.api.includeCodeArea | true | boolean | Code alerts in the API include the area label. (Reduces privacy) | | integration.requestWriteback | false | boolean | Allows requests:write. (Reduces privacy) | | integration.webhooks.enabled | false | boolean | Outbound webhook deliveries for this site. (Reduces privacy) | | integration.storeVisitNumberEncrypted | false | boolean | Exposes externalRef on encounters and webhooks. (Reduces privacy) | | integration.rosterMaxClose | 5 | 1–50 count | Roster circuit breaker: encounters one roster may close. (Reduces privacy) | | integration.rosterMaxClosePct | 20 | 5–50 percent | Roster circuit breaker: share of the census. (Reduces privacy) | ## Related [#related] * [Developers](/developers) for engine teams * [Go live](/developers/go-live) # Simulator (https://docs.edflow.space/admin/integration/simulator) The EDFlow EHR simulator for the sandbox and showcase: fire the next event for a visit, run scripted scenarios, autopilot a synthetic department, choose the transport (direct, signed webhook, HL7 v2, FHIR) and control the feed. The simulator creates synthetic EHR traffic. It exists only in synthetic deployments (development, the showcase and the integration sandbox). It isn't built into production or customer test, and every simulator function refuses to run there. ![EHR simulator (sandbox and showcase only): scenarios, arrival rate and the events it will send.](https://docs.edflow.space/screenshots/web/staff-simulator.png) ## Panels [#panels] | Panel | What it does | | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Patients | Pick a simulated visit and fire the next plausible event: triage, assign a physician or nurse, order a test, advance a test, result all tests, reassess, consult, disposition, bed steps, depart, left without being seen. **New arrival** creates a fictional patient and prints a card | | Scenarios | Scripted runs at 1×, 5× or 20× with progress, pause and cancel | | Autopilot | A continuous synthetic department with an arrival multiplier (0.5× to 3×) and speed. Stops after 2 hours unless renewed; at most 45 simulated visits per site | | Transport | **Direct**, or **Signed webhook** to `/ehr/v1/events` with the sandbox source key (exercising signatures, idempotency and per-event results), or send as **HL7 v2** or **FHIR** to demonstrate the adapters | | Feed controls | Heartbeat on or off (delayed after 5 min, down after 15), send a census or a roster, send 50 duplicates to show idempotency | | Log | The last 200 events with their ingest status | | Reset | Reset the showcase data, with a typed confirmation. Refused if any site is pilot or live or any real source is active | ## Scenarios [#scenarios] Walk-in discharge; chest pain admitted; abdominal CT with contrast; child with fever and a urine sample; left without being seen after a long wait; left after being seen; assigned then released; serial troponin; observation after anaphylaxis; resuscitation with paused updates; a code with a named patient; duplicate registration; discharge reversal; patient merge; paged Code Blue; staff-only Code White; feed outage with backfill; surge; unknown trauma patient. ## Related [#related] * [Sandbox](/developers/sandbox) * [Demo](/start/demo) # Sources and keys (https://docs.edflow.space/admin/integration/sources-and-keys) Register an EHR source in EDFlow, edit its versioned mapping profile, reveal a signing key once, rotate with two active key versions, and disable a source in an emergency. A **source** is one sender of EHR events for your site, usually one integration-engine channel. It signs every request to `/ehr/v1/*` with an HMAC key. (API clients for the REST API are managed in the developer portal; see [Credentials](/developers/credentials).) ![Sources and keys: registered sources with status, key versions and last use, and Rotate and Disable.](https://docs.edflow.space/screenshots/web/admin-integration-sources.png) ## Register a source [#register-a-source] ### Describe it [#describe-it] Id, kind, EHR system, the site codes and event types it may send, and the allowed source kinds. ### Answer the mapping questionnaire [#answer-the-mapping-questionnaire] For example "Do ED physicians read their own X-rays?". The answers set result thresholds and other behaviour. ### Add the mapping profile [#add-the-mapping-profile] A versioned JSON document (locations, test codes, practitioner ids, NPO diet codes, disposition codes, care-flag codes, consult services…), validated against its schema. Every edit creates a new version with a diff against any earlier one. See [Mapping profiles](/developers/mapping-profiles). ### Add a key version [#add-a-key-version] Needs your password and code again. The key (64 hex characters) is revealed **once** with a Copy button, then never again. Give it to the engine team through your secure channel. _Screenshot pending: admin-integration-key-reveal_ ## Rotate a key [#rotate-a-key] A source has at most **two** active key versions. To rotate: 1. **Add key version** (the new key is revealed once). 2. The engine team switches to the new key; the engine signs at send time, so queued messages use the new key. 3. Watch signature failures fall to zero on the new version, then **Retire** the old one. A third version is refused until you retire one. ## Emergency disable [#emergency-disable] **Disable source** makes every request from it fail at once with 403. Use it when a key may have leaked or the feed is sending wrong data. Re-enable after the problem is fixed and the key rotated. ## The master secret [#the-master-secret] A runbook panel explains rotating the deployment's master webhook secret. It invalidates every source key, so every source must be re-issued. Plan it with every engine team. ## Audit [#audit] Adding, revealing, retiring keys and disabling sources are audited and alert the integration analyst and the manager. ## Related [#related] * [Authentication](/developers/authentication) * [Engine configuration](/developers/engine-configuration) # Unmapped codes (https://docs.edflow.space/admin/integration/unmapped-codes) Map unmapped test and location codes from the EHR feed in EDFlow: map to a catalogue test, create an entry or ignore, the zero-unmapped go-live gate, and AI mapping suggestions. A code the feed sends that isn't in the catalogue or the mapping profile shows up here. Patients see an unmapped test as "Other test" until you map it. ![Unmapped codes: test and location codes the EHR sent that have no mapping yet, with suggested mappings to review.](https://docs.edflow.space/screenshots/web/admin-integration-unmapped.png) ## Each row [#each-row] Code system, code, display text, source, first and last seen, count and affected visits. ## Actions [#actions] * **Map to an existing test**: existing visits' "Other test" rows are relabelled within a minute. * **Create a catalogue entry**: with plain names, group, flags and default benchmarks. See [Tests and benchmarks](/admin/settings/tests-and-benchmarks). * **Ignore**: for codes that shouldn't appear to patients (for example internal orders). Location codes map to beds in [Zones, beds and shifts](/admin/settings/zones-beds-and-shifts). ## Go-live gate [#go-live-gate] The page shows "0 unmapped codes in the last 30 days" when you're there. It's one of the go-live gates. ## Mapping suggestions [#mapping-suggestions] Where the site turns on the mapping assistant, each row can show a suggested catalogue entry with the reason, from the code, its display text and the catalogue. It's only a suggestion: nothing is mapped until you accept it. In customer test and live, the privacy office must approve its use first, because feed samples are treated as real data. ## Related [#related] * [AI mapping assistant](/developers/ai-mapping-assistant) * [Mapping profiles](/developers/mapping-profiles) # After your visit (https://docs.edflow.space/patients/after-your-visit) Your going-home summary, follow-up dates you can add to your calendar, the summary link, the short survey, and when your access to EDFlow ends after you leave the emergency department. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. When you're getting ready to go home, your care team may publish a going-home summary. You can read it on your phone and keep it for a while after you leave. ## Your going-home summary [#your-going-home-summary] When it's ready, you see Your going-home information is ready. Tap **Read your summary**. ![After-visit summary published by the care team: what to do at home, when to come back, follow-up, and buttons to print or add to a calendar.](https://docs.edflow.space/screenshots/web/patient-summary.png) The summary has these parts: 1. **About your visit.** A short note from your care team, if the hospital uses it. 2. **Your medicines.** Only at some hospitals. Otherwise: Your printed instructions and your hospital record have your medicine list. 3. **Activity and eating.** 4. **Follow-up.** Who to see and when. Tap **Add to calendar** to save it. 5. **When to come back.** Signs to watch for, and: Call 911 in an emergency. For health advice, call Health811 at 811. 6. **Helpful resources.** 7. **Questions after you leave.** This summary helps you remember. The papers from your care team are your official record. Before it's ready, you see: Your care team is preparing your going-home information. ## Keep a copy [#keep-a-copy] * **Print** it. The printed page uses large text. * **Share** it with your phone's share button. This sends a special link, not the summary itself. * **Text me a link** or **Email me a link**, from the main phone, where the hospital allows it. We check the number or address with a 6-digit code first. ## The summary link [#the-summary-link] The link opens your summary on any phone or computer. It asks for your date of birth first. Some hospitals ask for your visit code instead. _Screenshot pending: summary-link_ * The link only shows your summary. Nothing else about your visit. * After 5 wrong tries, it locks for 15 minutes. After 10 wrong tries, it stops working. * It stops working when your access ends. ## Tell us how it went [#tell-us-how-it-went] After you leave, we ask five short questions about your visit. It takes about 2 minutes. You can add a comment. Please don't include names or health details. _Screenshot pending: patient-feedback_ You can give feedback once per visit. ## After you leave the department [#after-you-leave-the-department] Your visit stays on your phone, read-only, for a while. By default, that's 72 hours after you go home. You can still read your summary and give feedback. You can't send requests. _Screenshot pending: patient-read-only_ If you're staying in the hospital, the screen says you're now on your unit and your care continues there. If the hospital has a patient portal, there's a link to it. ## When access ends [#when-access-ends] ![Visit ended screen for a patient who is staying in hospital: live updates in this app have ended and the care team on the unit will keep you informed.](https://docs.edflow.space/screenshots/web/patient-visit-ended.png) You see: Your visit updates have ended. If you need care again, come back or call 911 in an emergency. For health advice, call Health811 at 811. The app deletes your visit from your phone. ## If you need care again [#if-you-need-care-again] If this is an emergency, call 911. For health advice, call Health811 at 811. ## Related [#related] * [If you feel worse](/patients/if-you-feel-worse) * [Privacy](/patients/privacy) # App or browser (https://docs.edflow.space/patients/app-or-browser) Follow your visit in your phone's browser with nothing to install, or use the EDFlow app. What the first screens say, how notifications work, and what your lock screen shows. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. You can follow your visit in your phone's web browser. You don't have to install anything. The app does the same things, and adds a few extras. ## Which one should I use? [#which-one-should-i-use] | | Browser | App | | ----------------------------------- | ---------------------------------- | --------------------------------------------- | | To start | Scan the QR code with your camera | Install the app, then scan inside it | | See your visit, tests and care team | Yes | Yes | | Ask your care team | Yes | Yes | | Share with family | Yes | Yes, with your phone's share sheet | | Updates when the screen is off | Text messages, if you turn them on | Notifications, or text messages if you prefer | | Lock with Face ID or fingerprint | No | Yes | Both clear your visit from the phone when your access ends. ## The first screens [#the-first-screens] The first time you sign in on a phone, you see three short screens. ### What you'll see [#what-youll-see] Your step in the visit, your care team, your tests and the usual waits, and notices when things slow down. ### What you won't see [#what-you-wont-see] You won't see your results or your place in line. You'll hear about your results from your care team, not in this app. ### Safety [#safety] EDFlow isn't for emergencies. If you feel worse, tell a staff member right away. Don't wait for this app. You can't skip this screen. #### Web ![Welcome screens: what you will see in the app, what you will not (no results, no diagnosis), and that it is not an emergency channel.](https://docs.edflow.space/screenshots/web/patient-welcome.png)#### iPhone _Screenshot pending: mobile-onboarding-welcome__Screenshot pending: mobile-onboarding-safety_#### Android _Screenshot pending: mobile-onboarding-welcome__Screenshot pending: mobile-onboarding-safety_ On the web, the main phone can then choose to get text updates. You type your phone number, then a 6-digit code we text you. You can say **Not now**. ## Notifications in the app [#notifications-in-the-app] Before your phone asks for permission, the app explains what we will send: > We'll let you know about the big steps in your visit. The lock screen only says: "You have a new update." _Screenshot pending: mobile-notifications-primer_ Your lock screen never shows your name, your tests or the hospital. It only says You have a new update. You can choose a more detailed message in [Settings](/patients/settings). ## Installing the app [#installing-the-app] Search for EDFlow in the App Store or Google Play. You need iOS 17 or later, or Android 8 or later. See [Devices](/start/devices). ## Related [#related] * [Sign in](/patients/sign-in) * [Updates and notifications](/patients/updates-and-notifications) * [Privacy](/patients/privacy) # Ask the assistant (https://docs.edflow.space/patients/ask-the-assistant) Ask EDFlow questions about your own visit, like how long a step usually takes, who your nurse is, or where the washroom is. What the assistant can and can't do, and how it handles your messages. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. Some hospitals offer an assistant that uses AI to help you find information about your visit. It uses the same information you already see in EDFlow. Your hospital may have turned it off. ![The patient assistant, labelled as AI, answering a question about what the current step means, with the reminder to tell staff in person if you feel worse.](https://docs.edflow.space/screenshots/web/patient-assistant.png) ## What you can ask [#what-you-can-ask] Tap **Ask** at the top of the Visit screen. You can type, tap a suggestion, or speak. For example: * **How long will this take?** * **Are my tests back?** * **Who is my nurse?** * **Where is the washroom?** Answers come as cards from your own visit screens, with a few connecting words. If it would help, the assistant can offer to send a request to your care team. It never sends anything until you tap **Send**. ## What it will never do [#what-it-will-never-do] The assistant can't give medical advice. It won't: * explain your results. It says: I can't see or explain test results. Your care team will talk with you about them. * check symptoms. It says: I can't check symptoms or give medical advice. If you feel worse, tell a staff member now. * give advice about medicines. It says: I can't give advice about medicines. Please ask your nurse or doctor. * tell you whether you can eat or drink. It says: I can't answer that, but your nurse can. Please wait for their answer before you eat or drink. * show your place in line: I can't show a place in line. The sickest people are always seen first, so the order can change. ## If you feel worse [#if-you-feel-worse] The **I feel worse** button stays on the screen. If you write that you feel much worse, the assistant shows what to do right away, even offline, and can alert your care team. If you write about hurting yourself, it alerts your care team at once and says: Please tell a staff member right now. You can also call or text 9-8-8 at any time to talk with someone. ## Before you use it [#before-you-use-it] The first time, you see **Before you ask**. It explains that: * answers come from AI and can be wrong; * your care team doesn't read the chat, but messages about feeling much worse or hurting yourself alert them; * a small safety team may review some conversations; * your message is processed in the United States by companies that keep nothing, and the hospital keeps the conversation for 7 days. Please don't share details like your health card number. If you do, the assistant hides them. ## Labels you may see [#labels-you-may-see] * Written with AI help and reviewed by your care team. * Translated by machine from your care team's message. ## Speaking instead of typing [#speaking-instead-of-typing] Tap **Speak**. In the app, your phone turns speech into text on the phone itself. You always see the text first and tap to send it. Voice on the web is not available at every hospital. ## Hiding the assistant [#hiding-the-assistant] In [Settings](/patients/settings), tap **Hide the assistant**. To delete a conversation, tap **Clear conversation**. ## Related [#related] * [Asking your care team](/patients/requests) * [AI governance](/security/ai) # Care team (https://docs.edflow.space/patients/care-team) Who is looking after you in the emergency department: your doctor, a doctor in training, your nurse and specialists, and why some names show only a first name. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. The Care team screen shows the people looking after you, by name and role. It updates when someone new joins your care, for example at a shift change. ![Care team screen: the nurse with an opted-in photo, the doctor assigned, and their roles, with first names only where the hospital chooses.](https://docs.edflow.space/screenshots/web/patient-care-team.png) ## Who you may see [#who-you-may-see] | Section | Who | What they do | | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | **Your doctor** | A doctor, a nurse practitioner or a physician assistant | Leads your care in the emergency department. If you stay in the hospital, this becomes the admitting team. | | **Doctor in training** | A resident | A doctor who is finishing specialty training. They work with your doctor. | | **Your nurse** | Your nurse | Looks after you on this shift. | | **Specialist** | A specialist | Another kind of doctor your care team asked to see you. | | **Also caring for you** | For example a respiratory therapist, social worker, pharmacist, support worker or student | Helps with parts of your care. Some hospitals don't show this section. | ## Names and photos [#names-and-photos] * Doctors are shown with their full name, for example "Dr. Demo Elm". * Other staff are shown with a first name and the first letter of their last name, or only a first name. The hospital chooses. * Photos appear only when the staff member chose to share one and the hospital allows it. * Some staff may not appear at all, for their own safety or privacy. * There are never phone numbers or email addresses. To reach your care team, use [requests](/patients/requests) or ask in person. ## When someone changes [#when-someone-changes] When your nurse or doctor changes, you see a note for two hours, for example: "Your nurse changed at 7:00 p.m." with the name of your new nurse. ## Before anyone is assigned [#before-anyone-is-assigned] You see: Your care team will show here once they're assigned. Until then, the triage nurse is looking after you. ## Related [#related] * [Your visit](/patients/your-visit) * [Asking your care team](/patients/requests) # Delays (https://docs.edflow.space/patients/delays) What the delay notice and the busy-department banner in EDFlow mean, why the emergency department sometimes slows down, and what the notices never tell you. > **Why does this happen?** > > Someone in the emergency department needs urgent care right now, so part of our team is with them. This may add time to your wait. We haven't forgotten you, and we'll be with you as soon as we can. If you feel worse, tell a staff member right away. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. Sometimes your wait gets longer for reasons you can't see. EDFlow tells you when that happens, in calm words. ## "Your wait may be longer" [#your-wait-may-be-longer] When someone in the department needs urgent care, part of the team goes to help them. If this is likely to delay your care, you see a notice: > **Your wait may be longer** > > Someone in the emergency department needs urgent care right now, so part of our team is with them. This may add time to your wait. We haven't forgotten you, and we'll be with you as soon as we can. > > If you feel worse, tell a staff member right away. _Screenshot pending: patient-code-delay_ Tap **OK** to close it. The notice stays as a banner at the top of your Visit screen until the delay ends, and in your updates. ### Why does this happen? [#why-does-this-happen] The emergency department always cares for the sickest people first. When someone arrives very unwell, doctors and nurses may need to leave other work for a while. ### What the notice never tells you [#what-the-notice-never-tells-you] * Who needs help, or why. * Where in the department it is happening. * How many people are involved, or how long it will take. If another delay happens within 30 minutes, the same notice is updated. You won't get a second pop-up. ## "It's busier than usual" [#its-busier-than-usual] When the department is busy, a banner appears at the top of your screen: > It's busier than usual today. Waits may be longer. _Screenshot pending: patient-busy-banner_ When it is very busy, the banner says: It's very busy right now. We see the sickest people first, so some waits will be long. We're sorry for the wait. Estimates also say that waits may be longer. ## What to do [#what-to-do] * Stay where staff can find you. * If you feel worse while you wait, tell a staff member right away. * If you need to step out, tell your care team with a request first. See [Asking your care team](/patients/requests). ## Related [#related] * [Wait estimates](/patients/wait-estimates) * [If you feel worse](/patients/if-you-feel-worse) * [Updates and notifications](/patients/updates-and-notifications) # Hospital info (https://docs.edflow.space/patients/hospital-info) Find washrooms, food, Wi-Fi, parking, visitor rules, interpreters and answers to common questions for the hospital you're in, and read education sheets approved by its care team. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. The Hospital info screen has practical information about the hospital you're in. The hospital writes it, in English and French. Open it from the menu on the Visit screen. ![Hospital information: finding your way, Wi-Fi, parking, the visitor policy and common questions.](https://docs.edflow.space/screenshots/web/patient-hospital-info.png) ## What's in it [#whats-in-it] | Section | What you'll find | | --------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **How the emergency department works** | A short card for each step of a visit. Why the sickest people are seen first, what the first check by a nurse is, why tests take time, what waiting for a bed means. | | **Around the department** | Washrooms, water, food and the cafeteria with hours, charging stations, the pharmacy, a quiet room, exits. Directions in words, and a map when the hospital has one. | | **Visitors and caregivers** | Who can stay with you, and the rules for visitors. | | **Wi-Fi** | The network name and password, with copy buttons. | | **Interpreters and accessibility services** | How to get a spoken-language or sign-language interpreter, hearing loops, mobility aids and quiet spaces. | | **Parking and payment** | Where to park and how to pay. | | **Questions and answers** | Answers to common questions. | | **Words we use** | Words the care team may use, like CT, ultrasound, IV or specialist. | | **Contact** | The hospital's main phone line and patient relations. Never staff phone numbers. | In the app, **Open in Maps** opens directions in your maps app. On iPhone you may also be able to join the Wi-Fi with one tap. ## Education sheets [#education-sheets] Some tests and topics have an education sheet. For example, what happens during a CT scan. You can open them from a test or from the hospital info. Each sheet says who reviewed it and when. It also says: This isn't a substitute for talking with your care team. Ask them anything. ## If something is only in English [#if-something-is-only-in-english] If the hospital hasn't written a French version of a section yet, it is shown in English. ## Related [#related] * [Tests](/patients/tests) * [Asking your care team](/patients/requests), to ask for an interpreter # If you feel worse (https://docs.edflow.space/patients/if-you-feel-worse) If you feel worse in the emergency department, tell a nurse or staff member in person right away. What the I feel worse button also does, what happens when you're offline or outside, and what to do after you go home. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. ## Tell a person first [#tell-a-person-first] If you feel worse, **tell any nurse or staff member in person, right away**. Press your call bell if you have one. If you're in the waiting room, go to the triage desk. Don't wait for a reply on your phone. ## What the button does [#what-the-button-does] The **I feel worse** button is on every screen. When you tap it: 1. Your phone shows this at once, even without internet: > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. 2. At the same time, it sends an urgent message to your care team. You don't need to confirm. If you tap it more than once, your care team gets one message. 3. The screen shows Sending to your care team…, then We've also let your care team know. Please still tell someone in person. 4. When a staff member answers, you see that they know you asked for help. The instruction to tell someone in person stays at the top. !["I feel worse" screen: tell a nurse or another staff member now, or press your call button; the app also lets your care team know.](https://docs.edflow.space/screenshots/web/patient-feel-worse.png) Tap **Back to my visit** when you're ready. ## If the message can't be sent [#if-the-message-cant-be-sent] If your phone is offline, you see: We couldn't send this. Please tell a staff member now. Go to a staff member now. Your phone will not send the message later. ## If you're outside the department [#if-youre-outside-the-department] If you told us you stepped out, the screen says: > Come back to the emergency department now. If you can't, call 911. It shows a button to call 911 and still sends the message to your care team. ## If you're here for someone else [#if-youre-here-for-someone-else] If you're here with your child, the screen says: If your child seems worse, tell a nurse or staff member right away. ## After you go home [#after-you-go-home] After you leave, the button doesn't send anything to the emergency department. It says: > If this is an emergency, call 911. For health advice, call Health811 at 811. You'll see buttons to **Call 911** and **Call Health811**. ## Related [#related] * [Safety](/start/safety) * [Asking your care team](/patients/requests) * [After your visit](/patients/after-your-visit) # For patients (https://docs.edflow.space/patients) Follow your emergency department visit on your phone with EDFlow: see where you are, who is caring for you, your tests and usual waits, ask your care team for things, and share updates with family. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. EDFlow helps you follow your visit to the emergency department. You don't need an account. You don't need to install anything. Scan the QR code on your wristband or visit card with your phone's camera. ![Visit screen: the current step is Tests under way, with what happens next, the care team card, a usual wait range and the I feel worse button.](https://docs.edflow.space/screenshots/web/patient-visit-home.png) ## What you can do [#what-you-can-do] ## Before you start [#before-you-start] * **Check in with the triage nurse first.** EDFlow starts after you are registered. Staff give you a card or a wristband with a QR code. * **If you feel worse, tell a staff member in person.** Don't wait for your phone. See [If you feel worse](/patients/if-you-feel-worse). ## Where to begin [#where-to-begin] 1. [Sign in](/patients/sign-in) with your card or wristband. 2. Read [Your visit](/patients/your-visit) to learn what each part of the screen means. 3. Look at [Wait estimates](/patients/wait-estimates) to understand the times you see. ## What you won't see [#what-you-wont-see] * Your test results. Your care team will talk with you about them. * Your place in line. The sickest people are always seen first, so the order changes. * Anything about other patients. ## Need help? [#need-help] Ask any nurse or the registration desk. They can help you sign in on your own phone. You can also read [Troubleshooting](/patients/troubleshooting) or [Questions and answers](/start/faq). # Privacy (https://docs.edflow.space/patients/privacy) What EDFlow stores about your emergency visit and for how long, who can see what, why notifications never include health details, and how to keep your visit private on a shared phone. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. EDFlow works for your hospital. The hospital is in charge of your health information. EDFlow only shows you what you need to follow your visit. ## What we use [#what-we-use] * Your first name and the first letter of your last name, or the name you chose. * The steps of your visit and their times. * The names of your tests and where each one is. Never your results. * The names and roles of your care team. * Your requests and the things on your to-do list. We never store your last name or your date of birth. When you sign in, they are checked and then thrown away. ## Who sees what [#who-sees-what] | Information | You | Family you share with | Your care team | | ------------------------------- | --------------------------------------------- | ------------------------------------------------ | ---------------------------- | | Your step in the visit | Yes | A shorter version | Yes | | Usual waits | Yes | Only while you wait to be seen or wait for a bed | Yes | | Care team | Names and roles | First names and roles | Yes | | Tests | Yes (private tests show as "Additional test") | No | Yes | | Results | No | No | In the hospital's own system | | Requests and to-do | Yes | No | Yes | | Where you are in the department | The area | No | Yes | | Your notes for the doctor | Yes, on your phone only | No | No | Staff can only open your visit for your care. Every time someone opens it, it is recorded. The hospital's privacy office checks these records. ## Notifications, texts and links [#notifications-texts-and-links] * Notifications and texts never include your name, tests or the hospital's name. * Links never contain your information. The code in a card or link is secret and only works for your visit. * We never use your information for ads. ## How long we keep it [#how-long-we-keep-it] * Your phone deletes your visit when your access ends. * The hospital keeps some records for safety and privacy checks, for the time the law requires. Your requests are kept as part of the hospital's safety records. * Numbers used for estimates and reports don't include who you are. ## Using a shared phone [#using-a-shared-phone] * Tap **Sign out and forget this device** in [Settings](/patients/settings) when you're done. * Keep the lock-screen preview set to **Generic**. * In the app, turn on Face ID or fingerprint lock. ## Questions about your information [#questions-about-your-information] Ask the hospital's privacy office. Their contact is in Settings, under Privacy. ## Related [#related] * [Share with family](/patients/share-with-family) * [Settings](/patients/settings) * [PHIPA](/security/phipa) for more detail # Questions for your doctor (https://docs.edflow.space/patients/questions-for-your-doctor) Write down questions for your doctor while you wait. The notepad in EDFlow is saved only on your phone, never sent to the hospital, and cleared when your access ends. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. It's easy to forget a question when the doctor comes by. Use the notepad to write your questions down while you wait. Open it from the menu on the Visit screen. ![Questions for my doctor: two sample questions typed in a notepad that stays on this device only.](https://docs.edflow.space/screenshots/web/patient-notes.png) ## Add a question [#add-a-question] 1. Tap the box and type your question. 2. Or tap a suggestion, for example **What happens next?**, **What should I watch for at home?**, **When can I eat or drink?** or **Who do I follow up with?**. You can edit, delete and reorder questions. You can have 20 questions of up to 280 characters each. ## When the doctor comes [#when-the-doctor-comes] Tap **Show my doctor**. Your questions that haven't been asked yet appear in very large text, so you can show the screen or read from it. After you ask a question, mark it **Asked**. ## Your notes stay on your phone [#your-notes-stay-on-your-phone] Saved only on this device. It isn't part of your medical record. * Your notes are never sent to the hospital. Your care team can't read them. * They are locked with a key that only works for your visit. * They are deleted when you sign out and forget this device, and when your access ends, even if your phone is offline. If you want to keep a question for later, copy it somewhere else before your access ends. ## Related [#related] * [Asking your care team](/patients/requests), to send "I have a question for my care team" * [Privacy](/patients/privacy) # Asking your care team (https://docs.edflow.space/patients/requests) Send a request to your care team in EDFlow: a blanket, water, help to the washroom, an interpreter, a question, or to say you're stepping out. What "Seen by" means, reminders, limits and cancelling. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. The Requests screen lets you ask your care team for things without waiting for someone to walk by. Each request goes to the right person: your nurse, the nurses in your area, the triage nurse, or a support worker. ![Requests screen: the request types you can send to your care team and one open request waiting to be seen.](https://docs.edflow.space/screenshots/web/patient-requests.png) ## If you feel worse [#if-you-feel-worse] The first button is always **I feel worse**. Use it and also tell a staff member in person. See [If you feel worse](/patients/if-you-feel-worse). ## The kinds of requests [#the-kinds-of-requests] Requests are in three groups. Your hospital decides which ones you see, and some only appear at certain steps of your visit. | Group | Examples | | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Where I am** | I'm stepping out, I'm back, I'm going to the washroom | | **What I need** | Blanket, water, help getting to the washroom, my pain is worse, I feel sick to my stomach, my IV is beeping or hurts, help with nicotine cravings | | **Questions** | Can I eat or drink?, when will I see the doctor?, I need an interpreter, I need a sign language interpreter (ASL or LSQ), I have a question for my care team | "Where I am" requests are marked **Lets staff know**. They update where staff can find you. They don't ask anyone to do something. ## Sending a request [#sending-a-request] ### Tap the request [#tap-the-request] Most requests send right away. You see **Sent · Undo** for 5 seconds, in case you tapped by mistake. ### Read the note, if there is one [#read-the-note-if-there-is-one] Some requests show a short note before you send them. For example, for "Can I eat or drink?": We'll ask your nurse. Please wait for their answer before you eat or drink. Tap **Send**. ### Wait for "Seen by" [#wait-for-seen-by] Sent to your care team. They may not see it right away. When someone sees it, the request shows their name. _Screenshot pending: patient-request-confirm_ ![A request marked "Seen by your care team", with the time it was seen.](https://docs.edflow.space/screenshots/web/patient-request-acknowledged.png) ## What the status means [#what-the-status-means] | Status | What it means | | --------------------------------------------------------------------------------- | ----------------------------------------------------------- | | **Sent** | Your request reached your care team. | | "Seen by" and a name | That person has seen your request. | | **Done** | Your care team took care of it. | | **Closed** | It was closed, for example because you left the department. | | **Cancelled** | You cancelled it. | ## "When will I see the doctor?" [#when-will-i-see-the-doctor] This question is answered on the spot with the usual wait for your step. Your nurse is told only if you have waited longer than most people. ## Reminders and duplicates [#reminders-and-duplicates] If you tap the same request again, it won't send twice. It shows when you sent it. After about 10 minutes, you can tap **Send a reminder**. The reminder moves your request up. It doesn't make a new one. ## Cancelling [#cancelling] While nobody has seen your request yet, you can tap **Cancel**. ## Stepping out [#stepping-out] Please tell your nurse before you leave the department. Please tell your nurse before you leave the department. If you're called while you're away, you may have to wait longer. When you come back, tap **I'm back**. Some patients don't see the stepping-out request, because their care team needs them to stay. ## Thinking of leaving? [#thinking-of-leaving] Please talk to a nurse first. Please talk to a nurse before you go. We've let your care team know. You can still be seen. ## When your care team calls you [#when-your-care-team-calls-you] Staff can send you a message to come back, for example: Please come back to the waiting room. The team is ready for you. Tap **I'm on my way** so they know you saw it. ## Limits [#limits] You've sent a lot of requests. Please ask a staff member in person. This happens only after many requests in one hour. When you're offline, requests can't be sent: You're offline. Tell a staff member in person, or try again when you're connected. After you leave the department, requests are closed. ## Related [#related] * [If you feel worse](/patients/if-you-feel-worse) * [Questions for your doctor](/patients/questions-for-your-doctor) * [Care team](/patients/care-team) # Settings (https://docs.edflow.space/patients/settings) Change your language, text size, contrast, theme and notifications in EDFlow, lock the app with Face ID or fingerprint, see the phones signed in to your visit, and sign out. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. Open **Settings** from the menu on the Visit screen. ![Settings: language, text size, high contrast, notifications, device lock, devices on my visit, and sign out.](https://docs.edflow.space/screenshots/web/patient-settings.png) ## Reading and display [#reading-and-display] | Setting | Choices | Where it's saved | | --------- | ------------------------------- | ---------------------------------------------------------- | | Language | English, Français | This phone, for all visits | | Text size | 100% to 200%, with a preview | This phone. In the app, it follows your phone's text size. | | Contrast | Standard, High | This phone. In the app, it follows your phone's settings. | | Motion | Follow my device, Reduce motion | This phone | | Theme | Follow my device, Light, Dark | This phone | ## Notifications [#notifications] | Setting | What it does | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Lock-screen preview | **Generic** (the default) only says You have a new update. **Detailed** says what kind of update it is, never health details. | | Silent notifications | No sound or vibration. | | Categories | Visit updates, request replies, and things to do. Turn each on or off. | | Text message updates | On the main phone only. Your number is shown with most digits hidden. Tap **Stop texts** to turn them off. | Notification settings are saved for this visit only. ## Lock with Face ID or fingerprint [#lock-with-face-id-or-fingerprint] In the app, you can ask for Face ID, Touch ID or your fingerprint each time you open it. ## Devices on my visit [#devices-on-my-visit] Open **Devices on my visit** to see every phone signed in to your visit, with when it was first and last used. ![Devices on my visit: this phone and one other device, each with when it was last used and a button to sign it out.](https://docs.edflow.space/screenshots/web/patient-devices.png) * Your main phone is marked **Owner**. The phone you're holding is marked **This device**. * From the main phone, you can sign out another phone, and approve or refuse a phone that asks to join. * If you see a phone you don't know, tap **This wasn't me**. This signs out every other phone and asks staff to give you a new card. ## Privacy [#privacy] Read what we collect and who to contact at the hospital with privacy questions. See also [Privacy](/patients/privacy). ## Signing out [#signing-out] * **Sign out** ends this phone's session. You can sign in again with your card. * **Sign out and forget this device** also deletes your notes, your settings and anything saved on this phone. We ask you to confirm first. ## Related [#related] * [Languages and accessibility](/start/languages-and-accessibility) * [Updates and notifications](/patients/updates-and-notifications) # Share with family (https://docs.edflow.space/patients/share-with-family) Share a live view of your emergency visit with family or friends in EDFlow: what they can and can't see, how to send the link, the device limit, and how to stop sharing at any time. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. You can send family or friends a link so they can follow your visit. They see a short version. You decide who gets a link, and you can stop sharing at any time. ![Share with family: two active family links with their labels and when they were last opened, and a button to stop each one.](https://docs.edflow.space/screenshots/web/patient-share.png) ## What they will and won't see [#what-they-will-and-wont-see] | **They'll see** | **They won't see** | | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | Your stage | Tests | | Rough waits, only while you wait to be seen | Results | | Your doctor's and nurse's first names and roles | Requests | | Hospital information | Notes | | | Where you are in the department | If you turn it on, they can also see when you're getting ready to go home, so they can plan a ride. ## Share a link [#share-a-link] ### Open Share [#open-share] On the Visit screen, tap **Share your updates**, or open **Share** from the menu. Then tap **Share with someone**. ### Agree to share [#agree-to-share] Read what they will and won't see. Tick **I agree to share these updates**. ### Choose the details [#choose-the-details] * The name they will see. It starts as your first name. You can change it. * A private label for you, like "Mom". They don't see it. * When sharing ends: at the end of your visit, or after 4 or 12 hours. * The language of the text message, English or French. ### Send it [#send-it] Use your phone's share button, copy the link, or show a QR code for them to scan from your screen. If none of these work, we can send a text message for you. The text has no names in it. ![New family link: what family will and will not see, the consent checkbox, and a label for the person you are sharing with.](https://docs.edflow.space/screenshots/web/patient-share-new.png) #### iPhone _Screenshot pending: mobile-share-sheet_#### Android _Screenshot pending: mobile-share-sheet_ ## Limits [#limits] * You can share with up to 5 people at a time. Stop sharing with someone to add another. * Each link works on up to 3 devices. The list shows how many are used, like "2 of 3 devices". * You can only share from the main phone, the first one that signed in with your card. Other phones see: Sharing can only be set up on the phone that first scanned your card. ## See who opened it [#see-who-opened-it] Each link shows when it was last viewed, or **Not opened yet**. You can see each device that opened it and remove one. ## Stop sharing [#stop-sharing] Tap **Stop sharing** next to the link. Their screen changes within a few seconds to say the updates have ended. You can stop sharing at any time. If you sent a link to the wrong person, make a new link and tick **Also sign out the devices that already opened it**. ## Why a link can stop working [#why-a-link-can-stop-working] A link ends when you stop sharing, when the time you chose runs out, or a short time after you leave the department (2 hours by default). Sometimes sharing isn't possible at all. Then you see: Sharing isn't available for this visit. If you have questions, ask a staff member. We don't show the reason, to protect your privacy. ## Related [#related] * [What family can see](/family), to send to the people you share with * [Privacy](/patients/privacy) * [Designing family updates under PHIPA](https://edflow.space/learn/designing-family-updates-under-phipa) on the product site # Sign in (https://docs.edflow.space/patients/sign-in) How to sign in with my card: scan the QR code on your wristband or visit card, or enter your last name, date of birth and visit code, then confirm it's you. What to do if you're locked out. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. You sign in with the card or wristband label staff gave you after triage. There are three ways to sign in. They all lead to the same place. ## Before you start [#before-you-start] * You need the **visit card** or the **wristband label** with the QR code on it. * Check in with the triage nurse first. EDFlow only works once you are registered. * Any phone with a camera and a web browser works. You don't need the app. ![Hospital entry page for a fictional emergency department: check in with the triage nurse first, the busy-department notice and the sign-in button.](https://docs.edflow.space/screenshots/web/hospital-entry.png) ## Sign in with your card [#sign-in-with-your-card] #### Web ### Scan the QR code [#scan-the-qr-code] Open your phone's camera and point it at the QR code on your card. Tap the link that appears. ### Check it's you [#check-its-you] The screen asks **Is this you?** It shows your first name, the first letter of your last name, and when you checked in. Tap **Yes, that's me** if it's you. ### Read the three welcome screens [#read-the-three-welcome-screens] They explain what you'll see, what you won't see, and what to do if you feel worse. You must read the last one. #### iPhone ### Open the app [#open-the-app] Choose **Scan my wristband**. ### Scan the QR code [#scan-the-qr-code-1] Point the camera at the QR code. The app only accepts EDFlow codes. ### Check it's you [#check-its-you-1] Tap **Yes, that's me**. _Screenshot pending: mobile-sign-in-choice__Screenshot pending: mobile-scan_#### Android ### Open the app [#open-the-app-1] Choose **Scan my wristband**. ### Scan the QR code [#scan-the-qr-code-2] Point the camera at the QR code. You can turn on the torch if it's dark. ### Check it's you [#check-its-you-2] Tap **Yes, that's me**. _Screenshot pending: mobile-sign-in-choice__Screenshot pending: mobile-scan_ !["Is this you?" check on a new device, showing the first name and initial, with Yes and No buttons.](https://docs.edflow.space/screenshots/web/patient-confirm-identity.png) If the name is not yours, tap **No, that's not me**. We sign you out and let the staff know. Please ask a staff member for help. ## Sign in with your details [#sign-in-with-your-details] Use this if you can't scan the code. 1. Choose **Enter my details**. 2. Type your **last name**. 3. Type your **date of birth**: year, month and day in three boxes. 4. Type your **visit code**. It is printed on your card, under the QR code. It looks like `XXXX-XXXX`. You can type it with or without the dash. 5. Tap **Continue**, then confirm it's you. ![Sign-in form: last name, date of birth and the visit code printed on your card. The values shown are sample placeholders.](https://docs.edflow.space/screenshots/web/patient-sign-in-manual.png) Some hospitals only use a visit code. In that case, you type the code, then the first name you'd like us to use. ## Sign in with help from staff [#sign-in-with-help-from-staff] If you'd like help, ask a nurse or the registration desk. On your phone, choose **Get help signing in**. Your phone shows a short code. Show it to the staff member. When they approve it, your phone signs in. Staff never need to hold your phone or your card. ## Using a second phone [#using-a-second-phone] The first phone that signs in with your card becomes the **main phone** for your visit. If you sign in on another phone, we ask for your date of birth first, or you can ask the main phone to approve it. If your card is a wristband label, we always ask for your date of birth. ## If something goes wrong [#if-something-goes-wrong] | What you see | What to do | | ------------------------------------------------------------------------ | ------------------------------------------------------------------------- | | We couldn't find a visit with those details. Check them and try again, or ask a staff member. | Check the spelling and the date. After a few tries you will need to wait. | | Too many tries. Please wait 15 minutes, or ask a staff member. | Wait 15 minutes, or ask a staff member to help you. | | This code doesn't work anymore. Ask a nurse or the registration desk for a new card. | Your card no longer works. Ask for a new card. | | Your visit isn't ready for EDFlow yet. Staff will give you a card when it is. | Staff are still setting up your visit. They will give you a card. | | This visit is already open on the most devices allowed. Sign out on another device, or ask a staff member. | Sign out on a phone you no longer use, or ask a staff member. | More help is on [Troubleshooting](/patients/troubleshooting). ## Related [#related] * [App or browser](/patients/app-or-browser) * [Your visit](/patients/your-visit) * [Settings](/patients/settings), to see the phones signed in to your visit # Tests (https://docs.edflow.space/patients/tests) Follow each of your tests in EDFlow: its steps, the usual wait for this day and hour, and when results are back. You never see the results themselves; your care team talks with you about them. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. The Tests screen shows every test your care team ordered, and where each one is. It never shows your results. ![Tests screen: each test with its current step, and results marked only as back or not back yet.](https://docs.edflow.space/screenshots/web/patient-tests.png) ## Results stay with your care team [#results-stay-with-your-care-team] You'll hear about your results from your care team, not in this app. When a test is back, it means your care team can look at it. It doesn't mean anything good or bad. Your care team looks at all your results together before they talk with you. ## How tests are grouped [#how-tests-are-grouped] Tests are grouped as **Blood tests**, **Urine tests**, **Scans and X-rays**, **Heart tests** and **Other tests**. Each test shows its plain name first, then its short name, for example "Blood count (CBC)". ## The steps of a test [#the-steps-of-a-test] | Kind of test | Steps | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Blood and urine tests | **Ordered**, **Collected**, **In the lab**, **Back** | | Scans and X-rays | **Ordered**, **Having your scan**, **Being read**, **Back** | | Heart tracing (ECG) | **Ordered**, **Done** | Each step is shown with words and a shape, not only a colour. ## How long a test usually takes [#how-long-a-test-usually-takes] Each test shows a short estimate, like "usually 45 min–1 h · most within 2 h". It is based on the same test at this hospital, on the same day of the week, around the same time. See [Wait estimates](/patients/wait-estimates). If a test takes longer than most, you see: This is taking longer than usual. ## Test details [#test-details] Tap a test to see what it is for in plain words, when each step happened, how to get ready (for example, drinking something before a scan) and whether you need to give consent. _Screenshot pending: patient-test-detail_ ## Things you may see [#things-you-may-see] | What you see | What it means | | ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Consent needed** | Someone will explain the test and ask for your OK before it happens. | | **Results come later** | Results for this test take longer. They come after your visit. Your care team will explain how you'll get them. This test is not counted in "tests are back". | | A repeat test is usually needed. | Some tests, like troponin, are done twice a few hours apart. | | "Scheduled for about 3:00 p.m." | This test is timed. It won't start before then. | | This test needs a new sample. This happens sometimes and doesn't mean anything is wrong. | A new sample is needed. | | **Additional test** | Some tests are private. They are shown without a name. | | More tests were ordered. This is common and part of making a plan with you. | New tests were added after the first ones. | | Your care team is reviewing your tests. They'll talk with you about them. | Your care team wants to review results before they show as back. | ![Tests screen with every result back and the stage "Results back: waiting to see your care team again". The results themselves are never shown.](https://docs.edflow.space/screenshots/web/patient-results-back.png) ![Tests screen showing an "Additional test" in place of a sensitive test name, with the patient name hidden.](https://docs.edflow.space/screenshots/web/patient-sensitive-test.png) ## When all results are in [#when-all-results-are-in] You see **All your results are in**. Next, a member of your care team will see you again to talk about your results and what happens next. ## No tests? [#no-tests] You see: No tests have been ordered. If your care team orders any, they'll show here. At some hospitals without a computer link, you only see: Your tests are under way. Your care team will talk with you about them. ## Related [#related] * [Wait estimates](/patients/wait-estimates) * [To do](/patients/to-do), for things you need to do before a test * [Results are back, without the results](https://edflow.space/learn/results-are-back-without-results) on the product site # Timeline (https://docs.edflow.space/patients/timeline) The timeline in EDFlow lists every step of your emergency visit with its time, from checking in to leaving, and what usually comes next. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. The timeline is the story of your visit so far. Each step shows when it happened. The newest step is at the bottom. To open it, tap **See full timeline** on the Visit screen. ![Timeline of the visit: each step so far with its time, and the steps still to come.](https://docs.edflow.space/screenshots/web/patient-timeline.png) ## What each step means [#what-each-step-means] | Step | What it means | | -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Checked in | You were registered at the emergency department. | | First check by a nurse | A nurse asked why you came and checked things like your temperature and blood pressure. | | Tests started while you wait | A nurse started some tests before a doctor saw you. | | A doctor has been assigned | A doctor, nurse practitioner or physician assistant is taking care of you. They have not seen you yet. | | Seen by a doctor | A doctor, nurse practitioner or physician assistant saw you. | | Tests ordered | Your care team ordered tests. If they order more later, you'll see "More tests ordered". This is common. | | Results are coming in | Some of your results are back. You'll hear about them from your care team. | | All your results are in | Every counted test is back. You're waiting to see your care team again. | | Seen again by your care team | Your care team saw you again to talk about the next steps. | | A specialist was asked to see you | Your care team asked another kind of doctor to see you. | | Treatment and monitoring | Your team is watching you for a while after treatment. | | Your nurse changed | A new nurse is looking after you, often because of a shift change. | | Plan: going home, staying in hospital, or moving to another hospital | The decision about where you go next. | | You can go now | You're cleared to leave. | | Bed requested, bed assigned, bed ready | Progress toward your bed upstairs. | | You stepped out, you're back | Only when you told us with a request. | | Left the department | You left the emergency department. | ## What usually happens next [#what-usually-happens-next] After your steps, the timeline shows the steps that usually come next, in a lighter style. They are labelled **Usually next** and never have a time. Your visit may go a different way. ## Things to know [#things-to-know] * Steps are never moved or deleted. If more tests are ordered after results come back, new steps are added in time order. * A step looks the same whether it came from the hospital's computer system or from a staff member. * A result step appears only when the hospital shows results as back. Some hospitals wait a few minutes so a clinician sees it first. ## Related [#related] * [Your visit](/patients/your-visit) * [Tests](/patients/tests) * [How a visit works](/start/how-a-visit-works) # To do (https://docs.edflow.space/patients/to-do) Things your care team needs from you in EDFlow: samples, consent before a test, and restrictions such as nothing to eat or drink. How to mark a task done. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. The To do screen lists things your care team needs from you. Each one says where it came from, for example "Because a urine test was ordered" or "From your care team". ![To do: things you can help with, such as giving a urine sample, each with a Done button.](https://docs.edflow.space/screenshots/web/patient-todo.png) ## The sections [#the-sections] | Section | What's in it | | --------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | **Restrictions** | Things not to do for now. They stay at the top. | | **To do** | Things to do, with a **Done** button. | | **Good to know** | Information, with a **Got it** button. | | **Done** | Things you've finished. | ## Restrictions [#restrictions] A restriction appears only when your care team has asked for it. For example: > Please don't eat or drink anything for now, not even water. Your care team will tell you when you can. _Screenshot pending: patient-todo-restriction_ There is no **Done** button on a restriction. It goes away when your care team lifts it. If there is no restriction but a test might need one, you see: Before you eat or drink, please check with your nurse. Please ask before you eat or drink. ## Things you may be asked to do [#things-you-may-be-asked-to-do] | Task | What it says | | --------------------- | ------------------------------------------------------------------------ | | Urine sample | Hand your sample to your nurse. Don't leave it in the washroom. | | Consent before a test | You'll be asked to sign a consent form before this test. Your care team will explain it first. | | Before a scan | If there's any chance you could be pregnant, tell your nurse before this scan. | | Before an MRI | Tell your nurse about any pacemaker, implant, metal in your body or recent surgery. Remove metal items when asked. | For a child, you may see: Your nurse will help collect a urine sample from your child. ## Marking a task done [#marking-a-task-done] 1. Tap **Done**. 2. The screen asks **Did you finish this?** Tap **Yes, I've done it**. 3. You see: We've let your nurse know. Some tasks finish by themselves. For example, a urine task is done when the lab records your sample. ## Nothing to do? [#nothing-to-do] You see: Nothing to do right now. We'll let you know if your care team needs something from you. ## Related [#related] * [Tests](/patients/tests) * [Asking your care team](/patients/requests), to ask "Can I eat or drink?" # Troubleshooting (https://docs.edflow.space/patients/troubleshooting) Fix common problems with EDFlow during your emergency visit: no connection, information may be delayed, updates are paused, the code doesn't work, you're locked out, or too many devices. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. If something doesn't work, you can always ask any nurse or the registration desk. Ask any nurse or the registration desk. They can help you use EDFlow. ## "You're offline" [#youre-offline] You're offline. We'll update this as soon as you reconnect. ![Visit screen while offline: a notice that you are not connected, the last information received and when, and the I feel worse button still available.](https://docs.edflow.space/screenshots/web/patient-offline.png) * The screen shows what we knew last, and when. * You can't send requests while you're offline. Tell a staff member in person. * The **I feel worse** button still shows what to do. * Try the hospital Wi-Fi. The name and password are in [Hospital info](/patients/hospital-info). ## "Updates may be delayed" [#updates-may-be-delayed] Updates may be delayed. Last updated {time}. Your care continues as usual. _Screenshot pending: patient-stale-banner_ The hospital's system is slow to send us news. Your care is not affected. Estimates may not be up to date. _Screenshot pending: patient-feed-down-banner_ ## "Updates are paused" [#updates-are-paused] Updates are paused. Please speak with the care team or call the hospital. Your care team paused updates for now. Nothing else on the screen changes until they turn updates back on. ## The code doesn't work [#the-code-doesnt-work] | What you see | What to do | | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- | | We couldn't find a visit with those details. Check them and try again, or ask a staff member. | Check your last name, date of birth and visit code. The code has letters and numbers. You can type it with or without the dash. | | This code doesn't work anymore. Ask a nurse or the registration desk for a new card. | Your card no longer works. Ask for a new one. | | This isn't a EDFlow code. | This QR code isn't for this app. Scan the code on your visit card. | | Your visit isn't ready for EDFlow yet. Staff will give you a card when it is. | Staff are still setting up your visit. | ## You're locked out [#youre-locked-out] Too many tries. Please wait 15 minutes, or ask a staff member. To keep your visit safe, we stop sign-in for 15 minutes after too many wrong tries. A staff member can help you sign in on your own phone. ## Too many phones [#too-many-phones] This visit is already open on the most devices allowed. Sign out on another device, or ask a staff member. A visit can be open on up to 5 phones at once. On your main phone, open **Devices on my visit** in [Settings](/patients/settings) and sign out a phone you don't use. ## Another visit on this phone [#another-visit-on-this-phone] You're signed in to another visit on this device. Switch to this visit? Switching signs out the other visit on this phone. ## The information looks wrong [#the-information-looks-wrong] Tell your nurse. Staff can report a data problem so the hospital can fix it. You can also use **Report a problem with the app** in **Help**. Please don't include names or health details. ## Related [#related] * [Sign in](/patients/sign-in) * [Questions and answers](/start/faq) # Updates and notifications (https://docs.edflow.space/patients/updates-and-notifications) Your updates inbox, app notifications and text messages in EDFlow: what we send, what your lock screen shows (never health details), and how to change or stop them. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. EDFlow tells you about the big steps in your visit. Everything we send is also in your **Updates** inbox. Tap the bell at the top of the Visit screen to open it. ![Updates inbox: the latest changes to the visit, newest first, each with its time.](https://docs.edflow.space/screenshots/web/patient-updates.png) ## The updates inbox [#the-updates-inbox] * Updates are grouped by **Today** and **Earlier**. * Tap an update to open the screen it's about. * Tap **Mark all as read** to clear the dots. * If a delay notice changes, the same update shows a new time instead of a new message. ## What your lock screen shows [#what-your-lock-screen-shows] We never put your name, your tests or the hospital's name in a notification. By default, your lock screen only says: > You have a new update. If you choose **Detailed** in [Settings](/patients/settings), notifications say a little more, but never health details. For example: | Update | Detailed text | | ----------------------------- | ------------------------------------------------------------------------------- | | Seen by a doctor | An emergency care provider has seen you. | | Some results back | Some of your results are back. | | All results back | All your results are in. | | Something to do | Your care team has something for you to do. | | Request seen | Your care team has seen your request. | | Going home | The plan is for you to go home. Please wait for your nurse before you leave. | | Staying in the hospital | You'll be staying in the hospital. | | Your bed is ready | Your bed upstairs is ready. | | Your care team is calling you | Your care team is calling you. | A delay notice always says: Your wait may be longer. Tap for an update. ## Text messages [#text-messages] If you turn on text updates, you get a text for the big steps only. The text says only that you have a new update and has a link. It never has your name or health details. You can turn texts off in [Settings](/patients/settings). * The number you give is checked with a 6-digit code first. * It is stored encrypted and deleted when your access ends. * We send at most a few texts a day. ## Quiet notifications [#quiet-notifications] In Settings, you can turn on **Silent notifications**. They arrive with no sound or vibration. ## If a new phone opens your visit [#if-a-new-phone-opens-your-visit] You get an update that your visit was opened on another device. On your main phone, you can tap **This wasn't me**. This signs out every other phone and asks staff to give you a new card. ## Nothing yet? [#nothing-yet] You see: Updates about your visit will show here. ## Related [#related] * [Settings](/patients/settings) * [Delays](/patients/delays) * [Privacy](/patients/privacy) # Wait estimates (https://docs.edflow.space/patients/wait-estimates) How EDFlow estimates waits in plain words: a usual range and the time 9 in 10 people are done within, based on past visits on the same day and hour. Why there is no countdown and why times can change. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. Wait times in EDFlow are estimates, not promises. They come from how long the same step took for other people at this hospital, on the same day of the week and around the same time. _Screenshot pending: patient-estimate-block_ ## How to read an estimate [#how-to-read-an-estimate] An estimate has two lines: * **Usually.** For example, "Usually 45 min to 1 h". Half of people finish this step within the first time, and three in four within the second. * **Most people.** For example, "Most people (9 in 10) are done within about 2 h. Sometimes it takes longer." Under them, a line says what the estimate is based on, like "Based on past Tuesdays around 3 p.m. at this hospital." Tap **How we estimate times** to read more. ## Why the numbers are rounded [#why-the-numbers-are-rounded] We round times up, so they are easy to read and you are less likely to wait longer than shown: | Time | Rounded to | | ----------------- | ------------------- | | Less than 1 hour | The next 5 minutes | | 1 to 3 hours | The next 15 minutes | | More than 3 hours | The next 30 minutes | ## Why there is no countdown [#why-there-is-no-countdown] The sickest people are always seen first. Someone who arrives after you may be seen before you. A countdown would often be wrong, so we don't show one. We also never show your place in line. ## Why a time can change [#why-a-time-can-change] Your estimate is set when a step starts. It does not jump around while you wait. It can change if: * a nurse checks you again and your care changes; * you move to another area of the department; * a new test is ordered. ## When a step takes longer than usual [#when-a-step-takes-longer-than-usual] If your step goes past the time most people are done within, you see: > This is taking longer than usual. If you haven't heard from anyone recently, please check with a nurse. ![Visit screen when a step is taking longer than the usual longest wait: "This is taking longer than usual", with no countdown.](https://docs.edflow.space/screenshots/web/patient-visit-over-longest.png) Staff also get an alert. When one of them sees it, your screen says: Your care team knows you're waiting. ## When there is no estimate [#when-there-is-no-estimate] | What you see | Why | | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | We'll see you as soon as we can. The sickest people are always seen first. | You'll be seen as soon as possible, so a time would not help. | | We don't have enough information to estimate this step yet. | The hospital doesn't have enough past visits for this step yet. | | "This service opens at 8 a.m." | The service for this test is closed right now. The screen says when it opens, and your care team will tell you what happens until then. | | Times may not be up to date while updates are delayed. | Updates from the hospital are delayed. | | This depends on beds upstairs. | You're waiting for a bed upstairs. This depends on beds in the hospital. | When the department is very busy, estimates also say: Waits may be longer than usual right now. ## Related [#related] * [Your visit](/patients/your-visit) * [Tests](/patients/tests) * [Why wait estimates should under-promise](https://edflow.space/learn/why-wait-estimates-should-under-promise) on the product site # Your visit (https://docs.edflow.space/patients/your-visit) What the Visit screen in EDFlow shows: your current step, what happens next, the usual wait for this step, your care team, your tests, quick requests and the latest updates. > **Tell a staff member now** > > Don't wait for a reply on your phone. Tell any nurse or staff member right away, or press your call bell. If you're in the waiting room, go to the triage desk. If this is an emergency, call 911. For health advice, call Health811 at 811. The Visit screen answers three questions: where am I, what happens next, and how long this step usually takes. It updates by itself. You don't need to refresh it. ![Visit screen: the current step is Tests under way, with what happens next, the care team card, a usual wait range and the I feel worse button.](https://docs.edflow.space/screenshots/web/patient-visit-home.png) ## What's on the screen [#whats-on-the-screen] From top to bottom: 1. **Notices.** For example, when the department is very busy or when your wait may be longer. See [Delays](/patients/delays). 2. **Your step.** The name of your step and one sentence about it. 3. **How long it usually takes.** A range, and the time most people are done within. See [Wait estimates](/patients/wait-estimates). 4. **What's next.** One to three sentences about the next step. This is what usually happens. It is not a promise. 5. **To do.** Things your care team needs from you, if there are any. See [To do](/patients/to-do). 6. **Your care team.** Your doctor and your nurse. See [Care team](/patients/care-team). 7. **Tests.** How many of your tests are back. See [Tests](/patients/tests). 8. **Quick requests.** The four requests people ask for most at your step. See [Asking your care team](/patients/requests). 9. **Recent updates.** Your last three steps. Tap **See full timeline** for the rest. See [Timeline](/patients/timeline). 10. **Share your updates.** If you haven't shared with family yet. See [Share with family](/patients/share-with-family). At the bottom, the status line shows when the screen last changed. The **I feel worse** button is always there. ## Right after you check in [#right-after-you-check-in] ![Visit screen right after check-in: the stage "Checked in" and what happens next, a first check by a nurse.](https://docs.edflow.space/screenshots/web/patient-visit-checked-in.png) A nurse will check you as soon as they can. If this hospital has enough past visits, you see how long that usually takes. ## While you wait to be seen [#while-you-wait-to-be-seen] ![Visit screen in French while waiting to be seen: the busy-department banner and the usual wait for this day and hour.](https://docs.edflow.space/screenshots/web/patient-visit-waiting.png) You see how long people usually wait to be seen at this hospital, on this day and at this hour. The sickest people are always seen first, so the order can change. If your condition means you'll be seen as soon as possible, you won't see a time. You'll see: We'll see you as soon as we can. The sickest people are always seen first. Some tests may start before a doctor sees you. The screen then says some tests have started while you wait. ## Other steps you may see [#other-steps-you-may-see] * **A doctor has been assigned.** Someone is taking care of you. They'll see you as soon as they can. There is no time. * **Tests under way.** Your tests are shown at the top. * **Results back.** You're waiting to see your care team again. * **Waiting for a specialist.** The screen names the kind of specialist, unless the hospital keeps it private. * **Treatment and monitoring.** How long your team would like to watch you. * **Getting ready to go home.** The plan is for you to go home. Please wait for your nurse to go over your instructions and take out your IV before you leave. * **Staying in the hospital.** You're waiting for a bed upstairs. This depends on beds upstairs. ## How long you've been here [#how-long-youve-been-here] Under your step, a quiet line says when you checked in and how long ago. It is only about you. It is never compared with anyone else. ## Related [#related] * [How a visit works](/start/how-a-visit-works) * [Timeline](/patients/timeline) * [Troubleshooting](/patients/troubleshooting), if the screen says updates may be delayed # Access requests and retention (https://docs.edflow.space/admin/privacy/access-requests-and-retention) Answer PHIPA access requests with a EDFlow visit-record export, place and lift legal holds, and understand the retention schedule, care records and de-identification after the operational window. ## Access requests [#access-requests] When a patient asks for their information under PHIPA: 1. Find the visit: from the visit's **Activity** tab, or **Legal holds → Care records** by the EHR visit number (hashed in memory, never stored as typed). 2. **Export the visit record**: timeline, care-team names, tests and their steps, requests, tasks, the going-home summary, family-link activity, the access log and care records. 3. A second privacy officer approves the export. It's audited. EDFlow holds far less than the EHR: never results, diagnoses or notes. The EHR remains the official record. ## Legal holds [#legal-holds] A hold stops retention from deleting a visit. * **Manual**: from the visit's Activity tab or **Legal holds** (reason required). * **Automatic**: visits with an urgent request, a death, a return within 72 hours, a patient-relations complaint recorded by staff, and incident subjects. * **Lift** needs `privacy.legal_hold` and a fresh sign-in check. Every hold and lift is audited. ## Retention schedule [#retention-schedule] | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | retention.operationalWindowDays | 30 | 7–90 days | Days PHI is kept before de-identification (F-21.2). (Reduces privacy) | | retention.auditDays | 730 | 730–3650 days | Audit log retention. (Reduces privacy) | | retention.analyticsDays | 730 | 365–2555 days | De-identified analytics retention. (Reduces privacy) | | retention.safetyRecordYears | 10 | 2–30 years | Retention of care records (D-36). (Reduces privacy) | | Data | Kept | Then | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- | ----------------------------------------- | | Printable card code | 15 min | Deleted | | Staff-assist codes | 5 min | Deleted | | Push tokens, patient and family phone numbers | Until the session, access or link ends | Deleted | | Card, visit-code, family and summary token hashes | Until access ends | Deleted | | Patient and family sessions | Access end + 7 days | Deleted (the audit log keeps the history) | | Identifiable visit data (display name, match key, locations, care-team links, orders, low and normal requests, inbox, estimates, stages, family links) | The operational window after departure (default 30 days) | De-identified | | **Care records**: urgent and high requests with their lifecycle, check-ins that raised a request, published summaries, task instructions shown, delay notices, call-backs, updates pauses | The safety-record period (default 10 years) | Deleted unless on hold | | EHR event ledger, idempotency keys, dead letters | 30 days | Deleted | | Outbox | Bodies 30 days, rows 90 days | Cleared, then deleted | | Audit log | 2 years (range 2 to 10) | Deleted with its digests | | De-identified analytics | 2 years (range 1 to 7) | Deleted | | AI conversations | Session end + retention days (default 7) | Deleted | ## De-identification [#de-identification] At the end of the operational window, the nightly job: 1. confirms the visit's de-identified analytics row exists; 2. copies care records; 3. converts remaining requests to de-identified request facts; 4. unlinks feedback; 5. deletes orders, tasks, inbox, estimates, family links, stages, care-team links and locations; 6. keeps a stub with the visit-number hashes only while care records exist. Visits on legal hold are skipped. Each run is audited with counts. ## Related [#related] * [Privacy and retention settings](/admin/settings/privacy-and-retention) * [PHIPA](/security/phipa) # AI review (https://docs.edflow.space/admin/privacy/ai-review) Review flagged EDFlow AI conversations as part of the safety review group: what gets flagged, reason codes, conflict rules, what you see, and resolving safety events. Where a site uses the patient or family assistant, some conversations are flagged for safety review. Only members of the designated **safety review group** can open them. ![AI safety review queue: flagged assistant conversations with the reason they were flagged, for a privacy officer to review.](https://docs.edflow.space/screenshots/web/admin-ai-review.png) ## What gets flagged [#what-gets-flagged] * Messages the safety layer recognised as distress or self-harm (which also alerted the care team). * Attempts to misuse the assistant (for example trying to make it ignore its rules). * Answers that the output checks blocked. * A random sample of other conversations, only when the privacy office has approved sampling. ## Opening a conversation [#opening-a-conversation] 1. Choose a reason code. Opening is audited and counts toward monitoring rule A-1. 2. You see the scrubbed conversation: identifiers the patient typed are hidden. 3. You can't open a conversation for a visit where you are on the care team, hold an open grant, or worked that zone's shift. The page blocks it and records the attempt. ## Resolving [#resolving] Record what happened (no action, content fix needed, prompt fix needed, clinical follow-up referred to the site) and close the safety event. Content and prompt fixes go back through the governance gates. ## Retention [#retention] Conversations are deleted after the site's retention days; threads with a safety event are kept for the operational window. ## Related [#related] * [AI](/admin/ai) * [AI governance](/security/ai) # Privacy officers (https://docs.edflow.space/admin/privacy) EDFlow for privacy officers: the audit log and what is logged, per-patient access reports, monitoring alerts A-1 to A-28, exports with second-person approval, incidents, emergency revoke and safety concerns. The privacy officer role holds the custodian's audit and investigation tools. It can't be combined with the manager role or any clinical role. ## The audit log [#the-audit-log] ![Audit log: every access and change with who, what, when and from where, with filters and export.](https://docs.edflow.space/screenshots/web/admin-audit-log.png) Filter by actor, actor type (patient, family, staff, station, system, integration, platform), action, visit, date range and outcome. Privacy officers can also search a visit by display name. Each row opens a detail drawer. ### What is logged [#what-is-logged] | Group | Examples | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Patient and family access | Sessions created and ended, rejected tokens, failed sign-ins, identity confirmed or mismatched, family links created, opened, revoked | | Staff authentication | Sign-ins, failures, lockouts, MFA changes, password resets, SSO rejections | | Staff access to patient data | Board views (every 15 min), each patient opened (with the tab), unmasks with reasons, card issuing and pairing approvals, payload reveals | | State changes | Every manual action, override, result hold and release, request action, call-back, summary publication, flag change, updates pause | | Department | Codes called, notices posted and ended, volume changes | | Administration | Settings changes with before and after, invites, role changes, approvals, stations, content status, access reviews | | Integration and API | Sources, key reveals, dead-letter replays, apps, credentials, scopes | | Privacy and platform | Audit views and exports, retention runs, legal holds, incidents, emergency revokes, support access | | AI | Safety conversations opened, automatic alerts, governance gates, kill switch | Audit rows never contain names, tokens, phone numbers, emails, message bodies or free text. The log is append-only and each day is hashed and chained to the previous day, so tampering can be detected; exports include the digests. ## Per-patient access report [#per-patient-access-report] ![Per-patient access report: every staff member who opened the visit, when, from which screen, and why.](https://docs.edflow.space/screenshots/web/admin-access-report.png) Every access to one visit, as CSV or PDF, including every integration that received the visit's data. ## Monitoring alerts [#monitoring-alerts] Automatic rules raise alerts on this page and by email to the privacy office. Acknowledge each with a note. Examples: | Rule | Condition | | ---- | ---------------------------------------------------------------------------------------------------------------------------- | | A-1 | One user opens more than 30 patients (or issues credentials, probes duplicates or reveals payloads for that many) in an hour | | A-2 | A confidential visit opened by someone not on its care team | | A-3 | More than 3 unmasks by one user in 12 hours | | A-4 | 10 or more failed manual sign-ins against one visit in 24 hours | | A-7 | An audit export | | A-8 | Support access started | | A-16 | A privileged role requested or activated | | A-17 | Self-assignment to a confidential visit, or a confidential or sharing flag cleared | | A-19 | A patient-facing trust anchor changed | | A-23 | An integration reading far more visits than usual | ## Exports [#exports] Audit exports need a second privacy officer's approval (and are themselves audited). SIEM export is available on request as CSV or NDJSON, with scheduled delivery in a later release. ## Incidents and emergency revoke [#incidents-and-emergency-revoke] **Privacy incidents** track a suspected breach: summary (no personal information), scope (criteria that find affected visits and place legal holds automatically), matching visit numbers from an EHR extract (hashed in memory), a notification timeline for the custodian, individuals and the IPC, the reportable decision, and closing. Anyone who is a subject or actor of the incident can't act on it. Annual statistics by IPC category are ready for the March 1 report. **Emergency revoke** ends family links, patient sessions, visit credentials, or all patient and family access across the site, with a reason and the typed site name. Staff sessions are not affected. ## Safety concerns [#safety-concerns] Staff report safety concerns from the console. They appear on **Safety concerns** with their category and status, and export to the hospital's incident system. ## Related [#related] * [Access requests and retention](/admin/privacy/access-requests-and-retention) * [Audit logging](/security/audit-logging) for IT # Message outbox (https://docs.edflow.space/admin/privacy/message-outbox) The EDFlow message outbox: every text, email and push attempt with masked recipients and masked links, delivery status, resend, and why invite and reset links are never kept. The outbox is the record of every message EDFlow tried to send. ![Message outbox: every SMS, email and push sent, with status and masked links; tokens are never shown.](https://docs.edflow.space/screenshots/web/admin-outbox.png) ## Each row [#each-row] | Field | Notes | | ------------------ | --------------------------------------------------------------------------------------------------------- | | Time, channel | Text, email or push | | Template | The fixed template key (for example the generic patient update) | | Recipient | Masked: the last 2 digits of a phone number, the first letter and domain of an email, a push token prefix | | Status | Queued, sent, delivered, failed, suppressed (rate cap or opt-out), captured (no provider configured) | | Provider id, error | For troubleshooting | | Related | The visit's EDFlow id, or the staff user | The body view shows the rendered text with every link token masked (`/f#t=••••`). ## What's never kept [#whats-never-kept] Invite and password-reset links are never kept or openable, in any environment. Phone numbers used once to send a family invite or a summary link aren't stored at all. ## Synthetic environments only [#synthetic-environments-only] In demo and test environments with synthetic data only, a captured patient or family link can be opened with **Open**, which is audited. This is never possible in production or customer test. ## Resend [#resend] Failed messages can be resent. ## Retention [#retention] Bodies are cleared after 30 days and rows deleted after 90 days. ## Related [#related] * [Notifications](/admin/settings/notifications) # Vendor support access (https://docs.edflow.space/admin/privacy/vendor-support-access) How time-boxed vendor support access to your EDFlow site works: no standing access, a ticket and reason, read-only or admin scope, at most 4 hours, notifications to managers and a full audit trail. EDFlow operators have **no standing access** to your site's data. When your team asks for help that needs a look at your site, an operator opens a support-access session. _Screenshot pending: admin-support-access-notice_ ## How it works [#how-it-works] | | | | ------------ | --------------------------------------------------------------------------- | | Duration | At most 4 hours, then it ends on its own | | Scope | Read-only or admin, chosen for the ticket | | Reason | A support ticket id is required | | Notification | Your site's managers are notified when it starts (monitoring rule A-8) | | Audit | Every action in the session carries the support-access id in your audit log | ## Checking what happened [#checking-what-happened] Filter the audit log by actor type **platform**, or by the support-access id from the notification. The per-patient access report includes any visit opened during support access. ## Break-glass [#break-glass] For production emergencies, break-glass access needs a second operator's approval and is recorded. See [Privileged access](/security/privileged-access) for how vendor staff can and can't reach production. ## If something looks wrong [#if-something-looks-wrong] Contact your EDFlow account contact and open a privacy incident if needed. # Code types (https://docs.edflow.space/admin/settings/code-types) Configure the EDFlow code-type catalogue: Ontario colour-code defaults, categories and patient notification rules, notice stages and scope, durations, optional templates and paging location filters. The code catalogue lists the codes staff can record and which ones may let waiting patients know about a delay. ![Code types: each code with its category and whether patients see a delay notice.](https://docs.edflow.space/screenshots/web/admin-settings-codes.png) ## Fields [#fields] | Field | Notes | | ---------------------- | ----------------------------------------------------------------------------------------------------- | | Key and staff name | For example `blue`, "Code Blue" / "Code bleu". Staff only | | Staff colour, severity | Staff styling only | | Category | Medical, security or facility | | Notify patients | Allowed only for **medical** codes. Locked off for security and facility codes, in the UI and the API | | Notice stages | Default: checked in, waiting to be seen, a doctor assigned, results back | | Notice scope | Affected zones plus the waiting room (default), or the whole department | | The ED team responds | Used by the paging filter | | Default duration | 5 to 240 min | | Suggested volume level | For example Code Orange suggests surge | The patient wording is the same fixed, reviewed text for every code type. It can't be edited per type. ## Defaults [#defaults] Ontario hospital colour codes: medical (Blue, Pink, trauma team activation, stroke, STEMI, critical patient arriving), security (White, Purple, Silver, Yellow, Amber, Black) and facility (Red, Green, Grey, Brown, Orange). Stroke and STEMI are staff-only by default because those teams work largely outside the ED physician's workflow. Optional templates: rapid response, massive transfusion, CBRN. ## Paging [#paging] | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | codes.notifyThrottleMinutes | 30 | 15–120 minutes | Delay-notice push throttle per patient. | | codes.autoNotifyFromFeed | false | boolean | Feed codes post the notice without a prompt (never skips the subject step). | | codes.edRespondsOutside | false | boolean | Prompt the charge nurse for codes outside the ED. | | codes.pagingEdLocations | [] | array | Paging locations inside the ED. | * **Paging ED locations** decides which paged codes are inside the ED. Codes elsewhere are staff-only and prompt nobody. * **ED responds outside** (small single-physician sites) prompts the charge nurse for codes outside the ED. * **Auto-notify from feed** only skips the second confirmation once the charge nurse has named the patient; it never notifies before that. ## Related [#related] * [Codes](/staff/charge/codes) * [Calling a code](/staff/physicians/calling-a-code) # Hospital information (https://docs.edflow.space/admin/settings/hospital-information) Set the hospital information patients and family see in EDFlow: names, address and entrance, phones, Wi-Fi, parking, visitor policies, wayfinding points with maps, the patient portal and co-branding. Hospital information feeds the hospital entry page, the patient and family **Hospital info** screens and the waiting-room display. Write it in English and French. ![Hospital information: names in English and French, address, phone numbers, Wi-Fi and the patient portal link.](https://docs.edflow.space/screenshots/web/admin-settings-site.png) ## Fields [#fields] | Field | Where patients see it | | -------------------------------------- | --------------------------------------------------------- | | Names (EN, FR) and short name | Everywhere | | Address, entrance, Maps link | Entry page, family info ("Open in Maps") | | Main phone | Contact section | | Wi-Fi network and password | Wi-Fi section, with copy buttons | | Parking and payment | Parking section | | Visitor policy and caregiver policy | Visitors and caregivers | | Hours (food, pharmacy…) | Around the department | | Patient relations and privacy office | Contact, and patient Settings → Privacy | | Patient portal name and URL | Going-home summary, the admitted screen, read-only banner | | Official wait-times URL | Entry page | | Interpreter and accessibility services | Interpreters and accessibility | | Time zone | All times (family see "Times are shown in … time") | A live preview shows the entry page and the patient screen as you type. ## Wayfinding points [#wayfinding-points] Each point has a category (washroom, water, food, charging, pharmacy, quiet room, exit, parking pay station), a name, text directions, hours, and optionally a floor-map image. A map image can't be saved without alt text. ## Trust anchors [#trust-anchors] The main phone, patient portal URL, Maps link, patient-relations and privacy-office contacts are **trust anchors**: patients act on them. Changing one needs a fresh sign-in check and a second approver, and alerts the privacy officer. A portal URL must be on the site's trusted domains. ## Co-branding [#co-branding] In production, the site's logo can appear next to the product mark on patient screens, cards and the display, following the co-branding rules in [Hospital communications](/brand/hospital-communications). Logos are sanitised on upload. ## Related [#related] * [Hospital info](/patients/hospital-info), the patient's view * [Waiting-room display](/admin/settings/waiting-room-display) # Site settings (https://docs.edflow.space/admin/settings) How EDFlow site settings work: allowed ranges, settings locked in production, privacy-reducing changes, approvals, history and revert, configuration transfer, and the full settings reference. Every site setting has a default, an allowed range, a plain explanation and a history. The table at the bottom of this page is generated from the same specification the admin forms and the server use, so it is always current. ![Hospital information: names in English and French, address, phone numbers, Wi-Fi and the patient portal link.](https://docs.edflow.space/screenshots/web/admin-settings-site.png) ## How changes are checked [#how-changes-are-checked] * **Ranges**: values outside the allowed range are refused by the server, not just the form. * **Locked**: some settings are fixed everywhere (for example MFA for administrators) or fixed in production (MFA for all staff). * **Privacy-reducing**: turning on something that shows more (named clinician metrics, room labels, detailed lock-screen text) needs a typed confirmation and a fresh sign-in check, and is audited with before and after values. * **Trust anchors**: the main phone, patient portal URL, Maps link and the patient-relations and privacy-office contacts need a second approver, because patients rely on them. * Every change goes through one path, so the same checks apply in the UI, imports and reverts. ## History and revert [#history-and-revert] **Settings → History** lists every version of the site's settings and catalogues with who, when and what changed. **Revert** creates a new version with the old values, under the same checks. ## Configuration transfer [#configuration-transfer] Export the site's configuration (settings, catalogues, content, request and code types, zones; never patient data, keys or users) as a signed file, and import it into another site with a diff preview. The import applies all or nothing. Use it to promote a tested configuration to production or to clone a site. ## Admin search [#admin-search] One search box over users, invites, content, request and code types, tests, sources and settings keys, filtered by what you can open. Patients are never searched here. ## Setting groups [#setting-groups] | Group | Page | | ------------------------------------------- | --------------------------------------------------------------- | | Hospital information | [Hospital information](/admin/settings/hospital-information) | | Zones, beds, shifts, reassessment intervals | [Zones, beds and shifts](/admin/settings/zones-beds-and-shifts) | | Request types and service levels | [Request types](/admin/settings/request-types) | | Code types | [Code types](/admin/settings/code-types) | | Tests, benchmarks and estimates | [Tests and benchmarks](/admin/settings/tests-and-benchmarks) | | Content, tasks and going-home templates | [Patient content](/admin/settings/patient-content) | | Languages | [Languages](/admin/settings/languages) | | Privacy, access and retention | [Privacy and retention](/admin/settings/privacy-and-retention) | | Notifications | [Notifications](/admin/settings/notifications) | | Waiting-room display | [Waiting-room display](/admin/settings/waiting-room-display) | | AI | [AI](/admin/ai) | ## Every setting [#every-setting] | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | flow.piaSource | attending_assigned | attending_assigned, explicit | Which event counts as the physician initial assessment (NACRS PIA only when explicit). | | flow.piaRoles | ["attending","resident","nurse_practitioner"] | array | Clinician types whose assignment counts as the PIA. | | flow.assignmentNotifyHoldMinutes | 10 | 5–15 minutes | How long a provider assignment is held before the patient is told (D-25). | | flow.seenInference.firstOrderByAssigned | true | boolean | The assigned clinician's first order infers "seen". | | flow.seenInference.consultRequest | true | boolean | A consult request infers "seen". | | flow.seenInference.disposition | true | boolean | A disposition infers "seen". | | flow.reassessmentInference.newOrderAfterAllBack | true | boolean | A new order after all results are back infers reassessment (D-26). | | flow.reassessmentInference.consultRequest | true | boolean | A consult request infers reassessment. | | flow.reassessmentInference.noteSigned | true | boolean | A signed note infers reassessment. | | flow.reassessmentInference.procedureArea | true | boolean | A move to a procedure area infers reassessment. | | flow.resultComplete.lab | resulted | in_lab, in_progress, performed, preliminary, resulted | Lab status that counts as "Back". | | flow.resultComplete.imaging | preliminary | in_lab, in_progress, performed, preliminary, resulted | Imaging status that counts as "Back" (D-28). | | flow.resultComplete.cardiology | performed | in_lab, in_progress, performed, preliminary, resulted | Cardiology status that counts as "Back". | | flow.resultComplete.imagingByModality | [] | array | Per-modality imaging thresholds, e.g. X-ray at performed where ED physicians read their own films. | | flow.resultsReviewedCountsForImaging | true | boolean | An imaging order with results reviewed counts as "Back". | | flow.manualProfile | lite | lite, full | Manual-mode depth at sites without a feed (D-46). | | flow.manualStaleMinutes | 90 | 30–240 minutes | Manual-lite prompt after this long without an update. | | flow.noUpdateAlertHours | 12 | 4–24 hours | "No updates" alert for the charge nurse (D-50). | | flow.observationIsCdu | false | boolean | Observation happens in a clinical decision unit. | | imaging.serviceHours | [] | array | Modality service hours; empty means 24/7 (D-28). | | imaging.downtime | [] | array | Current imaging downtime per modality (set from W-S06). | | results.displayDelayMinutes | 0 | 0–30 minutes | Delay before a completed result shows as "Back" to the patient. | | results.holdAllowed | true | boolean | Clinicians may hold results (D-29). | | lifecycle.deceasedPauseHours | 24 | 1–72 hours | Pause length after a deceased disposition (D-21). | | reassessment.intervals.ctas2 | 15 | 5–240 minutes | Waiting-room reassessment interval for CTAS 2 (D-53). | | reassessment.intervals.ctas3 | 30 | 5–240 minutes | Waiting-room reassessment interval for CTAS 3. | | reassessment.intervals.ctas4 | 60 | 5–240 minutes | Waiting-room reassessment interval for CTAS 4. | | reassessment.intervals.ctas5 | 120 | 5–240 minutes | Waiting-room reassessment interval for CTAS 5. | | cards.autoPrint | true | boolean | Visit cards print automatically at the print station. | | cards.printAt | after_triage | after_triage, registration | When the card prints (D-43). | | cards.form | card | card, wristband_label | Card or wristband label (discouraged; forces the date-of-birth check on every device, D-51). (Reduces privacy) | | cards.nameDisplay | initials | initials, first_initial, none | Name printed on the visit card. (Reduces privacy) | | cards.shortUrl | — | string | Printed "go to" URL on the card; https on a trusted domain. (Reduces privacy) | | tasks.urineMinAge | 4 | 0–10 age_years | Minimum age for the urine task T-01 (D-44). | | tasks.derivedDelayMinutes | 3 | 0–10 minutes | Delay before derived tasks appear. | | tasks.consentStyle | written | written, verbal | Consent task wording (T-02). | | tasks.consentWho | {"en":"Your nurse","fr":"Votre infirmière ou infirmier"} | object | Who explains the test in the verbal consent task. | | tasks.pregnancyCheckAges.min | 12 | 10–60 age_years | Youngest age for the pregnancy check T-05. | | tasks.pregnancyCheckAges.max | 55 | 10–60 age_years | Oldest age for the pregnancy check T-05. | | capacity.treatmentSpaces | 30 | 1–500 count | Treatment-space capacity, the occupancy denominator (F-08.3). | | privacy.dataProfile | standard | standard, minimal | Data minimization profile (EHR §11.3). (Reduces privacy) | | access.patientGraceHours | 72 | 0–168 hours | How long patient access lasts after departure (D-05). (Reduces privacy) | | access.familyGraceMinutes | 120 | 0–1440 minutes | How long family links last after departure. (Reduces privacy) | | retention.operationalWindowDays | 30 | 7–90 days | Days PHI is kept before de-identification (F-21.2). (Reduces privacy) | | retention.auditDays | 730 | 730–3650 days | Audit log retention. (Reduces privacy) | | retention.analyticsDays | 730 | 365–2555 days | De-identified analytics retention. (Reduces privacy) | | access.guardianAge | 16 | 0–18 age_years | Guardian mode applies below this age. (Reduces privacy) | | access.youthConfidentialAges.min | 12 | 10–18 age_years | Youngest age for youth-confidential mode (D-43). (Reduces privacy) | | access.youthConfidentialAges.max | 17 | 10–18 age_years | Oldest age for youth-confidential mode. (Reduces privacy) | | access.recipientPrompt | true | boolean | Triage asks who receives the card (D-43). (Reduces privacy) | | access.visitCodeSource | edflow | edflow, ehr_visit_number | Random codes or the EHR visit number (only with attested non-sequential numbers; never under minimal). (Reduces privacy) | | retention.safetyRecordYears | 10 | 2–30 years | Retention of care records (D-36). (Reduces privacy) | | sharing.enabled | true | boolean | Patients can share with family. (Reduces privacy) | | sharing.maxLinks | 5 | 1–5 count | Active family links per visit. (Reduces privacy) | | sharing.maxDevicesPerLink | 3 | 1–5 count | Devices per family link (D-14). (Reduces privacy) | | family.showPhotos | false | boolean | Care-team photos in the family view. (Reduces privacy) | | careTeam.namePolicy | first_last_initial | first_last_initial, first_only | How non-physician staff names show to patients (physicians always "Dr. First Last"). (Reduces privacy) | | careTeam.allowPhotos | true | boolean | Staff may opt in to show photos. (Reduces privacy) | | careTeam.photoApproval | true | boolean | Photos need manager approval. (Reduces privacy) | | careTeam.showOtherRoles | true | boolean | Show roles beyond physician and nurse. (Reduces privacy) | | patient.showRoomLabel | false | boolean | Show the room or bed label to the patient. (Reduces privacy) | | careTeam.showTriageNurseName | false | boolean | Show the triage nurse's name. (Reduces privacy) | | bigBoard.nameDisplay | initials | initials, first_last_initial | Names on big-board stations. (Reduces privacy) | | privacy.maskConfidentialNamesOnBoard | true | boolean | Mask confidential names on the board. (Reduces privacy) | | estimates.hideBeforePiaForCtas | [1,2] | array | CTAS levels whose estimate is hidden before the patient is seen (SR-07). | | estimates.showBoardingEstimate | false | boolean | Show the boarding estimate (D-32). | | estimates.streamDimension | true | boolean | Use the stream in triage-to-seen buckets (D-33). | | avs.enabled | true | boolean | After-visit summaries are available. | | avs.allowVisitReason | false | boolean | The AVS may state the visit reason. (Reduces privacy) | | avs.medicationsSection | off | off, prescribers_attested | AVS medicines section with prescriber attestation (D-35). | | analytics.clinicianMetrics | false | boolean | Clinician-level metrics (EHR §12). (Reduces privacy) | | analytics.namedClinicianMetrics | false | boolean | Named clinician metrics; requires clinician metrics (D-20). (Reduces privacy) | | analytics.nurseMetrics | false | boolean | Nurse self-view metrics. (Reduces privacy) | | analytics.minCell | 5 | 5–20 count | Small-cell suppression threshold. (Reduces privacy) | | security.mfaRequiredForAll | true | boolean | MFA for every password sign-in (locked on in production, D-13). (Reduces privacy) | | security.mfaRequiredForAdmins | true | boolean | MFA for manager, privacy and integration roles (locked on everywhere). (Locked, Reduces privacy) | | security.staffIdleLockMinutes | 15 | 5–60 minutes | Staff idle lock. (Reduces privacy) | | security.staffSessionHours | 12 | 8–16 hours | Staff absolute session lifetime. (Reduces privacy) | | security.staffEmailDomains | [] | array | Invite domains that need no approval (D-64). (Reduces privacy) | | security.guestNetworkPrefixes | [] | array | Guest-network prefixes named in breaker alerts, never hard-blocked. (Reduces privacy) | | sso.allowedDomains | [] | array | Entra ID sign-in domains. (Reduces privacy) | | sso.allowedTenants | [] | array | Entra ID tenant ids (guests always refused). (Reduces privacy) | | research.surveyConsentEnabled | false | boolean | Offer the research consent on the survey. (Reduces privacy) | | training.enabled | false | boolean | Training mode is available at this site (F-33.3). | | estimates.windowWeeks | 12 | 4–26 weeks | Sample window for estimates (F-05.3). | | estimates.minSamples | 20 | 10–100 count | Minimum samples per ladder level. | | estimates.flowDefaults | [{"dimension":"","metricKey":"flow.arrival_to_triage","p50":10,"p75":15,"p90":30},{"dimension":"1","metricKey":"flow.triage_to_seen","p50":0,"p75":0,"p90":5},{"dimension":"2","metricKey":"flow.triage_to_seen","p50":15,"p75":25,"p90":45},{"dimension":"3","metricKey":"flow.triage_to_seen","p50":60,"p75":90,"p90":180},{"dimension":"4","metricKey":"flow.triage_to_seen","p50":90,"p75":120,"p90":240},{"dimension":"5","metricKey":"flow.triage_to_seen","p50":90,"p75":135,"p90":240},{"dimension":"1","metricKey":"flow.triage_to_pia","p50":0,"p75":0,"p90":5},{"dimension":"2","metricKey":"flow.triage_to_pia","p50":15,"p75":25,"p90":45},{"dimension":"3","metricKey":"flow.triage_to_pia","p50":60,"p75":90,"p90":180},{"dimension":"4","metricKey":"flow.triage_to_pia","p50":90,"p75":120,"p90":240},{"dimension":"5","metricKey":"flow.triage_to_pia","p50":90,"p75":135,"p90":240},{"dimension":"","metricKey":"flow.seen_to_first_order","p50":15,"p75":25,"p90":45},{"dimension":"","metricKey":"flow.seen_to_decision_no_tests","p50":30,"p75":45,"p90":90},{"dimension":"","metricKey":"flow.testing","p50":120,"p75":160,"p90":240},{"dimension":"","metricKey":"flow.results_to_reassessment","p50":30,"p75":45,"p90":90},{"dimension":"","metricKey":"flow.boarding","p50":360,"p75":720,"p90":1440},{"dimension":"","metricKey":"flow.discharge_to_cleared","p50":20,"p75":30,"p90":60},{"dimension":"","metricKey":"flow.cleared_to_departure","p50":5,"p75":10,"p90":20}] | array | Default flow benchmarks (Appendix B.4). | | requests.slaMultiplier.urgent | 1 | 0.5–2 multiplier | SLA multiplier for urgent requests (F-09.6). | | requests.slaMultiplier.high | 1 | 0.5–2 multiplier | SLA multiplier for high requests (F-09.6). | | requests.slaMultiplier.normal | 1 | 0.5–2 multiplier | SLA multiplier for normal requests (F-09.6). | | requests.slaMultiplier.low | 1 | 0.5–2 multiplier | SLA multiplier for low requests (F-09.6). | | requests.maxPerHour | 12 | 1–60 count | Non-urgent requests per visit per hour. | | requests.urgentGoingNowMinutes | 5 | 3–10 minutes | "Going now" pauses escalation this long (D-23). | | requests.excludeTriageFromComfort | false | boolean | Keep the triage nurse out of comfort routing (D-37). | | codes.notifyThrottleMinutes | 30 | 15–120 minutes | Delay-notice push throttle per patient. | | codes.autoNotifyFromFeed | false | boolean | Feed codes post the notice without a prompt (never skips the subject step). | | codes.edRespondsOutside | false | boolean | Prompt the charge nurse for codes outside the ED. | | codes.pagingEdLocations | [] | array | Paging locations inside the ED. | | volume.reviewAfterHours | 4 | 1–12 hours | Prompt to review the volume level. | | volume.acceptFeedLevel | false | boolean | Apply the feed's volume level directly. | | volume.thresholds.busy.waiting | 12 | 1–500 count | Volume suggestion threshold: busy waiting (F-08.3). | | volume.thresholds.busy.boarding | 8 | 1–500 count | Volume suggestion threshold: busy boarding (F-08.3). | | volume.thresholds.busy.occupancy | 0.95 | 0.1–5 ratio | Volume suggestion threshold: busy occupancy (F-08.3). | | volume.thresholds.busy.waitRatio | 1.25 | 0.1–10 ratio | Volume suggestion threshold: busy waitRatio (F-08.3). | | volume.thresholds.veryBusy.waiting | 20 | 1–500 count | Volume suggestion threshold: veryBusy waiting (F-08.3). | | volume.thresholds.veryBusy.boarding | 12 | 1–500 count | Volume suggestion threshold: veryBusy boarding (F-08.3). | | volume.thresholds.veryBusy.occupancy | 1.1 | 0.1–5 ratio | Volume suggestion threshold: veryBusy occupancy (F-08.3). | | volume.thresholds.veryBusy.waitRatio | 1.75 | 0.1–10 ratio | Volume suggestion threshold: veryBusy waitRatio (F-08.3). | | analytics.ontarioTargets.admitted | 480 | 30–2880 minutes | Ontario target, admitted (D-48). | | analytics.ontarioTargets.nonAdmittedHigh | 480 | 30–2880 minutes | Ontario target, non-admitted CTAS 1–3. | | analytics.ontarioTargets.nonAdmittedLow | 240 | 30–2880 minutes | Ontario target, non-admitted CTAS 4–5. | | analytics.ontarioTargets.emsOffload | 30 | 5–240 minutes | Ontario target, EMS offload. | | notifications.push | true | boolean | Push notifications (effective only when the provider is configured). (Reduces privacy) | | notifications.patientSms | true | boolean | Patient SMS updates (US sub-processor, Q-15). (Reduces privacy) | | notifications.familySms | true | boolean | Family SMS updates. (Reduces privacy) | | notifications.email | true | boolean | Patient summary-link email. (Reduces privacy) | | notifications.pushPreviewDefault | generic | generic, detailed | Default push preview (D-11). (Reduces privacy) | | notifications.pushPerHour | 6 | 1–20 count | Push budget per patient per hour. | | notifications.smsPerDay | 3 | 0–10 count | SMS budget per patient per day. | | notifications.staffCodePush | false | boolean | Staff push when a code is called (D-38). | | notifications.staffBedInPush | false | boolean | Bed label in staff push text. (Reduces privacy) | | notifications.brandedLabelApproved | false | boolean | The privacy office approved the branded SMS and push label (BR-13). (Reduces privacy) | | languages.safetyLocales | [] | array | Up to five safety locales (D-52). | | feed.delayedAfterMinutes | 5 | 1–60 minutes | Feed is "delayed" after this silence (F-16.1). | | feed.downAfterMinutes | 15 | 2–240 minutes | Feed is "down" after this silence. | | integration.alertEmails | [] | array | Recipients of feed and integration alerts (≤ 10). (Reduces privacy) | | display.access | public | public, key | Waiting-room display is public or needs a display key. (Reduces privacy) | | display.showTypicalWait | false | boolean | Show the official typical wait (D-18). | | display.typicalWaitSource | feed | feed, manual | Source of the typical wait. | | display.manualTypicalWait | — | object | Manual typical wait with the time it was set. | | display.languageMode | alternate | alternate, side_by_side, english_only | Display language mode: English and French in turn, side by side, or English only (owner, 2026-09-26). | | display.orientation | landscape | landscape, portrait | Display orientation. | | display.allowEmbed | false | boolean | Allow framing by the embed origins. (Reduces privacy) | | display.embedOrigins | [] | array | Exact https origins allowed to frame the display (never "*"). (Reduces privacy) | | display.slideSlugs | [] | array | Display loop slides. | | integration.api.reads | false | boolean | Allows encounters, care-team, requests and tasks reads at this site (F-34.4). (Reduces privacy) | | integration.api.includeCodeArea | true | boolean | Code alerts in the API include the area label. (Reduces privacy) | | integration.requestWriteback | false | boolean | Allows requests:write. (Reduces privacy) | | integration.webhooks.enabled | false | boolean | Outbound webhook deliveries for this site. (Reduces privacy) | | integration.storeVisitNumberEncrypted | false | boolean | Exposes externalRef on encounters and webhooks. (Reduces privacy) | | integration.rosterMaxClose | 5 | 1–50 count | Roster circuit breaker: encounters one roster may close. (Reduces privacy) | | integration.rosterMaxClosePct | 20 | 5–50 percent | Roster circuit breaker: share of the census. (Reduces privacy) | | ai.enabled | false | boolean | AI features at this site (F-35.3 layer 4). (Reduces privacy) | | ai.features.patientAssistant | false | boolean | AI feature: patientAssistant. (Reduces privacy) | | ai.features.familyHelper | false | boolean | AI feature: familyHelper. (Reduces privacy) | | ai.features.familyCatchUp | false | boolean | AI feature: familyCatchUp. (Reduces privacy) | | ai.features.testExplainers | false | boolean | AI feature: testExplainers. (Reduces privacy) | | ai.features.machineTranslation | false | boolean | AI feature: machineTranslation. (Reduces privacy) | | ai.features.voiceNative | false | boolean | AI feature: voiceNative. (Reduces privacy) | | ai.features.voiceWeb | false | boolean | AI feature: voiceWeb. (Reduces privacy) | | ai.features.requestDigest | false | boolean | AI feature: requestDigest. (Reduces privacy) | | ai.features.quickReplies | false | boolean | AI feature: quickReplies. (Reduces privacy) | | ai.features.handover | false | boolean | AI feature: handover. (Reduces privacy) | | ai.features.patientMessageDrafts | false | boolean | AI feature: patientMessageDrafts. (Reduces privacy) | | ai.features.askData | false | boolean | AI feature: askData. (Reduces privacy) | | ai.features.insights | false | boolean | AI feature: insights. (Reduces privacy) | | ai.features.weeklyReport | false | boolean | AI feature: weeklyReport. (Reduces privacy) | | ai.features.anomalies | false | boolean | AI feature: anomalies. (Reduces privacy) | | ai.features.mappingAssistant | false | boolean | AI feature: mappingAssistant. (Reduces privacy) | | ai.features.catalogChecks | false | boolean | AI feature: catalogChecks. (Reduces privacy) | | ai.features.contentAuthoring | false | boolean | AI feature: contentAuthoring. (Reduces privacy) | | ai.features.feedbackThemes | false | boolean | AI feature: feedbackThemes. (Reduces privacy) | | ai.features.commandAssistant | false | boolean | AI feature: commandAssistant. (Reduces privacy) | | ai.features.auditExplainer | false | boolean | AI feature: auditExplainer. (Reduces privacy) | | ai.patientLanguages | [] | array | Machine-translated patient languages (each enabled in aiLanguages). (Reduces privacy) | | ai.monthlyBudgetUsd | 500 | 0–100000 usd | Site AI budget per month (AI_DEFAULT_SITE_BUDGET_USD). | | ai.conversationRetentionDays | 7 | 0–30 days | Days AI conversations are kept after the session ends. (Reduces privacy) | | ai.safetyReviewSampleRate | 0 | 0–1 ratio | Random sampling of unflagged conversations; > 0 only with randomSampleApproval. (Reduces privacy) | | ai.selfHarmAutoAlert | true | boolean | Self-harm sends a structured urgent alert; off only with selfHarmAlertWaiver (D-AI-03). (Reduces privacy) | | ai.distressAutoAlertSeconds | 60 | 30–120 seconds | Red-flag distress alert delay (D-AI-03). | | ai.showAssistantByDefault | true | boolean | Show the assistant entry point by default. | | ai.crossSitePeerRanges | false | boolean | Cross-site peer ranges (AI-15, Q-AI-06). (Reduces privacy) | | ai.governance.privacyApproval | — | object | Governance gate record: privacyApproval. (Reduces privacy) | | ai.governance.regulatoryMemo | — | object | Governance gate record: regulatoryMemo. (Reduces privacy) | | ai.governance.evalSignoff | — | object | Governance gate record: evalSignoff. (Reduces privacy) | | ai.governance.piaTra | — | object | Governance gate record: piaTra. (Reduces privacy) | | ai.governance.hazardLog | — | object | Governance gate record: hazardLog. (Reduces privacy) | | ai.governance.staffBriefing | — | object | Governance gate record: staffBriefing. (Reduces privacy) | | ai.governance.mappingAssistantPrivacyApproval | — | object | Governance gate record: mappingAssistantPrivacyApproval. (Reduces privacy) | | ai.governance.randomSampleApproval | — | object | Governance gate record: randomSampleApproval. (Reduces privacy) | | ai.governance.selfHarmAlertWaiver | — | object | Governance gate record: selfHarmAlertWaiver. (Reduces privacy) | | ai.governance.safetyReviewers | [] | array | The designated AI safety review group (§2.4 footnote 8). (Reduces privacy) | | messaging.patientFacingLabel | neutral | neutral, branded | Neutral or branded SMS and push label; branded needs brandedLabelApproval (BR-13). (Reduces privacy) | | messaging.brandedLabelApproval | — | object | Recorded privacy approval for the branded label (audited). (Reduces privacy) | # Languages (https://docs.edflow.space/admin/settings/languages) Configure languages in EDFlow: English and French, the site default and active offer of French, up to five safety locales for the safety-critical messages, and translation completeness. ![Languages: English and French for the app, plus the safety languages for the I feel worse message.](https://docs.edflow.space/screenshots/web/admin-settings-languages.png) ## Full languages [#full-languages] English and French are available at launch. Choose the site default and whether to **actively offer** French on first view. A full language can only be enabled when the patient, family, notification and display text is 100% translated. ## Safety locales [#safety-locales] Add up to five languages for the safety-critical messages: the safety panel, "I feel worse", delay notices and the not-an-emergency line. A safety locale can be enabled only when that text is 100% professionally translated and reviewed. Choose the languages most spoken by your community, using the adoption page's language breakdown. | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | languages.safetyLocales | [] | array | Up to five safety locales (D-52). | ## Hospital content [#hospital-content] Hospital information and patient content are written per language. A missing French entry falls back to English on the patient screen. ## Machine translation [#machine-translation] Where the site turns on AI translation for a language, it translates only reviewed text and shows a translation badge. Safety text in a new language always goes through human review first. See [AI](/admin/ai). ## Related [#related] * [Languages and accessibility](/start/languages-and-accessibility) * [Adoption and equity](/admin/analytics/adoption-and-equity) # Notifications (https://docs.edflow.space/admin/settings/notifications) Configure EDFlow notification channels per site: push, patient and family text messages (Twilio), email (Resend), the generic lock-screen default, rate caps, sending a test, and clinical communication platforms. ![Notification channels: push, SMS and email on or off, with a preview of the generic message text.](https://docs.edflow.space/screenshots/web/admin-settings-notifications.png) ## Channels [#channels] The page shows whether each provider is configured (push, text messages, email), read from the deployment's configuration without ever showing a key. Turn each channel on or off per site. | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | notifications.push | true | boolean | Push notifications (effective only when the provider is configured). (Reduces privacy) | | notifications.patientSms | true | boolean | Patient SMS updates (US sub-processor, Q-15). (Reduces privacy) | | notifications.familySms | true | boolean | Family SMS updates. (Reduces privacy) | | notifications.email | true | boolean | Patient summary-link email. (Reduces privacy) | | notifications.pushPreviewDefault | generic | generic, detailed | Default push preview (D-11). (Reduces privacy) | | notifications.pushPerHour | 6 | 1–20 count | Push budget per patient per hour. | | notifications.smsPerDay | 3 | 0–10 count | SMS budget per patient per day. | | notifications.staffCodePush | false | boolean | Staff push when a code is called (D-38). | | notifications.staffBedInPush | false | boolean | Bed label in staff push text. (Reduces privacy) | | notifications.brandedLabelApproved | false | boolean | The privacy office approved the branded SMS and push label (BR-13). (Reduces privacy) | ## What's sent [#whats-sent] Every notification uses fixed, generic text: the lock screen says only "You have a new update." unless the patient chooses the detailed variant, and even that never includes a test name, a result or the hospital's name. Texts contain a link and nothing else. Codes never send texts or email. See [Updates and notifications](/patients/updates-and-notifications). A detailed lock-screen **default** reduces privacy, so it needs a fresh sign-in check and typed confirmation. ## Send a test [#send-a-test] **Send a test** sends to your own verified phone or email only. When a provider isn't configured, the test goes to the outbox instead. ## Staff notifications [#staff-notifications] The "Code called" staff push is off by default. Bed labels in staff push are off by default. ## Clinical communication platforms [#clinical-communication-platforms] Optionally, forward urgent and high requests, escalations and unanswered call-backs to the hospital's clinical communication platform (Vocera, Spok, Ascom, Microsoft Teams, or generic HTTPS): * endpoint URL (`https` and public addresses only); * which events; * the routing map from zones and pools to platform groups; * whether "Going now" and "Can't go" come back; * a signing key revealed once, **Send a test**, and delivery health. Payloads carry no patient details. | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | messaging.patientFacingLabel | neutral | neutral, branded | Neutral or branded SMS and push label; branded needs brandedLabelApproval (BR-13). (Reduces privacy) | | messaging.brandedLabelApproval | — | object | Recorded privacy approval for the branded label (audited). (Reduces privacy) | ## Related [#related] * [Message outbox](/admin/privacy/message-outbox) # Patient content (https://docs.edflow.space/admin/settings/patient-content) Govern patient-facing content in EDFlow: education sheets, going-home templates, task templates, FAQ and glossary; the draft, clinical review, approval and publish workflow; and AI drafting help. Everything patients read beyond the product's own wording is hospital content, and it goes through clinical governance before any patient sees it. ![Patient content: education sheets, after-visit summary templates and FAQ, each with draft, approved or published status.](https://docs.edflow.space/screenshots/web/admin-settings-content.png) ## What counts as patient content [#what-counts-as-patient-content] * Education sheets (for example what happens during a CT scan). * Going-home templates: instruction sets, red flags, resources, and the pharmacist-approved medicine phrase library. * Observation plan templates. * FAQ entries, glossary terms, interpreter and accessibility information, "How the ED works" cards. * Task templates (see below). ## The workflow [#the-workflow] ### Draft [#draft] Anyone with `content.manage` writes the English and French versions side by side. The editor shows a reading-level score, banned-word warnings and a patient preview. ### In review [#in-review] The draft goes to a clinical approver. ### Approved and published [#approved-and-published] A clinical approver (a membership marked clinical approver, with `content.approve`) approves it; publishing makes it visible. The sheet shows "Reviewed by … on … · Version …". ### Retired [#retired] Retired content disappears from patient screens. Every version is kept. ![Content approval: a draft education sheet with its changes, awaiting a clinical approver's decision.](https://docs.edflow.space/screenshots/web/admin-content-approval.png) In production, nothing reaches patients without an approved, published version. Outside production, unapproved sheets show "Clinical review pending". ## Task templates [#task-templates] ![Task templates: approved tasks nurses can add for patients, such as samples and restrictions.](https://docs.edflow.space/screenshots/web/admin-settings-tasks.png) Each template has a key, kind (action, info, restriction), title and body in both languages, icon, and whether completion notifies the nurse. The tasks created from orders (urine samples, consent, check before eating, nothing by mouth, pregnancy check, MRI safety, full bladder, oral contrast) are listed read-only. See [Tasks](/staff/nurses/tasks). ## Writing help with AI [#writing-help-with-ai] Where the site turns it on: * **Test explainers**: a draft plain-language description of what a test is and what happens during it, the same for every patient. It goes through the same review; patients only ever see the approved version. * **Authoring help**: rewrite a draft in plainer words or check it against the writing rules. AI output is always a draft, labelled as AI-assisted, and never published without a clinical approver. Explainers never describe why a test was ordered for someone, reference ranges or risks. ## Writing rules [#writing-rules] See [Writing patient content](/brand/writing-patient-content). | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | tasks.urineMinAge | 4 | 0–10 age_years | Minimum age for the urine task T-01 (D-44). | | tasks.derivedDelayMinutes | 3 | 0–10 minutes | Delay before derived tasks appear. | | tasks.consentStyle | written | written, verbal | Consent task wording (T-02). | | tasks.consentWho | {"en":"Your nurse","fr":"Votre infirmière ou infirmier"} | object | Who explains the test in the verbal consent task. | | tasks.pregnancyCheckAges.min | 12 | 10–60 age_years | Youngest age for the pregnancy check T-05. | | tasks.pregnancyCheckAges.max | 55 | 10–60 age_years | Oldest age for the pregnancy check T-05. | # Privacy and retention (https://docs.edflow.space/admin/settings/privacy-and-retention) Configure EDFlow privacy and access settings: patient and family access windows, sharing limits, the data profile, youth-confidential ages, results display delay, retention periods and de-identification. Every privacy and access setting shows its allowed range and a plain explanation. Changes that reduce privacy need a typed confirmation and are audited with before and after values. ![Privacy, access and retention: access windows, family windows, the results display delay and retention periods, with allowed ranges.](https://docs.edflow.space/screenshots/web/admin-settings-privacy.png) ## Access windows [#access-windows] How long patients and family keep read-only access after departure: | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | access.patientGraceHours | 72 | 0–168 hours | How long patient access lasts after departure (D-05). (Reduces privacy) | | access.familyGraceMinutes | 120 | 0–1440 minutes | How long family links last after departure. (Reduces privacy) | | access.guardianAge | 16 | 0–18 age_years | Guardian mode applies below this age. (Reduces privacy) | | access.youthConfidentialAges.min | 12 | 10–18 age_years | Youngest age for youth-confidential mode (D-43). (Reduces privacy) | | access.youthConfidentialAges.max | 17 | 10–18 age_years | Oldest age for youth-confidential mode. (Reduces privacy) | | access.recipientPrompt | true | boolean | Triage asks who receives the card (D-43). (Reduces privacy) | | access.visitCodeSource | edflow | edflow, ehr_visit_number | Random codes or the EHR visit number (only with attested non-sequential numbers; never under minimal). (Reduces privacy) | ## Sharing [#sharing] | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | sharing.enabled | true | boolean | Patients can share with family. (Reduces privacy) | | sharing.maxLinks | 5 | 1–5 count | Active family links per visit. (Reduces privacy) | | sharing.maxDevicesPerLink | 3 | 1–5 count | Devices per family link (D-14). (Reduces privacy) | | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | family.showPhotos | false | boolean | Care-team photos in the family view. (Reduces privacy) | ## Data profile and masking [#data-profile-and-masking] * **Standard**: patients sign in with last name, date of birth and an 8-character visit code. * **Minimal**: a 10-character visit code only; patients type the first name they want to be called. Staff register initials. | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | privacy.dataProfile | standard | standard, minimal | Data minimization profile (EHR §11.3). (Reduces privacy) | | privacy.maskConfidentialNamesOnBoard | true | boolean | Mask confidential names on the board. (Reduces privacy) | ## Results [#results] | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | results.displayDelayMinutes | 0 | 0–30 minutes | Delay before a completed result shows as "Back" to the patient. | | results.holdAllowed | true | boolean | Clinicians may hold results (D-29). | ## Retention [#retention] | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | retention.operationalWindowDays | 30 | 7–90 days | Days PHI is kept before de-identification (F-21.2). (Reduces privacy) | | retention.auditDays | 730 | 730–3650 days | Audit log retention. (Reduces privacy) | | retention.analyticsDays | 730 | 365–2555 days | De-identified analytics retention. (Reduces privacy) | | retention.safetyRecordYears | 10 | 2–30 years | Retention of care records (D-36). (Reduces privacy) | Safety records (requests, call-backs, pauses, the going-home summary) are kept for the safety-record period so the hospital can answer complaints and reviews. Analytics use de-identified rows with no link to a visit. Legal holds pause deletion. See [Access requests and retention](/admin/privacy/access-requests-and-retention). ## Related [#related] * [Privacy](/patients/privacy), the patient's view * [PHIPA](/security/phipa) # Request types (https://docs.edflow.space/admin/settings/request-types) Edit the EDFlow request catalogue: enable, reorder and customise request types, routes and pools, FYI-only types, care-flag rules, service-level targets, and the locked I feel worse request. The request catalogue decides which tiles patients see, where each request goes and how fast it escalates. ![Request types: the catalogue patients choose from, with routing, limits and locked safety types.](https://docs.edflow.space/screenshots/web/admin-settings-requests.png) ## The default catalogue [#the-default-catalogue] 24 types: the 16 core requests (stepping out, back, washroom, help to the washroom, blanket, water, pain, nausea, IV, help with something else, eat or drink, when will I see the doctor, interpreter, question for the care team, thinking of leaving, I feel worse), plus a sign-language interpreter, Indigenous patient navigator, spiritual care, social work, nicotine cravings, and for admitted patients waiting for a bed: meal tray, next medicine, overnight visitor. You can add up to 30 custom types. ## Editing a type [#editing-a-type] | Field | Notes | | --------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Labels | English and French, plus the guardian wording ("My child…"). Previewed as a tile in every language, including the safety locales | | Icon | From the brand icon set | | Priority | Low, normal, high, urgent | | Routes | Ordered list: support pool, primary nurse, zone, triage pool (if waiting), triage pool, charge, physician, physician in charge | | Also notify | For example charge for "thinking of leaving" | | FYI only | Updates the board with no queue item, service level or sound (stepping out, back, washroom) | | Comfort | Eligible for the support pool | | Care-flag rules | Hide when a flag is set, show only when set, or make urgent (for example "thinking of leaving" with "must not leave") | | Stages | When the tile appears | | Confirmation | A fixed confirmation sheet, where one exists | | Reminder after | Default 10 min | **I feel worse** can't be disabled or edited, only reordered. ## Service levels [#service-levels] Targets by priority (urgent 2 min, high 5, normal 15, low 30) can be scaled from half to double, and the "Going now" timer set between 3 and 10 minutes. | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | requests.slaMultiplier.urgent | 1 | 0.5–2 multiplier | SLA multiplier for urgent requests (F-09.6). | | requests.slaMultiplier.high | 1 | 0.5–2 multiplier | SLA multiplier for high requests (F-09.6). | | requests.slaMultiplier.normal | 1 | 0.5–2 multiplier | SLA multiplier for normal requests (F-09.6). | | requests.slaMultiplier.low | 1 | 0.5–2 multiplier | SLA multiplier for low requests (F-09.6). | | requests.maxPerHour | 12 | 1–60 count | Non-urgent requests per visit per hour. | | requests.urgentGoingNowMinutes | 5 | 3–10 minutes | "Going now" pauses escalation this long (D-23). | | requests.excludeTriageFromComfort | false | boolean | Keep the triage nurse out of comfort routing (D-37). | ## Related [#related] * [Requests](/staff/requests) for staff * [Asking your care team](/patients/requests) for patients # Tests and benchmarks (https://docs.edflow.space/admin/settings/tests-and-benchmarks) The EDFlow test catalogue: EHR code mappings, patient-visible names and steps, sensitive and hidden tests, result thresholds per imaging modality, service hours, default benchmarks, estimate settings and historical import. The test catalogue turns EHR order codes into the plain-language tests patients see, and sets the defaults estimates use until the site has enough history. ![Test catalogue: tests with the steps patients see, sensitive tests, and default benchmarks by hour.](https://docs.edflow.space/screenshots/web/admin-settings-tests.png) ## Catalogue entries [#catalogue-entries] | Field | Notes | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | EHR codes | The order codes that map to this test | | Name and description | English and French, plain language ("Blood count"), abbreviation ("CBC") | | Group | Blood, urine, scans and X-rays, heart, other | | Flags | Sensitive (shown as "Additional test"), hidden from patients, counts toward all back, results later, needs consent, contrast, serial expected with a hold time | | Education | Linked education sheets | | Default benchmarks | p50, p75 and p90 minutes by priority | ## Consult services [#consult-services] Each service has plain names and a **sensitive** flag: sensitive services show as "A specialist" to patients. ## Imaging [#imaging] * **Result threshold per modality**: preliminary report by default, or "performed" for X-ray where ED physicians read their own films. * **Service hours and downtime per modality**: outside hours, patients see when the service opens instead of an estimate, and those intervals are excluded from benchmarks. | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | imaging.serviceHours | [] | array | Modality service hours; empty means 24/7 (D-28). | | imaging.downtime | [] | array | Current imaging downtime per modality (set from W-S06). | ## Estimates [#estimates] | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | estimates.hideBeforePiaForCtas | [1,2] | array | CTAS levels whose estimate is hidden before the patient is seen (SR-07). | | estimates.showBoardingEstimate | false | boolean | Show the boarding estimate (D-32). | | estimates.streamDimension | true | boolean | Use the stream in triage-to-seen buckets (D-33). | | estimates.windowWeeks | 12 | 4–26 weeks | Sample window for estimates (F-05.3). | | estimates.minSamples | 20 | 10–100 count | Minimum samples per ladder level. | | estimates.flowDefaults | [{"dimension":"","metricKey":"flow.arrival_to_triage","p50":10,"p75":15,"p90":30},{"dimension":"1","metricKey":"flow.triage_to_seen","p50":0,"p75":0,"p90":5},{"dimension":"2","metricKey":"flow.triage_to_seen","p50":15,"p75":25,"p90":45},{"dimension":"3","metricKey":"flow.triage_to_seen","p50":60,"p75":90,"p90":180},{"dimension":"4","metricKey":"flow.triage_to_seen","p50":90,"p75":120,"p90":240},{"dimension":"5","metricKey":"flow.triage_to_seen","p50":90,"p75":135,"p90":240},{"dimension":"1","metricKey":"flow.triage_to_pia","p50":0,"p75":0,"p90":5},{"dimension":"2","metricKey":"flow.triage_to_pia","p50":15,"p75":25,"p90":45},{"dimension":"3","metricKey":"flow.triage_to_pia","p50":60,"p75":90,"p90":180},{"dimension":"4","metricKey":"flow.triage_to_pia","p50":90,"p75":120,"p90":240},{"dimension":"5","metricKey":"flow.triage_to_pia","p50":90,"p75":135,"p90":240},{"dimension":"","metricKey":"flow.seen_to_first_order","p50":15,"p75":25,"p90":45},{"dimension":"","metricKey":"flow.seen_to_decision_no_tests","p50":30,"p75":45,"p90":90},{"dimension":"","metricKey":"flow.testing","p50":120,"p75":160,"p90":240},{"dimension":"","metricKey":"flow.results_to_reassessment","p50":30,"p75":45,"p90":90},{"dimension":"","metricKey":"flow.boarding","p50":360,"p75":720,"p90":1440},{"dimension":"","metricKey":"flow.discharge_to_cleared","p50":20,"p75":30,"p90":60},{"dimension":"","metricKey":"flow.cleared_to_departure","p50":5,"p75":10,"p90":20}] | array | Default flow benchmarks (Appendix B.4). | Estimates use the last few weeks of the site's history (window), and need a minimum number of samples per weekday and hour bucket before using it; otherwise they fall back step by step to wider buckets and finally to the catalogue defaults. See [Estimate quality](/admin/analytics/estimate-quality). | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | results.displayDelayMinutes | 0 | 0–30 minutes | Delay before a completed result shows as "Back" to the patient. | | results.holdAllowed | true | boolean | Clinicians may hold results (D-29). | ## Import and export [#import-and-export] Import or export the catalogue as CSV. Every row is validated; if any row fails, nothing is applied. Historical, de-identified intervals can be imported to calibrate estimates before go-live (from [Estimate quality](/admin/analytics/estimate-quality)). ## Flow settings [#flow-settings] | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | flow.piaSource | attending_assigned | attending_assigned, explicit | Which event counts as the physician initial assessment (NACRS PIA only when explicit). | | flow.piaRoles | ["attending","resident","nurse_practitioner"] | array | Clinician types whose assignment counts as the PIA. | | flow.assignmentNotifyHoldMinutes | 10 | 5–15 minutes | How long a provider assignment is held before the patient is told (D-25). | | flow.seenInference.firstOrderByAssigned | true | boolean | The assigned clinician's first order infers "seen". | | flow.seenInference.consultRequest | true | boolean | A consult request infers "seen". | | flow.seenInference.disposition | true | boolean | A disposition infers "seen". | | flow.reassessmentInference.newOrderAfterAllBack | true | boolean | A new order after all results are back infers reassessment (D-26). | | flow.reassessmentInference.consultRequest | true | boolean | A consult request infers reassessment. | | flow.reassessmentInference.noteSigned | true | boolean | A signed note infers reassessment. | | flow.reassessmentInference.procedureArea | true | boolean | A move to a procedure area infers reassessment. | | flow.resultComplete.lab | resulted | in_lab, in_progress, performed, preliminary, resulted | Lab status that counts as "Back". | | flow.resultComplete.imaging | preliminary | in_lab, in_progress, performed, preliminary, resulted | Imaging status that counts as "Back" (D-28). | | flow.resultComplete.cardiology | performed | in_lab, in_progress, performed, preliminary, resulted | Cardiology status that counts as "Back". | | flow.resultComplete.imagingByModality | [] | array | Per-modality imaging thresholds, e.g. X-ray at performed where ED physicians read their own films. | | flow.resultsReviewedCountsForImaging | true | boolean | An imaging order with results reviewed counts as "Back". | | flow.manualProfile | lite | lite, full | Manual-mode depth at sites without a feed (D-46). | | flow.manualStaleMinutes | 90 | 30–240 minutes | Manual-lite prompt after this long without an update. | | flow.noUpdateAlertHours | 12 | 4–24 hours | "No updates" alert for the charge nurse (D-50). | | flow.observationIsCdu | false | boolean | Observation happens in a clinical decision unit. | # Waiting-room display (https://docs.edflow.space/admin/settings/waiting-room-display) Set up the EDFlow waiting-room display: public or key access, the official typical wait, slides, language mode, orientation, embedding, and registering big-board and print stations. The waiting-room display is a television in the waiting room showing department-level information only: never a patient, a name, a code or an area. _Screenshot pending: waiting-room-display_ ## What it shows [#what-it-shows] * "If you're here for care, please check in with the triage nurse first." * The department's status in calm words (normal, busy, very busy). * A generic notice when a code is delaying care. * How a visit works, step by step. * How to join EDFlow on your phone. * "Feel worse? Tell the triage nurse now." * Optionally, a typical wait figure. ## Settings [#settings] ![Waiting-room display settings: what the display shows, the display key and the official wait figure.](https://docs.edflow.space/screenshots/web/admin-settings-display.png) | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | display.access | public | public, key | Waiting-room display is public or needs a display key. (Reduces privacy) | | display.showTypicalWait | false | boolean | Show the official typical wait (D-18). | | display.typicalWaitSource | feed | feed, manual | Source of the typical wait. | | display.manualTypicalWait | — | object | Manual typical wait with the time it was set. | | display.languageMode | alternate | alternate, side_by_side, english_only | Display language mode: English and French in turn, side by side, or English only (owner, 2026-09-26). | | display.orientation | landscape | landscape, portrait | Display orientation. | | display.allowEmbed | false | boolean | Allow framing by the embed origins. (Reduces privacy) | | display.embedOrigins | [] | array | Exact https origins allowed to frame the display (never "*"). (Reduces privacy) | | display.slideSlugs | [] | array | Display loop slides. | * **Access**: public, or with a display key carried in the URL fragment. **Rotate** makes old display URLs stop working within 60 s. Switching to public needs a fresh sign-in check. * **Typical wait**: off by default. When on, it shows the official figure from the feed, or a value an admin enters with its time. It's never computed per patient. * **Slides** and their order, wayfinding tiles, landscape or portrait, alternate languages every 15 s or side by side. * **Embedding**: only for the origins you list. ## Hardware [#hardware] A 1920 × 1080 or larger screen with a current browser in kiosk mode, on a network that can reach the app host. See [Network requirements](/security/network-requirements). ## Stations [#stations] **Settings → Stations** registers print stations and big-board stations. Registering shows a one-time enrolment code (valid 10 minutes) that the kiosk enters; the device then holds its own station credential, never a person's session. **Revoke** takes effect within 5 s. Each print job and big-board view is audited with the station. ## Related [#related] * [Department volume](/staff/charge/department-volume) * [Hospital communications](/brand/hospital-communications) # Zones, beds and shifts (https://docs.edflow.space/admin/settings/zones-beds-and-shifts) Define EDFlow zones with their streams, beds and EHR location codes, treatment-space capacity, shift times and the CTAS reassessment intervals for the waiting room. Zones and beds describe the department's layout. Charge nurses assign staff to them each shift, and that assignment routes patient requests. See [Zones and shifts](/staff/charge/zones-and-shifts). ![Zones and beds: the department's zones and the beds or spaces in each.](https://docs.edflow.space/screenshots/web/admin-settings-zones.png) ## Zones [#zones] | Field | Notes | | ------------- | ----------------------------------------------------------------------------------- | | Name and code | For example "Acute A", `A` | | Area type | Resuscitation, acute, fast track, internal waiting, hallway, triage, waiting room | | Stream | Used by estimates: a fast-track patient's wait uses the fast-track stream's history | | Colour | Staff-only colour from the brand's zone swatches. Never shown to patients | ## Beds [#beds] Each bed has a label, a zone and the EHR location codes that map to it. Unmapped location codes appear in [Unmapped codes](/admin/integration/unmapped-codes). ## Capacity [#capacity] The number of treatment spaces. The volume suggestion uses occupancy against it. See [Department volume](/staff/charge/department-volume). ## Shifts [#shifts] Shift name, start time and length (default Day 07:00–19:00 and Night 19:00–07:00). "On shift" and request routing follow the current shift's assignments. ## Reassessment intervals [#reassessment-intervals] How often waiting patients should be reassessed, per CTAS. The board shows "Due" and "Overdue" against these. Defaults: CTAS 2 every 15 min, 3 every 30, 4 every 60, 5 every 120. | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | reassessment.intervals.ctas2 | 15 | 5–240 minutes | Waiting-room reassessment interval for CTAS 2 (D-53). | | reassessment.intervals.ctas3 | 30 | 5–240 minutes | Waiting-room reassessment interval for CTAS 3. | | reassessment.intervals.ctas4 | 60 | 5–240 minutes | Waiting-room reassessment interval for CTAS 4. | | reassessment.intervals.ctas5 | 120 | 5–240 minutes | Waiting-room reassessment interval for CTAS 5. | ## Rules [#rules] You can't delete a zone with current shift assignments or occupied beds; the page says why. | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | capacity.treatmentSpaces | 30 | 1–500 count | Treatment-space capacity, the occupancy denominator (F-08.3). | # API reference (https://docs.edflow.space/developers/api) The EDFlow Integration API reference: base URLs per environment, the pinned API version, conventions for ids, lists and incremental sync, errors, rate limits, the sandbox playground, and the OpenAPI and Postman downloads. Every operation and webhook has its own page, generated from the OpenAPI 3.1 document the API itself validates requests against. The pages are listed in the navigation by tag. ## Base URLs [#base-urls] | Environment | API | mTLS host | | ------------- | ---------------------------------- | --------------------------------------- | | Sandbox | `https://api.sandbox.edflow.space` | `https://mtls.api.sandbox.edflow.space` | | Customer test | `https://api.test.edflow.space` | `https://mtls.api.test.edflow.space` | | Live | `https://api.edflow.space` | `https://mtls.api.edflow.space` | A credential works only in its own environment. These hosts don't change when the product is renamed; a host change is announced 12 months ahead. ## Versions [#versions] * The major version is in the URL (`/v1`). * Dated minor versions (`2026-10-01`, …) are pinned per app when it's created. Override per request with the `Api-Version` header; responses echo it. * See [Versioning and deprecation](/developers/versioning-and-deprecation). ## Conventions [#conventions] | Topic | Rule | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | Encoding | JSON, UTF-8, `camelCase` fields, `snake_case` enum values | | Timestamps | Responses: UTC with `Z` and milliseconds. Requests: any offset; no offset is refused | | Ids | Opaque and type-prefixed: `enc_`, `req_`, `tsk_`, `code_`, `led_`, `app_`, `cred_`, `we_`, `msg_`, `dlv_`, `rid_`. Sites use their code | | Objects | Every object has `object`; mutable objects have an increasing `version` | | Lists | `{ "object": "list", "data": [...], "hasMore", "nextCursor" }`, `limit` 1–100 (default 25), cursors valid 24 hours | | Incremental sync | Feeds accept `updatedSince` and return items by `(updatedAt, id)`; items newer than 10 seconds are held back so nothing is skipped | | Patient identifiers | Never in URLs. Visit numbers are accepted only in the body of `POST /v1/encounters/lookup` | | Nulls | Optional values are returned as `null`, never omitted | | Response headers | `Request-Id`, `Api-Version`, `RateLimit-Policy`, `RateLimit`, and `Deprecation`/`Sunset` on deprecated operations | ## What reads return [#what-reads-return] Reads return EDFlow ids, workflow state and catalogue keys. Never names, age, sex, date of birth, CTAS, chief complaint, location or bed, test names, free text or device details. Every read of visit-linked data is recorded for the patient's access report. ## Try it [#try-it] Operation pages in this reference include a playground that sends requests to the **sandbox only**, through the docs site's proxy. Keys stay in your browser's memory. ## Downloads [#downloads] * [OpenAPI document](/openapi/edflow-v1.json) * [Postman collection](/openapi/edflow-v1.postman.json) ## See also [#see-also] * [Authentication](/developers/authentication) * [Errors](/developers/errors) * [Rate limits and retries](/developers/rate-limits-and-retries) # API changelog (https://docs.edflow.space/developers/changelog) Changes to the EDFlow Integration API and event contract: dated API versions, additive releases, announced enum values and event types, deprecations and sunsets. Entries are drafted in CI from the differences between OpenAPI documents and the event contract's history, then edited by the integration team. Follow them with the [RSS feed](/developers/changelog/rss.xml) or the developer portal's notifications. ## How to read an entry [#how-to-read-an-entry] * **Added**: new endpoints, fields or event types. Safe to ignore until you need them. * **Announced**: new enum values, webhook event types or error codes that will reach customer test and live on the date shown (at least 60 days later). Update your lookup tables before then. * **Deprecated**: with the sunset date (at least 12 months later). * **Changed**: only behind a new dated `Api-Version`. ## API version `2026-10-01` · event `specVersion` 1.0 [#api-version-2026-10-01--event-specversion-10] The first dated version of the Integration API. **Added** * OAuth 2.0 client credentials (`private_key_jwt`, client secret, mTLS) with 5-minute JWT access tokens; discovery documents; token revocation. * Ingest: `POST /v1/events`, `POST /v1/events/batch`, `POST /v1/events/validate`, `POST /v1/fhir`, `POST /v1/fhir/$ingest`, `POST /v1/fhir/$process-message`, `POST /v1/hl7v2` (raw HL7 over HTTPS and JSON-wrapped). * Reads: encounters, care team, requests, tasks, codes, sites, the ingest ledger. * Write-back: acknowledge and resolve patient requests. * Webhooks: Standard Webhooks delivery with 18 event types, endpoint management, deliveries, redelivery and recovery. * Sandbox: scenarios, fault injection, conformance runs, synthetic requests, reset. * The signed ingest profile (`/ehr/v1/*`) with v2 signatures binding the method, path, site code and input kind. **Deprecated** * v1 signatures on `/ehr/v1/events`, accepted only for sources in a migration window of at most 90 days. ## Related [#related] * [Versioning and deprecation](/developers/versioning-and-deprecation) * [Release notes](/releases) for product changes # Event reference (https://docs.edflow.space/developers/events) The EDFlow normalized event contract: the envelope, prohibited fields (the PHI tripwire), identifiers never allowed in ids, shared types, and every inbound event type with JSON Schemas to download. A normalized event asserts current state for one fact about one ED visit. The same contract is used by `POST /v1/events`, `POST /v1/events/batch` and the signed `POST /ehr/v1/events`, and it's what the FHIR and HL7 v2 adapters produce. ## Envelope [#envelope] | Field | Required | Rules | | ------------- | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `specVersion` | yes | `"1.0"` | | `id` | yes | Unique per source and stable across retries: `^[A-Za-z0-9._:#/@-]{1,200}$`. Never contains a patient identifier | | `type` | yes | One of the types below | | `siteCode` | yes, except `system.heartbeat` | Bound to your source | | `occurredAt` | yes | When it happened. RFC 3339 **with an offset**. At most 10 minutes ahead and 90 days old | | `recordedAt` | no | When your system recorded it; defaults to `occurredAt` | | `sequence` | no | Increasing number within the feed, a tie-breaker | | `mode` | no | `live` (default) or `backfill` (never notifies anyone) | | `source` | yes | `kind` (`ehr`, `paging`, `simulator`), `system` (`epic`, `oracle-health`, `meditech`, `other`), `feed`, and optional `messageId`, `messageType`, `mappingProfile` | | `encounter` | for visit events | `externalId` (your visit identifier, hashed on receipt) and `idSystem` (`epic-csn`, `oracle-fin`, `meditech-account`, `visit-number`, …) | | `data` | yes | The schema for the type | Strings are at most 200 characters unless stated. Unknown fields are ignored and counted, except prohibited fields. ## Prohibited fields [#prohibited-fields] An event is **rejected** (`prohibited_field`) if any key, at any depth, matches one of these names (case-insensitive, ignoring `_` and `-`). Nothing is stored beyond the rejection record. | Category | Keys | | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Result content | `value`, `valueQuantity`, `valueString`, `valueCodeableConcept`, `result`, `results`, `resultValue`, `interpretation`, `referenceRange`, `abnormalFlag`, `abnormalFlags`, `conclusion`, `conclusionCode`, `presentedForm`, `impression`, `finding`, `findings` | | Clinical narrative | `note`, `notes`, `comment`, `comments`, `narrative`, `diagnosis`, `diagnoses`, `problem`, `problems`, `condition`, `medication`, `medications`, `allergy`, `allergies` | | Contact and government identifiers | `healthCardNumber`, `hcn`, `ohip`, `jhn`, `sin`, `ssn`, `address`, `addressLine`, `postalCode`, `phone`, `phoneNumber`, `telecom`, `email` | `chiefComplaint` is accepted only when the site opts in, and shown to clinical staff only. String values that survive the tripwire are also checked for health-card, phone, email, postal-code and record-number patterns; a match is replaced with `[redacted]` and reported as a warning. ## Identifiers in ids [#identifiers-in-ids] Event ids must be derived from source data (for example `{sourceId}:{MSH-10}:{n}`), never from patient identifiers. An id containing a health card number, a visit or record number pattern, or 7 or more digits equal to the message's patient or visit number is rejected. ## Event types [#event-types] | Event type | Summary | Scope | HL7 v2 | FHIR R4 | | --- | --- | --- | --- | --- | | admission.status_changed | Bed flow for an admitted patient waiting in the ED. | encounter | ADT^A07, ADT^A14, ADT^A27 | — | | careteam.member_assigned | One care-team member was assigned. | encounter | — | — | | careteam.member_released | One care-team member was released. | encounter | — | — | | careteam.snapshot | The authoritative team asserted by this source, limited to rolesCovered. | encounter | ADT^A04, ADT^A08 | Encounter, CareTeam | | consult.status_changed | A consult was requested, started, completed or cancelled. | encounter | ORM^O01, OMG^O19, OML^O21, OMI^O23 | ServiceRequest | | department.census_reported | Aggregate department status with no identifiers. | site | — | — | | department.code_called | An emergency code was called. | site | — | — | | department.code_cleared | A code was cleared. | site | — | — | | department.roster_reported | The complete list of encounters active in the ED, for reconciliation. | site | — | — | | encounter.arrived | Registration or arrival at the ED. | encounter | ADT^A04, ADT^A01 | Encounter | | encounter.assessed | The physician initial assessment or a reassessment. | encounter | — | — | | encounter.cancelled | The registration was voided. | encounter | ADT^A11 | Encounter | | encounter.departed | The patient physically left the ED. | encounter | ADT^A02, ADT^A03, ADT^A11 | Encounter | | encounter.departure_cancelled | The discharge was reversed. | encounter | ADT^A13 | — | | encounter.disposition_decided | A decision to discharge, admit, observe or transfer. | encounter | ADT^A01, ADT^A08, ADT^A03, ADT^A06 | — | | encounter.location_changed | A bed or area move, leave of absence or return. | encounter | ADT^A08, ADT^A02, ADT^A12, ADT^A21, ADT^A22 | Encounter | | encounter.triaged | Triage completed, or a re-triage. | encounter | ADT^A04, ADT^A08 | Encounter, Observation | | order.placed | A test or diagnostic order (the full order asserted each time). | encounter | ORM^O01, OMG^O19, OML^O21, OMI^O23 | ServiceRequest | | order.results_reviewed | A clinician acknowledged the results. | encounter | — | — | | order.status_changed | The current status of an order, with every timestamp known so far. | encounter | ORM^O01, OMG^O19, OML^O21, OMI^O23, ORU^R01, SIU^S12, SIU^S13, SIU^S14, SIU^S15 | ServiceRequest, Specimen, ImagingStudy, DiagnosticReport, Appointment, Task | | patient.merged | Two MRNs were merged. | site | ADT^A40, ADT^A34, ADT^A18 | — | | patient.updated | A demographic or privacy correction. | encounter | ADT^A08 | — | | system.heartbeat | Feed liveness. | source | — | — | Each type links to its page with the `data` fields, effects, an example and the JSON Schema. ## Per-event results [#per-event-results] | Status | Meaning | | ------------- | --------------------------------------------------------------------------- | | `accepted` | Applied, or recorded as older than current state | | `duplicate` | Same id and payload already processed | | `superseded` | Same id, new payload after a mapping-profile change or a dead-letter replay | | `buffered` | The visit or order isn't known yet; held up to 6 hours | | `quarantined` | A roster that would close too many visits, held for review | | `ignored` | Valid, deliberately not applied (for example an archived visit) | | `rejected` | Invalid; see the error code and path | ## Related [#related] * [Concepts](/developers/concepts) * [Errors](/developers/errors) * [Webhooks](/developers/webhooks) for outbound event types # Department analytics for the charge nurse (https://docs.edflow.space/staff/charge/analytics) Department analytics a charge nurse can open in EDFlow: today's flow and bottlenecks, and Ask your data where the site has turned it on, with what it can and can't answer. Charge nurses can open department analytics (not clinician-level metrics). Use them at huddles and handover to see where today's flow is stuck. ## Flow and bottlenecks [#flow-and-bottlenecks] ![Flow and bottlenecks: median time per segment of the visit, with the slowest segments flagged and ranked.](https://docs.edflow.space/screenshots/web/admin-flow-bottlenecks.png) The flow page splits every visit into segments (arrival to the first nursing check, then to being seen, to the first test, from results to being seen again, from the decision to departure…) and flags the segments running beyond p90 for this site, weekday and hour. The board's **Bottleneck** column uses the same flags. See [Flow and bottlenecks](/admin/analytics/flow-and-bottlenecks) for definitions. Useful views for a charge nurse: * **Today** against the same weekday in recent weeks. * **Results to seen again**: patients waiting for reassessment are often the quickest win. * **Boarding**: boarder-hours today, for bed meetings. * **Requests**: response times by zone and type, to rebalance zones or call in support. ## Ask your data [#ask-your-data] Where the site has turned it on, **Ask your data** answers questions about department operations in plain language, with a chart and the numbers behind it. For example: "How did door-to-doctor compare with last Tuesday?" or "Which hours had the longest results-to-seen-again times this week?" ![Ask your data: a question about last week's door-to-doctor times answered with a chart and the query it used, labelled as AI and for review.](https://docs.edflow.space/screenshots/web/admin-ask-your-data.png) * It reads de-identified, aggregate analytics only, never a patient's record. * It shows the query and definitions it used, so you can check them. * It won't answer questions about individual patients or rank clinicians. * Review a chart before you share it. AI can be wrong. ## Related [#related] * [Analytics for managers](/admin/analytics) * [Ask your data](/admin/analytics/ask-your-data) # Big board and handover (https://docs.edflow.space/staff/charge/big-board-and-handover) Big-board mode for the staff station in EDFlow (initials only, auto-paging, no actions, big-board station credentials) and the per-nurse handover summary. ## Big-board mode [#big-board-mode] A full-screen board for the staff station. **Never** put it where patients or visitors can see it. ![Big-board mode for a wall display: large rows by zone with stage, time in department and open requests, and no patient names by default.](https://docs.edflow.space/screenshots/web/staff-big-board.png) * Larger type, the display theme, a clock. * Names as initials by default. * Pages automatically every 15 s when rows overflow. * No drawer and no actions. * Reconnects on its own after a network drop. Open it from the board's view menu, in your own session. For a wall screen, ask a manager to register a **big-board station**: it gets its own device credential that can only show the big board, has no idle lock and records one view in the audit log every 15 minutes. It never uses a person's session. ## Handover summary [#handover-summary] Handover summary is part of release 1.1. **Handover** lists, for each nurse (explicit or zone-derived), their patients with stage, pending tests, open requests and open tasks. It prints on one page per nurse. ![Handover summary: patients by zone with what changed this shift, open requests and pending tests.](https://docs.edflow.space/screenshots/web/staff-handover.png) Where the site turns on staff AI, an attention summary can highlight what to look at first. See [AI assistance](/staff/ai-assistance). ## Related [#related] * [Board](/staff/board) * [Devices](/security/devices) for stations # Codes (https://docs.edflow.space/staff/charge/codes) Charge nurses and codes in EDFlow: call, extend, clear and cancel codes, resolve paged codes, post the delay notice, merge and throttle rules, and which categories can notify patients. > **Why does this happen?** > > Someone in the emergency department needs urgent care right now, so part of our team is with them. This may add time to your wait. We haven't forgotten you, and we'll be with you as soon as we can. If you feel worse, tell a staff member right away. This page is the charge nurse's reference for codes in EDFlow. For the call itself, see [Calling a code](/staff/physicians/calling-a-code). ![Code alerts: active codes with type, location, time called and who called, with Extend, Clear and Cancel.](https://docs.edflow.space/screenshots/web/staff-codes.png) ## Where codes come from [#where-codes-come-from] | Source | What happens | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Console or companion app | Two-step call; the caller answers "Which patient is this for?" | | Paging system | Filtered by location. Codes outside the ED are staff-only and prompt nobody (unless your site turns on "ED responds outside"). Inside the ED, you get a prompt: "Code Blue received from paging. Which patient is this for?" | | EHR | Same as paging | Nobody is notified from a paged or EHR code until you answer the prompt. ![Code call, second step: the chosen code type and location, who will be notified, and the final Call button, not yet confirmed.](https://docs.edflow.space/screenshots/web/staff-code-call-confirm.png) ## Managing an active code [#managing-an-active-code] * **Post delay notice**: one tap from the code strip, **Codes**, or the app. Anyone with the permission (including clerks) can post it for the resuscitation team. You can end it early. * **Extend**: +15 or +30 min, up to 240 min in total. * **Clear**: ends it now. Banners disappear within 10 s once the last notifying code ends. * **Cancel (called in error)**: ends it now and adds "This notice has ended." to the patients' inbox. A push already sent can't be recalled. Codes expire on their own at the expected duration. ## Who can notify patients [#who-can-notify-patients] * Only **medical** codes, and only types your site enabled. Code Stroke and STEMI are staff-only by default. * **Security** and **facility** codes can never notify patients, even through the API. * The code's patient, anyone in the named zones or bays, and anyone in resuscitation are excluded. Only the notice stages receive it. ## Merge and throttle [#merge-and-throttle] Each visit gets at most one pop-up and one push per throttle window. A second notifying code within the window updates the existing notice ("Updated …") without a new push or pop-up. The banner stays while any notifying code is active. _Screenshot pending: patient-code-delay_ ## Staff notifications [#staff-notifications] The "Code called" push to staff is off by default, because staff hear the overhead page. When on, it goes to on-shift staff with no area in the text. | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | codes.notifyThrottleMinutes | 30 | 15–120 minutes | Delay-notice push throttle per patient. | | codes.autoNotifyFromFeed | false | boolean | Feed codes post the notice without a prompt (never skips the subject step). | | codes.edRespondsOutside | false | boolean | Prompt the charge nurse for codes outside the ED. | | codes.pagingEdLocations | [] | array | Paging locations inside the ED. | ## Audit and analytics [#audit-and-analytics] Calling, clearing, posting and ending notices are audited. Code impact on flow is reported per code type in [Codes and delays](/admin/analytics/codes-and-delays), with the caution that codes often coincide with busy periods. # Department volume (https://docs.edflow.space/staff/charge/department-volume) Set the department volume level in EDFlow (normal, busy, very busy, surge), how suggestions are computed, imaging service status, and what patients, family, the entry page and the waiting-room display show. The volume level tells waiting patients, honestly and calmly, that waits may be longer. Open **Department** from the header. ![Department volume: normal, busy, very busy or surge, with a suggested level and what patients and the display will see.](https://docs.edflow.space/screenshots/web/staff-volume.png) ## Setting the level [#setting-the-level] Choose **Normal**, **Busy**, **Very busy** or **Surge**. Each option previews the patient banner and the display text. Add an optional staff-only note. The level stays until someone changes it; after 4 hours, charge nurses get a **Review department status** prompt. ## Suggestions [#suggestions] Every 5 minutes EDFlow computes a suggestion from the live census, for example "Suggested: Busy · 14 waiting · median wait 1.4× usual for Tuesday 3 p.m." with **Accept** and **Dismiss**. **A suggestion never changes anything until you accept it.** | Suggests | When any of these hold | | --------- | ------------------------------------------------------------------------------------------------ | | Very busy | 20 or more waiting, 12 or more boarders, occupancy 110% or more, median wait 1.75× usual or more | | Busy | 12 or more waiting, 8 or more boarders, occupancy 95% or more, median wait 1.25× usual or more | | Normal | None of the above for 30 minutes | Surge is never computed. It is suggested only by a code type (for example Code Orange) or by the EHR census. | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | volume.reviewAfterHours | 4 | 1–12 hours | Prompt to review the volume level. | | volume.acceptFeedLevel | false | boolean | Apply the feed's volume level directly. | | volume.thresholds.busy.waiting | 12 | 1–500 count | Volume suggestion threshold: busy waiting (F-08.3). | | volume.thresholds.busy.boarding | 8 | 1–500 count | Volume suggestion threshold: busy boarding (F-08.3). | | volume.thresholds.busy.occupancy | 0.95 | 0.1–5 ratio | Volume suggestion threshold: busy occupancy (F-08.3). | | volume.thresholds.busy.waitRatio | 1.25 | 0.1–10 ratio | Volume suggestion threshold: busy waitRatio (F-08.3). | | volume.thresholds.veryBusy.waiting | 20 | 1–500 count | Volume suggestion threshold: veryBusy waiting (F-08.3). | | volume.thresholds.veryBusy.boarding | 12 | 1–500 count | Volume suggestion threshold: veryBusy boarding (F-08.3). | | volume.thresholds.veryBusy.occupancy | 1.1 | 0.1–5 ratio | Volume suggestion threshold: veryBusy occupancy (F-08.3). | | volume.thresholds.veryBusy.waitRatio | 1.75 | 0.1–10 ratio | Volume suggestion threshold: veryBusy waitRatio (F-08.3). | ## What everyone sees [#what-everyone-sees] | Level | Patients and family | Display and entry page | | ---------------- | ------------------------------------------------------------------ | --------------------------------------------------------------------- | | Normal | Nothing | "Thank you for waiting. We see the sickest people first." | | Busy | It's busier than usual today. Waits may be longer. | The department is busy right now. Waits may be longer. | | Very busy, Surge | It's very busy right now. We see the sickest people first, so some waits will be long. We're sorry for the wait. | The department is very busy right now. Some waits will be long. | Every banner also says: If you feel worse while you wait, tell a staff member right away. On the hospital entry page, the busy message always comes after "check in with the triage nurse first". Patients never see red for volume, and volume changes never send push or text messages. _Screenshot pending: patient-busy-banner_ _Screenshot pending: waiting-room-display_ ## Imaging service status [#imaging-service-status] The same page shows each imaging modality as open, closed until a time, or down until a time. Charge nurses can mark a modality **Down** in one tap. While a service is closed or down, patients see when it opens instead of an estimate, and those intervals are excluded from benchmarks. ## Capacity drivers [#capacity-drivers] The page also shows boarders, stretchers occupied by boarders and incoming EMS, and today's level history. Time in each level feeds analytics. ## Related [#related] * [Codes and department status](/staff/codes-and-department-status) * [Waiting-room display](/admin/settings/waiting-room-display) # Escalations (https://docs.edflow.space/staff/charge/escalations) Request service levels and escalation in EDFlow for charge nurses: urgent requests without a response, Going now timers, thinking of leaving, over-the-usual-wait alerts and reassessments overdue. Escalation makes sure no request is forgotten. As charge nurse you're the first escalation point for most of them. ![An escalated request in the queue: past its response time, highlighted for the charge nurse.](https://docs.edflow.space/screenshots/web/staff-request-escalated.png) ## Levels [#levels] | Priority | First-response target | Escalation 1 | Escalation 2 | | -------- | --------------------------------- | ----------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | Urgent | 2 min ("Going now" or "Can't go") | Charge nurse and triage pool; staff push "Urgent request · Zone"; board alert | 5 min without an in-person resolution: charge nurse and physician in charge | | High | 5 min | Charge nurse | 15 min: zone nurses | | Normal | 15 min | Highlighted in red | 30 min: charge nurse (comfort requests go to the zone nurse instead) | | Low | 30 min | Highlighted in red | — | * For non-urgent requests, acknowledging stops escalation. * For urgent requests, only a **resolution** stops it. "Going now" pauses it for 5 minutes; if the request isn't resolved by then, escalation resumes at the next level. "Can't go" reassigns it to you or the zone at once. * An escalated row carries an **Escalated to charge** badge. Every escalation is audited. ## "I'm thinking of leaving" [#im-thinking-of-leaving] The patient's phone asks them to talk to a nurse before going, and tells them they can still be seen. You're notified at creation, and the attending too once the patient has been seen. It is **urgent** for CTAS 1 and 2 and for visits with "must not leave" or custody flags. The board shows a **Thinking of leaving** alert. ## Over the usual wait [#over-the-usual-wait] When a patient's current step passes p90 for this site, weekday and hour, a low-priority item appears in the **Over the usual wait** lane (at most one per visit per stage). Acknowledging it changes the patient's screen to "Your care team knows you're waiting." ## Reassessment overdue [#reassessment-overdue] The board's stats row counts waiting patients overdue for reassessment against the site's CTAS intervals. Triage nurses clear them with **Reassessed**. ## Urgent requests from outside [#urgent-requests-from-outside] A patient who stepped out and taps "I feel worse" appears as "Patient is OUTSIDE the department" on every staff surface. Their phone tells them to come back or call 911. ## Related [#related] * [Requests](/staff/requests) * [Requests analytics](/admin/analytics/requests) # When the EHR feed is down (https://docs.edflow.space/staff/charge/feed-down) What to do when the EDFlow EHR feed is delayed or down: what patients see, frozen estimates, the downtime procedure and kit, running the manual console, and handing back to the feed. When the EHR feed stops, EDFlow tells patients their updates may be delayed and keeps working from the console. The integration team is alerted automatically. _Screenshot pending: staff-feed-down_ ## Feed states [#feed-states] | State | When | Patients see | Staff see | | ----------- | --------------------------------------------------------------- | ---------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Healthy | An event or heartbeat within 5 min | "Live" | "EHR live" | | Delayed | Nothing for 5 min | "Updates may be delayed. Last updated … Your care continues as usual." | "EHR feed delayed · n min" chip and banner | | Down | Nothing for 15 min, all sources disabled, or the site suspended | The feed-down banner; estimates frozen | "EHR feed down" banner with links to the manual console and the downtime kit | | Manual mode | The site has no feed | Nothing extra | "Manual mode" chip | _Screenshot pending: patient-feed-down-banner_ ## Frozen estimates [#frozen-estimates] While the feed is down, estimates keep their last text and add "Times may not be up to date while updates are delayed." They never switch to "taking longer than usual". ## Downtime procedure [#downtime-procedure] ### Confirm [#confirm] Check the banner and ask integration on-call only if the banner has been up for longer than your site's downtime threshold. They are already alerted. ### Open the downtime kit [#open-the-downtime-kit] **Downtime** in the header: the current board as a paper tracking sheet (bed, initials, stage, pending tests), a blank request log, your site's downtime procedure and the recovery checklist. It prints and works offline. ### Keep patients current [#keep-patients-current] Use the manual console for the milestones that matter to patients: triage, seen, tests under way, results back, reassessed, disposition, departure. Patients see these immediately. Requests keep working. ### Register new arrivals if needed [#register-new-arrivals-if-needed] Register by hand only during downtime. Those visits are marked for linking when the feed returns. ## Handing back [#handing-back] When the feed recovers, the engine replays what it held. Events more than 30 minutes old apply silently (no patient notifications). Then: 1. Link any downtime registrations (**Needs linking** on the board). 2. Check overrides you set during downtime and clear the ones the EHR now gets right. 3. Follow the recovery checklist in the kit. ## Related [#related] * [Manual console](/staff/manual-console) * [Feed health](/admin/integration) for integration analysts * [Engine configuration](/developers/engine-configuration), how engines survive an outage # Charge nurses (https://docs.edflow.space/staff/charge) Running the emergency department with EDFlow as charge nurse: zones and shifts, codes, department volume, escalations, overrides, feed downtime, analytics and a quick-reference card. As charge nurse you set up the shift in EDFlow, keep the department's status honest for patients, and catch what escalates. Everything else runs from the EHR feed and your team's taps. ![Live board: patients by zone with stage, time in department, assigned clinician, tests, open requests and bottleneck flags, with filters and saved views.](https://docs.edflow.space/screenshots/web/staff-board.png) ## Your shift in EDFlow [#your-shift-in-edflow] | When | What | Guide | | ------------------------ | ------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | | Start of shift | Assign zones, the triage pool, the support pool, charge and the physician in charge; **Copy from last shift** | [Zones and shifts](/staff/charge/zones-and-shifts) | | When it gets busy | Accept or set **Busy**, **Very busy** or **Surge**; review it every 4 hours | [Department volume](/staff/charge/department-volume) | | When a code is called | Record it in two steps, answer "Which patient is this for?" for paged codes, post the delay notice | [Codes](/staff/charge/codes) | | When something escalates | Urgent requests without a response, thinking of leaving, over-the-usual-wait | [Escalations](/staff/charge/escalations) | | When the feed is wrong | Override a fact, correct a time, reopen a visit | [Overrides and corrections](/staff/charge/overrides-and-corrections) | | When the feed is down | Run the downtime procedure and the manual console | [When the feed is down](/staff/charge/feed-down) | | Any time | Department analytics and "Ask your data" where enabled | [Analytics](/staff/charge/analytics) | | At the station | Big-board mode, handover summary | [Big board and handover](/staff/charge/big-board-and-handover) | | End of shift | **End shift** releases the assignments | [Zones and shifts](/staff/charge/zones-and-shifts) | ## What only you can do [#what-only-you-can-do] | Permission | R-CHARGE | R-NURSE | | --- | --- | --- | | patient.override | Granted | Not granted | | patient.lifecycle | Granted | Not granted | | zones.assign | Granted | Not granted | | request.bulk | Granted | Granted | | code.call | Granted | Not granted | | code.clear | Granted | Not granted | | code.notice | Granted | Granted | | volume.set | Granted | Not granted | ## Quick-reference card [#quick-reference-card] | | | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------- | | Urgent request, no response in 2 min | You and the triage pool are pushed. At 5 min without an in-person resolution, you and the physician in charge | | Code from paging | Answer "Which patient is this for?" before anyone is notified | | Volume | Suggestions never apply themselves. Review the level every 4 h | | Feed down | Banner with links to the manual console and the downtime kit | | Override | Wins over the EHR until cleared. Always audited | | Reopen a departed visit | Patient → Update status → Reopen | | Never | Put a code name, area or count in anything patients see | # Overrides and corrections (https://docs.edflow.space/staff/charge/overrides-and-corrections) Override EHR data in EDFlow when the feed is wrong, undo a console action, correct a time (including the PIA), reopen a departed visit, cancel a duplicate and link a downtime registration. When the EHR says one thing and the department is doing another, patients should see what's really happening. These tools fix it, with a full audit trail. ## Override the EHR [#override-the-ehr] In any console action form, turn on **Override** (needs `patient.override`). The manual value then wins over the EHR for that fact until someone clears the override. The board and the patient page show an **Override** marker. _Screenshot pending: staff-override_ Example: the EHR keeps a patient in A12, but they're in hallway H2. Move them to H2 with **Override** on. Later EHR location updates are recorded but don't change what patients and staff see until you clear it. Every override and clear is audited. Report persistent feed problems with **Report a data problem** so the integration team can fix the mapping. ## Undo [#undo] Every console action shows a 10-second **Undo**. It restores the previous value and cancels the notification the action would have sent. ## Correct a time [#correct-a-time] **Update status → Correct a time** re-records a milestone (arrival, triage, assigned, seen, PIA, disposition, departure) with a later record time and a "corrected" marker. Correcting the PIA time affects NACRS-aligned analytics only; patients don't see it. Needs `patient.lifecycle`. ## Reopen a departed visit [#reopen-a-departed-visit] If a patient was marked departed by mistake, **Reopen visit** returns it to the board. The patient's access comes back if it's still within the grace window. Needs `patient.lifecycle`. ## Cancel a visit [#cancel-a-visit] **Cancel visit** (reason required) removes a duplicate or wrong registration. It disappears from everywhere except the audit log. ## "No updates in 12 hours" [#no-updates-in-12-hours] A visit with no activity for the site's threshold is flagged. Confirm departed if the patient has left; the disposition is recorded as unknown. ## Link a downtime registration [#link-a-downtime-registration] A visit registered by hand while the feed was active is marked for linking. When the EHR arrival comes in with the same match key within 12 hours, **Link to EHR visit** merges them: EHR facts take precedence (except overrides), and sessions, family links, requests, tasks and the summary move to the surviving visit. Unlinked ones are listed under **Needs linking** on the board. ## Related [#related] * [Manual console](/staff/manual-console) * [Data issues](/admin/integration/data-issues) # Zones and shifts (https://docs.edflow.space/staff/charge/zones-and-shifts) Assign nurses to zones, the triage pool, the support pool, charge and the physician in charge in EDFlow, and how those assignments route patient requests and decide who is on shift. Zone assignments decide who is on shift, whose phone rings for which patient, and which nurse patients see. Open **Zones** from the header. ![Zones and shifts: nurses and doctors assigned to each zone, which is how patient requests are routed.](https://docs.edflow.space/screenshots/web/staff-zones.png) ## Assign the shift [#assign-the-shift] ### Check the shift [#check-the-shift] The page shows the current shift from the site's settings (by default Day 07:00–19:00, Night 19:00–07:00). ### Start from last shift [#start-from-last-shift] **Copy from last shift**, then adjust. ### Assign each zone [#assign-each-zone] Use the select control for each zone to add nurses. Drag and drop works too, but is never the only way. ### Assign the pools and leads [#assign-the-pools-and-leads] * **Triage pool**: triage nurses for the waiting room. * **Support pool**: support staff for comfort requests. * **Charge** nurse or nurses. * **Physician in charge**, who receives the second level of urgent escalation. * **Physicians on shift**, used for per-hour clinician metrics. ## How assignments route requests [#how-assignments-route-requests] * A patient without an explicit primary nurse gets every nurse assigned to their bed's zone (the most specific assignment wins). Patients see up to two names. * Waiting-room and triage locations route to the triage pool; patients see "The triage nurse". * When a patient moves to a bed in another zone, their nurse and their new requests follow within 2 s. * If nobody is on shift for a route, the request goes to charge, then the physician in charge, then every on-shift clinician. See [Requests](/staff/requests) for the full routing table. ## On shift [#on-shift] Staff are **on shift** when they are assigned in the current shift. Each person can override it in the companion app's **Me** tab (for example when covering a break). Going off shift removes a person from routing and push within 5 s. ## End of shift [#end-of-shift] **End shift** releases the assignments. When a patient's derived nurse changes at shift change, the patient gets a quiet note in their inbox ("Your nurse changed at 19:00"), with no push. ## Related [#related] * [Zones, beds and shifts](/admin/settings/zones-beds-and-shifts), where managers define zones and shift times # Confidential and unknown patients (https://docs.edflow.space/staff/clerks/confidential-and-unknown-patients) Set or clear the confidential (no-information) flag in EDFlow, confirm a provisional identity for an unknown patient, and what each does to the board, cards and family sharing. ## Confidential patients [#confidential-patients] A patient who asks that no information be given about them (for example a public figure or someone at risk) is marked **confidential**. _Screenshot pending: staff-privacy-flag_ | What changes | Effect | | ---------------------------- | ----------------------------------------------------------------------------------------------- | | Board, palette, patient page | Name shows as **Confidential**. **Show** asks for a reason and is recorded as an unmask | | Family sharing | Unavailable; existing links end. The patient sees only "Sharing isn't available for this visit" | | Cards | Printing needs a recorded unmask first | | Patient app | Works as usual for the patient | **Set it**: patient → **Sharing & access** → **Confidential**. Needs `privacy.flag`. **Clear it**: needs a reason, because it reduces privacy. Clearing is recorded as an unmask. ## Unknown or unconfirmed patients [#unknown-or-unconfirmed-patients] A patient who arrives unidentified (for example an unconscious trauma patient) is registered with a **provisional identity**. _Screenshot pending: staff-provisional-identity_ * The board shows a provisional marker. * No card prints, and nobody can sign in: a correct sign-in shows "Your visit isn't ready yet. Staff will give you a card when it is." * Once you confirm the identity (**Confirm identity**), cards and sign-in work as usual. ## Restricted view and "not appropriate" [#restricted-view-and-not-appropriate] Clinical staff can also set a **restricted patient view** (the patient sees only the stage, care team and requests) or mark EDFlow **not appropriate** for the visit (no card, no access). Clerks see these flags but don't set them. ## Related [#related] * [Privacy at work](/staff/privacy-at-work) * [Register a patient](/staff/clerks/register-a-patient) # Helping patients sign in (https://docs.edflow.space/staff/clerks/helping-patients-sign-in) Help a patient sign in to EDFlow on their own phone: staff-assisted pairing and the five most common sign-in problems, without ever handling their card code. Patients sign in on their own phone. You can help, but never sign in for them or read their code aloud. ## Staff-assisted sign-in [#staff-assisted-sign-in] 1. Ask the patient to open the link on their card, or the app, and choose **Get help signing in**. Their phone shows a 6-character code and a QR, valid for a few minutes. 2. Open the patient from the board. 3. **Approve pairing code**: type or scan the code, choose a text size (for example 200% for someone who needs larger text), and **Approve**. 4. The patient's phone signs in and asks "Is this you?". _Screenshot pending: staff-assisted-qr_ ## The five most common problems [#the-five-most-common-problems] | Problem | What to do | | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | The camera doesn't open the link | Use **Enter my details**: last name, date of birth and the visit code under the QR. Or use pairing. | | "We couldn't find a visit with those details" | Check the spelling of the last name and the date format (year, month, day). The code can be typed without the dash. | | "Too many tries. Please wait 15 minutes" | Use pairing, which isn't affected. | | "This code doesn't work anymore" | The card was reissued or revoked. Reissue and give the new card. | | "This visit is already open on the most devices allowed" | On their main phone, open **Devices on my visit** and sign out an old device. Or sign one out from the patient's page. | ![Sign-in form: last name, date of birth and the visit code printed on your card. The values shown are sample placeholders.](https://docs.edflow.space/screenshots/web/patient-sign-in-manual.png) ## A second phone [#a-second-phone] If the patient already signed in on one phone and now uses another, the second phone asks for the date of birth, or approval from the first phone. That's expected. ## Related [#related] * [Sign in](/patients/sign-in), the patient's guide * [Troubleshooting](/patients/troubleshooting) # Registration clerks (https://docs.edflow.space/staff/clerks) What registration clerks see and do in EDFlow: the limited board, visit cards and the print queue, manual registration, lost cards, sign-in help, and confidential and unknown patients. Clerks start most patients' EDFlow visits: you make sure every registered patient gets a card and can sign in. ## What you see [#what-you-see] The board shows you only **Patient**, **Location**, **Stage**, **LOS**, **EDFlow** (not activated, active, family links) and **Arrived**. On a patient's page you see the header and the card, identity and device sections of **Sharing & access**. You never see CTAS, tests or clinical detail. ![The board as a registration clerk sees it: fewer columns, no clinical detail, and access actions only.](https://docs.edflow.space/screenshots/web/staff-board-clerk.png) ## What you do [#what-you-do] | Task | Guide | | ---------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Make sure cards print, reprint, choose who gets the card | [Visit cards](/staff/clerks/visit-cards) | | Register a patient by hand (manual sites, or EHR downtime) | [Register a patient](/staff/clerks/register-a-patient) | | Replace a lost card, sign out a patient's devices | [Lost cards and access](/staff/clerks/lost-cards-and-access) | | Help a patient sign in on their own phone | [Helping patients sign in](/staff/clerks/helping-patients-sign-in) | | Set confidential, confirm an unknown patient's identity | [Confidential and unknown patients](/staff/clerks/confidential-and-unknown-patients) | | Post the delay notice for an active medical code | [Codes](/staff/charge/codes) | ## Quick-reference card [#quick-reference-card] | | | | ----------------------------- | ----------------------------------------------------------------- | | Card prints after triage | Automatically, at your station (most sites) | | Reprint within 15 min | Same card | | Send again after 15 min | Reissue: new code, old card stops working | | You never see | The QR or the visit code in clear | | Patient needs help signing in | They open **Get help signing in**; you approve the code they show | | Duplicate warning | Review the possible duplicate before registering | | Never | Sign in on a patient's phone for them. Read a code aloud. | # Lost cards and access (https://docs.edflow.space/staff/clerks/lost-cards-and-access) Replace a lost or wrongly given EDFlow visit card, sign out a patient's devices, handle This wasn't me alerts and possible wrong-patient sign-ins, and revoke access. _Screenshot pending: staff-reissue-access_ ## Replace a lost card [#replace-a-lost-card] ### Open the patient [#open-the-patient] From the board. Opening is recorded. ### Reissue [#reissue] **Sharing & access → Visit card → Reissue**. Choose the station. ### Decide about devices [#decide-about-devices] * Card lost, patient still has their phone: leave **Also sign out devices** unticked. Their phone stays signed in. * Card given to the wrong person, or the patient doesn't recognize a device: tick it. Every device signs out, and the family links and text subscriptions those devices created end too. The old card's QR and code stop working immediately. Reissuing is audited and counts toward the privacy office's monitoring rules. ## "This wasn't me" [#this-wasnt-me] When a patient taps **This wasn't me** on their main phone, every other device is signed out and a **Reissue card** alert appears on the board. Reissue the card and give it to the patient in person. ## Possible wrong-patient sign-in [#possible-wrong-patient-sign-in] If someone answers "No, that's not me" on the "Is this you?" screen, the board shows **Possible wrong-patient sign-in** on that visit. Check with the patient that they have the right card, reissue if needed, then clear the alert. ## Sign out one device [#sign-out-one-device] **Sharing & access → Patient devices** lists each device (type, main phone, last seen). **Sign out** ends that device's session. ## Revoke access [#revoke-access] **Revoke access** signs out every device and ends the card, without printing a new one. Use it when the patient asks to stop using EDFlow. ## Related [#related] * [Visit cards and sign-in help](/staff/visit-cards-and-sign-in-help) * [Settings](/patients/settings), where patients see their devices # Register a patient (https://docs.edflow.space/staff/clerks/register-a-patient) Register a patient by hand in EDFlow at manual-mode sites or during EHR downtime: the fields, the minimal data profile, the duplicate check, triage and the card recipient. At sites without an EHR feed, you register every patient in EDFlow. At sites with a feed, register here only during EHR downtime. ![Register a patient at a manual-mode site: the minimal data profile and the visit card print.](https://docs.edflow.space/screenshots/web/staff-register.png) ## Register [#register] Open **Register a patient** from the header or the command palette. | Field | Notes | | ------------------------------------------------------ | ---------------------------------------------------------------------------------------- | | Given name, family name | Used to build the match key, then the family name is discarded | | Date of birth | Used for the match key and the age, then discarded. EDFlow never stores it | | Preferred name, preferred language, administrative sex | Optional except language | | Arrival time and mode | Defaults to now. For ambulance arrivals, the EMS arrival and transfer-of-care times | | Referred to a service | Optional | | Location | Waiting room, triage or a bed | | Confidential | See [Confidential and unknown patients](/staff/clerks/confidential-and-unknown-patients) | | Identity not yet confirmed | Provisional: no card until confirmed | | Triage | Optional here (CTAS and time), usually done by the triage nurse | After triage, choose **Who gets the EDFlow card?**: patient, guardian, substitute decision-maker, youth-confidential, or not appropriate. The card then goes to the print station. ## Minimal data profile [#minimal-data-profile] At sites using the minimal profile, you enter initials instead of the name and date of birth, and patients sign in with a 10-character visit code and type the name they want to be called. ## Duplicate check [#duplicate-check] If an active visit has the same match key, the form says only "A possible duplicate exists. Review before registering." **Show possible duplicate** opens that visit (recorded in the audit log). Register only if it's a different person. ## During EHR downtime [#during-ehr-downtime] With the feed active, a banner warns: "The EHR feed is active. Register here only during EHR downtime." The visit is marked for linking; when the EHR arrival comes in, the charge nurse links the two. See [Overrides and corrections](/staff/charge/overrides-and-corrections). # Visit cards (https://docs.edflow.space/staff/clerks/visit-cards) The EDFlow visit card print queue: automatic printing after triage, the 15-minute reprint window, card layouts and recipients, the print station, and what's printed on the card. Every registered patient who should use EDFlow gets a card (or, at some sites, a wristband label). Cards print at a **print station**: a computer with a printer, registered by a manager, that runs the print page under its own device credential. It is never signed in as a person. ## The print queue [#the-print-queue] ![Print station queue: cards waiting to print, auto-print status and reprints within the 15-minute window.](https://docs.edflow.space/screenshots/web/staff-print-queue.png) The station page lists new card jobs, prints them automatically, and marks each printed or failed. From the station you can **Reprint** or **Skip** a job. A card appears within seconds of triage (or registration, depending on your site). | Setting | Default | Allowed values | What it does | | --- | --- | --- | --- | | cards.autoPrint | true | boolean | Visit cards print automatically at the print station. | | cards.printAt | after_triage | after_triage, registration | When the card prints (D-43). | | cards.form | card | card, wristband_label | Card or wristband label (discouraged; forces the date-of-birth check on every device, D-51). (Reduces privacy) | | cards.nameDisplay | initials | initials, first_initial, none | Name printed on the visit card. (Reduces privacy) | | cards.shortUrl | — | string | Printed "go to" URL on the card; https on a trusted domain. (Reduces privacy) | ## Sending a card by hand [#sending-a-card-by-hand] Patient → **Send card to printer**: choose the layout, who gets the card, and the station. See [Visit cards and sign-in help](/staff/visit-cards-and-sign-in-help). ## The 15-minute window [#the-15-minute-window] * Within 15 minutes of issue, sending again reprints the **same** card. * After 15 minutes, sending again means **Reissue**: a new code, and the old card stops working immediately. Existing phones stay signed in unless you tick **Also sign out devices**. * The printable code is deleted from the station as soon as the card prints, or after 15 minutes. Nobody can print it again after that. ## Layouts [#layouts] | Layout | Size | | --------------- | ------------------------------------------------------------------------------------------------ | | Wallet card | 85 × 55 mm | | Thermal label | 4 × 2 in | | Full sheet | Letter or A4, with a cut line | | Wristband label | Only where the site chooses it. Every phone that signs in with it is asked for the date of birth | ## The card [#the-card] _Screenshot pending: visit-card-print_ * The QR code and the visit code (`XXXX-XXXX`, or `XXXXX-XXXXX` at visit-code-only sites). * The hospital name and the patient's initials (the site can choose none or first initial). * "Scan to follow your visit. Or go to … and enter your visit code." in English and French. * The not-an-emergency line in both languages. ## Who gets the card [#who-gets-the-card] Ask at triage or registration: the patient, a guardian (for a child), a substitute decision-maker, or youth-confidential. Choose **Not appropriate for EDFlow** when the patient shouldn't have one; then no card prints. ## Related [#related] * [Hospital communications](/brand/hospital-communications) for card stock and signage # Publishing the going-home summary (https://docs.edflow.space/staff/nurses/after-visit-summary) Compose, preview and publish the EDFlow going-home summary from approved templates, mark Cleared to leave, edit or unpublish, and what the patient receives. When the disposition is home, the visit moves to "Getting ready to go home" and the board shows "Going home: summary not published". The patient is told to wait for their nurse to go over instructions and take out the IV. ## Compose the summary [#compose-the-summary] Patient → **Going home**. _Screenshot pending: staff-avs-composer_ | Section | Input | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Discharge diagnosis (staff only) | Optional. Choosing a common diagnosis pre-fills the activity templates, the "when to come back" set, a resource and a default follow-up from the templates approved at your site. Review and adjust before publishing; the diagnosis itself is never shown to the patient | | About your visit | Optional, up to 280 characters, only where the site allows it | | Your medicines | Only prescribers, where the site turns it on. Otherwise the summary points to the printed instructions and the portal | | Activity and eating | Approved instruction templates | | Follow-up | Up to 6 entries: who, when, notes (160 characters) | | When to come back | Approved red-flag sets; the generic 911, Health811 and "if you feel worse" set is always included | | Helpful resources | Approved resource sets | | Prescription | "Sent to pharmacy" and pharmacy name | | Notes for work or school | "Given" | Free-text fields say **Visible to the patient**. Templates render in the patient's language, and the preview shows English and French side by side. No diagnosis text from the EHR is ever copied in. ## Publish [#publish] **Publish** creates version 1 and sends the patient "Your going-home information is ready." Edits after publishing create new versions and add "Your summary was updated" to the patient's inbox, without a push. You can edit until one hour after departure. **Unpublish** (for errors) asks for a reason and is audited. Every published version is kept as a safety record. ## Text the link to the patient's phone [#text-the-link-to-the-patients-phone] Once published, **Text the link to the patient's phone** sends the summary link by SMS to the number the patient verified for updates during the visit. You never type or see the number (only its last two digits); the text carries no health information and the link asks for the date of birth. Without a verified number, the patient can text themselves a link from their own device. ## Cleared to leave [#cleared-to-leave] When instructions are given and the IV is out, tap **Cleared to leave**. The patient sees "You can go now. Take care, and follow your going-home instructions." ## What the patient gets [#what-the-patient-gets] ![After-visit summary published by the care team: what to do at home, when to come back, follow-up, and buttons to print or add to a calendar.](https://docs.edflow.space/screenshots/web/patient-summary.png) The patient reads the summary on their phone, prints it, adds follow-ups to their calendar, and can share a summary link that asks for their date of birth. See [After your visit](/patients/after-your-visit). Family never see the summary. ## Related [#related] * [After-visit summary for physicians](/staff/physicians/after-visit-summary) * [Patient content](/admin/settings/patient-content) # Family links (https://docs.edflow.space/staff/nurses/family-links) See and revoke a visit's family links in EDFlow, lock sharing, pause updates to break news in person, and understand why sharing is unavailable for some visits. Patients create family links themselves, on their own phone, with consent. Staff don't create links. You can see them, revoke them and lock sharing when needed. _Screenshot pending: staff-family-links_ ## See a visit's links [#see-a-visits-links] Patient → **Sharing & access**. Each link shows the patient's private label, when it was created, when it ends, devices used and when it was last viewed. You never see the link itself. ## Revoke a link [#revoke-a-link] Tap **Revoke** on the link. Every device on it switches to "These updates have ended" within seconds. Revoking is audited. ## Lock sharing [#lock-sharing] **Lock sharing** stops the patient creating links and ends the current ones. Use it, for example, when a patient asks you to, when there is a custody or safety concern, or when the visit becomes confidential. The patient sees only "Sharing isn't available for this visit", never the reason. Sharing is also unavailable automatically for confidential visits, restricted patient views, youth-confidential cards and paused visits. ## Pausing updates [#pausing-updates] To break difficult news in person, **Pause updates**. Every patient and family screen freezes and shows "Updates are paused. Please speak with the care team or call the hospital." No notification is sent. After you've spoken with the family, record **Family has been informed**, then resume updates or leave them paused. ## What family see [#what-family-see] The family view shows the family stage, the estimate only while waiting to be seen (or for a bed where allowed), first names and roles, and hospital information. Never tests, results, requests, location or the summary. See [What family can see](/family). # Nurses (https://docs.edflow.space/staff/nurses) A nursing shift with EDFlow: going on shift, your zone and your patients, your request queue, tasks and family links, with a printable quick-reference card. This page walks through a nursing shift with EDFlow. Patients follow their visit on their phones, so most "what's happening?" questions are answered before they reach you. What reaches you is structured and routed. ## Start of shift [#start-of-shift] ### Sign in [#sign-in] On the workstation, and on the companion app if your unit uses hospital phones. See [Sign-in and security](/staff/sign-in-and-security). ### Check your zone [#check-your-zone] The charge nurse assigns zones at the start of the shift. You are **on shift** once you are assigned (you can override it in the app's **Me** tab). Being on shift is what routes requests, sounds and push to you. ### Filter the board to your patients [#filter-the-board-to-your-patients] Use **My patients**, or your zone filter, and save it as a view. _Screenshot pending: mobile-staff-me_ ![Live board: patients by zone with stage, time in department, assigned clinician, tests, open requests and bottleneck flags, with filters and saved views.](https://docs.edflow.space/screenshots/web/staff-board.png) ## How patients get to you [#how-patients-get-to-you] * If you are the patient's **primary nurse**, their requests come to you. * Otherwise, the patient's nurse is derived from their bed's zone: every nurse assigned to that zone. Patients see up to two names ("Your nurses"). * In the waiting room, requests go to the triage pool. See [Triage](/staff/nurses/triage). * When a patient moves beds, their open requests follow them. ## During the shift [#during-the-shift] | You want to | Do this | | ----------------------------------------------------- | ---------------------------------------------------------------------- | | Answer a request | Queue or app inbox: **Acknowledge**, then **Resolve** | | Answer "I feel worse" | **Going now**, then **Handled in person**. Or **Can't go** to escalate | | Confirm a patient finished a task | Queue → Patient updates → confirm | | Add a task (gown, stay in your room, arrange a ride…) | Patient → Tasks → add from template. See [Tasks](/staff/nurses/tasks) | | Tell the patient to come back | **Call back** | | Mark "Cleared to leave" | Patient → Going home | | Publish the going-home summary | See [After-visit summary](/staff/nurses/after-visit-summary) | | Revoke a family link | See [Family links](/staff/nurses/family-links) | | Pause updates (for example, to break news in person) | **Pause updates**; later **Family has been informed** | ## End of shift [#end-of-shift] The charge nurse ends the shift assignments. Patients see a short note that their nurse changed, without a push notification. ## Quick-reference card [#quick-reference-card] | | | | -------------- | ------------------------------------------------------------------------- | | Urgent chime | Answer **Going now** or **Can't go** within 2 min | | High request | First response within 5 min | | Normal request | Within 15 min | | Low request | Within 30 min | | Keys (queue) | `A` acknowledge · `R` resolve · `G` going now · `E` can't go | | Keys (board) | `J`/`K` move · `Enter` open · `/` search · `Cmd`/`Ctrl`+`K` palette | | Never | Photograph the board. Tell a patient "someone is coming" through the app. | ## Related [#related] * [Requests](/staff/requests) * [My metrics](/staff/nurses/my-metrics), where your site turns them on # My metrics for nurses (https://docs.edflow.space/staff/nurses/my-metrics) Nurse self-view metrics in EDFlow where the site turns them on: your request first-response times and the alerts you receive per hour, visible only to you. Some sites turn on a private metrics page for nurses. It is off by default. When it's on, open **My profile → My metrics**. ![My metrics: your own step times with the department range for comparison, private to you and never a ranking.](https://docs.edflow.space/screenshots/web/staff-my-metrics.png) ## What you see [#what-you-see] * **Request first response**: p50 and p90 time to first response for requests routed to you, by month. * **Alerts per hour**: how many sounds and push notifications EDFlow sent you per hour on shift. This helps nursing leadership keep alert load reasonable. ## What nobody sees [#what-nobody-sees] * Only you see your own values. There are no ranks, league tables or public displays. * Managers see department-level request times, not yours by name. ## Reading the numbers [#reading-the-numbers] Request times depend on your zone, the shift and how busy the department was. Use them to spot patterns (for example, a zone that gets many comfort requests without a support worker), not to compare yourself with others. ## Related [#related] * [Requests analytics](/admin/analytics/requests) * [Clinician metrics](/admin/analytics/clinician-metrics) # Tasks (https://docs.edflow.space/staff/nurses/tasks) Patient tasks in EDFlow: which tasks are created automatically from orders (urine samples, consent, check before eating, nothing by mouth), adding tasks from templates, and confirming tasks patients mark done. Tasks tell the patient what they need to do or know. Many are created from orders automatically; you add others from approved templates. There is no free text. _Screenshot pending: staff-tasks_ ## Tasks created from orders [#tasks-created-from-orders] | Trigger | Patient sees | | ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | Urine order, voided or clean catch, patient old enough, no "Nurse will collect" | "Hand your sample to your nurse. Don't leave it in the washroom." Done by itself when the lab records the sample | | Same, child in guardian mode | "Your nurse will help collect a urine sample from your child." | | Order with contrast or consent | The site's consent wording | | Contrast order and **no** NPO | "Before you eat or drink, please check with your nurse." | | NPO diet order, NPO flag, or you add NPO | Restriction: "Please don't eat or drink anything for now, not even water…" | | Abdomen or pelvis CT or X-ray, female or unknown sex, age 12 to 55 | Pregnancy check before the scan | | MRI | MRI safety questions | | Pelvic ultrasound needing a full bladder | Drink water, don't empty the bladder | | CT with oral contrast | "Your nurse will give you a drink for your scan…" | A CT with contrast **never** creates "nothing by mouth" on its own. Only an NPO order or your instruction does. An active NPO replaces the full-bladder and oral-contrast tasks with "Please ask your nurse before you drink anything for your scan." Mark **Nurse will collect** on a urine order (catheter, bag, or you'll collect it) so no task appears. ## Adding a task [#adding-a-task] Patient → **Tasks** → **Add from template**. Default templates include: change into a gown, stay in your room or area, keep your arm still (IV), give your nurse a list of your medicines, don't drive yourself home, arrange a ride home, go to X-ray, give a stool sample, nothing to eat or drink; and for children, the oral rehydration schedule, numbing cream applied, and nothing to eat before sedation. Managers edit templates in [Patient content](/admin/settings/patient-content). ## When a patient taps "Done" [#when-a-patient-taps-done] The patient confirms, sees "We've let your nurse know", and a **Patient updates** item appears in your queue (normal priority, no service level). Confirm it, or the order data confirms it (a urine sample at "collected"). ![To do: things you can help with, such as giving a urine sample, each with a Done button.](https://docs.edflow.space/screenshots/web/patient-todo.png) ## Clearing [#clearing] Clear a task that no longer applies. Restrictions lift when the order ends or you clear them. # Triage (https://docs.edflow.space/staff/nurses/triage) Triage nurses in EDFlow: the waiting-room request pool, reassessment due and overdue, re-triage requests, cards after triage, staff-assisted sign-in, the busy banner, and answering how much longer. At triage you start the patient's EDFlow visit, and you look after the waiting room's requests. ![The board as a triage nurse sees it: the waiting room first, with requests from patients who are not yet in a zone.](https://docs.edflow.space/screenshots/web/staff-board-triage.png) ## The waiting-room pool [#the-waiting-room-pool] While a patient is checked in or waiting to be seen (or located in the waiting room or triage), their requests go to the **triage pool**: every triage nurse on shift. Filter the queue by **Waiting room**. ![Request queue: requests by zone with type, age and status, and Acknowledge and Resolve buttons.](https://docs.edflow.space/screenshots/web/staff-request-queue.png) * "I feel worse" from a waiting patient reaches you as **Re-triage requested**, urgent. * A pain check-in that gets much worse reaches you as a high request. * "When will I see the doctor?" is answered on the patient's phone with the usual wait. It reaches you as an FYI only when the patient has waited past p90. * **Over the usual wait** items list waiting patients past p90. Acknowledging tells them "Your care team knows you're waiting." * Comfort requests (blanket, help to the washroom) go to the support pool first, where one is on shift. ## Reassessment due and overdue [#reassessment-due-and-overdue] For waiting patients, the board's **Reassess** column counts down to the site's interval for their CTAS (by default CTAS 2 every 15 min, 3 every 30, 4 every 60, 5 every 120): "Due in 6 min", then "Overdue 4 min". Tap **Reassessed** once you've reassessed: it records a re-triage with the current CTAS and restarts the clock. The stats row shows how many are overdue. ## Cards after triage [#cards-after-triage] At most sites, the card prints automatically after triage at the triage or registration print station. Ask who should get it: the patient, a guardian, a substitute decision-maker, or youth-confidential. If EDFlow isn't appropriate for this visit, mark it so no card prints. See [Visit cards and sign-in help](/staff/visit-cards-and-sign-in-help). ## Helping with sign-in [#helping-with-sign-in] If a patient needs help, ask them to open **Get help signing in** on their phone and approve the code they show. You never hold their phone or their card code. ## When it's busy [#when-its-busy] When the charge nurse sets **Busy** or **Very busy**, waiting patients see a banner that waits may be longer and that they should tell staff if they feel worse. The display and the hospital entry page show it too. ## Answering "how much longer?" [#answering-how-much-longer] Ask the patient to open their Visit screen with you. It shows the usual wait for their step at this hour and day. For CTAS 1 and 2 it shows no time. Then: * "This is what usually happens here at this time. The sickest people are always seen first, so the order changes." * "If you feel worse, come to the desk right away." ## Related [#related] * [Requests](/staff/requests) * [Wait estimates](/patients/wait-estimates) # Going-home summary rules for physicians (https://docs.edflow.space/staff/physicians/after-visit-summary) Content rules for the EDFlow going-home summary for physicians: no diagnosis text from the EHR, the prescriber-attested medicines section, follow-up and red flags from approved templates. The going-home summary helps the patient remember what to do. It is not the legal discharge record: the papers from the care team and the hospital record stay the official source. Nurses usually compose and publish it; see [After-visit summary for nurses](/staff/nurses/after-visit-summary) for the steps. _Screenshot pending: staff-avs-composer_ ## Start from the discharge diagnosis [#start-from-the-discharge-diagnosis] At the top of the composer, **Discharge diagnosis (staff only)** lists common ED diagnoses (head injury, laceration, sprain, fracture in a cast, minor burn, belly pain with no cause found, stomach bug, fever in a child, bladder infection, back pain, low-risk chest pain, asthma flare-up, allergic reaction, migraine, kidney stone, viral illness). Choosing one pre-fills the instructions, the "when to come back" set, a resource and a default follow-up from the templates approved at your site. Review the preview and adjust anything before publishing: the pick is a starting point, not a decision. The diagnosis itself is never shown to the patient. ## Text the link to the patient's phone [#text-the-link-to-the-patients-phone] Once the summary is published, **Text the link to the patient's phone** sends the summary link by SMS to the number the patient verified for updates during the visit. You never type or see the number (only its last two digits). The text carries no health information and opening the link asks for the date of birth. If no verified number is on file, the patient can text themselves a link from their own device. ## Content rules [#content-rules] * **No diagnosis text from the EHR** is ever copied into the summary. Sections come from approved templates written in plain language and reviewed by a clinical approver. * The optional **About your visit** text (up to 280 characters, where the site allows it) is visible to the patient. Write it for the patient, in plain words. * **When to come back** always includes the generic set: call 911 in an emergency, call Health811 for health advice, and what to do if you feel worse. * **Follow-up** entries say who and when, never why. ## Medicines section [#medicines-section] When the site turns it on, only prescribers can write it. Entries use the site formulary and the pharmacist-approved phrase library (how to take it), grouped as new, changed, stop taking, keep taking, up to 15 entries. Publishing needs the attestation "These entries match the prescription I gave." The patient sees "These match the prescription … gave you." At sites with an EHR feed, the default is to point the patient to their printed instructions and the portal instead. ## Versions [#versions] Every published version is kept as a safety record. Edits after publishing notify the patient quietly. You can unpublish with a reason. ## Related [#related] * [Patient content](/admin/settings/patient-content), where templates are approved * [After your visit](/patients/after-your-visit), the patient's view # Calling a code (https://docs.edflow.space/staff/physicians/calling-a-code) How to call a code in EDFlow in two steps: pick the type and the patient it's for, review who will be excluded and notified, then confirm. Code categories, who is notified, and the patient delay notice. Calling a code in EDFlow records it and, for medical codes the hospital allows, lets waiting patients know their wait may be longer. It never replaces the overhead page or your hospital's emergency procedures: page first, then record. ## Call a code [#call-a-code] ### Open Call a code [#open-call-a-code] From **Codes** in the console, the command palette (`Cmd`/`Ctrl`+`K`, "Call a code"), or **Department** in the companion app. ### Step 1: details [#step-1-details] * **Code type**, grouped by category. Each option says **Can notify waiting patients** or **Staff only**. * **Which patient is this for?** (required): a patient on the board (search by bed or name), **Incoming / not yet registered**, or **Outside the ED**. * **Zones or bays** (optional, pre-filled from the patient's location; staff only). * **Expected duration** (5 to 240 min; default from the type). * **Also post the delay notice now** (on by default only for types that can notify). ### Step 2: review and confirm [#step-2-review-and-confirm] You see the visits that will be excluded and paused, the exact patient, family and display wording in English and French, and the count ("12 waiting patients will see a notice. 8 will also get a push notification."). Confirm with **Record code and notify 12 patients**, or **Record code** for a staff-only code. ![Code call, second step: the chosen code type and location, who will be notified, and the final Call button, not yet confirmed.](https://docs.edflow.space/screenshots/web/staff-code-call-confirm.png) The receipt says, for example, "Notified 12 patients · 8 push · 4 in-app only". On the companion app, step 2 is a separate sheet, so a code can never be recorded with one tap. _Screenshot pending: mobile-staff-code-call_ ## What happens to the patient the code is about [#what-happens-to-the-patient-the-code-is-about] Choosing a board patient **excludes** them from the notice and **pauses their updates**: their phone and their family's screens freeze on "Updates are paused" with no notification. Everyone in the named zones or bays, and in resuscitation, is excluded too. Resume updates later from the patient's page. ## Who is notified [#who-is-notified] Only visits in the notice stages (by default checked in, waiting to be seen, a doctor assigned, results back), in the affected zones plus the waiting room, with an active patient session. Patients in treatment, boarders and patients getting ready to go home don't get it. Family see a banner only; the display shows a generic message. ## Default code types [#default-code-types] | Category | Can notify patients | Examples | | -------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Medical | Only where enabled | Code Blue and Code Pink, trauma team activation, critical patient arriving (on by default); Code Stroke and STEMI (staff only by default) | | Security | Never | Code White, Purple, Silver, Yellow, Amber, Black | | Facility | Never | Code Red, Green, Grey, Brown, Orange, CBRN | Your site edits its catalogue in [Code types](/admin/settings/code-types). ## Codes from paging or the EHR [#codes-from-paging-or-the-ehr] A code that arrives from a paging system or the EHR never notifies patients until a charge nurse answers "Which patient is this for?". Paging codes outside the ED are recorded as staff-only. ## Related [#related] * [Codes](/staff/charge/codes): extend, clear, cancel, merge and throttle rules * [Codes and department status](/staff/codes-and-department-status): what patients see # Physicians (https://docs.edflow.space/staff/physicians) Physicians, residents, nurse practitioners and physician assistants in EDFlow: Assign me, Seen and Seen again, why the seen time matters to the patient's screen, NACRS PIA, and a quick-reference card. EDFlow needs very little from physicians: usually the EHR already records your assignment, orders and disposition. This page explains the few taps that make the patient's screen accurate, and what the patient sees about you. ## Assigned, seen and PIA are three different facts [#assigned-seen-and-pia-are-three-different-facts] | Fact | How it's set | Patient sees | | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | **Assigned** | Your first assignment, from the EHR or **Assign me** | "A doctor has been assigned to you. They'll see you as soon as they can." (after a short hold, in case you release it) | | **Seen** | An initial assessment in the EHR, **Seen** in the console, or, where the site allows, your first non-directive order, a consult request or a disposition | "Seen by a doctor" (or nurse practitioner, physician assistant, specialist) | | **PIA (NACRS)** | The site's NACRS rule: at assignment, or at the first explicit assessment | Nothing. Used for analytics only | Patients are never told they've been seen before they have been. If you **Assign me** and then release within the hold, the patient never hears about it. ![Patient detail: stage, care team, tests, requests and tasks, with the source of each fact (EHR, manual or override).](https://docs.edflow.space/screenshots/web/staff-patient-detail.png) ## The taps that matter [#the-taps-that-matter] * **Assign me** when you pick up a patient, if your EHR doesn't send it. * **Seen** when you first see them, if your EHR doesn't record the initial assessment. * **Seen again** after results are back and you've spoken with the patient. It ends "Results back: waiting to see your care team again" and feeds the results-to-decision measure. It is one tap on the board row and the companion app. ## What patients see about you [#what-patients-see-about-you] * Physicians: "Dr." and your full name. NPs and PAs: full name. Your site's policy applies to others. * Residents appear as **Doctor in training**, never "Resident". * Your photo only if you opt in and the site allows photos. * You can be hidden from patients entirely for your safety. See [Your profile](/staff/physicians/your-profile). * Family see your first name and "Doctor". ![Care team screen: the nurse with an opted-in photo, the doctor assigned, and their roles, with first names only where the hospital chooses.](https://docs.edflow.space/screenshots/web/patient-care-team.png) ## Handover [#handover] Release with the reason **Handover** and assign the incoming physician. The seen and PIA times don't change, and the patient gets a quiet note that their doctor changed. ## Quick-reference card [#quick-reference-card] | | | | ------------------------------------------- | ------------------------------------------------------------------------------------------- | | Pick up a patient | **Assign me** | | First assessment | **Seen** (if the EHR doesn't send it) | | After results | **Seen again** | | Results reviewed before patients see "back" | **Hold results status**, then **Release results now** | | Going home | Disposition, then the AVS. See [After-visit summary](/staff/physicians/after-visit-summary) | | Code | Two steps. See [Calling a code](/staff/physicians/calling-a-code) | | Never | Put diagnosis text in the summary's free text. Tell a patient results through the app. | ## Related [#related] * [Results and reassessment](/staff/physicians/results-and-reassessment) * [My metrics](/staff/physicians/my-metrics) # My metrics for physicians (https://docs.edflow.space/staff/physicians/my-metrics) Per-physician step metrics in EDFlow: definitions, the private self view against blinded peer ranges, case-mix context, and why there are never ranks. Clinician metrics are off by default. When your site turns them on, **My profile → My metrics** shows your own monthly values next to the range of your peers. ![My metrics: your own step times with the department range for comparison, private to you and never a ranking.](https://docs.edflow.space/screenshots/web/staff-my-metrics.png) ## The metrics [#the-metrics] Two rows are context rather than timings: **Imaging ordering rate** is the share of the visits you saw with at least one imaging order (cancelled orders are not counted), and **Share of visits seen** is your visits seen over every visit seen at the site that month, a relative volume with no trend line and never a rank. Read both with the case mix beside them. Each segment is attributed to the clinician responsible during it, from the care-team history. The decision clinician is the one on the disposition. Visits handed over before the decision are reported separately and excluded from the default view. Per-hour values use the physician shift schedule. ## Your self view [#your-self-view] * Your own monthly values against the **peer range**: the middle half (p25 to p75) of peers of the same clinician type with at least 20 visits that month. * A 6-month trend. * **Case mix** beside every metric: CTAS mix, age bands, ambulance share, night-shift share. Read your numbers with it. ## What others see [#what-others-see] * Managers with the blinded view see each clinician as a dot labelled "Clinician A, B…", relabelled randomly every month, never sorted by value. Clinicians with fewer than 20 visits in the month are hidden. * A named view exists only when the site turns it on explicitly, and every view is audited. * Never ranks, league tables or public display. ## Related [#related] * [Clinician metrics governance](/admin/analytics/clinician-metrics) * [Analytics definitions](/admin/analytics) # Results and reassessment (https://docs.edflow.space/staff/physicians/results-and-reassessment) How result status reaches patients in EDFlow: the site's results display delay, holding and releasing results, all results back, serial tests, reassessment, and the results-back digest. EDFlow never receives, stores or shows result values. Patients see only a test's steps and when it is **back**. This page explains how you control when "back" appears. ## When "back" appears [#when-back-appears] Each test has a result threshold per type (for imaging, preliminary report by default; performed for X-ray where ED physicians read their own films). When a test passes it, it shows **Back** to the patient after the site's display delay: * The first result back after the patient is seen sends one "Some of your results are back" notice. Later results update the screen silently. * Results of directive tests done before the patient is seen update silently and send nothing. * When every counted result is back and the patient has been seen, the stage becomes **Results back: waiting to see your care team again**, with the usual time to reassessment. ![Tests screen with every result back and the stage "Results back: waiting to see your care team again". The results themselves are never shown.](https://docs.edflow.space/screenshots/web/patient-results-back.png) ## Holding results [#holding-results] On the patient's **Tests** tab, **Hold results status** keeps completed tests at "In the lab" or "Being read" and sends no result notice. The patient sees: "Your care team is reviewing your tests. They'll talk with you about them." **Release results now** shows every completed test as back at once. A disposition also releases the hold. _Screenshot pending: staff-results-release_ ## Serial tests [#serial-tests] For tests that usually need a repeat (for example troponin), the patient sees "A repeat test is usually needed" after the first result, and all-back waits for the site's serial hold time unless a repeat order or a disposition arrives. A timed repeat shows "Scheduled for about …" with no estimate until then. ## More tests after all back [#more-tests-after-all-back] A new result-bearing order returns the patient to "Tests under way" and adds "More tests were ordered. This is common and part of making a plan with you." to their inbox, without a push. The next all-back notifies again. ## Reassessment [#reassessment] Reassessment is recorded by an EHR reassessment event, a disposition, **Seen again**, or (where the site maps them) a new order after all back, a consult request, a signed note or a move to a procedure area. The board shows a **Results back** alert with the time since all-back: amber after p75, flagged as the bottleneck after p90. ## Results-back digest [#results-back-digest] In **My profile → Notifications**, turn on the **Results back** digest to get "Results back · Zone A" (bed label only if the site allows it) once per visit per result cycle. ## Related [#related] * [Tests](/patients/tests), the patient's view * [Tests and benchmarks](/admin/settings/tests-and-benchmarks) # Your profile (https://docs.edflow.space/staff/physicians/your-profile) Control how patients see you in EDFlow: the name display policy, the optional photo, being hidden from patients, linked EHR identities, and your notification settings. Open **My profile** from the header. ![My profile: display name policy, optional photo, hide from patients, sessions and security.](https://docs.edflow.space/screenshots/web/staff-profile.png) ## How patients see your name [#how-patients-see-your-name] | Role | Default | | --------------------------------------- | ---------------------------------------------------------------- | | Physician | "Dr." with your first and last name | | Nurse practitioner, physician assistant | First and last name | | Others | First name and last initial, or first name only, per site policy | You can change your display-name preference. A manager reviews the change before patients see it. Family always see your first name only. ## Photo [#photo] Photos are opt-in. Where the site allows them, upload a JPEG or PNG under 2 MB. If the site requires approval, patients see it only after a manager approves it. ## Hidden from patients [#hidden-from-patients] For your safety or privacy, a manager can hide you from patients. You still appear on the staff board, but never on the patient's care team, the family view or notifications. ## Linked EHR identities [#linked-ehr-identities] Read-only. These link your account to your EHR practitioner record so assignments from the EHR show your name. Changes are made by a manager with a second check and alert the privacy officer. ## Notifications [#notifications] Desktop notifications, sounds for high requests, your on-shift override, and the **Results back** digest. ## Also on this page [#also-on-this-page] Language, theme, density, password, two-step sign-in and recovery codes, active sessions, **What's new**, and **Take the tour again**. # admission.status_changed (https://docs.edflow.space/developers/events/admission-status-changed) Bed flow for an admitted patient waiting in the ED. Bed flow for an admitted patient waiting in the ED. **When to send:** A bed is requested (A14), assigned or ready, or the pending admission is cancelled (A27). - Sub-status of admitted_waiting_for_bed: bed requested, assigned, ready. - Boarding time is recorded for analytics. **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** ADT^A07, ADT^A14, ADT^A27 · **FHIR R4:** — JSON Schema: https://docs.edflow.space/schemas/ehr/v1/admission.status_changed.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:ADT000455:0", "type": "admission.status_changed", "siteCode": "demo-ed", "occurredAt": "2026-09-14T16:20:00-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "adt" }, "encounter": { "externalId": "3000124001", "idSystem": "epic-csn" }, "data": { "status": "bed_requested", "requestedAt": "2026-09-14T16:20:00-04:00", "unit": { "code": "7W", "display": "7 West (Medicine)" }, "admittingService": { "system": "https://edflow.space/fhir/CodeSystem/consult-service", "code": "internal_medicine", "display": "Internal Medicine" } } } ``` # careteam.member_assigned (https://docs.edflow.space/developers/events/careteam-member-assigned) One care-team member was assigned. One care-team member was assigned. **When to send:** A clinician signs up for or is assigned to the patient. - Adds the member to the care team. - May set the NACRS PIA under piaSource attending_assigned; never sets seen (D-25). **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** — · **FHIR R4:** — JSON Schema: https://docs.edflow.space/schemas/ehr/v1/careteam.member_assigned.schema.json ```json { "specVersion": "1.0", "id": "demo-oracle-eso:TRK88213:0", "type": "careteam.member_assigned", "siteCode": "demo-ed", "occurredAt": "2026-09-14T09:11:50-04:00", "source": { "kind": "ehr", "system": "oracle-health", "feed": "adt", "messageId": "TRK88213" }, "encounter": { "externalId": "FIN20260914-0042", "idSystem": "oracle-fin" }, "data": { "role": "primary_nurse", "practitioner": { "externalId": "N77001", "idSystem": "oracle-prsnl", "givenName": "Ben", "familyName": "Okafor", "credentials": "RN" }, "assignedAt": "2026-09-14T09:11:50-04:00", "isPrimary": true } } ``` # careteam.member_released (https://docs.edflow.space/developers/events/careteam-member-released) One care-team member was released. One care-team member was released. **When to send:** Handover, shift end or reassignment. - Removes the member; the handover reason attributes later segments to the next clinician (D-47). **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** — · **FHIR R4:** — JSON Schema: https://docs.edflow.space/schemas/ehr/v1/careteam.member_released.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:ADT000402:0", "type": "careteam.member_released", "siteCode": "demo-ed", "occurredAt": "2026-09-14T19:00:00-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "adt" }, "encounter": { "externalId": "3000124001", "idSystem": "epic-csn" }, "data": { "role": "attending_physician", "practitioner": { "externalId": "P10442", "idSystem": "epic-ser", "givenName": "Alicia", "familyName": "Moreno", "credentials": "MD" }, "releasedAt": "2026-09-14T19:00:00-04:00", "reason": "handover" } } ``` # careteam.snapshot (https://docs.edflow.space/developers/events/careteam-snapshot) The authoritative team asserted by this source, limited to rolesCovered. The authoritative team asserted by this source, limited to rolesCovered. **When to send:** PV1 plus ROL, Encounter.participant or an Oracle encounter-level CareTeam. - Members previously asserted by the same source within the covered roles, and missing here, are released at asOf. - Manual and zone-derived assignments are never removed. **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** ADT^A04, ADT^A08 · **FHIR R4:** Encounter, CareTeam JSON Schema: https://docs.edflow.space/schemas/ehr/v1/careteam.snapshot.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:ADT000188:1", "type": "careteam.snapshot", "siteCode": "demo-ed", "occurredAt": "2026-09-14T09:11:50-04:00", "recordedAt": "2026-09-14T09:12:05-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "adt" }, "encounter": { "externalId": "3000123456", "idSystem": "epic-csn" }, "data": { "asOf": "2026-09-14T09:11:50-04:00", "rolesCovered": [ "attending_physician", "resident_physician", "primary_nurse" ], "members": [ { "role": "attending_physician", "assignedAt": "2026-09-14T09:04:12-04:00", "practitioner": { "externalId": "P10442", "idSystem": "epic-ser", "givenName": "Alicia", "familyName": "Moreno", "credentials": "MD", "displayName": "Dr. Alicia Moreno" } }, { "role": "primary_nurse", "assignedAt": "2026-09-14T09:11:50-04:00", "practitioner": { "externalId": "N77001", "idSystem": "epic-ser", "givenName": "Ben", "familyName": "Okafor", "credentials": "RN" } } ] } } ``` # consult.status_changed (https://docs.edflow.space/developers/events/consult-status-changed) A consult was requested, started, completed or cancelled. A consult was requested, started, completed or cancelled. **When to send:** A consult order or ED consult event changes. - The stage is awaiting_consult while requested or in progress. - Sensitive services are never named to patients or family (D-24). **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** ORM^O01, OMG^O19, OML^O21, OMI^O23 · **FHIR R4:** ServiceRequest JSON Schema: https://docs.edflow.space/schemas/ehr/v1/consult.status_changed.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:ORD004520:0", "type": "consult.status_changed", "siteCode": "demo-ed", "occurredAt": "2026-09-14T11:05:00-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "orders", "messageId": "ORD004520", "messageType": "ORM^O01" }, "encounter": { "externalId": "3000124001", "idSystem": "epic-csn" }, "data": { "consult": { "id": "PL88190" }, "service": { "system": "https://edflow.space/fhir/CodeSystem/consult-service", "code": "internal_medicine", "display": "Internal Medicine" }, "status": "requested", "requestedAt": "2026-09-14T11:05:00-04:00" } } ``` # department.census_reported (https://docs.edflow.space/developers/events/department-census-reported) Aggregate department status with no identifiers. Aggregate department status with no identifiers. **When to send:** Sites that send only enrolled patients, or that override the busy signal. - Drives volume suggestions and the display's typical wait (D-18). **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** — · **FHIR R4:** — JSON Schema: https://docs.edflow.space/schemas/ehr/v1/department.census_reported.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:census:1789399800", "type": "department.census_reported", "siteCode": "demo-ed", "occurredAt": "2026-09-14T11:30:00-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "census" }, "data": { "asOf": "2026-09-14T11:30:00-04:00", "waiting": 14, "inTreatment": 31, "boarding": 9, "total": 54, "arrivalsLastHour": 11, "volumeLevel": "busy", "medianWaitToAssessmentMinutes": 95 } } ``` # department.code_called (https://docs.edflow.space/developers/events/department-code-called) An emergency code was called. An emergency code was called. **When to send:** From the paging or switchboard system, or the staff console. - Patients see the site-approved notice when the code type notifies patients; the push is always generic. - Staff see a banner. **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** — · **FHIR R4:** — JSON Schema: https://docs.edflow.space/schemas/ehr/v1/department.code_called.schema.json ```json { "specVersion": "1.0", "id": "demo-paging:CB-20260914-0931", "type": "department.code_called", "siteCode": "demo-ed", "occurredAt": "2026-09-14T09:31:00-04:00", "source": { "kind": "paging", "system": "other", "feed": "vocera" }, "data": { "codeId": "CB-20260914-0931", "codeType": "blue", "calledAt": "2026-09-14T09:31:00-04:00", "area": "Resus 2", "expectedDurationMinutes": 45 } } ``` # department.code_cleared (https://docs.edflow.space/developers/events/department-code-cleared) A code was cleared. A code was cleared. **When to send:** The code ends. - Banners are removed; the duration is recorded for delay analytics. **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** — · **FHIR R4:** — JSON Schema: https://docs.edflow.space/schemas/ehr/v1/department.code_cleared.schema.json ```json { "specVersion": "1.0", "id": "demo-paging:CB-20260914-0931:clear", "type": "department.code_cleared", "siteCode": "demo-ed", "occurredAt": "2026-09-14T10:04:00-04:00", "source": { "kind": "paging", "system": "other", "feed": "vocera" }, "data": { "codeId": "CB-20260914-0931", "clearedAt": "2026-09-14T10:04:00-04:00" } } ``` # department.roster_reported (https://docs.edflow.space/developers/events/department-roster-reported) The complete list of encounters active in the ED, for reconciliation. The complete list of encounters active in the ED, for reconciliation. **When to send:** Every 15 minutes per ED site. - Two consecutive misses and 15 minutes of silence close a visit as unknown, silently; boarders are never closed. - A roster that would close too many visits is quarantined for review (circuit breaker). **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** — · **FHIR R4:** — JSON Schema: https://docs.edflow.space/schemas/ehr/v1/department.roster_reported.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:roster:1789399800", "type": "department.roster_reported", "siteCode": "demo-ed", "occurredAt": "2026-09-14T11:30:00-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "census" }, "data": { "asOf": "2026-09-14T11:30:00-04:00", "complete": true, "activeEncounters": [ { "externalId": "3000123456", "idSystem": "epic-csn" }, { "externalId": "3000124001", "idSystem": "epic-csn" } ] } } ``` # encounter.arrived (https://docs.edflow.space/developers/events/encounter-arrived) Registration or arrival at the ED. Registration or arrival at the ED. **When to send:** A04 (or A01 at some sites), or an Encounter first seen arrived or in progress. - Creates the encounter in checked_in (or upserts it on a replay). - Access tokens are issued only for a confirmed identity. **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** ADT^A04, ADT^A01 · **FHIR R4:** Encounter JSON Schema: https://docs.edflow.space/schemas/ehr/v1/encounter.arrived.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:ADT000123:0", "type": "encounter.arrived", "siteCode": "demo-ed", "occurredAt": "2026-09-14T08:02:11-04:00", "recordedAt": "2026-09-14T08:02:14-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "adt", "messageId": "ADT000123", "messageType": "ADT^A04", "mappingProfile": "demo-epic@3" }, "encounter": { "externalId": "3000123456", "idSystem": "epic-csn" }, "data": { "arrivedAt": "2026-09-14T08:02:11-04:00", "arrivalMode": "walk_in", "patient": { "mrn": "E1234567", "givenName": "Jordan", "familyName": "Tremblay", "birthDate": "1991-04-02", "administrativeGender": "male", "preferredLanguage": "fr", "identityStatus": "confirmed", "privacy": { "confidential": false } }, "location": { "code": "EDWR/WR01", "area": "waiting_room", "display": "Waiting room" } } } ``` # encounter.assessed (https://docs.edflow.space/developers/events/encounter-assessed) The physician initial assessment or a reassessment. The physician initial assessment or a reassessment. **When to send:** The clinician actually assessed the patient (never for an assignment alone, D-25). - initial sets seen (and the NACRS PIA when the role is a PIA role). - reassessment clears awaiting_reassessment. **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** — · **FHIR R4:** — JSON Schema: https://docs.edflow.space/schemas/ehr/v1/encounter.assessed.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:ADT000188:2", "type": "encounter.assessed", "siteCode": "demo-ed", "occurredAt": "2026-09-14T09:04:12-04:00", "recordedAt": "2026-09-14T09:12:05-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "adt" }, "encounter": { "externalId": "3000123456", "idSystem": "epic-csn" }, "data": { "kind": "initial", "assessedAt": "2026-09-14T09:04:12-04:00", "role": "attending_physician", "practitioner": { "externalId": "P10442", "idSystem": "epic-ser", "givenName": "Alicia", "familyName": "Moreno", "credentials": "MD", "displayName": "Dr. Alicia Moreno" } } } ``` # encounter.cancelled (https://docs.edflow.space/developers/events/encounter-cancelled) The registration was voided. The registration was voided. **When to send:** A11 (unless the site uses A11 for patients who leave), or Encounter cancelled or entered-in-error. - Revokes every token and session at once; removes the visit from the board and analytics. **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** ADT^A11 · **FHIR R4:** Encounter JSON Schema: https://docs.edflow.space/schemas/ehr/v1/encounter.cancelled.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:ADT000140:0", "type": "encounter.cancelled", "siteCode": "demo-ed", "occurredAt": "2026-09-14T08:20:03-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "adt" }, "encounter": { "externalId": "3000123999", "idSystem": "epic-csn" }, "data": { "reason": "duplicate" } } ``` # encounter.departed (https://docs.edflow.space/developers/events/encounter-departed) The patient physically left the ED. The patient physically left the ED. **When to send:** A03, a move to an inpatient unit, or Encounter finished. - Stage departed (the deceased pause for deceased); the grace window starts; later events never notify. **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** ADT^A02, ADT^A03, ADT^A11 · **FHIR R4:** Encounter JSON Schema: https://docs.edflow.space/schemas/ehr/v1/encounter.departed.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:ADT000377:1", "type": "encounter.departed", "siteCode": "demo-ed", "occurredAt": "2026-09-14T13:38:00-04:00", "recordedAt": "2026-09-14T13:40:09-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "adt" }, "encounter": { "externalId": "3000123456", "idSystem": "epic-csn" }, "data": { "departedAt": "2026-09-14T13:38:00-04:00", "disposition": "discharge" } } ``` # encounter.departure_cancelled (https://docs.edflow.space/developers/events/encounter-departure-cancelled) The discharge was reversed. The discharge was reversed. **When to send:** A13. - Reopens the encounter in the stage derived from its other state; expired family links are not revived. **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** ADT^A13 · **FHIR R4:** — JSON Schema: https://docs.edflow.space/schemas/ehr/v1/encounter.departure_cancelled.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:ADT000381:0", "type": "encounter.departure_cancelled", "siteCode": "demo-ed", "occurredAt": "2026-09-14T13:44:31-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "adt" }, "encounter": { "externalId": "3000123456", "idSystem": "epic-csn" }, "data": { "reason": "clerical_error" } } ``` # encounter.disposition_decided (https://docs.edflow.space/developers/events/encounter-disposition-decided) A decision to discharge, admit, observe or transfer. A decision to discharge, admit, observe or transfer. **When to send:** The ED disposition is recorded (A08 site field, A06, or the disposition activity). - discharge → preparing_discharge; admit or observation → admitted_waiting_for_bed; deceased → the deceased pause. **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** ADT^A01, ADT^A08, ADT^A03, ADT^A06 · **FHIR R4:** — JSON Schema: https://docs.edflow.space/schemas/ehr/v1/encounter.disposition_decided.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:ADT000350:0", "type": "encounter.disposition_decided", "siteCode": "demo-ed", "occurredAt": "2026-09-14T13:02:40-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "adt" }, "encounter": { "externalId": "3000123456", "idSystem": "epic-csn" }, "data": { "decision": "discharge", "decidedAt": "2026-09-14T13:02:40-04:00", "practitioner": { "externalId": "P10442", "idSystem": "epic-ser", "givenName": "Alicia", "familyName": "Moreno", "credentials": "MD" } } } ``` # encounter.location_changed (https://docs.edflow.space/developers/events/encounter-location-changed) A bed or area move, leave of absence or return. A bed or area move, leave of absence or return. **When to send:** A02, A08 PV1-3, A12, A21 and A22, or the active Encounter.location. - Updates the location; out_of_department shows the patient as stepped out; inpatient_unit alone never departs the patient. **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** ADT^A08, ADT^A02, ADT^A12, ADT^A21, ADT^A22 · **FHIR R4:** Encounter JSON Schema: https://docs.edflow.space/schemas/ehr/v1/encounter.location_changed.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:ADT000188:0", "type": "encounter.location_changed", "siteCode": "demo-ed", "occurredAt": "2026-09-14T09:11:50-04:00", "recordedAt": "2026-09-14T09:12:05-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "adt" }, "encounter": { "externalId": "3000123456", "idSystem": "epic-csn" }, "data": { "location": { "code": "EDACU/A12/01", "area": "treatment_space", "display": "Acute 12" }, "effectiveAt": "2026-09-14T09:11:50-04:00", "reason": "bed_assigned" } } ``` # encounter.triaged (https://docs.edflow.space/developers/events/encounter-triaged) Triage completed, or a re-triage. Triage completed, or a re-triage. **When to send:** Triage is documented (A08 with the CTAS OBX, or the acuity Observation). - Stage waiting_to_be_seen; CTAS is staff-only and chooses the benchmark bucket. **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** ADT^A04, ADT^A08 · **FHIR R4:** Encounter, Observation JSON Schema: https://docs.edflow.space/schemas/ehr/v1/encounter.triaged.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:ADT000131:0", "type": "encounter.triaged", "siteCode": "demo-ed", "occurredAt": "2026-09-14T08:15:30-04:00", "recordedAt": "2026-09-14T08:16:02-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "adt" }, "encounter": { "externalId": "3000123456", "idSystem": "epic-csn" }, "data": { "triagedAt": "2026-09-14T08:15:30-04:00", "ctas": 3, "triageNurse": { "externalId": "N77001", "idSystem": "epic-ser", "givenName": "Ben", "familyName": "Okafor", "credentials": "RN" } } } ``` # order.placed (https://docs.edflow.space/developers/events/order-placed) A test or diagnostic order (the full order asserted each time). A test or diagnostic order (the full order asserted each time). **When to send:** ORC-1 NW or XO, or an active ServiceRequest. - Stage tests_in_progress once seen; derived tasks; an NPO diet becomes a task (D-44). **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** ORM^O01, OMG^O19, OML^O21, OMI^O23 · **FHIR R4:** ServiceRequest JSON Schema: https://docs.edflow.space/schemas/ehr/v1/order.placed.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:ORD004411:0", "type": "order.placed", "siteCode": "demo-ed", "occurredAt": "2026-09-14T09:18:58-04:00", "recordedAt": "2026-09-14T09:19:01-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "orders", "messageId": "ORD004411", "messageType": "ORM^O01" }, "encounter": { "externalId": "3000123456", "idSystem": "epic-csn" }, "data": { "order": { "placerOrderId": "PL88121" }, "code": { "system": "urn:edflow:site:demo:orderable", "code": "IMG4410", "display": "CT ABDOMEN PELVIS W CONTRAST" }, "category": "imaging", "modality": "ct", "priority": "stat", "orderedAt": "2026-09-14T09:18:58-04:00", "orderingPractitioner": { "externalId": "P10442", "idSystem": "epic-ser", "givenName": "Alicia", "familyName": "Moreno", "credentials": "MD" }, "flags": { "contrast": true, "requiresConsent": true } } } ``` # order.results_reviewed (https://docs.edflow.space/developers/events/order-results-reviewed) A clinician acknowledged the results. A clinician acknowledged the results. **When to send:** Rarely available from feeds; staff can tap it. - Recorded for analytics; for imaging it counts as back where ED physicians read their own films (D-28). **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** — · **FHIR R4:** — JSON Schema: https://docs.edflow.space/schemas/ehr/v1/order.results_reviewed.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:EVT000077:0", "type": "order.results_reviewed", "siteCode": "demo-ed", "occurredAt": "2026-09-14T10:52:00-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "ed-events", "messageId": "EVT000077" }, "encounter": { "externalId": "3000123456", "idSystem": "epic-csn" }, "data": { "reviewedAt": "2026-09-14T10:52:00-04:00", "practitioner": { "externalId": "P10442", "idSystem": "epic-ser", "givenName": "Alicia", "familyName": "Moreno", "credentials": "MD" } } } ``` # order.status_changed (https://docs.edflow.space/developers/events/order-status-changed) The current status of an order, with every timestamp known so far. The current status of an order, with every timestamp known so far. **When to send:** ORM SC, ORU, SIU, or a DiagnosticReport, Specimen, ImagingStudy, Appointment or Task. - Patient test steps advance; results count only after the display delay and holds (D-27, D-29). - Result content is never received or shown. **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** ORM^O01, OMG^O19, OML^O21, OMI^O23, ORU^R01, SIU^S12, SIU^S13, SIU^S14, SIU^S15 · **FHIR R4:** ServiceRequest, Specimen, ImagingStudy, DiagnosticReport, Appointment, Task JSON Schema: https://docs.edflow.space/schemas/ehr/v1/order.status_changed.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:RES009981:0", "type": "order.status_changed", "siteCode": "demo-ed", "occurredAt": "2026-09-14T10:35:10-04:00", "recordedAt": "2026-09-14T10:35:12-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "results", "messageId": "RES009981", "messageType": "ORU^R01" }, "encounter": { "externalId": "3000123456", "idSystem": "epic-csn" }, "data": { "order": { "placerOrderId": "PL88120", "fillerOrderId": "FL5521" }, "status": "resulted", "code": { "system": "urn:edflow:site:demo:orderable", "code": "LAB123", "display": "URINALYSIS WITH MICROSCOPY" }, "category": "lab", "timestamps": { "collectedAt": "2026-09-14T09:41:02-04:00", "receivedAt": "2026-09-14T09:55:30-04:00", "finalAt": "2026-09-14T10:35:10-04:00" } } } ``` # patient.merged (https://docs.edflow.space/developers/events/patient-merged) Two MRNs were merged. Two MRNs were merged. **When to send:** A40 (A34 or A18 in older feeds). - Encounters carrying the retired MRN hash are relinked to the surviving hash. **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** ADT^A40, ADT^A34, ADT^A18 · **FHIR R4:** — JSON Schema: https://docs.edflow.space/schemas/ehr/v1/patient.merged.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:ADT000512:0", "type": "patient.merged", "siteCode": "demo-ed", "occurredAt": "2026-09-14T15:10:00-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "adt" }, "data": { "survivingMrn": "E1234567", "retiredMrn": "E7654321" } } ``` # patient.updated (https://docs.edflow.space/developers/events/patient-updated) A demographic or privacy correction. A demographic or privacy correction. **When to send:** A08 with PID-5, PID-7, PID-15, PD1-12 or PV2-22. - Updates the display name, match key and privacy flags; a privacy flag revokes family links. **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** ADT^A08 · **FHIR R4:** — JSON Schema: https://docs.edflow.space/schemas/ehr/v1/patient.updated.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:ADT000211:0", "type": "patient.updated", "siteCode": "demo-ed", "occurredAt": "2026-09-14T09:40:12-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "adt" }, "encounter": { "externalId": "3000123777", "idSystem": "epic-csn" }, "data": { "patient": { "givenName": "Samira", "familyName": "Haddad", "birthDate": "1978-11-23", "identityStatus": "confirmed", "privacy": { "confidential": true } } } } ``` # system.heartbeat (https://docs.edflow.space/developers/events/system-heartbeat) Feed liveness. Feed liveness. **When to send:** Every 60 seconds per feed. - Feed liveness: 5 minutes of silence shows delayed, 15 minutes down (F-16). **Idempotency:** Stable across retries and derived only from source data: HL7 {sourceId}:{feedKey}:{MSH-7 ms}:{MSH-10}:{eventKey}, FHIR {sourceId}:fhir:{type}/{id}/_history/{version}:{n}. **HL7 v2:** — · **FHIR R4:** — JSON Schema: https://docs.edflow.space/schemas/ehr/v1/system.heartbeat.schema.json ```json { "specVersion": "1.0", "id": "demo-epic-bridges:hb:1789398000", "type": "system.heartbeat", "occurredAt": "2026-09-14T11:00:00-04:00", "source": { "kind": "ehr", "system": "epic", "feed": "adt" }, "data": { "queueDepth": 0 } } ```