dhis2-devs team mailing list archive

[Knut Staring <knutst@xxxxxxxxx>]

Hi guys,
For this discussion, it would make sense for you to take a look at the
"disaggregation" descriptors in the Global Health Observatory.

Go to http://extranet.who.int/gho/

Click on World Health Statistics and then select Mortality and burden of
disease. You should now see a table. Click on the header, where it says
Maternal mortality ratio (per 100 000 live births)

This will pull in the definition from the Indicator and Metadata Registry
(IMR) using a web service (is planned to be SDMX later).

Click on "More" in the upper right hand corner and scroll down to
Dissaggregation to see the dimensional breakdown.

Knut

2009/10/1 Jason Pickering <jason.p.pickering@xxxxxxxxx>

> Hi Johan,
> Thanks for this. It seems that we have agreement on most points.
>
> > We are not talking about cases when we talk about data element groups. We
> > are talking about metadata, that apply to ALL uses of that data element.
> > So we can have 5000 cases of malaria, from all kinds of ages and genders
> > (all of them!), but they would all share the metadata of Malaria = vector
> > borne, which has nothing to do with the individual cases.
> >
> > So DE groups are metadata. I have no idea if there is anything wrong with
> > using the same code and name for both metadata and event-data, but for me
> > they are different. If you have age as DE group set, you cannot enter
> > different ages for that data element. You will have to make another data
> > element, assigned to another group.
> >
>
> In my view of it, it is ALL  metadata about a measure, a number, or
> some other value (perhaps a true/false) that occurs. Everything else,
> orgunits, periods, data element names, data element groups,
> categories...all the dimensions that one wants to see in a PivotTable
> or filter out in a report, they are all metadata about the "data
> element"  or "measure", or in the DHIS database, i.e. what get put in
> the value.
>
> There are certain pieces of these metadata that have a one-to-one
> relationship with the value. Values can only occur at a certain point
> in time (period tells us when), at a certain place (orgunit tells us
> where) and for a certain observation (data element tells us how).
> Since we are only dealing with aggregate data, we do not care about
> the who.  We also do not really care about the exact place, the exact
> doctor that was seen, or the exact point in time. OpenMRS may, but
> DHIS2 does not. These dimensions (and all the others part of systems
> like OpenMRS, get folded into some larger dimension like "month" even
> though a particular even occurred at a given point in time.
>
> I simply cannot see the difference between a category and a data set
> .For me they are one in the same conceptually as they essentially
> assign a certain type to a number of measures Categories, Data sets,
> OrgUnits, Periods, they are all dimensions from an analysis
> perspective. Sometimes, I may want to use them, other times, I may
> want to completely fold them up and ignore them.   . Whether we need
> to semantically separate them for convenience purposes (e.g. the data
> entry screen) is fine. But when it gets to the analysis, I want to
> slice, dice and fold these different dimensions (whether they are
> called categories or data element groups make no difference). How the
> measures are grouped is simply metadata for me, which makes me feel
> that categories and data element groups are essentially the same
> beast.
>
> I think if there are "best practices" for DHIS2, as Ola mentions, then
> we need to specify them in great detail. It is obvious that you can
> use the "flat" model of DHIS 1.4 to obtain essentially the same data
> set without DHIS2 categories, albeit rather painfully. I would not
> dare to show the query that I constructed to "unfold" the dimensions
> that were inside of DHIS 1.4 data element names, but it is possible. A
> set of relations would make it a lot easier, and some Java code to
> allow me to press a button would be the icing on the cake.  Hopefully
> we are saying the same thing here.
>
> Enough email. My head hurts.
>
> JPP
>



-- 
Cheers,
Knut Staring