Existing Wording: The Consent resource is structured with a base policy which is either opt-in or opt-out, followed by a listing of exceptions to that policy. The exceptions can be additional positive or negative exceptions upon the base policy. The set of exceptions include a list of data objects, list of authors, list of recipients, list of Organizations, list of purposeOfUse, and Date Range.

Proposed Wording: Recommendation: Put the core elements at the top level of the Consent Resource, as is done in the FHIR Consent Directive so that basic opt-in or opt-out as well as implied/assumed basic consent directives, which are not explicitly consented to, can be supported. Specifically, add Consent.actor, Consent.action, Consent.data, and a Consent.securityLabel.

Comment:

The structure described in 6.4.3, which reflects the actual model in 6.4.4, has a fatal flaw. If a base consent policy is either opt-in or opt-out without any exceptions, which the ONC Patient Choice Project defines as a Basic Consent, then this structure cannot represent absolutely core elements of any basic consent. Specifically, this structure cannot convey which actor playing a specific role can take what privacy action, e.g., disclose, on what type or instances of information governed by a Basic Consent Directive privacy rules to which the actor must comply, which are encoded privacy tags in a security label, e.g., confidentiality code and purpose of use. That is because there has to be an exception in order to value these elements.

This is not a problem with the FHIR Consent Directive, which contains all of those core elements at the "top level" for a basic consent, and this can be "excepted" at the term level as authorizations permitted in an opt-out consent or restrictions on an opt-in consent with the same core elements that are required for consent sub-rules/terms.

Summary:

FHIR Consent Resource fails to support some of the most prevalent types of consent directives