Skip to main content

Guide · Hospitals

How to choose hospital management software in India

Every vendor will tick every box on your feature list. That is why feature lists do not discriminate between them. This guide sets out an evaluation that does — starting with your own workflows, and ending with contract terms most buyers only think about too late.

In short

A good HMIS evaluation has three parts: write down how your hospital actually works before you see any software; run demos against those specific workflows rather than the vendor’s script; and settle data ownership, exit terms and the support model in the contract rather than in a meeting. Most bad purchases skip the first part, which is what makes the other two ineffective.

Scope your own workflows first

The single highest-value thing you can do costs nothing and involves no vendor: write down how your hospital works today. Not the org chart — the sequence. Who touches a patient, in what order, and what each person needs from the person before them.

  • Map three real journeys. A routine OPD visit, a planned admission with surgery, and an emergency case that gets admitted. These three cover most of the handovers in a hospital.
  • Mark every place something is re-entered. Each one is a place your current system has a seam and a candidate for where a new system should save you time.
  • Write down your tariff and payer structure. Package rates, differential pricing, TPA arrangements, corporate rates. This is where generic products break, and it is easier to find out in week one than in month six.
  • List what you must be able to report. To management, to payers, to regulators. Work backwards from the reports to the data they need.
  • Name the people who will refuse. There is always a consultant and a senior nurse whose cooperation decides the outcome. Involve them now, not at go-live.

This document is your evaluation criteria. Everything after this is measuring vendors against it.

Building a shortlist

Three to five vendors is the right number. Fewer and you have no comparison; more and the evaluation collapses under its own weight. Filter on things that are cheap to check before you spend time on demos:

  • Do they have hospitals your size? A product built for 500-bed tertiary care behaves differently in a 60-bed hospital, in both directions.
  • Do they cover your specialities? Dialysis, IVF, oncology and day-care surgery all have workflow specifics that a general product may not carry.
  • Who supports you, and from where? A support desk three time zones away is a different proposition from one that can send someone.
  • Is the product theirs? Some vendors resell or white-label. That is not disqualifying, but you should know who actually fixes a bug, and how long that chain is.
  • Ask for two references you choose. Not the two they nominate — ask for a list and pick from it. The difference in what you hear is substantial.

Questions that expose a weak product in a demo

Vendors rehearse demos. The way past a rehearsed demo is to make them do your sequence, live, and to ask what happens when things go wrong — because error paths are where shallow products are shallow.

  1. 01

    Make them use your data shapes

    Give them your tariff structure, a package rate and a TPA arrangement before the demo, and ask them to configure it. A product that can only demo its own sample data is telling you how the implementation will go.

  2. 02

    Follow one patient all the way through

    Register, book, consult, order an investigation, dispense a medicine, admit, transfer a ward, discharge, bill, claim. Do not let them jump between prepared screens — insist the same patient carries through.

  3. 03

    Break the happy path

    Cancel an appointment after check-in. Enter a lab result and try to release it without verification. Dispense a medicine that is out of stock. Discharge a patient with an unsettled bill. The answers are more informative than any feature.

  4. 04

    Ask how a mistake is corrected

    Somebody will bill the wrong patient. Ask to see the correction, and ask whether the original is still visible afterwards. A system that lets records be silently overwritten is a liability, not a convenience.

  5. 05

    Put a doctor and a nurse at the keyboard

    Not the sales engineer. Ask a consultant to write a note and a nurse to chart a shift. If either of them looks uncomfortable, you have found your adoption problem early enough to act on it.

  6. 06

    Ask for a report you actually need

    Name a number your management asks for monthly and ask them to produce it. "We can build that" is a different answer from showing it.

Data ownership, exit terms and the support model

