dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

Yes I also agree on the difference between DataEntry screens and the
analysis. What I wanted to say is ... we have to be very careful in defining
our input formats so that we don't face a problem during analysis. We need
to settle for some sort of atomicity in both the input form and analysis.

Our analysis shouldn't go further down to a level where we haven't captured
(or have a break up) during data collection. But we can do analysis by
aggregating/rearranging the atomic units.

I don't think we can provide district health officers

"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)." while our dataentry screen have just a single entry field
for "OPD 1st Attendance Clinical Case of Malaria Under 1"

Thank you
Abyot.

On Thu, Oct 1, 2009 at 1:13 PM, Jason Pickering <jason.p.pickering@xxxxxxxxx
> wrote:

> >
> > 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
>