IHE - Privacy and Security Profiles - Basic Patient Privacy Consents

Across organizational boundaries it is sometimes important to have a way to express allowances or restrictions on healthcare data access because of the patients own wishes. There are cases where the allowed use-cases are so tightly constrained that a data-holder can completely make the decision to share or not and there is no need to communicate patient privacy policies, such as in the USA NwHIN-Exchange where the decision is made at the time of access, and a copy is completely transferred into the control of the requesting organization.

The need to include patient wishes in the access control decision is somewhat unique to healthcare, where there is a dual 'ownership' of the data. In most industries any information they have to share have simple one directional ownership, even if there are cases where a service is exposing intellectual property of others, the exposing organization obtains clear use of the data (e.g. images inside a mapping tool). In the case of healthcare information the patient has a stronger desire and need to control the information. This is related to the personal nature of the data, but also to the irrevocableness of the information. Once this information is exposed there is no way to revoke the information, such as there is with credit-card numbers.

IHE started this profile in May of 2006, but could find no standards available that met the complex need.  This is why the profile is clearly identified as "Basic", as we knew that this would not satisfy all use-cases, so we created the Basic Patient Privacy Consents profile. The profile can satisfy a few cases where the policies are simple; essentially pre-coordinated policies.

• In a cross-enterprise or cross-community environment how are the Privacy Preferences of the Patient (Consumer) made known and thus enforced?
• Consent is given and retracted
• Consent in some environments is only for a specific time
• There may be many consents relevant to different organizations or situations
• Need to support Privacy Policies beyond consent, such as authorizing research access

Step 1: The first thing that must be done is that organizational policies must be written. That is there needs to be some policy domain that is agreed to that is inclusive of all the organizations participating in the Health Information Exchange. Within this space a set of policies need to be written in detail, e.g. Opt-In, Opt-Out-Fully, Opt-Out-Safe, No-Publish, etc. Not just titles, but exactly what do they mean. For example what is the impact of each of these on Role-Based-Access-Control, Emergency-Override, Chain-of-Command, Patient-Access, Regulatory-Controls, Workflows, etc. Don't forget to define what the rule is when no consent has been obtained. This is truly the hard part, and a part that needs to be done regardless of how capable the privacy consent system is.

Now that you have a set of policies that would be offered to the Patient to choose from, give them each a unique identifier (i.e., privacy-OID). Configure all access control engines to recognize what that privacy-OID means, that is to execute a specific set of access control rules. The mechanism will be unique to each implementation of access control engines. The future 'advanced' consents would support encoding the meaning in computable statements that can be read by the access control engine directly. In this future state the policies are not pre-coordinated, but post-coordinated. This future is still not here today. 

Step 2: This step is all about capturing each patient's consent. The actual human interaction with the patient is beyond an 'interoperability' profile, but some application or human needs to provide the different choices to the patient. This user interface is critical to success as the patient needs to be well informed but not overwhelmed. The patient will choose which of the choices they agree with, this is the 'acknowledgement' step. We use 'acknowledge' as some policies are explicitly denying access, so 'consent' is not descriptive. 

The BPPC profile indicates how to create a CDA document that includes the ACT by the patient of 'acknowledging' the specific privacy policy or policies. This new document is now a representation, token, that captures the act of agreement by the patient and the organization authoring the document. This CDA document can include, embedded inside, a PDF image such as an ink-on-paper signature by the patient. This CDA document could be digitally signed using the Document Digital Signature Profile. This CDA document could have limits placed on the timeframe of the consent, very useful in some regions where consent is only for an episode of care.

This CDA document is then published in the same way that clinical documents are published, it has some specific metadata values to make it easy to find and easy to understand (the natural reason for metadata). Some regional implementations have chosen to create two document sharing infrastructures, one that holds only BPPC consent documents; the other holds all the clinical documents. This is usually done to separate, segment, the control documents from the clinical documents. This separation can be easily done virtually through an administrative confidentialityCode 

Step 3: This step is about Enforcement by the members of the  Privacy Domain. As indicated in Step 1 above, each unique policy identifier is pre-configured in all access control enforcement engines.  Any one of these access control engines could be audited to show that they do indeed enforce the policy appropriately.  These access control policies could leverage profiles such as ATNA for system identity, XUA for user identity and purpose of use, and directory information about users for other attributes.  One specific purpose of use could be a privilege escalation request through the declaration that the user has invoked a break-glass functionality.

