What is the best way to approach cascading category option combinations?
Facilities are assigned to organizational groups (there are 5 levels). Clients visit the facilities from their various locations and we need to collect those locations but only up to level 3 in the OU hierarchy. What is the best way to approach this?
My use case is not the same as Edward Robinson’s but I wanted to learn from his experience and try to sort out how I could achieve my desired results
This is a short description of the scenario.
For our DHIS 2, We have the following organization hierarchy as the basis. We have ten provinces, a lot of districts and health facilities.
In two of the provinces, my company is working with some partner organizations for the implementation of a three-year project. The flow of information is as follows:
CHWs collect data on papers, which is then sent to field supervisors for validation. After validating the data, the field supervisors will send the data to our partner organizations for data entry in the dhis 2. After data is entered in the Dhis 2, it will be viewed by our monitoring and evaluation officers for analysis and reporting. There are several partner organizations working in the same district and several field supervisors overseeing work of CHWS. Although we would like to view reports by chw, we also want to collect information about partner organization and field supervisors.
We would like to map these three entities (chws, field supervisors and partner organizations) without altering the Organization hierarchy.
We are seeking input from you on how we can achieve this, and we welcome all possible solutions.
NB: this is a new scenario for us. For other projects, we collect data up to health facility level.
• The data is being entered at the health facility level;
• Yes, Chws and field supervisors are not permanent entities. They may move from one district to another based on the Project director’s decision;
• The data is collected during the monthly and must be entered monthly in the DHIS 2;
• The paper collection is Tally sheet (configured as a data set in DHIS 2).
I came across this post, and it caught my attention, so thought I might offer some thoughts @dmbantu .
It seems like there is an association between an organisation unit and the various roles. It also seems that this association could be dynamic, with CHWs or supervisors moving to new branches of the organisation hierarchy. I think your choice of not placing the associations in the orgunit hierarchy is a smart one!
One possible option would be to use an “attribute option combination” to effectively disaggregate the dataset. You could in theory create a category combination of Partner organisations → Field supervisors → CHWs. This approach does not scale well though. If you have 10 partner organisationations, 100 supervisors and 1000 CHWs, you would end up with 1 million possible category option combinations, many of which would of course be invalid. It also does not seem to work since unlike a normal category combo, this one would seem to change over time. So, I do not think that approach would work.
For me it almost seems like you would need to collect the Field supervisors, Partners, and CHWs as data values. As you say, they could change over time. The problem then becomes how to analyze the data. It is not possible in DHIS2 to directly use a data value as a data dimension. Moreover, since the associations between CHWs/Supervisors/Partners would seem to be dynamic, there is currently no way to implement a time-based dimension through the DHIS2 analytics engine.
I think the only way would be to extract the data into your own data warehouse and deal with the time-based analytics there, transforming the data which has been collected as a data value into a dimension (i.e. column) in your own analytics database.
I might be over complicating things, but it sounds like a pretty tough problem to solve. You would need a means to manage the associations between Partners/Supervisors/CHWs over time. You would need some way to make the selections cascading, so that data entry personnel do not choose the wrong partner for a supervisor, and all of that would need to somehow be coupled to the data entry screens. In short, it seems like a quite difficult problem to solve both from a metadata management standpoint, but also from an analytics standpoint.
It would be interesting to know what you come up with. Keep us posted!
We were thinking of adopting this approach but as you say creating all 3 roles as category combination swill end up with a very high number of option combo permutations and this process can easily grow complex and be error-prone.
Were it not for data analysis problems, the following approach would keep things simple. If we were to collect Field supervisors, partners and CHWs as data values, should we have to create them as data elements?
I have read about data warehouse, but I have no idea how it works and I think this part would be really complicated for me as I am still a DHIS 2 learner.
Your explanation is helping me to understand how complex the problem is.
Yes, I think its definitely a non-trivial problem. You would likely need some other system (perhaps an HR management software) to manage the associations between CHWs/Supervisors and Partners. Somehow this system would need to be coupled to your DHIS2 to be sure that you have an up-to-date snapshot of the organization unit hierarchy. Then you would need to think about how to handle situations when a CHW has Supervisor A in December, and then Supervisor B in January. If you were looking at your data, you would want to be able to represent that association, but then you would need to keep a record of a CHW and their historical supervisors. Then you would have to figure out how to get that information in a DHIS2 data entry screen with some custom form, and then deal with the external analytics. I agree…I think it sounds quite complicated.
I might suggest to take it one step at a time. I suspect you do not have too many partners, and that could be added as an attribute option combo in your dataset fairly easily. You would then only need to manage a single category with a list of partners, but it would allow you at least to be able to aggregate your data across that dimension which might be an improvement over what you have now.
If the CHW, Field Supervisor, and/or Partner Organisations are set in mutually exclusive Organisational Units, then you might be able to create ogranisational Unit Groups within a Set per dimension needed. I.e. if CHW 1 was active in OU 1, OU 2, OU 3 and CHW 2 was active in OU 4, OU 5, and OU 6, you could create an OUG, call it “CHW 1 Area”, and assign 1,2,3 to it. Similar for CHW 2 Area, for 4,5,6. This could be packaged in a “CHW Assignments” OUGSet, which you could (although it might be super tedious) edit this as needed if assignments changed.
With an event model we do use simple analysis with Option Set pouplated Data Elements in event reports; there are certainly limitations here, but if we’re looking for an event count broken down by values within a Data Element, its an easy place for us to exist. Would be surprised if this wasn’t also possible with a Data Set?
Finally, I know that there is a Feature request that I believe is being set up in 2.37.0 to include StoredBy in the analytics as a dimension–depending on who is entering in this information, might also be a way to have CHW/Supervisors baked into the overall analysis without having to add metadata to the structure.
Thank you also for shedding light on my use case. What we have created is a dataset because we are collecting aggregate data.
Giving more details:
For the project we want to map health workers with field supervisors and partners. For now, we can exclude partners. Let’s say in one facility we have 2 field supervisors and 8 health workers so we want to map 4 health workers to supervisor 1 and 4 health workers to supervisor 2 (CHWs and supervisors are attached to a facility) and when going to visualization/ analysis, we want to view data of the health workers by supervisor. In this case:
Would the field supervisors be mapped as field supervisor 1 area, field supervisor 2 area as the example of CHWs in the description below? would the org unit groups and group sets be configured differently?
How would the organization unity look like after mapping CHWs and field supervisors, knowing that we now have the following org unit hierarchy? I will be happy if you can explain to me with pictures/ screenshots.
Thank you for delivering useful guidance.
(AL-Gassim Sharaf Addin)
split this topic