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

Artifacts Summary

This page provides a list of the FHIR artifacts defined as part of this implementation guide.

Explicit Basic Consent

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:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the mother
    • same pattern is used when the performer is an adult child giving consent onbehalf of elderly mother, or a power-of-attorney giving access to a disabled patient’s data.
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO
Consent for any Healthcare Research example

Consent for any healthcare research purpose

This is a BasicConsent:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes HRESCH to indicate all Healthcare Research

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:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO
Consent for treatment example with expiration

Consent that includes an expiration.

This is a BasicConsent, that has expired, example:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO
  • provision period end was at December 31, 2022 – thus this Consent has expired.
Consent for treatment example with ink signature

Consent for purposes of use involved in treatment: Treatment/Payment/Operations

This is a BasicConsent example:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference – Ink signature on paper
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO
Dissent for treatment example

Dissent for purposes of use involved in treatment: Treatment/Payment/Operations

This is a BasicConsent example:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #deny – rejecting the indicated policy
  • base provision includes TPO so as to be clear this is a consent about TPO
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

  • status 1..1 - would indicate active
  • scope 1..1 - #patient-privacy
  • category 1..1 - would indicate patient consent, specifically a delegation of authority
  • identifier 0..1 - no defined use in PCF. This could carry business identifiers assigned to the consent instance
  • patient 1..1 - would indicate the Patient resource reference for the given patient
  • dateTime 1..1 - would indicate when the privacy policy was presented
  • performer 1.. - would indicate the Patient resource if the patient was presented, a RelatedPerson for parent or guardian
  • organization 1.. - would indicate the Organization that presented the privacy policy, and that is going to enforce that privacy policy
  • source 1..1 - would point at the specific signed consent by the patient
  • policy.uri 1..1 - would indicate the privacy policy that was presented. Usually, the url to the version-specific policy
  • provision.type 1..1 - permit indicates agreement with the policy, deny would indicate rejection.
  • provision.actor 0..* - would indicate those being granted permit / denied access, if empty then all in the community
  • provision.actor.role - fixed value IRCP to indicate information recipient.
  • provision.purpose - would indicate some set of authorized purposeOfUse
  • provision.period MS - would indicate a sunset for the consent if applicable, empty means no expiration
  • provision.provisions are allowed

Not defined in PCF, but allowed

  • policy.authority - not used in PCF
  • policyRule - not used in PCF

Not allowed in PCF

  • provision.provision.provisions - NOT allowed, no clear use-case need and would add complexity
  • verification - not used in PCF, unclear the use-case need
  • provision.action - not used in PCF. The purpose is sufficient.
  • provision.class - not used in PCF, unclear the use-case need
  • provision.code - not used in PCF, unclear the use-case need

Specifics of Basic:

  • provision.purpose - would indicate some set of authorized purposeOfUse only Treatment, Payment, or Operations, see Intermediate
  • provision.securityLabel is not allowed, see Intermediate
  • provision.dataPeriod is not allowed, see Intermediate
  • provision.data is nto allowed, see Intermediate
  • provision.provision are NOT allowed, see Intermediate
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.

Explicit Intermediate Consent

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:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • base provision is #permit – accepting the policy

This is the Intermediate part:

  • Intermediate PurposeOfUse are those that fall outside the basic purposeOfUse valueset
  • In this case the PurposeOfUse will be for a Clinical Research Project – FooBar
  • given that the intermediate purpose is a Clinical Research project, then the policy URI will also be different
  • allowing a given purpose beyond the basic purpose valueSet
  • Given this is a research project, also have included the research organization as actor
Consent allowing data authored by a practitioner

Consent allowing data authored by

This is the Basic part:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO

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:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO

This is the Intermediate part:

Consent allowing data authored within a timeframe

Consent allowing data authored within a timeframe

This is the Basic part:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO

This is the Intermediate part:

  • access only data authored within 2022
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:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO

This is the Intermediate part:

  • a sub-provision denying access to data authored by ex-practitioner
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:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO

This is the Intermediate part:

  • permit form most uses
  • a sub-provision denying access to data authored within 2022
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:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO

This is the Intermediate part:

  • a sub-provision denying access to data authored within an encounter
Consent allowing most sharing but NOT specific data

Consent allowing most sharing of data but NOT specific data

This is the Basic part:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO

This is the Intermediate part:

  • a sub-provision denying access to a specific data instance
Consent allowing specific data

Consent allowing specific data

