Two days to enter 200 patients: what a district health office needs from a system built without it.

Ask an ASHA worker in Uttar Pradesh — one of more than 160,000 in that state alone, the largest frontline health worker cadre in the country — what digital health transformation looks like from the ground, and the answer isn't a dashboard. It's two jobs instead of one: the same immunisation or maternal health record written first into a paper register, because the register is still the official record, then again into an app that logs itself out every fifteen minutes on a security timer, on a workflow that reliably takes longer than that to complete.

Field research on frontline digital tools describes workers entering the same patient's data into as many as ten separate registers and apps — one ASHA reported taking almost two full days to enter details for 200 patients on a single TB-tracking application. Connectivity drops mid-entry, silently losing work already done. And critically, most of these systems were specified and built at the state or national level with no feedback loop showing the worker what any of the data she enters is actually used for — no signal that the extra hour a day produces anything beyond compliance.

Why this reads as a success in every report that measures it

This is the pattern behind most public health digitisation that stalls at the frontline, and it's a design failure, not an adoption failure. The distinction matters because the two get treated identically in a monitoring report: both show up as "low usage" or "slow uptake," which quietly implies the frontline worker is the problem — reluctant, undertrained, resistant to change. In practice, an ASHA worker who is already doing ten data-entry jobs to hit the same reporting requirement a well-designed system could do in one is not resisting technology. She's rationally deprioritising a fourth or fifth redundant app in favour of the actual patients in front of her, which is the correct call given what she's been handed.

A system optimised for what a ministry needs to see on a dashboard, without being co-designed around what a health worker needs to do in a twelve-patient afternoon, will always look like a success in a monitoring report and a burden on the ground — because the monitoring report is measuring rollout, and the burden is measuring the thing rollout doesn't capture: whether the tool fits inside an actual workday.

What "designed backward from the last mile" means in practice

Concretely, it means three things a specification has to get right before a single line of frontline-facing code is written. First, single entry: a patient's data captured once, at the point of contact, propagating to every register and reporting system that needs it — not re-keyed by the same worker into each one separately. Second, offline-first as the default assumption, not an edge case handled later: local capture that syncs when connectivity returns, rather than a workflow that simply fails, silently, when the network does. Third, a visible feedback loop — the worker who enters an immunisation record should be able to see, in the same app, that it changed something: a stock reorder triggered, a case flagged, a supervisor notified. Without that loop, entering data is an act of faith in a system that gives no evidence back.

Systems designed this way — Stage 03 of implementation built around the frontline worker's actual day, not just Stage 01's policy intent — are the difference between a mission that reports adoption and one that has genuinely reduced anyone's workload. This is also where Tech Infra Advisory's offline-first architecture work and Training & Enablement's frontline capability building meet directly: the first has to build the tool correctly, the second has to make sure the person using it was never left to work it out alone from a PDF manual.