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
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.
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.
···
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
,
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