Article 28 UK GDPR — processor terms for the WellDash care recording system
The contract between the care provider (controller) and WellDash (processor): what we may do with care data, the security measures we commit to, every sub-processor we use, and what happens to the data when the contract ends.
| Document | Data Processing Agreement (DPA) — WellDash AI-assisted care recording system |
| Parties | The care provider (the "Controller") and WellDash (the "Processor") |
| Effective date | [Date of sign-off] |
| Version | 1.0 (Trial) |
| Review date | [Date — recommended: end of trial period] |
| Related documents | DPIA (v2.0) · TRA (v1.0) · Main service agreement |
1.1 In this DPA the following terms have the following meanings:
pending state so nothing observed is lost; only the carer's acceptance flips it to approved, and only approved records are read by care surfaces, the medication register and analytics. No automated decision with legal or similarly significant effect is taken within the meaning of Article 22 UK GDPR.1.2 The terms "process", "processing", "processor", "controller", "data subject" and "personal data" are interpreted in accordance with UK GDPR Articles 4 and 28.
The Processor processes personal data for the sole purpose of providing the Services — AI-assisted structuring of carer observations into standardised, auditable care records. Processing is limited to text structuring, voice transcription, image description, document intake and record storage. The Processor does not process personal data for profiling, predictive analytics, behavioural forecasting, automated decision-making or model training.
For the duration of the service agreement. On termination the Processor shall delete or return all personal data to the Controller within 30 days unless retention is required by law.
(a) collection of carer observations in the browser; (b) targeted identity-entity redaction at source on voice, performed by the speech provider during transcription; (c) identity-data separation — the browser and the Controller's database hold identity, AI sub-processors receive care content only; (d) real-time transcription of voice audio; (e) real-time language-model structuring of care observations; (f) real-time image description; (g) human ratification by swipe-to-commit; (h) storage of records in the UK-hosted Supabase database, where a record counts as a care record only once approved.
The Processor processes personal data only on the Controller's documented instructions, including as to transfers to a third country, unless required otherwise by law. Instructions are set out in this DPA, the main service agreement and the DPIA. The Processor shall immediately inform the Controller if, in its opinion, an instruction infringes UK GDPR or the DPA 2018.
Persons authorised to process personal data are subject to a confidentiality obligation. Access is restricted to authorised personnel on a need-to-know basis.
The Processor implements and maintains appropriate technical and organisational measures under Article 32 UK GDPR, including at minimum:
supported_person_id, organisation_id, recorded-by fields, contact details, NHS number, date of birth) are stripped from every row returned to the model.The Processor engages the sub-processors listed in Schedule 1. The Processor warrants that each sub-processor is subject to a written contract with equivalent data-protection terms, that AI sub-processors are contractually excluded from using data for model training and are subject to a no-retention commitment, and that the Processor remains fully liable for each sub-processor's performance under Article 28(4) UK GDPR. The Processor shall give prior written notice of any intended addition or replacement of a sub-processor, giving the Controller the opportunity to object; on reasonable objection the Processor shall not engage the proposed sub-processor.
The Processor assists the Controller in responding to requests under Articles 12–22 UK GDPR. Rights apply to records held in the UK-hosted Supabase database. The Processor shall provide reasonable assistance within 30 days.
The Processor assists the Controller with Articles 25 and 32–36 UK GDPR, and has provided this DPA, the DPIA and the TRA for that purpose.
On termination the Processor shall delete or return all personal data and delete existing copies unless retention is required by law, and shall provide written confirmation of deletion on request. Deletion is today performed as an administered operation on the Controller's database rather than through a self-service control in the product.
The Processor makes available all information necessary to demonstrate compliance with Article 28, and shall allow for and contribute to audits and inspections by the Controller or its mandated auditor, subject to appropriate confidentiality safeguards.
The Processor shall notify the Controller without undue delay and in any case within 24 hours of becoming aware of a personal data breach affecting the Controller's personal data, in accordance with Article 33 UK GDPR. The notification shall include the nature of the breach (including the categories and approximate number of data subjects and records concerned), the likely consequences, and the measures taken or proposed.
The Processor shall cooperate in investigating and remedying the breach and shall provide the information the Controller needs to meet its own obligations under Articles 33 and 34 UK GDPR.
The Processor documents all personal data breaches, their effects and the remedial action taken, in accordance with Article 33(5) UK GDPR.
api.eu.deepgram.com) with targeted identity-entity redaction applied during transcription. No person identifier accompanies the audio.The Processor's position is that neither AI transfer carries personal data: under Recital 26 UK GDPR, data is personal data only where the recipient can identify a natural person by means reasonably likely to be used, and neither AI sub-processor holds a mapping, a database, session continuity or retention. On that basis Chapter V (Articles 44–49) is not engaged for these two transfers and Article 46 safeguards are not required. The Controller should note that this is a legal position on anonymity, not an exemption, and that it depends on the identity firewall continuing to hold — see clause 5.5.
Infrastructure sub-processors listed in Schedule 1B do process personal data and rely on their own published transfer mechanisms.
A Transfer Risk Assessment has been conducted and is published alongside this DPA. The Controller has reviewed and accepted the residual risks identified in it.
The Processor shall implement and maintain the identity firewall for all AI transfers. It is a load-bearing mitigation: its continued implementation is a condition of the transfer position set out in clause 5.2, and any change to it is a material change requiring notice under clause 10.
The Services operate on a hard-gate model: an AI-structured proposal does not become a confirmed care record until the witnessing carer accepts it. The AI proposes; the human commits. No automated decision with legal or similarly significant effect is taken.
The Processor shall not use the Controller's personal data to train, fine-tune or improve any machine-learning model, its own or a sub-processor's. This applies to voice audio, images, text and structured records. The Processor warrants that z.ai's Data Processing Addendum governs API processing for business users and excludes API data from model training, that Deepgram is configured with mip_opt_out=true on every care transcription call, and that neither AI sub-processor retains personal data beyond real-time processing.
The Processor shall not profile supported persons or carers, shall not perform predictive analytics and shall not produce risk scores or behavioural forecasts. Where the Services rank support options, the ranking is computed only from the person's own recorded history, is shown with the evidence count behind it, and enters a plan only through human approval.
The Processor maintains a record of the categories of processing carried out on the Controller's behalf under Article 30(2) UK GDPR: the processing operations, the categories of personal data, the sub-processors with their locations and purposes, the technical and organisational measures, and the international transfers with their safeguards.
Every record carries its typed row, its target table, its lifecycle state (pending then approved), the time of each transition and the staff member who confirmed it. Decisions on plan-change proposals and machine-to-machine writes are additionally written to an audit log. The audit trail is held in the UK-hosted Supabase database and is available to the Controller for inspection.
For the avoidance of doubt: the system does not retain the model prompt or the model's intermediate reasoning for each record. What is reconstructable is the clinical content, the schema it was written against, the lifecycle and the human attribution — not the generation trace.
8.1 The Processor is liable to the Controller for damage caused by processing only where it has not complied with obligations of UK GDPR specifically directed at processors, or has acted outside or contrary to lawful instructions of the Controller, in accordance with Article 82(2) UK GDPR.
8.2 The Processor remains fully liable for the performance of each sub-processor's data protection obligations under Article 28(4) UK GDPR.
9.1 The Processor's obligations survive termination for as long as it processes personal data on the Controller's behalf.
9.2 On termination the Processor shall, at the Controller's choice, delete all personal data processed on the Controller's behalf and delete existing copies unless retention is required by law, providing written confirmation within 30 days.
10.1 The Processor may amend this DPA to reflect changes in law, regulatory guidance or its practices. Material changes are notified in writing at least 30 days in advance; the Controller may object, in which case the parties negotiate in good faith.
10.2 The Processor shall notify the Controller of any intended addition or replacement of a sub-processor, giving the opportunity to object, in accordance with clause 3.4.
This DPA is governed by the laws of England and Wales, and any dispute is subject to the exclusive jurisdiction of the courts of England and Wales.
| Legal entity | Deepgram, Inc. |
| Registered address | 548 Market St, Suite 25104, San Francisco, CA 94104, United States |
| Processing location | EU — api.eu.deepgram.com. All care voice transcription is routed through the EU endpoint. |
| Purpose | Real-time speech-to-text transcription of carer voice observations |
| Data transferred | Unlinked voice audio — no person identifier, no database record, no organisational context. Identity entities are redacted during transcription: personal names, email addresses, phone numbers, street addresses, postcodes, geographic coordinates, usernames and URLs. Clinical values are deliberately preserved (times, dates, durations, ages, occupational roles and named clinicians remain in the transcript, because a care record that loses "the seizure lasted three minutes" is not a care record). |
| Retention | None beyond processing. mip_opt_out=true on every care transcription call; account-level retention disabled. |
| Model training | Excluded. Only data contractually included through Deepgram's Model Improvement Partnership Program is used for training; WellDash is not enrolled. |
| Security | SOC 2 Type II, HIPAA-ready, GDPR-ready, PCI DSS compliant. TLS in transit; AES-256 at rest. |
| Transfer mechanism | Processor's position: not personal data (Recital 26). EU endpoint used regardless. Deepgram provides a DPA incorporating SCCs on request. |
| Legal entity | JINGSHENG HENGXING TECHNOLOGY PTE. LTD |
| Processing location | Singapore |
| Purpose | Real-time language-model structuring of care observations and multimodal image description |
| Data transferred | Care observations with no names, identity codes, database keys or mapping; unlinked images with no person identifier or organisational context |
| Retention | None. z.ai's Data Processing Addendum states that it does not store the content customers or end users provide or generate; content is processed in real time and is not saved on its servers. |
| Model training | Excluded. z.ai's DPA governs API processing for business and enterprise users separately from its consumer privacy policy; API data is not used for model training. |
| Security | Industry-standard encryption; security commitments in the DPA; TLS in transit. |
| Transfer mechanism | Processor's position: not personal data (Recital 26). The UK–Singapore Digital Economy Agreement provides a supporting bilateral framework. |
| Sub-processor | Function | Personal data | Position |
|---|---|---|---|
| Supabase (PostgreSQL database and object storage) | The system of record — care records, plans, staff, documents and uploaded files | Yes — all of it, including special category health data, in identified form | UK-hosted project; encryption at rest and in transit. Vendor DPA reference [to be completed]. |
| Vercel (application hosting and serverless compute) | Runs the web application and every server route | Yes — in transit through function memory during each request; no application-managed persistence | Vendor DPA reference and transfer mechanism [to be completed]. |
| Resend (inbound and outbound email) | Receives care documents sent to a per-person intake address; sends outbound email drafted in the product | Yes — sender and recipient addresses, subject and body, and attached care documents in identified form. Email content is not anonymous. | Vendor DPA reference and transfer mechanism [to be completed]. Note this is the one live path where identified care content leaves the system. |
| Stripe (payments) | Subscription and payment processing | Yes — billing contact and payment data of the Controller's staff; no supported-person care data | Vendor DPA and standard transfer terms [to be completed]. |
Every care voice-transcription request is sent to Deepgram's EU endpoint with a specific list of identity entity classes to redact during transcription: personal names, email addresses, phone numbers, street addresses, postcodes, coordinates, usernames and URLs. Redacted entities are returned as bracketed placeholders. Health content is deliberately not redacted — it is the intended clinical record.
The browser holds the identity context — the carer has chosen which supported person they are recording for. What AI sub-processors receive is care content with no identity markers. Routing is by care domain, not by person. Images are sent for description without any person identifier, database record or organisational context.
The serverless function that relays observations keeps no conversation store and no re-identification mapping for sub-processors. It holds a privileged database connection used to hydrate the person's own care context and to stamp the write; that connection and the identifiers it resolves are never forwarded to an AI provider.
The person's stored preferred and legal names are read server-side for one purpose: to build a redaction list applied to care text before it reaches an AI provider. Identity and attribution columns are stripped from every row returned to the model — the model receives clinical content, not linkage keys.
Only the current care thread's plan steps, standing facts and controlled vocabularies are assembled for the AI step. The person's entire care record is never sent to any sub-processor.
Both AI sub-processors process in real time and do not persist the data. Deepgram: model-improvement opt-out on every care call, account retention disabled. z.ai: contractual no-storage of API content.
Both AI sub-processors are contractually prohibited from using the data for model training.
An AI proposal is written into the person's record immediately in a pending state so that nothing observed is lost, and becomes a confirmed care record only when the witnessing carer accepts it. Pending rows are excluded from the care surfaces, the medication register and the analytics that count records. A carer can return a proposal for re-composition instead of accepting it.
The model writes through a defined function-call interface. Its system prompt carries the live column list and enumerated values of the tables the current thread may write to, so it composes in the record's own vocabulary. The server then validates at write time: it refuses any target table outside the thread's declared set, drops any field that is not a live column and fails closed if the schema lookup fails, and PostgreSQL ENUM and check constraints reject invalid values at the database level.
No AI sub-processor receives both the health observation and any person identifier, and no AI-facing interface offers a field in which identity could be supplied. Server-side, the relay does resolve identity in order to scope the read and stamp the write; the guarantee is not that identity is unknown to the server, but that it never crosses into an AI prompt, tool call or payload.
TLS for all data in transit. AES-256 at rest for the UK-hosted Supabase database.
Row-level security is enabled on every table in the care schema, and the public browser keys hold no grant on any care table and no access to the care schema — a browser cannot read care data directly under any circumstances. Application access runs through server routes that enforce, for every request, that the staff member is active, the person is active, both belong to the same organisation, and that an oversight role, a current rota assignment or an explicit named grant authorises access to that specific person.
This Data Processing Agreement is executed by the duly authorised representatives of the parties. Signature blocks are provided in the master document supplied for signature.
The DPA is the contract. The DPIA is the risk assessment behind it. The TRA is the detail on what leaves the country.
The risk assessment the law requires before high-risk processing begins: what the system does with health data about vulnerable adults, the ten risks we identified, what we do about each one, and what risk is left over.
Read the DPIAWhy care data can be structured by AI providers outside the UK without exposing anyone: what actually leaves the country, what the receiving provider can and cannot do with it, and the code-level controls an auditor can check rather than take on trust.
Read the TRAEvery control described here is meant to be verifiable. If something in these documents does not match what you find, we want to know.