Fast Healthcare Interoperability Resources OAuth Scopes

OAuth 2.0 searched

Fast Healthcare Interoperability Resources publishes 9 OAuth 2.0 scopes. Scopes are the fine-grained permissions an application requests at authorization time to act against the Fast Healthcare Interoperability Resources API on a user’s behalf.

This index is generated from the provider’s OpenAPI security definitions (and, where available, its documented scope reference) and refreshes on every APIs.io network build. Browse every provider’s scopes at scopes.apis.io.

HealthcareStandardsInteroperabilityFHIRHL7Clinical DataHealth ITOpen StandardSMART on FHIRClinicalCDADICOMICDLOINCSNOMED CTUS Core
Scopes: 9 Flows: Method: searched

Scopes (9)

ScopeDescriptionFlows
patient/*.rs Permission to read and search any resource for the current patient (see notes on wildcard scopes below).
user/*.cruds Permission to read and write all resources that the current user can access (see notes on wildcard scopes below).
system/*.cruds Used with SMART Backend Services: "these scopes convey full access relative to a server's pre-configured client-specific policy."
openid Permission to retrieve information about the current logged-in user (with fhirUser).
fhirUser Permission to retrieve information about the current logged-in user.
launch Permission to obtain launch context when app is launched from an EHR.
launch/patient When launching outside the EHR, ask for a patient to be selected at launch time.
offline_access Request a refresh_token that can be used to obtain a new access token to replace an expired one, even after the end-user no longer is online after the access token expires.
online_access Request a refresh_token that can be used to obtain a new access token to replace an expired one, and that will be usable for as long as the end-user remains online.

Source

OAuth Scopes

Raw ↑
generated: '2026-11-05'
method: searched
source: https://hl7.org/fhir/smart-app-launch/scopes-and-launch-context.html
docs: https://hl7.org/fhir/smart-app-launch/scopes-and-launch-context.html
description: SMART App Launch scopes (v2.2.0, STU 2.2). Resource scopes take the form <context>/<ResourceType>.<permissions>
  where context is patient, user or system and permissions is a subset of c (create), r (read), u (update), d (delete),
  s (search); * is the resource-type wildcard. Scopes delegate access and "are always limited by underlying system
  policies and permissions". The FHIR core specification itself defines no scopes; these come from the HL7 SMART
  App Launch Implementation Guide.
schemes:
- name: SMART App Launch
  type: oauth2
  grant_types:
  - authorization_code
  docs: https://hl7.org/fhir/smart-app-launch/app-launch.html
  notes: authorizationUrl and tokenUrl are per server, discovered from .well-known/smart-configuration relative
    to the FHIR base URL; PKCE S256 required.
- name: SMART Backend Services
  type: oauth2
  grant_types:
  - client_credentials
  docs: https://hl7.org/fhir/smart-app-launch/backend-services.html
  notes: client_assertion_type urn:ietf:params:oauth:client-assertion-type:jwt-bearer with a signed JWT; system/
    scopes only.
scopes:
- scope: patient/*.rs
  description: Permission to read and search any resource for the current patient (see notes on wildcard scopes
    below).
- scope: user/*.cruds
  description: Permission to read and write all resources that the current user can access (see notes on wildcard
    scopes below).
- scope: system/*.cruds
  description: 'Used with SMART Backend Services: "these scopes convey full access relative to a server''s pre-configured
    client-specific policy."'
- scope: openid
  description: Permission to retrieve information about the current logged-in user (with fhirUser).
- scope: fhirUser
  description: Permission to retrieve information about the current logged-in user.
- scope: launch
  description: Permission to obtain launch context when app is launched from an EHR.
- scope: launch/patient
  description: When launching outside the EHR, ask for a patient to be selected at launch time.
- scope: offline_access
  description: Request a refresh_token that can be used to obtain a new access token to replace an expired one,
    even after the end-user no longer is online after the access token expires.
- scope: online_access
  description: Request a refresh_token that can be used to obtain a new access token to replace an expired one,
    and that will be usable for as long as the end-user remains online.

Work with this as data

Every scope set here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for oauth scopes

4 MCP tools reach this
  • find_scopesBrowse and filter every scope set in the catalog.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools →

Call it yourself

curl for this page
This scope set
curl "https://apis.io/api/v1/scopes/fhir-scopes"
All oauth scopes
curl "https://apis.io/api/v1/scopes?limit=25"

Calls without X-API-Key need no key. Calls with it need a paid plan — get a key.

Get an API key

Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.

A second provider on the same verified email joins the account you already have.