What is SMART on FHIR?

The two halves of the name

SMART on FHIR is two things stacked together. SMART — Substitutable Medical Applications, Reusable Technologies — is a launch and authorization framework developed at Boston Children's Hospital and Harvard Medical School. FHIR — Fast Healthcare Interoperability Resources — is the data standard that defines how clinical concepts like patients, encounters, observations, and medications are represented and exchanged.

The combination — SMART on FHIR — is the standard EHRs use to let third-party apps launch inside the clinician's workflow with patient context and access to clinical data through a defined API.

Why hospitals require it

Before SMART on FHIR existed, every healthcare vendor that wanted to integrate with an EHR built a one-off integration — proprietary APIs, point-to-point data dumps, screen scraping, custom HL7 v2 interfaces. That model was slow, brittle, expensive, and a compliance nightmare. Hospitals had to security-review every vendor's bespoke approach from scratch.

SMART on FHIR replaced that with one standard. Every certified EHR in the United States now exposes a SMART on FHIR endpoint — partly because the 21st Century Cures Act and the ONC's interoperability rules require them to. For a hospital, this means they can evaluate any third-party app against the same security checklist, the same scope model, and the same audit log surface.

For a vendor, this means the gate to integrating with Epic isn't "negotiate a custom contract with Epic engineering." The gate is "ship a SMART on FHIR app that passes the hospital's security review and gets listed on Epic Showroom."

How a SMART on FHIR launch actually works

From the clinician's perspective, it looks simple: they click a button inside Epic, your app opens, and the right patient is already loaded. From the technical side, this is what happens:

1. The clinician launches your app from inside the EHR. The EHR redirects to your app's launch URL with a launch token.
2. Your app initiates the SMART App Launch flow: it asks the EHR's authorization server for an access token, declaring the SMART scopes it needs (e.g. patient/Patient.read).
3. The EHR returns an access token plus a context object containing the patient ID and (usually) the encounter ID. This is patient context resolution — the app didn't pick the patient; the EHR did.
4. Your app uses the access token to call the EHR's FHIR endpoints. Reads return clinical resources; writes create or update them.
5. The EHR logs every access, scoped to the launching user and the patient context. The hospital's compliance team gets a complete audit trail.

SMART scopes — the security control plane

Scopes are how SMART on FHIR enforces least privilege. Every access token your app receives is bound to a specific set of scopes — for example, patient/Observation.read lets you read observations for the launched patient, and nothing else. You can't read another patient's records by passing a different ID; the EHR enforces the patient context at the token level.

This is the part hospital security teams scrutinize the most. The shorter and more specific your scope list, the faster the review goes. Asking for user/*.* — read everything for the launching user — is a way to stall a deal for months. Ask for what you need; nothing more.

EHR launch vs standalone launch

SMART on FHIR supports two launch modes. EHR launch is the one that matters for most healthcare vendors: the clinician opens your app from inside Epic and you receive the patient context. Standalone launch is the inverse — your app is opened first, often as a patient-facing web app, and then connects to an EHR session via OAuth.

Patient-facing engagement apps tend to use standalone launch. Clinician-facing apps — ambient scribes, CDS, RPM dashboards, care coordination — use EHR launch. If you're unsure which one you need, ask "where will the user be when they open this?" If the answer is "inside Epic," you need EHR launch.

What SMART on FHIR doesn't solve

It's the integration standard, not the deployment story. Building a SMART on FHIR app is the easy part now — code generation tools can scaffold one in an afternoon. Getting that app into a hospital's Epic instance still requires:

• HIPAA-compliant hosting and a Business Associate Agreement.
• SOC 2 Type II posture — the audit report hospitals' procurement teams demand.
• An Epic Showroom listing — Epic's vendor marketplace.
• Per-hospital security review against the hospital's specific risk model.
• Maintenance when Epic ships breaking changes (roughly quarterly).

SMART on FHIR is the technical contract. Everything around it — the compliance, the distribution, the maintenance — is the runtime. That's the part SoFaaS™ owns.