Multi-select dropdown or multi-select checkbox in tracker capture forms


(Arun Paul) #1

Hello everyone,

I am configuring a program using Tracker Capture. It requires data input using a multi-select dropdown or multi-select checkbox. Example for such a field is “Symptoms” or “Drugs given for treatment”. For these fields, I need to select more than one option as answers.

Is this UI component already supported?

Else, how can I support this through some work around or code-customization ?

Please let me know.

···

​Thanks in advance

,

  • Arun Paul

(Prosper) #2

Dear Paul,

Thanks for sharing this, its some blue print being discussed not yet implemented, we hope it can come soon especially for IDSR - symptoms. The work around right now is to design all the different options are either attributes or data elements depending on where they are going to be used with data type Yes Only

···

​Or if you are using a custom form, you can implement it your way

Regards

On Wed, Sep 28, 2016 at 1:24 PM, Arun Paul paul.arun@gmail.com wrote:

Hello everyone,

I am configuring a program using Tracker Capture. It requires data input using a multi-select dropdown or multi-select checkbox. Example for such a field is “Symptoms” or “Drugs given for treatment”. For these fields, I need to select more than one option as answers.

Is this UI component already supported?

Else, how can I support this through some work around or code-customization ?

Please let me know.

​Thanks in advance

,

  • Arun Paul

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

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

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

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


Prosper Behumbiize, MPH
Global DHIS2 Implementation| HISP Uganda/University Of Oslo
+256 752 751 776 | +256 776 139 139

prosper@hispuganda.org | prosper@dhis2.org | Skype: prospertb


(Jason Pickering) #3

The reason is has to be separate data elements is because of analytics. If you have a single data element with multiple choices, there is currently not a way to aggregate all of these. So lets say you have a question like

What symptoms does the patient have?

a) Headache

b) Fever

c) Fatigue

If there was some sort of UI component like you are talking about with a single data element, we would need to record something like

Headache; Fever; Fatigue

in a single row in the database. When we aggregate it, well, it would not be really clear how we would do this. We would need to parse out all of the options and then somehow transform them into

Headache = 2

Fever = 4

Fatigue = 5

The of course you have more complicated situations like patients who have both Fever and Fatigue.

So, the way it has to be implemented now in DHIS2, is through a boolean data element.

Does the patient have a headache?

Does the patient have a fever?

Does the patient have fatigue?

Aggregation becomes just a matter of counting how many of these are true.

So, you could implement some sort of custom control do to this, but in the end, you would need completely separate data elements, but maybe this was not really your question, since you were asking about a UI component?

Currently, its not there, but has been asked for several times.

Regards,

Jason

···

On Wed, Sep 28, 2016 at 1:00 PM, Prosper BT ptb3000@gmail.com wrote:

Dear Paul,

Thanks for sharing this, its some blue print being discussed not yet implemented, we hope it can come soon especially for IDSR - symptoms. The work around right now is to design all the different options are either attributes or data elements depending on where they are going to be used with data type Yes Only


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

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

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

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

​Or if you are using a custom form, you can implement it your way

Regards

On Wed, Sep 28, 2016 at 1:24 PM, Arun Paul paul.arun@gmail.com wrote:

Hello everyone,

I am configuring a program using Tracker Capture. It requires data input using a multi-select dropdown or multi-select checkbox. Example for such a field is “Symptoms” or “Drugs given for treatment”. For these fields, I need to select more than one option as answers.

Is this UI component already supported?

Else, how can I support this through some work around or code-customization ?

Please let me know.

​Thanks in advance

,

  • Arun Paul

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

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

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

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

Prosper Behumbiize, MPH
Global DHIS2 Implementation| HISP Uganda/University Of Oslo
+256 752 751 776 | +256 776 139 139

prosper@hispuganda.org | prosper@dhis2.org | Skype: prospertb

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049


(Alex Tumwesigye) #4

Jason and Prosper,

Thanks for sharing the idea of how it can be implemented. However, this works for a few options. In IDSR implementation I have encountered more than 30 symptoms. I think, we need to figure out how this can be achieved.

Thanks.

Alex

···

On Wed, Sep 28, 2016 at 3:00 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

The reason is has to be separate data elements is because of analytics. If you have a single data element with multiple choices, there is currently not a way to aggregate all of these. So lets say you have a question like

What symptoms does the patient have?

a) Headache

b) Fever

c) Fatigue

If there was some sort of UI component like you are talking about with a single data element, we would need to record something like

Headache; Fever; Fatigue

in a single row in the database. When we aggregate it, well, it would not be really clear how we would do this. We would need to parse out all of the options and then somehow transform them into

Headache = 2

Fever = 4

Fatigue = 5

The of course you have more complicated situations like patients who have both Fever and Fatigue.

So, the way it has to be implemented now in DHIS2, is through a boolean data element.

Does the patient have a headache?

Does the patient have a fever?

Does the patient have fatigue?

Aggregation becomes just a matter of counting how many of these are true.

So, you could implement some sort of custom control do to this, but in the end, you would need completely separate data elements, but maybe this was not really your question, since you were asking about a UI component?

Currently, its not there, but has been asked for several times.

Regards,

Jason


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

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

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

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

On Wed, Sep 28, 2016 at 1:00 PM, Prosper BT ptb3000@gmail.com wrote:

Dear Paul,

Thanks for sharing this, its some blue print being discussed not yet implemented, we hope it can come soon especially for IDSR - symptoms. The work around right now is to design all the different options are either attributes or data elements depending on where they are going to be used with data type Yes Only


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

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

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

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

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

​Or if you are using a custom form, you can implement it your way

Regards

On Wed, Sep 28, 2016 at 1:24 PM, Arun Paul paul.arun@gmail.com wrote:

Hello everyone,

I am configuring a program using Tracker Capture. It requires data input using a multi-select dropdown or multi-select checkbox. Example for such a field is “Symptoms” or “Drugs given for treatment”. For these fields, I need to select more than one option as answers.

Is this UI component already supported?

Else, how can I support this through some work around or code-customization ?

Please let me know.

​Thanks in advance

,

  • Arun Paul

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

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

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

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

Prosper Behumbiize, MPH
Global DHIS2 Implementation| HISP Uganda/University Of Oslo
+256 752 751 776 | +256 776 139 139

prosper@hispuganda.org | prosper@dhis2.org | Skype: prospertb

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET | HISP Uganda

Kampala

