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