Under the UK General Data Protection Regulation
Between the Clinic (Controller) and HMDG Ltd (Processor)
"Controller" means the clinic accepting this agreement, being the entity that determines the purposes and means of Processing of Personal Data.
"Processor" means HMDG Limited (trading as HMDG), a company registered in England and Wales under company number 10409692, registered office 76 Canterbury Innovation Centre, University Road, Canterbury, Kent, CT2 7FG, ICO registration ZB365505, which Processes Personal Data on behalf of the Controller through the ClinicSignal platform.
"ClinicSignal" means the business intelligence platform operated by the Processor that connects to the Controller's practice management system to derive operational and financial insights.
"Personal Data" means any information relating to an identified or identifiable natural person as defined in UK GDPR Article 4(1).
"Pseudonymised Data" means Personal Data that has been processed in such a way that it can no longer be attributed to a specific data subject without the use of additional information, where such additional information is kept separately and subject to technical and organisational measures.
"Processing" means any operation performed on Personal Data, including collection, recording, organisation, structuring, storage, adaptation, retrieval, consultation, use, disclosure by transmission, dissemination, alignment, combination, restriction, erasure, or destruction.
"UK GDPR" means the General Data Protection Regulation (EU) 2016/679 as it forms part of domestic law in the United Kingdom by virtue of Section 3 of the European Union (Withdrawal) Act 2018, as amended.
"Data Protection Legislation" means the UK GDPR, the Data Protection Act 2018, and any successor legislation, together with any applicable guidance or codes of practice issued by the Information Commissioner's Office (ICO).
"Master Services Agreement" means the commercial services agreement between the parties under which ClinicSignal is provided, published at clinicsignal.hmdg.co.uk/msa. The Processor's own processing as a controller (for example of the Controller's users' account details) is described in the Privacy Policy.
2.1 The Processor shall Process Personal Data solely for the purpose of providing the ClinicSignal platform service to the Controller, which includes:
2.2 The Processor shall not Process Personal Data for any purpose other than those specified in this Agreement, unless required to do so by law, in which case the Processor shall inform the Controller of that legal requirement before Processing (unless the law prohibits such notification).
2.3 ClinicSignal is a business intelligence tool for the Controller only. The Processor shall never use Personal Data to communicate directly with the Controller's patients. No patient-facing communications, marketing, or outreach will be conducted by the Processor.
3.1 The categories of data subjects whose Personal Data is Processed under this Agreement are:
3.2 The categories of Personal Data Processed are:
| Category | Data Fields | Purpose |
|---|---|---|
| Patient pseudonymous identifiers | Practice management system patient ID, derived age band, new/returning flag, referral source name, email and SMS marketing-consent flags | Cohort analysis, lifetime value tracking, rebooking patterns |
| Appointment data | Date, time, duration, status, appointment type, practitioner assigned, coded cancellation reason (free-text cancellation descriptions are not stored), booking channel indicator; group session attendance; patient case records (dates, session limits, referral type; no case names or notes) | Utilisation, scheduling, revenue computation, insight detection |
| Financial data | Appointment type prices, invoice totals, payment amounts | Revenue analysis, treatment profitability, pricing insights |
| Practitioner data | Name, role, active status, practitioner ID, rostered hours and availability (no reasons for unavailability) | Per-therapist performance metrics, revenue attribution |
| Referring practitioner contacts | Name, organisation, occupation, provider number, contact type | Referral source reporting |
| Marketing attribution identifiers | SHA-256 hashed email and phone identifiers from leads and bookings | Lead-to-booking attribution matching |
| Controller user data | Name, email address, role, login identifiers, IP address, usage logs, support correspondence | Service provision, authentication, support, audit |
3.3 ClinicSignal does not request or retrieve clinical content (notes, diagnoses, treatment records, medical histories, free-text clinical fields) from the Controller's practice management system. Patient demographic fields (name, email, phone, date of birth) may be returned in practice management system API responses. Patient name, email address, mobile number and marketing consent status may be fetched on demand from the practice management system for transient display within the Recall and Plan dashboards, and for inclusion in worklist exports generated by the Controller's authorised users for the Controller's own patient re-engagement activity. None of these demographic fields are persisted by ClinicSignal: name, email address and phone number are held in memory only for the duration of the request and are never written to ClinicSignal's database; date of birth is consumed in memory to derive a coarse age band and to detect duplicate patient records, then discarded. Persistent patient identifiers stored in ClinicSignal are limited to the practice management system's pseudonymous patient ID, the derived age band, the referral source name, and the patient's email and SMS marketing consent status (a yes/no/not-recorded flag, never the contact details themselves). The Processor's connectors request only the resources listed in the ClinicSignal Data Guide and map named fields from each response; fields not on that list are discarded before storage. The only free-text fields the Processor stores are catalogue names: appointment type and service names, referral source names and practitioner names. Free-text cancellation descriptions are received and discarded unread.
3.4 The parties acknowledge that appointment types, service names, practitioner assignments and related operational data may, depending on the Controller's configuration of its practice management system, reveal or imply health-related information about patients. To the extent any such data constitutes special category data under Article 9 UK GDPR, the Controller confirms that it has identified an appropriate lawful basis under Article 6 and a special category condition under Article 9, and instructs the Processor to Process such data strictly for the purposes set out in this Agreement.
3.5 For marketing attribution, raw email addresses and phone numbers are hashed using SHA-256 with a server-side salt at the point of ingestion. Raw values are discarded immediately and are not persisted in ClinicSignal's database.
4.1 The Processor shall:
4.2 The Processor shall maintain a record of processing activities under its responsibility in accordance with Article 30(2) UK GDPR.
4.3 HMDG personnel may access Controller data only where necessary to provide support, maintain the service, troubleshoot issues, generate insights, manage the account, or comply with legal obligations. Such access is subject to role-based controls, audit logging, and confidentiality obligations.
5.1 The Controller provides general written authorisation for the Processor to engage the sub-processors listed in Schedule 1.
5.2 The Processor shall inform the Controller of any intended changes concerning the addition or replacement of sub-processors, giving the Controller the opportunity to object to such changes within 14 days of notification. If the Controller objects on reasonable data protection grounds and the Processor is unwilling or unable to address the objection, the Controller may terminate this Agreement and the Master Services Agreement without penalty by giving written notice within a further 14 days.
5.3 Where the Processor engages a sub-processor, the Processor shall impose on that sub-processor, by way of a contract, data protection obligations equivalent to those set out in this Agreement.
5.4 The Processor shall remain fully liable to the Controller for the performance of any sub-processor's obligations.
6.1 The Controller instructs the Processor to generate anonymised and aggregated benchmark datasets derived from the Controller's data for use within ClinicSignal, unless the Controller opts out under clause 6.4.
6.2 The Processor shall not use identifiable Personal Data in benchmarking outputs. The Processor shall apply anonymisation, aggregation, suppression, and threshold controls designed to prevent identification of any patient, practitioner, or clinic. These controls include:
6.3 The parties acknowledge that data undergoing anonymisation remains Personal Data until anonymisation has been effectively completed. During the anonymisation process, all obligations under this Agreement continue to apply.
6.4 The Controller may opt out of contributing to aggregated benchmarking data at any time by written notice to the Processor at dpa@hmdg.co.uk. Opting out will disable market comparison features in the Controller's ClinicSignal dashboard but will not affect any other functionality.
6.5 Anonymised and aggregated benchmarking data shall not be sold, licensed, or shared with third parties, and shall be used only for the purpose of providing benchmarking insights within ClinicSignal to participating clinics.
7.1 ClinicSignal uses third-party AI language models (see Schedule 1) to generate natural-language narrative from structured business intelligence payloads.
7.2 The Processor shall not submit to AI sub-processors:
7.3 AI sub-processors shall receive structured payloads containing the aggregated and pseudonymised metrics necessary to generate the relevant insight or response. Where a practitioner-level explanation is requested, those payloads may include practitioner names and roles, which are Personal Data of the Controller's staff. The prohibition in clause 7.2 on patient identifiers applies regardless.
7.4 The Processor shall not permit AI sub-processors to use Controller Personal Data to train foundation models, fine-tune models, or improve their services, unless expressly agreed in writing by the Controller. This obligation shall be reflected in the Processor's contracts with AI sub-processors.
7.5 The Processor shall maintain logging sufficient to evidence what categories of data are submitted to AI sub-processors.
7.6 Clauses 7.2 and 7.3 govern the data the Processor assembles from the Controller's systems. Free text entered by the Controller's authorised users into the Advisor is submitted to the AI sub-processor as entered and is retained with the Controller's account for support purposes; the Processor does not filter it. The Controller shall ensure its users do not enter patient-identifying information or clinical records into the Advisor (clause 11.1), and the Controller is responsible for any such content its users enter. The structure of what the Processor sends to the AI sub-processor is published as the Advisor AI payload sample. Advisor questions are deleted automatically 12 months after they are asked, are deleted with the Controller's data under clause 12, and will be deleted earlier on the Controller's written request. The Controller may switch the Advisor off for its clinic at any time in Settings, which disables the feature for its users.
8.1 The Processor shall implement and maintain the technical and organisational measures set out in Schedule 4.
8.2 The Processor shall review and update its technical and organisational measures from time to time to reflect evolving security risks and best practice.
9.1 The Processor shall notify the Controller without undue delay, and in any event within 24 hours, after becoming aware of a Personal Data breach affecting the Controller's data.
9.2 The notification shall include:
9.3 The Processor shall cooperate with the Controller and take reasonable commercial steps to assist in the investigation, mitigation, and remediation of each such breach.
10.1 The Processor shall promptly notify the Controller if it receives a request from a data subject to exercise their rights under the Data Protection Legislation (including access, rectification, erasure, restriction, portability, or objection).
10.2 The Processor shall not respond to any such request directly unless authorised to do so by the Controller, except to redirect the data subject to the Controller.
10.3 The Processor shall assist the Controller in responding to data subject requests by providing relevant data extracts or deletions within 5 working days of the Controller's instruction.
11.1 The Controller shall:
11.2 The Controller acknowledges that the Processor's ability to perform its obligations is dependent on the accuracy and integrity of data supplied by the Controller and the proper configuration of the Controller's systems.
12.1 Personal Data shall be retained by the Processor for the duration of the Master Services Agreement. Historical appointment and billing records are retained for that period because the service's year-on-year comparisons, patient cohort analysis and benchmarks depend on them; the Controller may instruct the Processor in writing to delete records older than a stated date, accepting that those comparisons will then be unavailable.
12.2 Upon termination of the Master Services Agreement, or upon written request by the Controller, the Processor shall:
12.3 The deletion obligation does not apply to:
12.4 Backups are overwritten in the normal backup rotation cycle. The Processor shall confirm to the Controller the maximum backup retention period applicable to its current infrastructure on request.
12.5 Export under clause 12.2 is limited to Customer Data and Customer-specific outputs in a structured, commonly used format. The Processor is not required to export platform logic, code, models, templates, anonymised benchmarking datasets, or proprietary methodology.
12.6 Revoking or removing a practice management system credential stops further retrieval but does not by itself terminate the Master Services Agreement or delete Personal Data already imported; deletion follows a written request or termination under clause 12.2.
13.1 The Processor shall not transfer Personal Data outside the United Kingdom unless:
13.2 Before making any restricted transfer, the Processor shall ensure that a valid transfer mechanism is in place and shall undertake any transfer risk assessment required by the Data Protection Legislation.
13.3 Sub-processors that may process data outside the UK are identified in Schedule 1, along with the applicable transfer mechanism.
13.4 The Processor shall notify the Controller if any safeguard relied upon ceases to be valid and shall implement an alternative safeguard or suspend the relevant transfer.
13.5 Copies of the sub-processor agreements and transfer terms the Processor relies on are available to the Controller on written request to dpa@hmdg.co.uk.
14.1 The Processor shall make available to the Controller all information necessary to demonstrate compliance with this Agreement.
14.2 The Controller shall first rely on:
14.3 On-site or invasive audits shall be permitted only where reasonably necessary to address a specific compliance concern that cannot be resolved by the means in clause 14.2, and shall be:
14.4 The Controller shall bear its own costs of any audit. The Processor's reasonable costs of supporting an audit shall be borne by the Controller, save where the audit reveals material non-compliance by the Processor.
14.5 Nothing in this clause limits the Processor's obligations under clause 4.1, prevents the Controller from carrying out any check required by the Data Protection Legislation or a supervisory authority, or restricts a supervisory authority's own powers.
15.1 The Processor shall ensure that Controller data is logically segregated within ClinicSignal so that authorised users from one Controller cannot access another Controller's data.
15.2 Access by HMDG personnel to Controller data shall be controlled by role-based permissions, multi-factor authentication, and audit logging. Access logs shall be retained for a minimum of 12 months.
15.3 On request, the Processor shall provide the Controller with a summary of access events relating to the Controller's data within a reasonable timeframe.
16.1 This Agreement is accepted electronically by the Controller during the ClinicSignal sign-up or onboarding process.
16.2 At the point of acceptance, the Processor shall record:
16.3 The Processor may issue revised versions of this Agreement to reflect changes in law, sub-processors, or processing activities. Material changes shall be notified to the Controller at least 30 days before they take effect, and the Controller shall be given the opportunity to accept the revised version or terminate the Master Services Agreement without penalty.
16.4 Non-material changes (including corrections, formatting, or sub-processor additions made under clause 5.2) may be made without 30-day notice but shall be communicated to the Controller and reflected in the version history.
17.1 This Agreement shall come into effect when the Controller accepts it during ClinicSignal setup, and shall continue for the duration of the Master Services Agreement.
17.2 Either party may terminate this Agreement by giving 30 days' written notice to the other party, provided that termination of this Agreement automatically terminates the Master Services Agreement.
17.3 The Controller may terminate this Agreement immediately if the Processor commits a material breach of this Agreement or the Data Protection Legislation that the Processor fails to cure within 30 days of written notice.
17.4 Clauses 8 (Security Measures) and 9 (Breach Notification) for as long as the Processor holds any Personal Data, and clauses 12 (Data Retention and Deletion), 14 (Audit Rights) and 18 (Liability), shall survive termination of this Agreement.
18.1 Each party shall be liable for damage caused by Processing that infringes the Data Protection Legislation in accordance with Article 82 of the UK GDPR.
18.2 The Processor shall be liable for damage caused by Processing only where it has not complied with obligations of the UK GDPR specifically directed to processors, or where it has acted outside or contrary to the lawful instructions of the Controller.
18.3 Subject to any liability that cannot lawfully be excluded or limited, the Processor's aggregate liability arising out of or in connection with this Agreement is subject to the liability provisions and cap set out in the Master Services Agreement.
18.4 The Processor shall not be liable for damage arising from:
19.1 This Agreement shall be governed by and construed in accordance with the laws of England and Wales.
19.2 The courts of England and Wales shall have exclusive jurisdiction to settle any dispute arising out of or in connection with this Agreement.
| Sub-Processor | Purpose | Data Processed | Location and Transfer Mechanism |
|---|---|---|---|
| Railway Corporation | Application hosting, database hosting, job queue and background processing | All categories of Personal Data listed in clause 3.2, at rest in the database and in transit during request handling | USA (Virginia). UK Addendum to EU SCCs under Railway's Data Processing Addendum; Railway also participates in the UK Extension to the EU-US Data Privacy Framework. |
| Anthropic PBC | AI language generation for business insights and the advisor feature | Structured payloads of aggregated and pseudonymised metrics, which may include practitioner names and roles (clause 7.3). No patient names, raw email addresses, phone numbers, dates of birth or clinical content (clause 7.2). | USA. UK Addendum to EU SCCs under Anthropic's Data Processing Addendum. Controller data is not used for model training. Under Anthropic's standard commercial API terms, inputs and outputs are deleted within 30 days of processing, except where retention is required to enforce Anthropic's usage policy or by law. |
| Plus Five Five, Inc. (Resend) | Transactional email delivery (sign-in links, weekly and monthly reports, account notifications) | Controller user names and email addresses. Reports contain derived metrics, not patient data. | USA. UK Addendum to EU SCCs under Resend's Data Processing Addendum. |
Cloudflare, Inc. serves the public marketing website (clinicsignal.hmdg.co.uk) only and does not process Controller clinic records; it is described in the Privacy Policy. This schedule was last updated October 2026. The Processor will notify the Controller of changes in accordance with clause 5.2.
Data collection. When the Controller connects their practice management system, ClinicSignal retrieves appointment, practitioner, financial, and pseudonymised patient data via a secure API authenticated by an API key provided by the Controller. ClinicSignal does not retrieve clinical content. Patient names, email addresses, mobile numbers, marketing consent status and dates of birth may be returned by the practice management system and are handled as set out in clause 3.3: fetched on demand, held in memory for the duration of the request, and never written to ClinicSignal's database (dates of birth are reduced to an age band). Marketing leads from connected lead-capture systems are ingested with email and phone identifiers hashed at ingestion; raw values are discarded immediately.
Data storage. Data is stored in an encrypted database hosted by Railway in the United States (Schedule 1). Data is synced incrementally to minimise data transfer and API load. Historical data is imported once during initial setup. Controller data is logically segregated.
Data processing. ClinicSignal computes derived metrics (revenue, utilisation, rebooking rates, attribution, and similar) from the data. AI language models receive structured metric payloads as described in clause 7.
Data output. Insights and reports are delivered to the Controller via the ClinicSignal dashboard and email reports. Only the Controller's authorised users and authorised HMDG personnel can access this output.
Data deletion. On termination, data is deleted in accordance with clause 12.
Subject matter: provision of the ClinicSignal business intelligence platform.
Duration: for the term of the Master Services Agreement and the deletion period thereafter.
Nature of processing: collection, storage, synchronisation, analysis, aggregation, dashboard and report generation, AI-assisted insight generation, marketing attribution, deletion.
Purpose: operational, financial, and marketing business intelligence for the Controller.
Categories of data subjects: as listed in clause 3.1.
Categories of Personal Data: as listed in clause 3.2.
Special category data: not intentionally collected from clinical records. Appointment and service data may imply health-related information depending on the Controller's configuration; see clause 3.4.
Controller obligations: as listed in clause 11.
Processor obligations: as listed in clause 4 and elsewhere in this Agreement.
The Processor shall implement and maintain at least the following measures:
Encryption. Encryption of Personal Data in transit (TLS 1.2 or higher). Database volumes and backups encrypted at rest by the hosting provider. Controller API keys and OAuth tokens additionally encrypted at the application layer (AES-256-GCM). Encrypted database connections.
Access control. Role-based access controls. Multi-factor authentication for all administrative systems and production access. Least-privilege principle applied to all internal access. Production access restricted to named personnel and audited.
Authentication. Magic-link authentication for Controller users. No shared accounts.
Logical segregation. Controller data segregated such that one Controller cannot access another Controller's data through any normal application path.
API key handling. Controller API keys stored in encrypted secrets management, never in source code or logs. Access to keys restricted to runtime processes.
Logging and monitoring. Sign-in events and HMDG staff access to Controller dashboards recorded in the application with user and timestamp and retained for at least 12 months. Application and database logs retained by the hosting provider. Production errors alert the engineering team.
Vulnerability management. Automated dependency vulnerability alerts and secret scanning on every change. Dependencies patched within timeframes proportionate to severity.
Security assessment. An independent security review of the application was carried out in May 2026 and its findings were closed in June 2026.
Environment separation. Production and demo environments separated; the demo runs on synthetic data. Engineering access to production data for support and troubleshooting is limited to named personnel.
Backup and recovery. Encrypted daily, weekly and monthly backups of the production database, retained for 6, 27 and 89 days respectively. Documented restore procedure.
Incident response. Documented incident response procedures capable of detecting and responding to security breaches within the timescales required by clause 9.
Personnel security. Confidentiality obligations for all personnel with access to Personal Data. Access revoked promptly on personnel changes.
Sub-processor management. Due diligence on sub-processors before engagement. Contractual requirements for equivalent security measures.
Deletion. Documented data deletion procedures covering production systems, backups, and audit logs.
By requesting access to ClinicSignal and ticking the Data Processing Agreement checkbox during sign-up, you accept this Agreement on behalf of your clinic.