Uganda
+256 774149 775, + 256 759 800161

Skype ID: talexie

IT Consultant (Servers, Networks and Security, Health Information Systems - DHIS2, Disease Outbreak & Surveillance Systems) & Solar Consultant

"I don’t want to be anything other than what I have been - one tree hill "


(Knut Staring) #5

Alex, are you just saying you need a different GUI widget (e.g. a dropdown which allows for multi-select) or do you also want to store this differently in the data model?

I suppose you are in some ways asking for an option set which you can select multiple options, but when it comes to the storage, I think Jason’s point about the analytics is fundamental here. In order to make use of these data, it needs to come down to individual data elements behind the scenes (in the model (I don’t attributes would work so well, for the same reason).

Knut

···

On Wed, Sep 28, 2016 at 2:34 PM, Alex Tumwesigye atumwesigye@gmail.com wrote:

Jason and Prosper,

Thanks for sharing the idea of how it can be implemented. However, this works for a few options. In IDSR implementation I have encountered more than 30 symptoms. I think, we need to figure out how this can be achieved.

Thanks.

Alex


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

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

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

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


Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

On Wed, Sep 28, 2016 at 3:00 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

The reason is has to be separate data elements is because of analytics. If you have a single data element with multiple choices, there is currently not a way to aggregate all of these. So lets say you have a question like

What symptoms does the patient have?

a) Headache

b) Fever

c) Fatigue

If there was some sort of UI component like you are talking about with a single data element, we would need to record something like

Headache; Fever; Fatigue

in a single row in the database. When we aggregate it, well, it would not be really clear how we would do this. We would need to parse out all of the options and then somehow transform them into

Headache = 2

Fever = 4

Fatigue = 5

The of course you have more complicated situations like patients who have both Fever and Fatigue.

So, the way it has to be implemented now in DHIS2, is through a boolean data element.

Does the patient have a headache?

Does the patient have a fever?

Does the patient have fatigue?

Aggregation becomes just a matter of counting how many of these are true.

So, you could implement some sort of custom control do to this, but in the end, you would need completely separate data elements, but maybe this was not really your question, since you were asking about a UI component?

Currently, its not there, but has been asked for several times.

Regards,

Jason


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

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

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

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

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET | HISP Uganda

Kampala

Uganda
+256 774149 775, + 256 759 800161

Skype ID: talexie

IT Consultant (Servers, Networks and Security, Health Information Systems - DHIS2, Disease Outbreak & Surveillance Systems) & Solar Consultant

"I don’t want to be anything other than what I have been - one tree hill "

On Wed, Sep 28, 2016 at 1:00 PM, Prosper BT ptb3000@gmail.com wrote:

Dear Paul,

Thanks for sharing this, its some blue print being discussed not yet implemented, we hope it can come soon especially for IDSR - symptoms. The work around right now is to design all the different options are either attributes or data elements depending on where they are going to be used with data type Yes Only


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

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

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

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

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

​Or if you are using a custom form, you can implement it your way

Regards

On Wed, Sep 28, 2016 at 1:24 PM, Arun Paul paul.arun@gmail.com wrote:

Hello everyone,

I am configuring a program using Tracker Capture. It requires data input using a multi-select dropdown or multi-select checkbox. Example for such a field is “Symptoms” or “Drugs given for treatment”. For these fields, I need to select more than one option as answers.

Is this UI component already supported?

Else, how can I support this through some work around or code-customization ?

Please let me know.

​Thanks in advance

,

  • Arun Paul

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

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

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

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

Prosper Behumbiize, MPH
Global DHIS2 Implementation| HISP Uganda/University Of Oslo
+256 752 751 776 | +256 776 139 139

prosper@hispuganda.org | prosper@dhis2.org | Skype: prospertb


(Jason Pickering) #6

I think that this should be able to be solved with a custom UI component, potentially using a data element group (or attribute) to group a range of boolean data elements. So, although it would appear to the user that they are ticking multiple boxes in a drop down, what actually gets stored in the database would be multiple boolean true/false values for each individual option in the drop down.

I see no real easy way around the analytics, as values are stored as text and creating some kind of custom data value type and parsing out options would seem to be very intrusive and complicated.

Regards,

Jason

···

On Wed, Sep 28, 2016 at 2:34 PM, Alex Tumwesigye atumwesigye@gmail.com wrote:

Jason and Prosper,

Thanks for sharing the idea of how it can be implemented. However, this works for a few options. In IDSR implementation I have encountered more than 30 symptoms. I think, we need to figure out how this can be achieved.

Thanks.

Alex

On Wed, Sep 28, 2016 at 3:00 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

The reason is has to be separate data elements is because of analytics. If you have a single data element with multiple choices, there is currently not a way to aggregate all of these. So lets say you have a question like

What symptoms does the patient have?

a) Headache

b) Fever

c) Fatigue

If there was some sort of UI component like you are talking about with a single data element, we would need to record something like

Headache; Fever; Fatigue

in a single row in the database. When we aggregate it, well, it would not be really clear how we would do this. We would need to parse out all of the options and then somehow transform them into

Headache = 2

Fever = 4

Fatigue = 5

The of course you have more complicated situations like patients who have both Fever and Fatigue.

So, the way it has to be implemented now in DHIS2, is through a boolean data element.

Does the patient have a headache?

Does the patient have a fever?

Does the patient have fatigue?

Aggregation becomes just a matter of counting how many of these are true.

So, you could implement some sort of custom control do to this, but in the end, you would need completely separate data elements, but maybe this was not really your question, since you were asking about a UI component?

Currently, its not there, but has been asked for several times.

Regards,

Jason


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

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

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

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

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET | HISP Uganda

Kampala

Uganda
+256 774149 775, + 256 759 800161

Skype ID: talexie

IT Consultant (Servers, Networks and Security, Health Information Systems - DHIS2, Disease Outbreak & Surveillance Systems) & Solar Consultant

"I don’t want to be anything other than what I have been - one tree hill "

On Wed, Sep 28, 2016 at 1:00 PM, Prosper BT ptb3000@gmail.com wrote:

Dear Paul,

Thanks for sharing this, its some blue print being discussed not yet implemented, we hope it can come soon especially for IDSR - symptoms. The work around right now is to design all the different options are either attributes or data elements depending on where they are going to be used with data type Yes Only


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

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

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

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

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

​Or if you are using a custom form, you can implement it your way

Regards

