dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

I am not in agreement but will formulate a longer response on a
seperate thread. Jason

On 10/30/09, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
> This sounds like a simple GUI feature request rather than something
> fundamental about categories.
>
> Request: an option to generate totals column for category options.  Not that
> it should be stored.
>
> In general I think I would view having "Total" categoryoptions as a
> proverbial bad thing.
>
> Mind you this is a distraction from the general question ....
>
> 2009/10/30 Jason Pickering <jason.p.pickering@xxxxxxxxx>
>
>> Perhaps it is a bad example but it raises a good point, and we might
>> should move this to a new thread if it continues to balloon.
>>
>>  My understanding was the category options would be used for data
>> entry.  This is not really an issue about 1.4, it is really an issue
>> about whether people will enter totals or not. There is nothing to
>> prevent people from defining a category , Gender, with three (or more)
>> options, "Male" "Female" and "Total", and it may be necessary. Let me
>> explain.  On the paper tools used here in Zambia, there is a separate
>> column "Total" which is the sum of three age groups (Under 1, 1-5 and
>> Over 5). If I was going to implement the multidimensional data
>> elements here, if I wanted to replicate the paper tool exactly, I
>> would need a separate column for totals. This is what we have now, and
>> it serves a good purpose, as the data entry personnel can see if the
>> totals provided by the facility actually match the calculated totals.
>> No idea if this is how the categories work in DHIS2. But from the
>> analysis standpoint, it would seem that you would need some calculated
>> data element as well that would calculate the total from the
>> multidimensional components of the data element, unless as you say,
>> you are going to rely on OLAP or PivotTables to always do this
>> aggregation for you. I would think that actually having the ability to
>> persist and store the data value, as a calculated data element (Save
>> calculated) and assign it a Category option of "Total" (which might be
>> implicit anyway in the system) would make sense, since you might need
>> it directly in a report or something and do not want to have to revert
>> to OLAP or custom SQL to get this. But again, I am looking at this
>> from the perspective of a bunch of data elements which do not use
>> category options.
>>
>> You would get the totals as you state, but only by using OLAP. What
>> about if I want to create an Excel report with only Totals? Now if the
>> new model will automatically give me the totals from the component
>> dimensions, great, but I did not see this in the blueprint. I was
>> assuming that I would need explicitly define a separate, calculated
>> element for this.
>>
>> Regards,
>> Jason
>>
>>
>> On Fri, Oct 30, 2009 at 5:34 PM, Ola Hodne Titlestad <olatitle@xxxxxxxxx>
>> wrote:
>> > 2009/10/30 Jason Pickering <jason.p.pickering@xxxxxxxxx>
>> >>
>> >> OK, I took a walk around the block to think about this a bit more. I
>> >> think it does, make sense, sort of. Lets look at  "Total", which might
>> >> be defined as a calculated data element, say composed of different age
>> >> groups. But the "Total" in this category, would not be the same as the
>> >> "Total" that might be defined in a different category, or would it?
>> >>
>> >
>> > I thought the whole point of the category/categoryoption/categorycombo
>> model
>> > was that the total would be the data element itself without any
>> > categoryoption? The "total" should then not be defined as one of the
>> > options, but be always be derived from the sum of all the options.
>> >
>> > Your example Jason is from a 1.4 design point of view where you are not
>> > using this model, but normally need calculated data elements to get to a
>> > total (since the categoryoptions are part of the data element names).
>> With
>> > the new data element group set model I guess you can derive the total
>> > for
>> > e.g.  "Malaria new cases OPD" e.g. by filtering on the data element
>> > group
>> > "Malaria" in the group set "Diseases" plus the group called "New cases"
>> in
>> > the group set "Patient status" and then simply sum up all the data
>> elements
>> > in the two groups sets "Gender" and "Morbidity age group". Would't such
>> an
>> > approach give you the totals you need?
>> >
>> > As in exactly how we could accommodate that within DHIS2 e.g in a report
>> > table GUI I am not sure. Seems complicated and something for an OLAP
>> > tool
>> to
>> > take care of.
>> >
>> > Ola
>> > -----------
>> >
>> >>  Having a single categoryoption "Total" would allow one to slice out
>> >> particular groups of dimensional elements, which is a fairly common
>> >> operation as Ola mentions, with a single filter statement. Otherwise,
>> >> you would need to collect all of the "Total"s for different categories
>> >> through another table and perform an inner join, as opposed to a
>> >> filter. For multiple category options, I guess there would need to be
>> >> a decision made whether to perform an inner join or loop through a
>> >> filter, but I guess an inner join would actually be better for either
>> >> one or many category options (have not looked at the code). If the
>> >> uniqueness contraint is not there, the user would need to select in a
>> >> separate step to select all "Total"s and then perform an inner join,
>> >> as there would be no intrinsic relationship between "Total" in the
>> >> "Age" category and the "Total" in the "Gender" category. This might be
>> >> very tedious if there are many categories to select from. Having
>> >> multiple category options with the same name does not make sense in
>> >> this case, and I think this is what everyone is saying?
>> >>
>> >>
>> >>
>> >> Obviously  there should not be two category options called "Total" to
>> >> be within a single category/data element group set. However,I am not
>> >> sure I understand completely your point Ola. To me, the use case you
>> >> describe is very typical. "Give me all data for the under 1 age
>> >> group", "Give me all data on in patient discharges". Having to define
>> >> multiple "under 1" and "IPD" for each category seems to be very
>> >> inefficient, as well as painful.
>> >>
>> >> So, I guess maybe I am answering my own mail...I think.
>> >>
>> >>
>> >>
>> >>
>> >> 2009/10/30 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>> >> >
>> >> >
>> >> > On Fri, Oct 30, 2009 at 2:43 PM, Jason Pickering
>> >> > <jason.p.pickering@xxxxxxxxx> wrote:
>> >> >>
>> >> >> Could some one remind me once again what the point of having a
>> >> >> category option in two separate categories is? is there a use case
>> >> >> here? It does not seem totally obvious, but maybe I am missing
>> >> >> something.
>> >> >>
>> >> >
>> >> > It might be that there are none. This could be useful in the sense
>> that
>> >> > if
>> >> > nobody asks for removing the constraint - we won't.
>> >> >
>> >> >
>> >> >
>> >>
>> >> _______________________________________________
>> >> Mailing list:
>> >> https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> >> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> >> Unsubscribe :
>> >> https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> >> More help   : https://help.launchpad.net/ListHelp
>> >
>> >
>>
>> _______________________________________________
>> Mailing list:
>> https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe :
>> https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> More help   : https://help.launchpad.net/ListHelp
>>
>

-- 
Sent from my mobile device