Select Medical Holdings OAuth Scopes

OAuth 2.0 probed

Select Medical Holdings publishes 5 OAuth 2.0 scopes. Scopes are the fine-grained permissions an application requests at authorization time to act against the Select Medical Holdings 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.

HealthcareHospitalsRehabilitationPatient AccessFHIRInteroperabilityElectronic Health RecordsFortune 1000

Scopes: 5 Flows: Method: probed

Scopes (5)

Scope	Description	Flows
openid	OpenID Connect authentication — returns an id_token identifying the end user.	authorizationCode
profile	Standard OpenID Connect profile claims for the authenticated user.	authorizationCode
fhirUser	SMART scope returning a reference to the FHIR resource (Practitioner, Patient or RelatedPerson) representing the authorized user.	authorizationCode
launch	SMART EHR-launch context scope — lets an app launched from inside Epic inherit the current patient and encounter context.	authorizationCode
epic.scanning.dmsusername	Epic-proprietary scope carrying the document-management-system scanning username. Vendor-specific, not part of the SMART specification.	authorizationCode

📄 Provider scope reference: https://fhir.epic.com/Documentation?docId=oauth2

Source

OAuth Scopes

generated: '2026-08-28'
method: probed
source: https://epicproxy.et0948.epichosted.com/FhirProxy/api/FHIR/R4/.well-known/smart-configuration
docs: https://fhir.epic.com/Documentation?docId=oauth2
note: >-
  scopes_supported is read verbatim from the server's own SMART discovery document (HTTP 200,
  fetched 2026-08-28). IMPORTANT: this list is the set of NON-FHIR scopes the endpoint advertises.
  SMART resource scopes (patient/*.read, user/*.read and the v2 patient/Observation.rs form) are NOT
  enumerated in scopes_supported — Epic grants them per registered application — but the server does
  declare permission-patient, permission-user, permission-v1 and permission-v2 among its SMART
  capabilities, which is the machine-readable statement that those scope families are supported.
  They are recorded below as `enumerated: false` so nothing here asserts a scope string the provider
  did not publish.
schemes:
  - name: smartOnFhir
    authorizationUrl: https://epicproxy.et0948.epichosted.com/FhirProxy/oauth2/authorize
    tokenUrl: https://epicproxy.et0948.epichosted.com/FhirProxy/oauth2/token
    standard: SMART App Launch
scopes:
  - scope: openid
    description: OpenID Connect authentication — returns an id_token identifying the end user.
    enumerated: true
    flows: [authorizationCode]
  - scope: profile
    description: Standard OpenID Connect profile claims for the authenticated user.
    enumerated: true
    flows: [authorizationCode]
  - scope: fhirUser
    description: >-
      SMART scope returning a reference to the FHIR resource (Practitioner, Patient or RelatedPerson)
      representing the authorized user.
    enumerated: true
    flows: [authorizationCode]
  - scope: launch
    description: >-
      SMART EHR-launch context scope — lets an app launched from inside Epic inherit the current
      patient and encounter context.
    enumerated: true
    flows: [authorizationCode]
  - scope: epic.scanning.dmsusername
    description: >-
      Epic-proprietary scope carrying the document-management-system scanning username. Vendor-specific,
      not part of the SMART specification.
    enumerated: true
    vendor_specific: true
    flows: [authorizationCode]
scope_families_declared:
  - family: patient/*
    enumerated: false
    evidence: SMART capability "permission-patient" declared in smart-configuration
    note: Patient-context resource scopes, granted per registered app rather than advertised.
  - family: user/*
    enumerated: false
    evidence: SMART capability "permission-user" declared in smart-configuration
    note: User-context resource scopes, granted per registered app.
  - family: SMART v1 scope syntax
    enumerated: false
    evidence: SMART capability "permission-v1" declared in smart-configuration
  - family: SMART v2 scope syntax
    enumerated: false
    evidence: SMART capability "permission-v2" declared in smart-configuration
    note: v2 granular scopes (e.g. patient/Observation.rs) are supported.
  - family: offline_access
    enumerated: false
    evidence: SMART capability "permission-offline" declared; refresh_token grant type supported
x-evidence:
  - url: https://epicproxy.et0948.epichosted.com/FhirProxy/api/FHIR/R4/.well-known/smart-configuration
    http_status: 200
    fetched: '2026-08-28'

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/select-medical-holdings-scopes"

All oauth scopes

curl "https://apis.io/api/v1/scopes?limit=25"

Discovery needs no key. Ratings and market analysis are Pro.

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.

GitHub Google LinkedIn

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