Records of processing (summary)

Last updated on

This page summarises how Patient Watch Ltd processes personal data in connection with the Patient Watch service (the web application and related operations). It supports transparency and accountability under the UK GDPR.

It is the published summary on this website. Further detail appears in the Privacy Policy, Data Collected by Patient Watch, and Data Security & Privacy. Where another organisation (for example an NHS trust, private provider, insurer, study sponsor, registry, manufacturer, or supplier) acts as controller or joint controller for a deployment, that organisation maintains its own records of processing for its use of the service.

Document owner: Patient Watch Ltd. Review: at least annually and whenever processing or tooling changes materially. Last reviewed: 17 July 2026.

Product deployments (Supabase)

Patient Watch Ltd operates separate Supabase projects in the UK (London) for Patient Watch, Foot Watch, and Glucose Watch. Hosting region is fixed in contract for UK deployments; a future EU or US project would be hosted in that region only when agreed in writing.

Product Notes on data collected (summary)
Patient Watch Accounts, profiles, diaries, questionnaires, and programme data as configured (see Data Collected for typical fields such as name, email, phone, identifiers, and health-related content).
Foot Watch Same broad categories as Patient Watch where applicable; this line includes clinical photos when users or programmes upload images.
Glucose Watch Data minimisation: direct identifiers are limited to mobile phone number (this product line does not collect name or email). Glucose-related entries and operational metadata follow the programme configuration.

The schema-level detail of what is stored appears in our database types and product configuration; the table above is the high-level distinction between product lines for transparency and for records such as the internal Information Asset Register.


1. Processing activities (summary table)

The table below is organised by activity. Lawful bases are stated at a high level only; see the Privacy Policy for the full explanation of applicable conditions (including special-category health data and relevant Schedule 1 DPA 2018 conditions where they apply).

Activity Categories of personal data Data subjects Main purposes Typical recipient categories Retention (summary) Security measures (summary)
Accounts, profiles, and authentication Name, email, phone where provided, professional identifiers (for example GMC), account metadata, time zone Patients, clinicians, authorised staff Provide accounts, secure access, service operations, support Patient Watch Ltd, subprocessors that host or deliver the service (see Privacy Policy / DPA terms) As described in our published retention approach (often up to 5 years after last activity unless a different period applies for a lawful purpose) HTTPS, supplier-hosted infrastructure with encryption at rest, authentication and session controls, organisational access rules
Diaries, clinical content, and patient-generated data Diary entries, structured clinical or operational forms, health-related content (including images, scores, blood results where entered), comments, treatment-related notes as configured Patients, treating clinicians, authorised organisation users Direct care, staff workflow, documentation of care pathway, agreed secondary uses where configured; with consent or another applicable lawful basis, payer reporting via enrolling organisation, sharing with responsible clinician, and anonymised, aggregated, or governed pseudonymised study sponsor or manufacturer post-market surveillance or research outputs The patient’s organisation care team, responsible clinician, insurers or payers (via enrolling organisation where applicable), study sponsors and product manufacturers or suppliers (usually anonymised or aggregated outputs; pseudonymised personal data only where lawfully governed), Patient Watch Ltd for hosting and support within role As above; aligned with clinical service need and legal obligations Role-based and organisation-based access, encryption in transit and at rest, audit relevant to access
Questionnaires, studies, registries, trials, and audits Responses, identifiers and linkage fields as configured for each programme Patients, clinicians, researchers as roles permit Service delivery, clinical audit, service evaluation, registry activity, research, post-market surveillance, trials where lawfully established Healthcare organisations, sponsors, and partners only where permitted by law, contract, ethically approved protocols, and governance Per programme rules and contract; often up to 5 years default unless superseded Access restrictions, contractual controls on subprocessors, pseudonymisation or aggregation where designed into the programme
Communications and operational messages Message content, contact details used for delivery, delivery metadata Patients, staff Account and clinical notifications (including SMS where used), service messaging, support correspondence Patient Watch Ltd, messaging and email suppliers as subprocessors Duration needed for delivery and dispute resolution; message stores per configuration Encrypted transport, supplier contractual protections
Product, security, and audit logs Technical identifiers (for example device, IP-derived data), timestamps, security events All users Security monitoring, troubleshooting, audit, misuse prevention Patient Watch Ltd and infrastructure providers under contract Short to medium term for logs; aligned with security policy Logging with restricted access, monitoring, incident process
Feedback and improvement Survey responses, feedback text, sometimes role or cohort category Users Improve usability and product quality; may include aggregated statistics Patient Watch Ltd product and engineering teams; aggregate outputs may be shared without identifying individuals Retained while relevant to improvement cycles; survey-specific notices apply Minimisation, access control, anonymisation of small-number results where appropriate

2. Sources

Personal data comes from:

  • Data subjects (registration, profile completion, diary and questionnaire use).
  • Authorised clinicians and organisation staff entering or confirming information as part of care or research workflows.
  • Automated technical collection in connection with use of the service (for example device and connection metadata as described in the Privacy Policy).

3. International transfers

Our standard deployment is described in public materials (for example UK hosting emphasis in contractual and security documentation). Any transfer outside the UK follows the routes and safeguards described in the Privacy Policy and the Data Processing Agreement where Patient Watch acts as processor. For the core Supabase hosting subprocessor, Patient Watch Ltd maintains a signed Data Processing Addendum and Transfer Impact Assessment documentation, summarised for customers on the Subprocessors page.


Questions: info@patient-watch.com.