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 <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~dhis2-devs > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
