Most hospitals in Kenya outside the handful of large referral centers run on some combination of paper registers, Excel spreadsheets, and WhatsApp groups for coordinating between departments. It isn't that nobody has tried to sell them software, it's that almost everything on offer was designed for a different health system entirely: unfamiliar billing codes, no concept of M-Pesa, no idea what SHA is, and pricing built for a hospital group rather than a forty-bed facility. Mwangaza HIMS is my answer to that gap, a hospital information management system built from the ground up around how a Kenyan clinic actually registers a patient, bills a visit, and reports upward to the ministry. Mwangaza General Hospital, the demo facility referenced throughout this piece, is hypothetical, a stand-in built specifically to show the product wearing a real hospital's clothes, but everything described about the system itself is running, tested code.
Built for how Kenyan hospitals actually run
A generic EMR built for a US or European market treats Kenya-specific requirements as
an afterthought, if it addresses them at all. Mwangaza HIMS treats them as the
starting point. Every invoice can be settled through M-Pesa via Safaricom's Daraja
STK Push, with a reconciliation job that checks payment status automatically every two
minutes so a delayed callback never leaves a cashier guessing. Every eligible visit
compiles into a SHA (Social Health Authority) claim, mapped to ICD-10 codes and pulled
straight from the same billing lines the patient already paid against, built ahead of
Kenya's 1 September 2026 deadline for digital SHA integration. Patients without a
smartphone or reliable data aren't locked out: they can check appointment status or
request a callback by dialing *384*1# on any phone, and the system pushes
SMS reminders and results notifications through Africa's Talking regardless of whether
that channel is up. On the reporting side, the facility rolls its aggregate numbers
into the ADX format Kenya's KHIS/DHIS2 system expects, and every patient's consent to
share their data is recorded against the Data Protection Act 2019 rather than assumed.
One patient, one record
Underneath all of that sits a single design decision that shapes everything else: a patient has exactly one record. Every visit, from the front desk to the pharmacy counter, attaches to one Encounter, so nothing about a patient's care lives in a departmental silo the next clinician can't see.
Registration → Triage (SATS) → Consultation → Lab / Radiology → Pharmacy → Billing → SHA claim
\_______________________ one Encounter, one patient record _______________________/Triage runs on the South African Triage Scale, the same acuity scoring Kenyatta National Hospital adopted in 2014, so a nurse's priority call is backed by a validated scale rather than gut feel, with a clinician free to override it when what they're seeing disagrees with the numbers. By the time a patient reaches billing, their lab results, prescriptions, and consultation notes are already sitting on the same record the invoice draws from, which is also, not coincidentally, the same story Mwangaza General Hospital's own site tells patients: a referral between departments doesn't mean repeating your history at every desk.
What's inside
Strip away the acronyms and the modules break into three groups. On the clinical side: patient registration, SATS triage, the consultation queue, an electronic medical record, lab test ordering and results, radiology order tracking, and pharmacy dispensing with allergy and interaction checks built in. On the administrative and financial side: itemized billing against a configurable service catalog, M-Pesa and SHA payments, inventory and reorder tracking, staff and roster management, and both facility-level dashboards and the KHIS aggregate export. On the patient-engagement side: SMS notifications for appointments, results, and payments; video telemedicine consultations; and the USSD channel for anyone without the patient portal's smartphone requirement. Twenty-six modules in total, each built and tested as its own unit, sharing one underlying patient record rather than twenty-six separate ones.
Sized for a local budget, not a hospital chain
"Packaged" means something specific here: the whole system ships as a Docker Compose stack, Postgres, Redis, the API, and the frontend, with a clear path from a single VPS to a small cluster if a facility outgrows it, rather than a cloud bill sized for a hospital group from day one. The staff dashboard is meant to sit on the hospital's own LAN or VPN rather than the open internet, while the patient portal stays public-facing for booking and viewing records. Telemedicine runs on self-hosted Jitsi rather than a metered video SDK, which removes a recurring per-minute cost that would otherwise scale against exactly the kind of facility this is built for.
Where it stands today
I want to be upfront about where the project actually sits: this is a feature-complete, hardened build, not yet running against a real hospital's live data or real SHA and M-Pesa credentials. It has 26 modules, 48 automated tests, continuous integration on every change, and a full end-to-end UAT run through the real patient journey: registration, triage, consultation, lab and prescription, invoicing, M-Pesa payment, SHA claim, and audit trail. The SHA and KHIS integrations are built against sandbox and mock adapters for the honest reason that no facility can get live credentials until Kenya's own integration opens ahead of that September deadline; the adapter pattern is deliberately kept thin so swapping in real credentials is a configuration change, not a rewrite. What it needs next is a real pilot: a hospital or clinic willing to run it alongside their existing process for a season and tell me where it breaks. If that's you, or you know someone it might be, reach out.