On Wed, Sep 28, 2016 at 1:24 PM, Arun Paul paul.arun@gmail.com wrote:

Hello everyone,

I am configuring a program using Tracker Capture. It requires data input using a multi-select dropdown or multi-select checkbox. Example for such a field is “Symptoms” or “Drugs given for treatment”. For these fields, I need to select more than one option as answers.

Is this UI component already supported?

Else, how can I support this through some work around or code-customization ?

Please let me know.

​Thanks in advance

,

  • Arun Paul

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

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

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

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

Prosper Behumbiize, MPH
Global DHIS2 Implementation| HISP Uganda/University Of Oslo
+256 752 751 776 | +256 776 139 139

prosper@hispuganda.org | prosper@dhis2.org | Skype: prospertb

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049


(Calle Hedberg) #7

Hi

As both Prosper and Jason have confirmed, currently you have to use separate data elements or attributes. This might be inconvenient, in particular where the list of e.g. symptoms are long.

I can see two scenarios here:

There might not be much demand for analysing this type of data at all - might be mainly descriptive data for use by e.g. clinicians (one could argue that counting symptoms occurrences across many diseases don’t provide much of value, at least not on a regular reporting basis). The data element or attribute are then basically a free text field but with such “free” text either limited only to an option set or an option set + free text.

alternatively, you could do aggregated analysis by executing a count of all cases where symptoms LIKE ‘%Headache%’ (or any combination of such symptom “tags”) - again not currently supported I think but not complicated either.

I think we need more specific requirements and requirement scenarios here, to determine the design of such enhancements.

Regards

calle

···

On 28 September 2016 at 14:00, Jason Pickering jason.p.pickering@gmail.com wrote:

The reason is has to be separate data elements is because of analytics. If you have a single data element with multiple choices, there is currently not a way to aggregate all of these. So lets say you have a question like

What symptoms does the patient have?

a) Headache

b) Fever

c) Fatigue

If there was some sort of UI component like you are talking about with a single data element, we would need to record something like

Headache; Fever; Fatigue

in a single row in the database. When we aggregate it, well, it would not be really clear how we would do this. We would need to parse out all of the options and then somehow transform them into

Headache = 2

Fever = 4

Fatigue = 5

The of course you have more complicated situations like patients who have both Fever and Fatigue.

So, the way it has to be implemented now in DHIS2, is through a boolean data element.

Does the patient have a headache?

Does the patient have a fever?

Does the patient have fatigue?

Aggregation becomes just a matter of counting how many of these are true.

So, you could implement some sort of custom control do to this, but in the end, you would need completely separate data elements, but maybe this was not really your question, since you were asking about a UI component?

Currently, its not there, but has been asked for several times.

Regards,

Jason


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

On Wed, Sep 28, 2016 at 1:00 PM, Prosper BT ptb3000@gmail.com wrote:

Dear Paul,

Thanks for sharing this, its some blue print being discussed not yet implemented, we hope it can come soon especially for IDSR - symptoms. The work around right now is to design all the different options are either attributes or data elements depending on where they are going to be used with data type Yes Only


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

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

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

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

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

​Or if you are using a custom form, you can implement it your way

Regards

On Wed, Sep 28, 2016 at 1:24 PM, Arun Paul paul.arun@gmail.com wrote:

Hello everyone,

I am configuring a program using Tracker Capture. It requires data input using a multi-select dropdown or multi-select checkbox. Example for such a field is “Symptoms” or “Drugs given for treatment”. For these fields, I need to select more than one option as answers.

Is this UI component already supported?

Else, how can I support this through some work around or code-customization ?

Please let me know.

​Thanks in advance

,

  • Arun Paul

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

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

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

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

Prosper Behumbiize, MPH
Global DHIS2 Implementation| HISP Uganda/University Of Oslo
+256 752 751 776 | +256 776 139 139

prosper@hispuganda.org | prosper@dhis2.org | Skype: prospertb


Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19119

Email: calle.hedberg@gmail.com

Skype: calle_hedberg



(Calle Hedberg) #8

Alex,

You might have considerably more than 30 symptoms - it all depends on how “specialised” you want them (re ICD-9 used to be around 10,000 codes - now I believe ICD-10 have something like 60-70,000…).

The same logic applies to treatments - assuming 30-100 notifiable diseases being tracked, you might have a few hundred treatment options…

I think we need to unpack the main USAGE scenarios for this type of data - are we looking for analytics results, or will the data mainly be used to provide a “rich picture” for e.g. clinicians, lab engineers, surveillance officers, or various specialists to determine e.g. what lab tests to run or what public health actions to take?

Regards

Calle

···

On 28 September 2016 at 14:34, Alex Tumwesigye atumwesigye@gmail.com wrote:

Jason and Prosper,

Thanks for sharing the idea of how it can be implemented. However, this works for a few options. In IDSR implementation I have encountered more than 30 symptoms. I think, we need to figure out how this can be achieved.

Thanks.

Alex


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

On Wed, Sep 28, 2016 at 3:00 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

The reason is has to be separate data elements is because of analytics. If you have a single data element with multiple choices, there is currently not a way to aggregate all of these. So lets say you have a question like

What symptoms does the patient have?

a) Headache

b) Fever

c) Fatigue

If there was some sort of UI component like you are talking about with a single data element, we would need to record something like

Headache; Fever; Fatigue

in a single row in the database. When we aggregate it, well, it would not be really clear how we would do this. We would need to parse out all of the options and then somehow transform them into

Headache = 2

Fever = 4

Fatigue = 5

The of course you have more complicated situations like patients who have both Fever and Fatigue.

So, the way it has to be implemented now in DHIS2, is through a boolean data element.

Does the patient have a headache?

Does the patient have a fever?

Does the patient have fatigue?

Aggregation becomes just a matter of counting how many of these are true.

So, you could implement some sort of custom control do to this, but in the end, you would need completely separate data elements, but maybe this was not really your question, since you were asking about a UI component?

Currently, its not there, but has been asked for several times.

Regards,

Jason


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

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

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

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

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET | HISP Uganda

Kampala

Uganda
+256 774149 775, + 256 759 800161

Skype ID: talexie

IT Consultant (Servers, Networks and Security, Health Information Systems - DHIS2, Disease Outbreak & Surveillance Systems) & Solar Consultant

"I don’t want to be anything other than what I have been - one tree hill "

