Kenya has one of the most ambitious community health programmes in sub-Saharan Africa. Under the Community Health Policy and the broader Universal Health Coverage agenda, the country has committed to deploying a Community Health Promoter (CHP) for every 100 households — roughly 100,000 CHPs nationally, each responsible for a defined household roster, each conducting monthly household visits, referring sick members to higher-level facilities, and collecting health data on the populations they serve.1
In principle, this is a remarkable infrastructure. A trained health worker with a defined caseload, visiting every household every month, collecting consistent data, and linking the community to the formal health system. In practice, it is a remarkable infrastructure operating without the instruments it needs to function.
The CHPs record household visits in paper registers. The registers are collected periodically by Community Health Assistants — supervisors who cover twelve to fifteen CHPs each — and the data is manually entered, sometimes weeks after collection, into a national health information system that was not designed for community-level operations. By the time the data reaches any level of aggregation where it might inform a decision, it is months old, significantly incomplete, and stripped of the contextual detail that made it useful.
This is not a criticism of the people in the system. The CHPs we have spent time with are motivated, deeply knowledgeable about their communities, and doing remarkable work under significant constraints. The problem is structural: they have been given a mandate to generate operational health intelligence for Kenya's communities, and they have not been given the tools to do it.
What community health data is supposed to do
The purpose of the CHP programme is not just service delivery — it is early detection. A CHP who visits every household monthly is in a position to notice things that no clinic-based system can see: the child who has lost weight three visits in a row, the elderly person whose mobility has declined, the household where three members have developed coughs within a week of each other, the pregnant woman who has missed two scheduled ANC visits.
These are signals. In aggregate, across a sub-county, they are early warning systems for malnutrition trends, disease surveillance, maternal health gaps, and chronic condition deterioration. In a well-instrumented system, they would flow up the health hierarchy in near-real-time, trigger responses, and generate a continuously updated picture of community health status.
Kenya's community health architecture was designed with this vision in mind. The problem is not the design. The problem is that the data collection and transmission infrastructure was never built to match the ambition.
In practice, these signals mostly disappear. They are recorded in a register, the register is collected at some point, the data entry happens at some later point, and by the time anything aggregated reaches a supervisor or facility manager, the specific household with the specific pattern has been lost in aggregation. The early warning system exists on paper. It does not exist in practice.
The register problem
The paper register is the defining constraint of the current system. It is not just a data collection tool — it is the entire operational layer. Everything the CHP does is mediated through the register: household visits, referrals, follow-ups, births and deaths, new household members, nutrition screenings.
This creates several compounding problems.
Longitudinal tracking is essentially impossible. A paper register is organised by visit date. To understand a household's health trajectory over six months — which is the unit of analysis that matters for chronic conditions, nutrition monitoring, and pregnancy tracking — a CHP has to physically leaf through multiple register pages, find and reconcile entries for the same household across different months, and do this for every household they want to review. In practice, this means it does not happen. CHPs know their households from memory, not from structured records.
Referral follow-up is broken. When a CHP refers a household member to a facility, the register records the referral. Whether the person actually went, whether they were seen, what happened — none of this comes back to the CHP. The referral system is unidirectional. CHPs have no systematic way to know whether their referrals led to care. This means they cannot follow up effectively, and it means the community-to-facility link exists as a recommendation, not a closed loop.
Data quality degrades over time. Paper registers wear out, get wet, go missing. Entries made under pressure — at the end of a long day, in a dark household, with a restless infant nearby — are sometimes illegible or incomplete. By the time data is transcribed, errors compound. The national health information system receives data that is a lossy copy of what was collected, which was itself a selective record of what was observed.
| Indicator | Intended frequency | Actual reporting rate | Lag to national system |
|---|---|---|---|
| Household visits completed | Monthly | 68% | 6–10 weeks |
| Nutrition screenings (under-5) | Monthly | 51% | 8–12 weeks |
| Referrals made | As needed | 82% | 6–10 weeks |
| Referral outcomes recorded | As needed | 14% | Often never |
| Births in catchment | As occurred | 73% | 6–10 weeks |
| Maternal ANC follow-up | Monthly | 44% | 8–12 weeks |
Community health data gaps: selected indicators, sample sub-county, Kiambu County, 2024
These numbers are drawn from a sub-county engagement we conducted as part of early research for our community health programme. The pattern — reasonable visit rates, collapsing data completeness, significant lags, and near-total failure of referral outcome tracking — is consistent with what has been documented in multiple studies of Kenya's CHU system.
What a well-instrumented system would look like
We have been spending time in the community health sector precisely because we believe the infrastructure problem here is solvable, and the value of solving it — in lives, in early detection, in the integrity of Kenya's UHC ambition — is significant.
A well-instrumented community health system would have several properties.
The CHP's phone is the source of truth. Not a paper register. A structured digital form, designed for one-handed use during a household visit, that captures visit data in a format that is immediately queryable. Offline-first, as with all our operational software — the visit is recorded to local storage regardless of connectivity and synced when available. The timestamp reflects when the visit happened, not when it was entered.
Longitudinal household records are built automatically. Every visit adds to a persistent record for each household and each household member. Reviewing a household's health trajectory over six months means opening a screen, not leafing through a register. Patterns — declining nutritional status, repeated respiratory symptoms, missed ANC visits — can be surfaced automatically rather than relying on the CHP to manually detect them across paper pages.
I supervise fourteen CHPs. Every month I have to collect fourteen registers, go through them, and try to make sense of what happened. By the time I have finished, the month is almost over and I am already behind on the next one. I am always looking backwards, never forwards.
— Community Health Assistant, Kiambu County
Referral loops are closed. When a CHP makes a referral, the system flags it for follow-up. If the referred person does not show up at the facility within a defined window, the CHP is notified. When facility data is available — which requires integration with the facility's system — the outcome flows back to the CHW record. The referral system becomes a closed loop, not a one-way recommendation.
Supervisors have a real-time view. The Community Health Assistant does not have to wait for paper registers to understand what is happening across their caseload. Visits completed vs. pending, households with open flags, referrals outstanding — all available on demand. Not six weeks after the fact.
The harder problem: integration
Building the right field tool is the tractable part. The harder problem is integration with the broader health system.
Kenya's facility health information system is DHIS2, which is widely used across sub-Saharan Africa and has significant institutional investment. The national community health system uses a parallel platform. These systems are not, in any operational sense, connected. Data moves between them through manual processes — if it moves at all.
For a community health tool to fulfil its potential, it needs to exchange data with the facility system. CHPs need to know which of their households have active facility records, which have upcoming appointments, and what happened when they referred someone last month. Facilities need to know which households in their catchment area have been flagged by CHPs for follow-up. Neither can serve the other well when operating in complete informational isolation.
This integration is technically achievable. DHIS2 has an API. The will to use it exists at national level. What has been missing is operational software that makes the integration worth building — that gives the facility system something worth receiving, and the community system something worth sending.
This is the pattern we see across all of Flux's research areas: the technology to connect these systems exists, the APIs exist, the standards exist. What has been missing is operational software worth integrating — software that is actually used, that produces clean data, that generates enough institutional value to justify the integration investment.
Why this is on our roadmap
We have not yet built a community health product. We are in research. But we are in research with conviction.
Kenya's CHPs are the most distributed operational health infrastructure in East Africa. 100,000 trained workers, each with a defined household roster, each conducting regular household-level contact with populations that no facility-based system can reach at this resolution. This is an extraordinary asset that is operating far below its potential — not because of the people in it, but because of the tools.
The software problem here is real, tractable, and consequential. We know how to build offline-first field tools. We know how to close operational loops. We know how to make data flow from the field to supervision to the health system in a way that preserves its integrity and timeliness.
What we still need to understand — and what our current research is trying to answer — is the specific operational workflow of the CHP, the specific data the Community Health Assistant needs to supervise effectively, and the specific integration points with DHIS2 and facility systems that would create the most value. We are spending time in sub-counties, with CHPs, with CHAs, with facility managers. Building from observation, not assumption.
When we build, we will build offline-first, closed-loop, and integrated. And we will publish what we learn regardless of what the product becomes.
— Ken Ruto
Under Kenya's Community Health Policy and the Universal Health Coverage agenda, the government has deployed roughly 100,000 Community Health Promoters — since expanded to about 107,000 — each serving around 100 households across some 10,000 community health units. Ministry of Health, Kenya (2023); see also Amref Health Africa.↩
