How to use this checklist before you call any vendor
Choosing hospital software goes wrong when the demo leads the decision. A vendor shows a polished dashboard, the meeting runs out of time, and the questions that matter to your billing desk or wards are never asked. This checklist turns that around: you write down your needs first, then ask every vendor to prove their system against them.
It is meant for hospital administrators, medical superintendents and owners of nursing homes or multi-department hospitals who are shortlisting systems. By the end you should have four things on paper: a short profile of your hospital, a list of must-have modules, a set of demo scenarios, and your contract and support questions. If you first want to understand the patient journey the software has to support, read how a patient visit flows from OPD to billing.
Step 1: Write a one-page profile of your hospital
Vendors size their proposal to what you tell them. A one-page profile stops you being sold modules you will not use, and stops important details surfacing only after go-live. Take the figures from your own registers rather than estimating.
| Item to write down | Why it matters |
|---|---|
| Beds and wards, by type | Decides whether you need admissions, ward tariffs and bed management now |
| Departments, and full-time versus visiting doctors | Affects appointment calendars, doctor logins and doctor-wise reports |
| OPD patients on a normal day and on your busiest day | Shows how fast registration and token issue must be |
| In-house lab and pharmacy, or outsourced | Decides which modules and links between them matter |
| Branches or collection centres | Points towards a cloud or multi-location setup |
| Internet reliability at each site | A desktop version on a local network may suit areas with patchy connections |
| Insurance and TPA patients | You will need to see how their bills and paperwork are handled |
| Staff at each desk who will use the system | Decides the number of logins and the training plan |
Step 2: Sort modules into must-have, later and not needed
Most hospital systems list similar module names. The real difference is whether each module fits the way your teams work. Sort them into three columns before the first demo, and ask each vendor whether a module can be switched on later without moving your data again.
- Patient registration and records: must-have for everyone. Check that a returning patient can be found quickly by mobile number or ID.
- Appointments and OPD tokens: must-have if you have more than one doctor or a regular morning queue.
- OPD consultation and prescriptions: must-have if doctors will enter prescriptions themselves; agree how much typing they will accept.
- Billing and payments: must-have. Look for discount approvals, dues, refunds and a daily collection report.
- Pharmacy: must-have if you run an in-house pharmacy. Check batch, expiry, GST and sales linked to prescriptions.
- Lab and diagnostics: must-have if you run your own lab. Check test prices, sample status and report templates.
- IPD, beds and wards: must-have for any hospital that admits patients. Check room tariffs, bed changes during a stay and the discharge summary.
- HR and staff: often a later phase, but check roles and permissions now even if staff attendance comes later.
- Reports: list the five reports management reads every week and ask to see each one with sample data.
Step 3: Map every desk to a role and a login
Software that nurses or pharmacists find awkward gets bypassed, and a bypassed system produces wrong reports. Before the demo, list each desk and what that person needs on screen: reception (registration, tokens, quick receipts), doctors (patient history, prescriptions, lab results), nurses (vitals, nursing notes, bed status), billing (bills, discounts, dues), pharmacy (sales, stock, expiry), lab (bookings, results) and administration (masters, users, reports).
During the demo, ask the vendor to log in as each role instead of showing everything from the administrator's screen. You want to see how many steps a receptionist needs to register a returning patient and issue a token on a crowded morning. How these roles protect patient records is a separate subject, covered in our guide to patient data security in hospital software.
Step 4: Check how lab, pharmacy and outside services connect
"Yes, it integrates" is not an answer. For each item below, ask whether it is included, optional or custom work, and who maintains it after go-live.
- Lab inside the system: does a test ordered by the doctor appear at the lab and on the bill without re-entry, and is the finished report attached to the patient record?
- Pharmacy inside the system or separate: if your pharmacy also works as a retail medical store, compare the hospital module with dedicated pharmacy management software and decide which one holds the stock.
- Lab analysers and imaging equipment: if you want results to flow directly from machines, ask which equipment the vendor has connected before, and treat it as a separately scoped item.
- SMS and WhatsApp: appointment reminders and report-ready alerts need a sender setup and approved message formats; ask who arranges them.
- Biometric staff attendance and online payments: useful for some hospitals; confirm whether they are optional add-ons and how they are charged.
- ABDM: if you plan to take part in the Ayushman Bharat Digital Mission, ask exactly which ABDM functions the software supports today and what you must register for separately. Official information is at abdm.gov.in.
Step 5: Plan data migration before you sign
Data migration is where go-live dates slip. Decide early what moves into the new system, what stays archived, and who in your team cleans it.
- Patient master: names, contact details and IDs from your old software or Excel. Remove obvious duplicates first.
- Masters: doctors, departments, services, test prices, ward and room tariffs, and packages. Department heads should check these, not only the IT person.
- Pharmacy opening stock: item, batch, expiry, quantity and purchase rate, physically counted on the cut-over date.
- Open balances: patient dues and supplier dues as on the cut-over date.
- Old clinical records: decide whether to import summaries, upload scanned files, or keep the old system available read-only for reference.
Ask each vendor to import a small sample of your real data during evaluation. Problems with name formats, missing mobile numbers or inconsistent test names show up straight away.
Step 6: Run the demo on your own scenarios
Send these scenarios to every shortlisted vendor in advance, with your own sample names, tariffs and test prices. A vendor who cannot show them live with your data is telling you something useful.
- A returning patient whose name was spelt differently last time registers for a follow-up and receives a token.
- A doctor writes a prescription with two lab tests and three medicines; follow it to the lab, the pharmacy and the bill.
- A patient is admitted, moves from the general ward to a private room on day two, and is discharged under a package with extra charges.
- The billing desk gives a discount above the normal limit; show who approves it and where the approval is stored.
- A patient pays part of the bill and returns a week later; show the due appearing on the next visit.
- A medicine batch is close to expiry; show the alert and the near-expiry list.
- Show the end-of-day collection report and the weekly reports management asked for.
| Area | What a good result looks like | Score |
|---|---|---|
| Registration and token | Returning patient found and token issued in a few steps | 0 / 1 / 2 |
| Order to lab, pharmacy and bill | No re-entry of tests or medicines at any desk | 0 / 1 / 2 |
| Admission, room change, package | Tariff changes on the right day; package and extras clearly separated | 0 / 1 / 2 |
| Discount approval | Approver named and recorded against the bill | 0 / 1 / 2 |
| Dues | Part payment carried forward and visible on the next visit | 0 / 1 / 2 |
| Pharmacy expiry | Near-expiry items listed by batch | 0 / 1 / 2 |
| Reports | Management's weekly reports available without manual work | 0 / 1 / 2 |
| Staff reaction | Reception, nurse, billing and pharmacy staff could follow it | 0 / 1 / 2 |
Bring the people who will use the system: one receptionist, one nurse, one billing clerk and the pharmacist. Their reaction during a demo predicts adoption better than a management presentation does.
Step 7: Settle training, support and exit terms in writing
Hospital software is used every day for years, so the relationship after go-live matters as much as the demo. Verbal promises made during the sales meeting are easily forgotten by both sides when staff change. Ask for each of these points to be written into the proposal or agreement before you sign.
- Training: which roles are trained, how many sessions, and how new staff are trained later.
- Go-live support: who is present or on call during the first days, and how problems are reported.
- Support after go-live: channels (phone, WhatsApp, email), working hours, and how an urgent billing-desk problem is handled. Get this in the agreement, not only in the brochure.
- Updates and AMC: what the annual maintenance covers, how updates are applied and whether they change screens your staff already know.
- Backups: who takes them, where they are stored, and how a restore is done.
- Data export: in what format you can take all your data out if you change systems.
- Changes: how new reports or form changes are requested, estimated and charged.
Checking the company itself, such as its registration, live installations and contract terms, is covered in our guide on what to check before hiring a software company.
Putting MATROP on your shortlist: what we offer and where we may not fit
MATROP PRIVATE LIMITED has built software for businesses, schools and hospitals since 2016. Our Hospital Management Software covers patient registration and records, appointments and OPD tokens, consultation, IPD and wards, billing, pharmacy, lab, staff roles and reports. Modules can be enabled or disabled to match your workflow, custom reports can be built, and it comes as a desktop version on your local network, an online/cloud version and mobile apps. SMS/WhatsApp reminders, pharmacy barcode, staff duty schedules, attendance integration and the audit log are optional.
Implementation starts with a study of your OPD, IPD, billing, pharmacy and lab process, followed by setting up masters, tariffs and user roles, data entry and training for each team, go-live support and AMC options. You are welcome to send us the scenarios above and score our demo exactly as you score the others.
Be clear about gaps too. Our published module list does not mention direct connections to lab analysers or ABDM functions; if either is essential for you, raise it at the start so it can be scoped or ruled out honestly. Our office is in Ranchi, if you are nearby and would like to meet, and we work with hospitals in other parts of India as well.
Questions people ask
Who from the hospital should attend a software demo?
The administrator or owner, plus one person from each desk that will use the system daily: reception, nursing, billing, pharmacy and lab. They will spot practical problems that a management-only demo misses.
How many vendors should we shortlist?
Enough to compare, but few enough to test properly. Two or three detailed demos on your own scenarios usually tell you more than six short presentations, as long as you score each one on the same sheet.
What should we ask vendors about ABDM?
Ask which ABDM-related functions their software supports today, which are only planned, and what your hospital must register or do separately. Check the current details on abdm.gov.in rather than relying on a sales answer.
Who should own the software inside the hospital after go-live?
Name one person, often in administration or accounts, to manage users, masters such as tariffs and test prices, and contact with the vendor. Without an owner, small errors in masters quietly turn into wrong bills.
