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

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. The NCPDP®WG18 Patient Consent task group is working on a solution for the exchange of patient consent information between providers.	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.
The NCPDP®WG18 Patient Consent task group is working on a solution for the exchange of patient consent information between providers.

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 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.

About the ISA

ISA Content

ISA Sections

Appendices

Specialty Care and Settings

ISA Publications

Recent ISA Updates

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

Comment

NCPDP Comments

Consent2Share profile of FHIR Consent resource

NCPDP Comment

NCPDP Comment

Connect with us: