dhis2-devs team mailing list archive

[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