Computable Consents and Overarching Policies

- 14 mins

Patient/consumer consents are defined and enforced in the broader context of a law, regulation, or organizational policy that defines their scope, authority, and limitations. In the access control literature, such policies are often referred to as overarching policies.

The FHIR consent resource enables codifying consent rules in the form of machine-readable and computable provisions. It also enables recording the overarching policy as the broader policy context for the consent *.

The overarching policy can also be used as a mechanism to abstract away portions of the consent rules that are common across all consents of the same type and avoid reiterating them in every consent instance. This also makes it possible to accommodate changes to an overarching policy without changing all of the consent instances that derive from it (more on this below).

Expressing Overarching Policies

If the overarching policy is not expressed in a computable form, the adjudication of consent decisions could not take place automatically; unless the overarching policy and its rules are hardcoded into the software logic. This makes it very hard to ship a consent decision service that is general enough to be configured (without re-coding) to work in different jurisdictions with different overarching policies. It is also very inefficient to accommodate any changes in the overarching policy since a software update would be needed. Thus, in order to acheive true computable consents, it is important to codify overarching policies in machine-readable computable form.

One major challenge at the time of writing is that FHIR does not have a native mechanism for modelling policies and there is no widespread consensus on an external policy language (e.g. XACML or ODRL) for doing so. Work is in progress in developing a Permission resource in FHIR that can capture access control rules more generally. But assuming there is some standard way of modeling overarching policies in FHIR, I will focus on the subsequent questions: how do we implement this in a consent decision service, and what are the implications?

Combining Decisions

How consent provisions should be interpreted vis-a-vis the overarching policy is itself a question for the overarching policy that defines the scope and context of the consent.

In some cases, and for some rules, individual consents can add further restrictions to the general policy or relax the restrictions in the general policy (consent overrides), and in some cases the overarching policy should prevail and override the consent provisions (rule overrides) when in conflict.

This is commonly known as the decision combining strategy or conflict resolution strategy in access control and rights management literature.

The overarching policy may contain more than one rule and each rule may stipulate a different combining strategy. For example, rule 1 may be overridden by the consent but rule 2 may not. I will show this in an examples below.

Processing Overarching Policies

In order to determine a consent decision, the consent decisions service (ConDS) must evaluate the request context against both the overarching policy and the consent provisions, and then somehow combine these decisions into one final decision according to the combining strategy. In other words:

For example, consider the following overarching policy (OP-1) that prohibits disclosure of substance use (ETH) information:

id: "OP-1":
  combining-strategy: "consent-overrides"
    DENY IF 
      securityLabel= "ETH"

And the following consent provision that permits disclosure of substance use (ETH) information to ProviderA for treatment purpose (this is perfectly codeable using the current FHIR Consent resource provisions but I am using a less verbose notation for brevity):

policyBasis: 🔗 OP-1
    recipient = "ProviderA" AND
    purpose = "TREAT" AND
    securityLabel= "ETH" 

If a request from ProviderA is received for this patient’s subtance use information, the overarching policy returns a deny and the consent provisions return a permit decision for this request. Based on the combining strategy expressed in the overarching policy, the decision from the consent prevails and the final decision will be permit.

If a similar request is received from ProviderB, the overarching policy will return a deny decision but the decision from the consent provisions will be not-applicable (since the recipient does not match the provision). Combining these two leads to a deny decision **.

When Overarching Policy Changes

The question of whether the overarching policy can change without re-approval by the patient/consumer is a legal one. Certainly, the custodian organization cannot change their agreed-upon terms unilaterally. But in some cases, such as jurisdictional rules backed by law, the overarching policy may change, effectively changing the effect of the rules for a certain type of consents and how they apply.

One example of such a change in the overarching policy is the easing of re-disclosure rules under US CURES Act (link thanks to Keith Boone) and the corresponding new rules. This change essentially allows re-disclosure of certain categories of sensitive information (e.g., substance use) for the purpose of treatment, payment, and healthcare operations, if the patient has consented to their disclosure once. In other words (or at least one possible reading is), that if the patient has consented to the disclosure of this information to a provider, the information can be disclosed to any provider (for those particular purposes).

Again, note that the question of whether or not consents captured prior to this change can be used for redisclosure is a legal question and I am only focusing on the technical mechanics here.

How would this work in consent evaluation?

The overarching policy has now changed and a new rule is added that allows disclosing substance use information if a consent exists permitting disclosure to any provider. Note that this rule references the consent resource attributes:

id: "OP-1":
combining-strategy: permit-overrides
  combining-strategy: "consent-overrides"
    DENY IF 
    securityLabel= "ETH" 

rule-2: //🚨 new rule
  combining-strategy: "rule-overrides"
      request.purpose="TREAT" AND
      consent.securityLabel= "ETH" AND consent.purpose = "TREAT"

Let’s examine what happens when the new overarching policy goes into effect:

As an implementation nuance, note that the decision engine should keep track of which rule from the overarching policy ultimately prevailed so that it can determine whether or not that rule can be overridden by consent provisions.

Another nuance is that in the discovery stage, when looking for all the potentially applicable consents to the request context, a wider net should be used since the overarching policy of the consent (as shown in the example above) could lead to a decision for a consent that is seemingly not applicable to the request context if considered purely based on provisions. In the above example, when the request is coming from ProviderB, the consent filed for permitting disclosure to ProviderA is applicable because of rule-2 in the overarching policy.


The following actors are involved in the process of consent enforcement:

The high level flow is as the following:

ConESConDSConDisSConSrequest (workflow context)request (workflow context)determine consent queriesconsent queryconsentsloop[ all consent stores ]determine applicable consentsapplicable consent(s)evaluate consent(s)loop[ all consents ]combine decision(s)decision (permit/deny + obligations + notes)ConESConDSConDisSConS

Summary and Conclusions:

(*) At the time of writing, the FHIR Consent resource has two mechanisms for recording the overarching policy:

(**) There is a more sophisticated way of evaluating this request that can produce a permit decision with an obligation to redact substance use information. I will address this in a future blog post.

rss facebook twitter github youtube mail spotify lastfm instagram linkedin google google-plus pinterest medium vimeo stackoverflow reddit quora quora