Skip to main content

According to the GSMA’s 2025 report on mobile internet connectivity, 96% of the world’s population now lives within reach of a mobile broadband network. Yet 3.1 billion people who could get online do not use mobile internet at all. The GSMA calls this the usage gap, and it is now far larger than the coverage gap.

That single statistic should reorganise how we think about digital health in low-resource settings. The standard story is about bandwidth: slow networks, patchy signal, apps that will not load. Those problems are real. But for most people who are left out, the binding constraint is not the tower. It is the cost of a smartphone and data, the skills to use it, and whether anything on offer is worth the effort.

The digital health programmes that have reached real scale in these settings tend to share one design choice. They put a human being between the patient and the technology.

The apps that scaled were not really apps

Consider two very different examples.

South Africa’s MomConnect, launched by the National Department of Health in 2014, sends pregnant women and new mothers health messages by SMS and, more recently, WhatsApp. Registration runs through a reverse-billed USSD code, the same menu-based system people already use to top up airtime, which works on the most basic phone and costs the user nothing. Crucially, women are typically registered at their antenatal clinic, with a health worker helping. The programme has registered millions of women and reached public antenatal clinics across the country.

India’s eSanjeevani telemedicine platform had logged more than 430 million consultations by late November 2025, according to the Ministry of Health and Family Welfare. A large share of those run through a provider-to-provider model: a community health officer at a local Ayushman Arogya Mandir, a primary care centre, sits with the patient and connects to a doctor or specialist at a hub facility. The patient does not need a smartphone, data or digital literacy. The health worker brings all three.

Neither is the frictionless, direct-to-consumer model that dominates digital health pitches. Both work at a scale most of those pitches never reach.

Assisted beats autonomous where the usage gap is wide

The logic is straightforward once the usage gap is taken seriously. If the patient lacks the device, the data budget or the confidence, a patient-facing app has to overcome all three before it delivers any health benefit. A health worker with a tablet has to overcome none of them on the patient’s side.

Assisted models also solve a problem that bandwidth fixes cannot: trust. A text message from an unfamiliar number is easy to ignore. A consultation arranged by a nurse the patient already knows carries her credibility with it.

The same principle applies behind the scenes. DHIS2, the open-source health information system coordinated by the University of Oslo, is used as a national-scale system in more than 70 countries. Its Android capture app is designed to work offline and synchronise later, so a health worker in a clinic with no signal can keep recording data. The design question was never “how do we get fast internet to every clinic?” It was “how do we keep working without it?”

The uncomfortable trade-off

Assisted models have a cost that donors and investors often dislike. They depend on health workers, who need salaries, training and supervision. That makes them look less scalable, and less like a technology investment, than an app that promises to reach millions at near-zero marginal cost.

This creates a steady bias toward funding the wrong thing. Patient-facing apps are cheap to launch, easy to demonstrate and generate impressive download figures. Assisted models are slower to set up and show their value in routine service data, which rarely makes a slide. So pilots of consumer apps multiply, while the less glamorous hybrid models that actually reach the poorest users struggle for recurrent funding.

There is also an equity trap. A service that only works on a smartphone with a data plan will be used first by those who are already better off. Without deliberate design for the lowest common denominator, digital health can widen the gap it was meant to close.

Designing for the real constraints

A few principles that follow from this:

  • Design for the cheapest phone first. SMS, USSD and voice reach people that apps do not. Add richer channels on top, not instead.
  • Build offline by default. Assume connectivity is intermittent and let data synchronise when it can.
  • Zero-rate or reverse-bill. If users pay for data to access a health service, many will not.
  • Fund the intermediary. Budget for the health worker’s time as part of the digital programme, not as an external dependency.
  • Measure reach by who is left out. Track use by the poorest quintile and rural districts, not just total registrations.

The mechanism: every barrier compounds

It is worth being precise about why a direct-to-patient app struggles in these settings, because the problem is multiplicative rather than additive.

For a patient to benefit from a health app, a chain of conditions must all hold. She must own or have regular access to a smartphone. She must have data credit when she needs it. She must be able to read the language the app uses, or navigate it through icons and voice. She must know the app exists and trust it. She must have enough privacy to use it for sensitive matters. And there must be a clinical service at the other end that can respond.

If each of those conditions holds for, say, seven in ten people in a poor rural district, and the conditions were independent, the share for whom all six hold would be far lower than seven in ten: roughly one in eight or nine. In reality the barriers cluster in the same households, which is exactly who gets left out. That is the arithmetic behind so many digital health pilots that report enthusiastic early users and then plateau. The early users are the people for whom every link in the chain already worked.

