One hospital system, from registration and triage to theatre, pharmacy, claims and MOH reporting, branded for each hospital.

~50Modules
445Screens
33User roles
184Decision records

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

Frontend
  • SvelteKit 2
  • Svelte 5
  • TypeScript
  • Tailwind CSS 4
  • shadcn-svelte
  • TanStack Table
Data
  • MongoDB 8
  • Typesense
Infrastructure
  • Docker
  • Cloud Run
  • GitHub Actions
Integrations
  • OIDC
  • FHIR R4 (Kenya Core)
  • DHIS2 / KHIS
Other
  • 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