Short answer: model consent as a state transition with a category gate, a bounded grant, and an append-only withdrawal record; never let a successful login imply permission to read health data.
A property-management application makes this concrete. Its forgot-password endpoint may verify a tenant identity, but that proof says nothing about permission to read a medical accommodation document. The recovery flow and the consent service should share identity primitives while keeping authorization decisions separate.
The decision record: what must remain true
The invariants are deliberately boring. Every grant names a data category, purpose, actor, issuer, and expiry. Every read checks the current grant and the latest withdrawal event. A revoked grant must fail closed even when a cached access token has minutes left. The audit trail records the decision inputs, not the health payload itself.
The failure boundary matters: a consent database outage should block a protected read, while an outage in the audit sink should not silently turn an allowed read into an untraceable one. Queue the audit event durably, mark the request for review, and define the maximum delay your regulator and incident process can tolerate. I am not sure one number fits every jurisdiction; your privacy counsel has to set that service-level objective.
| Option | Strength | Cost or boundary |
|---|---|---|
| Inline consent check | Fresh decision on every read | Adds latency and dependency pressure |
| Token-embedded scopes | Works during dependency loss | Revocation waits for token expiry or introspection |
| Local policy cache | Predictable latency | Staleness must have a measured, enforced limit |
Use a hybrid when reads are frequent: short-lived scopes plus an online revocation check for sensitive categories.
How should health data consent category checks, grants, and revocation interact?
Treat category checks as a policy function, not a string comparison scattered through handlers. “Lab result,” “diagnosis,” and “billing metadata” should have stable identifiers, data owners, and purpose constraints. A grant for one category cannot widen itself because a downstream service asks for a broader field set.
The critical path can stay small and explicit. This Python sketch uses generic interfaces so the policy remains portable across storage engines and identity providers:
from dataclasses import dataclass
from datetime import datetime, timezone
@dataclass(frozen=True)
class ConsentGrant:
subject: str
category: str
purpose: str
expires_at: datetime
grant_id: str
def can_read(grant, subject, category, purpose, revoked_ids, now=None):
now = now or datetime.now(timezone.utc)
if grant is None:
return False
if grant.subject != subject or grant.category != category:
return False
if grant.purpose != purpose or grant.expires_at <= now:
return False
return grant.grant_id not in revoked_ids
The production version should evaluate issuer, tenant, legal basis, and policy version as well. Store a hash of the policy inputs in the decision event so an auditor can reproduce why a request was allowed without duplicating protected content.
Failure modes that look like successful authentication
The common bug is semantic: a password reset proves control of an account, then a service treats that event as consent. Another is a category alias introduced during a migration; “genetic” and “genomics” accidentally map to different policies. A third is clock skew that extends a grant past its stated expiry.
Short denial.
The race deserves a concrete test. Suppose a clinician request starts at 10:00:00 with a valid grant, the subject withdraws consent at 10:00:01, and the read reaches a replica at 10:00:02. A design that checks only the cached grant returns data even though the authoritative timeline says “withdrawn.” A design that checks the revocation watermark rejects the read, emits a decision event, and lets the caller retry after the replica catches up. That extra branch is awkward to explain in a happy-path demo, but it is the difference between an audit trail and a log full of plausible stories. Keep the watermark per category, expose its age as a metric, and make the maximum tolerated staleness an explicit policy value rather than an undocumented cache setting.
Test these as adversarial cases. Send a replayed reset token, race a read against revocation, submit an unknown category, and advance clocks across daylight-saving boundaries. In one review I found an HTTP 200 response carrying an empty document after revocation; clients interpreted it as “no records,” masking an authorization denial. Return a typed denial and keep the payload absent.
Observability needs privacy discipline. Log subject and grant identifiers, policy version, decision, and correlation ID; redact names, diagnoses, and raw tokens. Alert on spikes in denied reads, repeated reset requests, and grants issued outside normal operator hours. Metrics are useful only when their labels cannot reconstruct a patient.
Embedding a year-long consent scope in a bearer token is attractive because it removes a database call. I reject it for high-risk categories: revocation becomes eventual, and incident response cannot guarantee containment. It is acceptable for low-risk, non-health profile preferences where a documented delay is harmless and token rotation is operationally reliable.
The catch is operational ownership. A small team may not be able to run online introspection, durable event storage, key rotation, and clock monitoring 24/7. In that case, narrow categories, shorter grants, and a managed identity system can be safer than a bespoke policy engine. Keep the design you can test during an incident.
Top comments (0)