On Wed, Sep 28, 2016 at 1:00 PM, Prosper BT ptb3000@gmail.com wrote:

Dear Paul,

Thanks for sharing this, its some blue print being discussed not yet implemented, we hope it can come soon especially for IDSR - symptoms. The work around right now is to design all the different options are either attributes or data elements depending on where they are going to be used with data type Yes Only


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

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

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

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

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

​Or if you are using a custom form, you can implement it your way

Regards

On Wed, Sep 28, 2016 at 1:24 PM, Arun Paul paul.arun@gmail.com wrote:

Hello everyone,

I am configuring a program using Tracker Capture. It requires data input using a multi-select dropdown or multi-select checkbox. Example for such a field is “Symptoms” or “Drugs given for treatment”. For these fields, I need to select more than one option as answers.

Is this UI component already supported?

Else, how can I support this through some work around or code-customization ?

Please let me know.

​Thanks in advance

,

  • Arun Paul

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

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

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

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

Prosper Behumbiize, MPH
Global DHIS2 Implementation| HISP Uganda/University Of Oslo
+256 752 751 776 | +256 776 139 139

prosper@hispuganda.org | prosper@dhis2.org | Skype: prospertb


Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19119

Email: calle.hedberg@gmail.com

Skype: calle_hedberg



(Alex Tumwesigye) #9

Dear Knut,

Yes, I think a widget that groups a choice of data elements (Yes Only - as indicated by Prosper and Jason) and present them in the UI as multiple select would be great. But I am not sure how hard the implementation would be but I guess it can be modeled with minor changes.

Alex

···

On Wed, Sep 28, 2016 at 3:43 PM, Calle Hedberg calle.hedberg@gmail.com wrote:

Hi

As both Prosper and Jason have confirmed, currently you have to use separate data elements or attributes. This might be inconvenient, in particular where the list of e.g. symptoms are long.

I can see two scenarios here:

There might not be much demand for analysing this type of data at all - might be mainly descriptive data for use by e.g. clinicians (one could argue that counting symptoms occurrences across many diseases don’t provide much of value, at least not on a regular reporting basis). The data element or attribute are then basically a free text field but with such “free” text either limited only to an option set or an option set + free text.

alternatively, you could do aggregated analysis by executing a count of all cases where symptoms LIKE ‘%Headache%’ (or any combination of such symptom “tags”) - again not currently supported I think but not complicated either.

I think we need more specific requirements and requirement scenarios here, to determine the design of such enhancements.

Regards

calle


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

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

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

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

On 28 September 2016 at 14:00, Jason Pickering jason.p.pickering@gmail.com wrote:

The reason is has to be separate data elements is because of analytics. If you have a single data element with multiple choices, there is currently not a way to aggregate all of these. So lets say you have a question like

What symptoms does the patient have?

a) Headache

b) Fever

c) Fatigue

If there was some sort of UI component like you are talking about with a single data element, we would need to record something like

Headache; Fever; Fatigue

in a single row in the database. When we aggregate it, well, it would not be really clear how we would do this. We would need to parse out all of the options and then somehow transform them into

Headache = 2

Fever = 4

Fatigue = 5

The of course you have more complicated situations like patients who have both Fever and Fatigue.

So, the way it has to be implemented now in DHIS2, is through a boolean data element.

Does the patient have a headache?

Does the patient have a fever?

Does the patient have fatigue?

Aggregation becomes just a matter of counting how many of these are true.

So, you could implement some sort of custom control do to this, but in the end, you would need completely separate data elements, but maybe this was not really your question, since you were asking about a UI component?

Currently, its not there, but has been asked for several times.

Regards,

Jason


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


Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19119

Email: calle.hedberg@gmail.com

Skype: calle_hedberg


On Wed, Sep 28, 2016 at 1:00 PM, Prosper BT ptb3000@gmail.com wrote:

Dear Paul,

Thanks for sharing this, its some blue print being discussed not yet implemented, we hope it can come soon especially for IDSR - symptoms. The work around right now is to design all the different options are either attributes or data elements depending on where they are going to be used with data type Yes Only


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

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

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

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

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

​Or if you are using a custom form, you can implement it your way

Regards

On Wed, Sep 28, 2016 at 1:24 PM, Arun Paul paul.arun@gmail.com wrote:

Hello everyone,

I am configuring a program using Tracker Capture. It requires data input using a multi-select dropdown or multi-select checkbox. Example for such a field is “Symptoms” or “Drugs given for treatment”. For these fields, I need to select more than one option as answers.

Is this UI component already supported?

Else, how can I support this through some work around or code-customization ?

Please let me know.

​Thanks in advance

,

  • Arun Paul

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

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

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

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

Prosper Behumbiize, MPH
Global DHIS2 Implementation| HISP Uganda/University Of Oslo
+256 752 751 776 | +256 776 139 139

prosper@hispuganda.org | prosper@dhis2.org | Skype: prospertb

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET | HISP Uganda

Kampala

Uganda
+256 774149 775, + 256 759 800161

Skype ID: talexie

IT Consultant (Servers, Networks and Security, Health Information Systems - DHIS2, Disease Outbreak & Surveillance Systems) & Solar Consultant

"I don’t want to be anything other than what I have been - one tree hill "


(Calle Hedberg) #10

Hi

I’m running a training/discussion workshop with public health & surveillance officers tomorrow on the South African pilot Integrated Disease Surveillance Reporting system, and both symptoms and treatments have been included on the SA notification form - BUT it was initially decided to simply limit the number of symptoms to 4 and treatments to 3 (each being a text field). it’s not ideal, though, both because there might be more relevant symptoms/treatments, and also because we will have to use 4 or 3 separate option sets to ensure that the same symptoms are put into the same data element every time (if analytics results are important, that is).

So I will raise the issue there and get their take on the primary use of such data.

Regards

Calle

···

On 28 September 2016 at 14:51, Calle Hedberg calle.hedberg@gmail.com wrote:

Alex,

You might have considerably more than 30 symptoms - it all depends on how “specialised” you want them (re ICD-9 used to be around 10,000 codes - now I believe ICD-10 have something like 60-70,000…).

The same logic applies to treatments - assuming 30-100 notifiable diseases being tracked, you might have a few hundred treatment options…

I think we need to unpack the main USAGE scenarios for this type of data - are we looking for analytics results, or will the data mainly be used to provide a “rich picture” for e.g. clinicians, lab engineers, surveillance officers, or various specialists to determine e.g. what lab tests to run or what public health actions to take?

