Hi, looking at previous posts in the community I got the impression that this feature was working partially in the past, but it does not work anymore. Moreover, in the docs for 2.40 the possibility to assign a value to a TEA has been removed:
But that feature, no longer documented, is available in DHIS2 Play 2.40.3:
So back to my initial question: can I update a TEA value from a Program Stage?
Hey there @msilva !
can I update a TEA value from a Program Stage?
If you mean whether you can open a program stage, change a value in that stage, and have this directly affect the TEA values - this is not possible. No assign rules will affect data outside of its own context - or seen from the user prespective, outside of the form you are working in.
If you make such a rule that assigns to a TEA value, the user would have to upen the profile widget before the assign rule is triggered.
It does seem like it would be useful to allow updating TEA even without opening the profile form - but this needs proper treatment as a feature request. We would for example have to have a way of handing if the rule wanted to update a TEA value to an illegal value. We would also have to make sure the user sees that an update is made out of their own context.
We do have a roadmap idea that also seems to play into this, and would possibly be of help: Log in with Atlassian account
This item describes functionality to re-run program rules outside the data entry context itself, and it does seem like an opportunity to discuss updating the TEA values as well - these rule re-runs could assign the value you wanted based on data in a program stage.
The screenshot above and in the documentation seems like a plain error in the docs that we should fix. The example shows a Tracker program, and therefore the TEAttrubutes should be possible to select in the assign dialog. It was not removed on purpose, and on @Karoline inspection, it seems the error has been there quite a while.
Hi Markus and thanks so much for the elaborated answer. I really appreciate that.
I think it would be useful to be able to schedule program rules which assign values to run, in the scheduler app. About the TEA updates, for us is more a workaround to overcome some of the limitations we are facing when managing overdue patients. We are using this TEA in a similar way as “mark for follow-up” feature. The idea is that our patients follow a workflow where they visit - a visit is scheduled - they become overdue - they receive a call - they come back and the whole process starts all over again.
We have found that Tracker does not support PIs which do cross events calculations (how many days on average it takes a patient overdue who was called to come back to care). We found that our working lists also need to filter on stuff which relates to various events (show me patients overdue - information available in the previous event - and who were called - information available in the current event)… So we thought about updating the patient status in a TEA as the patient goes through the workflow of visit, overdue, called… That actually work for us.
We also thought about having the visit PS and the call PS together in just one PS, but that does not work because all those things happen in different points in time and we would like to be able to enter multiple calls events which may happen before the patient comes for a next visit.
Thanks again for your support 
Hi all,
First of all, thanks for sharing this, because we are facing this issue in an implementation. I would like to share our use case (similar than one from @msilva), just for reference.
In our use case, there is a tracker program with a TEA for the “outcome”. This TEA is updated depending on the values captured in different the program stages, using different program rules.
In our case, the way for editing the TEIs is through the Android Capture app (@dhis2-android).
Well, so, I can confirm that this was working as expected in version 2.6.2, 2.7.1.1 of the Android capture app.
But in version 2.8.2, 2.9 and 2.9.1, the behaviour is the same than the one shared by @Markus (you need to edit the TEI details if you want the execution of the Program Rules that updates the TEA outcome).
Hi @Markus and @Karoline
I will explain here why we opted for using a TEA that we called Patient follow-up status to overcome the current DHIS2 limitations. This TEA is updated as the patient progresses through the workflow: patient visits (program stage visit), new visit is scheduled, patient becomes overdue, patient is called (program stage calling report) and eventually they return to care and the overdue event is reused to enter this new visit. The TEA is updated using triggers in the DB, and the possible values are illustrated here:
The first thing that I noticed, is that event status in programstageinstance table remains SCHEDULE even though the patient is overdue. This means that Capture shows overdue patients by looking at their latest event due date, but the event status is never updated in the backend, so it is not worth using this status in a PR to filter overdue patients. I also noticed that the Android app behaves differently and after syncing an overdue patient, in some cases the event status in the backend changed to OVERDUE.
The first thing this solution does is to solve this Jira ticket:
https://dhis2.atlassian.net/browse/DHIS2-16885
Since now the patient status is in a TEA, we can easily show the Program Stage “Calling report” for those patients whose TEA value is OVERDUE_PENDING_CALL. Here the difficulty was to have a PR showing a Program Stage based on an information which should be stored in a previous event entered for a different PS (event status is overdue).
Similarly, we faced the same problem with working lists. We can only filter by data in events for a specific Program Stage. But what if we want to show the patients that are overdue which have not been called? It is not possible because overdue status is on an event entered for PS Visit, whereas the calling information is in a different event for PS Calling report. Having the value in a TEA solves the problem.
And we also found this solution to work better for line listing.
To sum up, the capacity of doing cross events filtering (line list, working list) and conditions which affect a PS from data entered in a different PS was required for our use case and using a TEA is a good workaround. Unfortunately not been able to assign this value using PRs, we had to do these updates in the backend using triggers, which means the users are forced to sync their android devices to be able to see the latest info in their working list and to be able to access calling report stage.
