Home › Security & your data
Your clinic’s records, and who can reach them
Multi-tenant software means many clinics share one system. What matters is what enforces the separation — and whether anyone has ever tested it.
Enforced by the database, not by application code
Almost every modern veterinary system is multi-tenant: many practices share one installation, with a column somewhere recording which records belong to whom. The usual approach is to add a filter to every query. It works until somebody writes a query that forgets it — and there is no warning when that happens, only a screen showing another clinic’s patients.
VetCentra puts the boundary a layer lower. Every tenant table carries the clinic it belongs to and has a PostgreSQL row-level security policy on it. The application connects as a restricted role and sets the current clinic per transaction. A query that forgets the filter does not leak — it returns nothing, because the database refuses.
That applies to us as well. Even a platform-level query has to declare itself, and the raw connection is limited to the two tables that must be readable before any clinic context exists — the ones login needs to find a user.
And it is proven, not asserted
An isolation check runs against the live schema and has to pass before anything is deployed. Beyond it, an API suite of over six hundred tests exercises the policies over real HTTP rather than by reasoning about them. Both run against a database that mirrors production.
What we can see
Support can sign in to a clinic to help with a problem. When that happens the session records who is really behind it, a bar sits across the top of the screen for the entire visit, and the visit is written into that clinic’s own audit log before the session is handed over. Your staff’s live sessions are untouched — real people are working in them.
We do not use one clinic’s data to inform another’s, and we do not sell it. Records belong to the practice that created them, and are exported and deleted on request when an account closes.
What holds when someone makes a mistake
Security is not only about outsiders. Most of what goes wrong in a clinic system is ordinary: a wrong figure typed, a permission left on, a record deleted in a hurry.
Isolation lives in the database
Every record carries the clinic it belongs to, and PostgreSQL refuses to return another practice’s rows even when a query asks for them. Not a filter in application code that a future change might forget.
Records are append-only
A consultation cannot be deleted. Stock movements cannot be edited. Payments and credit notes are insert-only. Invoice numbers are gapless and never reused, enforced by database triggers.
Permissions end when you end them
Roles and per-person permissions are the clinic’s own. Anything that narrows access — a role change, a deactivation, a password reset — ends that person’s active sessions rather than waiting for a token to expire.
Everything sensitive is journalled
Who did what, and when. That includes us: if support signs in to your clinic to help, the visit is written into your audit log and a bar sits across the top of the screen for the whole session.
Reading this to compare vendors? The useful question to ask any of them is: is tenant separation enforced in the database or in application code, and is there an automated test that proves it? The answer tells you a lot about the rest of the work.
Ask us the uncomfortable questions
We would rather answer them now than have you find out later. Message us and ask anything about how your data is held.