dhis2-devs team mailing list archive

[johansa@xxxxxxxxxx]

> 2009/10/1 Knut Staring <knutst@xxxxxxxxx>
>
>> On Thu, Oct 1, 2009 at 5:16 PM, <johansa@xxxxxxxxxx> wrote:
>>
>>> > Here is my suggestion, based on all the mails above, so that we can
>>> > develop all of this into a blueprint/specification.
>>> >
>>> > 1) Categories and category options should be left essentially as is.
>>> > 2) Data element groups sets should allow data elements to be assigned
>>> > to multiple data element groups. Data elements (both
>>> multi-dimensional
>>> > and non-multidimensional) should be able to be assigned a particular
>>> > (only one)  data element groups.
>>> > 3) A data element group set  would be something like "Age", "Sex",
>>> > "Disease transmission method". Each data element group set would
>>> would
>>> > contain multiple data element groups, such as "Under 1, Under 5, Over
>>> > 5", "Male, Female", "Vector borne, water borne".
>>>
>>> No. "Malaria" cannot be male or female. Diarrhoea cannot be 15 years
>>> old.
>>> But a person with malaria can be male or female, and a 15 year old
>>> person
>>> can have diarrhoea.
>>>
>>> The data element groups and group sets are metadata. The categories are
>>> event-specific data.
>>>
>>>
> In an ideal world we should be consistent on how we use categories and
> groups, I agree. And I tried to put forward some best practices using
> Jason's example earlier today. But there is nothing wrong with adding
> group
> sets like Age or Gender, I mean it doesn't break anything right? In the
> pivot table it will just be another column describing the data, and you
> can
> choose whether to use it or not, and whether to create it in the first
> place
> or not.  In Jason's case and in any other country where 1.4 is the data
> collection tool at the lower levels, the categories cannot be used (and
> all
> data elements are flat) so all dimensionality will have to come from these
> group sets and groups. That is why they have to break with the DHIS 2 best
> practise.
>
> Ola
> ---------
>

No, it's nothing wrong with doing it that way. But if you use DE groups to
differ on gender, you would have to make two data elements, Disease Male,
Disease Female, and assign them to each their group. When you have tables
with many columns, and many data elements, it pays off to do it the
category way.

Johan

>
>
>>
>> Not sure what you are trying to say here. We are of course always
>> talking
>> about number of cases, even though we do not specify "Cases of Malaria"?
>>
>>
>>
>>> Johan
>>>
>>> > 4) Data element groups sets should be exclusive. Data element groups
>>> > can only belong to one data element group set.
>>> > 3) Multidimensional elements will automatically be imparted an
>>> > intrinsic level of dimensionality via the Categories, ipso facto.
>>> > Category options would essentially be transformed to a data element
>>> > group at the stage of analysis.
>>> > 4) Non-multidimensional elements should be able to be assigned a
>>> > particular member of a CateogryOption,  post facto, so that
>>> > multi-dimensional and non-multidimensional elements would be able to
>>> > coexist peacefully.
>>> > 5) A particular measure's full dimensionality would result from the
>>> > combination of  prime dimensions:
>>> >    a) OrgUnitGroupSets (already implemeneted). Each OrgUnitGroupSet
>>> > would impart a column in a cross-tab query for each OrgUnitGroupSet,
>>> > providing classification by Type, Urban Rural, Ownership as examples.
>>> >    b) Period. There is no currently (as far as I know)
>>> > PeriodGroupSets, but usually, grouping can take place through the
>>> data
>>> > type itself, so that values can be grouped into quaters, bi-monthly
>>> > groups, etc. Period would impart a two columns in a cross-tab query
>>> > (StartDate and EndDate).
>>> >    c) The resulting number of dimensions resulting from the data
>>> > elements assignment of the data element to "Categories" and
>>> > "DataElementGroupSets".Each Category and each DateElementGroup
>>> > assigned to the data element would impart a single column in a
>>> > crosstab query.
>>> > d) Other dimensions that are already implemeneted, such as Dataset.
>>> >
>>> > Do these points capture the  requirements, based on everything we
>>> have
>>> > discussed in this monster thread?
>>> >
>>> >  Plese feel free to comment, especially the developers. Lars has been
>>> > quiet and said it is possible, so I suppose he is just coding
>>> already.
>>> > :)
>>> >
>>> > _______________________________________________
>>> > 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
>>>
>>
>>
>>
>> --
>> Cheers,
>> Knut Staring
>>
>> _______________________________________________
>> 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
>>
>>
>