d2:zScoreWFH & d2:zScoreWFA: differences across DHIS2 versions and WHO Anthros

Hello team,

While validating our nutrition program rules after upgrading from DHIS2 2.40 to 2.42, we found differences in the results of d2:zScoreWFH.

We reproduced these using the same minimal event program on the UiO demo instances for 2.40, 2.41 and 2.42. See program Metadata dependency here:
Test_Nut_Program.json (16.3 KB).

We ran 16 comparisons (6 WAZ and 10 WHZ), all for an event date of 1 July 2026.
Testing_Nut.xlsx (11.0 KB)

DHIS2 2.40 and 2.41 produce identical results in all ten WHZ tests, whereas 2.42 differs in every case. For example, for a male child born on 10 September 2023, measured on 1 July 2026 at 11 kg:

Height DHIS 2.40/2.41 DHIS 2.42 WHO Anthro
94 cm -2.96 -2.77 -2.96
94.5 cm -3.5 -2.88 -3.06

Across the ten tests, 2.42 is farther from Anthro in eight cases and closer in two.

Could you confirm whether an intentional change to the calculation or reference tables explains these differences, or whether this is a regression?

We used the Anthro tool available here: WHO Anthro Survey Analyser and other tools

WAZ differences from WHO Anthro

WAZ results are almost unchanged across the three DHIS2 versions, but differ substantially from WHO Anthro. All six DHIS2 results are less negative, with differences ranging from 0.15 to 0.82 z-score units.

For example, for a male child born on 4 March 2026, measured on 1 July 2026 at 4.5 kg, all three DHIS2 versions return −2.83, compared with −3.65 in Anthro. This crosses the −3 threshold for severe underweight.

For WAZ, we use d2:monthsBetween(DoB, Event date) as the age argument. Could completed-month age in DHIS2 versus exact age in days in Anthro explain these differences? Does d2:zScoreWFA support fractional months, and what is the recommended approach for obtaining results consistent with WHO Anthro?

We are aware of the 2022 report involving errors in both WAZ and WHZ functions, and the discussion of the intentional ±3.5 cap. However, several discrepancies here occur within that range. Could you clarify whether any known issue or limitation explains these observations, and whether a relevant fix is available or planned?

Thank you for reviewing these results.

Kathy Buelens

Hi @KathyBuelens,

Thanks for raising this. This is likely due to 2.42 using a different rule engine in Capture (Where I am assuming you are seeing these differences?) than 2.40/2.41. We will have a review on how these functions are used in that rule engine and get back to you very soon.

Thanks,
Karoline
DHIS2 Product Manager

Hello Karoline,

Indeed, the Capture app is where we are seeing the differences. I didn’t test on Android Capture app but since rule engines are supposed to be aligned now I guess we would have the same issue or worse sync issue because of conflicting values…

Thanks for looking into it!

Kathy Buelens