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 <vgarcia...@gmail.com>: > > 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 <mar...@dhis2.org > <mailto:mar...@dhis2.org>> 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 <vgarcia...@gmail.com >> <mailto:vgarcia...@gmail.com>>: >> >> 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 <vgarcia...@gmail.com >> <mailto:vgarcia...@gmail.com>> 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@lists.launchpad.net >> <mailto:dhis2-devs@lists.launchpad.net> >> Unsubscribe : https://launchpad.net/~dhis2-devs >> <https://launchpad.net/~dhis2-devs> >> More help : https://help.launchpad.net/ListHelp >> <https://help.launchpad.net/ListHelp> > >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
