Using DHIS2 v2.28. We have a training (Event) program which has been requested to be used at National level pending the next meeting with the responsible officer in a few days. A feature/capability that was requested was for "Event Capture to allow searching by some data element from parent Org unit regardless of where the record was entered within the hierarchy. That’s to say, if a record was entered at a level 4 Org Unit, when I Select Level 2 where that Org unit belongs and do search, Ill be able to find that record and view or open it for edit.
This feature/capability sounds like it’s the solution to a more specific real-world ‘requirement’ - do you know what this underlying requirement might be (ie the reason why they want to be able to do these searches and edits)?
When planning training, they would want to ensure they invite new cadres every time and so before training starts, they will search for all the participants’ IDs in the database to ensure they have not received a similar training. Now because staff move from one Facility to the other, its difficult to trace them to one facility where there training details could have been captured hence the need to be able to search at parent Org Unit instead of trying at all the possible locations one after the other.
Hey,
When there is a unique ID or identifying attributes for an entity, we would often think about making a simple tracker program with a tracked entity instance representing a participant in the training. It sounds like in this case however, the participants details are stored as event data - did you also consider the simple tracker program approach?
Thank you Markus for the insight, this can be an option to consider . The overall idea would allow for each staff to have multiple unrelated events (by each type of training attended). Probably I can just change the same program to allow registration…
I agree with Markus that Tracker would be better than Event Capture for this use case. Even if you add trainee ID as a data element to your Event Capture program, there’s a lot of potential for error - eg accidentally mis-typing one character in the ID, or accidentally issuing the same trainee ID to two people.
If you use Tracker, it will enforce the uniqueness of trainee IDs, and you can capture basic information such as the name alongside the ID, which allows staff to confirm they’ve got the right person when doing data entry. If you configure things correctly, you can also make it impossible for staff to accidentally enrol the same person in a course twice (make the program ‘once per lifetime’ and each course a ‘non-repeatable’ program stage). In fact, if there’s a structured series of courses that need to be done in a particular order, you could configure this as a single Tracker program with program rules to hide more advanced courses until the trainee has completed any prerequisite courses. Finally, there’s the added bonus that staff can easily look up the training history for any particular user.
As you have probably already discovered, for a use case like this Tabular Tracker Capture will probably help to make bulk data-entry much easier, allowing staff to quickly enter all trainees/enrolments for a course at the same time. (Note, however, that many aspects of program rules won’t work with Tabular Tracker Capture.)
. The overall idea would allow for each staff to have multiple unrelated events (by each type of training attended). Probably I can just change the same program to allow registration…