Hi Team! I’ve been circling around this one for quite some time, and thought I better ask as I’m still hitting a wall.
I’m trying to track a set of structures within an overall compound, all within a tracker program. The Tracked Entity in this case is a compound consisting of 5-20 structures. We need to and record each structure, but also be able to go back to a structure and carry out an activity if it was not completed the first time.
When we first ran this campaign, we had a simple program stage did not limit entry. The problem was, though the compound was set to unique, we could not set individual structures as unique and thus had a small percentage of duplicate cases (which took an inordinately large amount of time to fix).
I am trying to propose changes this year that would better allow for tracking to take place. What I would like to do is something like this:
Have 1 stage for “first visit” of structures within the compound
Have 2nd stage for “Follow-up” of structures
Have 3rd stage be “final status” of structures
For this to work, I need to be able to:
Limit an option once an option has been used within a program stage
a. I.e. they enter a compound, and in the “first visit” stage enter “01” as the structure they are in. In future events, I would like to remove “01” as an option in the selection, or error out if 01 is appearing more than once
Show only options within the “follow-up” program stage in which the activity was not carried out
a. I.e. They enter “No” on a data element, and I take the corresponding option as available to the “Follow-up” program stage. (or, the negation—hiding all options unless they meet the criteria)
I worked through this using Program Rule Variables and trying to assign countIfValue() to a PRV, however not getting it to work in android. Also tried assigning “1” as the value based on a condition, but that didn’t seem to sum the counts.
I am open, ultimately, to any advice on getting option set DEs to be able to be “counted” in a tracker program within Android. If I can get that to be functional, I imagine I can figure out a way to make this work. Thanks!
Did you try to play with previous vs current value as source type for your PRV?
I remember a time where calculated values weren’t working for me and that I used to play with previous vs current values of DEs to push data from a stage to an other. I was either using a PR directly on those PRV or, depending on what was required, pushing data in “hidden” DEs from a stage to an other (previous only consider the very previous one, so if you need to dig further in time, you need to copy data from one stage to the next).
The only issue I was facing then is that for events occurring the same day, DHIS2 isn’t able to distinguish which event is first, messing up with the PR.
This is very DIY though and can multiply the amount of PR exponentially. I assume there are cleaner ways
This is pretty similar to the way I’ve done it. Say you have a structure list like this:
Structure 1
Structure 2
Structure 3
I would create a program stage section titled “hidden section”, and have a Yes only DE for each structure, labelled something like:
Structure 1 already selected in previous event.
Then, for each structure you create a program rule that checks the box if either of these two conditions are true:
Structure in previous event = Structure 1 || Structure 1 already selected in previous event == true in previous event.
This gives you a little section at the bottom in each event that will tell you previous status from all other events. I usually hide the entire section for non super users (again, with a program rule).
Finally, you will have to create another program rule to hide option values if they’ve already been used in previous events.
@Thomas_Warichet appreciate your thoughts. Yes I was curious about some of the interplays of event from programStage/event from program, and tried some iteration. That said----I think I was (stupidly) considering “previous” to come from created date, not event date. I might have another look at that in case that helps me out.
@kstankevitz Thanks for this! Makes a lot of sense. I think this might be a good solution for me. Going to kick it around now. Will report back! Out of curiosity, do you have any distinct experiences with things of this nature for android/browser? I’m also assuming that with this approach, we don’t have to dive into priority of program rules, which is nice to leave out that nuance.
Update: @kstankevitz actually I read this too quickly, I thought you meant program stage called hidden, not a program stage section. Surprised that hiding the section doesn’t remove values. I also do wonder if I’ll be able to get this to work with the PRV and previous values. Good to know this has worked for you. Can you confirm this works for you on both Android and Browser?
We do use this on Android. We’re on v2.9.1.1 and its working fine. You do need to use priority, as the check boxes need to be evaluated before the options are hidden. In this case I give all the PRs that check the boxes in the hidden section a priority of 1, and the PRs that hide the options a priority of 2. Works fine.
Yes, hiding a program stage section is a work around for not removing the values when a DE becomes hidden.
I have a slightly different use case - we use the hidden Yes only DEs in Program Indicators, so its important for my use case to store them as DEs, but in theory this approach should work with PRVs too.
Awesome. Trying this out now and already getting much further than I’ve been able to in the past. Good point about PRV==DEs in terms of program functionality, could be a cleaner (if spookier) solution for me once I get it all tightened up. This is very helpful, thank you so much!
