AI in global health is only as good as the routine health data underneath it, and that data is fragmented, incomplete and frequently locked in silos. This playbook assesses data readiness for LMIC health systems: the reality of paper registers and parallel donor systems, DHIS2 as the aggregate data backbone, connectivity gaps that break real-time pipelines, data sovereignty constraints, and the lineage and quality controls needed before any model is trusted. It gives ministries and NGOs a practical path from fragmented reporting to an AI-ready data foundation a model can stand on.
Fragmented data is the real bottleneck
The binding constraint on AI in global health is rarely the model. It is the data underneath it. Routine health information in many LMICs still originates on paper registers, is aggregated monthly by hand, and flows through multiple parallel donor-funded systems that were never designed to reconcile with one another. DHIS2, the open-source platform maintained by the University of Oslo, is now used in more than 80 countries as the national aggregate reporting backbone, which is a genuine strategic asset. But DHIS2 mostly holds aggregate counts, not the patient-level, timestamped, well-labeled records that most clinical AI actually needs to learn from and predict on, and bridging that gap is often the largest single piece of work in a program.
Connectivity widens the gap further. The ITU estimates roughly a third of the world remains offline, and that third is concentrated in the rural areas health systems most need to reach. Real-time pipelines break where power and bandwidth are intermittent, and a model that assumes a live feed will simply stop working at the periphery. Layered on top are data sovereignty rules that constrain where records can be stored and processed, sometimes prohibiting the cloud arrangement a vendor assumes by default. Before funding a model, funders and ministries should fund an honest data readiness assessment, because a model trained on inconsistent, poorly documented data will pass a lab test and then fail quietly and expensively in the field. The uncomfortable truth for many programs is that the highest-return investment is not a better algorithm at all but the unglamorous work of digitizing capture, reconciling feeds, and documenting where each number comes from.
A five-layer data readiness assessment
Rate each layer red, amber, or green. Any red layer blocks the AI that depends on it until it is remediated, regardless of how strong the model looks in a controlled evaluation. This keeps money out of tools the data cannot yet support. Score each layer with the people who actually enter and use the data, not only with central IT, because the gap between the official system and what happens at a busy rural facility is usually where readiness quietly breaks down.
| Layer | Readiness question | Green signal |
|---|---|---|
| Capture | Is data born digital and standardized at the point of care? | Structured digital capture with validation, minimal paper re-entry |
| Aggregation | Do feeds consolidate into DHIS2 or an equivalent backbone? | Reconciled feeds with few parallel unlinked systems |
| Connectivity | Can data move reliably from facility to national level? | Store-and-forward sync that tolerates power and network outages |
| Sovereignty | Is storage and processing location compliant and controlled? | In-country or on-device options with clear data agreements |
| Lineage and quality | Can every field be traced to source with quality flags? | Documented lineage plus completeness and consistency metrics |
Build the foundation before the model
- Run a full data readiness assessment across capture, aggregation, connectivity, sovereignty, and lineage before committing budget to any AI build.
- Standardize on DHIS2 or the national backbone as the integration point, and steadily reduce the parallel donor systems that fragment reporting and duplicate effort.
- Invest in digital capture at the point of care so data is born structured, cutting the transcription errors introduced by monthly paper re-entry.
- Design pipelines for intermittent connectivity with store-and-forward synchronization rather than assuming a real-time link that the periphery cannot sustain.
- Track data lineage end to end so every field a model consumes can be traced to its source, quality-flagged, and explained when the model drifts.
Data mistakes that sink AI programs
- Funding the model before the data foundation, then discovering the training data is too sparse or inconsistent to trust for any real decision.
- Treating DHIS2 aggregate counts as if they were patient-level records suitable for individual clinical prediction.
- Building real-time pipelines that collapse the moment rural connectivity or power drops, which is exactly where they are needed most.
- Ignoring lineage, so no one can explain where a training value came from, why quality varies by site, or why a model quietly drifted.
Quantify readiness, not just volume
- Data completeness and timeliness rates for the specific facilities feeding the model.
- Share of records born digital versus re-entered from paper registers.
- Percentage of data feeds reconciled into the national backbone versus left siloed.
- Proportion of model input fields with documented lineage back to source.
Frequently asked questions
What is DHIS2 and why does it matter for AI?
DHIS2 is an open-source health information platform, maintained by the University of Oslo and used in more than 80 countries, that serves as the national aggregate reporting backbone. It matters because it is often the most complete data asset a country has, but it mainly holds aggregate counts, so most clinical AI still needs additional patient-level, timestamped data before it can be trusted for individual decisions.
Why is fragmented data such a barrier?
Routine health data often starts on paper, is aggregated monthly, and flows through several parallel donor systems that never reconcile. A model trained on this inconsistent, poorly labeled data will look fine in a lab and fail quietly in the field. Fixing capture, aggregation, and lineage usually delivers more real improvement than a better algorithm does.
How do you handle data readiness with poor connectivity?
Design for intermittence rather than fighting it. Use store-and-forward synchronization so data captured offline uploads when a link returns, and support on-device processing where sovereignty or bandwidth demands it. Assess connectivity as its own readiness layer, because a pipeline that assumes a real-time link will break at the rural sites that need it most.
Related reading
Go deeper on this sector and topic.