Breaking Boundaries with DHIS2: Handling Plus-Minus (±) in Program Rules

Implementation - Implémentation
, ,
1

In 2024, I’ve been pushing the boundaries of DHIS2 to develop more complex and extensive programs. Recently, I encountered a challenge while configuring an Event Program that required a program rule to hide a specific data element based on a calculated condition.

The logic was simple:
:pushpin: If Element A - Element B = (±)5, then Data Element C should be filled.

However, DHIS2 doesn’t have a built-in function for recognizing the plus-minus (±) sign, making this a tricky problem to solve. Since any subtraction that results in a negative value can be reversed to become positive (e.g., 15 - 24 = -9 but 24 - 15 = +9), I needed to structure the rule logically to achieve the intended outcome.

:small_blue_diamond: The Solution:
Instead of relying on a ± function, I designed the following program rule formula:

:backhand_index_pointing_right: (#Element A - #Element B) > 5 && (#Element B - #Element A) > 5

This ensures that if DHIS2 calculates a negative value in the first expression, it will rerun the calculation in reverse, producing a positive integer, thereby maintaining the intended logic.

This approach worked, but I’m sure there are other ways to achieve the same result. If you have experience with similar DHIS2 program rules, I’d love to hear your insights! Let’s innovate together. :rocket:

1 Like
2

Hi @Mr_jorge

This is a smart way to handle such a challenge, and it’s great that you’re sharing with the community.

Have this workaround been working as expected for you?

I’m also curious about the use case where using the ± was needed if it’s possible to share?

Thanks!

3

Hi @Gassim

The program rule is functioning as expected. The primary data collection tool for this form is the Capture app. In some cases, program rules work on web-based data collection but not in the mobile app, so this rule was specifically designed with mobile functionality in mind. Currently, it operates correctly on both the web and mobile app.

This rule was necessary for an MMS program that required tracking bottle weight. Due to a margin of error of ±3 in the bottle weight machine’s pill count, the team wanted data collectors to provide a comment explaining any discrepancies in usage. The comment data element is only required when this condition is met.