FHIR Consent

The provision backbone element defines a tree of rules that govern access. Each provision specifies an action (e.g., disclose, collect, use) and a purpose (e.g., TREAT, HRE). Rules can be nested to create complex policies, such as denying access for marketing while permitting it for treatment. The engine evaluates these rules to produce a permit or deny decision.

Records the chain of custody for clinical data. While Consent defines the permission to share, Provenance tracks who created, modified, or transmitted a resource and when. Together, they establish a complete audit trail for compliance with regulations like HIPAA and GDPR. Provenance captures the agent, entity, and activity involved in any data lifecycle event.

Captures a discrete record of a security-relevant event in a system. When a Consent resource is applied to permit or deny access, an AuditEvent logs the actual access attempt, including:

• The agent who requested access
• The entity (resource) accessed
• The outcome (success or denial) This provides the evidentiary record proving that consent directives were enforced.

A framework for tagging resources with confidentiality codes, sensitivity categories, and handling caveats. Consent policies often reference these labels to define scope—for example, a patient may consent to share 'normal' records but restrict access to resources tagged with ETH (substance abuse) or PSY (psychiatry). Labels are applied using the meta.security element on any FHIR resource.

Defines the OAuth 2.0 scopes that authorize third-party applications to access specific FHIR resources on behalf of a user. Consent directives can be enforced at the authorization server level by mapping patient preferences to allowed scopes. For example, a patient's 'deny mental health sharing' consent translates to blocking the patient/Observation.rs?category=mental-health scope for external apps.

A resource representing a legally enforceable agreement between parties. While Consent captures a patient's privacy directive, a Contract formalizes the binding terms between an organization and a data recipient—such as a Data Use Agreement (DUA) or Business Associate Agreement (BAA). Contracts often reference the Consent resources that authorize the data exchange.

The actors referenced in a Consent resource. Organization identifies the custodian (e.g., a hospital) and recipients (e.g., a research institution). Practitioner identifies specific clinicians authorized or denied access. Consent provisions use references to these resources to define who is bound by the directive, enabling fine-grained, role-based access control.