Need some help on Attribute combos

Hi everyone,

Iam new to DHIS2. I have created a dataset but Iam having difficulty in creating extra dataset dimensions: attribute combos.

After choosing the org unit, dataset and a period, the data capturer must select CBO (community-based org.), field supervisor and chw, i.e, when a data capturer selects a CBO, he/she must see all the field supervisors associated with that specific CBO and when he/she selects a field supervisor, he must ee all CHWs associated with that specific field supervisor.

I want to assign these dimensions as attribute combos to the dataset I have designed.

I would like to know how I should structure this in dhis2. Any suggestions are welcome.

Thanks in advance

1 Like

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

1 Like

Thank you very much, Jim Grace. Your explanation is very clear and you have shed light on the question I had about attribute combos.

1 Like

Hi, Jim.

I followed your first approach, but I would like more explanation. The configuration is as follows:

I created CBO as Category Option Group Set containing CBOs AMJ and ACTIVA as category option Groups: AMJ with CHWS_A and ACTIVA with CHWS_B as shown in the table below.

I created Field Supervisor as Category Option Group Set containing Field Supervisors Samuel Juizo Mazive and Roberto as category option Groups: Samuel Juizo Mazive with CHWS_A and Roberto with CHWS_B.

I defined a CHW category with a category option for each CHWS_A and CHWS_B. I defined a category Combination that contains the single CHW category and I assigned it to the Data Set. I shared CHWs_A with user Maria Manave and CHWs_B with user Miro Vaz. When I log in to DHIS 2 with Maria Manave and select the data set I see all the CHWs (A and B), but I expected to see only CHWs_A because CHWs_B are shared with Mario Vaz.

image

More tips will be helpful.

We do alot of community work and we have many forms that require attribute combos. By getting things working in one data set, the same approach will be used for the rest of the froms.

Hi @Fernando,

There are actually several options, but I think using category combinations, etc will limit your analytics outputs and not produce the filtered lists of CHWs you want. I would really like to talk through this on a call instead of writing an essay in response here. There are several other key things I also need to know before making a recommendation. Please send me an email scott@dhis2.org and let me know a date and time you are able to talk.

I’ll post our decision here of course for others that may be in a similar situation.

1 Like

Hi @Scott,

I have sent you an email.

Hi @fernando,

Thanks for the call. To recap for anyone looking at this in the future.

You are collecting data from CHWs that must be disaggregated by location, community based organization/NGO, and CHW supervisor.

  • CHWs are supported by a single NGO and NGO areas do not overlap
  • CHWs report to the facility for supervision and data reporting
  • The organizational unit hierarchy currently only goes down to facility level.

My recommendation

  1. Create a new organizational unit level below facility for CHWs
  2. Create the CHW organizational units - It may be easier to import all of these org units. Do not name the CHW org unit by the name of the CHW, but by position for example CHWs for Boma Cinic would be called: Boma CHW01, Bome CHW02, etc.
  3. Input the CHW name and contact details as attributes of the CHW org unit.
  4. Assign the CHW data set to the CHW org unit.
  5. Assign the CHW supervisor name and contact details for the facility attributes.
  6. Create an org unit group for each CBO/NGO and assign the CHW org units to the CBO/NGO group that provides them support.

Using this approach you will be able to disagregate all CHW data by location, CHW, and supporting CBO/NGO.

This approach is also described in the DHIS2 CHIS Guidlines. I recommend anyone looking to use DHIS2 to collect CHW data look at it.

Hope this helps! :slightly_smiling_face:

1 Like

Hi, Scott.

Thank you. I will share it with my supervisor and other team members and I will email you again so that we can schedule another meeting as there may have been other important points that I missed out.

Scott Russpatrick via DHIS2 Community noreply@community.dhis2.org escreveu no dia terça, 21/04/2020 à(s) 15:27:

That was great @Scott , thank you for your effort, I am actually going through an issue somehow similar to @fernando’s and your solution has given me a good insight on the way I should approach my problem.

Hi @Scott,

Could you please explain this part with screenshots within org unit management APP:

Being in the Org unit app, I do not see in which fields I can put details of CHWS and Supervisors.

My exact use case is the following:

My organization is about to implement a project in which we want to map the health workers with the supervisors. Let’s say in one facility there are 2 supervisors and 10 health workers. We want to map 5 health workers to supervisor 1 and 5 health workers to supervisor 2. I was wondering if you could assist me with my use case.

Thanks in advance