dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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
>