dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olatitle@xxxxxxxxx>]

2009/10/1 <johansa@xxxxxxxxxx>

> Don't trust people from WHO :) You might even encounter a militant
> gender-health specialist, who will say that ALL diseases must be split
> into genders, and this ratio is the centre of the universe (I'm not
> kidding, I met one in Botswana). That is not to say that your examples are
> not valid, they do make sense. But this is perfectly possible with the
> current design, as far as my experience is. My point is that I can easily
> come up with some examples that would require a different data model, but
> that would not make sense.
>
> Vector-borne diseases can be a DE group. If data elements have a category
> inpatient/outpatient, you can easily get only outpatient data from the
> pivot table (or, as many other countries: have two headcount elements for
> each form: Total inpatients, Total outpatients). Communicable and
> non-communicable diseases can also be an DE group, and if you don't want
> DEs to belong to two groups, you can lump them together with a query or in
> the pivot table. I think some countries, and some specialists (which are
> often too interested in details in their field) have some requirements
> which are not "one-click-at-a-button"-ready, but that this can always be
> solved with categories and DE groups in the pivot tables. My input to
> this, in sum: I've not yet encountered any requirements (with DHIS2: in
> Tajikistan and Sierra Leone) that could not be solved with
> categoryoptions, categories, categorycombos, DE groups, and Org.Unit
> groups (rural/urban, private/public, type of clinic), and combinations of
> data (indicators, or Diarrhoea and Safe Water crossexamined, for example).
> Johan
>
>
Agree that we need to keep it simple and focus on the 80% of the use cases.

I would still say that having data element group sets would simplify a lot
when setting up pivot tables.
The restriction on only one group per data element does not makes sense. I
remember it was allowed to assign multiple groups in the early days of 1.4,
and that was based on real needs. What happened is that there was a design
flaw that lead to duplication in the pivot tables due to multiple rows per
data element,orgunit, period (one per group). For orgunit groups this is
taken care of by having group sets such as OrgUnitType, RuralUrban etc. and
that is what we need for data elements and indicators as well.

And, I would also add that simplifying the multidimensional data element
approach from a user perspective would really improve the usability of DHIS
2. That goes for both creating dimensions and assigning them to data
elements, and to be able to use these dimensions in reports. Being able to
tweak the system to get want you want is not good enough in the long run,
these things should we delivered to the users out of the box.

Ola
---------



>
> > Hi Johan,
> > They are definetely real, at least. It does not mean they are
> > elsewhere. But the examples I just provided have come from data review
> > and analysis workshops conducted in the field here, which are a
> > primary means of district health officers being able to conduct
> > planning and performance review. They need to know what the total
> > number of outpatient attendances are, regardless of disease, so they
> > can plan staffing levels. They need to know prevalence of vector borne
> > diseases to plan spraying campaigns and bed-net campaigns. I did not
> > come up with these examples trivially, but have heard this time and
> > time again from the DHIOs here.
> >
> > But I do not agree with you about your last point. Looking at
> > prevalence of communicable versus non-communicable disease incidence
> > is important, at least this is what people at WHO have told me.
> > Perhaps it is not, but I see no reason to doubt. I agree, there are
> > infinite possibilities, and that is the point of a PivotTable. The
> > system should enable the analysis in such as way as makes sense to the
> > people using the data.
> >
> > I am not trying to be academic at all , but am rather trying to
> > distill into code, functionality and specifications what the
> > requirements from this country are. Perhaps they are not applicable
> > elsewhere, in which case, we need to decide whether it is something
> > general that should be implemented in the main branch, or specific and
> > should be implemented here only.
> >
> > Regards,
> > Jason
> >
> >
> >
> > On Thu, Oct 1, 2009 at 2:12 PM,  <johansa@xxxxxxxxxx> wrote:
> >> A general comment to this:
> >>
> >> Are the scenarios provided in this thread really a requested
> >> functionality? I can see that it's possible to come up with an infinite
> >> number of possible ways to look at data, but to look at "all
> >> communicable
> >> diseases", is something you don't do that often, I believe. Unless of
> >> course, you want some useless data. The few times you want it, you can
> >> combine the DE groups "vector-borne", "sexually transmitted" etc.. in
> >> pivots or with SQL.
> >>
> >> The design principle should be needs-focused, not possible-focused,
> >> though
> >> I sense there are great discussions to be had regarding database design
> >> and good coding etc. But be careful about creating a demand that does
> >> not
> >> exist.
> >>
> >>>> 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"
> >>>
> >>> Yes, we cannot, at least not reverting to dodgy SQL and naming
> >>> conventions to unravel the "dimensions" that are hiding inside of
> >>> names. Granted, the cateogry combos can help, but they do not go far
> >>> enough. But we do need to figure out how we can do this.
> >>>
> >>> I am attaching a few files, My apologies for this, but they are quite
> >>> small. I have attached a sample data entry form, which is used at the
> >>> facility level. You can see, this mirrors many of my examples
> >>> throughout this thread.
> >>>
> >>> I have also included in this file, a PivotTable, that I created to
> >>> answer the question above. It is not complete, but it does seperate
> >>> OPD. IP and deaths into seperate columns. I have scrambled the data
> >>> with random values, but have left values that were "blank" from the
> >>> data entry ,but showed up in the query.
> >>>
> >>> Now, I should be able to do this table by using category combos I
> >>> guess pretty easy. What I cannot do is then to aggregate by dimensions
> >>> that are not present in the category combos themselves, at least, but
> >>> I guess this is the functionality that Ola describes.
> >>>
> >>> Hope these two examples may help to make this a bit more concrete.
> >>>
> >>> Regards,
> >>> Jason
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> >>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> >>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >>
> >>
> >>
> >
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> More help   : https://help.launchpad.net/ListHelp
>