SMART on FHIR
Fire Arrow and SMART on FHIR
Fire Arrow does not implement the SMART on FHIR app launch profile. Authentication is OAuth 2.0 / OpenID Connect (the same foundation SMART builds on), and authorization is expressed through Fire Arrow's own rule and filter model rather than SMART scopes. Apps that launch from an EHR via SMART can still use Fire Arrow as their backend: the SMART launch hands the app its EHR token, and the app uses a separate OAuth/OIDC flow to authenticate against Fire Arrow.
What you can build
- OAuth 2.0 / OpenID Connect authentication
Fire Arrow accepts standard bearer tokens from any compliant OAuth/OIDC provider. Microsoft Entra ID is supported on both editions. The token is mapped to a FHIR identity (Patient, Practitioner, RelatedPerson, or Device) and every request runs against the configured rule chain.
- Authorization that goes beyond SMART scopes
Rule-based, deny-by-default, identity-aware. Compartments, organisation-scoped legitimate-interest rules, care-team membership rules, identity-conditional FHIRPath rules, field-level redaction, and search-parameter blocklists. The SMART specification explicitly defers this layer to the FHIR server.
- What is not supported
The SMART app launch profile (EHR launch, standalone launch, the launch parameter exchange, the SMART context delivery format, and SMART scope strings) is not implemented in Fire Arrow.
Who this is for
App developers, integration architects, and security reviewers comparing Fire Arrow's authentication and authorization model to SMART on FHIR, and teams planning an integration where a SMART-launched app needs to read or write data in Fire Arrow.
What SMART on FHIR is
SMART on FHIR is a profile of OAuth 2.0 that standardises how apps obtain authorised access to a FHIR server. It defines an app launch flow (the EHR hands the app a launch parameter, the app exchanges it for an access token, and the EHR delivers patient and user context with the token), a scope syntax (for example, a scope meaning 'this user can read and search Observations'), and a backend-services flow for unattended workflows. The major US EHRs (Epic, Cerner / Oracle Health, MEDITECH, Allscripts / Veradigm) implement it, and US regulation (ONC HTI-1) requires it.
What SMART defines stops at scope strings and launch flows. The SMART specification is explicit: 'Neither SMART on FHIR nor the FHIR Core specification provide a way to model the underlying permissions at play here; this is a lower-level responsibility in the access control stack.' Compartments, organisational hierarchy, care-team membership, field-level redaction, and search side-channel protection all live in the FHIR server, not in SMART.
What Fire Arrow implements
Authentication is OAuth 2.0 / OpenID Connect against any compliant provider. Tokens are validated against the provider's signing keys, mapped to a FHIR identity resource, and that identity is the subject every authorization rule reasons about. The same token format that an OIDC provider issues to a SMART app or to a non-SMART app or to a backend service: Fire Arrow accepts all of them and treats them the same way.
Authorization is the rule-and-filter model. Each rule pairs a role, a resource type, and an operation with an authorization strategy: outright allow or deny, FHIR compartments, an organisation-scoped legitimate-interest rule, a care-team membership rule, or an identity-conditional FHIRPath rule. Search is narrowed at the database layer, not after the fact. The same rule decides REST, GraphQL, and SQL-on-FHIR access. Field-level redaction is paired with search-parameter and reference-traversal blocklists for the same role.
What Fire Arrow does not implement: the SMART app launch profile. There is no SMART launch endpoint on Fire Arrow, no exchange of a SMART launch parameter for an access token, no SMART context delivery, and no parsing of SMART scope strings. Apps cannot launch into Fire Arrow from a SMART-on-FHIR container as if Fire Arrow were the EHR.
Pattern: a SMART app that uses Fire Arrow as its backend
When a SMART app needs to read from or write to Fire Arrow alongside the EHR, the integration uses two separate authentication contexts. The SMART launch happens at the EHR (Epic, Oracle Health, others) and gives the app an EHR-scoped token to talk to the EHR's FHIR endpoint with the user's SMART scopes. To talk to Fire Arrow, the app authenticates the user against Fire Arrow's OAuth/OIDC provider (typically the customer's Entra ID tenant) and uses the resulting token on every Fire Arrow call.
On the Fire Arrow side, the user resolves to a FHIR identity, and the rule chain decides what they can read or write. The identity-attributable audit log records each call against the resolved identity. The two access boundaries (EHR side and Fire Arrow side) stay independent, which is also the boundary auditors want: each FHIR server logs the access it served.
Why authorization sits outside the SMART layer
SMART scopes are expressive enough for the most common patient-app and clinician-app patterns: 'this app may read and search Observations on the launch patient', 'this app may read and write MedicationRequests on any patient the user is authorised for'. They are not designed for the patterns digital health products run into in production: a multi-tenant care network where a practitioner sees only the patients in their organisation plus a CareTeam exception for one cross-organisation patient, an investigator-vs-sponsor view of a clinical trial where the same Observation is visible with different fields redacted, or an AI agent that acts on a clinician's behalf and must be audited as that clinician.
Fire Arrow's rule model handles these patterns directly, in a form that can be diffed, reviewed, and tested per identity without enabling debug behaviour for live traffic. For the SMART-shaped patterns, the same rules work; the difference is that the scope-to-rule mapping happens in Fire Arrow's configuration, not in the SMART scope string itself.
Related docs
FAQ
Can an app launched from Epic or Oracle Health write into Fire Arrow?
Yes, with two separate authentication contexts. The SMART launch happens in the EHR and gives the app a token for the EHR's FHIR endpoint. To write into Fire Arrow, the same app authenticates the user against Fire Arrow's configured OAuth/OIDC provider (typically the customer's Entra ID tenant) and uses the resulting token on the Fire Arrow side. Fire Arrow's rule chain then decides what the user is permitted to write.
Will Fire Arrow add SMART app launch support later?
It is not on the current roadmap. Most workflows that ask for it are served well by the OAuth/OIDC + rule pattern described on this page. If your use case has a hard SMART launch requirement (for example, an app that must be listed in a SMART app gallery and have Fire Arrow as the backing FHIR server), let us know; that signal feeds into the roadmap.
Does Fire Arrow accept SMART scope strings?
No. The token Fire Arrow accepts is a standard OAuth 2.0 / OIDC bearer token. Authorization decisions come from Fire Arrow's rule chain, which evaluates the resolved FHIR identity against the configured rules. SMART scope strings on a token are ignored by Fire Arrow.
How does this affect ONC HTI-1 certification?
ONC HTI-1 applies to certified EHR systems that hold patient records on behalf of US covered entities. Fire Arrow is a backend component that digital health products build on, not a certified EHR, so HTI-1 certification scope sits with the product the customer ships rather than with Fire Arrow itself. Customers building products that need to interoperate with HTI-1-certified EHRs typically do so through the EHR's SMART surface as described above.
Can a backend-services-style headless integration use Fire Arrow?
Yes, through standard OAuth 2.0 / OIDC client credentials, Microsoft Entra ID service principals, or rotating API tokens issued through the admin surface. The service identity is bound by the same rule chain as a user identity. The authentication shape is OAuth/OIDC; it is not the SMART backend services profile specifically.