This is the Basic part:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO

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:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • base policy is Policy-break-glass-only
  • base provision is #deny access given the overriding policy

This is the Intermediate part:

  • sub-provision permits users on the managed group of authorized to break-glass
    • Note that the consent would not need to point at the group as it would be understood. But I point at a group for illustrative purposes.
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

  • all elements allowed by Basic are allowed here, plus the following
  • restriction at the root .provision apply to the whole Consent
    • restrictions at the .provision.provision are exceptions to the base consent
    • no .provision.provision.provisions are allowed
  • data authored in a timeframe is specified in the .dataPeriod element
  • explicit data objects are indicated in the .data element with .meaning of #instance
  • data with relationship to an object are indicated in a .data element with .meaning of #related
  • data authored by a given actor is indicated in the .data element with .meaning of #authoredby
  • purposes of use activities are indicated in the .purpose element
  • securityLabel is not allowed, see Advanced
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.

Explicit Advanced Consent

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:

  • ETH – Substance Abuse including Alcohol
    • ETHUD – Alcohol substance abuse
    • OPIOIDUD – Opioid drug abuse
  • PSY – Psychiatry Disorder / Mental Health
  • SDV – Sexual Assault, Abuse, or Domestic Violence
  • HIV – HIV/AIDS

At a minimum the following ConfidentialityCodes shall be implemented as parameters:

  • N Normal and
  • R Restricted
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:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO

This is the Advanced part:

  • Normal data only
  • only break-glass gets RESTRICTED data
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:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO

This is the Advanced part:

  • Normal data only
  • only Practitioner gets Mental Health or Sexual Health data
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:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO

This is the Advanced part:

  • Normal data only
  • only Practitioner gets Mental Health data only
Consent allowing NORMAL and focused RESTRICTED data access

Consent allowing NORMAL data access but only focused RESTRICTED.

This is the Basic part:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO

This is the Advanced part:

  • Normal data only
  • only Practitioner gets Restricted data only
Consent allowing NORMAL and RESTRICTED data access

Consent allowing NORMAL and RESTRICTED data access

This is the Basic part:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO

This is the Advanced part:

  • Normal and Restricted data only
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:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO

This is the Advanced part:

  • Normal data only
  • Not Restricted data only
Consent allowing NORMAL data access

Consent allowing NORMAL data access

This is the Basic part:

  • status is active - so it should be enforced
  • scope is privacy
  • category is LOINC 59284-0 Consent
  • date indicated when the consent is recorded
  • patient is identified
  • performer is the patient
  • organization is identified
  • source indicate a DocumentReference (with included text of the policy)
  • policy url is to a base policy
  • base provision is #permit – accepting the policy
  • base provision includes TPO so as to be clear this is a consent about TPO

This is the Advanced part:

  • Normal data only
IHE PCF Explicit Advanced Consent

Explicit Advanced Consent

  • all elements allowed by Basic and Intermediate are allowed here, plus the following
  • securityLabel indicates sensitivity or confidentiality tags on data

