DHIS2 Capture App (Program rules issue)

Implementation - Implémentation Mobile
,
1

Hi guys,
We have recently implemented 2 trackers for our organization. We’re currently piloting the solution and expecting it to go to production in the coming days.
Everything works great but unfortunately the Program rules does not work on the mobile application - Dhis2 capture.
For the web interface everything works fine. What could be the issue?
We’re currently on Dhis2 version 2.36.11.1 and Dhis2 cature version 2.8.2

2

Hi @salad_guyo

Please review the documentation for the list of expressions in the program rules that are supported by the app and some which are not yet implemented: Program rules supported - DHIS2 Documentation

You could list which program rules that aren’t working and we can discuss if there’s a workaround as well as whether the issue is because an expression is not yet implemented or if there’s another issue.

Thank you!

2 Likes
3

@salad_guyo We’re looking at moving to 2.8.2, would very much like to hear the programRules that you’re having issues with!

2 Likes
4

The last time we had a similar issue it was cause by what is mention here in the manual Gassim shared above:

DHIS2 web version considers the type boolean as 0 or 1 (which can be evaluated to true or false), however Android evaluates them only as true or false. While this makes possible the addition of booleans in web, it will fail in Android; in order to fix this an additional program rule variable is needed to transform the boolean into an number that can be operated. Check the table below for examples and possible solutions.

For the examples belows consider the following:

yn_prv1: is a program rule variable that has been configured to get the value of a 'Yes/No' data element
yn_prv2: is a program rule variable that has been configured to get the value of a 'Yes/No' data element
prv_boolean_one: is a program rule variable that has been configured to get the value of a 'Yes/No' data element
prv_boolean_two: is a program rule variable that has been configured to get the value of a 'Yes/No' data element
prv_boolean_one_to_number: is a program rule variable with calculated value
prv_boolean_two_to_number: is a program rule variable with calculated value
sometimes true is used as program rule condition meaning the action is always performed
The following acronyms are used:
DE (Data Elemetn)
PR (Program Rule)
PRE (Program Rule Expression)
PRC (Program Rule Condition)
PRV (Program Rule Variable)
PRA (Program Rule Action) ```

You might want to start from there.
1 Like
5

Thanks @Gassim for the pointer to the documentation, I have perused through briefly but will read in details at first chance. As for the failing rules;
We have a DE say cmt: vl_outcome with optionsets having either Suppressed or Unsuppressed.
We have a second DE cmt: action plan which is hidden whenever the value for cmt: vl_outcome is Suppressed
Here is the program rule for achieving this for the web interface:
Condition: d2:hasValue(#{CMT_ViralLoad_Outcome}) && (#{CMT_ViralLoad_Outcome}) == "Suppressed"
Action: Hide field: "CMT: Action plan"

… @Matthew_Boddie and @WaluQ

6

I believe the correct expression should be Condition: d2:hasValue(#{CMT_ViralLoad_Outcome}) && (#{CMT_ViralLoad_Outcome}) == 'Suppressed'

7

@salad_guyo sometimes the function d2:hasValue works better if you put variable name into quotes, in your case better to put as:
d2:hasValue(‘CMT_ViralLoad_Outcome’) && #{CMT_ViralLoad_Outcome} == “Suppressed”

Also I found an error on your condition:
d2:hasValue(#{CMT_ViralLoad_Outcome}) && (#{CMT_ViralLoad_Outcome}) == “Suppressed”
here you have put (#{CMT_ViralLoad_Outcome}) itself into condition and not comparing it with the value. Also I would suggest again to check if you ticket ‘USE CODE FOR OPTIONS SET’ for program rule variable.

Regards,
Ulanbek

3 Likes
8

Thanks @Ulanbek for the suggestion on checking USE CODE FOR OPTIONS SET, it really helps since the option ensures to use option code as a value - which is not open to random changes.
As for the logic, I think it’s just ok. We’re chaining the condition to ensure that first we have a value for the variable using d2:hasValue function AND that the value MUST be equal to “Suppressed”

9

The “problem” was making the data element compulsory under:
Program >> Program stages >> Assign data elements (check compulsory DE.)

Here is the solution that worked:
i) For a field that expects boolean value
We left it as compulsory but assigned a default value e.g false. The hide condition still does’t apply but the field is blurred out and filled with the set value.

ii) For a field that expects an option from option set
We had to uncheck compulsory coz setting default value and hiding the field did not work - tried using both code as value and option name(when USE CODE FOR OPTIONS SET is off) non worked.
If compulsory is left checked, the hide logic does not apply.

2 Likes
10

Hi @salad_guyo

yes hiding a compulsory data element doesnt sound like a good idea and is not supported in the app (the server could complain if we send an empty mandatory field depending on the configuration).

If is not too late to make suggestions, what we recommend in that case is to make it mandatory with a program rule once you know it is not going to be hidden.

2 Likes
11

Thanks @marta, that makes sense.

2 Likes
12

Hi there,

I just want to add-up to what said @marta above:
hiding elements most of time can just wipe out the values which was stored before. Therefore much better to take precautions before to hide or make something compulsory.

Good luck

2 Likes