dhis2-devs team mailing list archive

[Calle Hedberg <calle.hedberg@xxxxxxxxx>]

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:

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

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

3.
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?

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

5.
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@xxxxxxxxx>
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@xxxxxxxxx>
> 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@xxxxxxxxx>
>> 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
>>>
>>> On 28 September 2016 at 14:51, Calle Hedberg <calle.hedberg@xxxxxxxxx>
>>> 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@xxxxxxxxx>
>>>> 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@xxxxxxxxx> 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
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 28, 2016 at 1:00 PM, Prosper BT <ptb3000@xxxxxxxxx>
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> [image: Inline image 1]
>>>>>>>
>>>>>>> ​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@xxxxxxxxx>
>>>>>>> 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@xxxxxxxxxxxxxxxxxxx
>>>>>>>> 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@xxxxxxxxxxxxxx <ptb3000@xxxxxxxxx> | prosper@xxxxxxxxx | Skype:
>>>>>>> prospertb
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~dhis2-users
>>>>>>> Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~dhis2-users
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jason P. Pickering
>>>>>> email: jason.p.pickering@xxxxxxxxx
>>>>>> tel:+46764147049
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~dhis2-users
>>>>>> Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
>>>>>> 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 "
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>> 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@xxxxxxxxx
>>>>
>>>> Skype: calle_hedberg
>>>>
>>>> *******************************************
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> *******************************************
>>>
>>> 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@xxxxxxxxx
>>>
>>> Skype: calle_hedberg
>>>
>>> *******************************************
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~dhis2-users
>>> Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
>>> 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 "
>



-- 

*******************************************

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

Skype: calle_hedberg

*******************************************