What we connect to, what we read, what you are responsible for, and the evidence behind our security and transfer commitments
This guide is written for the person at a clinic who checks a supplier before connecting it to patient systems. It is factual rather than contractual: the Data Processing Agreement and Master Services Agreement govern, and this guide explains how the live system meets them. Where it offers guidance on your own obligations as controller, that is general information to confirm with your own adviser, not legal advice.
You create an API credential in your practice management system and paste it into ClinicSignal. ClinicSignal stores it encrypted (AES-256-GCM) and uses it only to read. Every request ClinicSignal makes is a read request; the integration has no write path to any system we connect to.
| System | Credential | What the credential can do | Our recommendation |
|---|---|---|---|
| Cliniko | API key generated by a Cliniko user | Inherits that user's permissions. Cliniko does not offer a read-only key. | Create a dedicated user with the Power Receptionist role, which can read appointments, patients and invoices but has no access to treatment notes, and generate the key from that user. ClinicSignal never requests notes regardless of the key's permissions. |
| Nookal | Client ID and API key | Read access to the Nookal API for your account. | Use the key only for ClinicSignal so it can be revoked independently. |
| WriteUpp | API key | The WriteUpp public API v1 is read-only. | None needed. |
| PracticeHub | API key plus application identifier | Read access to your PracticeHub account. | Use the key only for ClinicSignal. |
| Splose | API key (expires, typically annually) | Read access to your Splose account. | Re-issue the key when it expires; ClinicSignal tells you when a key stops working. |
Revoking or regenerating the credential in your system stops all further access immediately.
Our connectors request specific resources and map named fields from each response. Fields that are not on the list are discarded before anything is stored. For Cliniko, the resources are: individual appointments, group appointments and attendees, patients, practitioners, businesses (locations), appointment types, billable items, invoices and invoice items, referral sources, patient cases, contacts (referring practitioners), practitioner availability and unavailable blocks. The other systems supply the same categories through their own APIs.
From the patient resource we keep the practice-system patient ID, an age band derived from the date of birth, marketing-consent flags and referral source. Names, email addresses, telephone numbers and dates of birth are discarded on import. They are fetched again, from your system and for that screen only, when you open a recall worklist or export it.
We never request treatment notes, medical alerts, clinical attachments, documents, body charts, letters, patient messages or communication history, and the connectors contain no code to do so.
Field by field, this is what is kept from each resource:
| Resource | Kept | Received and discarded |
|---|---|---|
| Patients | PMS patient ID, age band derived from date of birth, referral source name, email and SMS marketing-consent flags, first and last visit dates | Name, email address, phone numbers, address, date of birth |
| Appointments | Start and end time, status, appointment type, practitioner, location, price, the coded cancellation reason, whether it was booked online | The free-text cancellation description, and Cliniko's administrative "notes" field on the booking; both are returned with the appointment and discarded unread. Neither is a treatment note: treatment notes are a separate resource that is never requested. |
| Group sessions and attendees | Session time, type, practitioner, attendee patient IDs and arrival status | Everything else |
| Invoices, items and payments | Amounts, dates, status, linked appointment and patient ID, item names and prices | Billing addresses, payment card details (never requested) |
| Practitioners | Name, role, active status, rostered hours and availability windows | Contact details; reasons for unavailability are never read |
| Patient cases | Case dates, session and billing limits, referral type, closed status | Case names and notes |
| Referral sources and contacts | Referral source names; referring practitioners' name, organisation, occupation, provider number | Contact details |
| Appointment types, locations | Names, durations, prices, addresses | Nothing else is returned |
Because we only store named fields, clinical content can reach ClinicSignal in one way: if it has been typed into a catalogue name we store. Those are appointment type and service names, referral source names and practitioner names. Free-text cancellation descriptions used to be stored; since 18 October 2026 they are discarded unread and the historical ones have been cleared, so nothing a receptionist types about an individual cancellation reaches us.
So the obligation in DPA clause 11 comes down to this: do not put clinical details about individual patients into those catalogue names. "Shockwave 30 min" is fine; an appointment type named after a specific patient's condition is not. If a response from your system ever contains unexpected content in a field we read, the responsibility for our handling of it is ours under the DPA; the responsibility for what was typed into your system is yours.
You remain the controller for patient, practitioner and prospective-patient information, so you decide the lawful basis. Appointment types and practitioner assignments can imply health information, which is special category data. Most clinics we work with rely on the following, and you should confirm the position for your own practice:
Your notice should also mention that the analytics service is hosted in the United States under standard contractual safeguards, that an AI service generates written explanations from aggregated figures, and that anonymised totals contribute to sector benchmarks unless you opt out. Connecting ClinicSignal does not itself create a lawful basis or patient consent, and we do not contact your patients. A pre-filled DPIA support pack is available for clinics that record a Data Protection Impact Assessment.
ClinicSignal's application and database are hosted by Railway in the United States. Our AI provider (Anthropic) and email provider (Resend, operated by Plus Five Five, Inc.) also process information there. For each we rely on the supplier's data processing agreement incorporating the EU Standard Contractual Clauses with the UK International Data Transfer Addendum; Railway additionally participates in the UK Extension to the EU-US Data Privacy Framework. Copies of the supplier agreements we rely on are available to customers on request from dpa@hmdg.co.uk, and the current list is Schedule 1 of the DPA.
Three related facts that reviewers often ask about: the signed-in application is served by Railway directly and does not pass through Cloudflare, which hosts only the public website; our application logs record request URLs (with patient references redacted) and status codes, never response bodies, so names fetched on demand are not written to logs; and we use no third-party error-monitoring or analytics tool inside the signed-in application. Earlier versions of the DPA listed Neon and Google BigQuery as suppliers; clinic data was never held in either, and both were removed from Schedule 1 in October 2026 to correct the record.
An independent reviewer examined the ClinicSignal application in May 2026 across four areas: application security, data handling, architecture and operational practice. The review covered authentication and session handling, tenant isolation (that one clinic cannot reach another's data), credential storage, input handling on exports and uploads, outbound requests, dependency hygiene and secret management.
It raised two high-priority findings and a set of medium and low ones. All were closed by June 2026. The high findings concerned secret hygiene (historic credentials in the source history, which were purged and every live credential rotated) and the absence of a usage cap on the Advisor (now capped per clinic and globally). The remaining fixes included rate limits on sign-in links, constant-time comparison for API credentials, protections against spreadsheet-formula injection in exports, restrictions on server-side outbound requests, a least-privilege database role for the application, encryption of stored credentials with a database-level check that nothing is stored in plain text, browser security headers, and automated secret and dependency scanning on every change.
Tenant isolation was reviewed and confirmed: every data path is scoped to the signed-in clinic, backed by a test that scans the codebase for unscoped queries. The reviewer's closeout summary is available to customers on request.
The Advisor answers questions from structured metrics that ClinicSignal assembles. ClinicSignal itself never includes patient names, contact details, dates of birth or clinical records in what it sends to the AI provider. Practitioner names and roles may be included so that answers about your team read naturally.
The question you type is sent to the AI provider as you entered it, and is kept with your clinic's account so HMDG can support you; it is deleted automatically after 12 months, with your data when you leave, or earlier on request. An owner can switch the Advisor off for the whole clinic in Settings. The AI provider does not use it for training and, under its standard commercial API terms, deletes inputs and outputs within 30 days, except where retention is required to enforce its usage policy or by law. There is no filter that removes patient details from free text. You and your users are responsible for what you enter: ask about patterns and numbers, not about named patients, and do not paste clinical records. This is a condition of use in the MSA. The full structure of what the Advisor sends, with illustrative figures, is published as the Advisor AI payload sample.
A line you can paste into your record of processing activities: "Business analytics. Processor: HMDG Limited (ClinicSignal), ICO ZB365505. Data: appointment, billing, practitioner and pseudonymised patient records from our practice management system; patient contact details fetched transiently for recall lists. Purposes: utilisation, attendance, rebooking, revenue and practitioner reporting; recall worklists; marketing attribution; AI-assisted explanations; sector benchmarking (opt-out available). Location: USA (Railway, Anthropic, Resend) under the UK Addendum to the SCCs; Railway also in the UK Extension to the Data Privacy Framework. Retention: life of the agreement, deleted within 30 days of termination or request (backups 90 days)."
ClinicSignal imports your full appointment and billing history and keeps it while you use the service. That is deliberate: year-on-year comparisons, patient cohort analysis (how many of last year's new patients returned) and benchmarks all need the history. If your clinic prefers a shorter window, you can instruct us in writing to delete records older than a date you choose (DPA clause 12.1); the comparisons that rely on them will then be unavailable.
These are three separate actions, and doing one does not do the others:
Deleting from ClinicSignal does not touch the records in your practice management system, nor any exports your team downloaded. Benchmark figures are stored only as totals for cohorts of 20 or more clinics, with no row for your clinic, so figures already computed remain after you leave but your contribution cannot be separated out of them. Your clinic is excluded from every computation after your data is deleted.