The provision structure provides a mechanism for recording a computable policy natively within the Consent resource. This structure seems to have been designed to model exceptions to a general default decision (i.e., permit or deny) based on the required `policyRule` attribute. This attribute is tied to an extensible vocabulary that records various policies from different jurisdiction. While this works great for recording the base policy for legal/indexing purposes, it does not make it easy for the implementers of a computable consent engine to determine whether the default decision is permit or deny. In order to do that, the implementer needs to have a service to map every single value from the policyRule value-set mapped to a default decision and since this value-set is extensible, it is still possible that the consent decision engine will not be able to process a consent referencing a value from a different jurisdiction. This makes it extremely difficult to implement a consent processor capable of parsing and understanding the decision of a computable consent.

To facilitate creating and consuming reliably computable consents, implementers need an explicit and unambiguous mechanism to record the default decision. Note that this previously existed in the consent resource via the OPT-IN and OPT-OUT values.

Based on the above, we propose the following:

• providing a clear mechanism for the default decision via the `code` element in the zero-th provision.

*clarifying in the documentation that:

• • the policyRule attribute in the documentation is primarily intended for legal/indexing purposes and note that the creator of a consent must set the `code` element in the zero-th provision to ensure automatic enforcement.
  • creators of computable consent need to ensure that the value of 'code' in the zero-th provision is consistent with the policy code recorded in `policyRule`.
  • the implementers who intend to consume a computable consent modeled in the provision structure can only look at the `code` element of the zero-th provision to get the intended default consent decision.

As an aside, I think the `policyRule` should either be optional or include a generic value in order to allow creating consents that capture a simple patient preference without tying to a particular jurisdiction for respective use-cases.