A record of a healthcare consumer’s 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, and general advance care directives. Invariants Defined on this element ppc-1 Rule Either a Policy or PolicyRule policy.exists() or policyRule.exists() ppc-2 Rule IF Scope=privacy, there must be a patient patient.exists() or scope.coding.where(system='something' and code='patient-privacy').exists().not() ppc-3 Rule IF Scope=research, there must be a patient patient.exists() or scope.coding.where(system='something' and code='research').exists().not() ppc-4 Rule IF Scope=adr, there must be a patient patient.exists() or scope.coding.where(system='something' treatment and code='adr').exists().not() ppc-5 Rule IF Scope=treatment, there must be a patient patient.exists() or scope.coding.where(system='something' consent for research participation and code='treatment').exists().not() data sharing.

Unique identifier for this copy of the Consent Statement.

This identifier 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 selector classification of the type of consent being presented: ADR, Privacy, Treatment, Research. consents found in the statement. This list is now extensible. element supports indexing and retrieval of consent statements.

The patient/healthcare practitioner or group of persons to codes based on scope selection) whom this consent applies.

A classification of the type of consents found in Date the statement. This element supports indexing and retrieval of consent statements. instance was agreed to.

The patient/healthcare consumer to whom Effective period for this consent applies. Consent Resource and all provisions unless specified in that provision.

When this The entity responsible for granting the rights listed in a Consent was issued / created / indexed. Directive.

Either the Grantor, which is the entity responsible for granting the rights listed in a Consent Directive or the Grantee, which is the The entity responsible for complying with the Consent Directive, including any obligations or limitations on authorizations and enforcement of prohibitions.

Commonly, the patient the consent pertains to is the consentor, but particularly for young In a fully computable consent, both grantee and old people, it may grantor will be some other person - e.g. a legal guardian. listed as actors within the consent. The Grantee and Grantor elements are for ease of search only.

The organization actor that manages the consent, and the framework within which it is executed. consent through its lifecycle.

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

The source on which this consent statement is 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 references A reference to the policies a consent that are included in this links back to such a source, a reference to a document repository (e.g. XDS) that stores the original consent scope. Policies may be organizational, but are often defined jurisdictionally, or in law. document.

Entity or Organization having regulatory jurisdiction The source can be contained inline (Attachment), referenced directly (Consent), referenced in a consent repository (DocumentReference), or accountability for enforcing policies pertaining to Consent Directives. simply by an identifier (Identifier), e.g. a CDA document id.

A set of codes that indicate the regulatory basis (if any) that this consent supports.

The references A Reference or URL used to uniquely identify the policies that are included in policy the organization will enforce for this consent scope. Policies may be organizational, but are often defined jurisdictionally, Consent. This Reference or in law. URL should be specific to the version of the policy and should be dereferencable to a computable policy of some form.

This element is for discoverability / documentation and does not modify or qualify A Reference that identifies the policy rules. the organization will enforce for this Consent.

While any resource may be used, Consent, PlanDefinition and Contract would be most frequent

A reference URL that links to the specific base a computable regulation or policy. version of the policy the organization will enforce for this Consent.

If the policyRule is absent, computable consent would need A Reference to be constructed from the elements of human readable policy explaining the Consent resource. basis for the Consent.

Whether a treatment instruction (e.g. artificial respiration respiration: yes or no) was verified with the patient, his/her family or another authorized person.

Has the instruction been verified.

Who verified Extensible list of verification type starting with verification and re-validation.

This allows the instruction (Patient, Relative or other Authorized Person). verification element to hold multiple use cases including RelatedPerson verification of the Grantee decision and periodic re-validation of the consent.

The person who conducted the verification/validation of the Grantor decision.

Date verification was collected. Who verified the instruction (Patient, Relative or other Authorized Person).

An exception to the base policy of this consent. An exception can be an addition or removal of access permissions. Date(s) verification was collected.

Allows for history of verification/validation.

Action to take - permit or deny - when the rule conditions are met. Not permitted in root rule, required in all nested rules. as default.

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

The timeframe in Timeframe for this rule is valid. provision.

This is 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 rule. 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 actors by type, use group to identify a set of actors by some property they share (e.g. 'admitting officers').

Actions controlled by this Rule. 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 security label, comprised of 0..* security label fields (Privacy tags), which define which resources are controlled by this exception.

If the consent specifies a security label of "R" then it applies to all resources that are labeled "R" or lower. E.g. for Confidentiality, it's a high water mark. For other kinds of security labels, subsumption logic applies. When the purpose of use tag is on the data, access request purpose of use shall not conflict.

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

When the purpose of use tag is on the data, access request purpose of use shall not conflict.

The class of information documentType(s) covered by this rule. 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 rule provision applies.

Clinical or Operational Relevant period of time that bounds the data controlled by this rule. 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 rule 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

Rules Provisions which provide exceptions to the base rule provision or subrules. subprovisions.