Consent and disclosure
Consent that is granular, revocable, recorded and re-asked, and the difference between a lawful basis for processing and a person's actual understanding.
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
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. | 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, 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
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)
Applying it
Do
"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.
Don’t
"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.
Do
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.
Don’t
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.
Do
"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.
Don’t
"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.
Do
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."
Don’t
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
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
- 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.
Updates to this page
Last read through against the system on 2026-09-02. Due for review every 6 months; expiry is reported by pnpm run check:freshness.
Delivering difficult results
Tone, sequence and structure for the moment an app tells someone something they did not want to hear, with no clinician present and no question available.
On-screen privacy
Health data is read on trains, in offices and over shoulders. The page sets how much of it an interface exposes to the room around the reader.