Smile CDR v2024.05.PRE
On this page:

15.9.1Roles 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.)

15.9.2System-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.

15.9.3System-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.

This permission does not take any arguments.

ACCESS_ADMIN_WEB

Admin
User is allowed to log into the Web Admin Console.

This permission does not take any arguments.

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.

This permission does not take any arguments.

ACCESS_FHIR_ENDPOINT

FHIR Client
User is allowed to access FHIR services as a client.

This permission does not take any arguments.

AG_ADMIN_CONSOLE_READ

appSphere Admin Console (read)
User is permitted to access application information using appSphere Admin Console

This permission does not take any arguments.

AG_ADMIN_CONSOLE_WRITE

appSphere Admin Console (write)
User is permitted to update existing application information using appSphere Admin Console

This permission does not take any arguments.

AG_DEV_PORTAL_READ

appSphere Developer Portal (read)
User is permitted to access application information using appSphere Developer Portal

This permission does not take any arguments.

AG_DEV_PORTAL_WRITE

appSphere Developer Portal (write)
User is permitted to add new application information using appSphere Developer Portal

This permission does not take any arguments.

ARCHIVE_MODULE

Archive Modules
User is allowed to archive modules.

This permission does not take any arguments.

CDA_IMPORT
Implies:

Import CDA Documents
User is allowed to use the $import-cda operation to import CDA documents

This permission does not take any arguments.

CHANGE_OWN_DEFAULT_LAUNCH_CONTEXTS

Change Own Launch Contexts
User is allowed to update the SMART launch context(s) associated with their own account.

This permission does not take any arguments.

CHANGE_OWN_PASSWORD

Change Own Password
User is allowed to change their own password.

This permission does not take any arguments.

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).

This permission does not take any arguments.

CONTROL_MODULE

Control Module
User is allowed to start/stop/restart modules.

This permission does not take any arguments.

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.

This permission does not take any arguments.

CREATE_MODULE

Create Modules
User is allowed to create new modules.

This permission does not take any arguments.

CREATE_USER

Create Users
User is allowed to create other users.

This permission does not take any arguments.

DELETE_CDA_TEMPLATE

Delete CDA templates
User is allowed to delete CDA document template scripts.

This permission does not take any arguments.

DOCREF
Implies:

DOCREF
User is allowed to use $docref operation

This permission does not take any arguments.

DQM_QPP_BUILD
Implies:

Dqm QPP Build
Transform MeasureReport into QPP format

This permission does not take any arguments.

EMPI_ADMIN

EMPI Admin
User may perform any administrative functions for the EMPI.

This permission does not take any arguments.

EMPI_UPDATE_MATCH_RULES

EMPI Update Match Rules
User can set/update matching rules for the EMPI.

This permission does not take any arguments.

EMPI_VIEW_MATCH_RULES

EMPI VIEW Match Rules
User can view matching rules for the EMPI.

This permission does not take any arguments.

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.

This permission does not take any arguments.

FHIR_ACCESS_PARTITION_ALL
Implies:

Access data in ALL Partitions
User is allowed to access (includes both read and write operations) data in all partitions. Note that this permission does not actually authorize any specific read/write operations, it simply implies access to the partitions.

This permission does not take any arguments.

FHIR_ACCESS_PARTITION_NAME
Implies:

Access data in Partition
User is allowed to access (includes both read and write operations) data in the given partition. Note that this permission does not actually authorize any specific read/write operations, it simply implies access to the given partition.

Argument
The argument to this permission is a partition name, or a comma separated collection of partition names

FHIR_ALL_DELETE
Implies:

FHIR Delete (All)
User is allowed to perform any FHIR delete operation.

This permission does not take any arguments.

FHIR_ALL_READ

FHIR Read (All)
User is allowed to perform any FHIR read/access-to-data operation (e.g. read, search, history, etc.).

This permission does not take any arguments.

FHIR_ALL_WRITE

FHIR Write (All)
User is allowed to perform any FHIR write/modify operation (e.g. create, update, etc.).

This permission does not take any arguments.

FHIR_AUTO_MDM

Automatic MDM Expansion
Perform MDM expansion for all search parameters in the Patient compartment, even if the :mdm qualifier is not explicitly provided in the query

This permission does not take any arguments.

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.

