Skip to main content

An AI community health worker app puts decision support on a health worker’s phone: it guides assessment, flags danger signs, suggests referral and records the visit. WHO has recommended mobile decision support for tasks already within a health worker’s scope since 2019. These tools help when they fit a short, often offline household visit and fail when they add screens and steps.

A community health worker walks into a compound at four in the afternoon. There is a toddler with a cough, a grandmother with swollen ankles, a pregnant neighbour who has come over because she heard the health worker was visiting, and a goat in the doorway. There is no reliable signal. The phone battery is at 31%. The health worker has maybe ten minutes before the next household, and six more to go before dark.

Now imagine the AI tool designed for this visit. If it was built in a well-lit office with fast Wi-Fi, it probably asks forty questions in a fixed order, expects a connection to load its model, and produces a paragraph of advice written for a doctor. It will be abandoned within a month, and the pilot report will blame “low digital literacy”.

The thesis of this piece is that AI decision support for community health workers succeeds or fails on time and fit, not on intelligence. A modest model that fits the visit beats a brilliant one that doesn’t. And the most important design decision is not what the AI knows but when it chooses to speak.

What do AI apps for community health workers actually do?

Most digital tools for community health workers already do some form of decision support. They walk the worker through a protocol, such as integrated community case management of childhood illness, and convert answers into a classification: treat at home, refer, or refer urgently. They also track households, schedule follow-ups and send data up the chain.

The newer AI layer adds several possibilities. Language models can answer free-text questions, summarise a household’s history, or translate guidance into a local language. Image models can help read a rapid test, assess a wound or check a child’s arm circumference measurement. Speech tools can let a worker dictate notes instead of typing.

WHO’s 2019 guideline on digital interventions for health system strengthening, its first on digital health, recommended digital decision support on mobile devices for community and facility-based health workers, but only for tasks already within the worker’s defined scope of practice and only under specific conditions. It also recommended combining digital tracking of clients with decision support where the health system could support both in an integrated way. That conditional wording is the important part. WHO was not endorsing apps in general. It was endorsing support for work the health worker was already trained and authorised to do.

Does AI decision support improve care?

The strongest recent evidence comes not from community health workers but from the tier just above them. In 2025, OpenAI and Penda Health, a primary care provider in Nairobi, released a study of an AI tool called AI Consult, used by clinicians in Penda’s clinics. The study covered 39,849 patient visits across 15 clinics between January and April 2025. Clinicians with access to the tool made 16% fewer diagnostic errors and 13% fewer treatment errors, relative to those without, as judged by independent physicians reviewing a sample of visits. At release, the study had not been peer reviewed.

The design detail matters more than the headline. According to reporting on the study, the tool was redesigned to run quietly in the background of each visit and alert the clinician only when something looked wrong, using a traffic-light system: green for no concern, yellow for a caution, red for a potential safety issue. It was adapted to Kenyan clinical guidelines. Coverage of the study, including in STAT, emphasised that the hardest part was not the model but getting it to fit the clinicians’ actual workflow.

That is the lesson that transfers to community health work. A tool that waits silently and speaks up only when it matters respects the visit. A tool that demands attention at every step competes with the patient.

It is also a caution. Penda’s clinicians are trained clinical officers working in clinics with electricity and connectivity. A community health worker in a compound has less training, less time, and often no signal. The same design principle applies, but the constraints are tighter.

Why do community health worker apps fail?

The failure modes are familiar to anyone who has watched digital health programmes scale.

They add time. Every screen is a cost. If the app takes longer than the paper form it replaced, workers will fill it in after the visit from memory, or not at all. The data looks complete and the decision support never actually informs a decision.

They assume connectivity. A model that needs a server round trip will fail in the places that need it most. Anything critical must work offline, with syncing when a signal returns. Our piece on digital health in low-bandwidth settings argues that the missing link is usually a person, not a connection, and that holds doubly for AI.

They speak the wrong language. Advice in formal English or a national language may be technically correct and practically useless when the worker thinks, and the family speaks, in something else.

They refer into a void. An app that correctly identifies a danger sign and recommends urgent referral has done its job only if there is a facility that will receive the patient, transport to get there, and a way for the worker to know what happened. Otherwise the app generates alarm, not care.

They pile on tasks. Each new feature is a new expectation. Community health workers are already asked to deliver an expanding list of services, often for a stipend or less. As we argued in community health workers don’t burn out, programmes burn them up, the burden is usually designed in from above.

What would a good AI tool for a household visit look like?

Start with the ten minutes. Any design that cannot be completed inside a short visit, with interruptions, in the worker’s language, on a mid-range phone with no signal, is not a design for community health work.

Within that constraint, a few principles follow.

Speak only when it matters. Run the protocol in the background and interrupt for danger signs, drug interactions, missed follow-ups and dose errors. Let the worker move through routine visits without friction.

Ask fewer questions. Use what is already known about the household from previous visits. A tool that pre-fills the child’s age and vaccination status saves more time than one that reasons brilliantly about pneumonia.

