Data Protection Impact Assessment

Document details

1. Screening — a DPIA is required

This processing meets several of the ICO's high-risk screening criteria under Article 35(1) and (3) UK GDPR:

• Innovative technology — large language and vision models applied to social care recording.
• Vulnerable individuals — supported persons are vulnerable adults within the meaning of the Care Act 2014, some non-verbal or with limited capacity.
• Large-scale special category data — health and care data for approximately 1,000 supported persons, processed systematically and continuously.
• Systematic monitoring — care observations recorded, structured and stored on an ongoing basis.
• International transfers — data is sent to sub-processors outside the United Kingdom.
• Combination of datasets — observations are combined with existing care plans, baselines and controlled vocabularies.

2. Description of the processing

2.1 Nature of the processing

WellDash lets carers — many of whom are not highly literate, or speak English as a second language — produce structured, auditable care records by speaking, typing or photographing observations during care delivery. Language and vision models structure natural-language observations into standardised records (toileting logs, behavioural observations, incident records) stored in a UK-hosted Supabase database.

The processing is characterised by an identity firewall: no person identifier of any kind — no name, no pseudonymous code, no database key, no organisational id — is attached to an observation sent to an AI provider or placed in an AI prompt. Identity lives in the browser's own state and in the UK-hosted database, and is joined back to a record after the AI step by application code that never calls an AI provider.

2.2 Three data paths

Path 1 — typed observations

1. A carer types an observation in the browser ("had a wee, bit dark, smelled strong").
2. The observation is sent for structuring with no identifier attached. The person's name, database key and organisation id stay in the browser's state and in the database. Names held on the record are used server-side only to build a redaction list applied to the text before it leaves.
3. The text passes through a server route that holds no conversation store and no re-identification mapping for sub-processors. It resolves the person's database key to scope the read and stamp the eventual write; that key is never forwarded to an AI provider.
4. The care text goes to z.ai for structuring into a record matching the database schema. What z.ai receives is a care observation with no name, code, key or mapping.
5. The structured proposal is written into the person's record in a pending state and presented to the carer as a swipeable card. Swipe right accepts it — it becomes a confirmed record. Swipe left returns it for re-composition.
6. Only approved records are read by the care surfaces, the medication register and the analytics.

Path 2 — spoken observations

1. A carer speaks an observation in the browser.
2. The audio goes to Deepgram's EU endpoint with targeted identity-entity redaction enabled — names, email addresses, phone numbers, addresses, postcodes, coordinates, usernames and URLs are stripped during transcription and returned as placeholders. Deepgram receives an unlinked audio stream: no person identifier, no database record, no organisational context, no care plan, no session history.
3. Deepgram returns a redacted transcript and does not retain the audio (model-improvement opt-out on every call; account retention disabled).
4. The transcript is routed by care domain, not by person.
5. Structuring, ratification and storage proceed as in Path 1.

Path 3 — photographic observations

1. A carer captures a photograph (a meal tray, a wound, a skin condition).
2. The image is sent to z.ai's vision API with no person identifier, database record, organisational context, care plan or session history attached. Images captured in the care hub are additionally scrubbed on-device before they leave.
3. z.ai returns a text description and does not store the image.
4. The description is associated with the person only in the browser's own state; structuring, ratification and storage proceed as in Path 1.

2.3 What each layer holds

2.4 Scope

2.5 Context

• Source: carer observations during care delivery; existing care plans and baselines from the UK-hosted database.
• Relationship: the provider owes a duty of care under the Care Act 2014 and the Health and Social Care Act 2008.
• Individual control: supported persons or their legal representatives consent to care recording as part of their care agreement. AI-assisted structuring is a method within that existing process — it does not introduce new purposes or new data categories.
• Vulnerability: some supported persons are non-verbal or lack capacity; many have representatives under the Mental Capacity Act 2005.
• Technology: z.ai GLM models for structuring and vision; Deepgram for transcription. No biometric identification, no surveillance, no profiling, no automated decision-making.

2.6 Purpose

To improve the quality, timeliness and accuracy of care records by helping carers structure observations into standardised, auditable records that meet CQC and DSPT expectations. The AI does not make clinical decisions. The carer ratifies every record. The AI is a structuring assistant; the human carer is the clinical authority and the trust anchor for every confirmed record.

3. Consultation

3.1 With individuals

Supported persons' views on care recording are captured through existing care planning processes (reviews, advocacy, family meetings) as required by the Care Act 2014. The controller should document that those processes cover this processing, or run a specific consultation if the DPO thinks it appropriate. Where a person lacks capacity, consultation should involve their representative or advocate under the Mental Capacity Act 2005.

3.2 With processors

WellDash has provided this DPIA, the TRA and the DPA. Sub-processor documentation reviewed: z.ai's Data Processing Addendum, privacy policy and API terms (no storage of API content, no training on API data, real-time processing only); Deepgram's master service agreement, privacy policy, Model Improvement Partnership Program documentation, data privacy compliance documentation and redaction documentation (SOC 2 Type II, HIPAA-ready, GDPR-ready, EU endpoint, entity-level redaction, model-improvement opt-out, and Deepgram's statement that it frequently enters into the EU Commission's Standard Contractual Clauses with customers).

Outstanding at the 12 August 2026 verification: equivalent documentation has not yet been reviewed for the infrastructure sub-processors named in DPA Schedule 1B (Supabase, Vercel, Resend, Stripe). That review should complete before sign-off.