This permission does not take any arguments.

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.

This permission does not take any arguments.

FHIR_DELETE_ALL_IN_COMPARTMENT
Implies:

FHIR Delete (All in Compartment)
User is permitted to delete any resource in the given compartment.

Argument
The argument to this permission is the name of the compartment to which access is being granted.

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).

Argument
The argument to this permission is the resource type.

FHIR_DELETE_CASCADE_ALLOWED
Implies:

FHIR Delete - Cascading Allowed
User is permitted to perform cascading deletes. See Cascading Deletes for more information.

This permission does not take any arguments.

FHIR_DELETE_EXPUNGE
Implies:

FHIR Delete and Expunge ($delete-expunge) All Data
User is permitted to invoke the $delete-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 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.

This permission does not take any arguments.

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.

Argument
The argument to this permission is the name of the type to allow deletion on, followed by a colon, followed by the name of the compartment to which access is being granted. For example, the argument Observation:Patient/123 means that the user is permitted to delete any Observation resource in the Patient/123 compartment.

FHIR_DTR_USER

DTR User privileges
Can execute any DTR operation

This permission does not take any arguments.

FHIR_EMPI_ADMIN

EMPI Administrative privileges
Can execute any EMPI operation.

This permission does not take any arguments.

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.

This permission does not take any arguments.

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.

This permission does not take any arguments.

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.

This permission does not take any arguments.

FHIR_EXTENDED_OPERATION_ON_ANY_INSTANCE
Implies:

Extended Operation (Instance Level / Unchecked Response)
User may invoke operation at the instance level on any operation name specified by argument in the form: $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.

Argument
The argument to this permission is the operation name.

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.

Argument
The argument to this permission is the resource type and operation name.

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.

Argument
The argument to this permission is the resource type and operation name.

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.

Argument
The argument to this permission is the resource type and operation name.

FHIR_GET_RESOURCE_COUNTS
Implies:

FHIR Get Server Resource Counts
User is permitted to call the $get-resource-counts operation, requesting the total counts of resources on the server.

This permission does not take any arguments.

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.

This permission does not take any arguments.

FHIR_LIVEBUNDLE
Implies:

FHIR LiveBundle Operations
User is allowed to invoke the $livebundle-watchlist-add, $livebundle-watchlist-delete, $livebundle-watchlist, and $livebundle operations

This permission does not take any arguments.

FHIR_MANAGE_PARTITIONS
Implies:

Manage Partitions
User is allowed to manage (add/update/delete) partition definitions in the system. Note that this permission is not automatically granted via the ROLE_FHIR_CLIENT_SUPERUSER permission and must be granted explicitly.

This permission does not take any arguments.

FHIR_MANUAL_VALIDATION
Implies:

FHIR Manual Validation
User is allowed to invoke the $validate operation to validate resources.

This permission does not take any arguments.

FHIR_MDM_ADMIN

MDM Administrative privileges
Can execute any MDM operation

This permission does not take any arguments.

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.

This permission does not take any arguments.

FHIR_MODIFY_SEARCH_PARAMETERS

Modify Search Parameters
User is allowed to create, update, and delete search parameters.

This permission does not take any arguments.

FHIR_OP_APPLY
Implies:

Apply
Execute the Apply Operation

This permission does not take any arguments.

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)

This permission does not take any arguments.

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)

This permission does not take any arguments.

FHIR_OP_CARE_GAPS
Implies:

CR Care Gaps
The care-gaps operation is used to determine gaps-in-care based on the results of quality measures.

This permission does not take any arguments.

FHIR_OP_CQL
Implies:

CR CQL
Evaluates a CQL expression and returns the results as a Parameters resource.

This permission does not take any arguments.

FHIR_OP_EMPI_CLEAR
Implies:

EMPI Clear Links
Delete all EMPI links, and remove all related Persons

This permission does not take any arguments.

FHIR_OP_EMPI_DUPLICATE_PERSONS
Implies:

EMPI Duplicate Persons
Request all EMPI Duplicate Persons

This permission does not take any arguments.

FHIR_OP_EMPI_MERGE_PERSONS
Implies:

Merge to EMPI Person resources
Merge one Person resource into another, copying over fields that are empty in the target, and copying over links that are missing in the target. MANUAL links will overwrite AUTO links. The original Person resource is deleted.