Work offline by default. Small models that run on the phone, with larger models used only when connected for non-urgent tasks, such as summarising a week’s visits.

Close the loop. When the tool recommends referral, it should notify the receiving facility, and the worker should find out whether the patient arrived. Referral completion is a better success measure than app usage.

Stay within scope. The tool should support tasks the worker is trained and authorised to do, which is exactly WHO’s condition. An AI that nudges a community health worker into diagnosing conditions beyond their training is not task-shifting. It is risk-shifting.

A worked example: two apps, one visit

This is a hypothetical comparison, built to illustrate design choices.

A community health worker visits a household with a two-year-old who has had a cough and fever for three days.

With App A, she opens a new assessment form. It asks her to enter the child’s name, age and weight, although these were recorded last month. It then presents 22 questions, one per screen. At question 14 it asks her to count breaths for 60 seconds using an in-app timer. The app then tries to reach a server to generate advice, fails, and saves the visit as pending. She tells the mother to go to the clinic if things get worse. The visit takes 18 minutes.

With App B, the household record opens with the child’s details and last visit already loaded. She taps “cough and fever”. The app shows the three questions that matter for danger signs and a breathing counter. The count is fast for the child’s age. The app, running offline, flags possible pneumonia, shows the correct dose of amoxicillin for the child’s weight from the protocol she is trained on, and prompts a follow-up visit in two days. It queues a note to the health centre so that if the child does not improve, the nurse already knows. The visit takes nine minutes.

App B has less AI in it than App A. It is far more useful.

The strongest counterargument: is the ten-minute visit the wrong target?

A fair critic would say that designing for speed risks designing for shallowness. The household visit is short because programmes are under-resourced, not because ten minutes is enough. Optimising AI tools for that constraint may lock it in, making it easier for funders to add more households per worker instead of more workers. Large language models, the critic would add, could enable longer, richer conversations about nutrition, mental health or family planning that a checklist never could.

This deserves weight. There is a real risk that efficiency gains are captured as higher caseloads rather than better care, the same risk we have flagged for hospital AI scribes. And some conversations should take longer.

But the answer is not to design tools that ignore the time available. It is to design tools that save time on the routine parts so that time exists for the conversations that matter, and then to protect that time in the programme’s targets. That is a decision for managers and ministries, not software. The tool can create the time. Only the programme can decide not to spend it on more households.

What this means for ministries, donors and developers

For ministries of health, set procurement requirements that reflect the visit: offline operation, local language support, completion time targets tested with real workers, and integration with referral facilities. Measure referral completion and follow-up, not logins.

For donors, recognise that the AI moment in primary care is arriving with serious money. In January 2026 the Gates Foundation and OpenAI announced Horizon1000, a $50 million initiative to bring AI tools to 1,000 primary health care clinics and their communities in Africa by 2028, starting in Rwanda. Initiatives like this will set norms. Insist that community health workers are designed for, not an afterthought, and fund independent evaluation of outcomes, not just adoption.

For developers, test in the household, not the office. Time every visit. Count screens. Measure battery drain. Treat every interruption as a cost the worker pays. And remember that in task-shifted systems, as we argued in task-shifting is safe when the system is built for it, the tool is part of the system, not a substitute for it.

Frequently asked questions

Does WHO recommend apps for community health workers?

WHO’s 2019 guideline on digital interventions recommends digital decision support via mobile devices for community and facility-based health workers, but only for tasks already within their scope of practice and in specific conditions. It also recommends combining digital client tracking with decision support where the health system can support both. It does not endorse any specific app or AI product.

Can AI help community health workers diagnose illness?

AI can support community health workers in following established protocols, such as identifying danger signs in sick children, calculating drug doses and flagging when referral is needed. It should not push them to diagnose conditions beyond their training. The safest designs keep the worker within their defined role and make referral to a qualified clinician easier and faster.

Do community health worker apps work offline?

Well-designed ones do. Many established community health platforms store data on the phone and sync when a connection is available. Newer AI features, especially those based on large language models, often need a connection, which limits their use in remote areas. Any feature needed for safety during a visit, such as danger-sign detection or dosing, should work without a signal.

What is Horizon1000?

Horizon1000 is an initiative announced in January 2026 by the Gates Foundation and OpenAI, with $50 million in funding and technology, to support African countries in using AI to strengthen primary health care. It aims to reach 1,000 primary health care clinics and their surrounding communities by 2028, beginning in Rwanda, with plans to expand to other countries.

The takeaway

The best AI for a community health worker is the one she barely notices until it matters. Build for the compound, the dying battery and the ten-minute visit, and measure whether the referred child reached the clinic. Everything else is a demo.

If you have used a digital tool as a community health worker or supervisor, what is the one feature you would delete tomorrow?

Abhishek Shankar

Abhishek Shankar is a three-time founder and CEO of MyBabyBridge, which uses AI and data to make IVF more accessible. He writes about the gap between what works in health pilots and what survives at scale, covering financing, workforce, digital health and equity. He writes more at abhishek-shankar.com.

Leave a Reply