Regards

Calle

On 28 September 2016 at 14:34, Alex Tumwesigye atumwesigye@gmail.com wrote:

Jason and Prosper,

Thanks for sharing the idea of how it can be implemented. However, this works for a few options. In IDSR implementation I have encountered more than 30 symptoms. I think, we need to figure out how this can be achieved.

Thanks.

Alex


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


Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19119

Email: calle.hedberg@gmail.com

Skype: calle_hedberg


On Wed, Sep 28, 2016 at 3:00 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

The reason is has to be separate data elements is because of analytics. If you have a single data element with multiple choices, there is currently not a way to aggregate all of these. So lets say you have a question like

What symptoms does the patient have?

a) Headache

b) Fever

c) Fatigue

If there was some sort of UI component like you are talking about with a single data element, we would need to record something like

Headache; Fever; Fatigue

in a single row in the database. When we aggregate it, well, it would not be really clear how we would do this. We would need to parse out all of the options and then somehow transform them into

Headache = 2

Fever = 4

Fatigue = 5

The of course you have more complicated situations like patients who have both Fever and Fatigue.

So, the way it has to be implemented now in DHIS2, is through a boolean data element.

Does the patient have a headache?

Does the patient have a fever?

Does the patient have fatigue?

Aggregation becomes just a matter of counting how many of these are true.

So, you could implement some sort of custom control do to this, but in the end, you would need completely separate data elements, but maybe this was not really your question, since you were asking about a UI component?

Currently, its not there, but has been asked for several times.

Regards,

Jason


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

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

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

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

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET | HISP Uganda

Kampala

Uganda
+256 774149 775, + 256 759 800161

Skype ID: talexie

IT Consultant (Servers, Networks and Security, Health Information Systems - DHIS2, Disease Outbreak & Surveillance Systems) & Solar Consultant

"I don’t want to be anything other than what I have been - one tree hill "

On Wed, Sep 28, 2016 at 1:00 PM, Prosper BT ptb3000@gmail.com wrote:

Dear Paul,

Thanks for sharing this, its some blue print being discussed not yet implemented, we hope it can come soon especially for IDSR - symptoms. The work around right now is to design all the different options are either attributes or data elements depending on where they are going to be used with data type Yes Only


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

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

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

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

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

​Or if you are using a custom form, you can implement it your way

Regards

On Wed, Sep 28, 2016 at 1:24 PM, Arun Paul paul.arun@gmail.com wrote:

Hello everyone,

I am configuring a program using Tracker Capture. It requires data input using a multi-select dropdown or multi-select checkbox. Example for such a field is “Symptoms” or “Drugs given for treatment”. For these fields, I need to select more than one option as answers.

Is this UI component already supported?

Else, how can I support this through some work around or code-customization ?

Please let me know.

​Thanks in advance

,

  • Arun Paul

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

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

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

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

Prosper Behumbiize, MPH
Global DHIS2 Implementation| HISP Uganda/University Of Oslo
+256 752 751 776 | +256 776 139 139

prosper@hispuganda.org | prosper@dhis2.org | Skype: prospertb


Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19119

Email: calle.hedberg@gmail.com

Skype: calle_hedberg



(Abyot Gizaw) #11

Hi,

I like the idea of outlining concrete usecase scenarios first…

The issue is not at all about UI - rather on the output side. Do we need to aggregate or not.

Where aggregation is not required:

  • may be introduce new value type something like “MULTI_TEXT” together with option set (Note: we already have valueType TEXT together with option set where aggregation/counting is possible)

···

Where aggregation is required:

  • introduce a special data model, multiSelectProgramStageDataElementGroup. This group belongs to a program stage. A program stage can have multiple of this group - we might have multiple multi-select choices. Each group contains list of yes only value type data elements.

On Wed, Sep 28, 2016 at 2:58 PM, Calle Hedberg calle.hedberg@gmail.com wrote:

Hi

I’m running a training/discussion workshop with public health & surveillance officers tomorrow on the South African pilot Integrated Disease Surveillance Reporting system, and both symptoms and treatments have been included on the SA notification form - BUT it was initially decided to simply limit the number of symptoms to 4 and treatments to 3 (each being a text field). it’s not ideal, though, both because there might be more relevant symptoms/treatments, and also because we will have to use 4 or 3 separate option sets to ensure that the same symptoms are put into the same data element every time (if analytics results are important, that is).

So I will raise the issue there and get their take on the primary use of such data.

Regards

Calle


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

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

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

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

Abyot A. Gizaw.

Senior Engineer, DHIS2

University of Oslo

http://www.dhis2.org

On 28 September 2016 at 14:51, Calle Hedberg calle.hedberg@gmail.com wrote:

Alex,

You might have considerably more than 30 symptoms - it all depends on how “specialised” you want them (re ICD-9 used to be around 10,000 codes - now I believe ICD-10 have something like 60-70,000…).

The same logic applies to treatments - assuming 30-100 notifiable diseases being tracked, you might have a few hundred treatment options…

I think we need to unpack the main USAGE scenarios for this type of data - are we looking for analytics results, or will the data mainly be used to provide a “rich picture” for e.g. clinicians, lab engineers, surveillance officers, or various specialists to determine e.g. what lab tests to run or what public health actions to take?

Regards

Calle


Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19119

Email: calle.hedberg@gmail.com

Skype: calle_hedberg


On 28 September 2016 at 14:34, Alex Tumwesigye atumwesigye@gmail.com wrote:

Jason and Prosper,

Thanks for sharing the idea of how it can be implemented. However, this works for a few options. In IDSR implementation I have encountered more than 30 symptoms. I think, we need to figure out how this can be achieved.

Thanks.

Alex


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


Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19119

Email: calle.hedberg@gmail.com

Skype: calle_hedberg


On Wed, Sep 28, 2016 at 3:00 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

The reason is has to be separate data elements is because of analytics. If you have a single data element with multiple choices, there is currently not a way to aggregate all of these. So lets say you have a question like

What symptoms does the patient have?

a) Headache

b) Fever

c) Fatigue

If there was some sort of UI component like you are talking about with a single data element, we would need to record something like

Headache; Fever; Fatigue

in a single row in the database. When we aggregate it, well, it would not be really clear how we would do this. We would need to parse out all of the options and then somehow transform them into

Headache = 2

Fever = 4

Fatigue = 5

