Multiple Level Tracker Tracker program: 1 Enrollment leading to mutiple enrollments

Implementation - Implémentation
1

Hi All,

We are embarking on a new tracker program, and at its architectural level had some questions/would love some recommendations if possible.

We are looking to track activities at individual structures, which fall into larger compounds within a country. There is an initial activity where compounds are enumerated, and the number of structures within are discovered. Secondary and more iterative activities are visiting those structures and listing out the activities that are complete.

An example would be that someone goes to a compound, and finds it has 8 structures. An ID is given to that compound (and left at the location). Later, a different person comes and wants to list the activities that happen at some/all of those structures. Later, people may follow-up on specific structures where activities were not possible the first visit.

Thus we have enumeration happening at a compound, but the structures within are the ones being individually tracked. Ideally we’d only be enumerating once per compound (saving time/energy for the process of enumeration, and limiting the total number of TrackedEntityInstances) but giving the ability for tracking each structure within.

So far we can consider having multiple program stages, where 1 program stage = a structure, would be possible. It feels a bit clunky, and seems less than ideal that these 20 or so program stages would be identical to one other (not to mention maintenance of the 20 programStages to be kept identical during any development). We can also consider simply making the enumerator enroll structures, not compounds, however they we lose at least some analytics (how many structures within compounds, other compound-relevant analytics) and greatly increase the number of TEIs to sort through.

Anything we should be thinking about? Relationships, multiple enrollments per TEI, some kind of automatic TEI generation, multiple programs…? Appreciate anyone’s insights.

1 Like
2

Hi Matthew,

It seems like you need to have 2 different tracker programs related to each other. So, there would be one Tracker for the Structure and another for Compounds. First, you enroll the Structure and create 8 relationships (in the case with your example) and attach them to that particular Tracker Enrollment, meaning if you find 8 compounds you just generate empty enrollments and attach them to that Tracker with some identifier and the next person would see this identifier and update the compounds. There is a new feature on the development list for DHIS2, which would give the ability to do an analysis of related enrollments too.
We implemented a few trackers of this sort on the HMHB project. If you want to deep dive how we implemented the same you are very welcome.

Best,
Daler

2 Likes
3

My recommendation is to make both Compounds and Structures as Organization Units (OUs) where Compounds are at a lower hierarchy level number than structures, and then depending on what is being tracked in the Compound/Structure will determine the design of the tracker program.

For instance, let’s say that we are tracking products that are being shipped to Downtown Mall (Compound) but then we want to track these products being distributed across several Shops (Structures) in the mall. Then one possible way to approach this is to create an Organization Unit for the Downtown Mall and a number of OUs for the Shops right below the Downtown Mall i.e. District → Facility.

As for the Tracker Program, since we are tracking the Products, then the Tracked Entity Instance will be the Product. The products are created and enrolled when shipments are received by Downtown Mall but it will be later on moved into a Shop where additional details can be added. I had to imagine a scenario because I am not aware of the details related to the tracker program you are designing but I hope this helps.

However, moving Products from the Mall to the Shop will not be possible if they are enrolled in different Tracker Programs so whether you should create separate programs for each OU level depends on what you are tracking exactly.

1 Like
4

Thanks both @Gassim and @Daler , appreciate the willingness to dive into some concrete options. Very useful.

Creation of OrganisationUnits (OUs) as structures is intriguing, however its the structures themselves that we’re going to need to be tracking. There is also a highly dynamic, fluid nature to these structures where in-field edits will need to be made so that structures which were previously unknown have to be reported on, and that I’m thinking will be a dealbreaker for OUs as a solution.

For the suggestion of multiple trackers—this is something that I was considering but couldn’t find anything on and would definitely like to pick your brain a bit on @Daler . The key part to me is that for the person that is working in the compound list, I would want for them to be able to go to a compound, say there are 8 structures, and then have those 8 structures created automatically. If they have to go into another program and create 8 teis & enrollments for the 8 structures, after creating the 1 tei & enrollment, that feels like it wouldn’t be worth it and we’d simply have them stay with 1 tracker, namely the structure that allows for the disaggregation that we need. But I need to dig in more into enrollment possibilities, relationships, as well as any limitations of these within an Android deployment.