On this page:

7.7Roles and Permissions

 

The Smile CDR permission model has several key concepts:

  • System-Defined Permissions are an authorization for individual action to be performed by a user. There are two types of permissions:
    • Some permissions do not require an argument but simply grant a specific permission. For example, the FHIR_TRANSACTION permission grants the user authorization to perform FHIR transaction operations.
    • Some permissions do require an argument in order to be used. For example, the FHIR_READ_INSTANCE permission grants the user authorization to perform FHIR read operations on a specific instance, which is specified in an argument to the permission (such as Patient/1234).

Note that in many cases a combination of permissions are required in order to allow the user to perform specific functions. Some examples follow:

  • The FHIR_TRANSACTION permission allows the user to perform FHIR transaction operations but does not explicitly authorize any of the operations that can be performed within a transaction. If the user wishes to perform a transaction containing a Patient create operation, the user would need both the FHIR_TRANSACTION permission and a permission that explicitly authorizes the create, such as FHIR_WRITE_ALL_OF_TYPE with an argument of Patient.

  • The ROLE_FHIR_CLIENT permission allows the user to access the FHIR endpoint as a normal client (this is generally desirable) but does not grant the user permission to actually perform any FHIR operations. For example, if the user should be allowed to read anything (i.e. invoke FHIR search, read, history, etc.) but never write, grant the user the ROLE_FHIR_CLIENT and FHIR_ALL_READ permissions. If the user should also be allowed to write Observations (but no other types of resources), they should be granted the FHIR_WRITE_ALL_OF_TYPE permission with an argument of Observation.

  • System-Defined Roles are a grouping of permissions mapping to a logical role.

  • User-Defined Roles are a set of permissions and roles which are tailored to the needs of a specific implementation. (Note that these are not yet available but will be implemented in an upcoming release.)

7.7.1System-Defined Roles

 

The following table lists the roles that are built into Smile CDR and may be assigned to a user.

Role Description
ROLE_ANONYMOUS Anonymous
This role must be granted to any user that will be used for anonymous access requests. See Anonymous Access for more information.
ROLE_FHIR_CLIENT FHIR Client
User has permission to access the FHIR services as a client.
ROLE_FHIR_CLIENT_SUPERUSER FHIR Client (Superuser)
User has permission to perform any standard FHIR client operation. This does not imply superuser status for other parts of the CDR (e.g. user management, FHIR search parameter modification, etc.).
ROLE_FHIR_CLIENT_SUPERUSER_RO FHIR Client (Read-Only Superuser)
User has permission to perform any standard FHIR client read/fetch operation. This permission allows the user to perform any read, search, history, etc. operation but does not allow the user to perform create, update, etc. This permission does not imply superuser status for other parts of the CDR (e.g. user management, FHIR search parameter modification, etc.).
ROLE_FHIR_TERMINOLOGY_READ_CLIENT
Implies:
FHIR Terminology Service Read-Only Client
User is permitted to invoke any terminology read-only operations. In other words, this role includes various capabilities relating to accessing data in the FHIR terminology services. This includes operations such as $lookup and $validate-code, as well as read and search capabilities on ValueSet, CodeSystem, and ConceptMap resources.
ROLE_SUPERUSER
Implies:
Superuser
User has all permissions to do anything. Use this permission with caution since it gives the user access to almost all administrative functions.

7.7.2System-Defined Permissions

 

The following table lists the permissions that are built into Smile CDR and may be assigned to a user.

