15.11    Anonymous Access
  • Security
  • 15.0 Security in Smile CDR
  • 15.1 Authentication Protocols
  • 15.2 Authorization and Consent
  • 15.3 Inbound Security Module
  • 15.4 Local Inbound Security Module
  • 15.5 LDAP Inbound Security Module
  • 15.6 Scripted Inbound Security Module
  • 15.7 SAML Inbound Security Module
  • 15.8 Trusted Client Mode
  • 15.9 Roles and Permissions
  • 15.10 Callback Scripts
  • 15.11 Anonymous Access
  • 15.12 Consent Service
  • 15.13 Consent Service: JavaScript API
  • 15.14 Consent Service: Java API
  • 15.15 Security Recipes
  • 15.16 Two Factor Authentication
  • 15.17 Troubleshooting Security
    • 15.13    Consent Service: JavaScript API   
       Table of Contents

    Consent Service

    15.12.1Consent Service

     

    A common concern in building healthcare applications is ensuring that local rules are respected around who can see and change different data. These rules may take many forms. A few examples are presented below:

    • In a healthcare app, administrative users might not be allowed to look at specific details of some resources (e.g. perhaps they can access Observations but not see the values)

    • In a regional data exchange, you might want to allow individual patients to specify that their data should be restricted.

    • In a research database, you might want to prevent the release of data about a specific patient until that patient has provided consent.

    • In a patient portal, a specific user should only ever be allowed to access their own data.

    The list above shows a few examples, but the overall point here is that there is a bottomless list of possible consent rules that might need to be applied.

    15.12.1.1Architecture

    As described in Authorization and Consent, the Authorization Service and the Consent Service play related but distinct roles (and in fact these roles may overlap).

    The following diagram shows the interplay between these two systems.

    Authorization Svc

    15.12.2Enabling the Consent Service

     

    The Smile CDR consent service is driven by a user-supplied script that implements the specific consent rules of your application. This script can be simple or very powerful, and has the ability to make decisions based on various kinds of input. Consent scripts are configured in FHIR REST endpoint modules (i.e. FHIR REST Endpoint, FHIR Gateway REST Endpoint, and Hybrid Providers REST Endpoint) and FHIR storage modules. This configuration is found in the Consent Service section.

    Note that Hybrid Providers projects must implement the following pointcut calls in order for the consent service to work with a Hybrid Providers REST Endpoint module:

    Consent Service implementations may be created using either of the following APIs:

       15.11    Anonymous Access
  • Security
  • 15.0 Security in Smile CDR
  • 15.1 Authentication Protocols
  • 15.2 Authorization and Consent
  • 15.3 Inbound Security Module
  • 15.4 Local Inbound Security Module
  • 15.5 LDAP Inbound Security Module
  • 15.6 Scripted Inbound Security Module
  • 15.7 SAML Inbound Security Module
  • 15.8 Trusted Client Mode
  • 15.9 Roles and Permissions
  • 15.10 Callback Scripts
  • 15.11 Anonymous Access
  • 15.12 Consent Service
  • 15.13 Consent Service: JavaScript API
  • 15.14 Consent Service: Java API
  • 15.15 Security Recipes
  • 15.16 Two Factor Authentication
  • 15.17 Troubleshooting Security
    • 15.13    Consent Service: JavaScript API