Create a Consent resource with Consent.status set to active, Consent.scope set to patient-privacy, and Consent.category using LOINC code 59284-0 (consent document) or a more specific category code
Set Consent.patient to reference the Patient, Consent.dateTime to the consent signing date, and Consent.performer to the organization or individual who obtained consent
Define the default behavior using Consent.provision.type — use deny to default to denying all sharing unless explicitly permitted, or permit to default to permitting sharing unless explicitly restricted
Add nested Consent.provision.provision elements to represent specific permit or deny rules, scoping each by actor (who is affected), action (what activity), securityLabel (data sensitivity), purpose (treatment, research, etc.), or dataPeriod (time window of covered data
When a FHIR access request arrives, evaluate the Consent by matching the requesting actor and purpose against the provision tree and enforce the most specific matching provision's type
Known gotchas
FHIR Consent enforcement is not automatic — the FHIR server does not natively enforce Consent resources; the server or an intermediary must actively query and evaluate Consent before returning data, requiring custom implementation
Consent.provision nesting creates a tree where more specific (deeper) provisions override less specific (shallower) ones — a common mistake is placing a broad deny at a nested level that incorrectly overrides a more specific permit at the same depth
Consent for research versus treatment purposes requires different scope and category codes; conflating the two in a single Consent resource can lead to unintended data disclosure or incorrect access denials across different use contexts
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp