← Back to team overview

dhis2-devs team mailing list archive

Re: Expected "inter-stage" behaviour of ASSIGN program rule action

 

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> 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>:
>
> 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> 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
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>
>

Follow ups

References