← Back to team overview

dhis2-devs team mailing list archive

Re: On categories and dimensions and zooks

 

I think you made one category too many..
please read on below

> Here I go again, this time on categories/category options/category
> combinations.
>
> The concept I want to address is that of dimensional hierarchy within a
> set
> of data elements. Let me try my ASCII art skills here..
>
>
> Total foos distributed
>
> __________________________|____________________________________________
>                                                           |
>
>
> |
>                           Total foos distributed to
> wogs
> Total foos distributed to zooks
>                                     |                        |
>
>                         |                                  |
>
> Total foos distributed to blue wogs   Total foos distributed to green
> wogs                   Total foos distributed to blue wogs
>   Total foos distributed to green zooks
>
> In this example, the data element "Total foos distributed" is the sum of
> its
> component parts. Perhaps it is also collected at various locations which
> have certain types themselves, which will serve as a dimension later on in
> this example. Perhaps we also collect information on the number of "bars"
> distributed as well, which has a corresponding disaggregation hierarchy
> as
> presented above.
>
>  Let's assign the first level a dimension of "Parent data element", the
> second level "Type" and the third level "Color".
> I am being purposeful abstract here, but in practice these dimensions
> might
> correspond to disaggregation dimensions "Age", "Gender", ARV Treatment
> regimen", etc in a real system.
>
> My limited understanding of the Data element category is as follows. In my
> example here, I would have three  categories (Item, Creature, and Color).
> The first category (Item) might contain the following category options
> (Foos, Bars). The second  category (Creature) would contain the following
> options (Wogs, zooks), while the third level category (Color) could
> contain
> the options (Blue, Green).

No need for category "item"
Your dataelements would be 1) foos 2) bars
Both with category combo "creature-colour", consisting of the two
categories "creature" and "colour". The two category options wogs and
zooks would go into creature, and blue and green into colour. No need for
foos nor bars to be category options.

> Where am I going with this you ask? Well, I would like to be able to
> pivot/crosstab my data on these possible dimensions, to see how many foos
> have been distributed to green creatures in rural locations. I might want
> to
> know how many Foos and Bars have been distributed to only wogs at private
> facilities (another dimension). A PivotTable, along with the appropriate
> data source, would allow me to do this.

Some countries have rural/urban or perhaps private/public as part of the
data form. However, most don´t have that, and they solve it with having
these dimensions as (compulsory, exclusive) org unit groups. In
tajikistan, urban/rural was part of the form, and then we made that
another category, with the two category options urban and rural. Then you
will get 2 data element (foos, bars), with 6 dimensions each(3*(category
with 2 options each)). This should clarify most of the things below... but
keep reading!

> Now, when I look at the current implementation of the Data element
> categories, it is not clear to me how I might be able to accomplish this.
> I
> can create these dimensions (categories in DHIS-speak), and assign
> elements
> (category options in DHIS-speak) to them. I can then assign a number of
> dimensions (categories) to a category option. I can then assign a data
> element to a category option, which translate essentially to assigning a
> dimensionality to the data element.
>
> However, there does seem to be the ability to assign dimensions, there
> does
> not seem to be the ability to assign particular elements within those
> dimensions to a particular DHIS data element.
>
>  Am I missing something here?
>
> Let me ramble on. There is the ability, through organizational unit group
> sets to assign dimensionality to a certain organizational unit. (Ownership
> type, urban/rural, facility type). It would seem to me that the
> organizational unit is simply another dimension, albeit a fundamental one
> within DHIS and most Health information systems. Nonetheless, it is a
> dimension, that amends itself to production of data sets that can be
> crosstabbed on various dimensions (different organizational unit groups).
>
> However, it would seem that the data element itself, as currently defined
> in
> both DHIS 1.4 and 2, lack this intrinsic notion of dimensionality.
>
> It would seem that the final data set that should be present in a given
> crosstab table would be the Cartesian product of each of its possible the
> dimensions trimmed for values that result in NULLs (e.g Location,
> Ownership
> Type, Urban/Rural/Facility Type, Item, Creature, Color in my given
> example).
> This does not seem to be the case to me at the moment, but perhaps I am
> missing something?
>
> Thoughts?

Regarding pivot tables then, you can make your pivotviews either based on
the aggregate data element values (add up all the category option values),
or add the category combo, category, and category options as pivot fields.
Then you can easily disaggregate as you please. If you then also have the
orgunit groups as a pivot field, you should be able to do see whatever
level of aggregation you want.

Hope this helps
Johan

> Regards,
> Jason
> _______________________________________________
> 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
>





Follow ups

References