When we built the measles care pathway for first-level health workers in Tamaulipas, the architecture decision took about a minute.
One HTML file. No backend. No login. No network calls. It runs from a phone, from a USB stick, from a folder someone copied over Bluetooth.
That is not an elegant choice. It is barely a choice at all. It is what the constraint leaves you.
The constraint
The connection drops. The patient is still in front of you.
That sentence is the whole specification. Everything else follows from it.
A health worker in a community clinic, seeing a child with fever and rash, needs to know: does this meet the case definition, what sample do I take, in what window, where does it go, who do I notify, and what do I do in the meantime. Those answers cannot depend on whether the signal is up.
Software that degrades gracefully offline is a nice engineering property. Software where being offline is the expected state is a different design, and most health tooling is not built that way. It is built for a demo room with reliable wifi, and then deployed somewhere else.
What “offline” actually costs you, and what it buys
The costs are real and I will not pretend otherwise.
You give up central telemetry — you do not know who used it or where. You give up instant updates; a corrected version has to be redistributed. You give up server-side validation, so the logic has to be conservative. You give up any feature that genuinely needs a live lookup.
What you buy is the only thing that mattered: it works at the moment of the decision.
A tool that is right 100% of the time and available 70% of the time is, at the bedside, a tool that is available 70% of the time. Availability is not a non-functional requirement in clinical work. It is the requirement.
The distribution problem nobody designs for
Here is the part that surprises people who have not deployed into a health system.
The hard problem was never rendering a decision tree. It was getting the current version into the hands of a worker whose phone is full, whose data plan is limited, who changes shift, and who may be in a clinic you cannot reach today.
A single file solves distribution, and distribution was the actual bottleneck. It travels through the channels that already exist — a message, a shared folder, a copy from one phone to another — instead of requiring a channel we would have had to build and maintain.
Any architecture that made distribution harder would have been worse, no matter how much cleaner it looked on a diagram.
What this taught me about building for health generally
Three things I now apply everywhere, including to work that has nothing to do with outbreaks.
Design for the worst environment you will actually be deployed in, not the average one. The average clinic has connectivity. The one where the case shows up at 9pm on a Sunday may not. Averages hide exactly the cases you built the tool for.
The person using it did not choose it. They were handed it, mid-shift, with no training window. If it needs explaining, it needs redesigning. Every field, every option, every default is a question you are asking someone who is busy and tired.
Version drift is a clinical risk. If two workers are following two versions of the same pathway, you have a safety problem, not a devops problem. Make the version visible on the screen, so anyone can tell at a glance which one they are holding.
The general point
The measles pathway is a small thing. It is not machine learning. There is no model in it.
But it is the clearest example I have of the principle the whole studio runs on: a method is only as good as the conditions it survives. A correct pathway that requires connectivity is, in the clinic that needs it most, not a correct pathway.
That is also why I still direct a health institution while building software. Not as a credential — as quality control. Every tool gets tested against a question I cannot avoid: would this actually survive here?
You do not get that instinct from a requirements document. You get it from having been the person who has to answer for the outcome.
The pathway is open source: github.com/iamstudio2026/sarampion. If you are building decision support for conditions like these, I would like to hear about it.