Why the Hardest Software Problem Is Actually a Measurement Problem

The hidden question behind both hospitals and obesity prevention

What do a hospital EHR and a childhood obesity prevention program have in common? At first glance, almost nothing. One is a sprawling clinical software platform that can cost hundreds of millions and still frustrate doctors. The other is a public health intervention problem, where researchers try to figure out which programs actually reduce overweight and obesity in children. But both are wrestling with the same brutal question:

How do you know that you are helping, when the thing you are trying to help is changing inside a messy, human, regulated system?

That is the real challenge. Not building forms. Not storing data. Not even choosing the right database. The deeper problem is that both medicine and public health live in a world where outcomes are mediated by context, uncertainty, time, and interpretation. You do not just need software or interventions. You need a way to turn reality into something that can be measured, compared, acted on, and trusted.

And that is far harder than it sounds.

The most expensive failure mode in healthcare is not lack of information. It is false certainty about information that was badly captured.

This is why so many health systems end up feeling dysfunctional. They are often optimized for billing, reporting, or compliance, not for the actual structure of clinical reality. And this is why well intentioned interventions can look promising in one setting and fail in another. Both domains are haunted by the same illusion: that once you collect data, you have understood the problem.

You have not. You have only begun.

---

Why healthcare breaks software, and why software breaks healthcare

If you try to build an EHR as if it were a normal software product, you will fail. Not because healthcare is mysterious in some romantic way, but because it is ontologically inconvenient. A patient is not just a record. A diagnosis is not just a label. A medication order is not just a transaction. Each one is wrapped in uncertainty, time dependence, causality, exceptions, and human judgment.

A blood glucose value is not merely a number. It may be capillary or venous, fasting or non fasting, calibrated or not, part of a panel or a point of care test, measured in one unit system or another, and meaningful only relative to the question being asked. In other words, the data point is never just the data point. It is a measurement event embedded in a clinical story.

This is where many systems go wrong. They treat complexity as if it were a nuisance to be filed away. Yet complexity is not incidental. It is the structure of the domain.

The same is true in intervention research. Asking whether a childhood obesity prevention program works is easy only at the level of slogans. The real questions are harder: Which children? Which setting? Which measures? Which combination of activities? What barriers prevented implementation? What happened when the program was transplanted into a different school, neighborhood, or health system? Once again, the outcome is inseparable from context.

That is the shared lesson: health is not a static object you can store. It is a process you must model.

An EHR that cannot represent uncertainty, causality, severity, time, and changing identity will mislead clinicians. A prevention strategy that cannot specify population, setting, measurement, and implementation conditions will mislead policymakers. Both systems may generate impressive dashboards. Both may even produce statistically valid reports. But if the underlying model is too shallow, the surface polish becomes a liability.

A beautiful interface sitting on top of a broken model is not progress. It is decoration.

---

The measurement trap: when counting replaces understanding

The deepest connection between EHR design and obesity prevention is that both can fall into the same measurement trap: what gets measured starts to define what is considered real.

In an EHR, if your system is built around billing, then billing becomes the gravitational center of clinical reality. If your coding system handles diagnoses but not uncertainty, clinicians are pushed into premature certainty. If your record structure cannot capture the difference between a suspected condition and a confirmed one, you create a false world of completed facts. The software does not merely record medicine. It subtly edits it.

In obesity prevention, something similar happens when success is reduced to a narrow metric such as BMI change at a single time point. BMI matters, of course, but it is not the whole story. Programs may influence diet quality, physical activity, sleep, self regulation, family routines, school environment, or access to safe places to play. If the evaluation framework ignores these intermediate changes, effective programs can look ineffective, and ineffective programs can look harmless.

This is the hidden cost of over simplified metrics: they reward only what is easy to count.

The result is a systems level version of Goodhart’s law. When a measure becomes a target, it stops being a good measure. In hospitals, this can lead to checkbox medicine and defensive documentation. In public health, it can lead to intervention theater, where activity is mistaken for impact. People optimize to satisfy the metric, not the underlying mission.

Consider a simple analogy. Suppose you tried to manage a city by counting only the number of traffic lights. You might conclude that more traffic lights equals better transportation. But the real question is flow, safety, accessibility, and reliability. The count is not the system. It is merely a proxy. Healthcare is full of proxies that have quietly become idols.

The answer is not to abandon measurement. It is to measure more honestly. That means representing uncertainty, partial progress, and implementation conditions, not just final outcomes. It means treating the data model as a theory of reality, not a filing cabinet.

If your system cannot represent ambiguity, it will manufacture certainty where none exists.

---

A better mental model: medicine as layered evidence, not isolated facts

One way to unify these problems is to think in terms of layered evidence.

At the lowest layer, there are observations: a weight reading, a lab value, a school attendance report, a blood pressure measurement. These are not truths in themselves. They are measurement events with conditions attached.

The next layer is interpretation: what does the observation mean in context? Is the child overweight according to the chosen standard? Is the glucose elevated in a way that suggests diabetes? Is the intervention feasible in this school? These are judgment calls, often probabilistic.

The next layer is causality: what likely produced the observation? Was the hypertension caused by obesity, steroids, stress, renal disease, or something else? Did the school nutrition program actually reduce energy intake, or did families change behavior for unrelated reasons? Here the system must support hypotheses, not just conclusions.

