← Back to team overview

dhis2-devs team mailing list archive

Re: Dimensions and enumerated choices/values

 

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

Bob.

2009/12/8 Lars Helge Øverland <larshelge@xxxxxxxxx>

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

References