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.
- Version ultérieure
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
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}/acknowledgeand…/resolve(scoperequests:write, the site's write-back switch, and anIdempotency-Key).by.practitioneris 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".
printf '%s' '{"by":{"practitioner":{"display":"Sam Rivera","externalId":"SYN-N4455","idSystem":"epic-ser"}}}' > body.jsoncurl -sS -X POST 'https://api.sandbox.edflow.space/v1/requests/%7BrequestId%7D/acknowledge' \ -H 'Content-Type: application/json' \ -H "Authorization: Bearer $EDFLOW_ACCESS_TOKEN" \ --data-binary @body.jsonEngines 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
| 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 |
| 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
- 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
Dernière mise à jour le
Cette page vous a-t-elle été utile?
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.
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.