13 May 2020 - Mohammad Jafari
One of the most significant parts of the Consent resource is to capture and record the preferences of the patient in the form of rules that specify under what conditions access must be denied or granted to the patient data. While the Consent resource currently supports referencing an external artifact that encodes such rules (using the
policy attribute), the native mechanism for expressing and encoding rules is the use of
provision attribute. Provisions capture the core logic of the rules that apply to the use of the patient’s data, and therefore, defining clear and unambiguous semantics for them is crucial in correctly capturing the patient’s preferences and enforcing them as intended. In other words, by ensuring that:
Figure 1 shows an overview of the current provision model in the Consent resource:
Figure 1. Current Model for Provisions in the Consent Resource
denyas well as overall applicable conditions such as validity period.
denyor vice versa).
Figure 2 shows a (hypothetical) example for this model. These provisions articulate that during the time period from 01/01/2020 to 31/12/2022, all access is permitted except:
Figure 2. An example set of rules modelled using the current provision model
Aside from the ambiguities and inconsistencies in the current specifications and the accompanying examples, the experience of implementing the current provision model revealed a number of serious problems with the current design.
The current provision structure is inherently complex: it is a tree with (theoretically) unlimited height and branching factor which can lead to exponential complexity as the number of provisions and the paths in the tree grows. Note that this complexity does not lead to more expressiveness, compared to a simpler, flat structure (proposed further below).
Because of this complexity, the nuances and side-effects of the rules and their arrangement in the tree is not very straightforward and there could be a lot of pitfalls. This makes the structure error-prone, both at the time when human users translate rules from a paper form (or their mind) into a provision tree, as well as when a machine reads and interprets it.
For example, consider the structure in Figure 3; it looks very similar to the example policy in Figure 2 but it has subtle differences. For example, the former would allow
Org1 to access anything for the purpose of
HLEGAL, but the latter does not. This nuanced difference lies in the layering of the tree in a way that is not obvious and intuitive and can be pitfall in policy authoring.
Figure 3. Another provision structure, similar to that of Figure 2 but with important differences
As will be discussed below, while the current structure does not prevent conflicts, it does not provide an explicit mechanism for conflict resolution either. Since the matching takes place by traversing down the tree structure, it is not impossible for more than one path to match a request. For example, consider the structure of Figure 4. If
Org1 requests access to
Claims for the purpose of marketing (
HMK), there will be a conflict. One branch denies any access for the purpose of marketing while another branch permits access for marketing purposes to
Org1. It is not clear how such conflicts should be resolved and the current model provides no mechanism to specify this. Some possible resolutions could be:
These are all poor choices since they are left to implications, and therefore, increase the risk of errors, unintended consequences, and poor interoperability because of the risk of different assumptions by interacting parties. Even if one of these alternatives is codified in the specifications, errors, both in modelling rules and in implementing the rule processor software are likely.
Figure 4. A provision structure that could lead to conflicting decisions
type attribute that enables each nested provision to specify a
permit decision currently seems superfluous; if provisions at each nested level are an exception to the previous level, the decision is implicitly the opposite of the decision of the previous level (as shown in the examples above). So it is not clear how the value of this attribute should be interpreted in nested provisions.
Because of these issues, we propose an alternative model of provisions based on a much simpler structure with a more explicit mechanism for conflict resolution. Figure 5 shows an example.
The provisions are organized in a single flat array with no nesting and a new attribute
onConflict records the expected behaviour if the decision from some provisions are inconsistent with others. A basic value set for this attribute can be:
denyOverrides, indicating that when in conflict, a decision to deny must prevail,
permitOverrides, indicating that when in conflict, a decision to permit must prevail,
firstMatchOverrides, indicating that the first decision, based on the order of provisions in the array, must prevail, and
invalid, indicating that the author’s intention has been to avoid conflicts, so, if a conflict occurs the Consent resource must be considered invalid.
Figure 5. An example for the proposed provision structure
This structure is much easier to understand by human users and policy authors, leads to a less complicated evaluation algorithm, and is consistent with the best practices of existing policy languages, such as XACML and ODRL.