Security Labeling Service resources

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)

  • SAMSHA C2S Alcohol Use Disorders
    • ValueSet 2.16.840.1.113762.1.4.1142.1 // SNOMEDCD
    • ValueSet 2.16.840.1.113762.1.4.1142.2 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.3 // RXNORM
    • ValueSet 2.16.840.1.113762.1.4.1142.4 // ICD10CD
    • ValueSet 2.16.840.1.113762.1.4.1142.5 // LOINC
  • SAMSHA C2S Amphetamine Use Disorders
    • ValueSet 2.16.840.1.113762.1.4.1142.10 // RXNORM
    • ValueSet 2.16.840.1.113762.1.4.1142.11 // SNOMED-CT
    • ValueSet 2.16.840.1.113762.1.4.1142.6 // HCPCS
    • ValueSet 2.16.840.1.113762.1.4.1142.7 // ICD10CM
    • ValueSet 2.16.840.1.113762.1.4.1142.8 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.9 // LOINC
  • SAMSHA C2S Cannabis Use Disorders
    • ValueSet 2.16.840.1.113762.1.4.1142.12 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.13 // ICD10CM
    • ValueSet 2.16.840.1.113762.1.4.1142.14 // LOINC
    • ValueSet 2.16.840.1.113762.1.4.1142.15 // SNOMED-CT
  • SAMSHA C2S Cocaine Use Disorder
    • ValueSet 2.16.840.1.113762.1.4.1142.16 // ICD10CM
    • ValueSet 2.16.840.1.113762.1.4.1142.17 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.18 // SNOMED-CT
  • SAMSHA C2S Hallucinogens
    • ValueSet 2.16.840.1.113762.1.4.1142.19 // ICD10CM
    • ValueSet 2.16.840.1.113762.1.4.1142.20 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.21 // LOINC
    • ValueSet 2.16.840.1.113762.1.4.1142.22 // SNOMED-CT
  • SAMSHA C2S Inhalants
    • ValueSet 2.16.840.1.113762.1.4.1142.28 // ICD10CM
    • ValueSet 2.16.840.1.113762.1.4.1142.29 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.30 // SNOMED-CT
  • SAMSHA C2S Opioids
    • ValueSet 2.16.840.1.113762.1.4.1142.38 // ICD10CM
    • ValueSet 2.16.840.1.113762.1.4.1142.39 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.40 // LOINC
    • ValueSet 2.16.840.1.113762.1.4.1142.41 // RXNORM
    • ValueSet 2.16.840.1.113762.1.4.1142.42 // SNOMED-CT
    • ValueSet 2.16.840.1.113762.1.4.1142.59 // CPT
  • SAMSHA C2S Other Psychoactive Substance Use Disorder
    • ValueSet 2.16.840.1.113762.1.4.1142.43 // SNOMED-CT
    • ValueSet 2.16.840.1.113762.1.4.1142.44 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.45 // ICD10CM
  • SAMSHA C2S Sedative Hypnotic, or anxiolytic related disorders
    • ValueSet 2.16.840.1.113762.1.4.1142.46 // SNOMED-CT
    • ValueSet 2.16.840.1.113762.1.4.1142.47 // ICD10CM
    • ValueSet 2.16.840.1.113762.1.4.1142.48 // ICD9CM
  • SAMSHA C2S Substance use Information Sensitivity
    • ValueSet 2.16.840.1.113762.1.4.1142.55 // HCPCS
    • ValueSet 2.16.840.1.113762.1.4.1142.56 // LOINC
    • ValueSet 2.16.840.1.113762.1.4.1142.57 // RXNORM
  • SAMSHA Test C2S Alcohol Use Disorders
    • ValueSet 2.16.840.1.113762.1.4.1142.65 // SNOMED-CT
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)

  • SAMSHA C2S Alcohol Use Disorders
    • ValueSet 2.16.840.1.113762.1.4.1142.1 // SNOMEDCD
    • ValueSet 2.16.840.1.113762.1.4.1142.2 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.3 // RXNORM
    • ValueSet 2.16.840.1.113762.1.4.1142.4 // ICD10CD
    • ValueSet 2.16.840.1.113762.1.4.1142.5 // LOINC
  • SAMSHA Test C2S Alcohol Use Disorders
    • ValueSet 2.16.840.1.113762.1.4.1142.65 // SNOMED-CT
clinical codes that indicate HIV

