dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olatitle@xxxxxxxxx>]

2009/12/8 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.
>
>
For sure, I agree that there are other and better tools out there for
conducting surveys. Still need to deal with storage of the survey data or at
leasts parts of it, in order to be able to analyse it and to correlate with
service-routine data.




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

Not really. If the data element is a boolean then the "data element + the
category option combo" will have a Yes or No value.
The data entry form should be able to assign the Yes value to the selected
options somehow.

Ola
------


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