dhis2-devs team mailing list archive

[johansa@xxxxxxxxxx]

Dear Thuy,

I'm not very familiar with the requirements in Sri Lanka, but I have a few
general comments. First, the categories and combinations should be used
when we want to aggregate them into a data element that is a natural total
of these categories. For stock, this is usually not the case, as we do not
want to add start balance, received, issued, and monthly requirement (in
this case). The total will be meaningless. The average monthly requirement
would probably also be a semipermanent data element I think.

Second, regarding the parent/child/grandchild totals, I think it should be
possible to set aggregation start levels, meaning you could use the same
data element definitions for all levels without running into double/triple
counting. But others would need to fill in about this.

Aside from this, I would recommend some changes to the form attached, if
possible. If these forms are not final, I would recommend adding some
aggregate information on stock outs, such as days out of stock. But if
this is generally not a problem, then the few instances can be derived
from the other data elements.

Regards,
Johan

> Dear all,
>
> According to the aggregating report RHMIS1158 and requirements described.
> I
> create the system in DHIS as below. Please see if I doing right, or DHIS
> need a new function in aggregated way.
> I created 5 data elements
>  - Condom,
>  - Oral Pill packet,
>  - Injectables Vials,
>  - Intra Uterine device,
>  - Implants.
> All these dataelements would be assigned with category combination include
> 4
> category options are :
> - Amount at the end of lastmonth,
> - Amount received during the month,
> - Amount issued during the month,
> - and Average monthly requirement.
>
> Those data elements were in a dataset for all organistaion unit levels
> enter
> data. Because all of them need to update their stores. But by doing as
> described above, there are problems:
>
> 1. The system require that the upper level shouldn't see data entry form
> or
> edit data values of lower levels. To solve this, I create different
> datasets
> contain above data elements and assign to different organisation unit
> levels.
>
> 2. However, when generate report, because DHIS aggregated data from bottom
> to top org unit levels. So the parent org unit can't view their own data
> values but total values included their values and their children's values.
> And data would be double a lot because example for data element Condom
> received during the month. parent orgunit received 100, then they issued
> 100. The children org unit will received 100. So after aggregated, the
> total
> received will be 200. This is not right.
>
> And in report, they just want to view seperate org unit level total but
> not
> aggregate from bottom to top. And it was a little bit difficult when
> parent
> org unit will want to see their values OR children org unit values, not
> include total of their grandchildren orgunit level values
>
> So I created more data elements for different org unit levels. Such as
> Parent OrgUnit - Condom(received during the month)  (in dataset of parent
> org unit)
> Children OrgUnit - Condom(received during the month) (in dataset of
> children
> org unit)
> GrandChildren OrgUnit - Condom(received during the month) (in dataset of
> grandchildren ort unit)
> For this, I can seperate the org unit levels to not view and edit data
> values of others. As well as generate report without total of multi org
> unit
> levels.
>
> But I wonder if this is the right way to store data? by this way will we
> face any problem in the future? If this is not the right way, then how
> should I create the reports to satisfy report viewing requirement? I know
> that in data element has a check box for aggregated at level.. but that is
> only for temporary use. and in this case the aggregated of org unit level
> is
> not stable to use that. Should we have selections to select which level to
> aggregate while design/generate report?
>
> Those are doubts in my mind. I am not much sure what I am doing is right
> or
> wrong because I don't have much experience about retrieving data values
> and
> analysis later. So I hope you have experience about that help me to see
> the
> problems may happen if I do this way or that way to store data.
>
> Thank you very much
>
> Thuy
>