dhis2-devs team mailing list archive

[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


> 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
>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>>
>