A Features Checklist for Your First Hospital System

Every vendor’s feature list is long, and every long feature list is designed to survive comparison rather than to help you decide. This one is ordered by when you need something, which is the only ordering that is any use while you are buying.

One test, applied to every line:

Name the person in your hospital who uses this, and the day of the week they use it.

A feature nobody can be named for is a feature you are buying for the brochure. It is also a feature that will be quoted for, configured, half-trained and then ignored.

Insist on these from day one

These are the ones that make the difference between a system that runs the hospital and a system the hospital works around.

One permanent patient identifier. Not a per-year series, not a number that restarts. A patient registered in March is the same record in November. Ask what happens when the same patient is registered twice, and whether records can be merged.

Registration the desk can complete at speed. Check which fields are mandatory. Every required field your receptionist cannot supply at 9am becomes a fake entry within a week.

A queue. Who is waiting, for which doctor, in what order, visible to both the desk and the consulting room. This single screen is what stops the corridor asking the receptionist the same question forty times a morning.

A consultation record the doctor will use. Not a blank text box, and not a form so structured that it takes longer than writing on paper. Watch a doctor use it during the demo and count the actions to finish a routine follow-up.

A prescription on your own letterhead. Your hospital’s name, logo and address — not the vendor’s. Ask to see it printed, and ask how it is sent to the patient.

Billing with a receipt number against every payment. Then ask the harder question: what happens when a bill is wrong. Can it be corrected, and does the correction leave a trace of who made it and when? A system where yesterday’s bill can be quietly edited is not a financial record.

Refunds as a recorded process. Not a deletion. Somebody asks, somebody approves, somebody pays, and all three are recorded.

An end-of-day position. What was collected today, by payment mode, and what is outstanding. One screen. If it takes three, nobody will look at it, and a number nobody looks at is not a control.

Access by role. The desk, the doctor and the owner do not see or do the same things. Ask whether this is enforced on the server or only hidden in the interface — the difference matters and the honest answer is specific.

Your data, out, on demand. In a machine-readable format, written into the contract. This is the one item on this list that costs nothing to agree at signature and cannot be bought at exit — the whole argument is in how to switch hospital management software.

These matter sooner than people expect

Search that finds the patient. By phone number, by partial name, by misspelt name. Test it with a real Indian name spelled three ways. This is used five hundred times a day and is almost never on a feature list.

The two or three reports you actually read. Ask for them by name during the demo and have the vendor produce them on screen. “Custom reports available” means a support ticket.

Messaging the patient. Appointment reminders, the prescription, the bill. Ask which channel, whether it is included, and what it costs per message at your volume.

Multi-doctor money rules. Consulting fees that vary by doctor and by day, revenue shares, visiting-consultant arrangements. These are specific to Indian practice and are where generic international products tend to fall down.

Changing things without the vendor. Fees, doctors, consulting days, service names, discount limits, the letterhead. If every routine change is a support ticket, the product’s quality matters less than the vendor’s queue length.

Language at the desk. Which languages the interface and the printed documents support, in the version you would actually be given.

Defer these, deliberately

Not “never” — later, on purpose, once the core is stable and you know what you need.

Modules for departments you do not run. An inpatient ward, a pharmacy counter, a laboratory or an imaging department you do not have today. Buying the module now does not reserve you a better one later; the version that exists when you open that department will be different anyway.

Analytics dashboards. Valuable once there is a year of trustworthy data. On day one there is nothing in them.

A patient-facing app. A separate product with its own adoption problem. Most hospitals get more from a message that arrives reliably than from an app nobody installs.

Integrations, until the core is steady. Machines, gateways and portals each add a failure mode. Add them one at a time, after the everyday work is boring.

AI you cannot see working. Ask what it does today, in the version you would be given, and ask to watch it on a live screen rather than a slide. A vendor who separates what is shipped from what is being built is telling you how they will behave after you sign.

Our own answer, for symmetry. What Arko Care runs today is the whole outpatient department: walk-in registration with a permanent UHID, the token queue, consultation notes, prescriptions on the hospital’s own letterhead with one tap to send on WhatsApp, each doctor’s most-prescribed medicines as one-tap chips, billing with a receipt number against every payment, refunds in three recorded steps, and Day Close showing the money actually collected by payment mode. Inpatient, laboratory and pharmacy modules are not live today. The AI assistance inside the consultation is being built now:

In build now It rolls out with our next hospitals.

Features that sound important and are not

• “Unlimited users.” Impressive on a slide. Ask instead what happens to the price when you add a doctor, because that is the number that will actually change.
• A count of modules. Forty modules from a vendor who has shipped twelve of them well is worse than twelve that work.
• “Fully customisable.” Usually means “billable”. Ask what is configurable by you, what is configurable by them, and what needs development.
• A mobile app for everything. A doctor checking the day’s list on a phone is useful. A busy desk doing registration and billing on a phone is not how the work happens.
• Standards badges without a version. Ask which standard, which version, and what was actually exchanged with what. The terminology is unpacked in HMS, HIS, EMR, EHR.

Scoring it

Take the day-one list above, put each vendor in a column, and mark each row seen live, described, or not shown. Do it the same evening, while you still remember which demo was which.

Then count only the “seen live” marks. Two vendors with identical feature lists usually have very different columns once you do that, and the gap between what was demonstrated and what was merely described is the most predictive thing you will collect.

The tasks to make them perform are in what to ask in a vendor demo, the wider evaluation is in how to choose hospital management software, and the argument for buying in this order rather than all at once is what to buy before you need an ERP.

Arko Care is an AI-native, white-label hospital management system for Indian hospitals: your name, your logo and your own web address on everything your patients see. Book a demo and score us on the day-one list.