This page is part of the FHIR Specification (v1.4.0: STU 3 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

Privacy Consent Directive (PCD)

M.0 PCD on FHIR Implementation Guide (IG)

This is the IG Overview.

M.0.1 Introduction

The purpose of this document is to describe constraints on the FHIR Contract used to express a Privacy Consent Directive.

Privacy policies define how Individually Identifiable Health Information (IIHI) is to be collected, accessed, used and disclosed. A Privacy Consent Directive is a record of a client’s (e.g., patient, consumer) health information privacy policy. A Privacy Consent Directive grants or withholds authorization to collect, access, use, or disclose IIHI about the client. A client may author/publish their privacy preferences as a self-declared Privacy Consent Directive. Effective Privacy Consent Directives are a bilateral agreement between the client and an individual/organization that is in accord with law, regulation and organizational policies with regard to their content. In addition, Privacy Consent Directives provide the ability for a healthcare client to delegate authority to a Substitute Decision Maker who may act on behalf of that individual.

The Privacy Consent Directive on FHIR provides support for alternative representations for expressing health information privacy consent directives in a standard form for the exchange of privacy policies that can be enforced by consuming systems (e.g., scanned documents, computable structured entries).

The implementation guide also supports backward compatibility by enabling references to CDA Consent Directives following the HL7 CDAR2 ConsentDirective Implementation Guide which incorporated the IHE Basic Patient Privacy Consents (BPPC) mechanism of acknowledging a Privacy Policy identifier and expanded upon it with privacy policy attributes captured in the CDA document according to the CDA-CD-IG specification. This guide allows for the capture of a scanned document in the structuredBody of a CDA document to support manual interpretation of the meaning of the privacy consent directive as well as to support the capture of a client’s wet signature.

This guide supports sending a computable representation of privacy consent directives using structured entries based on a mapping of the HL7 Version 3 Domain Analysis Model: Medical Records; Composite Privacy Consent Directive, Draft Standard for Trial Use (DSTU) Release 2 (CPCD DAM) to HL7 FHIR Contract attributes, or by using standard access control markup languages (XACML, XrML and others). It is expected that other SDOs will use the Privacy domain analysis model to create profiles (e.g., OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) Technical Committee) and that for encoding capabilities, formal policy languages will be used.

M.0.1.1 US Realm sample Use-Cases

Five categories of Privacy Consent Directives are described in the Office of the National Coordinator for Health Information (ONC) Consent Directives Document released March 31, 2010, and include the following US-specific “Core consent options” for electronic exchange:

1. No consent: Health information of patients is automatically included—patients cannot opt out;
2. Opt-out: Default is for health information of patients to be included automatically, but the patient can opt out completely;
3. Opt-out with exceptions: Default is for health information of patients to be included, but the patient can opt out completely or allow only select data to be included;
4. Opt-in: Default is that no patient health information is included; patients must actively express consent to be included, but if they do so then their information must be all in or all out; and
5. Opt-in with restrictions: Default is that no patient health information is made available, but the patient may allow a subset of select data to be included.

M.0.1.2 Canada Realm sample Use-Cases

The following scenarios are based on existing jurisdictional policy and are realized in existing systems in Canada. The default policy is one of implied consent for the provision of care, so these scenarios all deal with withdrawal or withholding consent for that purpose. In other jurisdictions, where an express consent model is used (Opt-In), these would examples would contain the phrase "consent to" rather than "withhold" or "withdraw" consent for.

1. Withhold or withdraw consent for disclosure of records related to specific domain (e.g. DI, LAB, etc.)
2. Withhold or withdraw consent for disclosure of a specific record (e.g. Lab Order/Result)
3. Withhold or withdraw consent for disclosure to a specific provider organization
4. Withhold or withdraw consent for disclosure to a specific provider agent (an individual within an organization)
5. Withhold or withdraw consent for disclosure of records that were authored by a specific organization (or service delivery location).
6. Combinations of the above

M.0.2 Scope

The scope of this IG is to define a FHIR profile for a Privacy Consent Directive in a structured and coded way so so that the rules can be enforced.

The enforcement of the Privacy Consent Directive is not included in this Implementation Guide, but is expected that enforcement can be done using various Access Control enforcement methodologies (e.g. XACML).

M.0.3 Conformance

This guide defines the following conformance statements. Systems implementing the actors described below should provide a conformance resource documenting their conformance to this implementation guide.

Actor	Description
Actor 1 (Consent Writer?)	Brief description of Actor 1 conformance requirements.
Actor 2 (Consent Reader?)	Brief description of Actor 2 conformance requirements.
Actor 3 (Consent Enforcer?)	Brief description of Actor 3 conformance requirements.

M.0.4 Resource Profiles

This guide defines the following profiles.

Profile Name	Description
Base Privacy Consent Directive	Constraints upon Contract to support documentation of a Patient Privacy Consent Directive.
Profile 1-a	Brief description of profile 1-a.
Profile 2	Brief description of profile 2.

M.0.5 Extensions

The following extensions have been defined to support .. These extensions are used within the Profile 1 and Profile 2 profiles on the Resource Name Resource.

Extension	Definition
Property 1	Brief description of the property 1 extension.

M.0.6 Value Sets and Terminologies

Name	Definition
Namespace: http://hl7.org/fhir/ValueSet
Value Set 1	Brief description of value set 1.

M.0.7 References

¹ Implications of SOA Architectures for Security and Privacy Bernd Blobel, PhD, FACMI, FACHI, FHL7 eHealth Competence Center Regensburg

² HL7 CDAR2 ConsentDirective Implementation Guide

³ IHE Basic Patient Privacy Consents (BPPC)

⁴ HL7 Version 3 Domain Analysis Model: Medical Records; Composite Privacy Consent Directive, Draft Standard for Trial Use (DSTU) Release 2 (CPCD DAM)