Computable Consents and Overarching Policies

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:

• Fetch overarching policy
• Evaluate the request against the overarching policy
• Evaluate the request against consent provisions
• Combine the decisions from overarching and provisions based on the decision combining strategy.

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

id: "OP-1":
rule-1:
  combining-strategy: "consent-overrides"
  rule: 
    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
provisions:
  PERMIT IF
    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
rule-1:
  combining-strategy: "consent-overrides"
  rule: 
    DENY IF 
    securityLabel= "ETH" 

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

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

• Consider a request from ProviderA for substance use information for treatment purpose; rule-1 outputs a deny decision, and rule-2 leads to a permit decision. These two decisions are combined based on the combining strategy for the policy which leads to the permit decision prevailing. This decision should override the decision by the consent provisions so evaluating the consent provisions will not be necessary after this step.

• A similar request from ProviderB will also similarly lead to a permit decision (despite consent provisions).

• Now, consider a request from ProviderC for substance use information for the purpose of marketing. In this case, rule-1 will lead to a deny and rule-2 will lead to a not-applicable decision (since the purpose of use does not match) leading to an ultimate deny decision. Note that based on the combining strategy of rule-1 this decision could potentially be overridden by the consent provisions if a provision exists that permits disclosing substance use information for marketing purposes to ProviderC.

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.

Flow

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

• Consent Enforcement Service (ConES): the service in charge of capturing the workflow context for a requested action and subsequently enforcing the consent decision in the workflow.
• Consent Decision Service (ConDS): the service in charge of determining whether a given requested activity should be permitted (and subject to what conditions) based on consent policies.
• Consent Discovery Service (ConDisS): the service in charge of finding all applicable consents to a request.
• Consent Store (ConS): A server (e.g., FHIR) where consents are stored.

The high level flow is as the following:

• The Consent Enforcement Service (ConES) identifies a pending request in a workflow where consent should be enforced. It captures the context of the workflow (e.g., patient/consumer in question, purpose of use, requested information, etc.) and formulates a consent decision request and sends it to the the Consent Decision Service (ConDS).
• The ConDS forwards the request context (potentially with additional contextual attributes) to the Consent Discovery Service (ConDisS).
• The ConDisS analyzes the request and invokes queries to various Consent Stores (ConS) where consents may reside.
• The ConDisS collects the responses from various Consent Stores and examines them to create a bundle of consents that are applicable to the request and sends it back to the ConDS.
• The ConDS evaluates the request against each consent and records individual decisions. This is where the discussion in this blogpost is relevant.
• If there are more than one applicable consents and therefore more than one decision, the ConDS uses a combining strategy to make one final decision.
• The decision is sent back to the ConES. The decision may include obligations and advices aside from an authorization decision to permit or deny the action.

Summary and Conclusions:

• Fully computable consents need to rely on computable overarching policies that are expressed in a machine-readable way and can be evaluated automatically.
• Being able to expressing decision combining strategy at the policy and rule level is an essential requirement for any language used for codifying overarching policies.
• Evaluating overarching policies requires access to the full context of a request and the consent in question.
• Applicable consents needs to be discovered and collected with a broader net than the narrow scope of the request since overarching policies may make more general decisions that go beyond the scope of the consent provisions.

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

• regulatoryBasis which is a code that captures the law or regulation that governs the consent and its enforcement, and
• policyBasis which is a reference or link to a computable version of 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.

Tweet