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 Ltd (trading as HMDG), a company registered in England and Wales, 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.
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 | Cohort analysis, lifetime value tracking, rebooking patterns |
| Appointment data | Date, time, duration, status, appointment type, practitioner assigned | 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 | Per-therapist performance metrics, revenue attribution |
| 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, and patient names may be fetched on demand from the practice management system for transient display within the Recall and Plan dashboards. None of these demographic fields are persisted by ClinicSignal: name fields are discarded immediately after synchronisation, date of birth is consumed in memory to derive a coarse age band and discarded, and email and phone are not used. Persistent patient identifiers stored in ClinicSignal are limited to the practice management system's pseudonymous patient ID and the derived age band.
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 or via in-product settings. 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 only structured payloads containing aggregated and pseudonymised metrics necessary to generate the relevant insight or response.
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.
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.
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.
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.
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.
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 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 Inc. | Application hosting and runtime environment | All categories of Personal Data passing through the application during request handling | USA. UK Addendum to EU SCCs. |
| Neon Inc. | Primary database hosting | All categories of Personal Data listed in clause 3.2 | EU/UK region. UK adequacy or IDTA, as applicable to the chosen region. |
| Anthropic PBC | AI language generation for business insights and advisor feature | Structured payloads of aggregated and pseudonymised metrics. No raw email, phone, name, DOB, or clinical content. | USA. UK Addendum to EU SCCs and Anthropic Data Processing Addendum. Controller data is not used for model training. |
| Google Cloud (BigQuery) | Aggregated market benchmarking data warehouse | Anonymised, de-identified aggregate metrics only. No Personal Data after anonymisation is complete. | EU region. Google Cloud DPA and SCCs. |
| Resend Inc. | Transactional email delivery (weekly reports, account notifications) | Controller user names and email addresses. Reports contain derived metrics, not patient data. | USA. UK Addendum to EU SCCs. |
This schedule was last updated May 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 patient names, email addresses, phone numbers, full dates of birth, or clinical content. 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. 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 only.
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) and at rest (AES-256 or equivalent). Backups encrypted at rest. 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. All Personal Data access events logged. Audit trails retained for a minimum of 12 months. Anomaly detection on access patterns.
Vulnerability management. Regular dependency patching. Vulnerability scanning at least quarterly. Critical vulnerabilities patched within reasonable timeframes proportionate to severity.
Penetration testing. Penetration testing or equivalent security assessment at least annually.
Environment separation. Production, staging, and development environments separated. Personal Data not used in non-production environments unless anonymised.
Backup and recovery. Encrypted backups. Tested disaster recovery procedures. Defined recovery point and recovery time objectives.
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. Security awareness training. Access reviews at least quarterly. 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.