This permission does not take any arguments.

FHIR_OP_EMPI_QUERY_LINKS
Implies:

EMPI Query Links
Request matching EMPI Links

This permission does not take any arguments.

FHIR_OP_EMPI_SUBMIT
Implies:

EMPI Batch Processing.
Submit Patients/Practitioners for EMPI processing.

This permission does not take any arguments.

FHIR_OP_EMPI_UPDATE_LINK
Implies:

EMPI Update Link
Update an EMPI Link

This permission does not take any arguments.

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).

This permission does not take any arguments.

FHIR_OP_EVALUATE
Implies:

CR Evaluate
The evaluate operation is used to evaluate cql expressions from a specified library resource and returns it as a Parameters resource.

This permission does not take any arguments.

FHIR_OP_EVALUATE_MEASURE
Implies:

Evaluate Measure
Execute the CQL Evaluate Measure Operation

This permission does not take any arguments.

FHIR_OP_EXTRACT
Implies:

Extract
Execute the Extract Operation

This permission does not take any arguments.

FHIR_OP_INITIATE_BULK_DATA_EXPORT
Implies:

Initiate Bulk Export ($export) - All Permissions
User may invoke the $export operation to initiate a FHIR Bulk Export Operation. This permission grants the user permission to initiate any kind of bulk export, so it may be more appropriate to use a more nuanced kind.

Argument
The argument to this permission is an optional space-separated list of allowed resource types, or an empty string to allow all resource types. E.g. 'Patient Encounter Observation'.

FHIR_OP_INITIATE_BULK_DATA_EXPORT_GROUP
Implies:

Initiate Bulk Export ($export) - Group Export
User may invoke the $export operation to initiate a FHIR Bulk Export Operation. This permission grants the user permission to initiate a group-level export.

Argument
The argument to this permission is the ID of the group that the user is authorized to export, optionally followed by a space-separated list of allowed resource types. E.g. 'Group/123' or 'Group/123 Patient Encounter Observation'.

FHIR_OP_INITIATE_BULK_DATA_EXPORT_PATIENT
Implies:

Initiate Bulk Export ($export) - Patient Export
User may invoke the $export operation to initiate a FHIR Bulk Export Operation. This permission grants the user permission to initiate a patient-level export.

Argument
The argument to this permission is the ID of the patient that the user is authorized to export, optionally followed by a space-separated list of allowed resource types. E.g. 'Patient/123' or 'Patient/123 Patient Encounter Observation'.

FHIR_OP_INITIATE_BULK_DATA_EXPORT_SYSTEM
Implies:

Initiate Bulk Export ($export) - System Export
User may invoke the $export operation to initiate a FHIR Bulk Export Operation. This permission grants the user permission to initiate a system-level export.

Argument
The argument to this permission is an optional space-separated list of allowed resource types, or an empty string to allow all resource types. E.g. 'Patient Encounter Observation'.

FHIR_OP_INITIATE_BULK_DATA_IMPORT
Implies:

Initiate Bulk Import ($import)
User may invoke the FHIR Bulk Import operation. Note that data being bulk imported is not subjected to any additional authorization checks, so this permission should only be granted to fully trusted users.

This permission does not take any arguments.

FHIR_OP_MDM_CLEAR
Implies:

MDM Clear Links
Delete all MDM links and remove all related Golden Resources

This permission does not take any arguments.

FHIR_OP_MDM_CREATE_LINK
Implies:

MDM Create Link
Create an MDM Link

This permission does not take any arguments.

FHIR_OP_MDM_DUPLICATE_GOLDEN_RESOURCES
Implies:

MDM Duplicate Golden Resources
Request all MDM Duplicate Golden Resources

This permission does not take any arguments.

FHIR_OP_MDM_LINK_HISTORY
Implies:

MDM Link History
Request matching Historical MDM Links

This permission does not take any arguments.

FHIR_OP_MDM_MERGE_GOLDEN_RESOURCES
Implies:

Merge two MDM Golden Resources
Merge one Golden Resource into another, copying over fields as determined by the survivorship rules, and copying updating MDM links according to the rules. MANUAL links will overwrite AUTO links. The original Golden Resource is deactivated.

This permission does not take any arguments.

