Zazi Care
Member onboarding, loans, and M-Pesa deposits moved from paper forms to a self-service platform.
Zazi Care — main image
1600×900 · upload in admin → Content
Results
- The platform was designed so that the indicators that matter are produced by clinical work rather than compiled after it. The reporting layer queries clinical records directly. Available continuously, per facility:
- Antenatal coverage and visit completion, including who is overdue and by how long
- Delivery outcomes
- Immunisation coverage against the national schedule
- Growth and nutrition indicators, including children flagged for faltering
- PMTCT cascade progress, including infants due for testing this week
The challenge
Anyone who has sat in a Kenyan antenatal clinic knows this one. A mother's entire pregnancy record lives on paper she carries in her handbag. Lose the booklet, or deliver at a facility other than the one you booked at, and the clinical history is gone. The nurse starts over.
Kenya's maternal health records run on two Ministry of Health forms: the ANC card carried during pregnancy, and MOH 216, the mother-and-child booklet tracking immunisations, growth and development to age five. Both are well-designed documents. Both exist as a single physical copy held by the patient.
Three things follow from that.
Continuity breaks at handover. A mother books antenatal care at a dispensary and delivers at a sub-county hospital. The receiving clinician works from whatever she remembered to bring.
Defaulters are invisible. A woman who misses her third visit disappears until she turns up again, if she turns up. There is no overdue list, because there is no aggregate view of anything.
Reporting is transcription. Facility indicators get compiled by hand from paper registers, which means they arrive late and nobody entirely trusts them.
The obvious brief is "digitise the forms." We argued against it in the first week. Digitising a form gives you a better filing cabinet. The record still fragments the moment the mother moves between facilities.
THE APPROACH: THE JOURNEY BOOK
We inverted the data model instead. A Journey is one pregnancy lifecycle, and it owns every clinical record beneath it, from the first antenatal visit through to the child's fifth birthday. Four chapters:
Pregnancy - antenatal visits, labs, ultrasound, PMTCT, birth plan
Delivery - the delivery record and immediate newborn care
Postnatal - postnatal visits, feeding, mental health screening, family planning
Child - profile, immunisations, growth, developmental milestones
There is no such thing as a floating clinical record in this system. Every model carries a journey reference, and one API call returns a complete pregnancy in a single payload. That is what makes the mobile app and the facility-handover case work at all.
The constraint has a cost. Some things are genuinely awkward to model this way, and we made deliberate exceptions where the clinical reality demanded it. What we bought is continuity as a structural property rather than something a clinician has to remember to do.
What we built
We mapped the paper forms field by field rather than approximating them. That work is unglamorous and it was most of the project.
MOH 216 sections four through twelve are implemented in full: preterm follow-up and supplements, vitamin A, deworming, micronutrient powders, the developmental milestone checklist with red flags and autism screening, the special care checklist, hearing, eye and dental screening, and feeding counselling.
Alongside it: PMTCT with triple testing for HIV, syphilis and hepatitis B, ARV prophylaxis tracking, the early infant diagnosis testing schedule and an exposed-infant register. Postnatal depression screening. Cervical and breast cancer screening. Obstetric history, birth plans, family planning.
Nurses recognise the screens because the screens are the booklet.
Two engines that do clinical work
WHO growth monitoring, implemented directly against the growth standards. Weight-for-age, height-for-age and weight-for-height z-scores are computed on our own servers from the reference tables, with no external service call. A clinic on a poor connection still gets the score, and the malnutrition flag, immediately.
A national immunisation schedule engine. Given a date of birth it produces the full due schedule, tracks given against due, handles BCG scar checks and captures adverse event reports. Preterm infants get corrected-age handling automatically instead of the nurse doing the arithmetic at the desk.
A portal built the way clinicians think
The web portal is organised around the journey, not around lists. There are deliberately no standalone "all antenatal visits" pages. You reach clinical data by opening a mother, opening her pregnancy, opening a chapter. That mirrors the consultation, and it stops the record fragmenting in the interface the way it fragments on paper.
The antenatal form was the hardest interaction problem in the project. The paper first-visit form is enormous. Our first version was one long page, and it tested badly: nurses get interrupted mid-consultation, and an interrupted long form loses everything. We rebuilt it as a six-step flow that saves partial progress, holds the visit in an incomplete state until it is finished, and returns the nurse to the step she left. That change came from watching the form in use, not from the specification.
A companion app for mothers
Built in Flutter, with one-time-code sign-in rather than passwords, because password resets are a support burden this user base does not need. A mother sees her pregnancy, her upcoming appointments with facility and time, her child's health book, vaccine history, growth charts and health education content. She can log developmental milestones herself, and those arrive on the clinician's side clearly marked as parent-reported rather than mixed into clinical observations.
The infrastructure behind it
Facility-level tenancy, with data access scoped and enforced server-side rather than trusted to the client. Full audit logging across every clinical model, including read access, so the question "who opened this patient's file, and when" has an answer. Facility onboarding draws from the national health facility registry, so a provider signing up gets their official details populated rather than typed. Appointments generate themselves from the return dates clinicians already record, which makes the follow-up queue a by-product of ordinary work rather than a second data-entry task.
Messaging runs over push, SMS and email through one service path, with quiet hours and delivery deduplication.
WHAT THE SYSTEM MEASURES
The platform was designed so that the indicators that matter are produced by clinical work rather than compiled after it. The reporting layer queries clinical records directly. Available continuously, per facility:
Antenatal coverage and visit completion, including who is overdue and by how long
Delivery outcomes
Immunisation coverage against the national schedule
Growth and nutrition indicators, including children flagged for faltering
PMTCT cascade progress, including infants due for testing this week
Per-clinician activity
The point is not the dashboard. It is that a facility can see its defaulters on the day they default, and can answer a county reporting request without anyone opening a paper register.
Facing something similar?
One business day to a straight answer: what it takes, what it costs, and whether we are the right team for it.
Start a project