An assisted model breaks the chain. The health worker supplies the device, the data, the literacy and the trust. The patient needs only to turn up at a facility or be visited at home. The number of conditions that must hold for the patient falls from six to one or two.

A worked scenario: two ways to reach the same mothers

Imagine a ministry that wants to improve attendance at postnatal check-ups in a rural region.

Option one is a smartphone app for new mothers, with reminders, educational videos and a chat function. It launches with a publicity campaign. Downloads are respectable in the towns. In villages, uptake is low: many mothers share a basic phone with their husband or have no data credit, and the videos take too long to load. Those who do use it are mostly the mothers who were already likely to attend. The app’s dashboards show good engagement among active users, and the ministry reports success.

Option two uses community health workers who already visit households. Each is given a basic Android phone with an offline app that records births, schedules postnatal visits and sends a free SMS reminder the day before. When a mother misses a visit, the health worker sees it on her list and calls or visits. Uptake is slower to build and costs more per month, because the health workers need phones, airtime and supervision. But it reaches the mothers who are least likely to attend on their own.

The first option looks more like digital innovation. The second is more likely to change the number the ministry actually cares about.

The strongest counterargument

Advocates of direct-to-consumer tools have a serious point. Health workers are scarce and expensive, and many health systems cannot afford to add more. Building digital programmes on top of a workforce that is already stretched risks overloading them with data entry and reporting. Meanwhile, smartphone ownership is rising quickly, especially among young people. Designing for today’s constraints may mean building systems that are outdated in five years. Direct tools also give people autonomy and privacy that an intermediary cannot.

This argument partly holds. Health worker time is precious, and poorly designed digital tools have added reporting burdens without reducing others. Some users, particularly younger and urban ones, do prefer direct access, and for sensitive topics such as sexual and reproductive health, privacy can be decisive.

But the argument is about the future population, while health systems have to serve the current one. The people with the greatest health needs tend to be the last to get smartphones and data. A strategy built on direct tools will reach them last. The practical answer is layering: assisted models for the hardest-to-reach, direct tools for those who can use them, and a shared backend so that both feed the same records.

Second-order effects to watch

Health worker burden. Every new digital tool asks something of frontline workers. Without discipline, a community health worker can end up carrying several apps from different donors, each with its own reporting requirements.

Data quality. Assisted models generate data that is only as good as the health worker’s time and training. When workers are paid per record or per visit, the incentive can shift toward volume over accuracy.

Platform lock-in. Programmes built on commercial messaging platforms depend on those companies’ pricing and policies. A change in terms can raise costs overnight.

Sustainability. Many successful programmes began with donor funding. Transitioning to government budgets is where many stall. Assisted models, with their recurring staff costs, face this challenge most sharply.

What this means for different players

Ministries should treat community health workers as the primary interface for digital health in underserved areas and budget for their tools, airtime and supervision as part of core health spending. They should also limit the number of separate apps frontline workers must carry.

Funders should resist funding standalone consumer apps without evidence of reach among the poorest users. Paying for the recurring costs of assisted models, and for their transition to domestic budgets, is less visible and far more valuable.

Mobile operators and regulators can help by making health services free to access, through zero-rating or reverse billing, as MomConnect’s USSD registration shows is possible.

Clinicians at hub facilities in assisted telemedicine models should be given the time and training to do remote consultations well. A rushed specialist on a bad connection can undermine trust in the whole model.

Developers should design for intermittent connectivity, basic handsets and low literacy from the start, and test their products in the places where they are meant to work, not just in the capital.

What to watch next

Several signals will show whether digital health in low-bandwidth settings is maturing. Watch whether national digital health strategies explicitly budget for assisted access, not just platforms. Watch whether donors coordinate to reduce the number of separate apps on each health worker’s phone. And watch whether the usage gap, rather than coverage, becomes the headline metric that ministries and funders report against.

The takeaway

Low-bandwidth digital health is not mainly a connectivity problem waiting for better networks. Networks are arriving faster than people are adopting them. The programmes that reach the people furthest from care are the ones that accept this and route technology through people who are already trusted.

The best low-bandwidth health technology may turn out to be a well-supported community health worker with a phone that works offline.

What’s the most effective digital tool you’ve seen work without reliable internet, and who made it work? Share it in the comments.

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