Best approach for OUs where CHWs come and go

Support - Assistance technique
1

Hi @Jim_Grace,

Our use case

We want to configure CHWs as org units in the organization hierarchy, but since CHWs are dynamic (i.e., they are not permanent entities), what is the best approach to adopt?

NB: We are talking situations where CHWs come and go, and we can even move them from one facility to another if needed.

If possible, please, you can provide a step-by-step explanation on how to achieve this.

Thanks

2

Hi @fernandoshake, I worked on a project that did exactly this. They created generic, numbered organisation units for the CHWs because they would change. So for example if they had a facility “Central Hospital”, they created organisation units below called “Central Hospital CHW01”, “Central Hospital CHW02”, etc. Under each facility they created as many CHW organisation units as they were likely to have CHWs at one time. (If they found they didn’t have enough, they could add more later.)

For each CHW person, they created a DHIS2 user account, and assigned the user to the organisation unit where they worked. So for example CHW user “John Doe” could be assigned to organisation unit “Central Hospital CHW02”. Maybe John Doe also worked at “Western Clinic” and was known there as “Western Clinic CHW05”. The user could be assigned to both organisation units “Central Hospital CHW02” and “Western Clinic CHW05”. When they were working for Central Hospital, they would record data under the organisation unit “Central Hospital CHW02”, and when they were working for Western Clinic, they would record data under the organisation unit “Western Clinic CHW05”.

When John Doe leaves they could disable their account, and assign a new person to “Central Hospital CHW02” and/or “Western Clinic CHW05”.

Let me know if you have further questions. I’m tagging @Scott in case he has any newer or better suggestions.

2 Likes
3

Hi @Jim_Grace,

Following this approach, sine we will not be using CHWs’ real names when configuring them as org units, what will happen if we want to do data analysis per CHW? Sorry if my question is not clear.

Thanks

4

@fernandoshake I believe your question is clear, and I’m not sure there is a good answer. A lot depends on exactly what kind of data analysis you need to do per CHW, and how important that need is. Here are some ideas:

  1. Using the approach above:
  • If your primary concern is data quality for the facilities, and if you find data you want to investigate with a CHW, you could do data analysis per CHW org unit (…CHW01, …CHW02, etc.) If you find data you want to investigate, you would need to know which person was assigned to which orgUnit, and you could follow up with that person. You might also create a SQL View that queries the datavalue table and looks at the storedby column. This will tell you which user entered the data.
  • If you want to do some rough overall analysis, like how many values did each each CHW enter during a time period, you could write a SQL view for that which also looks at the storedby column in the datavalue table.

  1. You could create a different organisation unit for each CHW under each facility. Depending on the size of your implementation, the number of CHWs involved, and the expected lifetime of your implementation, you may or may not want to do this because of the number of organisation units involved. If you want to track the data from CHWs as they move between organisation units, you could even create an organisation unit group for each CHW, and assign to each group the CHW-specific organisation units where they have worked. This of course would result in many more organisation units over time. If you use the CHW organisation unit groups, they would have to be maintained centrally.

  2. Use attribute option combinations instead of multiple organisation units. In the maintenance app create a category with data dimension type Attribute named, say, “CHW”, and create a category combination also of data dimension type Attribute (maybe also named “CHW”) containing only that category. For each data set for which you need CHW data entry, assign it the category combination of CHW. For each CHW user, create a category option with their name and add it to the CHW category. The category option can be assigned to only those facilities where the CHW is currently working, so data for that category option may be entered only for those facilities. You can limit the sharing of the category option so it is shared only with the CHW for whom it is created and not other CHWs, so other CHWs cannot enter data for it. (It would also need to be shared with anyone who needs to see data for all the CHWs.) This would allow you to do very flexible analysis per CHW. One major drawback is that, unlike the first two approaches, maintenance of this implementation cannot be distributed. With the first two approaches, a facility or district user could be authorized to create new user accounts and new organisation units within their facility or district. With this approach, the configuration of CHW category options would have to be done centrally, and would involve a lot of steps including the sharing. If you had the programming resources, you could write a custom app to administer this metadata.

1 Like
5

Just weighing in that we did exactly what Jim described in #3 and it has been great for analyzing performance of individual CHWs but was VERY COMPLEX to set up and get the hang of all the sharing.

2 Likes