The short answer
In FHIR R4, a Consent is “a record of a healthcare consumer’s choices, 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.”1 It’s structured as a base policy that is either opt-in or opt-out, followed by exceptions, called provisions, that can be positive or negative.1
The specification is explicit that enforcement of a privacy consent directive is not included; it expects enforcement through access-control methods such as OAuth, UMA or XACML.1 So a Consent resource on the server doesn’t stop an AI agent reading data the patient refused to share. Your agent’s tools, or a gateway in front of them, have to read the Consent and act on it.
This post covers records and access, not clinical decisions.
Deedglass
The server said “saved”. Deedglass looked.
Deedglass reads it back
What Consent covers
The R4 page lists four anticipated uses, and then narrows them:1
| Use | What it records | Modelled in R4 |
|---|---|---|
| Privacy consent directive | Agreement to collect, access, use or disclose information | Yes |
| Medical treatment consent directive | Consent to a treatment, or refusal | No, scoped only |
| Research consent directive | Consent to a research protocol and its information sharing | No, scoped only |
| Advance care directive | Instructions for potential future treatment | No, scoped only |
The resource is scoped to all four, but “at this time, only the privacy use case is modeled.”1 The resource is at maturity level 2, Trial Use, in R4.1 For agents that read or share records, privacy consent is the part that matters.
How a Consent is structured
The elements an agent’s tool needs to read:11
| Element | Meaning |
|---|---|
status |
draft, proposed, active, rejected, inactive or entered-in-error; only active should count |
scope |
Which of the four areas this covers |
patient |
Who the consent applies to |
policy / policyRule |
The base policy: opt-in or opt-out |
provision.type |
deny or permit, the exception to the base |
provision.period |
When the exception applies |
provision.actor |
Who it applies to, by role and reference |
provision.action, purpose, data |
What actions, for which purposes, on which data |
Exceptions can list data objects, authors, recipients, organisations, purposes of use and date ranges.1
A worked example
A patient’s privacy consent, in words:
- Base policy: opt-in. The care team may access the record.
- Provision 1, deny: no disclosure of records from a particular clinic to any external organisation.
- Provision 2, permit, with a period: an insurer may access claim-related records for the next 90 days.
Now an agent at the insurer asks to read records for a claim review. The tool has to check, in order:
| Check | Example question |
|---|---|
Is there an active Consent for this patient? |
If none, what does your policy say: refuse, or fall back to a documented default? |
| Does the base policy allow this kind of access? | Opt-in: only listed parties; opt-out: everyone unless excepted |
Does any deny provision match this actor, purpose and data? |
The clinic’s records are excluded |
Does a permit provision cover it, and is today inside its period? |
The 90-day window |
| Is the purpose of use the one the provision names? | Claim review, not marketing |
Only if all of that passes should the tool fetch the data. And it should fetch only the data the provision covers, not the whole record.
Enforcement is not included
The line from the specification bears repeating: enforcement of the privacy consent directive is not included, and is expected to be done with access-control methods (OAuth, UMA, XACML), including the detailed meaning of each element.1
Three consequences for agent builders:
- A FHIR server returning data doesn’t mean consent allowed it. Unless your server or gateway enforces Consent, it will return what the token’s scopes allow. Token scopes are a separate control; our post on SMART on FHIR v2 scopes covers them.
- The model must not be the one deciding. “Check consent before reading” in a prompt is advice to a system that can be steered. The check belongs in the tool code that runs before the read.
- Consent itself can be sensitive. The specification notes that consent to share is often itself something to protect, and that systems often work with partial representations of the full statement.1 Don’t hand the whole Consent to the model if a yes-or-no answer will do.
Where an agent should check consent
| Layer | Strength |
|---|---|
| In the system prompt | Weak: the model can ignore or be steered |
| In the agent’s read tool, before the request | Good: runs for every call the tool makes |
| In a gateway in front of the FHIR server | Better: runs for every client, not just this agent |
| In the FHIR server’s own access control | Best, if your server supports Consent-based enforcement |
Whichever layer enforces it, record the decision: which Consent, which provision, allowed or refused. That record is what you’ll want when someone asks why a read happened. FHIR’s own audit resources are one way to keep it; see FHIR AuditEvent vs Provenance.
A checklist
- Agent read tools look up the patient’s
activeConsent before fetching data. - Base policy,
denyandpermitprovisions, periods, actors and purposes all checked. - A documented default when no Consent exists.
- The tool fetches only data the consent covers.
- The model gets a decision, not the full Consent text.
- Every allow and refuse recorded with the Consent and provision used.
- Token scopes kept narrow as a separate control.
For what counts as protected health information, see the PHI glossary entry; for the standard itself, the FHIR entry. To see what the agents configured on your machine could reach, paste the config into the check page or run npx deedglass scan (how the grade works); to try tool-call rules in your browser, open the playground.
Written with AI assistance and checked against our claims register.