Privacy Consent on FHIR (PCF), published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 1.1.1-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/ITI.PCF/ and changes regularly. See the Directory of published versions

3:5.8 Privacy Consent Patterns

The following are the FHIR Consent profiling for the PCF profile. The FHIR Consent fundamentals are explained in Appendix P.

3:5.8.1 Foundation Policies

The Foundation Consent Content Profile indicates the common constraints for all of PCF. There are no examples of this as there is no intended use of this profile.

3:5.8.2 Basic

Using Basic Consent Content Profile

Examples for this Resource Profile:

• Basic Consent to sharing for Treatment policy
  • ITI-71 access token
• Basic Consent with an Ink signature
  • ITI-71 access token
• Basic Consent that Rejects the base policy given – This could also be a representation of a situation when the patient has changed to rejection of a prior agreement
  • ITI-71 access token
• Consent that has expired
  • ITI-71 access token

3:5.8.3 Intermediate

Using Intermediate Consent Content Profile

Examples for this Resource Profile:

• restricted Consent to data authored in a timeframe
  • ITI-71 access token
• restricted exception to data authored in a timeframe
  • ITI-71 access token
• restricted consent to a named set of data
  • ITI-71 access token
• restricted exception to a named set of data
  • ITI-71 access token
• restricted consent to data authored by a Practitioner
  • ITI-71 access token
• restricted exception to data authored by a Practitioner
  • ITI-71 access token
• restricted consent to data related to an encounter
  • ITI-71 access token
• restricted exception to data related to an encounter
  • ITI-71 access token
• restricted consent to specific intermediate purpose of use
  • ITI-71 access token
• Dissent except for Break-Glass.
  • ITI-71 access token

3:5.8.3.1 Example of Intermediate by ID Search Set Bundle Processing

Given using Intermediate consent that identifies one Observation with id=1 not be shared. Like named set of data. The Consent Authorization Server would provide ITI-71 access token which is communicated to the Consent Enforcement Point. The Consent Enforcement Point would first allow the Search to happen, and the raw output from a FHIR search would include all observations including the forbidden Observation. That would look like:

The Bundle would then be processed by the Consent Enforcement Point, which will remove any Observations with id=1. Thus the first entry would be removed and the total decremented. The result would look like the following and be what is returned by the Grouped Server:

3:5.8.4 Advanced

Using Advanced Consent Content Profile

Examples for this Resource Profile:

• Consent to allow NORMAL data access
  • ITI-71 access token
• Consent to allow NORMAL and RESTRICTED data access
  • ITI-71 access token
• Consent to allow NORMAL data access but not RESTRICTED – This adds the not restricted which should not be needed as the root only authorizes NORMAL
  • ITI-71 access token
• Consent to allow NORMAL data access, and some access to RESTRICTED
  • ITI-71 access token
• Consent to allow NORMAL data access, and some access to Mental Health
  • ITI-71 access token
• Consent to allow NORMAL data access, and some access to Mental Health and Sexual Health
  • ITI-71 access token
• Consent to allow NORMAL data access, and break-glass access to RESTRICTED
  • ITI-71 access token

3:5.8.4.1 Example of Advanced Search Set Bundle Processing

Given using Advanced consent that identifies that no Alcohol Use Disorder information shall be shared, and using the SLS model of “Query/Use enforcement” discussed in Appendix P: Security Labeling Service Models. Note that there are other SLS architecture models, the “Query/Use enforcement” is being used only for illustrative purposes. The Consent Authorization Server would provide ITI-71 an Access Token indicating no Alcohol Use Disorder information is allowed is communicated to the Consent Enforcement Point. The Consent Enforcement Point would first allow the Search to happen, and the raw output from a FHIR search would include all observations including the forbidden Observation. That would look like:

In the “Query/Use enforcement” the Bundle would then be processed by the SLS and sensitivity and confidentiality tags would be added:

The tagged Bundle would then be processed by the Consent Enforcement Point, which will remove any Alcohol use Disorder information. Thus the first entry would be removed and the total decremented. The result would look like the following and be what is returned by the Grouped Server:

Note that the data returned may have the resulting security tags that the SLS applied, or those tags may be removed prior to the Grouped Server returning the results to the Grouped Client. This exposure of the tags is a policy decision that the PCF does not mandate.