Skip to content
Eight criteria that separate a system that will work in your environment from one that won't
Selecting a hospital management system (HMS) or hospital information system (HIS) is one of the most consequential technology decisions a healthcare facility will make. Get it right and you gain end-to-end visibility over patient flow, billing, pharmacy, and government reporting. Get it wrong and you inherit a system that is expensive to run, costly to exit, and disruptive to clinical staff.
The challenge for decision-makers in Sub-Saharan Africa is that most HMS evaluation guides are written for hospitals in Europe, North America, or Southeast Asia — markets with reliable power, ubiquitous broadband, and mature regulatory infrastructure. The criteria that matter in Nairobi, Lusaka, or Lagos are meaningfully different.
This guide covers eight criteria that should shape any HMS evaluation for an African hospital, clinic, or mission health facility. Each criterion reflects a challenge that decision-makers across the region encounter regularly.
1. How does the system handle unreliable internet?
This is the single most important technical question to ask any vendor — and the one that is most often answered evasively.
The honest answer requires a binary choice: fully cloud-based (requires reliable internet at all times) or on-site server deployment (runs entirely from hardware installed at your facility, with no dependency on external connectivity). There is no credible middle ground.
Be cautious of vendors who describe their system as “low-bandwidth”, “offline-capable”, or “caches data during outages”. These claims often describe partial functionality only — patient registration may work offline, but billing, pharmacy dispensing, or laboratory results may not. The operational consequences of a partially-available system during a network outage can be severe.
For facilities in areas with consistent fibre or 4G coverage, a cloud-based system is entirely appropriate and offers real advantages: no server hardware to manage, automatic updates, and lower upfront capital expenditure.
For facilities where connectivity is intermittent, expensive, or simply absent — whether due to geography, infrastructure gaps, or budget constraints on data — an on-site server deployment is the correct choice. In this configuration, all clinical and administrative functions run locally. Internet connectivity, if available, can be used for remote support, reporting, and backups, but is not required for day-to-day operation.
Key Question
Ask vendors: what functions are unavailable when internet connectivity drops? If the answer is anything other than 'none' (for an on-site system) or 'all' (for a cloud system with no offline mode), probe further.
2. Does the system integrate natively with DHIS2?
DHIS2 (District Health Information Software 2) is the dominant health data platform across Sub-Saharan Africa, used by ministries of health in more than 40 countries for disease surveillance, facility reporting, and national health statistics.
For hospitals operating under government contracts, donor frameworks, or within national health programmes, DHIS2 reporting is not optional — it is a compliance requirement. The question is not whether your facility will report to DHIS2, but how.
Many facilities currently manage this through manual data extraction and re-entry: staff download a report from the HMS and type the figures into DHIS2. This process is slow, error-prone, and adds significant burden to already stretched administrative teams. It also introduces data quality problems at the national level.
A properly integrated HMS should be capable of pushing data directly to the national DHIS2 instance — either in real time or on a scheduled basis — without manual intervention. This requires the system to map its internal reporting categories to DHIS2 data elements and organisation units, which is more complex than it sounds and varies by country configuration.
When evaluating vendors, ask for evidence of live DHIS2 integration in the specific countries where you operate. A system that claims DHIS2 compatibility but cannot demonstrate it in your country’s configuration should be treated with caution.
Key Question
Ask vendors: in which countries is your DHIS2 integration live, and can we speak to a reference facility that is currently using it?
3. Who provides local support, and where are they based?
Remote helpdesks have a poor track record in Sub-Saharan Africa. Not because the technology cannot support remote troubleshooting — it often can — but because the most common implementation challenges are not technical. They involve workflow redesign, staff training, data migration from paper or legacy systems, and building organisational buy-in. These activities require on-the-ground presence.
A strong vendor will either maintain their own country-based staff or operate through named, trained, and accountable local partners. Both models can work well. What does not work well is a relationship where the only available support is a ticket queue managed in a different time zone.
Before signing any contract, establish clearly who your primary point of contact will be after go-live, where they are based, what their response time commitments are, and what escalation paths exist. Ask to speak with that person before signing — not just a sales representative.
For facilities in Ghana, Nigeria, Malawi, or Zambia in particular, there are now a small number of HMS vendors with genuine in-country partner networks. Prioritise these over vendors offering purely remote support, even where the remote vendor’s product appears technically superior.
4. How does the system handle national health insurance and regulatory requirements?
National health insurance schemes — NHIA in Nigeria, NHIF in Kenya, NHIMA in Zambia, CBHI in Rwanda, and others — are an increasingly significant part of hospital revenue across the continent. A hospital management system that cannot process scheme claims, verify patient eligibility, or generate compliant billing output will create significant administrative overhead.
Regulatory requirements also extend beyond insurance billing. Several African countries have introduced requirements around patient identification (using national ID numbers), facility licensing data, and structured electronic health records. Understanding the regulatory trajectory in your operating environment is important when evaluating long-term vendor viability.
When evaluating vendors, distinguish between live integrations and roadmap commitments. Both have value — a credible commitment from a vendor with a track record of delivering similar integrations in comparable markets is worth more than a vague promise — but they should not be conflated. Ask specifically: is this live and in use by current clients in this country, or is it planned?
Key Question
Ask vendors: which national insurance schemes are you currently live with, and in which facilities? What is your timeline and development commitment for schemes you do not yet support?
5. Does the vendor have a verified track record in comparable facilities?
Reference sites are among the most underused tools in HMS procurement. A vendor who claims broad African experience should be able to name specific facilities — hospitals or clinics similar in scale and context to yours — that are currently using their system.
When you contact reference sites, ask about: the accuracy of the implementation timeline as originally quoted; how go-live was actually managed; what problems were encountered and how they were resolved; and whether staff who were sceptical at the start are now users. The last question often reveals more than any formal reference call.
A vendor’s track record in Indonesia or India tells you relatively little about their ability to deliver in Kenya or Nigeria. Market-specific experience matters — particularly around regulatory configuration, infrastructure norms, and local partner relationships.
6. Is the system genuinely designed for your type of facility?
The HMS and EMR market spans an enormous range — from simple electronic records for single-doctor clinics, to enterprise-grade platforms managing 500-bed tertiary hospitals with multiple departments, pharmacies, laboratories, theatres, and radiology suites.
A system that works well for a small outpatient clinic will typically lack the ward management, inpatient billing, theatre scheduling, and departmental reporting that a hospital requires. Conversely, a system designed for large urban hospitals may be unnecessarily complex and expensive for a 20-bed district facility.
Be particularly cautious of systems that have been “adapted” from another use case — for example, pharmacy management software or general practice software that has had hospital modules bolted on. These systems often have structural limitations in their data model that create problems at scale.
Ask vendors which facility types make up the majority of their current client base, and whether you can see a demo configured for a facility similar to yours — not a generic product demonstration.
7. What is a realistic implementation timeline?
Optimistic implementation timelines are one of the most common failure modes in African HMS deployments. Vendors under competitive pressure frequently quote timelines that assume ideal conditions: clean data for migration, fully available staff, reliable infrastructure, and no scope changes. None of these assumptions typically hold.
A credible vendor will offer a phased implementation approach: an initial deployment of core modules (patient registration, outpatient billing, pharmacy) followed by progressive rollout of additional functionality. This reduces risk, allows staff to build confidence before being asked to use more complex features, and creates early wins that support organisational buy-in.
Ask what the vendor’s median go-live timeline has been across their last ten implementations, and what the longest implementation in their portfolio took. Both numbers are revealing.
8. What is the true total cost of ownership?
Published licence fees rarely capture the full cost of an HMS deployment. Before committing, obtain a comprehensive cost breakdown that includes:
- Initial software licence or subscription fee
- Server hardware procurement and installation (for on-site deployments)
- Implementation, data migration, and go-live support fees
- Staff training costs
- Annual support and maintenance fees
- Upgrade costs for major version releases
- Any per-user, per-module, or transaction-based charges
The most common financial surprise in SSA deployments is the hardware cost for on-site server deployments. Depending on facility scale, a correctly specified server, UPS, and networking infrastructure can represent a substantial capital outlay. Ensure this is included in any proposal.
Summary: Eight Criteria at a Glance
Selection Criterion | What to Look For | Why It Matters in SSA |
Internet-independent deployment | Full on-site server mode — not just a cache or low-bandwidth workaround | Power and connectivity outages are routine. A cloud-only system will fail during them. |
DHIS2 integration | Native, live data push to the national DHIS2 instance | Most SSA governments mandate DHIS2 reporting. Manual export adds staff burden and introduces errors. |
Local in-country support | Named partners or staff in your country, not just a remote helpdesk | Configuration, training, and troubleshooting require on-the-ground presence. |
Regulatory readiness | NHIA / NHIF claims processing, government ID lookup (e.g. NIN, NHIMA) | Payer integration determines whether the system reduces or multiplies billing complexity. |
Implementation track record | Live deployments in comparable facilities in the region | Reference sites in Nigeria, Ghana, Malawi, or Zambia, reduce procurement risk significantly. |
Segment fit | Purpose-built for hospitals and large clinics — not repurposed pharmacy or GP software | A system designed for primary care will lack the ward management, theatre scheduling, and departmental billing your facility needs. |
Deployment timeline | Realistic go-live commitments with phased roll-out options | Overpromised timelines are the most common implementation failure mode in SSA. |
Total cost of ownership | Transparent pricing including server hardware, annual licence, support, and training | Hidden costs — particularly around hardware, data migration, and ongoing support — frequently exceed the initial licence fee. |
What to do next
The procurement process for an HMS is rarely straightforward. Facilities that invest time in structured evaluation — including site visits to reference facilities, detailed technical demonstrations, and thorough commercial due diligence — consistently achieve better outcomes than those who move quickly on price alone.
If you are evaluating HMS options for a facility in Sub-Saharan Africa, Ksatria Medical Systems has live deployments across Nigeria, Ghana, Malawi, and Zambia, with in-country partner networks, native DHIS2 integration, and a deployment model that accommodates both reliable and unreliable internet environments.
Request a demonstration configured for your facility type and country — our team will walk you through how Ksatria addresses each of the criteria covered in this guide.
