On this page:

7.1Authorization and Consent

 

The concepts of consent and authorization in Smile CDR are related but distinct. When a FHIR request is being processed, there are two specific layers that are invoked to make decisions on whether the request can proceed and what data is ultimately disclosed: The Authorization Service and the Consent Service.

The following diagrams show the functionality provided by each of these layers.

7.1.1Authorization Service

 

The following diagram shows the primary purpose of the Authorization Service.

Authorization Svc

The Authorization Service looks at every request (including both the details of the request, and any data being returned) and makes a determination about whether the operation should be permitted or blocked.

As inputs into its decision, the Authorization Service uses:

The Authorization Service makes a simple binary determination: either the request is authorized, or it is blocked and the client will see an HTTP 403 Unauthorized response.

7.1.2Consent Service

 

The following diagram shows the primary purpose of the Authorization Service.

Authorization Svc

The Consent Service looks at every request and makes a determination about whether any data being exposed is acceptable for the user to see, and optionally removes it from what is returned. This removal may include filtering out entire resources (i.e. blocking), and/or filtering out certain elements of resources being returned (i.e. masking).

The consent service is a very flexible mechanism, based entirely on programmed consent rules. Unlike the Authorization Service, which uses a fixed set of inputs (permissions and scopes) to make decisions, the consent script may use any of a number of inputs including but not limited to:

  • Logged-in User and Session Details
  • Consent Records (i.e. Consent resources that have been stored in the CDR)
  • Local policies expressed in code or in 3rd-party formats

See Consent Service for information on setting up the consent service.