SMART on FHIR in plain English
SMART on FHIR sounds like an acronym soup, but the idea is simple: a standard way for an app to log in to an EHR and get permission to use its data. Here it is without the jargon.
The problem it solves
Before SMART, every EHR vendor secured its FHIR API a little differently, so an app that worked with one system had to be re-integrated for the next. SMART on FHIR standardises how a third-party app authenticates and gets permission to read or write clinical data — so you build the integration once and reuse it across compliant EHRs.
How it works, briefly
SMART is OAuth 2.0 applied to healthcare. Your app requests specific scopes (for example, patient/Observation.read), the user authorises it through the EHR's own login, and the app receives an access token plus a launch context — which patient the session is about. From there it calls the FHIR API like any REST client, scoped to exactly what it was granted.
EHR launch vs standalone launch
In an EHR launch, a clinician opens your app from inside the EHR and the patient context comes along automatically. In a standalone launch, the user opens your app directly and chooses the context. Supporting both widens where your product can live.
Scopes are least privilege for clinical data
Ask only for the resources and actions you need. Narrow scopes are easier to get approved, lower your risk, and shorten every security review. Requesting patient/*.* when you only read observations is a red flag to any careful health system.
Why it matters for your product
SMART on FHIR turns "integrate with each EHR" into "integrate with the standard." It's the difference between a bespoke project per customer and a product that plugs into an ecosystem — and it's increasingly what health systems expect before they let an app near their data.
Working on something similar? We build and run these systems for healthcare and software teams. Talk to an engineer →