---
title: "Consent and disclosure"
description: "Consent that is granular, revocable, recorded and re-asked, and the difference between a lawful basis for processing and a person's actual understanding."
url: "https://opsinjs.pensievelabs.org/health/consent-and-disclosure"
source: "https://opsinjs.pensievelabs.org/health/consent-and-disclosure.md"
section: "Health"
kind: "health"
evidence: "mixed"
reviewed: "2026-09-02"
reviewer: "design"
aliases: ["withdraw consent", "privacy notice"]
implements: ["consent-sheet", "care-card", "disclaimer-note", "term", "field", "log-sheet"]
---
> Elements written as `` below are opsinjs documentation
> components. Their attributes are the content: the values they render are
> generated from `tokens/*.json` and `registry/catalogue.ts` and are
> published separately at https://opsinjs.pensievelabs.org/r/index.json and under the Reference
> section.
> Nothing is missing from this page. The data simply does not live in
> the prose.
## What this means [#what-this-means]
Health data is a special category of personal data under the UK GDPR and the EU
GDPR, and this page governs the interface through which a product asks for
permission to process it, records the answer, and lets the reader take the
permission back. The screen this page is written against is the one carrying a
wall of text, a single checkbox, and a button that is the only way forward.
That screen is built to produce a record that someone agreed. The record it
produces does not evidence informed agreement, because a reader who has scrolled
past a wall of text to reach the only button cannot afterwards name the
processing they accepted. Once that reader discovers a use they did not expect,
every other permission the product holds is open to the same doubt.
The twelve requirements below carry two different kinds of authority. Five of
them restate, in interface terms, conditions that the UK GDPR and the EU GDPR
place on consent as a lawful basis; four are design judgement that opsinjs holds
and argues for under "Why (evidence)". The *Basis* column records which of the
two applies, row by row, and is empty where neither has been assigned.
## The rule [#the-rule]
**Consent is per purpose, asked in context, expressed in plain language,
revocable where the data appears, recorded with its version, and re-asked when
the purpose changes.**
| # | Requirement | Where it appears in the interface | What is recorded | Basis |
| -- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------- | -------------------------------------------------------- | ------------------------------------------------------------- |
| 1 | One decision covers one purpose, and purposes are never bundled into a single question. "Store my readings", "share with my GP", "use my data to improve the app" and "send me health tips" are four different questions with four different answers. | At the point the purpose first arises | One record per purpose | Statutory (UK GDPR, EU GDPR) |
| 2 | Consent is asked at the point the feature that uses the data is used, rather than during onboarding. Location is requested when the feature needing it runs, not on the second screen of setup. Consent given before the reader knows what the app does is not informed. | At first use of the feature | | Design judgement |
| 3 | Every field collected is asked for against a stated purpose, no field is collected without one, and that purpose is shown where the field is asked for. Collection "for future use" names no purpose and does not meet this requirement. | Beside the field, or on the permission request | | Design judgement |
| 4 | The wording names the recipient, the data and the reason, in plain language: "so your GP can see your blood pressure readings in your record" rather than "to improve your experience". See [Plain-English A to Z](../content/plain-english-a-z.mdx). | The body of the consent request | The wording shown, under the version identifier in row 8 | Statutory (UK GDPR, EU GDPR) |
| 5 | Declining a secondary purpose leaves every primary function available and takes no more effort than accepting. No box is pre-ticked, consent is never carried by a Continue button, and the accept and decline controls have equal visual weight. | Both controls on the consent request | | Statutory (UK GDPR, EU GDPR) |
| 6 | A control that withdraws consent sits on the screen showing the data, rather than only in a settings sub-page. | The data screen, next to the disclosure in row 10 | | Statutory (UK GDPR, EU GDPR): withdrawal is as easy as giving |
| 7 | The consequences of withdrawal are stated before the reader withdraws, in the four parts set out below. | The withdrawal control, before the reader confirms | | |
| 8 | The record stores what was agreed, when it was agreed, and against which version of the wording. | Not on screen; the record is a data-layer obligation | Purpose, decision, timestamp and wording version | Statutory (UK GDPR, EU GDPR) |
| 9 | A purpose that changes materially is asked again as a new consent, and the request names what has changed. | A new request, at the point the new purpose first applies | A second record, under the new wording version | |
| 10 | Sharing is disclosed wherever the shared data is visible, rather than once at the moment of consent. The words "your GP can see this" belong on the data screen rather than in a policy document. | | | Design judgement |
| 11 | Sexual health, mental health, reproductive health, substance use, HIV status and genetic data are asked for separately, stored separately, and displayed under [On-screen privacy](./on-screen-privacy.mdx), because disclosure of any of them carries consequences outside the app. | A separate request; the display rules apply on every screen showing the data | | |
| 12 | The interface does not assess whether the reader understands what they are agreeing to. The wording is written so that misunderstanding is unlikely, rather than so that agreement is likely. | | | Design judgement |
Four of the twelve rows produce a stored artefact, and the other eight are
requirements on what is on screen at the moment of asking. Rows 7, 9 and 11 carry
no entry under *Basis*, because "Why (evidence)" classifies nine of the twelve
rules and does not classify those three.
### What the reader is told before withdrawing [#what-the-reader-is-told-before-withdrawing]
Row 7 covers four separate facts, and a withdrawal statement that omits any one
of them leaves the reader deciding without it. The third column below works those
four parts through a consent to share blood pressure readings with a GP surgery,
which is the third pair under "Applying it".
| Part of the statement | What the reader learns from it | In the GP-sharing example |
| --------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------- |
| What stops | The processing that ends at the moment of withdrawal. | No new readings are sent to the surgery. |
| What is deleted | The data removed as a consequence, and where it is removed from. | Nothing is deleted; withdrawal ends the sharing rather than reversing it. |
| What is kept | The data that remains after withdrawal, and the reason it remains. | The reader's own history in the app is unchanged, because that history was never the subject of this consent. |
| What cannot be undone | The part of the decision that withdrawal does not reach. | The GP keeps the readings they have already seen. |
## Why (evidence) [#why-evidence]
**Statutory requirements.** In the UK and the EU, data about health is a
special category under the UK GDPR and the EU GDPR, with additional conditions
on processing, and consent as a lawful basis has statutory requirements: freely
given, specific, informed, unambiguous, and as easy to withdraw as to give.
Rules 1, 4, 5, 6 and 8 restate those requirements in interface terms. The
binding sources are the legislation itself and the current guidance of the
implementing organisation's regulator; this page names the frame and does not
summarise the law.
Consent is also frequently not the right lawful basis for direct care. An
interface may need to explain a use without asking for consent to it, and a
consent request for processing that will proceed regardless misrepresents the
decision as optional. Which lawful basis applies is a question for the
implementing organisation's data protection lead.
**Opinion.** Rules 2, 3, 10 and 12 are design judgement. Rule 2 trades a tidy
onboarding for comprehension, at a cost in conversion that is real and that we
have not measured; we think the trade is right and we accept that it is a
trade. Rule 12 holds that no consent interface can establish understanding, so
the wording is written to make misunderstanding unlikely rather than to make
the record thorough enough to shift liability.
What would change our mind: the statutory rules are not contingent on any
evidence this page could gather, so nothing we could observe would revise rules
1, 4, 5, 6 and 8. On rule 2, evidence that contextual permission prompts
confuse users more than a single upfront explanation would make us reconsider
the balance.
## Applying it [#applying-it]
"Share your blood pressure readings with your GP surgery? They will see the
readings and when you took them. You can stop this at any time from the blood
pressure screen." The sheet then presents accepting and declining as two
controls of equal visual weight.
"I agree to the Terms of Service and Privacy Policy" as a single checkbox
covering storage, sharing, analytics and marketing. A reader who ticks it
makes four decisions in one action, and the record cannot show which of the
four they considered.
Put a "Shared with your GP" indicator and a control directly on the data
screen, so that the disclosure and the means of ending it are both present on
the screen where the shared data is displayed.
Place the withdrawal control three levels into settings under a different
name. A reader who looks for it on the data screen does not find it, and
withdrawing then takes more steps than granting did.
"If you stop sharing: no new readings are sent, and nothing already sent is
deleted. Your GP keeps the readings they have already seen. Your own history
in the app is unchanged." The statement names what stops, what is deleted,
what is kept and what cannot be undone, before the reader confirms.
"Are you sure? Your care may be affected." The confirmation names no specific
consequence, so the reader has nothing to check the warning against, and it
discourages a withdrawal the reader is entitled to make.
Ask for a new consent when the purpose changes, and say what changed: "We
would now like to use your readings for research. This is new, and it is
optional."
Update the privacy policy and rely on continued use as agreement. Continued
use records no decision about the new purpose, so the resulting record cannot
show that the reader ever saw it.
## Components that implement this [#components-that-implement-this]
{/* Generated from `implements`. Do not restate the list by hand. */}
`ConsentSheet` is specified to require a named purpose, a plain-language
explanation, a stated withdrawal consequence and a version identifier, so a
generic all-purpose consent cannot be constructed from it by leaving fields out.
The specification also requires accept and decline to be presented with equal
visual weight.
## What this does not cover [#what-this-does-not-cover]
* **Legal compliance.** This page is written by designers and engineers, and it
is not legal advice, not a compliance checklist, and no substitute for the
implementing organisation's data protection lead or its regulator's guidance.
* **Lawful bases other than consent.** The choice of lawful basis, including the
frequent case where consent is the wrong basis for direct care, is made outside
this page.
* **Records management.** Retention, deletion, subject access and portability are
obligations on the implementing organisation's data layer rather than on the
consent interface.
* **Consent on behalf of another person.** Children, people lacking capacity and
carers raise a substantially different set of questions, which are not yet
specified here.
* **Research consent.** Consent for research is a distinct regime with its own
governance, and this page does not describe it.
* **The wording of sensitive questions.** How the questions themselves are
phrased is covered by
[Asking sensitive questions](../content/asking-sensitive-questions.mdx).
Specify proxy and carer consent: what changes when the person using the app
is not the person the data is about.
## Updates to this page [#updates-to-this-page]