The database refuses
Every table carries a clinic ID, and Postgres row-level security is enabled and forced on all of them. The application connects with a role that cannot bypass those policies, and an automated test fails if that ever changes.
Save file: protected
Your data stays in its room
Every clinic on Mediora shares one system, so separation can't depend on a developer remembering a filter. The database itself refuses to show one clinic another clinic's data.
Separation in three layers
Each layer would stop a leak on its own. Deepest first.
Every query is scoped
Each database query runs inside a transaction that first sets the clinic from your verified login. Developers never type the clinic filter by hand, so nobody can forget it.
Every request is checked
Your login token carries your clinic and role. A request that can't be tied to a clinic never reaches the code that reads data, and each role only reaches the screens it's allowed to.
Two clinics, one database
A small model of how it works. Switch clinics, then try to read or write the other clinic's patients.
Maple Dental
Run a query
| tenant_id | name | phone |
|---|---|---|
| clinic_a | Ayesha K. | +92 300 •••• 567 |
| clinic_b | Liam W. | +61 491 ••• 188 |
| clinic_a | Emily C. | +44 7700 ••• 142 |
| clinic_b | Omar S. | +92 321 •••• 890 |
| clinic_a | Maria L. | +1 512 ••• 0142 |
| clinic_b | Chloe N. | +61 491 ••• 131 |
Dimmed rows exist, but the policy hides them from a Maple Dental session.
What the app sees
-- set from your verified login, never from the request
SET app.current_tenant_id = 'clinic_a';
SELECT name, phone FROM patients;3 rows
- Ayesha K.+92 300 •••• 567
- Emily C.+44 7700 ••• 142
- Maria L.+1 512 ••• 0142
Only Maple Dental's patients come back. The other clinic's rows are not filtered out by the app: the database never returns them.
What else is built in
Specifics, so your compliance team doesn't have to guess.
Accounts and sign-in
- Passwords
- Hashed with Argon2id. At least 12 characters, with upper case, lower case and a number.
- Sessions
- Access tokens last 15 minutes. Refresh tokens last 30 days, can be used once, and a reused one is detected.
- Lockout
- Ten failed sign-ins for one email within 15 minutes locks that email for 15 minutes.
- Rate limits
- Sign-up, sign-in and token refresh are rate-limited per IP address, and so is every other request.
- New staff
- Invited staff get a one-time temporary password and must change it the first time they sign in.
When someone leaves
- Suspension
- The owner suspends a staff member and their next request is refused, on every device. Open live connections are re-checked every 30 seconds.
- History
- Their past appointments, messages and notes stay intact and attributed to them. Nothing is hard-deleted.
- Seats
- A suspended account frees its plan seat straight away.
The clinical record
- Who can read it
- Doctors write notes and prescriptions, the owner can read them, and receptionists cannot open them at all.
- Drafts
- A draft note is visible only to the doctor writing it. Others can't even tell it exists.
- Signing
- A signed note can never be edited, by anyone. A database trigger enforces it. Corrections are added as dated addenda.
- Prescriptions
- Issued prescriptions are frozen. Voiding one records who did it, and a reissue starts a new draft linked to the original.
The AI assistant
- No clinical access
- The assistant's tools cannot read clinical notes or prescriptions. That's how the system is built, not an instruction it's asked to follow.
- No identity guessing
- The assistant never chooses which clinic or which patient it acts for. Both are fixed from the conversation before it runs.
- Off by default
- The owner switches it on. Booking and cancelling are separate switches, and a per-conversation hourly cap stops reply loops.
Records you can trust
- Audit log
- Every successful change is logged with who made it, their role at the time, what changed, when, the IP address and the browser.
- Append-only
- The database rejects edits and deletions of audit entries.
- No clinical copies
- Clinical content is left out of the audit log, so it stays readable only by the people allowed to read the record.
- Secrets
- WhatsApp access tokens are encrypted with AES-256-GCM and are checked with Meta before they're saved. Secrets are redacted from the audit log.
Data that adds up
- Money
- Prices are stored as whole minor units (cents, pence, paisa), never as floating-point numbers, so totals don't drift.
- Time
- Every clinic has its own timezone. Hours, reminders and daily totals follow clinic time, including daylight-saving changes.
- Double bookings
- A database constraint makes it impossible to book one doctor into two overlapping appointments, even when two people click at the same moment.
The numbers
- Access token
- 15 min
- Then a single-use refresh.
- Hard deletes
- 0
- Staff, services and patients are archived.
- Credential cipher
- AES-256
- GCM mode, for WhatsApp tokens at rest.
- Tables with RLS
- All
- Enabled and forced on every one.
What we haven't done yet
Good security includes being clear about the gaps. These are the ones a careful buyer should know about today.
Report a security issue
Security
Found something that looks wrong? Email security@mediora.app with what you saw and how to reproduce it. Please don’t access other clinics’ data while testing. We’ll confirm we received your report and keep you updated while we fix it.
Security questions
Can another clinic see our data?
No. Every record carries your clinic's ID, and the database itself enforces row-level security on every table, so a query made for one clinic cannot return another clinic's rows even if application code has a bug. The application also connects with a database role that cannot bypass those rules.
What happens when a staff member leaves?
The owner suspends them. Their very next request is refused, on every device, and their seat frees up immediately. Their past appointments, messages and notes stay intact, because nothing in Mediora is ever hard-deleted.
Is Mediora HIPAA, UK GDPR or SOC 2 certified?
Not yet. We have not completed a formal compliance audit or certification. The security page lists exactly what the system does today, so your compliance team can judge it against your obligations, and we're happy to answer their questions directly.
Who owns the patient data?
Your clinic does. Mediora stores and processes it on your behalf to run the service. Archived patients, staff and services are kept rather than deleted so your history and reports stay correct.
Is there an audit trail?
Yes. Every change made in Mediora is recorded with who did it, their role, what changed, when, and from which IP address. The database refuses edits or deletions of audit entries. Clinical content is deliberately left out of the audit log so it stays visible only to the people allowed to read it.
Continue?
Bring your compliance questions to a demo. We'll walk through the architecture with whoever needs to sign off.
Or start free