Background: SMART on FHIR’s authorization scheme uses OAuth scopes to communicate (and negotiate) access requirements.  For a review of Smart scopes see: App Launch Scopes and Launch Context in the SMART App Launch Guide. An example of a resource level scope supplied during authorization :    patient/AllergyIntolerance.rs The client was granted just patient-level read access to allergies. An example of a category-level scope supplied during authorization :  patient/Observation.rs?category=laboratory . to request read and search access to laboratory observations but not other observations, the scope    This tracker specifically addresses the following section in SMART guide that was removed (see referenced tracker below): Requirements for support While the search parameter based syntax here is quite general, and could be used for any search parameter defined in FHIR, we’re seeking community consensus on a small common core of search parameters for broad support. Initially, servers supporting SMART v2 scopes SHALL support: category=  constraints for any supported resource types where  category  is a defined search parameter. This includes support for category-based Observation access on any server that supports Observation access.   Proposal: Add guidance to the US Core Futures page and the quickstart sections describing a starter set of relevant example scopes in this release. see the rough draft of the guidances here limited to resources and categories These additions would be guidance - recommendations and no mandates via conformance language or capability statements.  Will be Silent on any ramifications for certification for this version.   Rationale: These scopes will be useful for implementers to drive consistent behavior.  US core could begin introducing formal conformance requirements in future versions to align with regulatory requirements. However, mandating any behavior would be a controversial expansion of functionality post-ballot.