- Both GDPR and HIPAA make withdrawal of consent a legal right, and GDPR adds that withdrawing must be as easy as consenting — a bar most systems fail.
- A real revocation does three things: stops future data provisioning quickly, leaves the audit history intact, and is honest that published aggregates cannot be recalled.
- Revocation fails in practice when data has already been copied out in bulk; consent checked at query time, with no bulk exports, is what gives a 'no' teeth.
- Per-study, scope-limited consent makes revocation precise: there is a specific grant to switch off, and a specific study that stops receiving data.
On this page
Somewhere in your settings history is a checkbox you ticked in 2019. You no longer remember the app, the study, or the sentence above the box. The permission it created is still alive, still working, somewhere — and if you wanted to take it back today, you would not know where to begin.
Now try the inverse experiment on any system that holds your health data: find the button that un-consents. Time how long the "no" takes compared with how long the "yes" took. That ratio is the most honest measurement of consent ever devised, and most systems fail it by orders of magnitude.
Consent as an event vs. consent as a state
Most of what gets called consent is an event: a signature, a tap, a moment — after which the data flows on its own momentum, indefinitely. The tick-box gets you through the gate, and then the gate is welded open.
Real consent is a state: a standing grant that is continuously true and can become false. The difference sounds philosophical until you ask an operational question — "if this patient said no right now, what exactly would stop, and when?" — and watch the room go quiet. Biobank-style broad consent, where one signature covers unlimited future studies, sits at the event end of the spectrum; per-study consent sits at the state end, and we compare them in broad consent vs. dynamic consent.
What the law already requires
Revocability is not a boutique ethical preference. It is written into both major regimes.
Under the GDPR, consent that cannot be withdrawn was never valid consent at all. Article 7 gives the data subject the right to withdraw at any time, states that withdrawal does not affect the lawfulness of processing already done, and then sets the bar that most real systems miss:
It shall be as easy to withdraw as to give consent.
The European Data Protection Board presses the point in its consent guidelines: consent obtained in one click should not demand a phone call, a letter, and a six-week wait to undo. For health data — special-category data under Article 9 — the stakes of getting this right are higher still, as we cover in GDPR and health research.
HIPAA arrives at the same place for research authorizations: under the Privacy Rule, an individual may revoke an authorization at any time in writing, effective for everything except actions already taken in reliance on it. The HHS HIPAA materials and the research pathway around §164.508 — which we walk through in HIPAA and research — both treat revocation as a built-in property of a valid authorization, not an add-on.
Notice what both regimes agree on: revocation points forward. The law does not pretend the past can be unprocessed. That honesty is the template for what a real revocation should do.
The three honest properties of a real revocation
A revocation worth the name does exactly three things — no more, and crucially, no less.
It stops future provisioning, fast. From the moment of revocation, no new data flows to the study; the next query, the next dataset refresh, the next provisioning event excludes the patient. Speed is the integrity test: a no that takes effect in weeks while a yes took effect in seconds reveals which answer the system was built to hear.
It leaves the audit intact. Revocation must not erase the history of what was accessed while consent was valid — that history is the patient's evidence, the regulator's evidence, and the platform's accountability. The right mental model is a ledger, not a whiteboard; what append-only machinery looks like is the subject of what a real audit trail looks like. Revocation itself should be written to that same ledger as a first-class event, timestamped, with effects traceable from it.
It does not claw back published aggregates. If a study already published that a treatment helped 40% of a 3,000-patient cohort, your revocation cannot subtract you from a percentage in a journal — and a system that promises otherwise is lying. Aggregates that protected you on the way out (no individual rows, minimum cohort sizes) do not endanger you by remaining published. The honest promise is precise: nothing new flows; nothing true is erased; nothing aggregate is recalled.
| A real revocation | What it never promised | |
|---|---|---|
| Future data provisioning | Stops, at consent-check speed | — |
| In-flight study refreshes | Patient excluded from the next pull | Rewriting datasets already lawfully delivered |
| Audit history | Preserved, append-only, revocation logged | Erasing the record of valid past access |
| Published results | Stand | Un-publishing aggregate statistics |
Why most systems can't actually do this
The gap between the legal right and lived reality is architectural. If a platform's model of data sharing is bulk export — a CSV leaves the building, a copy lands in a sponsor's environment — then revocation is reduced to an email asking nicely. The copy is out; no switch exists.
Three design choices create the switch. Consent checked at query time: every data access re-asks "is this grant still valid, right now?" — so revocation takes effect at the very next access, automatically. No bulk hand-offs: when queries run where the data lives and return aggregates only, there is no orphaned copy for a revocation to chase. Per-study scope: when each study holds its own narrow grant, revocation has a precise target — this study stops, that one continues if the patient wishes — instead of one giant lever wired to nothing.
None of this is exotic engineering. It is simply engineering that takes the "no" as seriously as the "yes" — and it is rare because most systems were funded to optimize the yes.
How Mithras builds the no
Mithras Health — a patient-mediated research-data platform for chronic disease, currently pre-launch — treats revocability as the property the rest of the consent design hangs from. Every study receives a separate, scope-limited consent, made as one decision across two documents — a plain-language summary and a formal authorization, a design we detail in two documents, one decision — and revocable at any time. Consent is evaluated in the access path itself, so a revocation is effective at the next query, not the next quarterly reconciliation.
And revocation is recorded the same way consent was: as an event on an append-only, cryptographically anchored audit trail, retained for six years. The patient can see what was accessed while the grant was alive, and exactly when the grant died.
The 2019 checkbox is worth a last look. The reason it haunts is not that you said yes — you may well have meant it. It is that the yes outlived your memory of giving it, with no living connection back to you. Consent that cannot be revoked is not a decision you made; it is a decision you used to be able to make. The whole point of building revocation properly is to keep the decision yours for as long as the data is.
Appendix · questions
Questions, answered
Can I withdraw consent after my health data is used in research?
What happens to my data in a study after I revoke consent?
Why doesn't revocation delete everything about me?
How fast should consent revocation take effect?
The sun is rising on chronic-disease research.
One email when we launch — and nothing else. Patients, researchers, sponsors, and programs all start here.
Mithras