Privacy Consent on FHIR (PCF)
1.1.1-current - ci-build
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
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
Artifacts related to Explicit Basic option
Basic Purpose ValueSet |
ValueSet of the PurposeOfUse minimally extensible by Basic Option |
Binary example using Binary |
Example of a binary ink signed document. |
Binary example using DocumentReference |
Example of a scanned image of an ink signature in binary using DocumentReference. |
Clerk Practitioner example |
Clerk Practitioner example used as an example Clerk managing Consents |
Consent for access for treatment example given by mother to infants data |
Consent for purposes of use involved in Treatment/Payment/Operations, to an infants data, given by the mother This is a BasicConsent example:
|
Consent for any Healthcare Research example |
Consent for any healthcare research purpose This is a BasicConsent:
Note that in this case the HRESCH is not part of the extensible ValueSet for BasicConsent, but because it is not within that ValueSet then it is allowed as extensible. Also note that HRESCH is a top level (ontological) code covering all possible forms of healthcare research. Thus the Permit on this top level concept is a Permit on all sub concepts including specific projects that the organization defines within this top level concept. |
Consent for purpose of treatment example |
Consent for purposes of use involved in treatment: Treatment/Payment/Operations This is a BasicConsent example:
|
Consent for treatment example with expiration |
Consent that includes an expiration. This is a BasicConsent, that has expired, example:
|
Consent for treatment example with ink signature |
Consent for purposes of use involved in treatment: Treatment/Payment/Operations This is a BasicConsent example:
|
Dissent for treatment example |
Dissent for purposes of use involved in treatment: Treatment/Payment/Operations This is a BasicConsent example:
|
DocumentReference Consent Paperwork example |
DocumentReference example of the paperwork of the Consent This is showing an example of a document that is purely text. |
Example Organization holding the data |
The Organization that holds the data, and enforcing any Consents |
Example Patient |
The patient from which all the example relate |
IHE PCF Explicit Basic Consent |
Explicit Basic Consent
Not defined in PCF, but allowed
Not allowed in PCF
Specifics of Basic:
|
Provenance of Create of a basic consent |
Given a Consent is created, and AuditEvent is not seen as sufficient, This example provides an example of Provenance that would be equivilant. |
Provenance of Update of a basic consent |
Given a Consent is updated, and AuditEvent is not seen as sufficient, This example provides an example of Provenance that would be equivilant. |
Artifacts related to Explicit Intermediate option
Consent allowing data access for a given intermediate purpose |
Consent allowing data access for a given intermediate purpose This is the Basic part:
This is the Intermediate part:
|
Consent allowing data authored by a practitioner |
Consent allowing data authored by This is the Basic part:
This is the Intermediate part:
|
Consent allowing data authored related to an encounter |
Consent allowing data authored related to an encounter This is the Basic part:
This is the Intermediate part:
|
Consent allowing data authored within a timeframe |
Consent allowing data authored within a timeframe This is the Basic part:
This is the Intermediate part:
|
Consent allowing most sharing but NOT data authored by a practitioner |
Consent allowing most sharing of data but NOT data authored by a practitioner This is the Basic part:
This is the Intermediate part:
|
Consent allowing most sharing but NOT data authored within a timeframe |
Consent allowing most sharing of data but NOT data authored within a timeframe This is the Basic part:
This is the Intermediate part:
|
Consent allowing most sharing but NOT data related to an encounter |
Consent allowing most sharing of data but NOT data related to an encounter This is the Basic part:
This is the Intermediate part:
|
Consent allowing most sharing but NOT specific data |
Consent allowing most sharing of data but NOT specific data This is the Basic part:
This is the Intermediate part:
|
Consent allowing specific data |
Consent allowing specific data This is the Basic part:
This is the Intermediate part:
|
Consent forbid data access except for Break-Glass |
Consent forbid data access except for Break-Glass This is the Basic part:
This is the Intermediate part:
|
Dummy Practitioner example |
Dummy Practitioner example for completeness sake. No actual use of this resource other than an example target |
Example Encounter |
holding typical values |
Example Organization doing the FooBar Research |
The Organization that is allowed access for FooBar research project |
IHE PCF Explicit Intermediate Consent |
Explicit Intermediate Consent
|
Those users that the organization authorizes to use Break-Glass |
This is a managed list of users that are authorzed to Break-Glass. The list is managed by the treatment Organization. |
Artifacts related to Explicit Advanced option
Advanced Security Tag ValueSet |
ValueSet of the security tags allowed in Advanced Consent Option At a minimum the following stigmatizing Sensitivity classifications shall be implemented as parameters:
At a minimum the following ConfidentialityCodes shall be implemented as parameters:
|
Consent allowing NORMAL and break-glass access to RESTRICTED data |
Consent allowing NORMAL and break-glass access to RESTRICTED (e.g., Mental Health or Sexual Health) data. This is the Basic part:
This is the Advanced part:
|
Consent allowing NORMAL and focused access to Mental Health or Sexual Health data |
Consent allowing NORMAL and focused access to Mental Health or Sexual Health data. This is the Basic part:
This is the Advanced part:
|
Consent allowing NORMAL and focused Mental Health data access |
Consent allowing NORMAL data access but only focused Mental Health Abuse. This is the Basic part:
This is the Advanced part:
|
Consent allowing NORMAL and focused RESTRICTED data access |
Consent allowing NORMAL data access but only focused RESTRICTED. This is the Basic part:
This is the Advanced part:
|
Consent allowing NORMAL and RESTRICTED data access |
Consent allowing NORMAL and RESTRICTED data access This is the Basic part:
This is the Advanced part:
|
Consent allowing NORMAL but not RESTRICTED data access |
Consent allowing NORMAL data access but NOT RESTRICTED. The exclusion of RESTRICTED should not be needed, given permit is only Normal This is the Basic part:
This is the Advanced part:
|
Consent allowing NORMAL data access |
Consent allowing NORMAL data access This is the Basic part:
This is the Advanced part:
|
IHE PCF Explicit Advanced Consent |
Explicit Advanced Consent
|
Artifacts to support a Security Labeling Service (SLS)
clinical codes that indicate ETH |
codes that when found in data would indicate the data is likely ETH related ETH - substance abuse information sensitivity (alcohol or drug-abuse information)
|
clinical codes that indicate ETHUD |
codes that when found in data would indicate the data is likely ETHUD related ETHUD - alcohol abuse information sensitivity (alcohol abuse information)
|
clinical codes that indicate HIV |
HIV/AIDS information
|
clinical codes that indicate OPIOIDUD |
codes that when found in data would indicate the data is likely OPIOIDUD related OPIOIDUD - Opioid substance abuse information sensitivity (drug-abuse information)
|
clinical codes that indicate PSY |
codes that when found in data would indicate the data is likely PSY related PSY - psychiatry disorder information sensitivity ??should this include MH (Mental Health), PSYTHPN (psychotherapy note), and SUD (subsance use)??
|
clinical codes that indicate SDV |
SDV - Sexual assault, abuse or domestic violence ??should this also include SEX (sexuality and reproductive health information sensitivity), PREGNANT (pregnancy), STD (sexually transmitted disease)? The SAMSHA valuesets seem to be labeled as if they are only about sexuality and reproductive health, but do include sexual abuse and sexually transmitted disease.
|
Example of a blood pressure R4 observation, minimal |
holding typical values |
Example of a bodyWeight R4 observation |
Sample for demonstration purposes of a common weight Observation
|
Example of an MHV blood sugar R4 observation |
holding typical health values
|
Example of an valid FHIR bodyWeight R4 observation, but not compliant with the profile |
Sample for demonstration purposes of a common weight Observation.
|
Observation - SH: Alcohol Use |
This example Observation resource to represent alcohol use assessment in a patient summary.
|
The following artifacts define the specific capabilities that different types of systems are expected to have in order to comply with this implementation guide. Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements.
PCF Consent Authorization Server Actor |
CapabilityStatement for the Consent Authorization Server Actor Explain
|
PCF Consent Recorder Actor |
CapabilityStatement for the Consent Recorder Actor Explain
|
PCF Consent Registry Actor |
CapabilityStatement for Consent Registry Actor. Explain
|
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.
Dummy Authoring Practitioner example |
Dummy Practitioner example for completeness sake. No actual use of this resource other than an example target |
Mother of John |
The patient resource describing the mother |