Public Health Data Systems: Why Ministries and Health NGOs Keep Making Decisions on Data That Is Already Stale

A regional health ministry, working alongside an international health NGO, was allocating emergency medical supplies based on facility stock reports submitted monthly, by paper form, then re-keyed into a spreadsheet at the district office, then rolled up to the regional office two to three weeks later. By the time a stockout was visible at the regional level, the facility had usually been out of essential supplies for three to four weeks already. The data was accurate. It was also structurally too old to be useful for the decision it was meant to inform.

This is the defining problem in public health data systems across the ministries and health-focused NGOs we have engaged with: the data collection process is built around administrative reporting cycles, not around the speed at which health decisions actually need to be made. A monthly report is fine for annual planning. It is close to useless for stockout response, outbreak detection, or supply chain reallocation — and those are exactly the decisions the data is supposed to support.

The instinct in public health, understandably, is to collect more indicators — more granular facility data, more demographic breakdowns, more program-specific fields layered onto an already long form. We have audited data collection tools with over 150 fields per facility visit, of which fewer than half were ever pulled into a single report or decision. Every additional field is additional friction for an already overworked health worker to fill in accurately, and it does nothing to fix the underlying problem: the data still moves through the system too slowly to be actionable.

The health ministries and NGOs that get this right build a data architecture around decision speed, not just data completeness. That typically means three things working together. First, a minimal, decision-linked data set collected at the facility level — fewer fields, each one directly tied to a resourcing or clinical decision. Second, digital collection at the point of care or point of stock check, feeding a central system directly rather than through a paper-to-spreadsheet-to-database relay that adds weeks of latency by design. Third, a dashboard layer built for the specific cadence each decision requires — daily for stockouts and outbreak signals, weekly for program performance, monthly for planning — rather than one generic report trying to serve every audience at once.

1. 1Define the decisions first — stockout response, outbreak escalation, program reallocation — before defining a single data field.
2. 2Cut every field not directly tied to one of those decisions, even if it is "nice to know."
3. 3Move collection to the point of care wherever field connectivity allows, and build an offline-first fallback for where it does not.
4. 4Build alerting, not just reporting — a system that flags a facility falling below a stock threshold is worth more than a dashboard someone has to remember to check.

Health data systems are notorious for fragmentation — a facility often reports the same information separately to a national health information system, a donor-specific tracker, and an NGO's own case management tool, because no one built the integration layer to let one data entry event satisfy all three. Fixing this is unglamorous, integration-heavy work, and it is almost always more valuable than any new dashboard: every hour a health worker spends re-entering the same data into a second system is an hour not spent on care, and every re-entry point is another place the numbers can quietly diverge.

Pick the single decision your organization makes most often under time pressure — stockout response is usually the clearest example — and trace exactly how long it currently takes for facility-level data to reach the person who makes that call. That lag is your baseline, and closing it is a far more valuable first engagement than a ministry-wide data platform overhaul.