Note that the scope syntax has changed since SMARTv1. User-facing apps can also receive “launch context” to indicate details about the current patient or other aspects of a user’s EHR session or a user’s selections when launching the app. Similarly, a backend service might be granted scopes like system/Encounter.rs, allowing it to read and search for Encounters within the overall set of data it is configured to access. For example, an app might be granted scopes like user/Encounter.rs, allowing it to read and search for Encounters that are accessible to the user who has authorized the app. These scopes draw on FHIR API definitions for interactions, resource types, and search parameters to describe a permissions model. SMART uses a language of “scopes” to define specific access permissions that can be delegated to a client application. Symmetric (“client secret”) authenticationĪuthenticate a client using a secret that has been pre-shared between the client and server Scopes for Limiting Access This is SMART’s preferred authentication method because it avoids sending a shared secret over the wire. Asymmetric (“private key JWT”) authenticationĪuthenticates a client using an asymmetric keypair. Note that client authentication is not required in all authorization scenarios, and not all SMART clients are capable of authenticating (see discussion of “Public Clients” in the SMART App Launch overview). When clients need to authenticate, this implementation guide defines two methods. SMART Defines Two Patterns For Client Authentication This pattern allows for backend services to connect and interact with an EHR when there is no user directly involved in the launch process, or in other circumstances where permissions are assigned to the client out-of-band. Authorization via SMART Backend ServicesĪuthorizes a headless or automated client application (“Backend Service”) to connect to a FHIR Server. Authorization allows for delegation of a user’s permissions to the app itself.

This pattern allows for “launch context” such as currently selected patient to be shared with the app, based on a user’s session inside an EHR or other health data software, or based on a user’s selection at launch time. SMART Defines Two Patterns For Client Authorization Authorization via SMART App LaunchĪuthorizes a user-facing client application (“App”) to connect to a FHIR Server. This information helps client direct authorization requests to the right endpoint, and helps clients construct an authorization request that the server can support. well-known/smart-configuration relative to a FHIR Server Base URL, allowing clients to learn the authorization endpoint URLs and features a server supports. SMART defines a discovery document available at. Discovery of Server Capabilities and Configuration The patterns defined in this specification are introduced in the sections below. This implementation guide describes a set of foundational patterns based on OAuth 2.0 for client applications to authorize, authenticate, and integrate with FHIR-based data systems. SMART Defines Two Patterns For Client Authentication.SMART Defines Two Patterns For Client Authorization.Discovery of Server Capabilities and Configuration.

Smartapp gethub