FHIR is the interoperability standard that defines how healthcare data is structured and exchanged through APIs. SMART adds the authorization and app launch profile that makes those APIs usable in a controlled, patient-consented way. In practice, FHIR provides the data access framework, while SMART defines how applications authenticate, request consent, and receive the right token context.
How FHIR and SMART split the problem
FHIR and SMART address different layers of healthcare access control, and that distinction matters when you are designing or reviewing an app integration. FHIR is the data and API interoperability layer, while SMART is the profile that governs how an application gets authorised to use that FHIR data in a controlled way. In practice, FHIR says what can be exchanged, SMART helps decide who or what can exchange it, and under what consent and token conditions.
That means FHIR alone does not solve application access control. A FHIR endpoint may expose a patient resource, but without a SMART profile the service lacks the standardised launch, OAuth, and consent context that most healthcare app ecosystems expect. SMART is therefore not a replacement for FHIR, it is the access layer that makes FHIR usable in a governed application model.
The cleanest way to think about it is: FHIR defines the healthcare data surface, and SMART constrains the application’s entry to that surface. For practitioners, the difference is between interoperability of records and controlled delegation of access. The more sensitive the workflow, the more important it is to separate API reachability from authorisation scope.
- FHIR is the interoperable resource model and API contract.
- SMART adds launch context, OAuth-based authorisation, and app-level consent handling.
- Access control decisions are enforced through the SMART-mediated token and scope model, not by FHIR structure alone.
Where access control actually changes
In healthcare, the practical control point is usually not whether an app can call an API at all, but what it can see once it is inside. FHIR resources are granular, which is useful for interoperability but risky if the API is treated as a generic data pipe. SMART narrows that risk by tying access to the app, the user context, and the consent granted for a specific launch or workflow.
This is why SMART matters most in app-based clinical access, patient-facing portals, and delegated third-party integrations. It introduces a predictable authorisation pattern for scenarios where the same FHIR server may need to support multiple apps with different roles, scopes, and patient permissions. For an organisation, that reduces ambiguity around whether an application is merely connected or genuinely authorised for the requested data and action.
FHIR by itself can still be used in secure architectures, but the security outcome depends on separate controls you apply around it. SMART standardises the access pattern so that authentication, consent, and token context are not improvised differently for every vendor integration. That consistency is often the real operational benefit.
For implementers, a useful test is whether the app can be launched and trusted in the intended clinical context without overexposing resources. If not, you likely have a FHIR integration, but not a properly governed SMART one.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | FHIR and SMART both hinge on controlled application access to sensitive health data. |
| Recommendation — Apply PR.AC controls to restrict app access to only the FHIR resources and scopes needed. | ||
| CIS Controls v8 | 6 — Access Control Management | SMART scopes and app permissions map directly to managing who can access healthcare APIs. |
| Recommendation — Use Control 6 to define, review, and revoke application access to FHIR endpoints. | ||
| NIST SP 800-63 | 3 — Federation and Assertions | SMART relies on federated authorization flows and token-based assertions for app access. |
| Recommendation — Use federated assertions to bind app access to the correct user and launch context. | ||
| NIST Zero Trust (SP 800-207) | 4 — Policy Engine, Policy Administrator, and Policy Enforcement Point | SMART-mediated access decisions are enforced at runtime through token and scope policy. |
| Recommendation — Enforce runtime policy decisions so apps only receive the FHIR access they are authorised to use. | ||
| OWASP Agentic AI Top 10 | A1 — Agent Goal Misalignment / Authorization Drift | Healthcare apps can overreach if delegated access exceeds the intended workflow or consent. |
| Recommendation — Constrain delegated app actions so authorization stays aligned with the intended clinical workflow. | ||
Practitioner Guidance
What to verify: Confirm whether the integration is using SMART on FHIR, or only plain FHIR APIs with custom authentication bolted on. If consent, scopes, launch context, and token claims are not explicitly defined, the access model is probably weaker than the interface suggests.
Common mistake: Treating interoperability as if it were authorisation. A system can exchange FHIR data cleanly and still grant overly broad access if the SMART layer, scopes, or app registration rules are weak.
What good looks like: Each application has a clearly bounded launch path, minimal scopes, and traceable token context tied to the intended patient or user workflow. Access should be understandable from the token and consent posture, not inferred from the API URL alone.
Practitioner takeaway: Use FHIR to model the data exchange and SMART to govern the application’s right to participate in that exchange, because that separation is what prevents a usable integration from becoming an uncontrolled one.
Related resources from NHI Mgmt Group
- What is the difference between MFA and least privilege in healthcare access control?
- What is the difference between contact and contactless smart cards for access control?
- What is the difference between privileged access management and basic access control in healthcare?
- What is the difference between secrets rotation and access control for non-human identities?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