Due to the BPPC defined metadata for this CDA document that holds the consent acknowledgement, there are very simple queries for the XDS metadata that are all that is needed to determine which policies have been agreed to. There is no need to pull the copy of the CDA document. The Access Control engine simply needs to do an XDS/XCA query for BPPC type documents. If zero results are returned this indicates that there are no consents on file. For every result that does return, the startTime and stopTime indicate the validity time for that consent, thus allowing for episodic consents.  The resulting entries can be examined for the eventCodeList, the list of consent-OIDs that have been acknowledged. The Access Control engine just looks up these codes internally for the rules to apply (for example where the consent-OID is an XACML policy identifier).

Standards: The key standards are CDA, with optional inclusion of a Digital Signature, and/or Scanned Document (PDF). The intended environment is XDS, XDR, XDM, or XCA. It is also possible to use the BPPC Document in other ways, they are just not explained in the IHE profile.

BPPC has been further developed in HL7 as part of a Draft Standard for Trial Use on Consent templates using CDA. This Draft is a logical extension of BPPC, and the transition of an operational environment to these advanced CDA consent documents, when they are available, should be an easy transition.

Diagram showing a potential implementation of OPT-OUT: The logic shown is not mandatory, but is shown as illustrative of how this might be implemented using XUA in an XDS environment that enforces the BPPC consent, specifically OPT-OUT, in the Health Information Exchange. All accesses shown would also be protected and monitored by ATNA to assure that only trusted systems are involved and that all accesses to sensitive information is recorded in the security audit log.

1. The user is authenticated, typically as part of their long-term session.
2. At some point the system queries the HIE and includes a XUA assertion along with the XDS Query parameters
3. An Access Control service intercepts the transaction and inspects the XUA assertion and XDS Query parameters
4. The Access Control service looks for any OPT-OUT BPPC documents, If the patient has agreed to OPT-OUT; then the access control service responds with zero-results-found. 
5. If there is no OPT-OUT, then the query is forwarded to the Document Registry that processes it normally
6. And returns the normal results

It is possible that the return results could be further filtered based on the ROLE of the user, but that is not shown here. This is the topic of slides later on.

Although BPPC is 'Basic', it does enable communications of the patients agreement to simple pre-coordinated policies such as Opt-In and Opt-OUT. It can enable episodic consents that are time limited. It can be used to enable specific authorizations such as research projects, or clinical trials. It could be used to enable authorizations that are site specific, where the patient might authorize one organization to have access but not others. The profile is designed to be easily integrated into access control environments, yet be on the logical pathway to more advanced consent policy languages.

References:  

• Status: Final Text
• IHE ITI Technical Framework
• Vol 1: Section 19
• Vol 3: Section 5.1
• Options added to other transactions
• Vol 2a:  Section 3.18
• Vol 2b: Section 3.32, 3.41, 3.42, 3.43

Additional Comments

• Uses CDA to capture that the patient has agreed to a policy by reference
  • The policy is not actually ever described in the profile or the document, just referenced. This is because there is not sufficient maturity to any standard for encoding of privacy policies. Therefore BPPC assumes that someone can write the policy in human readable language and give that a unique identifier (OID). This OID is used as a reference.
• Supports the consent being digitally signed with DSG
• Supports encapsulation of a scanned image of something (e.g. an ink on paper signature) using the XDS-SD profile
• Supports time limited consents
• Supports both positive policies (OPT-IN) and negative (e.g. OPT-OUT)
• Recognizes that the absence of an instance of a policy means that some other policy is in place. Commonly called 'implied consent'.
• Defined for XDS, XDM, XDR, XCA - and may work for other environments
• See Stepping stones for Privacy Consent, Data Objects and the Policies that Control them, Consent Management using HITSP TP30

Back links

This is part of a blog presentation of the IHE Privacy and Security Profiles Overview:

• Introduction to IHE impact on Meaningful Use
• IHE - Privacy and Security Profiles - Introduction
• IHE - Privacy and Security Profiles - Consistent Time
• IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
• IHE - Privacy and Security Profiles - Enterprise User Authentication
• IHE - Privacy and Security Profiles - Cross-Enterprise User Assertion
• IHE - Privacy and Security Profiles - Document Digital Signature
• This Page
• IHE - Privacy and Security Profiles - Document Encryption
• IHE - Privacy and Security Profiles - Access Control
• IHE - Privacy and Security Profiles - Miscellaneous
• IHE - Privacy and Security Profiles - Conclusion