Existing Wording: Throughout 6.4.1

Proposed Wording: Recommendations:

Delete "Policy Context" and replace with Consent Policy defined as: Specifies one of more consumer, organization, or jurisdictional policies upon which the Consent Directive is based and is to be enforced in this domain, and which may include foundational privacy principles such as FIPPS, GDRP, OECD, PIPEDA, Australian Privacy Act, Japan Personal Information Protection Act, and APEC. Any organizational and /or jurisdictional policies may limit the consumers policy choices about matters affecting the consumer including actions, such as clinical, research, or end of life care; information about such care; entities authorized to perform those actions; and the manner in which those actions are permitted to be exercised, such as allowed operations and purposes of use, and the obligations and prohibitions to which grantees to a consent directive must comply.

*Add a "Consent Statement" definition such as: An electronic representation of a Consent Directive, which has less than full fidelity to the legally binding Consent Directive from which it was "transcribed", that is used to provide

recipients with the full content representation they may require for compliance purposes, and typically include a reference to or an attached unstructured representation for recipients needing an exact copy of the legal agreement with which they must comply.

*Add a "Consent Metadata" definition such as: Consent content derived from a Consent Directive, which conveys the minimal set of information needed to manage consent directive workflow, including registration of active and revoked Consent Directives; query/response transactions by which interrogators ascertain whether they are authorized to share specific information governed under specific Consent Directives with one or more recipients by notification or in response to requests; and retrieval of the Consent Directive from its custodian. In addition, the derived Consent Directive information includes the Security Labels to inform recipients about specific access control measures required for compliance, e.g., for applying Security Labels to governed information being accessed or disclosed.

*Add a "Consent Form" definition such as: Human readable consent content describing one or more consumer, organizational, or policies related to actions impacting the grantor for which the grantee would be authorized or prohibited from performing, and the terms, rules, and conditions pertaining to the authorization or restrictions, such as effective time, applicability or scope, purposes of use, obligations and prohibitions to which the grantee must comply once the form is "executed" by means required, such as verbal agreement, wet signature, or electronic/digital signature, and becomes a Consent Directive.

Comment:

Throughout 6.4 front matter there is a munging of these five distinct consent concepts: Consent Policy, which is inappropriately termed Policy context; Consent Directive, which is used and defined; Consent Statement, which is used, but undefined; Consent Metadata, which is not used, so not defined, and is being confused with a Consent Statement; and Consent Form, which is not used, so not defined, and sometimes confused with "consent", "privacy statement", "Consent Statement", and "Consent Directive".

Consent Policy is called policy context and is defined as Any organizational or jurisdictional policies, which may limit the consumers policy choices, and which includes the named range of actions allowed. The definition is ok if it included a healthcare consumers policies, which would be the healthcare consumers policy choices if the consumer were on an equal footing to negotiate the Consent Directive, which a consumer is able to do to a large extent with respect to a PHR. However, this is not a context as in milieu of social norms; it is a specific set of policies, which must be explicitly acknowledged in the Consent Directive in order for it to count as an informed consent.

Consent Directive is adequately defined, but not used in the explanatory text where is should be. Instead the term "consent", "privacy statement", and "Consent Statement" are used as if synonymous.

The undefined term "Consent Statement" is used throughout the front matter but it's meaning is unclear because its usage overlaps with other consent concepts. In section 6.4.1.1 this term is first used in the statement: "It may be used to represent the Privacy Consent Directive itself, or a derived consent statement that is not the original Consent Directive." The distinction between "representing the Privacy Consent Directive itself" and being a derivative is important because exactly the same electronic capture of a Consent Directive may be legally binding in one context and not in another, or the electronic syntax and semantics may be insufficient to convey a legally binding Consent Directive content in any case, e.g., if there is no way in which to clearly indicate the governed information or include any type of signature. In addition, there are two types of Consent Directive derivatives, which are used for two entirely different purposes: Consent Statement, which represents a Consent Directive, but is not legally binding, and Consent Metadata, which includes the minimum necessary information necessary for a consent management workflow.

With respect to Consent Statements: A policy domain may accept a verbal or structured/unstructured/combination of both representative of the agreement between the grantor and grantee as constituting a Consent Directive. Another policy domain may consider this representation insufficient. That is the critical differentiator between a Consent Statement and a Consent Directive.

Support for representation of signature is a good example of this differentiation. While it's true that "Consent statements are often signed - either on paper, or digitally. Consent Signatures will be found in the Provenance resource (example consent and signature)", only a Consent Directive is signed in a manner deemed adequate by a policy domain. For example in the State of Minnesota, which adopted the Uniform Electronic Transaction Act that typically permits electronic signatures, only a wet signature on a Healthcare Directive Form is considered an executed Consent Directive, and specific rules about witnessing of that signature apply. According to a report to the Minnesota Legislature on the use of electronic "Representations of Consents", Epic Care Everywhere EHR does not permit the use of electronic signatures on its Consent Statements. Instead, paper copies of Consent Directives with wet signatures are used.

The definition of a Consent Statement must also differentiate between what such a statement connotes i.e., that it is a representation of a Consent Directive, and the concept of Consent Metadata. From the context of its use in the front matter, Consent Statement is described as an electronic representation that has less than full fidelity with a legally binding Consent Directive from which it was "transcribed". Consent Statements may be "lossy" due to the inability of the specification to support certain concepts or by design, reduced in contextual content to minimize transaction size of computable content, which humans are not expected to understand.

This contrasts with Consent Metadata, which is a purposely truncated subset of information "derived" from a Consent Directive. Consent Metadata is constrained to the minimum that the requester "needs to know" to manage a specific type of consent workflow, such as simply confirming authorization to share information governed by a consent directive with a particular party. Or it can be as robust as to include all Consent Metadata needed for all consent management workflows, which is typically provided when a custodian registers information about a Consent Directive it obtains and manages.

For example, a transcribed Consent Form such as represented with a v2 CON segment, may capture most but not all of the content of a Consent Directive, and may or may not be deemed sufficient to be legally binding; nevertheless, it may still contain more sensitive information than should be sent in a Consent Metadata exchange intended simply to trigger workflow. This idea is stated in the front matter, but attributed to Consent Statement and not Consent Metadata.

Consent management - particularly privacy consent - is complicated by the fact that consent to share is often itself necessary to protect. The need to protect the privacy of the privacy statement itself competes with the execution of the consent statement. For this reason, it is common to deal with 'consent statements' that are only partial representations of the full consent statement that the patient provided.

Summary:

Disentangle Consent Policy, Consent Directive, Consent Statement, Consent Metadata, and Consent Form.