What follows describes, in plain terms, how the software actually behaves today. It is accurate, and it is not a substitute for the policy itself. If you need the binding version before it is published, ask us and we will tell you where we are with it.
Data about a clinic — its name, its plan, who works there, what it is billed. We decide how that is used, so we are the controller of it.
Data about a patient — their record, their history, their photographs and radiographs. The clinic decides how that is used; we only hold and process it so the clinic can run its practice. We are the processor of it, and the difference is not decorative: it is why we cannot simply decide to keep, read or reuse patient data.
Our own console shows how busy each clinic is — counts of staff, patients and cases, and when a clinic was last active. There is no screen anywhere in it that opens a patient record or a case, and that is enforced by the database rather than by not building a button.
The one exception is a support ticket. When a clinic writes to us, we read what it wrote. The form asks for the case reference rather than the patient, and if patient information does end up in a ticket we can remove the content of that message on request, keeping only the fact that it was removed.
Within the European Union. Payments, when they are introduced, will be handled by a hosted payment provider — we will never hold a card number.
For as long as the clinic is a customer. When an account closes, its data is kept for ninety days so the clinic can export it, and is then erased. That is a deadline on us, not an intention.
A patient's rights are exercised through their clinic, which is their controller: the clinic can export everything held about one patient, and can erase them. Erasing removes what identifies the person and keeps the production record of work already done, which has its own retention obligation.