Data protection

Hecate holds appointment and contact data for dental clinics. This page sets out what is held, on whose instructions, for how long, and who else touches it. It is written to be read before you sign anything, not after.

Who is responsible for what

Your clinic is the data controller. You decide why patient data is processed and on what basis. Hecate is the data processor, acting only on your documented instructions under Article 28 GDPR.

A Data Processing Agreement covering those Article 28 terms is provided before onboarding begins, not after. Ask for it during the first call if you want your lawyer to read it early.

What is never stored

No diagnosis. No treatment record. No clinical note. No radiograph, no chart, no prescription.

This is a deliberate boundary rather than a gap in the product. What Hecate holds is scheduling and communication data: a name, a phone number, an optional email and date of birth, which practitioner and which service, when the appointment is, and the messages exchanged to arrange it.

Because no health data is entered, the processing sits under Article 6 as ordinary personal data, not under Article 9 as a special category. That materially narrows what you have to justify and document as a controller. It also means the boundary has to be respected in practice: free-text notes on a patient record are for scheduling context, and clinical detail should not be typed into them.

Separation between clinics

Every clinic is a separate tenant. Separation is enforced inside PostgreSQL itself, using row-level security tied to the connection's tenant, rather than by application code remembering to add a filter. Application-level filtering is applied as well, so a single mistake in either layer does not expose anything.

An automated test that deliberately attempts to read one clinic's records while authenticated as another runs as a build gate. If that test ever succeeds, the build fails and nothing ships.

Support access by our own staff is separate again. It runs under a distinct database role, it requires a written reason for any change, and it records a before-and-after difference of what was altered against the named person who did it.

Patient rights

Access and portability. A patient's complete record, including their message history, exports on request in one action from their record page. You do not need to raise a ticket with us.

Erasure. Deleting a patient requires a written reason, which is stored with the deletion. This exists so that a right-to-erasure request and an accidental deletion are distinguishable afterwards.

Rectification. Patient details are editable directly by clinic staff at any time.

Objection to reminders. Appointment reminders are transactional messages tied to a booking the patient made, not marketing. A patient who asks to stop receiving them can be set not to, without cancelling their appointments.

Retention

Retention is configured per clinic, and the defaults are conservative rather than permissive.

• Inactive patients are erased automatically once they have not been seen for a period you set.
• Message history is purged automatically after a configurable window, and can also be purged manually at any time.
• The audit log has its own retention period and its own purge.

Nothing is retained indefinitely by default. If you need a longer period for accounting or legal reasons, that is a setting, and the reason should be recorded in your own retention policy.

Evidence you can show a regulator

• A Data Protection Impact Assessment is generated from the live system configuration and kept as versioned snapshots, so you can show what the assessment said at a given date rather than reconstructing it.
• The audit log records administrative access to clinic data, attributed to a named person, and exports on request.
• The Data Processing Agreement documents the Article 28 relationship.

Sub-processors

Some processing necessarily happens outside our own systems. These are the parties involved and why.

Sub-processor	Purpose	Location
OpenAI	Reading the intent of an inbound patient message	United States
Meta Platforms (WhatsApp)	Delivering and receiving messages	United States
Twilio	SMS delivery, including waitlist offers	United States
Resend	Transactional email to clinic staff, such as password resets	United States

Transfers outside the European Economic Area rely on Standard Contractual Clauses. This is disclosed here rather than buried, because a clinic acting as controller has to be able to name its sub-processors, and because a page arguing for careful data handling should be straightforward about its own.

Resend delivers transactional email to clinic staff, such as password resets. It has no access to any clinic's patient data. The demo request form on this marketing site does not go through Resend or any other sending service; it is delivered by our own email hosting, and the privacy notice covers it.

Romanian specifics

Alongside the GDPR, processing is subject to Law 190/2018, which implements the GDPR in Romania, and to Law 506/2004 on privacy in electronic communications. The supervisory authority is the ANSPDCP.

Appointment reminders are treated as transactional communications under Law 506/2004 rather than as marketing, because they relate to a booking the patient has already made.

Security

Data is encrypted in transit. Access to the dashboard requires an account created by your clinic administrator, with roles that limit what a practitioner can see compared to an administrator. Authentication endpoints are rate-limited. There is no self-service signup, so no account exists that your clinic did not ask for.

Questions

If something here does not answer what you need, ask before you sign. Requests about a specific patient's data should come from the clinic, since your clinic is the controller and we act on your instruction.