FHIR_OP_MDM_NOT_DUPLICATE
Implies:

MDM Not Duplicate
Unduplicate MDM Golden Resources

This permission does not take any arguments.

FHIR_OP_MDM_QUERY_LINKS
Implies:

MDM Query Links
Request matching MDM Links

This permission does not take any arguments.

FHIR_OP_MDM_SUBMIT
Implies:

MDM Batch Processing.
Submit target resources for MDM processing

This permission does not take any arguments.

FHIR_OP_MDM_UPDATE_LINK
Implies:

MDM Update Link
Update an MDM Link

This permission does not take any arguments.

FHIR_OP_MEMBER_MATCH
Implies:

Member match
Operation to find a member by patient and coverage information

This permission does not take any arguments.

FHIR_OP_PACKAGE
Implies:

Package
Execute the Package Operation

This permission does not take any arguments.

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).

This permission does not take any arguments.

FHIR_OP_PATIENT_EVERYTHING_ACCESS_ALL
Implies:

Patient Fetch ($everything) - Access All
User is allowed to search/fetch across the entire patient's record (all resources that references input Patient, including those outside of patient's compartment).

Argument
The argument to this permission is the ID of the Patient for which user is authorized to execute $everything operation. E.g. 'Patient/123'.

FHIR_OP_PATIENT_MATCH
Implies:

FHIR MDM Match
User may invoke the MDM $match operation either on a server level or on a Patient type

This permission does not take any arguments.

FHIR_OP_PATIENT_SUMMARY
Implies:

Generate IPS ($summary)
User is allowed to invoke the $summary operation to generate an International Patient Summary document.

This permission does not take any arguments.

FHIR_OP_POPULATE
Implies:

Populate
Execute the Populate Operation

This permission does not take any arguments.

FHIR_OP_PREPOPULATE
Implies:

Prepopulate
Execute the Prepopulate Operation

This permission does not take any arguments.

FHIR_OP_STRUCTUREDEFINITION_SNAPSHOT
Implies:

FHIR StructureDefinition Snapshot
User may invoke the StructureDefinition $snapshot operation

This permission does not take any arguments.

FHIR_OP_SUBMIT_DATA
Implies:

CR Submit Data
The submit-data operation is used to submit data-of-interest for a measure. There is no expectation that the submitted data represents all the data-of-interest, only that all the data submitted is relevant to the calculation of the measure for a particular subject or population.

This permission does not take any arguments.

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.

This permission does not take any arguments.

FHIR_PROCESS_MESSAGE
Implies:

FHIR Process Message ($process-message)
User is allowed to invoke the $process-message operation on a server that supports it.

This permission does not take any arguments.

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).

Argument
The argument to this permission is the name of the compartment to which access is being granted.

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).

Argument
The argument to this permission is the name of the resource type.

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).

Argument
The argument to this permission is 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.

This permission does not take any arguments.

FHIR_READ_TYPE_IN_COMPARTMENT
Implies:

FHIR Read (Specific Type in Compartment)
User is permitted to read any resource of the given type in the given compartment.

Argument
The argument to this permission is the name of the type to allow reading from, followed by a colon, followed by the name of the compartment to which access is being granted. For example, the argument Observation:Patient/123 means that the user is permitted to read any Observation resource in the Patient/123 compartment.

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.

This permission does not take any arguments.

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.

This permission does not take any arguments.

FHIR_UPDATE_REWRITE_HISTORY
Implies:

History Rewrite
User is allowed to update historical versions of a resource without creating new versions. See Rewrite Resource History for more information.

This permission does not take any arguments.

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.

This permission does not take any arguments.

FHIR_WRITE_ALL_IN_COMPARTMENT
Implies:

FHIR Write ANY in Compartment X
User is allowed to write (create, update, patch, etc.) 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).

Argument
The argument to this permission is the name of the compartment to which access is being granted.

FHIR_WRITE_ALL_OF_TYPE
Implies:

FHIR Write ANY of Type
User is allowed to write resources (create, update, patch, etc.) of the specified type. This permission takes an argument that should be the name of the resource type (e.g. Patient).

Argument
The argument to this permission is the name of the resource.

FHIR_WRITE_INSTANCE
Implies:

