dhis2-devs team mailing list archive

[Markus Bekken <markus@xxxxxxxxx>]

Thank you for understanding. The primary focus going forward is to solve these usecases on the event aggregation / program indicator side. I would be happy to hear the other use cases you mentioned too.

Between the options below I hope you will be able to find a liveable solution.

Markus

> 23. mai 2017 kl. 12.18 skrev Victor Garcia <vgarciabnz@xxxxxxxxx>:
> 
> Hi Markus,
> 
> thanks for the response. We suspected that this behavior could be something non-expected, but we really relied on it because it allows us to analyse in a more flexible way.
> 
> For example, one of our use cases is to create a table combining two dataelements in different stages that are defined as optionSets. Let's say we have "Main symptom" at first stage and "Condition at exit" at closure. We need a table that displays the options in "Main symptom" as rows and the options in "Condition at exit" as columns. 
> 
> - Following the first approarch, it would be required to create a program indicator for each combination. We can create some of them (the most important), but the number of combinations could be very large. And it would not allow filtering by other dimensions like patient age or sex.
> 
> - The second approach will work in most of the cases. We could create a helper field in the last stage that copies the value of "Main symptom" and analyse in the last stage. But if somebody modifies the values in the first stage when the last stage has already been registered, the values in the last stage will remain outdated unless they open the last stage to trigger the program rules. It is not usual but could happen sometimes.
> 
> We have a few more use cases where it would be useful to do assignments to other stages. But we also know that this is a behaviour that was not initially thought.
> 
> Thanks,
> 
> Víctor
> 
> On 22 May 2017 at 21:43, Markus Bekken <markus@xxxxxxxxx <mailto:markus@xxxxxxxxx>> wrote:
> Hi Victor,
> Sorry for the delayed response. 
> 
> The ASSIGN rules is only intended to affect the data that the user sees(the active/current event). This usually means that you can create helper fields, but they rely on the basis for your calculations being in the same event, or in previously registered data. The behavior you describe in 2.25 was not planned, and can be seen as a bug. 
> 
> There is two alternative options that can be pursued:
> - Try creating a program indicator with analytics type "Enrollment"(introduced in 2.26). This will allow you to compare data from the latest event in each program stage across entire enrollments. Possibly this can take away the need for the helper fields.
> - Make a helper field in second program stage, and make an assign rule that assigns "the other way". You will be able to query data from all other program stages when calculating and assigning values to helper fields.
> 
> Best regards,
> Markus
> 
>> 22. mai 2017 kl. 16.32 skrev Victor Garcia <vgarciabnz@xxxxxxxxx <mailto:vgarciabnz@xxxxxxxxx>>:
>> 
>> Hi all,
>> 
>> does anyone have any insight about this issue? It is fundamental to understand the behaviour of ASSIGN program rules in order to design the programs.
>> 
>> Thanks,
>> 
>> Víctor
>> 
>> On 15 May 2017 at 17:26, Victor Garcia <vgarciabnz@xxxxxxxxx <mailto:vgarciabnz@xxxxxxxxx>> wrote:
>> Hi all,
>> 
>> I have a question regarding the behaviour of ASSIGN activity type in program rules when the program has several stages.
>> 
>> Our context is a program with three stages (opening, consultation, closure). In analysis we want to show data from opening and closure stages in the same table. Since currently it is not possible to do this kind of analysis in Event Report, we have created some ASSIGN program rules to copy values from closure stage to opening stage so that we have all the information we need for analysis in the same stage.
>> 
>> In 2.25 we saw that it was possible to assign values to previous stages and we created a setup relying on this behaviour. But it seems to have changed in 2.26 and now the ASSIGN action only affects the "active" stage and does not create any value in previous or following stages...
>> 
>> Since this point is not explicitely detailed in the documentation, we would like to know what is the expected "inter-stage" behaviour of ASSIGN in order to think about an strategy that will work in current and future releases. And if there is a way to do this kind of assignments in 2.26.
>> 
>> Thank you a lot,
>> 
>> Víctor
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs <https://launchpad.net/~dhis2-devs>
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx <mailto:dhis2-devs@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~dhis2-devs <https://launchpad.net/~dhis2-devs>
>> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
> 
>