How patient data is protected

Every record lives under its clinic, and the boundary is enforced in the database rather than in application code. 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.

That is a strong claim, so it is tested rather than asserted. A test suite runs the real rules files against two clinics' staff and asks each to reach the other's records: patients, clinical notes, photographs, appointments, money and the logs. The same suite asserts the opposite direction, because a system that denied everything would pass a test that only checked for refusals.

Permissions are per person and grouped into modules, so clinical records are separable from the rest: the front desk can book an appointment without being able to read what was recorded in the room. Export is its own permission, separate from being able to look at something.

Five roles come built in and a clinic can define its own. Removing somebody takes effect at the database, not just in the interface — it stops an open tab as well as a fresh login, and file downloads as well as page loads.

Two records, because they answer different questions.

Record access is kept as one row per person, per patient, per hour with a count on it, rather than one row per read. A log of every database read is a volume nobody reads back, and it answers the question that matters — which records did this account open — no better. It stores the record's id and never the patient's name: a log read by somebody investigating a leak should not be a second copy of what it protects.

Both are exportable, and exporting either is itself written down.

Images are not served from a permanent link. Each request checks the viewer's permission and then redirects to a URL signed for fifteen minutes, so a link that leaves the panel is a dead link by the time it is read. Opening one is recorded in the access log alongside opening the record itself.

Sessions are carried in a signed, HTTP-only cookie. A long idle period signs you out, everywhere somebody can be signed in — a panel left open on a front desk is a real risk rather than a theoretical one, and a warning appears before it happens so nobody loses work.

Patient records, files and authentication run on Google Cloud in europe-west1, Belgium. Data is encrypted in transit and at rest.

Three companies receive data on our behalf, each under a data processing agreement, and the full list with its purposes and locations is in the processing agreement. One of them is the AI assistant: what a patient types into the chat widget, and the records that answer a staff question in the panel, reach it. Under our agreement it may not be used to train models.

Backups age out on their own cycle. Deleting something moves it to a recycle bin for thirty days and then removes it; a clinic can set shorter windows for conversations, appointments and financial records, and the purge runs nightly and records what it did.

No analytics, no session replay, no tag manager, no advertising pixels — on the marketing site or in the panel. Nothing about a patient is sent to a third party we have not named. The clinic's data is not used to improve the product for anybody else.

A security page that lists only strengths is a brochure. These are the gaps a clinic would find out about anyway, and it is better to hear them here.

Clinic+ is not certified under HIPAA and does not currently sign Business Associate Agreements. If that is what you need, tell us — it changes what we build next.

If you believe you have found a vulnerability, or that a clinic's data has been exposed, write to security@clinicplus.io. If it affects a clinic's data we will tell that clinic within 48 hours of becoming aware, with what happened, which categories of data and how many records were exposed, and what we are doing about it.