Skip to content
In active development· June 2026

Medilog EHMS

An electronic health management system built from inside Tanzanian clinical practice: patient records, workflows, and reporting without the paper chase.

The story

I didn't decide to build a hospital system and then go looking for problems. The problems were already on my desk. Through medical school, internship at a regional referral hospital, and now clinical practice at Consolata Hospital Ikonda, the same pattern kept repeating. The medicine was sound, but the information around it kept failing: files that couldn't be found, results that arrived after decisions had to be made, and hours of clinician time spent transcribing the same facts onto new pieces of paper.

Before medicine, I spent years fixing computers for a living. That work taught me to treat every fault as a system problem: reproduce it, isolate the layer, fix the cause rather than the symptom. Medilog is that method applied to the workflow I now live inside every day. I'm not building it as an outside vendor guessing at hospital life. I'm building it between ward rounds, from the records I actually handle.

The problem

A patient arrives for follow-up. Their file is somewhere in the registry, in another department, misfiled, or gone. So the history gets retaken from memory, the previous plan is reconstructed from what the patient recalls, and a test that was already done gets ordered again. Nothing about this is rare; it is an ordinary morning in most paper-first facilities.

The costs compound:

The approach

Three decisions shape Medilog more than any feature list:

  1. The patient record is the spine. One record, captured once, readable at every step of the visit: reception, triage, consultation, lab, pharmacy. Most of the pain in Fig. 1 is not a missing feature; it's the absence of a shared record.
  2. Design from the ward outward. Every module must trace to a workflow I or my colleagues actually perform. If a screen doesn't map to something that happens in a Tanzanian hospital corridor, it doesn't belong in the product.
  3. Honest, incremental scope. Registration and clinical documentation first, because that's where continuity dies today. Lab, pharmacy, reporting, and administration are mapped, and labeled planned, not promised.
Diagram of one patient visit: five steps from reception to pharmacy, each annotated with its paper-workflow pain point, connected to a single shared Medilog patient record that feeds reporting, audit, and continuity of care.
Fig. 1 — One patient visit: where the paper record breaks, and where a single shared record holds.
Concept architecture diagram: a patient-record core surrounded by six modules — registration and visits, clinical documentation, lab and results, pharmacy and dispensing, reporting and analytics, administration — with development status marked per module.
Fig. 2 — Concept architecture: a patient-record core, with modules added in order of clinical need.

Where it stands

As of June 2026, Medilog is in active development: the patient-record data model and the registration and clinical-documentation workflows are being built and tested against daily practice at Ikonda. Next steps, in order: close the documentation loop on a full outpatient visit, then extend the record to lab requests and results.

If you work in healthcare delivery, health-tech, or hospital administration and this problem looks familiar, I'd genuinely like to compare notes, so get in touch.