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."
A worked example
Picture two clinics, Sunrise and Lotus, signed up to the same software. Their patient records live in the same database, in the same table, mixed together row by row. When Sunrise's receptionist opens the patient list, the software asks the database for "all patients." Without isolation, that question would return everyone's, Lotus included.
With Row Level Security, the database does something extra before it answers: it checks who is asking. It sees the request is coming from a logged-in Sunrise account, so it quietly attaches "…and only the rows that belong to Sunrise" to the question, every single time. Lotus's rows are still sitting right there in the same table, but the database simply will not hand them over. Sunrise's screen cannot show Lotus's patients, because the data never leaves the database in the first place. There is no filter for a tired developer to forget, and no clever request that gets around it, because the check happens inside the database rather than in the part of the software a person wrote.
Shared database or a database each?
There are two honest ways to keep clinics apart. One is to give every clinic its own separate database (a database per tenant); the wall between them is the fact that they are physically different stores. It feels reassuring, but it gets expensive and slow to operate at scale: every update, backup and migration has to be repeated across thousands of databases, and small clinics end up paying for idle capacity. The other is one shared database where Row Level Security draws the wall inside it, per row. Shared-with-RLS is what most modern cloud software uses, including Avinya Plus, because it keeps the system simple to run and update while still letting the database (not human discipline) enforce the boundary. The trade-off is that the isolation is now a rule rather than a wall, which is exactly why it matters that the rule lives in the database and is forced.
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.
What to ask a vendor
You don't need to be technical to test this. A few plain questions separate a real answer from a comfortable one:
- Is isolation enforced in the database, or just hidden in the interface? "We don't show you other clinics on screen" is not isolation. Ask whether the database itself refuses to return another clinic's records.
- Is the rule still enforced for admin tools and direct API access? The interface is only one door. Ask whether the same boundary holds when a request goes straight to the system, and whether it applies even to the highest-level database accounts (this is what "forced" means).
- Is every record access logged? If something ever did go wrong, can the vendor show who looked at which record and when? An audit trail is the difference between investigating an incident and guessing about one.
- For a group, is each branch isolated too? If you run more than one location, ask whether one branch can read another's patients, and how that is stopped.
If the answers are clear and specific, that is a good sign. If they are vague or reassuring without detail, treat it the way you would any other unverifiable claim about patient safety.
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.
Frequently asked questions
- How does clinic software keep my data separate from other clinics?
- Cloud clinic software is shared infrastructure, so isolation depends on how tenants are kept apart. The strongest approach moves the rule into the database itself, so it decides which records each clinic is allowed to see on every request. In Avinya Plus, that is enabled and forced on patient tables.
- What is multi-tenancy?
- A multi-tenant application is one system serving many independent customers, called tenants. For clinic software, each clinic, and each branch in a group, is a tenant. Everyone shares the same application and database, but each tenant must only ever see their own data.
- What is Row Level Security?
- Row Level Security (RLS) moves the separation rule from application code into the database. The database itself decides which records a query may see or change, based on the logged-in clinic, and enforces that on every query automatically. A developer cannot forget it, even when going around the interface.
- Can another clinic see my patient data?
- Not when isolation is enforced in the database. With Row Level Security enabled and forced, the database refuses to return another clinic's records, even via the API rather than the interface. In Avinya Plus this applies to patients, appointments, prescriptions, records and invoices, and every access is logged.
- Is multi-branch data isolated?
- Yes. For a multi-branch group, each branch is its own tenant. Database-enforced isolation is what stops one location from reading another's patients, because policies require an explicit clinic membership before any record is returned. It is a default you can verify, not a promise you take on faith.