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.
- Version 1.1
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
EHR launch
The EHR opens EDFlow with launch and iss.
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
fhirUser (a Practitioner) must resolve to an existing, invited staff membership through its EHR identities. SMART never creates accounts.
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
Authorization is still enforced by EDFlow with the membership's role and site. Opening is audited like any other.
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"
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
Dernière mise à jour le
Cette page vous a-t-elle été utile?
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.
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.