Overview
OAuth scopes are the mechanism SMART on FHIR uses to specify what specific FHIR data a third-party application can access. Scopes combine a context prefix (patient/ for patient-specific access, user/ for access as the logged-in user, system/ for backend-service access) with a resource type (Observation, MedicationRequest, Patient, etc.) and permission (read, write, rs for read+search). The scope patient/Observation.read grants the app read access to the patient's Observation resources and nothing else.
Fine-grained scope-based authorization is a key security feature. Rather than granting apps unrestricted access to all patient data, SMART flows let the authorizing user (or patient) see the specific scopes the app is requesting and approve only what is appropriate. A medication-reminder app might legitimately request patient/MedicationRequest.read — a narrow, purpose-appropriate scope. A fitness app requesting patient/* (all patient data) would be more concerning and should be denied by informed users.
Standardized scopes evolved substantially in SMART App Launch v2, published 2022. The prior v1 scope format (patient/Observation.read) remains supported; v2 adds wildcards (patient/*.read), resource-level constraints, and specific operation-level permissions (Observation.rs for read+search, Observation.cu for create+update). The evolution reflects maturation of the standard as real-world use cases surfaced scope-granularity limits.
For apps, scope strategy involves requesting the minimum necessary for functionality — both to improve user trust during the authorization decision and to reduce the app's attack surface if compromised. Apps that request too broad scopes face user-experience friction at authorization time and regulatory attention.
For EHRs and FHIR servers, scope enforcement is a core security responsibility. The authorization server validates requested scopes against user permissions, records the granted scopes in issued access tokens, and enforces scope restrictions on every resource access. Violations — an app attempting to read Observations when it only has MedicationRequest scopes — must be rejected by the server.
SMART Backend Services uses system-level scopes (system/Observation.read) without patient or user context. These are used for server-to-server integrations like bulk-data export where no individual patient's consent is being requested at the time of access. Governance of system-scope access is typically contractual and out-of-band rather than through patient-level authorization.
From a board-reporting standpoint, OAuth Scopes (SMART on FHIR) belongs in the compliance committee's quarterly dashboard. The reporting line should include volume, exception rate, and any open remediation action; reviewers tie OAuth Scopes (SMART on FHIR) metrics to the broader compliance program KPIs so an emerging OAuth Scopes (SMART on FHIR) risk surfaces before it becomes a formal finding. Pairing the OAuth Scopes (SMART on FHIR) trend with smart on fhir gives the committee a single view of whether the control environment is strengthening or drifting.
Industry benchmark
SMART App Launch v2 scopes (2022): v1 legacy plus wildcards and operation-level granularity. All major certified EHRs support SMART scope-based authorization.
Worked example
A blood-pressure tracking app requests patient/Observation.rs and patient/Patient.read scopes at authorization. The patient sees a clear statement: "This app is requesting read and search access to your observations (vitals, labs) and your patient record." The patient approves; the app receives an access token valid only for those scopes.
Frequently asked questions — OAuth Scopes (SMART on FHIR)
What's the difference between patient/ and user/ scopes?
patient/ scopes grant access to a specific patient's data (typically from standalone patient-app launch). user/ scopes grant access as the logged-in user (typically from EHR launch where a clinician is the user, and their normal access scope applies).
Can apps request all resources?
Wildcard scopes (patient/*.read) are supported in SMART v2 but users and EHR policies often restrict them. Broad-scope requests trigger greater user scrutiny and may be denied by EHRs.
How do scopes interact with HIPAA?
Scopes define the technical access boundary; HIPAA and state law define legal permissions around data sharing. Apps must comply with both — technically-enforced scopes do not substitute for legal compliance.
Disclaimer
This glossary entry is operational reference for revenue-cycle and medical-billing professionals. It is not legal, clinical, or contractual advice. Industry benchmarks cite named public sources where available; always verify against the current guidance from the authority body before relying on a number in a contract, policy, or compliance filing.