Hi Gassim, thanks for your answer.
This is an overdue working list, and while the overdue status is technically tied to the program stage, I believe the core issue is that the patient is who becomes overdue when a scheduled event is missed. Ideally, this status would live as a TEA or be directly linked to the enrollment—which, as you pointed out, solves the core issue.
I shared some thoughts on this a while back here: Can we assign a value multiple times to a TEA from a Program Stage? - #5 by msilva
Because program rules within an event are limited to the scope of that event, we can’t easily assign a value to a TEA from there. Furthermore, “overdue” is a status that happens automatically over time without user interaction. To get around this, we are currently running custom SQL scripts to push this valuable information into the program attribute where I think it belongs.
It’s tough to see that two years later, overdue management in DHIS2 still requires these kinds of workarounds. Diverting the user flow depending on the type of working list adds significant friction to this process.
For comparison, in systems like OpenMRS, the landing page for a patient is always the comprehensive patient dashboard. Forcing a user straight into a data entry form when accessing an overdue list is counterintuitive for us—the patient is very likely not to be there physically, and the user is usually just inspecting the record to find contact information or assess the urgency of reaching out and bringing the patient back to care.
I hope the product team can reconsider this flow for future updates, as a dedicated dashboard view would drastically improve tracking workflows.