SMART on FHIR: What It Is and What It Means for Your API Program

If you're building or managing healthcare APIs, you'll run into SMART on FHIR. It's referenced in CMS-0057-F, required by ONC's HTI-1 Rule, and expected by every third-party developer who wants to integrate with your FHIR APIs.

But most explanations of SMART on FHIR are written for developers who already understand OAuth, or for clinicians who don't need the technical details. If you're an API platform team trying to figure out what this means for how you manage partner access, the standard documentation isn't much help.

This page explains SMART on FHIR in plain terms: what it is, how it works, and what it requires from your API program.

What Is SMART on FHIR?

SMART on FHIR is an open standard that defines how third-party applications connect to healthcare systems through FHIR APIs. It combines OAuth 2.0 authorization with FHIR data standards so that applications can request specific permissions to access patient data, and healthcare systems can enforce those permissions consistently.

Think of it this way: FHIR defines the data. SMART defines the locks on the doors.

What Does SMART Stand For?

SMART stands for Substitutable Medical Applications, Reusable Technologies. The name reflects the original goal: building healthcare applications that can work across different electronic health record (EHR) systems without custom integration for each one. A SMART-enabled app written for one EHR should be able to connect to another EHR that supports the same standard.

In practice, "substitutable" means standardized. The authorization flow, the scope format, and the data access patterns are the same regardless of which healthcare system the application connects to.

What Is the Difference Between SMART on FHIR and FHIR?

FHIR (Fast Healthcare Interoperability Resources) is a data standard. It defines how health data is structured and exchanged through APIs. Patient records, observations, medications, conditions, and other clinical data all have defined FHIR resource types with standard fields and formats.

SMART on FHIR is an authorization layer that sits on top of FHIR. It doesn't define the data. It defines who can access it and how they prove they're allowed to.

• FHIR answers: what does the data look like and how do I request it?
• SMART on FHIR answers: who is allowed to request it and what are they allowed to see?

You can have FHIR APIs without SMART on FHIR. But without a standardized authorization layer, every healthcare system implements access control differently, and every third-party developer has to build custom authentication for each system they integrate with. SMART on FHIR solves that by making authorization consistent.

What Are SMART on FHIR Scopes?

Scopes are the core of SMART on FHIR authorization. A scope defines exactly which FHIR resources an application is allowed to access and what it can do with them.

The format follows a consistent pattern: context/ResourceType.permission

• Context defines whose data: patient (data for a specific patient who authorized access), user (data the logged-in user can see), or system (backend access without a user present)
• ResourceType is the FHIR resource: Patient, Observation, MedicationRequest, Condition, etc.
• Permission is what the application can do: read, write, or * (both)

Examples:

• patient/Observation.read - read observation data for a specific patient
• patient/MedicationRequest.read - read medication requests for a specific patient
• system/Patient.read - read patient records without a user session (backend service)
• user/Condition.write - write condition data on behalf of the logged-in user

Scopes are not optional. They're the mechanism that ensures a wellness app that only needs step counts doesn't get access to medication history. Every application declares the scopes it needs, and the authorization server enforces those boundaries on every request.

How Does SMART on FHIR Authorization Work?

The authorization flow follows OAuth 2.0, with healthcare-specific additions:

1. Registration. The third-party application registers with your healthcare system. During registration, it declares which FHIR scopes it needs and what it will use them for.
2. Authorization request. When the application needs to access data, it redirects to your authorization server and requests the specific scopes it needs.
3. User consent. For patient-facing applications, the patient sees which data the application is requesting and approves or denies access. For system-level access, approval happens during the registration/review process rather than at runtime.
4. Token issuance. Your authorization server issues an access token that's bound to the approved scopes. The token only works for the data the application was authorized to access.
5. API access. The application uses the token to call your FHIR APIs. Each call is checked against the token's scopes. A request for data outside the approved scopes is rejected.
6. Token refresh or expiration. Tokens expire. Long-running applications use refresh tokens to maintain access without re-authorization. Revocation is immediate when needed.

Every step in this flow generates data that auditors will ask about: who registered, what scopes were requested, who approved them, when tokens were issued, and what data was accessed with those tokens.

Is SMART on FHIR Required by Regulation?

Yes. Both CMS-0057-F and ONC's HTI-1 Rule expect SMART on FHIR authorization for FHIR API access.

CMS-0057-F requires FHIR-based APIs for patient access, provider access, payer-to-payer exchange, and prior authorization by January 2027. These APIs must enforce scope-based access control and maintain audit logs of all access events.

The HTI-1 Rule requires certified health IT to support FHIR APIs with standardized authorization. Certified API developers must publish FHIR service base URLs and support OAuth 2.0 authorization with SMART on FHIR scopes.

The practical result: if you're a payer, health plan, or health IT vendor subject to these rules, SMART on FHIR isn't a nice-to-have. It's a compliance requirement with a deadline.

What Does SMART on FHIR Mean for API Platform Teams?

For API platform teams, SMART on FHIR turns API access management into a structured discipline. You're no longer just handing out API keys. You're managing a lifecycle:

• Application registration with declared scope requirements
• Scope review and approval by someone authorized to grant access
• Credential issuance tied to approved scopes
• Enforcement on every API call
• Audit logging that captures who accessed what, when, and under which scopes
• Periodic review to verify active applications still need the access they have
• Revocation when access is no longer appropriate

At small scale, this can be managed manually. At the scale CMS-0057-F anticipates, with dozens or hundreds of third-party applications accessing patient data, manual scope management becomes a compliance risk.

The teams that handle this well treat application lifecycle management as a product problem, not an infrastructure afterthought. They build (or buy) the tooling to manage registration, scopes, approvals, and audit logging in one place, connected to their API gateway and authorization server.

For teams evaluating how to manage SMART on FHIR scopes across their partner base, Apiable handles application registration, scope-based access control, approval workflows, and audit logging out of the box. Book a demo to see how it maps to your FHIR API program.