Hi Fernando,
I was hoping someone would have better ideas than mine, but I haven’t seen them yet. Here are my thoughts:
It may not be possible to do what you want, at least not in the way you describe. Attribute option combos can’t be selected in a hierarchy as you desire: CBO → Field supervisor → CHW. Here are two different approaches that may or may not fit your requirements, but will work in DHIS 2:
1 - Define a CHW category with a category option for each CHW. Define a category combination that contains the single category CHW. So each CHW will be a single category option and also a single category option combination. During data entry, the user selects which CHW they are entering data for. You can use sharing to restrict the data entry users to see only those CHWs for which they are authorized to enter data. So a data entry user would see a flat list of CHWs, but hopefully it would not be too long.
The Field supervisors can be category option groups, belonging to the “Field supervisor” category option group set. Each Field supervisor group would contain the CHWs associated with that Field supervisor. This can be used, for example, if you want to do reporting or analysis based on Field supervisor.
In the same way, CBOs can also be category option groups, belonging to the “CBO” category option group set. Each CBO group would contain all the CHWs in that CBO. This allows you to do reporting or analysis based on CBO as well. Note that DHIS 2 does not let you model Field supervisor and CBO here as a true hierarchy, but you can create them as two different sets of groups. If you have users who should see only some CBOs, or only some Field supervisors, you can use sharing on these objects also, so that users are not presented with long lists of objects to which they should not have access.
If you want to model the full hierarchy of CBO → Field supervisor → CHW in this way, there is some redundant configuration. You must include each CHW both in the Field supervisor and in the CBO to which they belong. And if you want to manage sharing for all these objects, the configuration becomes yet more complex. To avoid error, and excessive work, you may want to have the relationships in this hierarchy defined somewhere external to DHIS 2, and use some scripting to update the relationships in DHIS 2 through the Web API, as the relationships change externally to DHIS 2.
This design is very similar to what is used by PEPFAR, so it has been tried and tested. PEPFAR has a single attribute category option (and a single category option combination) for each “mechanism”, which can be thought of as a project. Each mechanism is associated with a partner, and above that also with a US Government agency who oversees the work of the partner for that mechanism. The Partners and Agencies are created as category option groups of mechanisms within two group sets, much as I suggested you might do for Supervisors and CBOs. For the purpose of sharing, PEPFAR creates user groups for each partner and each agency, and shares with them the mechanisms, partners and agencies that each group is allowed to see. All the relationships between mechanism → partner → agency are stored externally to DHIS 2, and a script is run daily to update these relationships in DHIS 2 as they change in the external reference. The script also updates the sharing relationships of these objects with the user groups, and even adds new user groups when there are new partners or agencies. PEPFAR calls this script the “mechanism importer”.
2 - A different approach would be to model each CBO as an organisation unit at the next level down. I don’t know how your model works, but If you have the same CBO at multiple org units, you would have to create a different org unit at the next level down for each combination of org unit / CBO.
2a - You could still model CHWs as category options, and supervisors as category option groups. You could configure each CHW category option to restrict it to an organisation unit. That way, when an organisation unit is chosen, only the CHWs assigned to that CBO will be available for selection.
2b - You could model supervisors as an organisation unit level below CBOs. You could still model CHWs as category options.
2c - You could model CHWs as an organisation unit level below supervisors. This is somewhat like how we model CHWs in a system we have developed to track CHW stock levels – they are actually modeled as organisation units below a facility. I believe there are other DHIS 2 instances as well that take this approach.
Maybe others can add their experience in any of these approaches.
I hope this helps you and/or others!
Cheers,
Jim
