Security
Putting your patients' files into software the clinic does not own is a decision that needs detail, not reassurance. This page lists what protects your clinic's data, where each control is enforced inside the system, and then says what the system cannot protect on your behalf.
The controls
Not general promises: each control has one place it is enforced, written beside it. Show it to any developer who knows databases and they will know exactly what it means.
Every screen inside the system sits behind an authenticated account. There is no share link that opens a patient's file for whoever holds it, and no internal page that reads without signing in. The session is kept in a cookie no script in the browser can read, and every request is checked before it reaches any data.
Enforced atSupabase Auth + request middleware, httpOnly cookie
Four roles: clinic owner, doctor, assistant, and the platform's own administrator. Each has a list of named permissions — who edits a visit, who sees stock, who reads the audit register — and the owner can take a permission away from a role but cannot grant one above that role's own ceiling. Revoking a staff member's access takes effect the moment it is done.
Enforced atROLE_PERMISSION_MATRIX
The separation is not a condition in the screen that can be forgotten; it is a policy on the table itself. A query that does not name the clinic does not return another clinic's rows — it returns nothing. And if you run more than one branch, moving between them is itself a named permission.
Enforced atPostgreSQL row-level security policies
Adding a patient, editing a visit, issuing a prescription, a stock movement, an expense, a change to the clinic's staff or to the subscription: each writes a line carrying who did it, which record it touched, and the value before and after. The clinic owner reads that register on the audit screen inside the system.
Enforced ataudit_logs table · Audit screen
Scans, lab results and proof-of-payment images are held in a store that is not public: none of them opens from a direct link or by guessing an address, and only someone on the staff of the clinic that owns the file can read it. The one public thing is the clinic's logo, because it is printed on the clinic's own documents.
Enforced atPrivate Supabase Storage buckets (public = false)
The ticket page opens with a number and a code, and needs no account. The code is stored hashed, so nobody — including us — can retrieve it or send it on, and the session it opens ends after twenty-four hours. The page is also kept out of search results.
Enforced atHashed code · signed 24-hour session
What the AI may do
The booking assistant and the clinic assistant are optional, each added as a line on the subscription. Their limits are written into the system, not promised on a marketing page.
The assistant prepares a suggested time or a tidied note and shows it as a draft. Nothing enters a patient's file or the appointment book until the person responsible has read it and accepted it themselves.
Using the assistant is a doctor's permission, not something everyone who opens the system has. Consumption counts against the subscription's limit and is recorded, so you can see how much was used and where it stops.
No diagnosis, no choice of drug or dose, no treatment decision. Those belong to the treating doctor, whose name is the one printed on the prescription and whose responsibility it remains.
What stays with the clinic
Everything above protects the data from outside and from other roles. What is left sits inside the clinic, and we say it plainly because leaving it out would imply protection that does not exist.
The invitation is the most important security decision in your hands: after it, the account sees everything its role allows. Review the clinic's staff list from time to time, and revoke access for anyone who has left on the day they leave, not a month later.
A shared account at reception defeats the register and the permissions at once: everything done is attributed to one person, and everyone sees whatever the most privileged of them can see. Give each person their own account, and lock the screen when leaving it.
To follow up a problem, the booking or request number and the name of the screen are enough. Do not put a full medical history or a lab image into a support message: it is not needed, and the file's place is inside the system.
Tell us from the support page, and write exactly what you did, what you expected to happen, and what actually happened. Your ticket reaches the same team that writes the system, and the reply comes in that same conversation. Please do not test what you found against another clinic's data, and do not publish it before we have fixed it.