FHIR Write Specific Instance
User is allowed to write (create, update, patch, etc.) the specified instance. This permission takes an argument that should be the ID of the resource instance (e.g. Patient/123).

Argument
The argument to this permission is 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 (create, update, patch, etc.) any resource of the given type in the given compartment.

Argument
The argument to this permission is the name of the type to allow writing to, followed by a colon, followed by the name of the compartment to which access is being granted. For example, the argument Observation:Patient/123 means that the user is permitted to write any Observation resource in the Patient/123 compartment.

HFQL_EXECUTE

Execute HFQL Query
User is allowed to execute HFQL/SQL statements.

This permission does not take any arguments.

INVOKE_CDS_HOOKS

CDS Hooks
User can call CDS Hooks

This permission does not take any arguments.

MANAGE_BATCH_JOBS

Manage Batch Jobs
User has permission to manage (i.e. modify and control) batch jobs

This permission does not take any arguments.

MDM_ADMIN

MDM Admin
User may perform any administrative functions for the MDM.

This permission does not take any arguments.

MDM_UPDATE_MATCH_RULES

MDM Update Match Rules
User can set/update matching rules for the MDM.

This permission does not take any arguments.

MDM_VIEW_MATCH_RULES

MDM VIEW Match Rules
User can view matching rules for the MDM.

This permission does not take any arguments.

MODULE_ADMIN

Module Admin
User is allowed to create, reconfigure, and start/stop modules.

This permission does not take any arguments.

OIDC_CLIENT_PRESET_PERMISSION

Add OpenID Connect Client with pre-set permissions.
User is allowed to create OpenID Connect clients with pre-set permissions.

Argument
The argument to this permission is the name of permissions (e.g. ACCESS_FHIRWEB).

OPENID_CONNECT_ADD_CLIENT

Add OpenID Connect Client
User is allowed to create OpenID Connect clients.

This permission does not take any arguments.

OPENID_CONNECT_ADD_SERVER

Add OpenID Connect Server
User is allowed to create OpenID Connect servers.

This permission does not take any arguments.

OPENID_CONNECT_EDIT_CLIENT

Edit OpenID Connect Client
User is allowed to edit existing OpenID Connect clients.

This permission does not take any arguments.

OPENID_CONNECT_EDIT_SERVER

Edit OpenID Connect Server
User is allowed to edit existing OpenID Connect servers.

This permission does not take any arguments.

OPENID_CONNECT_MANAGE_GLOBAL_SESSIONS

Manage Sessions (Global/All Users)
User is allowed to list and revoke SMART/OIDC sessions for any users in the system. This is an administrative privilege that should only be granted to admin and system users.

This permission does not take any arguments.

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.

This permission does not take any arguments.

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.

This permission does not take any arguments.

PACKAGE_REGISTRY_READ

Package Registry: Read Operations
User can access data from the package registry.

This permission does not take any arguments.

PACKAGE_REGISTRY_WRITE

Package Registry: Write Operations
User can write data to the package registry.

This permission does not take any arguments.

REINSTATE_MODULE

Reinstate Modules
User is allowed to reinstate modules.

This permission does not take any arguments.

SAVE_USER

Save Users
User is allowed to create/update users.

This permission does not take any arguments.

START_STOP_MODULE

Start/Stop Modules
User is allowed to start/stop modules and nodes.

This permission does not take any arguments.

SUBMIT_ATTACHMENT
Implies:

Submit Attachment
User is allowed to use the $submit-attachment operation.

This permission does not take any arguments.

UPDATE_MODULE_CONFIG

Update Module Configuration
User is allowed to modify a module's configuration.

This permission does not take any arguments.

UPDATE_USER

Update Users
User is allowed to update other users.

This permission does not take any arguments.

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.

This permission does not take any arguments.

VIEW_AUDIT_LOG

View Audit Log
User is allowed to view the audit log.

This permission does not take any arguments.

VIEW_BATCH_JOBS

View Batch Jobs
User has permission to view batch jobs

This permission does not take any arguments.

VIEW_CDA_TEMPLATE

View CDA templates
User is allowed to view all CDA templates (including script contents and expected parameters list).

This permission does not take any arguments.

VIEW_METRICS

View Metrics
User can access internal metrics API, including thread dump API

This permission does not take any arguments.

VIEW_MODULE_CONFIG

