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 – Open
Implementation Specification	HL7 Implementation Guide for CDA®, Release 2: Consent Directives, Release 1	Final	Pilot	No	Free	N/A
Emerging Implementation Specification	IHE Advanced Patient Privacy and Consents (APPC)	Balloted Draft	Pilot	No	Free	Yes
Emerging Standard	HL7 FHIR® Consent Resource	In Development	Pilot	No	Free	Yes
Emerging Standard	HL7 FHIR® Contract Resource	In Development	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. See IHE and FHIR projects in the Interoperability Proving Ground. 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.
See IHE and FHIR projects in the Interoperability Proving Ground.
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 [email protected] 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.

About the ISA

ISA Content

ISA Sections

Appendices

Specialty Care and Settings

ISA Publications

Recent ISA Updates

21st Century Cures

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

Comment

NCPDP Comments