A record of a healthcare consumer’s policy choices, choices or choices made on their behalf by a third party, which permits or denies identified recipient(s) or recipient role(s) to perform one or more actions within a given policy context, for specific purposes and periods of time.

Broadly, there are 3 key areas of consent for patients: Consent around sharing information (aka Privacy Consent Directive - Authorization to Collect, Use, or Disclose information), consent for specific treatment, or kinds of treatment, treatment and general advance care directives. consent for research participation and data sharing.

Unique identifier for this copy of the Consent Statement.

This identifier is identifies this copy of the consent. Where this identifier is also used elsewhere as the identifier for a consent record (e.g. a CDA consent document) then the consent details are expected to be the same.

Indicates the current state of this consent. Consent resource.

This element is labeled as a modifier because the status contains the codes rejected and entered-in-error that mark the Consent as not currently valid.

A classification of the type of consents found in the statement. This element supports indexing and retrieval of consent statements.

The patient/healthcare consumer patient, healthcare practitioner, research subject, or a group of persons to whom this consent applies.

Relevant time or time-period when this Consent is applicable. Date the consent instance was agreed to.

When Effective period for this Consent was issued / created / indexed. Resource and all provisions unless specified in that provision.

Either the Grantor, which is the The entity responsible for granting the rights listed in a Consent Directive or the Grantee, which Directive.

The entity responsible for complying with the Consent Directive, including any obligations or limitations on authorizations and enforcement of prohibitions.

In a fully computable consent, both grantee and grantor will be listed as actors within the consent. The Grantee and Grantor elements are for ease of search only.

The resource actor that identifies manages the actor. To identify a actors by type, use group to identify a set of actors by some property they share (e.g. 'admitting officers'). consent through its lifecycle.

Actions controlled by this The actor that controls/enforces the access according to the consent.

The organization that manages the consent, and the framework within source on which it this consent statement is executed. based. The source might be a scanned original paper form.

The source can be contained inline (Attachment), referenced directly (Consent), referenced in a consent repository (DocumentReference), or simply by an identifier (Identifier), e.g. a CDA document id.

The source on which this consent statement is based. The source might be a scanned original paper form, or a A reference to a consent that links back to such a source, a reference to a document repository (e.g. XDS) that stores the original consent document.

The source can be contained inline (Attachment), referenced directly (Consent), referenced in a consent repository (DocumentReference), or simply by an identifier (Identifier), e.g. a CDA document id.

The references to A set of codes that indicate the policies regulatory basis (if any) that are included in this consent scope. Policies may be organizational, but are often defined jurisdictionally, or in law. supports.

Entity or Organization having regulatory jurisdiction A Reference or accountability URL used to uniquely identify the policy the organization will enforce for  enforcing policies pertaining this Consent. This Reference or URL should be specific to Consent Directives. the version of the policy and should be dereferencable to a computable policy of some form.

The references to the policies A Reference that are included in identifies the policy the organization will enforce for this consent scope. Policies may be organizational, but are often defined jurisdictionally, or in law. Consent.

This element is for discoverability / documentation, While any resource may be used, Consent, PlanDefinition and does not modify or qualify the policy rules. Contract would be most frequent

A referece URI that links to the specific a computable policy. version of the policy the organization will enforce for this Consent.

If A Reference to the human readable policy reference is not known, the resource cannot be processed. Where explaining the reference is absent, there is no particular policy other than what is expressed directly in basis for the consent resource. Consent.

A set of security labels that define which resources are controlled by this consent. If more than one label is specified, all resources must have all Whether a treatment instruction (e.g. artificial respiration: yes or no) was verified with the specified labels. patient, his/her family or another authorized person.

Has the instruction been verified.

The context Extensible list of the activities a user is taking - why the user is accessing the data - that are controlled by this consent. verification type starting with verification and re-validation.

This element is for discoverability / documentation, and does not modify or qualify allows the policy (e.g. verification element to hold multiple use cases including RelatedPerson verification of the policy itself describes Grantee decision and periodic re-validation of the purposes for which it applies). consent.

Clinical or Operational Relevant period The person who conducted the verification/validation of time that bounds the data controlled by this consent. Grantor decision.

This has a different sense to the Consent.period - that is when the consent agreement holds. This is the time period of the data that is controlled by Who verified the agreement. instruction (Patient, Relative or other Authorized Person).

The resources controlled by this consent, if specific resources are referenced. Date(s) verification was collected.

Allows for history of verification/validation.

How the resource reference is interpreted when testing consent restrictions. Action to take - permit or deny - as default.

A reference to Alternate for the provision structure using the Permission resource. Only one of Permission and .provision may be used in a specific resource that defines which resources are covered by this consent. resource.

An exception to the base policy of this consent. An exception can be an addition or removal of access permissions.

Action to take - permit or deny - when the exception conditions are met. Timeframe for this provision.

The timeframe in this exception This is valid. the bound effective time of the consent and should be in the base provision in the Consent resource.

Who or what is controlled by this Exception. provision. Use group to identify a set of actors by some property they share (e.g. 'admitting officers').

How the individual is involved in the resources content that is described in the exception.

The resource that identifies the actor. To identify a actors by type, use group to identify a set of actors by some property they share (e.g. 'admitting officers').

Actions controlled by this Exception. provision.

Note that this is the direct action (not the grounds for the action covered in the purpose element). At present, the only action in the understood and tested scope of this resource is 'read'.

A set security label, comprised of 0..* security labels that label fields (Privacy tags), which define which resources are controlled by this exception. If more than one label is specified, all resources must have all the specified labels.

If the consent specifies a security label of "R" "R" then it applies to all resources that are labeled "R" "R" or lower. E.g. for Confidentiality, it's a high water mark. For other kinds of security labels, subsumption logic applies. Not all When the purpose of use tag is on the security labels make sense for data, access request purpose of use in this element (may define a narrower value set?). shall not conflict.

The context of the activities a user is taking - why the user is accessing the data - that are controlled by this exception. provision.

E.g. if When the purpose of use tag is 'research', then the operational context must be research, in order for on the consent to apply. Not all data, access request purpose of the security labels make sense for use in this element (may define a narrower value set?). shall not conflict.

The class of information documentType(s) covered by this exception. provision. The type can be a FHIR resource type, a profile on a type, or a CDA document, or some other type that indicates what sort of information the consent relates to.

Multiple types are or'ed together. The intention of the documentType element is that the codes refer to document types defined in a standard somewhere.

The resourceType(s) covered by this provision. The type can be a FHIR resource type or a profile on a type that indicates what information the consent relates to.

Multiple types are or'ed together. The intention of the contentType resourceType element is that the codes refer to profiles or document types defined in a standard or an implementation guide somewhere.

If this code is found in an instance, then the exception provision applies.

Clinical or Operational Relevant period of time that bounds the data controlled by this exception. provision.

This has a different sense to the Consent.period - that is when the consent agreement holds. This is the time period of the data that is controlled by the agreement.

The resources controlled by this exception, provision if specific resources are referenced.

How the resource reference is interpreted when testing consent restrictions.

A reference to a specific resource that defines which resources are covered by this consent.

A computable (FHIRPath or other) definition of what is controlled by this consent.

Constraining the expression type for a specific implementation via profile is recommended

Provisions which provide exceptions to the base provision or subprovisions.