Add a global symptomatic variable to a case

bernardsilenou commented 4 years ago

Situation Description

Currently, asymptomatic cases can only be inferred from all symptoms == NO. Users will want to explicitly register that a case is asymptomatic in one click.

Feature Description

The symptomatic variable can have categories: Symptomatic & asymptomatic -when asymptomatic == T, then all symptom ==NO, -when symptomatic == T, then all symptom are presented on form for user to choose,

Possible Alternatives

Add a check box button beside "set all clear to NO" and if set to T, the symptoms == NO and if set to yes, then symptoms == NA and user then have to choose option for each symptom.

Additional Information

MateStrysewske commented 4 years ago

@bernardsilenou I don't really understand why they can't just use the existing buttons for this purpose. Do you need this so that they can see at a glance whether a case is asymptomatic without having to look at the list of symptoms?

carolinverset commented 4 years ago

@bernardsilenou @benchaabaner @Emond-Fuseau @OlivierLeuci

I agree with you : For asymptomatic cases, we could click on no for all the symptoms. But for symptomatic cases, in France, we do not know the symptom from which the case is suffering. We just need to know whether the case has symptoms or not.

Another advantage is that we will thus have a synthetic variable which would make it possible to add a filter in the case directory to visualize and export only symptomatic or asymptomatic patients.

Best regards Carolin

MateStrysewske commented 4 years ago

@carolinverset There's already a hidden "symptomatic" variable that is automatically updated based on whether any symptom has been set to "yes". I still don't really understand the need for making it available for the user though. Adding such a filter would not be a problem.

bernardsilenou commented 4 years ago

@MateStrysewskeSym I think it goes both ways, we still need to show this hidden variable for users to be able to choose yes/no right? -If a case is symptomatic and you do not know the symptoms, then this may affect the relationship between the hidden symptomatic variable and the symptoms because symptomatic can be "yes" and all symptoms are NA. Maybe we need to add a new symptomatic satiable that does not depend on the symptoms? -The benefit i see with this variable is in a situation that we know a case is symptomatic but we do not know the exact symptoms. In the current setting, we can't record this information.

MateStrysewske commented 4 years ago

@bernardsilenou How exactly can a situation like this even happen? If you know for a fact that a case is symptomatic, you'd also need to know about at least one symptom, right? How else would you verify that the person is indeed symptomatic?

carolinverset commented 4 years ago

@bernardsilenou @MateStrysewskeSym Information on cases and contacts comes from another information system and is imported daily into SORMAS. This data indicates whether the patient is symptomatic or not and doesn't specify the nature of the symptom.

When we rarely integrate a case, the teleoperator only asks if the case is symptomatic and is not supposed to ask the nature of the symptom.

However, if this seems too specific to the needs of France, we can set up an entry rule to indicate a specific symptom to be checked even if that is not necessarily that of the case.

But it would be verry important to create the filter for the hidden variable at the level of the case directory and in the case file. What do yu think about ?

Best regards, Carolin

bernardsilenou commented 4 years ago

@carolinverset As earlier discussed, its not a good idea to choose a random symptom in order to set the hidden symptomatic variable to true. @MateStrysewskeSy From my understanding, the back-end symptomatic variable is a derived variable (default == False) and only set to True if ate least one symptom is true. There are 2 solutions we can think of for you to choose the best one or propose another:

Make the back-end symptomatic variable visible on ui and allow users to manually set it to True even if all symptoms are NA. I do not know what this might have on statistics and dashboard. This solution will need us to break the relationship/ validatioin between the symptomatic variable and list of symptoms which i think we do not want to. We can not also force teh user to choose a symptom when they set this variable to true because they do not know the symptoms.
Keep the system as it is and add a new asymptomatic variable with categories, NA(default), yes, no, unknown.

I can further refine the ticket based on the choice you decide

MateStrysewske commented 4 years ago

@bernardsilenou I guess we'd have to go with the first version because it's also used in the dashboard to indicate how many cases are symptomatic, and those only set to symptomatic without any symptom set to yes would have to be included there.

bernardsilenou commented 4 years ago

@MateStrysewskeSym thanks, French team will work on it this sprint.

bernardsilenou commented 4 years ago

Summary of refinement:

