BPPC could apply to any topology of exchange. The reality is that BPPC is only ever needed when ONE organization captures consent that applies to ANOTHER organization.
When no need to expose Privacy Consent
Authorizing HIE Disclosure
In this case the Privacy Consent that the organization captured is not useful for others to see. The other actors in the HIE ask for data, which they either get or not. There is little that asking organization/individual can do to change the decision.
These are why there isn’t much actual use of consent in HIE’s; because it is eventually realized to be a local matter.
When Privacy Consent is managed in the HIE
The special cases might be broad cases, like any normal (Role-Based-Access-Control) for Treatment and Billing. This can be addressed by BPPC through an identified Patient Privacy Consent Policy, that the patient has agreed to. This enables the simple go or not case.
The special cases are where the consent is actually a set of specific ‘use’ instructions. That is that it is a policy that is not a simple authorization to release under normal Role-Based-Access-Control; but an authorization to release with conditions (constraints). --- Note, there is IHE work going on right now to address this, going beyond BPPC.
When Privacy Consent is sent to the Requesting PartyA targeted case is where there is a need to carry the evidence of consent (authorization to release) along with the documents being released. In this case the BPPC document is not there for enforcement, but rather simply as a Document of Consent. This might be more useful when the Privacy Consent can carry more exacting rules than BPPC, so we might see this show up more with the new work in IHE on "Advanced Patient Privacy Consents" (or whatever it ends up being named).
So the case for BPPC use with XDR, XDM and Direct; are less obvious. But they tend to fall into this last set of use-cases. This was the point of the blog article. The point is that there already is little need to communicate a Privacy Consent document, but where one does a PUSH through XDR, XDM, or Direct; one would only need it a fraction of the time.
Other ModelsI am not trying to express all the models in one blog article. The point of the article was to show when a Privacy Consent document would need to be communicated in a PUSH transaction.
There are other models that are supported by Privacy Consent documents like BPPC. Such as where the Requesting Party is the one that has gathered the Privacy Consent (authorization to release to the requesting party). This use-case is used by some payers that need to express that they have gotten explicit authorization from the patient. Another use-case might be where a patient has authorized unusual access, such as when they are getting care in a different country or where they are authorizing a clinical research project.
There are models where the Privacy Consent registry is an independent agent. There are various models that put the patient at the center of the Control. In some of these models the patient gets to choose from a set of Privacy Consent registries, the one that they want to use to control their rules. This is the center of some usecases in HEART using User Managed Access (UMA). This is a very exciting concept. I am participating and expect it will produce useful specifications. This however is very radical, so I expect it will take many many years before we see this in the wild. I thus expect many years of overlapping solutions.
IHE did develop BPPC to be re-usable... More blog articles Patient Privacy Controls