Introduce disease properties to switch between basic and extended classification [3]

[generalkolo]

Situation Description

The NCDC Data Transition team in accordance with the WHO standards has requested that we add the following case classifications under Measles Disease

• Clinically confirmed
• Epidemiologically linked.

Feature Description

In addition to the case classifications currently available under Measles (NOT YET CLASSIFIED, SUSPECT CASE, PROBABLE CASE, CONFIRMED CASE, NOT A CASE), a request has been made to add two more; Clinically confirmed and Epidemiologically linked.

The automatic case classification by the system would be put on hold for the disease (Measles) as a clear algorithm for the selection is yet to be achieved instead users having the right user privilege should be able to manually select case classifications.

Possible Alternatives

Additional Information

[bernardsilenou]

Definitions from WHO https://www.who.int/immunization/monitoring_surveillance/burden/vpd/surveillance_type/active/measles_standards/en/

Laboratory-confirmed: A case that meets the clinical case definition (suspected case definition in SORMAS) and is laboratory-confirmed == Confirmed case in SORMAS Epidemiologically confirmed: A case that meets the clinical case definition and is linked to a laboratory-confirmed case Clinically confirmed: A case that meets the clinical case definition and for which no adequate blood specimen was taken

[bernardsilenou]

@MateStrysewske @generalkolo @kwa20 In order not the affect the case classification for other diseases and considering the fact the clinical and epi confirmed are all forms of confirmed categories for measles. We would like to proposed this design:

• Add a required variable basis for classification to case: enums: lab, clinical, epi
• Activate it for measles only for now
• if case classification == confirmed, then show basis of classification

@generalkolo Please can you discuss this with the incident managers and comment if this is fine for them?

[bernardsilenou]

@kwa20 I can remember that you once designed a similar issue like this when classification == not a case. I cant not find the ticket, Pls can you link it to this one?

[kwa20]

@bernardsilenou I think you're looking for #3419

[bernardsilenou]

@kwa20 Yes, this is it. I had a look and realized that the options can be multiple, right? So we may not use the same module. For this issue, you can choose only one option.

[kwa20]

@bernardsilenou yes it's multiple options. However, is this not what we are looking for here?:

[bernardsilenou]

@kwa20 this is what we need but only for confirmed cases + single option we can use the same place holders for clinical, epi and labo confirmation that we already have at back end

• The only change needed is to make sure that only one of the 3 options can be selected for a case. Just add a rule.
• Or, we just create a new variable if it is easier to program. This may not be good because we would then have 2 different variables at back end collecting data for the same goal/ idea.

@MateStrysewske Pls can your suggest a good practice on how to go about implementing this?

[kwa20]

@bernardsilenou Can you explain why a 'one selection only' option is needed? Multiple reasons could indeed apply right?

[bernardsilenou]

@kwa20 You are very right, multiple option can apply in real life. The clinical picture, lab, epi data, etc can be multiple but the goal is to lead you to a single classification. The interpretation is slightly opposite from the DE instance. On DE, the 3 variables: clinical (if symptom exist), lab ( if positive pathogen test exist) and api (exposures) confirmation are not categories of the case classification but are used to determine the classification. Can we validate this in Sirvnet by calling tomorrow?

In this ticket they are categories of final case classifications and can only be one, ie most accurate starting from lab confirmation to unclassified

[MateStrysewske]

@bernardsilenou @kwa20 This is kinda tricky. We should definitely find a way to use the fields that we already have - because we already have them. Right now they're only enabled for Germany (and thus Covid-19); what we could do is to add a new disease configuration parameter that allows to enable "extended case classification", which would make these three fields visible (by default OFF for all diseases in all countries, ON for Covid-19 in Germany, ON for Measles in Nigeria), and another parameter that allows to toggle between "single" and "multi" extended classification. "Multi" would work just as the three fields are working in Germany right now, "single" would add some logic that ensures that only one of the fields can be answered with "Yes". The easiest solution for this would be to automatically set the two other fields to "No" if "Yes" is selected in one of them, a better, but more complicated solution would be to add a custom dropdown that includes the three options and then maps to the three fields in the database.

What do you think?

[bernardsilenou]

@MateStrysewske

• "extended case classification" as a disease config is a very good idea. I did not think of such a great idea.
• This would mean we can use the same front end form as we already have, cool
• For the toggle config I would suggest that we do not set the others to NO when one is set to Yes because this may latter affect statistics if on the same server, one disease is set to yes and another to no. We would then need to make our methods to be disease specific which is not good. Can this even happen? if not then is does not matter.
• However, if we set the others to NO, we should not show it at front end. If user choose one option, the others should just be blank and if they click on it, they then get a warning message that " the case classification can only be one category". Yes just means the most accurate, but does not proof that other options are No.

[generalkolo]

@bernardsilenou the solution indicated here works better for the system and the visual and user experience is better because the user has the option to click from the drop down.

I also spoke to the data transition team and they agreed the same.

@MateStrysewske @generalkolo @kwa20 In order not the affect the case classification for other diseases and considering the fact the clinical and epi confirmed are all forms of confirmed categories for measles. We would like to proposed this design:

• Add a required variable basis for classification to case: enums: lab, clinical, epi
• Activate it for measles only for now
• if case classification == confirmed, then show basis of classification

@generalkolo Please can you discuss this with the incident managers and comment if this is fine for them?

---

