dhis2-devs team mailing list archive

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

Hi Knut,

I think it is a very good idea, and concur that it should at least in
theory, be another dimension to the actual value, with potentially
special methods and properties. I could envision such a value being
stored as an integer (as is usually the case for enumerated values)
but what would be presented to the user would actually be the
enumerated reference. The data value itself would need to be tied to
an Enumerated lists dimension, similar to how they are tied to an
orgunitid currently. The orgunitID itself is stored in the database,
but the orgunit name is presented to the user. Again, this highlights
the fact that there are essentially no end to the number and type of
dimensions that a particular data element may have, but the question
is which ones should be implemented in DHIS2.

I think this links to some degree to the other discussion we have been
having with the Viet Nam team. I could imagine a "category" combo
being used to create a range of data elements, which might be
enumerated lists. In this case, there would be no total, and no
implicit internal aggregation rules or relationships between the
different category elements. The category combos would be very useful
for creating the sorts of tables that you often see in surveys, but
not if they assume that you collect all the parts, and they add up to
a total.

However, before we jump into that, I think revisiting the use of
something like LimeSurvey, which is pretty darned good and free, for
such surveys, is not a bad idea.

Regards,
JPP





On Tue, Dec 8, 2009 at 1:48 PM, Knut Staring <knutst@xxxxxxxxx> wrote:
> In the context of storing data from survey questionnaires such as health
> facility Service Availability Mapping, a common occurrence is "dropdown
> questions", i.e. where the answer is selected from a predefined list of
> options (enumerations). It occurred to me that this is a bit like custom
> dimensions - and survey data are often analysed/broken down according to
> such responses.
> It would seem helpful to handle this as part of our overall rethinking of
> dimensionality (where "data element" is in fact just one "privileged",
> compulsory dimension out of many possible ones, though we typically tend to
> think of it as "disease"). The problem I guess is that with such choice
> questions, there is not really a datavalue - i.e. the dimension option
> becomes the datavalue to be stored.
> Or am I way out in the left field here?
> I suppose we would have a problem with the "Other" option, which is usually
> accompanied by a free text field in a survey...
> Knut
> _______________________________________________
> 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
>
>