The of course you have more complicated situations like patients who have both Fever and Fatigue.

So, the way it has to be implemented now in DHIS2, is through a boolean data element.

Does the patient have a headache?

Does the patient have a fever?

Does the patient have fatigue?

Aggregation becomes just a matter of counting how many of these are true.

So, you could implement some sort of custom control do to this, but in the end, you would need completely separate data elements, but maybe this was not really your question, since you were asking about a UI component?

Currently, its not there, but has been asked for several times.

Regards,

Jason


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

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

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

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

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET | HISP Uganda

Kampala

Uganda
+256 774149 775, + 256 759 800161

Skype ID: talexie

IT Consultant (Servers, Networks and Security, Health Information Systems - DHIS2, Disease Outbreak & Surveillance Systems) & Solar Consultant

"I don’t want to be anything other than what I have been - one tree hill "

On Wed, Sep 28, 2016 at 1:00 PM, Prosper BT ptb3000@gmail.com wrote:

Dear Paul,

Thanks for sharing this, its some blue print being discussed not yet implemented, we hope it can come soon especially for IDSR - symptoms. The work around right now is to design all the different options are either attributes or data elements depending on where they are going to be used with data type Yes Only


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

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

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

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

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

​Or if you are using a custom form, you can implement it your way

Regards

On Wed, Sep 28, 2016 at 1:24 PM, Arun Paul paul.arun@gmail.com wrote:

Hello everyone,

I am configuring a program using Tracker Capture. It requires data input using a multi-select dropdown or multi-select checkbox. Example for such a field is “Symptoms” or “Drugs given for treatment”. For these fields, I need to select more than one option as answers.

Is this UI component already supported?

Else, how can I support this through some work around or code-customization ?

Please let me know.

​Thanks in advance

,

  • Arun Paul

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

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

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

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

Prosper Behumbiize, MPH
Global DHIS2 Implementation| HISP Uganda/University Of Oslo
+256 752 751 776 | +256 776 139 139

prosper@hispuganda.org | prosper@dhis2.org | Skype: prospertb


(Alex Tumwesigye) #12

Abyot,

The use cases sometimes are not very specific. In some cases we need aggregation so we should support both if possible.

Alex

···

On Wed, Sep 28, 2016 at 4:02 PM, Abyot Asalefew Gizaw abyot@dhis2.org wrote:

Hi,

I like the idea of outlining concrete usecase scenarios first…

The issue is not at all about UI - rather on the output side. Do we need to aggregate or not.

Where aggregation is not required:

  • may be introduce new value type something like “MULTI_TEXT” together with option set (Note: we already have valueType TEXT together with option set where aggregation/counting is possible)

Where aggregation is required:

  • introduce a special data model, multiSelectProgramStageDataElementGroup. This group belongs to a program stage. A program stage can have multiple of this group - we might have multiple multi-select choices. Each group contains list of yes only value type data elements.

Abyot A. Gizaw.

Senior Engineer, DHIS2

University of Oslo

http://www.dhis2.org

On Wed, Sep 28, 2016 at 2:58 PM, Calle Hedberg calle.hedberg@gmail.com wrote:

Hi

I’m running a training/discussion workshop with public health & surveillance officers tomorrow on the South African pilot Integrated Disease Surveillance Reporting system, and both symptoms and treatments have been included on the SA notification form - BUT it was initially decided to simply limit the number of symptoms to 4 and treatments to 3 (each being a text field). it’s not ideal, though, both because there might be more relevant symptoms/treatments, and also because we will have to use 4 or 3 separate option sets to ensure that the same symptoms are put into the same data element every time (if analytics results are important, that is).

So I will raise the issue there and get their take on the primary use of such data.

Regards

Calle


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

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

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

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

On 28 September 2016 at 14:51, Calle Hedberg calle.hedberg@gmail.com wrote:

Alex,

You might have considerably more than 30 symptoms - it all depends on how “specialised” you want them (re ICD-9 used to be around 10,000 codes - now I believe ICD-10 have something like 60-70,000…).

The same logic applies to treatments - assuming 30-100 notifiable diseases being tracked, you might have a few hundred treatment options…

I think we need to unpack the main USAGE scenarios for this type of data - are we looking for analytics results, or will the data mainly be used to provide a “rich picture” for e.g. clinicians, lab engineers, surveillance officers, or various specialists to determine e.g. what lab tests to run or what public health actions to take?

Regards

Calle


Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19119

Email: calle.hedberg@gmail.com

Skype: calle_hedberg


On 28 September 2016 at 14:34, Alex Tumwesigye atumwesigye@gmail.com wrote:

Jason and Prosper,

Thanks for sharing the idea of how it can be implemented. However, this works for a few options. In IDSR implementation I have encountered more than 30 symptoms. I think, we need to figure out how this can be achieved.

Thanks.

Alex


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


Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19119

Email: calle.hedberg@gmail.com

Skype: calle_hedberg


On Wed, Sep 28, 2016 at 3:00 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

The reason is has to be separate data elements is because of analytics. If you have a single data element with multiple choices, there is currently not a way to aggregate all of these. So lets say you have a question like

What symptoms does the patient have?

a) Headache

b) Fever

c) Fatigue

If there was some sort of UI component like you are talking about with a single data element, we would need to record something like

Headache; Fever; Fatigue

in a single row in the database. When we aggregate it, well, it would not be really clear how we would do this. We would need to parse out all of the options and then somehow transform them into

Headache = 2

Fever = 4

Fatigue = 5

The of course you have more complicated situations like patients who have both Fever and Fatigue.

So, the way it has to be implemented now in DHIS2, is through a boolean data element.

Does the patient have a headache?

Does the patient have a fever?

Does the patient have fatigue?

Aggregation becomes just a matter of counting how many of these are true.

So, you could implement some sort of custom control do to this, but in the end, you would need completely separate data elements, but maybe this was not really your question, since you were asking about a UI component?

Currently, its not there, but has been asked for several times.

Regards,

Jason


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

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

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

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

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET | HISP Uganda

Kampala

Uganda
+256 774149 775, + 256 759 800161

Skype ID: talexie

IT Consultant (Servers, Networks and Security, Health Information Systems - DHIS2, Disease Outbreak & Surveillance Systems) & Solar Consultant

"I don’t want to be anything other than what I have been - one tree hill "

On Wed, Sep 28, 2016 at 1:00 PM, Prosper BT ptb3000@gmail.com wrote:

