FHIR Consent mapped with BPPC

Today on the FHIR Consent call we had a very useful discussion of how one would use FHIR Consent to do the same thing that BPPC does in XDS. Said another way, what is the degenerate form of FHIR Consent that is equal-to the functionality of BPPC, and what is the degenerate form of FHIR Consent that is compatible with BPPC. We did have a slight side discussion about APPC, but lets start simple.

BPPC -- Basic Patient Privacy Consent

An IHE profile for use in an XDS/XCA environment to convey the Privacy Policy Consent status given some basic function. This profile was intentionally called "Basic" with the expectation that something more expressive would eventually come along, but at the time we needed a solution for simple use-cases. Something did come along that is more expressive, called Advanced Patient Privacy Consent (APPC).  BPPC is still the dominant solution as it fits the realistic set of use-cases that are most used. APPC leverages BPPC for context setting and documentation, but adds more flexible rules. Where BPPC supports a binary (true/false), and APPC enables all flavors of grey.

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

BPPC supports:

The BPPC profile supports a few vectors. It might be Basic, but it is really quite useful:

1. 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
2. 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.
3. 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:5.1.2.1.1.2 
4. Time period that the Consent is valid -- supports a consent that starts in the future, and a consent that has an expiration -- ITI TF3:5.1.2.2.1
5. When the Consent happened - BPPC doesn't address when the consent was indexed as that is not important to automatic processing
6. 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.
7. Copy of the signed policy, which may be scanned ink-on-paper or other representation
8. Replacing previous choice -- enabling patient to change their mind as many times as they want

Here is a table showing the mapping between these fundamentals:

• 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

Basic Patient Privacy mechanism	BPPC in MHD	BPPC in FHIR Consent	BPPC in XDS
Resource Type	FHIR DocumentReference	FHIR Consent	XDS Document Entry
type identifier	DocumentReference.code = LOINC “57016-8”	Consent.category = LOINC “57016-8”	DocumentEntry.typeCode = LOINC “57016-8”
1) Identify who the Patient is	DocumentReference.subject = Reference(Patient)	Consent.patient = Reference(Patient)	DocumentEntry.patientId
2) What organization is bound by this Consent	DocumentReference.author = Reference(Organization)	Consent.performer = Reference(Organization) Consent.organization=Reference(Organization) Consent.provision[0].actor.reference=Reference(Organization)	DocumentEntry.author
3) Policy being acknowledged	DocumentReference.context.event	Consent.policy.uri	DocumentEntry.eventCodeList
4) Time period that the Consent is valid	DocumentReference.context.period	Consent.provision[0].period	DocumentEntry.serviceStartTime <=>.serviceStopTime
5) When consent happened	DocumentReference.content.attachment.creation	Consent.dateTime	DocumentEntry.creationTime
6) What PurposeOfUse this applies to	DocumentReference.securityLabel	DocumentReference.provision[0].purpose	DocumentEntry.confidentialityCode
7) Copy of the signed policy	DocumentReference.content.attachment.url	Two Alternatives A) Consent.sourceAttachment B) Consent.sourceReference = Reference(DocumentReference)	DocumentEntry.URI
8) Replacing previous choice	FHIR Create (New)DocumentReferencewith details & Set previous DocumentReference.status = superseded with DocumentReference.relatesTo.target = (New)DocumentReference	Two Alternatives A) (New)Consent with details & Set previous Consent.status=inactive B) Update Consent with details using a Version tracking Server	XDS Replace operation
fixed values	DocumentReference.content.format=urn:ihe:iti:bppc:2007	Consent.status = active Consent.scope = patient-privacy Consent.provision[0].type = permit | deny	DocumentEntry.formatCode=urn:ihe:iti:bppc:2007
notes		unclear how negative consents are really supported. If one points at a "OPT-OUT" policy, what goes into the Consent.provision[0].type? A "permit" seems wrong as you are not permitting "OPT-OUT". Yet a "deny" also seems wrong as you are not applying a double-negative --> NOT "OPT-OUT"

APPC - Advanced Patient Privacy Consents Profile

APPC could also be mapped similar in two additional variations. These variations leverage the fact that APPC is a profile of the XACML language, and thus is a rich language for encoding policy rules. Thus where Consent has a complex set of .provision.provision nesting, this would not be used. Rather the XACML encoding would be used. In this case the Consent is mostly a method for managing the consents and not for encoding the rules; that is that the rules would be encoded in XACML and managed as XACML encoding. Likely encoding that are pushed into the XACML engine and thus only externally referenced by each policy set unique identifier.

The two variations are:

• 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)

Performance

ALL of these and other solutions need careful design considerations to make access control decisions accurate and fast. This often means that these run time decisions are not processing the FHIR or XDS data, but rather each time a policy is changed, that change is pushed to the access control decision engine for ingestion into that engine's system.