Privacy Consent on FHIR (PCF)
1.1.1-current - ci-build International flag

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

Example Consent: Consent allowing NORMAL but not RESTRICTED data access

Generated Narrative: Consent ex-consent-advanced-normal-not-restricted

status: Active

scope: Privacy Consent

category: Consent

patient: Jack Smith Male, DoB: 1923-07-25

dateTime: 2022-06-13

performer: Jack Smith Male, DoB: 1923-07-25

organization: Organization somewhere org

source: DocumentReference: status = current; type = Release of information consent; description = The captured signed document

Policies

-Uri
*http://example.org/policies/basePrivacyConsentPolicy.txt

provision

type: Opt In

securityLabel: Confidentiality N: normal

purpose: ActReason TREAT: treatment, ActReason HPAYMT: healthcare payment, ActReason HOPERAT: healthcare operations

Provisions

-TypeSecurityLabel
*Opt OutConfidentiality R: restricted

Notes:

IUA Access Token

Provided an ITI-71 results in a PERMIT access token issued. That token would have the following residual element to inform the Consent Enforcement Point that it needs to restrict the results.

Given that the token will express the permit portion, the residual would need to express the refinement. In this case, given that the restriction to normal data is at the root, it means that nothing BUT normal data is allowed. This case also has explicit deny on restricted data. This restriction would be implied, but here it is explicit, so we will show how to make it explicit in the oAuth token. The oAuth token would be expressing a general permit for the given user to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.

The token would need to include an ihe_pcf extension to point at this consent, and that would include a residual to express the refinement. Shown as followed:

  • The restriction to the given purpose (Treatment, Payment, and Operations) would be expressed in the ihe_iua extension
    • The other ihe_iua extension parameters are not shown below
  • The restriction to just normal data would need to be expressed:
    • First as a forbid everything
    • Second as a permit normal data
    • Third is a redundant forbid of restricted data
"extensions" : {
  "ihe_iua" : {
    ...
    "purpose_of_use" : [{
        "system" : "http://terminology.hl7.org/CodeSystem/v3-ActReason",
        "code" : "TREAT"
      },{
        "system" : "http://terminology.hl7.org/CodeSystem/v3-ActReason",
        "code" : "HPAYMT"
      },{
        "system" : "http://terminology.hl7.org/CodeSystem/v3-ActReason",
        "code" : "HOPERAT"
    }]
  }
  "ihe_pcf" : {
    "patient_id" : "http://example.org/fhir/Patient/ex-patient",
    "doc_id" : ["http://example.org/fhir/Consent/ex-consent-intermediate-authoredby"],
    "residual" : [
      {
        "type" : "forbid",
      },{
        "type" : "permit",
        "securityLabel" : [{
            "system" : "http://terminology.hl7.org/CodeSystem/v3-Confidentiality",
            "code" : "N"
        }]
      },{
        "type" : "forbid",
        "securityLabel" : [{
            "system" : "http://terminology.hl7.org/CodeSystem/v3-Confidentiality",
            "code" : "R"
        }]
      }
    ]
  }
}