A buyer’s guide written by a vendor, which you should read accordingly.

Run the journey, not the feature list

A feature list is a claim. A patient journey is a test. Take one ordinary case, a returning patient with a follow-up, a prescription, a test and a bill, and make every vendor walk it end to end while you watch.

You will learn more in twenty minutes of that than in a two-hour presentation. Watch for the moments where the demonstrator switches screens unexpectedly, types something twice, or says “normally we would configure that”.

Questions that expose real differences

Every vendor has an answer to "do you have X". These are harder to answer well.

What happens when two people do this at once?

Two desks admitting to the same bed, two cashiers on the same invoice. Concurrency is where systems quietly corrupt data, and the answer tells you whether anyone thought about it.

Show me a mistake being corrected.

A wrong diagnosis on a signed note, a payment against the wrong patient. Real systems have a correction path that leaves a trail; weak ones either forbid it or allow a silent edit.

Who can see the clinical record, and how do I change that?

Ask them to deny one permission to one user in front of you. If it takes a support ticket, it is not really configurable.

What does the audit trail record?

Ask specifically about reads, not just writes.

What is not built yet?

The most useful question on this list. A vendor who names three things is more trustworthy than one who names none.

What happens if we leave?

Export format, how long, what it costs, and what happens to their copy.

Pricing models, and what each one does to behavior

Per-doctor and per-seat pricing is the norm, and it has a predictable consequence: hospitals share logins to avoid the next seat. A shared login destroys the audit trail you are buying, makes clinical notes unattributable, and defeats whatever permission model sat underneath.

Ask what the pricing does to your behavior, not just what it costs. Then ask about the things that are not in the headline: implementation, migration, training, AMC, upgrade fees, and the charge for getting your data out.

Migration is the project, not a task

Migration fails on data quality far more often than on software. Duplicate patients, inconsistent identifiers, services with no prices, stock that has not been counted. That work is yours regardless of vendor, and it is the main reason implementations slip.

Insist on a written migration scope: what is included, what is quoted, and what will not be migrated at all. "Free data migration, subject to scope" without a published scope is not a commitment.

Reading a compliance claim

Certification claims are the easiest thing to check and the least often checked. ISO 27001, SOC 2, HIPAA, ABDM certification and NABL are each granted by a body that issues a document with a date and a scope. Ask for it.

Two specific traps in India. First, no software is NABH accredited; hospitals are. Second, "ABDM ready" and "ABDM certified" are not the same, and only one of them has a definition.

Uptime figures deserve the same treatment. A vendor with no production deployment quoting 99.99% is quoting an aspiration, and a vendor with one can tell you what they measured and over what period.

Where we would fail your evaluation

Since this is our website, here is the disclosure the rest of the guide implies. Nirogix’s inpatient is built and in verification but not yet running in a paying customer’s hospital, and it has no drawn bed map, no structured medication administration record and no auto-generated discharge summary yet. No WhatsApp. No telemedicine. No claims or TPA integration. No analyzer interfacing. No purchasing side to the pharmacy. Our ABDM work is built and uncertified, and no record has been exchanged in production.

If your requirements are in that list, we should not be on your shortlist this quarter, and you now know that without spending an afternoon finding out.