The top layer is action: what should be done next? Recheck the measurement? Start treatment? Change the care pathway? Modify the intervention? Each action depends on the strength and quality of the evidence below it.

This layered model exposes why both EHRs and intervention studies fail when they collapse everything into a single categorical field. A diagnosis code alone cannot carry the weight of uncertainty, cause, severity, and timing. Likewise, a binary outcome cannot tell you whether a program worked because it changed behavior, improved adherence, or simply selected easier participants.

If you want systems that learn, you need structures that preserve the path from observation to interpretation to action.

A practical way to think about this is to ask four questions every time data is captured or an intervention is designed:

1. What exactly was observed?
2. What does it mean, and how certain are we?
3. What might have caused it?
4. What decision will this support?

That framework is powerful because it prevents the most common error in healthcare analytics: confusing recorded data with epistemic certainty.

---

Implementation is not a side issue. It is the intervention.

The obesity literature highlights a point that health software often forgets: effectiveness depends on implementation. It is not enough to ask whether a program works in theory. You have to ask whether it works in a particular setting, with particular people, under particular constraints, and alongside other interventions.

The same is true for EHRs. A system can be technically sound and still fail because it does not fit clinical workflow, does not respect user cognition, or creates too much burden at the point of care. The physician sees thirty seconds of software. The architect sees a schema. The organization sees cost savings. But the patient experiences the whole chain.

This is why many EHR projects fail in slow motion. They are not defeated by one catastrophic bug. They are defeated by cumulative friction. Every extra click, every ambiguous field, every missing code, every brittle workflow, every awkward search result becomes a tax on clinical attention. Over time, that tax is paid in errors, burnout, and workarounds.

Public health interventions suffer a similar fate. A program may look elegant in a protocol and still collapse in practice because teachers are overloaded, parents are unavailable, measurements are inconsistent, or the school environment makes healthy behavior impossible. The problem is not only whether the intervention is efficacious. It is whether the system can carry it.

This suggests a useful distinction:

Efficacy is about whether something can work. Implementability is about whether it can survive contact with reality.

In healthcare software, implementability is not a deployment detail. It is the product. In public health, implementation barriers are not extraneous noise. They are part of the causal pathway.

That means the design of the system and the design of the measurement framework should be developed together. If you do not know how an intervention will be delivered, you cannot know how to evaluate it. If you do not know how data is captured, you cannot know what the data means.

---

What good systems actually optimize

The fantasy behind many EHRs is that better software means more features. The fantasy behind many intervention programs is that better evidence means clearer answers. In reality, the most valuable systems optimize for something more humble and more difficult: epistemic fidelity.

Epistemic fidelity means the system preserves the relationship between reality and representation without distorting it too much. It asks whether the software, code system, or evaluation framework is telling the truth in a way that remains usable.

A high fidelity system does not need to be simple. It needs to be honest. It should be able to say, for example:

• this diagnosis is suspected, not confirmed,
• this measurement was taken under these conditions,
• this causal link is a hypothesis, not a fact,
• this outcome improved in one subgroup but not another,
• this intervention succeeded only when paired with family support and a school lunch change,
• this dataset cannot support a claim stronger than its collection methods allow.

That kind of system is less glamorous than a slick dashboard. But it is far more useful.

There is a profound strategic lesson here. The best systems are not those that pretend away complexity. They are those that make complexity navigable. They do not eliminate ambiguity. They encode it. They do not force premature closure. They preserve degrees of belief. They do not treat context as a nuisance. They model it as part of the mechanism.

If that sounds expensive, it is. But the alternative is usually more expensive later, when the system becomes too brittle to trust.

---

Key Takeaways

1. Treat health data as evidence, not just records. Capture uncertainty, context, timing, and measurement conditions, not only final labels.

2. Design for implementation from the beginning. A system or intervention that cannot survive workflow, staffing, and local constraints will fail in practice even if it looks good on paper.

3. Measure what matters, not only what is easy. Avoid letting billing, compliance, or a single outcome metric define the whole problem.

4. Preserve causality as a hypothesis. Support links such as “because of,” “possibly caused by,” and “associated with,” rather than collapsing everything into static categories.

5. Ask four questions before trusting any health metric: What was observed, what does it mean, what may have caused it, and what action will it support?

---

The real lesson: healthcare is a theory of reality problem

The temptation in both software and public health is to think the main challenge is execution. Build the system. Run the trial. Train the users. Ship the product. But the deeper challenge is more philosophical and more practical at the same time: what kind of world are you assuming when you store, code, and evaluate human health?

If your model assumes neat categories, stable causes, and universally comparable outcomes, it will break. If your model assumes complexity, ambiguity, and implementation variance, it may be harder to build, but it will be closer to reality.

That is why the best EHR is not the one with the prettiest interface or the biggest feature list. It is the one that can represent medicine as it actually happens: uncertain, temporal, contextual, and collaborative. And that is why the best obesity prevention evidence is not the one with the boldest headline effect. It is the one that can explain who benefited, where, how, under what conditions, and at what cost.

In the end, both problems ask the same thing of us: stop mistaking simplification for understanding.

The systems that endure are not the ones that flatten reality. They are the ones that learn how to hold its complexity without lying about it.