Consent Resource

The Consent Resource moves beyond binary 'opt-in/opt-out' flags to define a provision-based access control policy. Each provision specifies:

• Actor: The specific person, device, or organization authorized.
• Action: The operation permitted (e.g., read, collect, disclose).
• Purpose: The reason for use, bound to a PurposeOfUse value set (e.g., TREAT, HRESCH for healthcare research).
• Data Scope: The exact FHIR resources or clinical compartments covered. This granularity is essential for federated learning, allowing a patient to consent to their de-identified data being used for model training (HRESCH) while blocking direct clinical access.

Unlike a scanned PDF of a paper form, the Consent Resource is a machine-readable, computable object. It uses the FHIRPath expression language within the provision.code and provision.data elements to define complex rules. This allows a federated learning orchestrator to programmatically evaluate consent directives before aggregating local model updates. For example, a rule can be evaluated to exclude a patient's data from a specific research study if their consent has expired, ensuring dynamic, automated compliance without manual review.

The resource tracks the full lifecycle of an agreement through its status field:

• draft: The consent is being prepared.
• active: The consent is in force and must be enforced.
• inactive: The consent is temporarily suspended.
• entered-in-error: The record was created accidentally.
• rejected: The consent was refused. This state machine, combined with dateTime elements for the period of validity, allows federated systems to automatically expire access rights, ensuring models are never trained on data for which authorization has lapsed.

A Consent Resource does not act in isolation. It is designed to be the policy decision point that drives the application of FHIR Security Labels. When a consent provision is active, the system applies a corresponding security label tag to the target data. For instance, a consent directive restricting re-identification automatically applies a REDACT or SUBSETT label. In a federated learning query, the security label infrastructure reads these tags to filter the dataset before it ever leaves the local institution, providing a dual-layered privacy enforcement mechanism.

To establish a legally defensible audit trail, the Consent Resource links directly to the Provenance Resource. This connection records:

• Who captured the consent (the practitioner or system).
• When it was signed and verified.
• Why it was created (e.g., a specific research enrollment event).
• Witnesses to the signing process. For federated learning, this chain of custody is critical for regulatory audits, proving that a specific patient's data was included in a training round based on a valid, witnessed, and unaltered consent directive.

Consent Resources can be organized hierarchically to reflect organizational policies. A master consent can define a broad policy (e.g., 'permit use of de-identified data for all institutional review board-approved studies'), while a child consent can define an exception (e.g., 'except for psychiatric notes'). This scoping is managed through the Consent.policyRule and Consent.category elements. Federated learning systems can traverse this hierarchy to resolve conflicts, ensuring that the most restrictive, patient-specific directive always takes precedence over a general institutional policy.