Open Smart Register Platform

Who the ten minutes actually belongs to

I brought the primary decision makers into the field to watch a real visit, because the number that came out of it would decide everything else. A household visit runs about ten minutes, which leaves roughly three for the app, and that is generous. The reason it needed defending is that ministries tend to see community health workers as free data collection — the visit is expensive and already happening, so why not attach something to it. We were asked for latrine and well-access status, socioeconomic classification, and in one case a full civil registry recording every person in a household. None of it helps her decide anything at the door, and every question she can’t use is one more reason to stop answering carefully.

Translating paper without translating its logic

On paper, a checklist of negative symptoms is scannable: a worker takes in twenty items at once, confirms what she already observed, and moves on. Translate that literally into a digital form and she walks through twenty sequential screens to record twenty things that aren’t happening. The paper version took seconds, the faithful version takes minutes, and the design job was to notice the difference before shipping it.

Nobody could approve anything

Every implementation had a health worker, a supervisor, a funder, an NGO, a ministry, and our product team, all wanting something different from the same screen and none of them outranking the others. I learned to find the day-to-day decision maker fast and take approval there, and to identify who only needed broad sign-off so they weren’t pulled into field-level choices. The national ministry was always the hardest room, because in a hierarchical system one senior preference becomes a requirement before anyone asks whether it survives a doorstep. Nothing I said in that room moved anyone — what moved them was watching a real health worker walk through a visit, or a role play, or failing that a video. The constraint has to be witnessed, not argued.

The first phone anyone had held

Most users had no smartphone vocabulary at all: no expectation of what a tap does, what a list means, or where to look first. So I built the interface out of objects they already carried — a home screen of stacked ledgers, patient records styled like the mother-and-child passport cards families kept at home, registers laid out as tables with color-coded flags so status read at a glance. Data entry ran through custom input screens built for each kind of value rather than generic form controls, because a generic field costs taps and taps cost minutes.

Then the metaphors expired

The physical language worked, and then it stopped working. Within a few years those same users had WhatsApp and YouTube on their own phones, and a stack of books is slower than a list once you already know what a list is — it mirrored the ledger faithfully, including the part where you page through a fixed order instead of searching. The forms aged the same way: paper always shows every question, so our first digital forms did too, until users fluent in smartphones let us introduce skip logic and show only what an answer made relevant. I retired the design language I had built and moved toward the patterns people had learned on their own time.

The system I couldn’t have designed on day one

For the first few years I designed implementations one at a time, and each one taught me how a health system actually differs from the one before it. That stretch is what made a design system possible, because only then could I see which parts genuinely vary — who is on a register, how they’re triaged, what a program is trying to catch — and which only appear to, like what a clinical form or a chart needs to do. The design system that came out of it put the landing view and profile under local control and held forms and charts fixed, and from then on I built mockups with in-country teams from its templates. That changed the conversation from “what should this look like” to “which of these does your program need,” which is why one product served eighty programs instead of becoming eighty products.

Mandatory fields were never a UI problem

The registers I watched in use had gaps everywhere — workers filled in what mattered in the time they had and moved on — while the standards those same workers were measured against assumed every field on every visit. The request that came back every year was to make fields required so the data would arrive complete, and I argued the other way every time. A required field doesn’t create time at a doorstep; it moves the cost onto the health worker, and when the field is wrong for the visit she enters something false to get past it. Completeness was a care-model decision needing supervision, training, and incentives behind it, not a validation rule in front of it.

Making something come back down

The original failure was that nothing returned to the person holding the record, and the clearest fix was the monthly report: two to three days of hand-tallying every month, replaced by a document generated from visits she had already entered. From there we shipped the things that pointed data back at her rather than up the hierarchy — lists prioritized by risk so her day followed who needed her most, one-tap check-ins so proving she’d worked no longer cost a full form, referral loops that told her whether the patient she sent to the clinic actually arrived, accomplishment views, peer chat, and supervisor review built as a conversation rather than an audit. A field that only feeds the hierarchy is a tax. A field that returns an answer is a tool.

Rebuilding FHIR-native with Google

We rebuilt OpenSRP with Google as one of the first FHIR-native applications of its kind, now part of Open Health Stack. With the updated design system and prototypes that behaved like the production app rather than slides describing it, new implementation time fell from three-to-six months to four-to-six weeks.