SMART App Launch 2.2 makes authorization part of the API

Transport availability is not authorized use

HL7 lists SMART App Launch 2.2.0 as the current published version of its FHIR R4-based authorization guide. The guide defines patterns for applications to discover server capabilities, request authorization, receive tokens, and access FHIR resources within granted scope. That layer is part of interoperability, not an optional wrapper around it. An endpoint can be reachable and return syntactically valid FHIR while still failing the buyer's access, context, identity, or governance requirements.

Product comparisons should therefore separate FHIR support from SMART authorization support and state the tested guide version. A provider may document both, but buyers still need to observe the interaction between the application, authorization server, resource server, identity system, and user context. A successful token request in a vendor demonstration does not establish that the configured access is appropriate, least-privileged, or reliable in the buyer's environment.

Discovery makes capability claims inspectable

SMART defines discovery metadata so an application can learn relevant endpoints and supported capabilities. That gives teams a machine-readable starting point, but the metadata itself must be governed. An advertised capability can be incomplete, stale, or broader than what a particular tenant and user can actually exercise. Buyers should compare the published configuration with the observed authorization behavior and the organization's approved integration record.

A representative test should change one material capability or endpoint. The team can observe how clients detect the change, whether cached metadata is invalidated, how failures are reported, and which owner approves the new configuration. Versioned discovery evidence helps distinguish a client defect from a server change or authorization-policy decision. Without it, an integration incident can be reduced to a generic 'FHIR error' that hides the accountable boundary.

Scopes express limits, not entitlement by themselves

SMART scopes let an application request categories of access and context, including patient-, user-, or system-level patterns. A requested scope is not automatically granted, and a granted scope does not resolve every downstream policy question. Resource-level access can still depend on the authenticated party, organizational relationship, patient context, consent, purpose, data segmentation, and server policy. Buyers should reject language that treats a scope string as complete authorization evidence.

The system should preserve the requested scope, granted scope, token audience, client identity, user and patient context when applicable, decision source, and relevant timestamps without exposing secrets. Test cases should include a narrower grant, an expired token, an incorrect audience, revoked access, and a request outside the available patient context. The application's error handling should not encourage a broader request merely to make the workflow succeed.

Runtime evidence completes conformance claims

Implementation-guide support is a versioned, testable claim. It is not proof of every production configuration, identity flow, data permission, or operating outcome. Buyers should request current conformance artifacts, supported launch patterns, deployment constraints, test results, known exceptions, and change-management practices. They should then run scenarios using representative identities and data boundaries in an environment that reflects intended use.

Health Interoperability Review verified the current published guide on July 23, 2026; this article does not imply a new July release. The purchasing signal is the continuing need to evaluate authorization as part of usable interoperability. Strong evidence connects declared SMART capabilities to observed discovery, scope decisions, token behavior, FHIR access, audit records, and incident response while preserving the distinction between technical conformance and buyer-specific governance.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.