I have a tracker program to monitor milk yield of cows. Once in a month (called test day), the data collector will record morning, mid-day and evening milk yield in liters.
How on can configure DHIS2 to calculate sum of morning, mid day and evening milk production (similar to calculate type questions in Kobo toolbox).
@drvetmedtariqabbas I see that you have made progress in the program you are creating in your instance! Thanks for the screenshot, it sometimes helps in getting to the answer easily. To get the sum of the numbers entered, you’d use a program indicator with an expression: #{morning} + #{midday} + #{evening} [the aggregation type: sum]
Here is a step by step guide in the docs:
### Create or edit a program indicator
Thanks dear AL-Gassim Sharaf Addin!
You’re welcome! (:
I’m looking forward and I’m sure other community members, to hearing about your experience using Tracker for animal production. 
Thanks a lot !
I request to please answer my queries please .
how to create a program indicator that shows monthly performance of each data collector e.g., how many cows he diagnosed for pregnancy in a month in a district he is working ? template attached .
regards
Hi @drvetmedtariqabbas,
It is possible to get indicators for each district if that is what you are looking for? Or maybe create a Data Element that has the name of the data collector because I don’t think it is possible to get indicators from user activity (just the data itself.)
I can’t see the relevance between the image you posted and the question. The woman there is the TEI.
Hope this helps (:
Hi @drvetmedtariqabbas ,
as AL-Gassim suggests, you can use a data element (type: username) with usernames of users as an option set.
An alternative will be to set up the “data collectors” as Organisation Units under the facility orgUnit, example “Farm” or “District”. I am not sure about the structure of your OrgUnit hierarchy, so taking “farm” as example.
So you structure could look like this:
Farm
|
|__Data collector 1
|__Data collector 2
etc.
So the user (the real data collector) will have access to their “Data Collector” orgUnit.
When you later aggregate data for the Farm facility, you will be able to disaggregate that data by “Data collector” orgUnits.
The “Data Collector” orgUnits should not use names of data collectors but rather positions.
The details could be entered in the details of that specific orgUnit.
If data collectors work across several districts, this solution is also possible with some design adjustments.
Hope this can help you further.
Kind regards,
Yury
Hi @YuryR,
Your post has aroused interest. How would we map CHWs as Org Units (data is captured per CHW)? We have the list of the CHWS’ names, not their positions and in our case the CHWS can work across several districts.
Could you share an example with a screenshot of how this part should look like
Would it be possible to view the details when viewing data in the analytics?
Our Tree has four levels (country, province, district and health facility)
Thanks
Hi @fernandoshake, This approach is thoroughly documented in the DHIS2 CHIS guidelines (Chapter 4):
It works very well at large scale (>30,000 CHWs).
My suggestion was based on this structure:
District A
|
|__Farm 1
| |
| |__Data Collector 348
| |__Data collector 467
|
|__Farm 2
| |
| |__Data Collector 911
| |__Data collector 348
|
etc.
The orgUnit details will contain necessary information about Data Collectors.
name, description, contact details, + custom attribute options
For data collectors working across several farms in a district (eg. 348), The data could be aggregated for the highlighted orgUnits (across farms/districts/regions and/or time periods).
It is planned to include “storedBy” and lastUpdatedBy" fields in the new (upcoming) Event Report App - 2.38. However, it will not be a filterable dimension yet.
Hi @Scott,
After reading CHIS guidelines, we are thinking of creating CHWs as category options and attaching them to the respective org units. What is the recommended action should we take in the following situation:
We are worried about data loss.
Thanks
Hi Fernando,
I can not say that I recommend the approach of having CHWs as category options. Liberia did this and it does not scale well, and it become very difficult to manage the meta-data.
What is the structure of your CHW program? If the CHW moves you could just move the CHW1 org unit to the new parent org unit (org unit B). But, I would only recommend doing that if it is important to see a longitudinal recorded for the specific CHW. If that is not important, and it usually isn’t, then I would recommend that you just make a new CHW org unit under Org Unit B and attribute the details of that org unit to CHW1.
Starting on page 72 of this document we outline 5 different cases for how CHW could be represented in DHIS2. Can you tell me which case is most similar to yours? CHISGuidelines_version_August29.pdf - Google Drive
What I mean is that you can put the name, contact details, etc of the specific CHW as attributes to the org unit that they represent. Note that you never want to use the actual name of the CHW as the name of the org unit. The name of the org unit needs to be the position that they hold. Example below:
Hi @Scott,
Thank you for all information and material you have shared so far. Regarding details of CHWs, will it be possible to view them in analytics in case we want to?
Thanks again.
Yes, as org units you can see all data captured by the CHWs.
