I would like to raise a question about the expected behaviour of working lists in the Capture app.
We are seeing a different navigation behaviour depending on the type of working list used:
Tracked entity / enrollment working lists
When the working list filters only on program attributes, clicking on a patient takes the user to the patient dashboard / enrollment dashboard. This is the behaviour we expect.
Program stage working lists
When the working list filters on program stage data, clicking on a patient takes the user directly to the event / visit form.
Can anyone clarify whether this difference is intended?
In our PHC workflow, this creates an issue. Program stage working lists are very useful to identify patients requiring a specific type of follow-up or visit, but users should first land on the enrollment dashboard to review the patient context before starting or opening the visit form. Going directly into the visit form disrupts the workflow because the health worker may need to check previous visits, patient summary information, other program data, or decide whether a new visit should actually be started.
Is there any configuration option to control where the user lands after clicking a row in a program stage working list?
You’re saying that they ‘may’ need to go back to the enrollment dashboard (or are they always expected to land in the enrollment dashboard)? If it’s sometimes (not always) then they have the option to click back and return to the enrollment dashboard.
If they’re always expected to land on the enrollment dashboard, have you experimented with the filters when using the enrollment working list? If they don’t need to filter using program stage data elements then maybe using a TEI/enrollment working list could be the solution?
Otherwise, this is a feature request: “Ability to control the landing page from working list.” You’re welcome to create a feature request idea and link it here please. (See ideas!)
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.
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.
