To vet a clinic software vendor on security, make them demonstrate five things live in the demo, not on a slide: per-user logins, an audit trail that names who viewed, downloaded, or edited each record, database-level isolation between branches, a one-click export of all your data, and a straight answer on where the data is hosted and who can reach it. If any of those is hand-waved, that is your answer.
This post is security-only. The broader buyer's interview, covering GST billing, support, and contract terms, lives in questions to ask before you buy clinic software. Here we go deep on the five controls that decide whether your patient records are actually protected, and the red flags that tell you they are not. It is a deepening read under the patient data security playbook, so use them together.
Why this sits with you and not the vendor: under India's Digital Personal Data Protection Act, 2023, your clinic is the data fiduciary for every patient record, and that duty to safeguard the data stays yours even when a vendor processes it on your behalf. You cannot outsource the responsibility. So the demo is your due diligence, and these are the things to make the salesperson prove.
Control 1: per-user logins and role-based screens
Ask each staff member to be a separate person in the system. NIST's small-business security fundamentals put access control first for a reason: each user should have their own account, and people should only reach the data their job needs. A clinic is the textbook case. Your receptionist books appointments and should never open a clinical note. Billing works the ledger. The doctor sees the chart. The owner sees oversight.
In the demo, ask the vendor to log in as a receptionist and then try to open a patient's diagnosis. If the screen simply hides the link but the data is still reachable, that is cosmetic, not enforced. Real role-based access changes what each role can load underneath, not just what the menu shows. This is the difference between an interface that looks tidy and a system that actually contains who can see what. We unpack the role design itself in staff roles and access control.
For reference on what enforced roles look like: Avinya Plus changes the screens by role, so reception lands on the calendar, billing on ledgers, doctors on charts, and the owner-admin on oversight.
Control 2: an audit trail that names the user
Per-user logins are only half the control. The other half is the record of what each user did. Ask the vendor to show you the audit trail, then ask one sharp question: does it log views and downloads, or only edits? A log that records edits but not who opened or exported a record cannot answer the question a patient or a regulator asks after an incident, which is "who saw my file?"
A good audit trail records every create, update, delete, view, and download, with the actual user attached to each entry, not a generic "admin." Make them open a real patient record on screen and then show you that the view was logged against a named user. If they cannot produce that, the accountability you would need after a problem does not exist. This is the spine of audit trails for clinics.
Avinya Plus logs create, update, delete, view, and download actions, each attributed to the user who performed it. That is the standard to hold every vendor to.
Control 3: database-level isolation between branches
This one matters even if you run a single clinic today, because it tells you whether the product was built to keep data separated properly. Ask: if I open a second branch, is each branch's data isolated at the database level, or just filtered in the interface? Filtering in the interface means one bug or one misconfigured query can leak Branch A's patients into Branch B's screen. Isolation at the database means the separation holds even if the application layer is wrong.
The honest technical answer here is a phrase like row-level security in the database, where the rule that says "this row belongs to this branch" lives below the application and is enforced on every query. Avinya Plus isolates each branch using PostgreSQL Row Level Security, so one login can move between branches with permission while the data stays separated underneath. You do not need to be a database engineer to ask the question; you need the vendor to answer it without retreating to "it's all secure."
Control 4: a one-click full data export
Your data is the one asset you cannot rebuild, and the ability to leave with all of it is itself a security control. A vendor who cannot hand you your data is a vendor who can hold it hostage. Make them run the export during the demo: the full patient list, visit history, service catalogue, and billing, in a format you can actually open, like CSV or Excel.
Watch for "we'll arrange that for you," a fee that appears only at exit, or an export that drops clinical notes and attachments. Records that are structured and exportable let you keep your own backup on a schedule your team owns, which is your responsibility, not the vendor's. Avinya Plus keeps records structured and exportable for exactly this reason. The cost of getting this wrong is vendor lock-in, which you pay quietly for years.
Control 5: where the data is hosted and who can reach it
End with the plain questions a fiduciary has to be able to answer. Where is my data stored? Who at your company can access my patient records, and under what conditions? What happens to my data if I leave? You are entitled to clear answers because the DPDP duty to protect that data is yours.
A cloud, browser-based product like Avinya Plus means the data sits with the provider's infrastructure, which makes "who can reach it and how" a fair and necessary question. A confident vendor explains its access controls in plain language. A vendor who deflects to a badge instead of an answer has told you something.
The red flags that should stop a deal
Some answers are disqualifying on their own:
- A shared admin login that everyone uses. This destroys the audit trail before it starts, because every action is logged as one anonymous "admin." You can never prove who did what.
- No self-serve export, or a charge to get your own data out. If leaving is expensive or slow by design, you do not really own your records.
- "Bank-grade security" with nothing behind it. Ask what specifically that means. If the answer is more adjectives, it means nothing.
- A compliance badge waved as proof. A SOC 2, ISO 27001, HIPAA, or "DPDP compliant" logo on a slide is not evidence that your clinic is protected, and it is not a substitute for the five controls above. To be plain about our own stance: Avinya Plus claims no such certification, because compliance is the clinic's responsibility and depends on your processes, not a vendor's logo. Hold every vendor, including us, to the demonstrated controls, not the badge.
Run the demo as an interview. Bring one real scenario from your own clinic and make the vendor do it end to end while you watch the logins, the log, the isolation, and the export. The product that handles that calmly, and answers the hosting question without flinching, is usually the one that will protect your patients when you are the one using it at 7pm.
This is general guidance for running a clinic, not legal advice. Confirm your specific data-protection duties with a qualified professional.
Frequently asked questions
- What security controls should I make a clinic software vendor demonstrate live?
- Make them show five things in the demo, not on a slide. Per-user logins with role-based screens, an audit trail that names who viewed or downloaded each record, database-level isolation between branches, a one-click export of all your data, and a clear answer on where data is hosted and who can reach it.
- Is a SOC 2, ISO 27001, or DPDP compliant badge proof that my patient data is safe?
- No. A badge on a slide is not evidence that your clinic is protected. Compliance is the clinic's own responsibility and depends on your processes, not a vendor logo. Judge a vendor on the controls they can demonstrate live, not on a certification claim. Avinya Plus claims no such certification for this reason.
- Why does a shared admin login matter for security?
- A shared admin login that everyone uses destroys accountability. Every action gets logged as one anonymous admin, so you can never prove who viewed, edited, or exported a record. Insist on a separate named account for each staff member so the audit trail actually attributes each action to a person.
- What does branch isolation at the database level mean and why ask about it?
- It means one branch's data is separated below the application, so the separation holds even if the interface has a bug, rather than just being filtered on screen. Avinya Plus uses PostgreSQL Row Level Security. Ask about it even with one clinic, because it shows the product was built to keep records properly separated.
- Who is responsible for protecting patient data, the clinic or the software vendor?
- Your clinic. Under India's Digital Personal Data Protection Act, 2023, your clinic is the data fiduciary and stays responsible for safeguarding patient records even when a vendor processes them for you. That is why the security demo is your due diligence. Confirm your specific duties with a qualified professional.