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
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.
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).
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.
- The user is authenticated, typically as part of their long-term session.
- At some point the system queries the HIE and includes a XUA assertion along with the XDS Query parameters
- An Access Control service intercepts the transaction and inspects the XUA assertion and XDS Query parameters
- 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.
- If there is no OPT-OUT, then the query is forwarded to the Document Registry that processes it normally
- And returns the normal results
- 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
- 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
- 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