See past articles for more
- Basic Consent - a necessary first step
- BPPC is not just for XDS/XCA
- IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
- Texas HIE Consent Management System Design
- Beyond Basic Privacy – The IHE APPC Profile
- Identify who the Patient is -- in BPPC the patient is all that is recorded in coded form. The act might have been signed by a guardian or parent; but that would be only noted in the attachment. It was not seen as critical to automatic processing
- Identify what organization is being bound by this Consent -- in BPPC there was not a need to differentiate between what organization is bound, vs what organization signed, vs what organization is allowed to use this consent.
- Policy being acknowledged -- this enables the community to define a set of policies that are offered, and the one picked and agreed to by the patient is referenced. That policy might be the "OPT-OUT" policy, thus their selection is to not allow sharing of data. -- ITI TF3:18.104.22.168.1.2
- Time period that the Consent is valid -- supports a consent that starts in the future, and a consent that has an expiration -- ITI TF3:22.214.171.124.1
- When the Consent happened - BPPC doesn't address when the consent was indexed as that is not important to automatic processing
- What PurposeOfUse this applies to -- what activities identified by PurposeOfUse vocabulary. When the consent is an OPT-OUT, this means this PurposeOfUse is forbidden. The PurposeOfUse enables research project-by-project identification each as a coded value.
- Copy of the signed policy, which may be scanned ink-on-paper or other representation
- Replacing previous choice -- enabling patient to change their mind as many times as they want
- Column A -- short identification of the above fundamental
- Column B -- BPPC as it would look in MHD (FHIR DocumentReference) with no adjustments
- Column C -- BPPC as it would look published in FHIR Consent with no adjustments or improvements -- plenty more can be don in FHIR Consent
- Column D -- BPPC as it is today in XDS/XCA
APPC - Advanced Patient Privacy Consents Profile
- Where the FHIR Consent is similar to above, where Consent.policy.uri points at a base policy, but the deviations from that policy would be encoded in APPC (XACML) and that is pointed by Consent.source[x]
- This model optimizes on maintenance at the expense of much less optimal run-time decision making
- Where the FHIR Consent is very sparsly populated with Consent.policy.uri pointing at a patient specific instance of APPC (XACML). Meaning where above this uri value is from a small pre-published policies that are chosen from, in this case each Consent instance has a unique uri as each one has encoded policy using XACML language. The drawback is that one must look inside to see all the context, which is not a problem when one is relying on XACML enforcement engines which would need this in XACML anyway.
- This model optimizes on run-time decision use of XACML, and is harder to do the maintenance (new consent, replacement consent, expiration, etc)