There is a moment at the free clinic I work at that I keep returning to. A patient is waiting. The prescription is written. The shared spreadsheet says a medication sample is available. It is not. Someone miscounted, a donation was never entered, or a bottle expired on a shelf that no one “owns.” We improvise—substituting, phoning around, apologising—and the visit continues. What does not continue is confidence: the patient learns that “we have it” is not the same as “we can deliver it reliably”. Over time, I have started to see this as a design failure before it is a supply failure: the information flow is brittle, and the workflow breaks exactly where patients feel it most.

My training in neuroscience and public health pushes me to think in systems. Small disruptions in signalling can cascade into downstream harm; in clinical operations, the comparable “signal” is trustworthy information—who records it, when it becomes true, and what happens when it is wrong. Digital health should, in principle, stabilise those flows and reduce friction. In practice, many tools underperform when they are designed for assumptions that do not match a low-resource environment. I argue that digital health in low-resource settings must be designed to fit clinical workflows, because misaligned digital systems actively degrade care quality.

The constraint is knowable before deployment

The International Telecommunication Union reports that in low‑income countries only 27% of the population uses the internet.¹ The GSMA adds an equity constraint that product roadmaps routinely underestimate: across low‑ and middle‑income countries (LMICs), women are 15% less likely than men to use mobile internet, representing roughly 265 million fewer women users.² If a digital intervention assumes continuous connectivity, a private smartphone, or uninterrupted charging, exclusion becomes a predictable implementation failure in low-resource settings.

Implementation research explains how those constraints become predictable failure modes. Professional eHealth users in low‑resource countries report barriers including unreliable power, limited infrastructure, lack of common interoperability standards, and shortages of trained workers.³ The World Health Organization emphasises that digital interventions are not a substitute for functioning health systems and should complement—not replace—fundamental system components.⁴ At the infrastructure level, the ITU–WHO Digital Health Platform Handbook describes how siloed tools create “islands of isolated information” and increase burdens through redundancy and duplicated effort.⁵ When the system demands two sources of truth, neither stays true for long. Failure cases make these mechanisms visible. During the Ebola response in Sierra Leone, Danquah and colleagues evaluated a smartphone contact‑tracing application and documented implementation challenges, including poor network coverage, technical problems, short battery life and charging issues, and a time lag between training and the emergence of real cases and contacts.⁶ The system had offline features, but the workflow still depended on synchronisation, daily power reality, and skills that decayed during that lag. A parallel lesson appears in remote care: in Médecins Sans Frontières’ tele‑mental health evaluation, 30% of respondents reported that more than half of their patients were unreachable, commonly due to poor network coverage, lack of devices, or lack of private space.⁷ These are not edge cases. They are design assumptions that collide with lived constraints. When these assumptions fail, the consequence is not only non-use, but erosion of trust in the system itself.

What scale actually looks like

The programs that do scale tend to look almost boring, which I think is the point. A CDC Emerging Infectious Diseases review reports that by October 2021, 55 countries had leveraged DHIS2‑based information systems to support COVID‑19 detection, prevention, and response measures, including vaccination.⁸ Indonesia’s measles–rubella campaign offers the same pattern at program level: a RapidPro‑based monitoring platform registered 6,462 health facilities across 28 provinces, and districts with greater platform utilisation demonstrated higher coverage and a shorter interval to achieving full coverage.⁹ Here, fit means minimal workflow disruption, use of channels suited to device realities, and embedding the tool in decision-making loops rather than adding parallel reporting burdens.

Even emerging technologies succeed when they are embedded into a defined operational bottleneck. In Rwanda, drone delivery of blood products achieved a mean delivery time of 49.6 minutes and was estimated to be 79 minutes faster than road delivery based on driving-time estimates, or 98 minutes faster using Google Maps estimates. The study also found a decrease of 7.1 blood-unit expirations per month, corresponding to a 67% reduction at 12 months.¹⁰ In Ghana, aerial vaccine logistics was associated with a 30% reduction in the duration of vaccine stockouts and a 44% reduction in missed opportunities for vaccination.¹¹ These systems worked not because they were flashy, but because they integrated into supply chains with measurable failure points.

Offline-first clinical software sharpens the boundary between fit and misfit at the point of care. In a mixed-methods feasibility study of the Hikma Health offline-first EHR, participants reported comfort after approximately three hours of training and about three weeks of use, and patient interview time decreased by roughly three minutes, which matters in high-volume clinics where small time savings compound across repeated patient encounters. The authors also report that workflows requiring repeated multi‑clinician synchronisation struggled under inconsistent connectivity and the design of sync functionality.12 For me, this is the design lesson in short: “offline‑first” is an architectural commitment. When this commitment is partial, systems revert to hybrid workflows that duplicate effort and reintroduce the very failures they aim to solve.

Design is a choice, not a constraint

From this evidence, and from my own clinic’s operational pain points, I draw four design commitments:

Workflow fit: the tool must match the actual sequence of tasks, roles, and handoffs.

Resilience: offline function, local storage, queued sync, and low-bandwidth fallbacks must be defaults.

Integration: interoperability and clear ownership must be planned from the start, because siloed tools predictably create redundancy.⁴

Equity: access barriers must be treated as acceptance criteria, not afterthoughts.²

These commitments also align with the broader implementation evidence. A sustainability review found that long-term use depends on simplicity, interoperability, adaptability, and continuous training and support, while the WHO Digital Implementation Investment Guide stresses needs-based planning aligned with national digital architecture and existing technologies.^13,14

Back to the medication shelf

The intervention I would build at the free clinic is not complicated. I would start with an offline‑capable inventory‑and‑dispensing workflow that shows “on hand / reserved / expires soon / substitutes” at prescribing, decrements stock at dispensing, and produces low‑stock notifications to the person responsible for procurement. This aligns with WHO’s recommendation to use stock notification and commodity management via mobile devices when supply‑chain systems can respond in a timely and appropriate manner.⁴ I would pair the tool with deliberate onboarding: micro‑training modules, role‑specific checklists, and brief supervised use, because training and refresher support are not peripheral—they are determinants of sustainability.¹³ The last mile does not need the most impressive technology. It needs the most reliable one.