[Blueprint dynamic-option-list-in-data-entry] Dynamic option list in data entry

This is a good question. Binding a set of dynamic values to one data element would be simple and nice. DHIS 1.4 is binding a set of dynamic values to a combination of data element and data set, making things even more flexible. There is probably a good reason for that. Will have to explore this further.

···

On Sat, Apr 18, 2009 at 12:37 PM, miri murodlatifov@yahoo.com wrote:

Blueprint changed by miri:

Whiteboard changed to:

What this dynamic values used for? Is this dynamic value used in more

than one dataset? If this is single time usage, we could implement it

using dataset custom form edit functionality (creating drop down with

custom values). By single I mean only one form uses this set of

predefined data values.

Dynamic option list in data entry

https://blueprints.launchpad.net/dhis2/+spec/dynamic-option-list-in-data-entry

Hi,

I don’t know much about the logic behind this, but talking on technical side of it. To have drop down on custom dataentry screen we do not need to persist any dataValueOption object and its collection. We can bind all possible values while binding dataelement combo to custom dataentry HTML, e.g. datavalue options are stored in HTML as “select bla bla bla” saved. As dataelement is related to dataset and values are available in dropdown there should not be a problem with dataset to dataelement relation. So, this means creating custom forms for such data entry is a must as datavalueoption is not persisted in database and there is no relation defined as such.
This is simple solution to make set of value options mandatory for data entry. Any other crazy and cool ideas?

regards,
murod

P.S: By the way this could be extended to persist this relation in database, but seems unnecessary.

···

From: Calle Hedberg chedberg@telkomsa.net
To: Lars Helge Øverland larshelge@gmail.com; miri murodlatifov@yahoo.com; Calle Hedberg calle.hedberg@gmail.com; DHIS 2 developers dhis2-devs@lists.launchpad.net
Cc: vshaw@hisp.org
Sent: Saturday, April 18, 2009 1:10:49 PM
Subject: Dynamic option list in data entry

Lars,

You definitely want to bind those values to a combination of
data set and data element, because different data sets will have different
scopes. This should be even more obvious when moving into survey data, where
drop-downs are a must.

Simple example:

You have two data sets related to different types of disease
notifications – let us say one is about haemorrhagic fevers (ebola, Marburg,
etc) and the other about vaccination related diseases. Both data sets are using
the data element “Diagnosis” or “Disease”, but the
possible diagnoses for each will be different. You do not want “measles”
to appear when capturing haemorrhagic fever data, and you do not want “Marburg”
to appear when you capture vaccine-related diseases.

Regards

Calle

From: Lars Helge Øverland
[mailto:larshelge@gmail.com]

Sent: 18 April 2009 12:54 PM

To: miri; Calle Hedberg; Calle Hedberg; DHIS 2 developers

Subject: Re: [Blueprint dynamic-option-list-in-data-entry] Dynamic
option list in data entry

On Sat, Apr 18, 2009 at 12:37 PM, miri murodlatifov@yahoo.com wrote:

Blueprint changed by miri:

Whiteboard changed to:

What this dynamic values used for? Is this dynamic value
used in more

than one dataset? If this is single time usage, we could implement it

using dataset custom form edit functionality (creating drop down with

custom values). By single I mean only one form uses this set of

predefined data values.

Dynamic option list in data entry

https://blueprints.launchpad.net/dhis2/+spec/dynamic-option-list-in-data-entry

This is a good question. Binding a set of dynamic values to one data element
would be simple and nice. DHIS 1.4 is binding a set of dynamic values to a
combination of data element and data set, making things even more flexible.
There is probably a good reason for that. Will have to explore this further.

Sure, makes sense, thanks for the clarification.

···

On Sat, Apr 18, 2009 at 1:10 PM, Calle Hedberg chedberg@telkomsa.net wrote:

Lars,

You definitely want to bind those values to a combination of data set and data element, because different data sets will have different scopes. This should be even more obvious when moving into survey data, where drop-downs are a must.

Simple example:

You have two data sets related to different types of disease notifications – let us say one is about haemorrhagic fevers (ebola, Marburg, etc) and the other about vaccination related diseases. Both data sets are using the data element “Diagnosis” or “Disease”, but the possible diagnoses for each will be different. You do not want “measles” to appear when capturing haemorrhagic fever data, and you do not want “Marburg” to appear when you capture vaccine-related diseases.

Hi,

i see your point in that this would be easy and it would probably work. But it sounds a little static to me. Wouldn’t we want to have some pre-defined and re-usable comments?

Also, we definitely should have this for regular and multidimensional data entry as well. I guess it is needed and otherwise we are making things inconsistent…

···