Permission Description
ACCESS_ADMIN_JSON Access JSON Admin API Endpoint
User is allowed to invoke operations on the JSON Admin API endpoint. Note that this permission does not give the user the ability to actually perform any of the functions on the API so this permission is generally granted in combination with at least one other.
ACCESS_ADMIN_WEB Admin
User is allowed to log into the Web Admin Console.
ACCESS_FHIRWEB Access FHIRWeb Console
User is allowed to access the FHIRWeb Console, which can be used for testing, building FHIR queries, and exploring data in the database. Note that this permission only allows access to the FHIRWeb Console; the user still needs to have other appropriate permissions for any desired operations or they will be blocked.
ACCESS_FHIR_ENDPOINT FHIR Client
User is allowed to access FHIR services as a client.
ARCHIVE_MODULE Archive Modules
User is allowed to archive modules.
CHANGE_OWN_PASSWORD Change Password
User is allowed to change password.
CHANGE_OWN_TFA_KEY Can set own 2FA Key
User is allowed to set up their own 2FA key (as opposed to having one assigned by an administrator).
CONTROL_MODULE Control Module
User is allowed to start/stop/restart modules.
CREATE_CDA_TEMPLATE Create CDA templates
User is allowed to create (and update existing) CDA document template scripts. Use this permission with caution, as these scripts, when called upon, have the ability to create, view, and modify data without additional permissions.
CREATE_MODULE Create Modules
User is allowed to create new modules.
CREATE_USER Create Users
User is allowed to create other users.
DELETE_CDA_TEMPLATE Delete CDA templates
User is allowed to delete CDA document template scripts.
EMPI_ADMIN EMPI Admin
User may perform any administrative functions for the EMPI.
EMPI_UPDATE_MATCH_RULES EMPI Update Match Rules
User can set/update matching rules for the EMPI.
EMPI_VIEW_MATCH_RULES EMPI VIEW Match Rules
User can view matching rules for the EMPI.
ETL_IMPORT_PROCESS_FILE ETL Import / Process File
User is allowed to initiate the processing of an ETL import job. Use this permission with caution, as import jobs have a large amount of flexibility to create and modify data and do not require additional permissions.
FHIR_ALL_DELETE
Implies:
FHIR Delete (All)
User is allowed to perform any FHIR delete operation.
FHIR_ALL_READ FHIR Read (All)
User is allowed to perform any FHIR read/access-to-data operation (e.g. read, search, history, etc.).
FHIR_ALL_WRITE FHIR Write (All)
User is allowed to perform any FHIR write/modify operation (e.g. create, update, etc.).
FHIR_BATCH
Implies:
FHIR Batch
User is allowed to perform a FHIR Batch. Note that this permission only allows the batch operation to happen; the user still needs to have other appropriate permissions for the operations in the batch or it will be blocked.
FHIR_CAPABILITIES
Implies:
FHIR Access Server Capability Statement (metadata)
User is allowed to access the server's capability statement. This permission is often granted to anonymous users.
FHIR_DELETE_ALL_IN_COMPARTMENT
Implies:
FHIR Delete (All in Compartment)
User is permitted to delete any resource in the given compartment.
FHIR_DELETE_ALL_OF_TYPE
Implies:
FHIR Delete (All of Type)
User is allowed to delete any resource of the type specified in the argument (e.g. Patient).
FHIR_DELETE_CASCADE_ALLOWED
Implies:
FHIR Delete - Cascading Allowed
User is permitted to perform cascading deletes. See Cascading Deletes for more information.
FHIR_DELETE_TYPE_IN_COMPARTMENT
Implies:
FHIR Delete (Specific Type in Compartment)
User is permitted to delete any resource of the given type in the given compartment.
FHIR_EXPUNGE_DELETED
Implies:
FHIR Expunge ($expunge) Deleted Resources
User is permitted to invoke the $expunge operation to permanently delete logically deleted resources. This is a dangerous operation, as it causes data to be permanently deleted. Use caution when granting this permission. See [/docs/fhir_repository/deleting_data.html](deleting data) for information on this operation. Note that the ROLE_FHIR_CLIENT_SUPERUSER role does not grant this permission, it must be explicitly enabled.
FHIR_EXPUNGE_EVERYTHING
Implies:
FHIR Expunge ($expunge) All Data
User is permitted to invoke the $expunge operation to permanently delete ALL data on the server. This is a dangerous operation, as it causes data to be permanently deleted. Use caution when granting this permission. See [/docs/fhir_repository/deleting_data.html](deleting data) for information on this operation. Note that the ROLE_FHIR_CLIENT_SUPERUSER role does not grant this permission, it must be explicitly enabled.
FHIR_EXPUNGE_PREVIOUS_VERSIONS
Implies:
FHIR Expunge ($expunge) Previous Versions
User is permitted to invoke the $expunge operation. This is a dangerous operation, as it causes data to be permanently deleted. Use caution when granting this permission. See [/docs/fhir_repository/deleting_data.html](deleting data) for information on this operation. Note that the ROLE_FHIR_CLIENT_SUPERUSER role does not grant this permission, it must be explicitly enabled.
FHIR_EXTENDED_OPERATION_ON_ANY_INSTANCE_OF_TYPE
Implies:
Extended Operation (Instance Level / Unchecked Response)
User may invoke operation at the instance level with type and operation name specified by argument in the form: Patient/$fooOperation. When using this permission, the operation response is not validated/authorized in any way, so this authority should only be granted for operations that are known to be appropriate for the user.
FHIR_EXTENDED_OPERATION_ON_SERVER
Implies:
Extended Operation (Server Level / Unchecked Response)
User may invoke operation with name specified by argument (e.g. $fooOperation). When using this permission, the operation response is not validated/authorized in any way, so this authority should only be granted for operations that are known to be appropriate for the user.
FHIR_EXTENDED_OPERATION_ON_TYPE
Implies:
Extended Operation (Type Level / Unchecked Response)
User may invoke operation at the type level with type and name specified by argument in the form: Patient/$fooOperation. When using this permission, the operation response is not validated/authorized in any way, so this authority should only be granted for operations that are known to be appropriate for the user.
FHIR_GET_RESOURCE_COUNTS
Implies:
FHIR Get Server Resource Counts
User is permitted to call the $get-resource-count operation, requesting the total counts of resources on the server.
FHIR_GRAPHQL
Implies:
FHIR GraphQL Operation
User may invoke the GraphQL Operation. Note that user must still have additional permissions to see the resources being requested via GraphQL.
FHIR_LIVEBUNDLE
Implies:
FHIR LiveBundle Operations
User is allowed to invoke the $livebundle-watchlist-add, $livebundle-watchlist-delete, $livebundle-watchlist, and $livebundle operations
FHIR_MANUAL_VALIDATION
Implies:
FHIR Manual Validation
User is allowed to invoke the $validate operation to validate resources.
FHIR_META_OPERATIONS_SUPERUSER
Implies:
Resource Metadata Operations: Superuser
User is allowed to invoke the resource metadata operations ($meta, $meta-add, and $meta-delete) on any resource.
FHIR_MODIFY_SEARCH_PARAMETERS Modify Search Parameters
User is allowed to create, update, and delete search parameters.
FHIR_OP_BINARY_ACCESS_READ
Implies:
FHIR Binary Access Operations (read)
User is allowed to invoke the $binary-access-read operation (note that the user will also need permission to read/write the individual resource that is actually being accessed)
FHIR_OP_BINARY_ACCESS_WRITE
Implies:
FHIR Binary Access Operations (write)
User is allowed to invoke the $binary-access-write operation (note that the user will also need permission to read/write the individual resource that is actually being accessed)
FHIR_OP_ENCOUNTER_EVERYTHING
Implies:
Encounter Fetch ($everything)
User is allowed to search/fetch across the entire encounter (all resources belonging to that patient's compartment).
FHIR_OP_PATIENT_EVERYTHING
Implies:
Patient Search Chart ($everything)
User is allowed to search/fetch across the entire patient's record (all resources belonging to that patient's compartment).
FHIR_OP_PATIENT_MATCH
Implies:
FHIR EMPI Patient Match
User may invoke the EMPI $match operation on a Patient
FHIR_OP_STRUCTUREDEFINITION_SNAPSHOT
Implies:
FHIR StructureDefinition Snapshot
User may invoke the StructureDefinition $snapshot operation
FHIR_PATCH
Implies:
FHIR Patch
User is allowed to perform a FHIR patch operation. Note that this permission allows a patch to be performed, but the user may need additional permissions in order to be able to write to specific resources.
FHIR_PROCESS_MESSAGE
Implies:
FHIR Process Message ($process-message)
User is allowed to invoke the $process-message operation on a server that supports it.
FHIR_READ_ALL_IN_COMPARTMENT
Implies:
FHIR Read ANY in Compartment X
User is allowed to read resources of any type in the given compartment. This permission takes an argument that should take the form of the name of the compartment (e.g. Patient/123).
FHIR_READ_ALL_OF_TYPE
Implies:
FHIR Read ANY of Type
User is allowed to fetch resources (read, search, history, etc.) of the specified type. This permission takes an argument that should be the name of the resource type (e.g. Patient).
FHIR_READ_INSTANCE
Implies:
FHIR Read Specific Instance
User is allowed to fetch (read, search, history, etc.) the specified instance. This permission takes an argument that should be the ID of the resource instance (e.g. Patient/123).
FHIR_READ_SEARCH_PARAMETERS Read Search Parameters
User is allowed to read/search for search parameters.
FHIR_TRANSACTION
Implies:
FHIR Transaction
User is allowed to perform a FHIR transaction. Note that this permission only allows the transaction operation to happen; the user still needs to have other appropriate permissions for the operations in the transaction or it will be blocked.
FHIR_TRIGGER_SUBSCRIPTION
Implies:
FHIR Trigger Subscription
User is permitted to call the $trigger-subscription operation. See Manually Triggering Subscriptions for information on this function.
FHIR_UPLOAD_EXTERNAL_TERMINOLOGY
Implies:
Upload External Terminology
User is permitted to upload external CodeSystems using the $upload-external-code-system operation, as well as by using the Apply Delta operations. See Uploading External Terminologies for more information on this function.
FHIR_WRITE_ALL_IN_COMPARTMENT
Implies:
FHIR Write ANY in Compartment X
User is allowed to write resources of any type in the given compartment. This permission takes an argument that should take the form of the name of the compartment (e.g. Patient/123).
FHIR_WRITE_ALL_OF_TYPE
Implies:
FHIR Write ANY of Type
User is allowed to write resources (create, update, etc.) of the specified type. This permission takes an argument that should be the name of the resource type (e.g. Patient).
FHIR_WRITE_INSTANCE
Implies:
FHIR Write Specific Instance
User is allowed to write (create, update, etc.) the specified instance. This permission takes an argument that should be the ID of the resource instance (e.g. Patient/123).
FHIR_WRITE_TYPE_IN_COMPARTMENT
Implies:
FHIR Write (Specific Type in Compartment)
User is permitted to write any resource of the given type in the given compartment.
MODULE_ADMIN Module Admin
User is allowed to create, reconfigure, and start/stop modules.
OPENID_CONNECT_ADD_CLIENT Add OpenID Connect Client
User is allowed to create OpenID Connect clients.
OPENID_CONNECT_ADD_SERVER Add OpenID Connect Server
User is allowed to create OpenID Connect servers.
OPENID_CONNECT_EDIT_CLIENT Edit OpenID Connect Client
User is allowed to edit existing OpenID Connect clients.
OPENID_CONNECT_EDIT_SERVER Edit OpenID Connect Server
User is allowed to edit existing OpenID Connect servers.
OPENID_CONNECT_VIEW_CLIENT_LIST View OpenID Connect Client List
User is allowed to view the list of registered OpenID Connect clients. This permission does not give the user the ability to create/edit clients.
OPENID_CONNECT_VIEW_SERVER_LIST View OpenID Connect Server List
User is allowed to view the list of registered OpenID Connect servers. This permission does not give the user the ability to create/edit servers.
REINSTATE_MODULE Reinstate Modules
User is allowed to reinstate modules.
SAVE_USER Save Users
User is allowed to create/update users.
START_STOP_MODULE Start/Stop Modules
User is allowed to start/stop modules and nodes.
UPDATE_MODULE_CONFIG Update Module Configuration
User is allowed to modify a module's configuration.
UPDATE_USER Update Users
User is allowed to update other users.
USE_CDA_TEMPLATE Generate CDA documents via the templates
User is allowed to create Compositions / Fhir Documents / CDA Documents via the cda template store. Use caution with this permission with severity relative to how much access the scripts themselves allow.
VIEW_AUDIT_LOG View Audit Log
User is allowed to view the audit log.
VIEW_CDA_TEMPLATE View CDA templates
User is allowed to view all CDA templates (including script contents and expected parameters list).
VIEW_MODULE_CONFIG View Module Configuration
User is allowed to view (but not change) module configuration information. This does not include database passwords.
VIEW_MODULE_STATUS View Module Status
User is allowed to view (but not change) status information about modules. This includes running/stopped status, health checks, etc. but does not give access to more sensitive details such as logs.
VIEW_TRANSACTION_LOG View Transaction Log
User is allowed to view the overall transaction log.
VIEW_TRANSACTION_LOG_EVENT View Transaction Log Entries
User is allowed to view individual transaction log entries.
VIEW_USERS View Users
User is allowed to view list of users and individual user details.