Dear Paul,

Thanks for sharing this, its some blue print being discussed not yet implemented, we hope it can come soon especially for IDSR - symptoms. The work around right now is to design all the different options are either attributes or data elements depending on where they are going to be used with data type Yes Only


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

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

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

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

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

​Or if you are using a custom form, you can implement it your way

Regards

On Wed, Sep 28, 2016 at 1:24 PM, Arun Paul paul.arun@gmail.com wrote:

Hello everyone,

I am configuring a program using Tracker Capture. It requires data input using a multi-select dropdown or multi-select checkbox. Example for such a field is “Symptoms” or “Drugs given for treatment”. For these fields, I need to select more than one option as answers.

Is this UI component already supported?

Else, how can I support this through some work around or code-customization ?

Please let me know.

​Thanks in advance

,

  • Arun Paul

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

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

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

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

Prosper Behumbiize, MPH
Global DHIS2 Implementation| HISP Uganda/University Of Oslo
+256 752 751 776 | +256 776 139 139

prosper@hispuganda.org | prosper@dhis2.org | Skype: prospertb

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET | HISP Uganda

Kampala

Uganda
+256 774149 775, + 256 759 800161

Skype ID: talexie

IT Consultant (Servers, Networks and Security, Health Information Systems - DHIS2, Disease Outbreak & Surveillance Systems) & Solar Consultant

"I don’t want to be anything other than what I have been - one tree hill "


(Calle Hedberg) #13

Hi,

As indicated day before yesterday, I had an IDSR training session with a group of public health specialists yesterday, and I raised the issue under discussion:

Firstly, there was broad consensus that nobody would be interested in using e.g. symptoms data for daily/weekly analytics in the sense Jason/Knut are referring to above (i.e. counting the number of headaches, or calculating what proportion of malaria cases that have sweats at night). The PRIMARY use of such symptoms data for disease surveillance will be to enable disease specialists to investigate the case if the initial lab tests requested by the notifying health practitioner is negative - meaning that the initial diagnosis probably is wrong and the specialists need to consider

  • what additional tests to do using specimens already sent to the lab

  • what additional specimens to request from the treating facility, if any

  • what advice to give the clinicians treating the patient while waiting for a final diagnosis

  • what other alerts should be sent out and/or outbreak mechanisms mobilised related to the differential diagnoses being considered

So as a simple example: if an acute febrile illness patient is initially diagnosed with malaria and the blood smear or DBS analysis is negative, the set of symptoms will be used to e.g determine what other test to conduct and other interventions.

Secondly, the specialists did point out that the symptoms data MIGHT be relevant for certain types of longitudinal research, like when trying to find out if the typical symptoms of a disease has changed over time (possibly due to pathogen mutations or other factors). A typical scenario would then be to take let us say 5 or 10 or 15 years of case notifications for that disease and what symptoms have been reported for each. You would not use standard program indicators for that, though - you would simply dump out all relevant cases then parse the symptoms text field (using Excel, STATA, R, or whatever) for symptoms trend analysis.

Thirdly, based on the above, I do agree with Jason that it would be best to keep non-standard symptoms & other “syndrome”-type comments in a separate text field so that you don’t risk “contaminating” the MULTI_TEXT attribute/element with random stuff.

I think Abyot’s grasp of this is very good:

Introduce valueType “MULTI_TEXT”, which when used for both an attribute/data element and it’s specified option set will enable users to select multiple text values which will be inserted into the attribute/DE as sequential values separated by e.g. a semi-colon. If there is a need for free text values, then follow usual procedure and include “Other (specify)” - a program rule using a LIKE operator will show/hide the Specify field if so required.

If a “MULTI_TEXT” option set is specified to be a drop-down list, there are of course multiple ways to enable multi-selections: you can use tick-boxes or highlighting values with a SAVE button (i.e. there won’t be any duplicated values) or you can use double-clicking with the value immediately appearing in the text box followed by re-filtering of the list to remove the value already selected. A text filter on top of the option list would be appreciated. If the option set is large and e.g. tick-boxes are used with a small “SAVE” button, it would be preferable to always show what’s already selected on top even when scrolling to the next page. (OK - you get my drift here: whatever multi-option selection method you prefer from a design view, just make sure it’s easy to find options in a long list and make sure users cannot choose the same option value twice).

If a “MULTI_TEXT” option set is specified to be a radio-button list, it should be straight-forward and users cannot choose anything more than once. BUT a radio-button list is only relevant with a reasonably number of option values.

Which brings me to a related issue: the choice of using drop-down values or radio-buttons are now set at the program definition level. Would it be possible to leave that as a sort of “default” parameter but then override it either in the attribute/DE or option set definitions?

The public health specialists yesterday also requested that it should be possible to filter the symptoms option set based on the diagnosis - or in more generic terms they requested that only symptoms relevant for a specific disease should be shown. While I strongly argued against that concept when it comes to symptoms - it would for instance negate their wish to use longitudinal disease/symptoms pairs to reveal changes in symptoms for a disease, and it also reduces the usability of symptoms data to investigate indeterminate syndromes - there are some scenarios where clearly defined relations makes this type of pre-filtering useful.

Concrete example: SA IDSR will be tracking 48 notifiable diseases, but those 48 conditions actually covers nearly 650 specific ICD-10 codes. Right now we have the Diagnosis field with an optionSet of 48 values and the next ICD-10 field with an optionSet of ~650 values. It would be highly preferable to filter the drop-down of ICD-10 codes to only show those relevant for the specific condition/diagnosis specified. In practical terms, this would require either optionSet attributes (preferable) or at least one additional “groupfilter” field in the optonValue table.

Finally, I agree with Jason/Knut/Alex and then Abyot’s more specific version that a collection of YesOnly DEs could be packaged as a multiSelectProgramStageDataElementGroup. I’m less sure if that is required also for attributes - the current problem is that a number of things like searches are only supported for attributes and not DEs, so users end up using attributes for too many things. If the same functionality were added for DEs, we would have a more robust and logical model.

Regards

Calle

···

On 28 September 2016 at 15:23, Alex Tumwesigye atumwesigye@gmail.com wrote:

Abyot,

The use cases sometimes are not very specific. In some cases we need aggregation so we should support both if possible.

Alex

On Wed, Sep 28, 2016 at 4:02 PM, Abyot Asalefew Gizaw abyot@dhis2.org wrote:

Hi,

