Legal
Data Processing Agreement
The terms on which we hold patient data for a clinic: who decides what, what we are allowed to do with it, who else touches it, where it sits, and what happens when the relationship ends.
Last updated 10 August 2026
01Roles
The clinic is the controller. It decides which patients exist, what is recorded about them, and why.
Clinic+ is the processor. We hold and process that data only to provide the service and only on the clinic's documented instructions — which, in practice, means the settings the clinic configures and the actions its own users take in the panel.
This agreement supplements our Terms of Service and applies whenever we process personal data on the clinic's behalf. Our own controller-side processing is described in the Privacy policy.
02Subject matter, duration and purpose
We process the data described below for as long as the clinic's account is open, plus the deletion window in section 9. The purpose is the provision of practice-management software: scheduling, clinical records, billing, stock, patient communication and the AI assistant that answers on the clinic's behalf.
| Data subjects | Categories of personal data |
|---|---|
| Patients | Identity and contact details, appointment history, clinical records (examinations, tooth charts, prescriptions, vaccinations, measurements), consent records, documents and clinical photographs, financial entries and balances, conversations with the assistant. |
| Clinic personnel | Name, email address, role and permissions, actions recorded in the audit log. |
| Website visitors of the clinic | Messages sent to the assistant before any booking, and whatever contact details they volunteer in order to book. |
Clinical records are special category / sensitive personal data under most regimes, including GDPR art. 9 and KVKK art. 6. Both sides process them on that footing.
03Our obligations as processor
We process only on the clinic's instructions, and we tell the clinic if an instruction appears to breach applicable data protection law rather than quietly carrying it out.
Everyone with access is bound by confidentiality. We do not use clinical data to train models, we do not sell it, and we do not process it for our own purposes.
04Security measures
Isolation between clinics is enforced at the database, not in the application layer. Access rules check a signed membership claim on every read and write, so a query that omits or fakes a clinic scope fails rather than returns another clinic's rows — the boundary holds even when the code above it is wrong.
Permissions are role-based and set per member, with clinical records and sensitive financial fields isolated as their own modules so access can be narrowed to the people who need them. Exports are a separate permission and are written to an audit log.
Data is encrypted in transit and at rest by the platform. Authentication sessions are carried in a signed, HTTP-only cookie. Production access by our staff is limited to operating the service and answering support requests.
05Sub-processors
The clinic authorises the following sub-processors. Each is bound by terms no less protective than these.
| Sub-processor | Purpose | Location |
|---|---|---|
| Google Cloud / Firebase | Database, file storage, authentication, application hosting | europe-west1 — St. Ghislain, Belgium |
| Resend | Transactional email: confirmations, reminders, magic links | us-east-1 — United States |
We will give 30 days' notice before adding or replacing one. If the clinic reasonably objects on data-protection grounds, it may terminate without penalty for the remainder of the term.
06International transfers
Clinical records are stored in the European Union. Transactional email means a recipient address and the contents of that message reach the United States.
Where the clinic is in the European Economic Area, transfers rely on the European Commission's Standard Contractual Clauses, which form part of this agreement with their annexes completed. A clinic in the United Kingdom gets the same clauses plus the UK Addendum; a clinic in Switzerland gets them with the Swiss amendments. Which one attaches is decided from the country the clinic gives us, at the moment it accepts — not later, because nobody reviews a self-serve account in between.
One case deserves naming rather than burying. A clinic operating in Türkiye is transferring health data abroad the moment it uses the service, since the data sits in Belgium. Under KVKK art. 9 that needs its own mechanism, and Türkiye has issued no adequacy decision for any country — so a standard contract notified to the Board, or an undertaking, is the practical route. Clinics in that position should raise it with us before signing.
07Where the processor sits
The processor is a United States company. The data is in Belgium. The storage location does not settle the question on its own.
Because our own staff administer the service from outside the EEA, a controller in the EEA should treat access by us as a restricted transfer even though the storage never leaves it. The mechanism in section 6 covers that access as well as the mail route, and Annex I.B of the clauses describes it on that footing rather than pretending the Belgian storage location settles it.
08Helping with patient requests
Most requests need no help from us: the panel lets the clinic find, correct, export and delete a patient record directly, which is faster than any ticket we could open.
Where a request cannot be satisfied through the panel, we assist within a reasonable period. If a patient contacts us directly, we do not act on their record — we tell them to contact their clinic, and inform the clinic that they tried.
09Personal data breaches
If we become aware of a breach affecting the clinic's data we notify the clinic without undue delay and in any case within 48 hours, with what we know: what happened, which categories and roughly how many records are involved, the likely consequences, and what we are doing about it. Whether the supervisory authority and the patients must be told is the controller's decision, and we give the clinic what it needs to make it.
10Return and deletion
The clinic can export its data at any time while the account is open, and after termination for as long as the window in the Terms allows. After 90 days we delete it from live systems; backup copies age out on their own cycle and are not restored selectively. Where law requires us to keep something longer, we keep only that and only for as long as required.
11Audits
We make available the information needed to demonstrate compliance with this agreement. Where the clinic requires an audit, it may be satisfied by our documentation and a completed security questionnaire, with an on-site audit no more than once a year , on reasonable notice and without disrupting the service for other clinics.
12How this is agreed
This agreement takes effect when the clinic accepts it, and applies for as long as we process personal data on its behalf. Acceptance happens once, when the clinic is created: a single tick binds the Terms of Service, the Privacy policy and this agreement, together with whichever transfer clauses the clinic's country calls for.
What is recorded is more than a yes: the version of the document set, the timestamp, who accepted and under which email address, the country given, the instruments that attached, and the IP address and browser it came from. It is written in the same operation that creates the clinic — so no clinic exists without one — and stored so that the clinic's own administrators can read it and nobody can alter it, including us.
Clinics that need a countersigned copy, or their own paper instead of ours, should write to hello@clinicplus.io. The processor under this agreement is Pull House LLC, 8 The Green, Suite 23111, Dover, DE 19901, United States, trading as Clinic+. Governing law is the State of Delaware, United States.