Choosing a hospital management system in Ethiopia: twelve questions to ask any vendor

Every hospital management system looks good in a demonstration. The vendor registers a patient, opens a consultation, orders a test and prints a receipt, and the screens are clean because the data is clean. The question a hospital director has to answer is different: will this system still be in daily use in two years, in this hospital, with these staff, on this connection?

Ethiopian hospitals have a long history of software projects that did not reach their second year. The reasons are rarely technical failure. More often the system did not fit how the hospital worked, could not be supported locally, assumed infrastructure the hospital did not have, or never connected the departments that most needed connecting. The questions below are the ones we would ask in your position — of any vendor, including us.

1. Is it one system, or several sharing a logo?

Ask the vendor to follow one patient from registration to the cashier without leaving the system: triage, consultation, a lab request, the result coming back, a prescription, the dispense and the bill. If the lab result has to be typed into a second screen, or the pharmacy cannot see the prescription the doctor wrote, you are buying modules, not a system. The value of a hospital management system is that every department works from one patient record.

2. Can the people who use it most use it in their language?

The heaviest users of hospital software are not doctors. They are registration clerks, nurses, pharmacy technicians and cashiers. If those staff work more comfortably in Amharic or Afaan Oromo, a system that is only in English will be used reluctantly and inaccurately. Ask to see the cashier and nursing screens in each language, and ask whether printed documents — prescriptions, discharge summaries, lab reports — come out in the patient's language too.

3. Does it understand how Ethiopian patients pay?

Cash still matters, but mobile money is growing quickly, and a large share of public-sector visits are covered by community-based health insurance. Ask how the system records a CBHI member's coverage, how a claim is built from the services actually delivered, and how the payer's approval, rejection and reimbursement are recorded against the bill. Ask whether mobile payments are reconciled to the visit automatically or by a clerk at the end of the day. Our billing and insurance module is one answer to these questions; make every vendor answer them.

4. What does reporting to the Ministry look like?

Facilities report monthly to the national HMIS, which runs on DHIS2. A system that captures visits, deliveries and immunizations as care happens should be able to produce the monthly figures without a separate tally. Ask exactly what it exports, in what format, and who maps the indicators to your DHIS2 data elements. Be wary of vague claims of "DHIS2 integration" — ask to see it working. We describe our own approach, including what is not built yet, on the reports module page.

5. What happens when the internet slows down or the power goes?

This is the question that ends most projects. Ask the vendor to show the system on a throttled connection. Ask what a nurse does when the connection drops in the middle of a medication round, and what the cashier does when the power fails. A vendor who says "that won't happen" has not worked in Ethiopian hospitals. A good answer includes how the software behaves on a slow link, what works offline (if anything), and a written downtime procedure your staff can follow. We have written more about this in running hospital software on unreliable internet and power.

6. Who owns the data, and how do we get it out?

Your hospital owns its patients' records. The contract should say so, and the system should let you take a complete export at any time without paying for the privilege. Ask how each hospital's data is separated from other customers', who at the vendor can see it, and whether access is logged. Ask what happens to your data if the vendor goes out of business.

7. How is access controlled and audited?

A cashier should not read clinical notes; a lab technician should not change a price list. Ask to see the role configuration, how a new staff member is invited and how a departing one is removed, whether administrators use multi-factor sign-in, and whether every change to a clinical or financial record leaves a trace that cannot be edited afterwards. See our notes on patient data protection obligations.

8. Who configures it, and who trains our staff?

A hospital management system is mostly configuration: departments, wards, beds, services, price lists, roles, document templates. Ask who does that work and how long it takes. Ask whether training happens on your premises, on your own configured system, in your staff's language — or in a hotel conference room on a generic demo. Training is the difference between a system that is used and one that is bypassed.

9. Where is support, and who answers?

When the pharmacy cannot dispense on a Saturday evening, who picks up the phone? Ask where the support team is, which languages they work in, what hours they cover and what happens outside them. Ask for the name of the person who would know your configuration.

10. Which features exist today?

Every vendor has a roadmap. The problem is when the roadmap is presented as the product. Ask the vendor to mark, on their own feature list, what is in use today and what is planned. On our module pages we show available capabilities with a filled dot and roadmap items with a hollow one, because a hospital buying in good faith deserves to know the difference.

11. Is it built on standards that will outlive the vendor?

Diagnoses coded in ICD-10, lab tests coded in LOINC, and data that can be exchanged using HL7 FHIR as national interoperability matures all make your records more useful and less dependent on one company. Ask which standards are used today, not which are "supported".

12. How is the price built?

Ask what drives the price, what is included, and what will cost extra later — training, new modules, upgrades, additional users, data export. A quotation that looks cheap but charges separately for every change will cost more over five years than one that includes them. Our pricing page explains how we quote and what is always included.

How to run the evaluation

1. Write down the five workflows that matter most to your hospital — usually registration to consultation, lab ordering and results, prescribing to dispensing, admission to discharge, and billing with insurance.
2. Ask each shortlisted vendor to demonstrate those five workflows, in that order, using your price list and your departments if possible.
3. Include a nurse, a cashier, a pharmacist and your HMIS officer in the demonstration, not only the medical director and the IT lead.
4. Ask for a written list of what is available today and what is roadmap, and keep it with the contract.
5. Visit or speak to a facility running the system, if the vendor has one. If they do not — as we do not yet — ask for a guided session on a fully configured demo environment and judge the system on the workflows that matter to you.

A hospital management system is a ten-year decision. Spending a few extra weeks asking these questions is the cheapest insurance a hospital can buy. If you would like to put them to us, tell us about your hospital or ask to see the demo hospital.