@MateStrysewske the extended classification is a great idea but to the best of my knowledge (informed by having several discussions with the data transition team), a Measles case when confirmed can only be one of the three; laboratory confirmed, epidemologically linked, clinically confirmed so if the parameter when toggled on for "single" classification would provide the users with a single drop down with the three options mentioned above then that's fine and when toggled to "multi" classification can show the UI here (https://github.com/hzi-braunschweig/SORMAS-Project/issues/4218#issuecomment-776205335) then that's fine but I believe the team would most of the time prefer the "single" classification.

@bernardsilenou @kwa20 This is kinda tricky. We should definitely find a way to use the fields that we already have - because we already have them. Right now they're only enabled for Germany (and thus Covid-19); what we could do is to add a new disease configuration parameter that allows to enable "extended case classification", which would make these three fields visible (by default OFF for all diseases in all countries, ON for Covid-19 in Germany, ON for Measles in Nigeria), and another parameter that allows to toggle between "single" and "multi" extended classification. "Multi" would work just as the three fields are working in Germany right now, "single" would add some logic that ensures that only one of the fields can be answered with "Yes". The easiest solution for this would be to automatically set the two other fields to "No" if "Yes" is selected in one of them, a better, but more complicated solution would be to add a custom dropdown that includes the three options and then maps to the three fields in the database.

What do you think?

@Chinedar

[MateStrysewske]

@generalkolo The disease configuration would be necessary because e.g. for Covid-19 it's important that all three variables are tracked because all three of them could be "Yes" at the same time.

[bernardsilenou]

@MateStrysewske Yes, we would need the disease configuration. What @generalkolo is saying is about the design. When we toggled on for "single" option, can we till have a design like the one i proposed?

From users perspective, I also think this design would be better to us.

If not possible, what about still adding a disease configuration for each option: multiple or single classification and add a new variable to be used for single option

[MateStrysewske]

@bernardsilenou Yes, such a design is possible, it's just more development effort because we have to create a field with quite some custom logic for it. :)

[bernardsilenou]

@MateStrysewske I think it is worth it to do it like this. Would you summaries and close the conversation? O have nothing new to add.

[generalkolo]

@MateStrysewske I think it is worth it to do it like this. Would you summarize and close the conversation? O have nothing new to add.

@MateStrysewske ?

[MateStrysewske]

@bernardsilenou @generalkolo I'll add a summary to this issue after the release and when the next sprint starts, so probably at some point this week.

[MateStrysewske]

Backend/API

• Add two new fields to DiseaseConfiguration:
  • extendedClassification
  • extendedClassificationMulti
• Add two new parameters to Disease:
  • defaultExtendedClassification - true for CORONAVIRUS and MEASLES
  • defaultExtendedClassificationMulti - true for CORONAVIRUS
• Write a datbase migration script that sets these values for the disease configurations for CORONAVIRUS and MEASLES (if they exist)

UI

• Remove the logic that displays the three fields clinicalConfirmation, epidemiologicalConfirmation and laboratoryDiagnosticConfirmation only for German systems

If for the disease of a case extendedClassification is TRUE and extendedClassificationMulti is TRUE and the case classification is CONFIRMED:

• Show the three fields as is the case for Covid-19 cases on German systems right now

If for the disease of a case extendedClassification is TRUE and extendedClassificationMulti is FALSE and the case classification is CONFIRMED:

• Hide the three fields and instead show a dropdown field that contains the captions of these three fields
• If one of the values is selected, when the case is saved, set the value of the field that matches the selected value to TRUE and the two other fields to FALSE
• When the case form is loaded, pre-select the dropdown with the value of the field that is TRUE (if any); if there are multiple fields set to TRUE, choose the last one that is TRUE in order of declaration in CaseDataDto right now (so laboratory > epidemiological -> clinical)

For any other case (=> extendedClassification FALSE and/or case classification is not CONFIRMED) don't show these fields at all

[StefanKock]

This ticket is not part of the already started Sprint 101

[bernardsilenou]

@StefanKock Please can we schedule it for 101.

[StefanKock]

@StefanKock Please can we schedule it for 101. Priotization is done at HZI.

[StefanKock]

Taken into Sprint 101 in exchange for #3003

[MateStrysewske]

4721 made clear that the way this issue was implemented isn't fully functional. These are the required changes:

Web app:

• Remove the new DiseaseConfigurationFacade.getDiseaseConfiguration method
• Instead, extend DiseaseConfigurationFacadeEjb with two new lists: extendedClassificationDiseases and extendedClassificationMultiDiseases that work similar to the other cache lists (i.e. fill them in loadData either with the database value or with the disease default if the database value is null)
• Add two new methods to DiseaseConfigurationFacade that request these values for a specific disease: usesExtendedClassification and usesExtendedClassificationMulti
• In the UI, call the first method to check whether extended classification is used, and if yes, call the second method (instead of calling the now removed getDiseaseConfiguration method)

Android app:

• Similar to the web app, add the new properties as lists to DiseaseConfigurationCache, and add helper methods to retrieve the values
• Use these helper methods instead of getDiseaseConfiguration when determining whether or not to display the extended classification controls in CaseEditFragment and CaseReadFragment

[MateStrysewske]

@JonasCir will take care of these changes

[bernardsilenou]

@MateStrysewske We jut did a test and realized that we did not mention that this variable should be added to detailed case export. Have added #4796

[JonasCir]

mh I messed up my commit messages :D