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

Printer Friendly, PDF & Email
Type Standard Implementation/Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 2
No
Free
Yes – Open
Emerging Implementation Specification
Final
Pilot
Rating 1
No
Free
N/A
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Emerging Implementation Specification
In Developement
Pilot
Rating 1
No
Free
Yes
Emerging Implementation Specification
In Developement
Pilot
Rating 1
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.
  • 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.