dhis2-devs team mailing list archive

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

>
> but in the end getting confused which one is the dataelement which one is
> the dimension. Well the MD model can handle such a breakup I guess but the
> point is not that.
>

Well me too, and that is why I started all of this. My data entry
screen (e.g. a paper form, collect
OPD 1st Attendance Clinical Case of Malaria Under 1

with different patient status (OPD, IP, Deaths), different classes of
diagnosis (Confirmed, Clinical) and different age groups.

However, in the end what the district health officers want to know is
as follows:

How many cases of OPD, IP and Deaths of Malaria have their been, with
possible slices of those dimensions (by age, comparing clinical and
confirmed etc). By defining appropriate categories, I can see now how
I can possible get this through a a DHIS report table, the datamart,
or some other custom SQL query.

But, the problem arises when there is some higher order
dimensionality, that has not been defined in the categories. Such as,

All cases of vector-borne diseases

This category was not part of my original categories and might include
(as I stated in my example) Malaria, Leishmaniasis, Dengue, etc
aggregated together. If I wanted to get this, I suppose I could create
a data element group for this. But what happens when I need more than
one data element group, such as Communicable diseases, which might
include vector borne, water borne, etc.


> The point is, what users should do is I guess to first define what they need
> from that functionality - what kind of data are they going to collect? what
> does their dataentry screen look like?

No, I totally disagree. For me the data entry screen is only a
necessary artifact to answer the questions that need to. How many
cases of under 1 clinical malaria have we had? What is the case
fataility ratio for confirmed malaria cases? There are so many
possibilities.

> But how different
> is the analysis going to be from our input formats?

Very. I think I have given enough examples to support this.

> Anyways for me a dimension is just an attribute to a dataelement. So before
> talking about a dimension first we need to have a dataelement and
> (logically) we can't mix the two!

I completely agree with you, and this is why I am not comfortable with
the current implementation. Dimensions are simply additional metadata
added to a given observation, or measure. If you take a look at the
OpenHealth data models, a measure has dimensions. DHIS appears to be
built around three compulsory dimensions, which all measures should
have: 1)  What: Data element, which is essentially a description of
what the observation can be classified as 2) When: A point in time
(period) 3) Where: An organizational unit, or place. All other
dimensions are simply bling that need to be added for the purpose of
analysis. However the current model has to some degree mixed up data
entry with analysis, and thus the conundrum that I find myself in.

Regards,
Jason