One hospital system, from registration and triage to theatre, pharmacy, claims and MOH reporting, branded for each hospital.
Project Summary
- Client: Own product
- Industry: healthcare
- My role: Founder & Lead Engineer
- Core tasks: Product architecture, Clinical workflows, Web app, Interoperability (FHIR, DHIS2), Revenue cycle
- Appointed date: Sep 2026
- Completion: Ongoing
- Team size: 1
Most Kenyan hospitals run on a patchwork: one system for billing, another for the lab, paper on the wards and spreadsheets for MOH returns. Dira (Swahili for "compass") is a single hospital management information system that each hospital can run under its own brand.
What it covers
- Patient flow. Registration with a master patient index and duplicate detection, appointments, queues, triage with an early-warning score, outpatient encounters and emergency.
- Clinical services. Lab, radiology, pharmacy and stock, admissions and bed board, nursing and eMAR, theatre, ICU, maternity, NICU, dialysis and oncology.
- Revenue cycle. Billing, cashier, refunds, payers, pre-authorisations, claims and remittances, feeding a finance ledger.
- Back office. HR and rostering, inventory and procurement, assets, fleet and mortuary.
- Reporting and governance. MOH 705, 710 and 717 returns, public-health surveillance, research, a patient portal, and audit and privacy controls.
Under the hood
Dira is a SvelteKit and TypeScript application on MongoDB, with Typesense search and OIDC sign-in. A hospital can run on dedicated infrastructure or share a multi-tenant deployment with its own database, managed from a control plane. Clinical data moves as FHIR Kenya Core bundles, reports map to DHIS2/KHIS, and sensitive actions use four-eyes approvals, break-glass access and an audit ledger. It ships as a hardened Docker image, and 33 roles drive a generated access matrix.
Built to be trusted
Every significant design choice is written down: 184 architecture decision records so far. Playwright tests run on phone, tablet, laptop and desktop, alongside accessibility, FHIR-conformance, contract and load tests. A downtime mode with paper registers and reserved identifier blocks keeps a hospital running when the network doesn't.
Where it stands
Dira runs end to end against synthetic hospitals and patient data, and is ready for a first pilot site.
Tech stack
- SvelteKit 2
- Svelte 5
- TypeScript
- Tailwind CSS 4
- shadcn-svelte
- TanStack Table
- MongoDB 8
- Typesense
- Docker
- Cloud Run
- GitHub Actions
- OIDC
- FHIR R4 (Kenya Core)
- DHIS2 / KHIS
- Playwright
What I did
- Designed the product, domain model and tenancy architecture
- Built clinical, revenue-cycle and back-office modules
- Built FHIR Kenya Core, DHIS2/KHIS and payer integration layers
- Set up testing across devices, accessibility, conformance and load
Key decisions
- A separate database per hospital, managed from a control plane
- FHIR Kenya Core as the interoperability contract
- Architecture decision records for every significant choice
- A designed downtime mode instead of assuming connectivity
Challenges
- Keeping ~50 modules consistent under one domain model
- Isolating each hospital's data while sharing one codebase
- Mapping clinical records to FHIR Kenya Core and MOH returns
Have a similar problem to solve? Let's talk.
Start a conversation