A DHIS2 loader passed sampled checks—then exhaustive verification found four defect classes

A new feasibility study of a multimodal diabetes registry offers a useful negative result for data-platform evaluation: successful imports, plausible counts and sampled checks did not prove that the load was correct. Only an exhaustive comparison against the source exposed the remaining failures.

The scale was large, but the metric was exact

The study mapped 2,280 AI-READI participants into an unmodified DHIS2 Tracker program with 27 stages, 445 distinct data elements and 8,089,500 events. Dense wearable, glucose and environmental readings were summarized by participant and UTC hour; ECGs, diagnoses and 118,480 retinal images remained record-level events.

That aggregation reduced wearable and glucose volume by about 26×, according to the paper. It was also a lossy systems choice rather than a clinical validation: activity segments were prorated across hours, structural OCT and fluorescence-lifetime imaging were not loaded, and the study did not test clinician use, live device feeds or analytics at the reported scale.

For correctness, the authors read the registry back and compared every stored field in all 20 non-core stages with a value recomputed from the source. The final run covered 64,850,380 values. All agreed within a tolerance of 0.01, with no unmatched registry event and no missing source hour or record. A separately written glucose pipeline checked 46,421 hours and all 464,210 values agreed; the only stated difference was the standard-deviation divisor.

Four failures hid behind apparently successful loading

The 100% final agreement came only after four repairs. Exhaustive verification found one duplicated ECG event, 2,229 retinal photographs without previews, 169,969 sleep events derived from source segments that were repeated verbatim or ended before they started, and 129,916 humidity hours whose flagged-time lists had not been stored.

None was a wrong numeric value. They were missing, duplicated or source-artifact records—the categories most likely to evade a spot check over values that exist. The paper says earlier sampled and count-only checks missed them.

The sleep case is especially consequential for downstream benchmarks: the repeated source segments would overstate summed sleep time by 43% if a consumer failed to remove them. The paper also notes that AI-READI’s own OMOP Data Quality Dashboard run failed 49 of 1,241 checks, underscoring that source validation and load validation are separate layers.

What this benchmark actually establishes

This is not evidence that DHIS2 is clinically ready for dense multimodal monitoring. The server used a pre-release build with default database settings, per-modality load times were not recorded, and the exported metadata package had not yet been imported into a clean instance.

What the study does establish is narrower and reusable: loader evaluation should report unmatched records in both directions, use deterministic client identifiers so retries are idempotent, inspect per-object response counts rather than top-level success, and independently recompute at least one aggregation path. A benchmark that scores only values returned by a successful import can report perfection while silently excluding the records that failed.