Recording Patient Preferences for Electronic Consent to Access and/or Share their Health Information with Other Care Providers

Type	Standard / Implementation Specification	Standards Process Maturity	Implementation Maturity	Federally required	Cost	Test Tool Availability
Implementation Specification	IHE Basic Patient Privacy Consents (BPPC)	Final	Production	No	Free	Yes
Implementation Specification	HL7® Implementation Guide for CDA®, Release 2: Consent Directives, Release 1	Final	Pilot	No	Free	N/A
Emerging Standard	HL7 FHIR® Consent Resource	In Development	Pilot	No	Free	Yes
Emerging Standard	HL7 FHIR Contract Resource	In Development	Pilot	No	Free	Yes
Emerging Implementation Specification	IHE Advanced Patient Privacy and Consents (APPC)	Balloted Draft	Pilot	No	Free	Yes
Implementation Specification	Specialty Medication Enrollment FHIR IG	Final	Pilot	No	Free	No

Limitations, Dependencies, and Preconditions for Consideration	Applicable Security Patterns for Consideration
The IHE and CDA-based specifications operate in conjunction with the IHE XDS, XCA, and XDR profiles. IHE BPPC may not support management of patient privacy across governmental jurisdictions which may have different regulations regarding access to patient data by providers, patients, governmental entities, and other organizations. Along with security tokens and consent documents, security labels are the critical third part of the Attribute-Based-Access-Control and SLS for this interoperability need. Security Labels are used in CDA, FHIR, as well as the IHE Document Sharing (e.g. XDS), as described on the FHIR security page at https://www.hl7.org/fhir/security-labels.html Carequality® is working to develop a technical method for distributing and identifying consent forms to be used as part of their Patient Consent Framework.	Secure Communication – Create a secure channel for client-to- serve and server-to-server communication. Secure Message Router – Securely route and enforce policy on inbound and outbound messages without interruption of delivery. Authentication Enforcer – Centralized authentication processes. Authorization Enforcer – Specifies access control policies. Credential Tokenizer – Encapsulate credentials as a security token for reuse (e.g., SAML, Kerberos). User Role – Identifies the role asserted by the individual initiating the transaction. Purpose of Use – Identifies the purpose for the transaction. Patient Consent Information – Identifies the patient consent information that may be required before data can be accessed. Additional information about security patterns can be found in Appendix 1.

Limitations, Dependencies, and Preconditions for Consideration

Applicable Security Patterns for Consideration

The IHE and CDA-based specifications operate in conjunction with the IHE XDS, XCA, and XDR profiles.
IHE BPPC may not support management of patient privacy across governmental jurisdictions which may have different regulations regarding access to patient data by providers, patients, governmental entities, and other organizations.
Along with security tokens and consent documents, security labels are the critical third part of the Attribute-Based-Access-Control and SLS for this interoperability need. Security Labels are used in CDA, FHIR, as well as the IHE Document Sharing (e.g. XDS), as described on the FHIR security page at https://www.hl7.org/fhir/security-labels.html
Carequality® is working to develop a technical method for distributing and identifying consent forms to be used as part of their Patient Consent Framework.

Secure Communication – Create a secure channel for client-to- serve and server-to-server communication.
Secure Message Router – Securely route and enforce policy on inbound and outbound messages without interruption of delivery.
Authentication Enforcer – Centralized authentication processes.
Authorization Enforcer – Specifies access control policies.
Credential Tokenizer – Encapsulate credentials as a security token for reuse (e.g., SAML, Kerberos).
User Role – Identifies the role asserted by the individual initiating the transaction.
Purpose of Use – Identifies the purpose for the transaction.
Patient Consent Information – Identifies the patient consent information that may be required before data can be accessed.

Additional information about security patterns can be found in Appendix 1.

Comment

Submitted by pwilson@ncpdp.org on 2023-10-06

NCPDP Comment

NCPDP recommends that ONC remove the comment, “The NCPDP WG18 Patient Consent task group is working on a solution for the exchange of patient consent information between providers,” from the Limitations, Dependencies, and Preconditions for Consideration section. The WG18 Patient Consent Task Group has been disbanded.
NCPDP recommends that ONC create a new distinct category from the existing electronic consent for patient preference. The goal of the new category is to obtain authorization for an individual medication and not to designate a preference for other medications.
NCPDP recommends that ONC add the following category:
1. Category Name: Obtaining patient or provider authorization/consent related to a specific medication fulfillment
  Type: Implementation Specification
  Standard: Specialty Medication Enrollment FHIR® Implementation Guide STU2
  Standards Process Maturity: Final
  Implementation Maturity: Pilot

                   Adoption Level: 1
                   Federally Required: No
                   Cost: Free
                   Test Tool Availability: No

Submitted by shellyspiro on 2023-10-02

Pharmacy HIT Collaborative (PHIT) comment

PHIT supports NCPDP’s recommendation to create a new distinct category from the existing electronic consent for patient preference: Obtaining patient or provider authorization/consent related to a specific medication fulfillment. As NCPDP notes, the goal of the new category is to obtain authorization from an individual medication and not to designate a preference for other medications.

Submitted by pwilson@ncpdp.org on 2021-09-29

NCPDP Comments

The NCPDP WG18 Patient Consent task group is working on a solution for the exchange of patient consent information between providers.

Submitted by akontur on 2020-12-09

Consent2Share profile of FHIR Consent resource

We have removed the Consent2Share profile of FHIR Consent resource from the standards grid as it is not currently being developed further and was not finalized in the ONC Cures Rule. The profile and supporting documentation remains available at https://gforge.hl7.org/gf/project/cbcc/frs/?action=FrsReleaseBrowse&frs_package_id=303

Submitted by pwilson@ncpdp.org on 2020-11-07

NCPDP Comment

The NCPDP WG18 Patient Consent task group is working on a solution for the exchange of patient consent information between providers.

Submitted by pwilson@ncpdp.org on 2019-09-23

NCPDP Comment

NCPDP is forming a task group to explore the need for transactions that support the exchange of patient consent.