HIV/AIDS information

  • SAMSHA C2S HIV/AIDS Information
    • ValueSet 2.16.840.1.113762.1.4.1142.23 // HCPCS
    • ValueSet 2.16.840.1.113762.1.4.1142.24 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.25 // LOINC
    • ValueSet 2.16.840.1.113762.1.4.1142.26 // RXNORM
    • ValueSet 2.16.840.1.113762.1.4.1142.27 // SNOMED-CT
    • ValueSet 2.16.840.1.113762.1.4.1142.60 // CPT
  • SAMSHA Test C2S HIV/AIDS Information Sensitivity
    • ValueSet 2.16.840.1.113762.1.4.1142.67 // SNOMEDCD
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)

  • SAMSHA C2S Amphetamine Use Disorders
    • ValueSet 2.16.840.1.113762.1.4.1142.10 // RXNORM
    • ValueSet 2.16.840.1.113762.1.4.1142.11 // SNOMED-CT
    • ValueSet 2.16.840.1.113762.1.4.1142.6 // HCPCS
    • ValueSet 2.16.840.1.113762.1.4.1142.7 // ICD10CM
    • ValueSet 2.16.840.1.113762.1.4.1142.8 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.9 // LOINC
  • SAMSHA C2S Cannabis Use Disorders
    • ValueSet 2.16.840.1.113762.1.4.1142.12 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.13 // ICD10CM
    • ValueSet 2.16.840.1.113762.1.4.1142.14 // LOINC
    • ValueSet 2.16.840.1.113762.1.4.1142.15 // SNOMED-CT
  • SAMSHA C2S Cocaine Use Disorder
    • ValueSet 2.16.840.1.113762.1.4.1142.16 // ICD10CM
    • ValueSet 2.16.840.1.113762.1.4.1142.17 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.18 // SNOMED-CT
  • SAMSHA C2S Hallucinogens
    • ValueSet 2.16.840.1.113762.1.4.1142.19 // ICD10CM
    • ValueSet 2.16.840.1.113762.1.4.1142.20 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.21 // LOINC
    • ValueSet 2.16.840.1.113762.1.4.1142.22 // SNOMED-CT
  • SAMSHA C2S Inhalants
    • ValueSet 2.16.840.1.113762.1.4.1142.28 // ICD10CM
    • ValueSet 2.16.840.1.113762.1.4.1142.29 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.30 // SNOMED-CT
  • SAMSHA C2S Opioids
    • ValueSet 2.16.840.1.113762.1.4.1142.38 // ICD10CM
    • ValueSet 2.16.840.1.113762.1.4.1142.39 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.40 // LOINC
    • ValueSet 2.16.840.1.113762.1.4.1142.41 // RXNORM
    • ValueSet 2.16.840.1.113762.1.4.1142.42 // SNOMED-CT
    • ValueSet 2.16.840.1.113762.1.4.1142.59 // CPT
  • SAMSHA C2S Other Psychoactive Substance Use Disorder
    • ValueSet 2.16.840.1.113762.1.4.1142.43 // SNOMED-CT
    • ValueSet 2.16.840.1.113762.1.4.1142.44 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.45 // ICD10CM
  • SAMSHA C2S Sedative Hypnotic, or anxiolytic related disorders
    • ValueSet 2.16.840.1.113762.1.4.1142.46 // SNOMED-CT
    • ValueSet 2.16.840.1.113762.1.4.1142.47 // ICD10CM
    • ValueSet 2.16.840.1.113762.1.4.1142.48 // ICD9CM
  • SAMSHA C2S Substance use Information Sensitivity
    • ValueSet 2.16.840.1.113762.1.4.1142.55 // HCPCS
    • ValueSet 2.16.840.1.113762.1.4.1142.56 // LOINC
    • ValueSet 2.16.840.1.113762.1.4.1142.57 // RXNORM
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)??

  • SAMSHA C2S Mental Health Disorders
    • ValueSet 2.16.840.1.113762.1.4.1142.32 // ICD10CM
    • ValueSet 2.16.840.1.113762.1.4.1142.33 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.34 // LOINC
    • ValueSet 2.16.840.1.113762.1.4.1142.35 // RXNORM
    • ValueSet 2.16.840.1.113762.1.4.1142.36 // SNOMED-CT
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.

  • SAMSHA C2S Sexuality and reproductive health information sensitivity
    • ValueSet 2.16.840.1.113762.1.4.1142.49 // ICD9CM
    • ValueSet 2.16.840.1.113762.1.4.1142.50 // RXNORM
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

  • marked as compliant with IHE.ToDo.bodyWeight profile
  • marked as test data
  • status of final
  • category vital-signs
  • code of loinc body weight
  • subject of the example patient
  • effective time of December 25th, 2004
  • weight 185 pounds
  • note: a bit heavy
Example of an MHV blood sugar R4 observation

holding typical health values

  • SLS assessed this as not sensitvie
  • SLS added Normal due to not sensitive
Example of an valid FHIR bodyWeight R4 observation, but not compliant with the profile

Sample for demonstration purposes of a common weight Observation.

  • Given that this is not compliant, it is thus not declaring that it is compliant, it is just an Observation
  • marked as test data
  • status of final
  • category of vital-signs
  • code of loinc 29463-7 and 3141-9
  • also code of snomed 27113001
  • subject of the example patient
  • linked to an encounter
  • effectiveDateTime = March 28, 2016
  • weight 280 lbs
  • note: a bit heavy, about 280 lbs
Observation - SH: Alcohol Use

This example Observation resource to represent alcohol use assessment in a patient summary.

  • SLS assessed this as ETHUD
  • SLS added Restricted due to the ETHUD assessment

Behavior: Capability Statements

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

  • is a Client that uses Access Consent [ITI-108] to retrieve current Privacy Consent and make access control decisions based upon them
PCF Consent Recorder Actor

CapabilityStatement for the Consent Recorder Actor

Explain

PCF Consent Registry Actor

CapabilityStatement for Consent Registry Actor.

Explain

Example: Example Instances

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