The FHIR Consent resource records a person's choices about who may perform which actions on which data, for what purpose and period. It does not enforce those choices. The specification says enforcement is not included and should come from access control mechanisms such as OAuth, UMA or XACML.
What Consent holds
According to the R5 page, Consent records choices made by a healthcare consumer, or on their behalf, that permit or deny named recipients or roles to perform actions for specific purposes and time periods. Three uses are anticipated: privacy, medical treatment and research consent. Only the privacy use case is fully modeled so far.
Status values are draft, active, inactive, not-done, entered-in-error and unknown. R5 removed proposed and rejected compared with R4 and R4B and added not-done and unknown, so check which version your server uses.
The permit and deny model
Consent.decision sets a base policy of permit or deny. Provision elements are exceptions to that base. They can add or remove permissions and can cover actors, actions, data, purposes, resource types and date ranges. In R5, decision moved from provision.type, so older code reading R4 structures needs a change.
Where enforcement happens
The page states that enforcement is not included and is expected to come from access control mechanisms such as OAuth, UMA or XACML. The resource can carry machine readable rules for a decision engine to evaluate, but the evaluation lives elsewhere.
The FHIR security page adds that patient sensitive resources are often controlled by a privacy consent, and that a consent based authorization server can decide which tokens and scopes to issue, with cascaded authorization.
A workable architecture
- Store Consent resources as the system of record for choices.
- At token issuance, have the authorization server check consent and limit scopes.
- At request time, have a policy enforcement point check the resource, purpose and requester against consent.
- Write an AuditEvent for each decision, including denials. See AuditEvent vs Provenance.
- Tag affected data with security labels so downstream systems know it is restricted. See what FHIR security labels can do.
Questions to settle before you build
Consent logic goes wrong most often because the policy was never written down. Before coding, answer these in plain language:
- What is the default when no Consent exists: permit or deny? Different data classes may have different defaults.
- Who can create, change or revoke a Consent, and how is a revocation propagated to caches and downstream copies?
- How are consents from a representative handled, such as a parent or guardian?
- Which purposes of use do you honor, and how do you verify the purpose a client claims?
The Consent decision field gives you the base policy mechanism, and provisions give exceptions. Your own rules decide what the base should be.
Common mistakes
- Treating the presence of a Consent record as if it blocked access.
- Checking consent on read but not on search, _include or batch requests, which the security page lists as access control considerations.
- Ignoring status, so inactive or entered-in-error records are still applied.
- Forgetting that consent for treatment is not consent for research.
Quick check
If I store a deny Consent, is the data protected?
Not by itself. Something in the request path has to read that Consent and refuse access. The resource is a record of the choice, not a control.
Sources
Last reviewed: 19 October 2026.
