FHIR Permission Resource and Linked Permissions

The Permission resource was added to the R5 version of HL7 FHIR to provide a mechanism to express generic access control policies in an interoperable and computable fashion. This was in response to an increasing set of use cases that require formulating access control policy rules beyond the scope of the FHIR Consent resource. Unlike Consent, the Permission resource can model generic policy rules that are not specific to an individual patient or health record. Since Permission provides a more general mechanism to model authorization policies, it can also model consent policies and the current specifications allow modeling the consent rules by referencing a Permission resource, as an alternative to using the provision data structure within the Consent resource.

Aside from the common metadata, the Permission resource allows expressing a policy in the form of an array of rules (in the rule attribute). Each rule is based on a simple access control model that permits or denies some activity by an actor on some data.

Against a given context, each rule may evaluate to a permit, deny, or not-applicable decision. The combining attribute enables specifying a combining strategy that determines how to consolidate the decisions from different rules into a single final decision. For example, a deny-overrides combining strategy means that if any of the rules decides that access should be denied, that decision should prevail, even if other rules decide to permit access. This model (albeit simplified) is very similar to that of OASIS XACML.

One of the requirements currently not addressed by the Permission resource is the ability to link to other permissions in order to support modularization of policies. A simple example is to have different Permission resources for different purposes of use and linking them into a main policy.

Another example is to have a consent policy with the broad rule that denies sharing of substance use treatment data and a more specific rule that permits sharing this data with a particular actor. Since the broad rule will be common across many consents it can be modeled as a single Permission resource which is then referenced by the individual consent policies (each modeled as its own Permission) where more specific rules are articulated.

There has been discussions at the HL7 Security Work Group about the best way to model this in a Permission resource. My proposal is the following:

• Enable referencing another Permission resource from within an element in the rule array using a new attribute called import that holds a reference to a Permission resource.

• If this attribute is used, then no other attribute should be present in that rule element; in other words, each element in the rule array may either describe an access control rule or reference another Permission as shown in the figure below.

• The result of evaluating the referenced Permission will be combined with the decision from other rules in the array based on the decision combining strategy.

This will look like the following:

{
  "resourceType": "Permission",
  "id": "example",
  "status": "active",
  "validity": {
    "start": "2024-01-01"
  },
  "combining": "permit-overrides",
  "rule": [
    {
      "import": {
        "reference": "Permission/overarching"
      }
    },
    {
      "type": "permit",
      "data": [
        {
          //...
        }
      ],
      "activity": [
        {
          //...
        }
      ]
    }
  ]
}

In order to support a meaningful implementation of this feature, some semantic rules are also needed. The following is a starting draft:

• If the reference leads to an inactive or expired Permission, this should be interpreted as returning a not-applicable decision because the referenced permission is silent about whether access should be permitted or denied in the given context.
• A circular reference in processing linked Permissions should be treated as an error, leading to a not-applicable decision bubbling up from the Permission resource in which the circular reference was encountered.
• There should be a pragmatic limit on the length of the chain of linked Permission and the implementers should put reasonable guardrails against maliciously or erroneously large chains that could lead to draining of resources at the time of processing.

Tweet