When you sign up for cloud clinic software, your clinic's data sits on shared infrastructure alongside thousands of other clinics. The thing standing between your patients and someone else's is how the software isolates tenants. Two terms describe it (multi-tenancy and Row Level Security), and they're worth understanding before you trust a vendor with patient data.
What "multi-tenant" means
A multi-tenant application is one system serving many independent customers: the tenants. For clinic software, each clinic (and, for a group, each branch) is a tenant. Everyone shares the same application and database, but each tenant must only ever see their own data.
The convenience is real: instant updates, no servers to run. The risk is also real: if isolation is weak, a bug (or a developer who forgets a filter) can expose one clinic's records to another.
Where most isolation goes wrong
Many systems enforce separation in application code: every query is supposed to add "…where clinic = this one." It works until one query forgets. There's no safety net: the filter is a convention, and conventions get missed under deadline pressure. "We hide other clinics in the interface" is this weak form, and it's not enough for health data.
What Row Level Security adds
Row Level Security (RLS) moves the rule from application code into the database itself. With RLS, the database decides which rows a query is even allowed to see or change, based on the logged-in tenant. It enforces that on every query, automatically. A developer can't forget it, and bypassing the UI to hit the API directly doesn't help: the database still refuses to return another tenant's rows. (PostgreSQL documents this as row security policies.)
When RLS is not just enabled but forced, it applies even to the table owner: the strongest form of "this row is not yours to read."
Why a clinic should care
This isn't abstract. Under India's data-protection rules, a clinic is the data fiduciary responsible for keeping patient data secure (see our DPDP primer). Database-enforced isolation is how you make "we keep clinics separate" a guarantee you can stand behind, not a hope. For a multi-branch group, it's also what stops one location from reading another's patients.
The question to ask any vendor: "Is tenant isolation enforced in the database, or only in the application?" If the answer is vague, treat it as a no.
How Avinya Plus does it
In Avinya Plus, PostgreSQL Row Level Security is enabled and forced on the tenant-scoped tables (patients, appointments, prescriptions, records, invoices, and more), with policies that require an explicit clinic membership. One clinic can't read another's rows, even via the API, and every access is written to an audit trail.
Strong isolation should be a default you can verify, not a promise you take on faith. Book a demo from the menu to walk through how data stays separated.
Sources
Run your clinic on Avinya Plus.
Patient records, GST billing, and scheduling in one system your team will actually use.