Privacy Consent on FHIR (PCF)
1.1.0 - Trial-Implementation 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.0 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 most sharing but NOT data authored by a practitioner

Generated Narrative: Consent

Resource Consent "ex-consent-intermediate-not-authoredby"

Profile: IHE PCF Explicit Intermediate Consent

Security Labels: http://terminology.hl7.org/CodeSystem/v3-ActReason

status: active

scope: Privacy Consent (Consent Scope Codes#patient-privacy)

category: Consent (LOINC#59284-0)

patient: Patient/ex-patient " SMITH"

dateTime: 2022-06-13

performer: Patient/ex-patient " SMITH"

organization: Organization/ex-organization "somewhere org"

source: DocumentReference/ex-documentreference

Policies

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

provision

type: permit

purpose: treatment (Details: http://terminology.hl7.org/CodeSystem/v3-ActReason code TREAT = 'treatment', stated as 'null'), healthcare payment (Details: http://terminology.hl7.org/CodeSystem/v3-ActReason code HPAYMT = 'healthcare payment', stated as 'null'), healthcare operations (Details: http://terminology.hl7.org/CodeSystem/v3-ActReason code HOPERAT = 'healthcare operations', stated as 'null')

provision

type: deny

data

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 the oAuth token and scope will address a general permit, and thus the residual need only express the forbid to information authored by the given practitioner.

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 forbid data authored by the given practitioner would be expressed
"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-not-authoredby"],
    "residual" : [
      {
        "type" : "deny",
        "data" : [{
            "meaning" : "authoredby",
            "reference" : {
            "reference" : "http://example.org/fhir/Practitioner/ex-practitioner"
            }
        }]
      }
    ]
  }
}