Most HMS demos look good. The differences that matter show up after you sign. This checklist is built around the questions that actually separate the products.
Choosing a hospital management system is a long-term decision. You are not buying software for this quarter; you are choosing the platform your facility will run on for years, and the cost of switching later is high. The trouble is that almost every product demos well. The differences that decide whether you are happy in two years rarely show up in a polished walkthrough. They show up the first time the power goes, the first HMO claim, and the first month-end report.
This is a practical checklist for evaluating an HMS in the Nigerian context. Use it to push past the demo and test the things that matter here specifically.
Start here, because in Nigeria it is non-negotiable. Power and connectivity are intermittent, and a cloud-only system that freezes during an outage is worse than paper. Do not accept "yes, it works offline" as an answer. Ask the vendor to unplug the network during the demo and complete a full journey, register a patient, chart, order a test, dispense, and bill, with the connection down, then reconnect and watch it sync.
If a vendor will not run the demo with the network off, assume the offline claim is marketing until proven otherwise.
We have written separately on why offline-first matters for hospitals in Africa, because the architecture, not just a feature flag, determines whether your facility keeps working on a bad day.
Payment in Nigeria is mixed: cash, bank transfer, mobile money, and a significant share of care paid through HMOs and insurance schemes. An HMS that assumes simple cash billing will leave you managing claims on the side. Check that the system supports:
If claims and tariffs live outside the system, you are buying a billing problem disguised as a feature.
Many hospitals discover too late that their HMS does not include a real laboratory system, so they license a separate one and pay again to connect it. Ask directly: is the lab a module of this platform sharing the same patient record, or a separate product? When a doctor orders a test, does it arrive in the lab without re-entry, and does the result return to the same chart? The difference is large and recurring. Our comparison of one platform versus separate hospital and lab systems breaks down where that cost hides.
If your facility reports to a state or national health authority, much of that data ends up in DHIS2. Ask whether the system can generate the aggregate returns from the care it already records, or whether someone will be tallying registers by hand every month. The right answer is that reporting is a by-product of structured, coded clinical data, not a separate monthly project. Our guide to DHIS2 reporting covers what good looks like here.
Patient data is sensitive and increasingly regulated. Check for encryption at rest and in transit, role-based access so staff see only what they should, and a full audit trail on every record. Ask where the data is hosted and whether it stays in your region, which matters for data protection compliance. A vague answer on security is itself an answer.
The licence price is the visible cost. The real number includes implementation, training, hardware, support, and, crucially, the integrations. Every separate system you have to connect, lab, billing, reporting, is an extra integration to build and maintain. Ask for pricing that is clear about what is included and what is charged per integration, so you can compare like with like. A cheap licence attached to a stack of paid integrations is rarely the cheaper option.
Your needs will change. Check that the platform covers the modules you will need next, not just today, and that it speaks recognised healthcare standards such as FHIR and HL7 for interoperability and ICD-11 for coding. Standards support is what lets the system connect to the wider health ecosystem instead of locking you into one vendor's island.
Software is only as good as the rollout. Ask who does the implementation, how training is handled, how support is reached, and what happens when something breaks during a clinic. A capable product with no implementation muscle behind it will struggle in a real facility.
We built Veona around exactly these realities. It is offline-first, so outages do not stop care. It supports cash, mobile money, and HMO or insurance claims at the point of billing. The laboratory is built in, sharing one patient record, so there is no separate LIS to license and connect. Reporting, including DHIS2 alignment, is generated from coded clinical data rather than counted by hand. Security covers encryption, role-based access, audit trails, and regional hosting. Pricing is clear about what is included, with integrations priced per integration. And the platform is standards-aware, with FHIR, HL7, and ICD-11 support.
If you want to see how it holds up against your own version of this list, our pricing page lays out what is included, and the platform overview shows the modules on one record. The best evaluation, though, is to run the checklist live, with the network off.
Book a demo and we will test offline behaviour, payments, the built-in lab, and reporting against your real workflow.