3.3 With the DPO

The controller's DPO should review and advise on this DPIA under Article 35(2) UK GDPR. Their advice and any deviations from it should be recorded in the signature copy.

4. Necessity and proportionality

4.1 Lawful basis

4.2 Necessity

• Manual care recording is inconsistent, delayed and incomplete — minimal notes written at the end of a shift are inadequate for inspection and clinical governance.
• Many carers speak English as a second language or have limited literacy; handwritten notes are frequently illegible or insufficient.
• Record quality directly affects CQC assessment and DSPT compliance.
• Structured records make it possible to notice a change against the person's own baseline earlier.
• Less intrusive alternatives — manual templates, dropdown forms — have been tried and produce lower-quality records because carers disengage from them.

4.3 Data protection by design (Article 25)

• Identity firewall, all AI paths — no identifier is attached to an observation sent for AI processing or placed in the prompt. The prompt tells the model it is never given the person's name or ids and instructs it to refer to them neutrally.
• Server-side tool scoping — the tool interfaces exposed to the model contain no identity parameter. There is no field into which the model could place a person's name, code or key. The server attaches the active person from its own request-scoped context, so cross-person access is structurally unavailable even under prompt injection or model error.
• Row scrubbing — when the model reads recent care logs, identity and attribution columns are stripped from every row before it sees them.
• Identity-data separation on voice and image — sub-processors receive unlinked observations with no person identifier, database record, organisational context or session history.
• Relay isolation — no conversation store and no re-identification mapping for sub-processors; the privileged database connection used to fetch the person's own context is never forwarded onward.
• Data minimisation — only the current thread's plan steps, standing facts and vocabularies are assembled for the AI step.
• No retention, no training — contractual with both AI sub-processors.
• Human ratification (hard gate) — the AI proposes; the witnessing carer commits.
• Constrained generation — function-call interfaces plus the live column list and enumerated values in the prompt, with server-side validation and database constraints at write time.
• Sealed database — row-level security on every care table; the public browser keys hold no grant on any care table and no access to the care schema.

4.4 Function creep prevention

The purpose is strictly limited to structuring carer observations into standardised care records. The system does not make clinical decisions or diagnoses, does not profile or risk-stratify supported persons, does not perform predictive analytics or behavioural forecasting, does not automatically change care plans (a change is a proposal that a named human approves), and does not share data with any party other than the sub-processors named in the DPA for the purposes stated there.

Where support options are ranked, the ranking is computed only from the person's own recorded history, is shown with the number of episodes behind it, marks an untested option as untested, and enters a plan only through human approval.

4.5 Data quality

Structured records use controlled vocabularies and PostgreSQL ENUM types that reject invalid values at the database level. The model composes through a function-call interface with the live column list and enumerated values in its prompt, so it writes in the record's own vocabulary. The server validates at write time: it refuses a target table outside the thread's declared set, drops any field that is not a live column, fails closed if the schema lookup fails, and lets the database constraints reject anything invalid that remains. This is a layered check — prompt-level constraint plus write-time validation — rather than a guarantee that an invalid token can never be generated.

4.6 Data minimisation

Hydration fetches only the care plan steps, baseline values and vocabularies relevant to the specific thread. The person's entire care record is never sent to any sub-processor.

4.7 Privacy information

The controller's privacy notice should mention AI-assisted structuring of care records. Suggested wording: "We use AI technology to help our carers structure their observations into standardised care records. Observations are processed in real time and are not stored by our AI providers. All records are reviewed and approved by a human carer before they count as part of the record."

4.8 Individuals' rights

AI-assisted structuring does not affect existing rights under Articles 12–22. Records are stored in the UK-hosted database and are subject to the same retention policies as manually created records. Rights of access, rectification, erasure, restriction, objection and portability apply in the same way.

Honest note: those rights are today serviced by administered database operations, not by a self-service control in the product. A provider taking this system into production should agree the response process and its service level explicitly.

4.9 Safeguards for international transfers

See the TRA. In summary: neither AI transfer carries a person identifier, so the processor's position is that Chapter V is not engaged for them. Infrastructure sub-processors do process personal data and rely on their own published transfer mechanisms.

5. Risk identification and assessment

Risks are assessed using the ICO's methodology on a Low/Medium/High scale, before mitigation.

6. Mitigating measures and residual risk

7. Conclusion and sign-off

7.1 Residual risk

After mitigation the overall residual risk is Low, with two Medium residuals: the regulatory question over the transfer position (R8) and the identified-content email intake path (R11).

7.2 Commitments

• Evaluate UK-hosted or EU-hosted AI providers for production deployment if Singapore remains a concern.
• Update the ICO registration to reflect this processing activity.
• Update the privacy notice to mention AI-assisted structuring of care records.
• Ensure carers are trained on safe use, including not using supported persons' names in voice observations.
• Complete the sub-processor documentation review for Supabase, Vercel, Resend and Stripe, and agree the process and service level for data subject rights requests and deletion.
• Review this DPIA at the end of the trial period, or earlier if circumstances change.

7.3 ICO consultation

On this residual risk assessment, prior consultation with the ICO under Article 36 UK GDPR is not required. The controller should consult the ICO if the ICO challenges the position that the AI transfers do not involve personal data, if either AI sub-processor's practices change, if the scope of processing expands significantly, or if new sub-processors are added.