We do not create a new variable but we use the already existing hidden variable in base (name = "symptomatic": true/false)
We make this variable "symptomatic" visible in the ui, in the symptoms tab (above the block with all the symptoms) Expected behavior:
→ If all symptoms are unknown or NA (Or simply == yes) in the symptom block, leave the possibility for the user to manually enter whether the case is symptomatic or not → If at least 1 symptom =YES, then the variable automatically switches to symptomatic → If all symptoms = NO, then the variable automatically switches to asymptomatic Conversely:
If symptomatic = yes, allow users to choose the corresponding symptoms.
If symptomatic = no, do not allow users to choose the symbols and set all symptoms to no.

optional:

Add additional filter the case directory to show only symptomatic or asymptomatic cases.
Add additional filter the contact directory to show only symptomatic or asymptomatic contacts.

benchaabaner commented 4 years ago

@bernardsilenou @MateStrysewskeSym @carolinverset

Here is the behaviour we have :

if symptomatic = no : all the other symptoms are set to "no" and can't be changed and the date field is disabled
if symptomatic = yes :

Do we still need the "set cleared to no" link ? this behaviour is possible via the symptomatic switch ?

bernardsilenou commented 4 years ago

@benchaabaner if symptomatic= yes, we still need set all clear to no. The reason is because if a person has only fever, the users like to choose fever = yet and set all clear to no afterwards. It is time consuming for them to go through all the symptoms when they can clearly see that the person has only fever. This is not a good practice but that what they do.

solution: If symptomatic = yes, then set all clear to no should be activated only of a least one symptom ==Yes, else not editable

benchaabaner commented 4 years ago

@bernardsilenou The behavior we developed sets symptomatic and all the symptoms to no by default (first picture above)

Default should be NA or NULL (not shown at front end) for all symptoms and the asymptomatic variables. Figure one is fine if symptomatic = no.

If a person has only fever, then the user will have to set symptomatic to yes then all the symptoms will be enabled and he only has to check the fever symptom and set it to yes. All the other symptoms are still set to no but can be changed ( second picture above)

with this behavior, I feel that there is no need for the "set cleared to no" link. They are already set to no by default.

You are right if the levels of the symptom variables are yes and no only. But we have NA(default), yes, no, unknown. "set cleared to no" is just a design manner to set or most often some "NA" symptoms to "no" without doing them one at a time.
A case can be symptomatic but a particular symptom is NA because the data was recorded from another system or paper form that did not document this particular symptom. This this is the reason why we need NA and unknown and do not sett all symptoms to no by default as long as the case is symptomatic.

benchaabaner commented 4 years ago

@bernardsilenou @MateStrysewske @carolinverset

Summary of our latest discussion :

If default, symptomatic = NULL and all the symptoms are set to NULL and are enabled
If Symptomatic = no, all symptoms are set to no and are disabled.
If Symptomatic = yes, all symptoms are set to NULL and are enabled

Do we all agree on this behaviour ?

bernardsilenou commented 4 years ago

@bernardsilenou @MateStrysewske @carolinverset

Summary of our latest discussion

default, symptomatic = NULL and all the symptoms are set to NULL and are enabled :+1:

If Symptomatic = no, all symptoms are set to no and are disabled. :+1:

If Symptomatic = yes, all symptoms are set to NULL and are enabled :+1:

add this last option please

If any symptom is first set to yes, then symptomatic set to yes

@MateStrysewske please can you confirm?

mouloud-mala commented 4 years ago

@bernardsilenou @MateStrysewske @benchaabaner

I am working on but the symptomatic variable (boolean) cannot be null, by default symptomatic = false. How to manage the case where symptomatic is null ?

Best regards. Mouloud.

MateStrysewske commented 4 years ago

@mouloud-mala You could replace the boolean field with a YesNoUnknown field and use Unknown instead of null.

mouloud-mala commented 4 years ago

@MateStrysewske Should I change on base boolean for SymptomState ? Because the boolean is used in uptdateIsSymptomatic() on CaseFacadeEjb, ClinicalVisitFacadeEjb and VisitFacadeEjb classes.

MateStrysewske commented 4 years ago

@mouloud-mala You shouldn't have to do anything about SymptomState. And of course changing the type of the symptomatic field will involve quite some refactoring.

mouloud-mala commented 4 years ago

@MateStrysewske For information can I create a enum like SymptomState with YesNoUnknow for the symptomatic variable (SymptomaticState) ?

MateStrysewske commented 4 years ago

@mouloud-mala No, please just use YesNoUnknown.

SORMAS-Foundation / SORMAS-Project