View Module Configuration
User is allowed to view (but not change) module configuration information. This does not include database passwords.

This permission does not take any arguments.

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.

This permission does not take any arguments.

VIEW_TRANSACTION_LOG

View Transaction Log
User is allowed to view the overall transaction log.

This permission does not take any arguments.

VIEW_TRANSACTION_LOG_EVENT

View Transaction Log Entries
User is allowed to view individual transaction log entries.

This permission does not take any arguments.

VIEW_USERS

View Users
User is allowed to view list of users and individual user details.

This permission does not take any arguments.

15.9.4System-Defined Negative Permissions

 

The following table lists the negative permissions that are built into Smile CDR and may be assigned to a user. Negative permissions prevent actions from occurring, and take precedence over positive permissions. In other words, if a user has a normal permission indicating the ability to perform an action, but also has a negative permission that contradicts the given permission, the action will not be permitted.

Negative Permission Description
BLOCK_FHIR_READ_UNLESS_CODE_IN_VS
Implies:

Block FHIR Read Unless Code is in ValueSet
When present, this permission indicates that resources of the given type can not be read unless they have a coded field (indicated by a SearchParameter name) is found in the specified ValueSet (indicated by URL). See Block Unless Code in ValueSet for more information.

Argument
The argument for this permission is in the form [resourceType]/[param name]/[ValueSet URL], e.g. "Observation/code/http://hl7.org/fhir/ValueSet/observation-vitalsignresult"

BLOCK_FHIR_READ_UNLESS_CODE_NOT_IN_VS
Implies:

Block FHIR Read Unless Code is not in ValueSet
When present, this permission indicates that resources of the given type can not be read unless they have a coded field (indicated by a SearchParameter name) is not found in the specified ValueSet (indicated by URL). See Block Unless Code in ValueSet for more information.

Argument
The argument for this permission is in the form [resourceType]/[param name]/[ValueSet URL], e.g. "Observation/code/http://hl7.org/fhir/ValueSet/observation-vitalsignresult"

15.9.5Block Unless Code in ValueSet

 

A pair of permissions can be used to authorize access to data by checking if a coded field contains a code that is matched by a ValueSet. This functionality can be an allow-list (only allow access to resources matched by the ValueSet) or a block-list (only allow access to resources that are not matched by the ValueSet).

To specify an allow-list, the BLOCK_FHIR_READ_UNLESS_CODE_IN_VS permission should be used. To specify a block-list, the BLOCK_FHIR_READ_UNLESS_CODE_NOT_IN_VS permission should be used. Both of these permissions take an argument in the form: [resourceType]/[param name]/[ValueSet URL].

Because these permissions are negative, they must be combined with a normal permission that actually grants access to resources. In other words, if only a negative permission is present, it will not be possible to access data.

For example, to enforce that a user can only access Observations belonging to Patient/123 where the Observation.code value is in the Vital Signs Result ValueSet, use the following permissions:

FHIR_READ_ALL_IN_COMPARTMENT/Patient/123
BLOCK_FHIR_READ_UNLESS_CODE_IN_VS/Observation/code/http://hl7.org/fhir/ValueSet/observation-vitalsignresult

To enforce that a user can only access Observations belonging to Patient/123 where the Observation.code value is not in the Vital Signs Result ValueSet, use the following permissions:

FHIR_READ_ALL_IN_COMPARTMENT/Patient/123
BLOCK_FHIR_READ_UNLESS_CODE_NOT_IN_VS/Observation/code/http://hl7.org/fhir/ValueSet/observation-vitalsignresult

15.9.5.1Automatic Search Narrowing

When these permissions are used, it can be helpful to also enable Automatically Narrow Search Scope on your FHIR Endpoint module. This will automatically add appropriate search parameters to searches in order to ensure that they are excluded from search results.

15.9.5.2Automatic Search Narrowing Limitations

When the Automatically Narrow Search Scope configuration has been enabled on your FHIR Endpoint module, the calculation of search result totals will not be available to preserve the privacy of possibly-filtered records. This includes the use of the _total=accurate and _summary=count query string parameters.

Note that when using search narrowing with these permissions, the search will have a token:in or token:not-in search parameter added to the search.

These operations are currently not suitable for large ValueSets (containing over 500 codes) and may not perform well at that scale.