This page describes support for SMART on FHIR Security within Smile CDR. Note that this page uses terms described on the SMART on FHIR: Introduction page. If you haven't read that already, you should start there.
There are several modules that can be used in different ways in order to create a complete SMART on FHIR compliant architecture.
The following table lists the scopes that are supported by Smile CDR.
| Scope | Description | |
|---|---|---|
| User Identity | openid profile |
This pair of scopes permits the client to request details about the logged in user.
They enable the OpenID Connect id_token claim.
|
| Refresh Tokens | online_access |
This scope permits that the client be issued a Refresh Token upon authentication, and permits the user to exchange the Refresh Token for an Access Token. This scope has no effect for clients that do not support the refresh_token grant type. |
offline_access |
This scope permits that the client be issued a Refresh Token upon authentication, and permits the user to exchange the Refresh Token for an Access Token. This scope has no effect for clients that do not support the refresh_token grant type. |
|
|
SMART on FHIR Launch See Launch Context Scopes for a description of what these scopes do. |
launch/patient |
Standalone Patient Launch Context: Request that the server provide a contextual Patient resource identifier as a part of the claims returned to the client during the authorization flow. If this scope is requested and approved by the user, the Patient launch context will be taken from the [UserSessionDetails.launchResourceIds](/docs/javascript_execution_environment/callback_models.html#usersessiondetails) array if any entries exist with a type of `patient`. If none are found, [UserSessionDetails.defaultLaunchContexts](/docs/javascript_execution_environment/callback_models.html#usersessiondetails) will also be searched for any entries with a type of `patient`. |
launch/encounter |
Standalone Encounter Launch Context: Request that the server provide a contextual Encounter resource identifier as a part of the claims returned to the client during the authorization flow. If this scope is requested and approved by the user, the Patient launch context will be taken from the [UserSessionDetails.launchResourceIds](/docs/javascript_execution_environment/callback_models.html#usersessiondetails) array if any entries exist with a type of `encounter`. If none are found, [UserSessionDetails.defaultLaunchContexts](/docs/javascript_execution_environment/callback_models.html#usersessiondetails) will also be searched for any entries with a type of `encounter`. | |
launch/location |
Standalone Location Launch Context: Request that the server provide a contextual Location resource identifier as a part of the claims returned to the client during the authorization flow. If this scope is requested and approved by the user, the Patient launch context will be taken from the [UserSessionDetails.launchResourceIds](/docs/javascript_execution_environment/callback_models.html#usersessiondetails) array if any entries exist with a type of `location`. If none are found, [UserSessionDetails.defaultLaunchContexts](/docs/javascript_execution_environment/callback_models.html#usersessiondetails) will also be searched for any entries with a type of `location`. | |
launch |
EHR Launch Context: Request that the server provide any relevant launch context information available. If this scope is requested and approved by the user, the Patient launch context will be taken from the [UserSessionDetails.launchResourceIds](/docs/javascript_execution_environment/callback_models.html#usersessiondetails) array if any entries exist with a type of `location`. If none are found, [UserSessionDetails.defaultLaunchContexts](/docs/javascript_execution_environment/callback_models.html#usersessiondetails) will also be searched for any entries with a type of `location`. | |
|
SMART on FHIR Data Access This section lists the SMART on FHIR scopes natively supported by Smile CDR. See Scope Permission Model for a description of how these scopes are actually applied to a user session. |
patient/*.read |
This scope permits the client to read (read/search/history) all data for all patients on the server. In other words, all data in any Patient compartment. |
patient/*.write |
This scope permits the client to write (create/update) all data for all patients on the server. In other words, all data in any Patient compartment. | |
patient/[ResourceType].read |
This scope permits the client to read (read/search/history) all data for the given resource type for all patients on the server. Note that [ResourceType] must be a valid FHIR Resource type (e.g. Observation).Clients that have been configured to support wildcard scopes (e.g. Patient/*.read) are also permitted to request this scope without needing to have it declared explicitly in the client definition.
|
|
patient/[ResourceType].write |
This scope permits the client to write (create/update) all data for the given resource type for all patients on the server. Note that [ResourceType] must be a valid FHIR Resource type (e.g. Observation).Clients that have been configured to support wildcard scopes (e.g. Patient/*.read) are also permitted to request this scope without needing to have it declared explicitly in the client definition.
|
|
|
Smile CDR FHIR Extensions The SMART on FHIR scope specification covers basic clinical read/write scenarios well, but leaves a number of other part of the FHIR specification without any relevant scopes for authorizing use. This section describes Smile CDR specific scopes that can be used to add additional FHIR capabilities to applications. |
cdr_fhir_delete |
This scope permits the user to perform FHIR delete operations.
Associated permissions: |
cdr_fhir_expunge |
This scope permits the user to perform FHIR expunge operations.
Associated permissions: |
|
cdr_fhir_validate |
This scope permits the user to perform FHIR $validate operations.
Associated permissions: |
|
| Misc. Permissions | cdr_all_user_authorities |
This is a special scope that grants the session all permissions that are granted to the authorizing user. Note that this scope supercedes all other data access scopes. This is useful if you wish to have clients/applications authorizing using SMART on FHIR that need to access administrative functions of Smile CDR. |
Note that at present the online_access and offline_access scopes have identical functionality; this is because a standalone CDR and an EHR do not share the same concept of a user session. In future, functionality may be added that allows a more complete online_access session concept.