On Sat, Apr 18, 2009 at 1:38 PM, Murodullo Latifov murodlatifov@yahoo.com wrote:

Hi,

I don’t know much about the logic behind this, but talking on technical side of it. To have drop down on custom dataentry screen we do not need to persist any dataValueOption object and its collection. We can bind all possible values while binding dataelement combo to custom dataentry HTML, e.g. datavalue options are stored in HTML as “select bla bla bla” saved. As dataelement is related to dataset and values are available in dropdown there should not be a problem with dataset to dataelement relation. So, this means creating custom forms for such data entry is a must as datavalueoption is not persisted in database and there is no relation defined as such.

This is simple solution to make set of value options mandatory for data entry. Any other crazy and cool ideas?

Hi,

i see your point in that this would be easy and it would probably work. But it sounds a little static to me. Wouldn’t we want to have some pre-defined and re-usable comments?

Also, we definitely should have this for regular and multidimensional data entry as well. I guess it is needed and otherwise we are making things inconsistent…

Hi,

regular and multidimentional data entry is already inconsistent with custom data entry. If custom data entry has dataset consisting two different set of dataelement comboid combinations it will show only the first dataelement comboid combination, not the rest. Maybe my installation does not this.
Comments for my opinion should not be predefined, user should have freedom to fill in what he wants to comment. what if his desire is not listed on predefined options?

Hi,

i see your point in that this would be easy and it would probably work. But it sounds a little static to me. Wouldn’t we want to have some pre-defined and re-usable comments?

Also, we definitely should have this for regular and multidimensional data entry as well. I guess it is needed and otherwise we are making things inconsistent…

Hi,

regular and multidimentional data entry is already inconsistent with custom data entry. If custom data entry has dataset consisting two different set of dataelement comboid combinations it will show only the first dataelement comboid combination, not the rest.

I guess you mean two different set of dataelement category combo. You cannot have more than one category combo for data elements in a multidimensional data entry form (unless you use the sections but I have never seen that work). Anyway I don’t see why this is an argument to make things even more inconsistent. This thing will also be used for the survey functionality we are planning to make.

Maybe my installation does not this.
Comments for my opinion should not be predefined, user should have freedom to fill in what he wants to comment. what if his desire is not listed on predefined options?

Sorry, I didn’t mean predefined in terms of hard-coded. Poor wording on my side. I meant that we should have a GUI where we enter and persist comments, and then re-use these for all forms.

I am little unsure of what you mean here. Do you mean the user should type in the options directly when he designs the form?

I do agree that we could embed the options in the html form for cde. This sounds like a good idea. But we could still have user-defined, persisted options attached to a data element - data set combo. This would then be automated for the multidimensional data entry form.

···

2009/4/18 Murodullo Latifov murodlatifov@yahoo.com

best regards,
Ola Hodne Titlestad
HISP
University of Oslo

···

2009/4/18 Lars Helge Øverland larshelge@gmail.com

2009/4/18 Murodullo Latifov murodlatifov@yahoo.com

Hi,

i see your point in that this would be easy and it would probably work. But it sounds a little static to me. Wouldn’t we want to have some pre-defined and re-usable comments?

Also, we definitely should have this for regular and multidimensional data entry as well. I guess it is needed and otherwise we are making things inconsistent…

Hi,

regular and multidimentional data entry is already inconsistent with custom data entry. If custom data entry has dataset consisting two different set of dataelement comboid combinations it will show only the first dataelement comboid combination, not the rest.

I guess you mean two different set of dataelement category combo. You cannot have more than one category combo for data elements in a multidimensional data entry form (unless you use the sections but I have never seen that work). Anyway I don’t see why this is an argument to make things even more inconsistent. This thing will also be used for the survey functionality we are planning to make.

Maybe my installation does not this.
Comments for my opinion should not be predefined, user should have freedom to fill in what he wants to comment. what if his desire is not listed on predefined options?

Sorry, I didn’t mean predefined in terms of hard-coded. Poor wording on my side. I meant that we should have a GUI where we enter and persist comments, and then re-use these for all forms.

I am little unsure of what you mean here. Do you mean the user should type in the options directly when he designs the form?

I do agree that we could embed the options in the html form for cde. This sounds like a good idea. But we could still have user-defined, persisted options attached to a data element - data set combo. This would then be automated for the multidimensional data entry form.


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

Just a quick comment.

The option list for data element+dataset combo will in the future also most likely be needed in other use cases in addition to data entry so there is a need to persist these in the model.

E.g. if you want to define some aggregation (e.g. from case based to routine data) or validation, triggers etc. you will need to have these options available when defining the rules, E.g.
if data element “Diagnosis” = ‘Malaria’ then … do_something_. Filling such rules without having the possible options available is error-prone and tedious work.

Ola