This is the part of the evaluation most hospitals rush, and the part that costs the most when it goes wrong. Get the following in the contract, not in an email:

  • Ownership. You own your data. State it explicitly.
  • Export. A complete export, in a documented format, within a stated number of days, at a stated cost — including after termination. "We will help you" is not a term.
  • Continuity. What happens if the vendor is acquired or ceases trading. For on-premise deployments, consider source code escrow; for cloud, a defined data-return process.
  • Support. Response and resolution targets by severity, hours of cover, and who you call at 2am when admissions cannot bill. A single WhatsApp number is not a support model.
  • Change costs. What a configuration change costs versus a customisation, and what happens to your customisations at the next upgrade.
  • Price protection. How the subscription can rise at renewal. An uncapped renewal is a bill you have not seen yet.

Our guide to HMIS cost in India covers the money side in detail, including the costs that never appear in the licence line.

How to test an ABDM claim

Almost every Indian hospital vendor now says “ABDM-ready”. The phrase has no fixed meaning, so replace it with specific questions:

  • Are you certified, empanelled, or building toward it? These are three different answers.
  • Show me an ABHA link being initiated and an OTP verified, live.
  • What happens when a patient refuses consent? If records can still be shared, the consent framework is decorative.
  • Can you export my records as FHIR today, or is that planned?
  • Where is the ABHA identifier stored? The right answer is that it is not stored.
  • Who pays when the specification changes?

For context on what the programme actually requires, read our breakdown of ABDM and ABHA integration — which also states plainly where our own work stands, so you can apply the same questions to us.

A scoring framework

Weighted scoring is not a magic answer, but it stops the loudest person in the room from deciding. Adjust the weights to your situation — a hospital with a heavy insurance mix should weight claims handling far higher than one running mostly cash.

A starting point. Set the weights before you see any demos, not after.
 Suggested weightWhat you are actually judging
Workflow fit25%Whether it matches the journeys you mapped, without customisation.
Usability for clinical staff15%Whether doctors and nurses will actually use it under time pressure.
Billing and payer handling15%Your tariff structure, packages, TPA and corporate arrangements.
Reporting10%Whether the numbers management asks for come out without manual work.
Implementation and support15%Who does the work, how long it takes, and what happens afterwards.
Commercial terms10%Ownership, export, continuity, renewal caps.
Interoperability and ABDM10%FHIR today, and a credible, specific ABDM position.

FAQ

Common questions about choosing an HMIS

How long should an HMIS evaluation take?
For a mid-sized hospital, six to twelve weeks from scoping to signature is realistic: two to three weeks writing down your own workflows, three to four weeks of demos with the departments that will use the system, and the rest on reference checks and contract terms. Evaluations that finish in two weeks usually skipped the first step, which is the one that determines whether the purchase works.
Should we shortlist on features or on fit?
On fit. Feature lists converge — almost every vendor will tick almost every box. What differs is whether the product matches how your hospital actually works: your handovers, your tariff structure, your payer mix. Score vendors against your workflows, not against a checklist the vendor could have written.
What should we ask about data ownership?
Three things in writing. Who owns the data (it should be you). How you get a complete export, in what format, and how quickly. And what happens to your data if you terminate, if the vendor is acquired, or if the vendor ceases trading. A vendor who cannot answer these plainly is telling you something.
Is a cheaper vendor a false economy?
Not necessarily — but the licence fee is rarely where the money goes. Implementation, data migration, training, customisation, integration and the support model usually add up to more than the first year of licence. Compare three-year totals, and treat any quote that omits implementation as incomplete rather than cheap.
How much weight should we give ABDM readiness?
Enough to ask precisely, not enough to accept a brochure claim. Ask whether the vendor is certified or building toward it, ask to see an ABHA link actually happen, ask what occurs when consent is refused, and ask who carries the cost when the specification changes. The difference between those answers is larger than the difference between most feature lists.

Put these questions to us

Bring your mapped workflows and your hardest error-path questions. We would rather find out early that we are not the right fit than late.

See Polynexus HMIS

Related pages

HAVE A PLATFORM IN MIND?