dhis2-users team mailing list archive

[Calle Hedberg <calle.hedberg@xxxxxxxxx>]

Nayeem

I agree with your approach for those examples, although using the data
element aggregation type might not cater for all types of indicators (ref
for instance where numerator and denominator have different aggregation
types, or where one of them are some type of group membership count, or
indicators where you only want a result if the numerator or denominator is
above a threshold, or where one of them is offset in time). With the DHIS
increasingly used for e.g. survey data, sample data, case-based tracker
data etc etc, we need a more versatile indicator processing where all forms
of aggregation are either blocked (if clearly not correct/relevant) or else
yield correct results.

The issues have been on the agenda for a long time now, and I hope it will
be finally resolved in 2.31. What's needed is to ensure e.g. the SL demo
instance have examples of all types of indicators (and the underlying
data), then to verify that any relevant aggregation yields correct values.

Regards
Calle

On Wed, 19 Sep 2018 at 16:50, Nayeem Al Mifthah <n.mifthah@xxxxxxxxx> wrote:

> Hi Calle
> Hope you doing well.
>
> You are correct in a sense of different analytics type may required for
> indicator aggregation :-)
>
> There are better and easy way to calculate. If you minutely look at my
> earlier mail, probably you identify that, I have written to perform
> aggregation according to aggregation type of the particular data element,
> which might be sum, average, average (sum in organisation unit hierarchy
> etc.). After that the indicator calculation should done.
>
> Probably my earlier mail have difficulties to understand due to only one
> example. Let me give another example as well-
>
> Probably there is a data element for number of doctors posted in an health
> facility with aggregation type average (sum in organisation unit hierarchy)
> and another data element for number of patient visited with aggregation
> type sum.
>
> Now you might have the below data table-
>
> Hospital A, January, Doctor posted- 6
> Hospital A, February, Doctor posted- 4
> Hospital A, March, Doctor posted- 6
>
> Hospital A, January, Patient visited- 3000
> Hospital A, February, Patient visited- 4000
> Hospital A, March, Patient visited- 6000
>
> Hospital B, January, Doctor posted- 40
> Hospital B, February, Doctor posted- 50
> Hospital B, March, Doctor posted- 80
>
> Hospital B, January, Patient visited- 40000
> Hospital B, February, Patient visited- 30000
> Hospital B, March, Patient visited- 40000
>
> ___________________________________
> If you want to calculate average number of patient seen by one doctor, you
> can find-
> Hospital A in January- 500
> Hospital A in February- 1000
> Hospital A in March- 1000
>
> Now if you want to make the same indicator for first quarter there is no
> way to calculate from 500, 1000, and 1000. There average is 833 which is
> not actually expected result, even the sum 2500 is not also expected value.
>
> The best way is to make sum of patient as per the aggregation type of the
> data element which gives (3000+4000+6000)= 13000 and make average number of
> doctor posted for the period (6+4+6)/3= 5.33. Now if we done the
> calculation for the indicator we found 13000/5.33= 2439 patient has been
> seen averagely by one doctor in first quarter.
> ___________________________________
>
> Again, if you want to calculate the same indicator for-
> Hospital A in January- 500
> Hospital B in January- 1000
>
> Now, if you want to calculate for Hospital A and B together, there is no
> way to find desired value from 500 and 1000. The average is 750 and sum is
> 1500 which are not expected.
>
> The desired output should be (Patient visited hospital A in January, 3000
> + Patient visited hospital B in January, 40000) / (Doctor posted in
> Hospital A, 6 + Doctor posted in hospital B, 40).
> Result 43000/46 = 934 patient per doctor.
> _______________________________
>
> The same way of calculation is also applicable for indicators which build
> in combination of organization unit, program indicators and others.
>
> Sorry for the long mail, but hope it clarifies. :-)
>
> Regards-
> *Nayeem Al Mifthah*
> *Health Information Systems Specialist*
> Support to the National HMIS
> MIS, Directorate General of Health Services
> Ministry of Health and Family Welfare, Bangladesh
> Telephone: +880-2-58816459    |    Fax: +880-2-58813875
> Mobile:  +88-01914 030 574    |    Email: n.mifthah@xxxxxxxxx
> Skype: nayeem.a.m    |   LinkedIn:  linkedin.com/in/nayeemam
>
>
> On Wed, Sep 19, 2018 at 2:22 AM Calle Hedberg <calle.hedberg@xxxxxxxxx>
> wrote:
>
>> Folks,
>>
>> This has been repeated ad nauseam - as you say, most health indicators
>> should in general be calculated as sum(numerator)/sum(denominator), whether
>> it's aggregated in the time or in the geographic dimension. That is because
>> most aggregated data elements used to calculate indicators are counts of
>> many discrete events.
>>
>> Yes, we need some alternative processing for
>> - "number only" indicators (aka "Calculated data elements") and certain
>> indicators
>> - indicators that include data elements representing "levels" (e.g.
>> hospital beds, or staff numbers - those can be summed up geographically but
>> must be averaged over time).
>>
>> Most of the underlying meta-concepts are in the DHIS already (data types,
>> aggregation types), but implementing it fully requires quite a bit of
>> re-engineering analytics - which hopefully will be done for 2.31 :-)
>>
>> Regards
>> Calle
>>
>> On Tue, 18 Sep 2018 at 19:03, Nayeem Al Mifthah <n.mifthah@xxxxxxxxx>
>> wrote:
>>
>>> Might be same behavior desires for totals as well.
>>>
>>> Regards,
>>> Nayeem Al Mifthah
>>> Kindly ignore typos.
>>>
>>> On Tue, 18 Sep 2018, 22:35 Nayeem Al Mifthah, <n.mifthah@xxxxxxxxx>
>>> wrote:
>>>
>>>> Hi Lars and others
>>>> I have commented on an old issue DHIS2-575 about the desired behaviour
>>>> ...
>>>>
>>>> I think expected behavior should calculate the element aggregation as
>>>> per aggregation type of that perticular data elements first and later
>>>> calculate the indicator. Example:
>>>>
>>>> If number of patient visited OPD in January is 200 and number of
>>>> admission in January is 40. In that case, comparison of admission to OPD is
>>>> 20%.
>>>>
>>>> And in February, number of OPD visit in February is 400 and admission
>>>> is 200. % of admission to OPD in February will be 50%.
>>>>
>>>>
>>>>
>>>> If I want to see the same indicator in January+February, it is showing
>>>> liniar average of two months indicator like (20+50)/2= 35%
>>>>
>>>> It should show, (40+200)/(200+400)=30%
>>>>
>>>> I think it should aggregate the element according to aggregation type
>>>> of that element at first and then calculate indicator.
>>>>
>>>>
>>>> Regards,
>>>> Nayeem Al Mifthah
>>>> Kindly ignore typos.
>>>>
>>>>
>>>> On Tue, 18 Sep 2018, 22:14 Lars Helge Øverland, <lars@xxxxxxxxx> wrote:
>>>>
>>>>> Hi Gourav,
>>>>>
>>>>> thanks and, perhaps surprisingly, this is expected behavior as of now.
>>>>> Indicators are often percentages, and it does not make sense to summarize a
>>>>> lot percentages across different indicators; it makes more sense to average
>>>>> them.
>>>>>
>>>>> That said, sometimes indicators represents plain sums of data elements
>>>>> (no denominator, or denominator = 1), so we are working on some refinements
>>>>> here which we will backport.
>>>>>
>>>>> best,
>>>>>
>>>>> Lars
>>>>>
>>>>>
>>>>> On Tue, 18 Sep 2018 at 08:09, gourav sachdeva <
>>>>> gouravsachdeva95@xxxxxxxxx> wrote:
>>>>>
>>>>>> Hello Team,
>>>>>>
>>>>>> I'm facing an issue in a pivot table, version 2.28 while calculating
>>>>>> the total of indicators.
>>>>>>
>>>>>> Whenever I try to generate the pivot report with indicators it shows
>>>>>> the average instead of the sum in the total section. I checked, the same
>>>>>> issue has been created on Jira and the status is resolved but I am still
>>>>>> facing the above mentioned.
>>>>>>
>>>>>> https://jira.dhis2.org/browse/DHIS2-3350
>>>>>>
>>>>>> Version: 2.28
>>>>>> Build Revision: 6657e9d
>>>>>> Build Date: 2018-09-17 03:20
>>>>>>
>>>>>> The screenshot is enclosed for the reference with the mail.
>>>>>> Looking forward to your response.
>>>>>>
>>>>>> --
>>>>>> *Thanks & Regards,*
>>>>>>
>>>>>> *Gourav Sachdeva*
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lars Helge Øverland
>>>>> Technical lead, DHIS 2
>>>>> University of Oslo
>>>>> lars@xxxxxxxxx
>>>>> https://www.dhis2.org
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~dhis2-users
>>>>> Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~dhis2-users
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~dhis2-devs
>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> --
>>
>> *******************************************
>>
>> Calle Hedberg
>>
>> 46D Alma Road, 7700 Rosebank, SOUTH AFRICA
>>
>> Tel/fax (home): +27-21-685-6472
>>
>> Cell: +27-82-853-5352
>>
>> Iridium SatPhone: +8816-315-19119
>>
>> Email: calle.hedberg@xxxxxxxxx
>>
>> Skype: calle_hedberg
>>
>> *******************************************
>>
>>

-- 

*******************************************

Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19119

Email: calle.hedberg@xxxxxxxxx

Skype: calle_hedberg

*******************************************