Dimensions and enumerated choices/values

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

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@gmail.com> 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: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

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

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

···

2009/12/8 Jason Pickering jason.p.pickering@gmail.com

On Tue, Dec 8, 2009 at 1:48 PM, Knut Staring knutst@gmail.com wrote:


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@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

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.

Yes to both. We will for sure not replicate LimeSurvey, OpenXdata or CsPro, but it would be good to take some lessons from these best practicses when it comes to storage and handling.

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.

You are right, it would be boolean values. And that should allow us to also cater for multiple choice questions where more than one option can be selected.

Knut

···

On Tue, Dec 8, 2009 at 2:45 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:

2009/12/8 Jason Pickering jason.p.pickering@gmail.com

We actually have functionality which covers this partly. If you create a DataSet with one or more DataElements of Text type, then click “edit custom values” (the third icon from the left in the list) you will be able to define such dropdown values.

As Jason points out there are a few challenges with aggregating such values and we don’t have aggregation of Text data yet.

Lars

I don’t know a great deal about survey design (beyond epi-info many moons ago) but I know that a lot of work goes into coding the answers so they can be more easily analyzed afterwards. So I think I prefer an enumerated category approach to using text value types.

What is wrong with the datavalue just being a boolean (answered or not?). And the dataelement having an “answer” category with the categoryoptions representing the choice of answers? There is no need to be too literal about the datavalue meaning the value entered in the questionnaire. We tend to think of the dimensions as being attributes of the dataelement but remember this is not really accurate. The dimensions exist precisely to tell us something more about the datavalue.

I think there is a relationship with the parallel discussion on matching report/form combinations with data storage combinations.

I don’t think these UI and storage combinations should necessarily be the same thing. One can have a data storage strategy which uses “standard” dataelements and categorycombos (like for example malaria with ‘<4’, 4-10’ etc) and a form or report model which models the data differently : ‘<4’, ‘total’ etc. And then map from one to another. This might sound far fetched but I think its a basic MVC issue - well perhaps not quite basic. If you want, or need, to have a data collection strategy which emphasises “totals” for example that could be ok. But it shouldn’t necessarily mean we store them that way. The problem comes in because we are using the categorycombo as a UI layout tool for the perfectly good reason that it can be used like this. But I suspect there is a real use case for separating the two. Maybe XForms provides a clue here. With XForms we have a form model which has a one to one relationship with the elements on form. But when the user hits that submit button, or DHIS consumes that spreadsheet, we transform that form model into our dataelement model. Not this year maybe … :wink:

Bob.

···

2009/12/8 Lars Helge Øverland larshelge@gmail.com

We actually have functionality which covers this partly. If you create a DataSet with one or more DataElements of Text type, then click “edit custom values” (the third icon from the left in the list) you will be able to define such dropdown values.

As Jason points out there are a few challenges with aggregating such values and we don’t have aggregation of Text data yet.

Lars


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp