Buyer's guide
What to look for in a hospital management system in 2026
Choosing a hospital management system is a five-year commitment dressed up as a software purchase. Most facilities run the system they pick today until the next leadership change forces a re-evaluation, by which point switching costs are five times higher than they were at signing. The questions you ask before signing are the questions you'll wish you had asked five years in.
This is a working buyer's guide, written for hospital administrators in Ghana evaluating HMS platforms in 2026. Eight questions, why each one matters, and what a good answer sounds like.
1. "Is the system built for Ghana, or localised to it?"
A hospital management system designed in Europe or India and "configured" for the Ghanaian market is structurally different from a system designed for the Ghanaian market from the first line of code. The differences show up in the small places: how NHIS claims are handled, how mobile-money payments reconcile, how the system behaves on intermittent connectivity, what languages the patient-facing components speak.
A good answer: specifics. The vendor names the things they've built for Ghana — payment integrations, claim formats, connectivity behaviours, regulatory alignments — without prompting. The bad version says "we support all geographies" and changes the subject.
2. "What's your implementation timeline, and what's bundled?"
The single biggest predictor of HMS failure is a slow implementation. Eighteen-month rollouts almost always fail; they become political, the leadership team that committed has moved on, and the system goes live half-configured because the budget is exhausted.
Look for vendors who can implement in six to eight weeks for a typical mid-size hospital. Anything beyond twelve weeks is a red flag — either the system is more complex than it should be, or the vendor's implementation team is undersized, or the rollout is being padded to bill more.
A good answer: a written timeline with named weeks, named deliverables, and a named clinical lead requirement from your side. Bundled training, configuration, and migration; itemised list of what's not bundled (custom integrations, hardware, complex legacy migrations). The bad version is "depends on your needs."
3. "Show me the audit trail."
Click into any patient record. Ask the vendor to show you, live, every action taken on that record — who, when, from where, what changed. If the answer involves opening logs in a separate tool, requesting an export, or "we can build that," walk away. Audit trails are foundational; if they're not first-class, the system was not built with healthcare compliance in mind.
A good answer: a built-in view, in the application, accessible to administrators, showing every read and write with full provenance. Tamper-evident. Exportable in standard formats. Reviewable by patients on request.
4. "What happens during a power or internet outage?"
Most of Ghana runs reliably most of the time. But "most of the time" is not "all of the time," and a hospital management system that fails during the four hours your facility loses connectivity has lost the trust of every clinician who tried to use it that morning. They will go back to paper, and they won't come back.
A good answer: specifics on offline behaviour. Read-only access to recently-cached records. Local queueing of writes that synchronise on reconnect. Graceful degradation rather than total failure. Clear documentation of what works and what doesn't during outages, so your staff can plan.
5. "How does the system protect patient data?"
The right answer here is technical and specific, not marketing. Patient data is sacred; the vendor should treat the question like the most important one in the conversation, not as a checkbox.
A good answer: encryption at rest (AES-256) and in transit (TLS 1.3), explicit data residency (where servers are physically located), tenant isolation (how your data is separated from other hospitals' data), backup cadence (how frequently, where stored, how recoverable), incident response (what happens during a breach, how quickly you're notified), regulatory alignment (Ghana DPA, ISO 27001, SOC 2). If the vendor cannot speak fluently to these terms, they are not ready to hold your patient data.
6. "What's your release cadence, and how do I know it works?"
A healthcare system that ships updates once a year is a system that has stopped responding to its users. A healthcare system that ships updates every Tuesday afternoon is a system that has stopped testing them. The right cadence is somewhere in between — frequent enough to evolve, deliberate enough to not break clinical workflow on a Tuesday morning.
A good answer: monthly releases with a published changelog, scheduled deployment windows that don't fall during clinical peak hours, staging environment access for technical buyers who want to test, clear rollback procedures when something goes wrong.
7. "What does support look like at 2pm on a Saturday?"
The wrong answer is "open a ticket." The wrong answer is "email support@vendor.com and we'll respond Monday." A clinical system has clinical-grade response requirements; a hospital management system that goes down on a Saturday afternoon and waits until Monday is a system the next medical director will be replacing.
A good answer: named support channels with SLA tiers. Issues that block patient care get a response in under an hour, in the channel your team actually uses (often WhatsApp in Ghana). Lower-severity issues get a response within a business day. Escalation paths are documented; the named account manager exists and answers their phone.
8. "Can I see the system running in another hospital?"
The most diagnostic question in any HMS sales conversation. The good answer is "yes, here are three references; the bad answer is "we have a demo environment with sample data." A demo environment is theatre; a working hospital is reality. The questions a clinician will ask after spending an hour in another hospital using the system are the questions that should be answered before you sign.
A good answer: a working customer (or, in the case of newer products, a substantive pilot) who will take a phone call and answer the questions you have. The bad version is "we're in stealth" or "all our customers signed NDAs." Healthcare buyers reasonably want to talk to other healthcare buyers; vendors who block that are vendors with something to hide.
What this looks like in practice
We built ACOS knowing these eight questions would be asked, because we ran them ourselves while looking at the alternatives. The answers we landed on are public:
- Built for Ghana, end-to-end. Not localised. - Six to eight weeks to live for a typical mid-size hospital. Implementation page. - Audit trail is first-class, in-application, tamper-evident. - Designed for intermittent connectivity from day one. - Encryption, residency, and compliance posture documented on the security page. - Monthly release cadence with public changelog. - WhatsApp support during business hours; clinical-blocker SLA under one hour. - Pilot in production at a private hospital in Accra; references available on request.
We're not the only system that can answer these eight questions well. We are one of the systems that wrote down our answers and stuck them on a website you can read at midnight before signing. That, more than anything else, is what we'd encourage you to look for in any vendor: the willingness to commit to specifics, in writing, before the contract.
Looking at HMS platforms in 2026? Tell us about your hospital. We're happy to talk you through ACOS — and equally happy to tell you when another system might fit better.