I like the idea of outlining concrete usecase scenarios first…

The issue is not at all about UI - rather on the output side. Do we need to aggregate or not.

Where aggregation is not required:

  • may be introduce new value type something like “MULTI_TEXT” together with option set (Note: we already have valueType TEXT together with option set where aggregation/counting is possible)


Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET | HISP Uganda

Kampala

Uganda
+256 774149 775, + 256 759 800161

Skype ID: talexie

IT Consultant (Servers, Networks and Security, Health Information Systems - DHIS2, Disease Outbreak & Surveillance Systems) & Solar Consultant

"I don’t want to be anything other than what I have been - one tree hill "

Where aggregation is required:

  • introduce a special data model, multiSelectProgramStageDataElementGroup. This group belongs to a program stage. A program stage can have multiple of this group - we might have multiple multi-select choices. Each group contains list of yes only value type data elements.

Abyot A. Gizaw.

Senior Engineer, DHIS2

University of Oslo

http://www.dhis2.org

On Wed, Sep 28, 2016 at 2:58 PM, Calle Hedberg calle.hedberg@gmail.com wrote:

Hi

I’m running a training/discussion workshop with public health & surveillance officers tomorrow on the South African pilot Integrated Disease Surveillance Reporting system, and both symptoms and treatments have been included on the SA notification form - BUT it was initially decided to simply limit the number of symptoms to 4 and treatments to 3 (each being a text field). it’s not ideal, though, both because there might be more relevant symptoms/treatments, and also because we will have to use 4 or 3 separate option sets to ensure that the same symptoms are put into the same data element every time (if analytics results are important, that is).

So I will raise the issue there and get their take on the primary use of such data.

Regards

Calle


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

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

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

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

On 28 September 2016 at 14:51, Calle Hedberg calle.hedberg@gmail.com wrote:

Alex,

You might have considerably more than 30 symptoms - it all depends on how “specialised” you want them (re ICD-9 used to be around 10,000 codes - now I believe ICD-10 have something like 60-70,000…).

The same logic applies to treatments - assuming 30-100 notifiable diseases being tracked, you might have a few hundred treatment options…

I think we need to unpack the main USAGE scenarios for this type of data - are we looking for analytics results, or will the data mainly be used to provide a “rich picture” for e.g. clinicians, lab engineers, surveillance officers, or various specialists to determine e.g. what lab tests to run or what public health actions to take?

Regards

Calle


Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19119

Email: calle.hedberg@gmail.com

Skype: calle_hedberg


On 28 September 2016 at 14:34, Alex Tumwesigye atumwesigye@gmail.com wrote:

Jason and Prosper,

Thanks for sharing the idea of how it can be implemented. However, this works for a few options. In IDSR implementation I have encountered more than 30 symptoms. I think, we need to figure out how this can be achieved.

Thanks.

Alex


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


Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19119

Email: calle.hedberg@gmail.com

Skype: calle_hedberg


On Wed, Sep 28, 2016 at 3:00 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

The reason is has to be separate data elements is because of analytics. If you have a single data element with multiple choices, there is currently not a way to aggregate all of these. So lets say you have a question like

What symptoms does the patient have?

a) Headache

b) Fever

c) Fatigue

If there was some sort of UI component like you are talking about with a single data element, we would need to record something like

Headache; Fever; Fatigue

in a single row in the database. When we aggregate it, well, it would not be really clear how we would do this. We would need to parse out all of the options and then somehow transform them into

Headache = 2

Fever = 4

Fatigue = 5

The of course you have more complicated situations like patients who have both Fever and Fatigue.

So, the way it has to be implemented now in DHIS2, is through a boolean data element.

Does the patient have a headache?

Does the patient have a fever?

Does the patient have fatigue?

Aggregation becomes just a matter of counting how many of these are true.

So, you could implement some sort of custom control do to this, but in the end, you would need completely separate data elements, but maybe this was not really your question, since you were asking about a UI component?

Currently, its not there, but has been asked for several times.

Regards,

Jason


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

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

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

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

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET | HISP Uganda

Kampala

Uganda
+256 774149 775, + 256 759 800161

Skype ID: talexie

IT Consultant (Servers, Networks and Security, Health Information Systems - DHIS2, Disease Outbreak & Surveillance Systems) & Solar Consultant

"I don’t want to be anything other than what I have been - one tree hill "

On Wed, Sep 28, 2016 at 1:00 PM, Prosper BT ptb3000@gmail.com wrote:

Dear Paul,

Thanks for sharing this, its some blue print being discussed not yet implemented, we hope it can come soon especially for IDSR - symptoms. The work around right now is to design all the different options are either attributes or data elements depending on where they are going to be used with data type Yes Only


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

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

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

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

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

​Or if you are using a custom form, you can implement it your way

Regards

On Wed, Sep 28, 2016 at 1:24 PM, Arun Paul paul.arun@gmail.com wrote:

Hello everyone,

I am configuring a program using Tracker Capture. It requires data input using a multi-select dropdown or multi-select checkbox. Example for such a field is “Symptoms” or “Drugs given for treatment”. For these fields, I need to select more than one option as answers.

Is this UI component already supported?

Else, how can I support this through some work around or code-customization ?

Please let me know.

​Thanks in advance

,

  • Arun Paul

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

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

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

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

Prosper Behumbiize, MPH
Global DHIS2 Implementation| HISP Uganda/University Of Oslo
+256 752 751 776 | +256 776 139 139

prosper@hispuganda.org | prosper@dhis2.org | Skype: prospertb


Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19119

Email: calle.hedberg@gmail.com

Skype: calle_hedberg



(Muyunda Walusiku) #14

Has there been any development from this discussion?


(Calle Hedberg) #15

Hi

No and yes.

Ref my post above, there has been no progress on the issue of a multi-text data type after I wrote a JIRA issue in December 2016. (DHIS2-429).

For filtering option sets there’s been progress through the introduction of optionvalue groups in recent versions, which supports filtering option sets using program rules.

Regards

Calle


(Jasper Timm) #16

Hi,

Just adding that I’m also in need of a multi-select checkbox at the moment and something like what Calle described would be quite useful.

Thanks,

  • Jasper

(Markus Bekken) #17

Thanks for the comments. Just to highlight that the issue number is DHIS2-429, there was a small typo in the number above.
Its great if you can add details on your use cases or vote for the issue in jira:
https://jira.dhis2.org/browse/DHIS2-429