Extend mSERS functionality

[MartinWahnschaffe]

Situation Description & Motivation

The aggregate reporting in SORMAS (mSERS) allows poe and hospital informants to report cases, lab confirmations and deaths for disease that don't use actual case-based surveillance. To do this they use the mobile app. District users (surveillance officers) would also need this functionality, but currently don't have access to it. Regional and national users can do the same and also report numbers for whole districts, regions or the instance. All of those numbers are currently aggregated within taking the jurisdiction levels into account to avoid overcounting/duplicates.

High-Level Explanation

The goal of this epic is to achieve the following high-level goals:

1. Introduce age groups for aggregate reporting
2. Correctly group reported data by jurisdiction and epi week when aggregating totals
3. Allow surveillance officers to take part in reporting by reporting for the whole district or adding missing reports for individual facilities
4. Take care of duplicates that may be introduced by multiple users reporting for the same jurisdiction

First Step

• [x] #8967
• [x] #8974

Second Step

• [x] #9068
• [x] #9052
• [x] #9073
• [x] #9119
• [x] #9084
• [x] #9039
• [x] #9605

Identified Bug

• [x] #9121
• [x] #9885
• [x] #9892
• [x] 9845
• [x] #10026

Changes

• [x] #9623
• [x] #9847
• [x] #9629
• [x] #9822
• [x] #9770
• [ ] #9801
• [ ] #9703
• [ ] #10169

Optional

• When creating a district report, the system could automatically sum up the numbers from the facilities+PoEs and pre-fill the creation form. Same for region reports
• For the situation of a regular adjustment of age groups (not just a fix of a wrongly defined age group), we actually need a better solution. Ideally each configuration entry should have an optional usage time period, so that an age group can be valid until a specific date and another age group starting at a specific date. A separate issue will be created for this.

Additional Information

For age group formatting see: https://github.com/hzi-braunschweig/SORMAS-Project/wiki/Disease-Configuration-Options

[MartinWahnschaffe]

@KristinaBorch @bernardsilenou Can you provide some details on the overall mSers extension? Who is using the feature in which context and why should it be extended.

Please also add a few use cases that explain: How would a surveillance officer use the functionality. How does he/she cooperate with hospital informants in the same district? Who is looking into the reports? Why/when/where are they exported?

[bernardsilenou]

@MartinWahnschaffe

1. Even though regional users have the option to create reports the mSERS module is only for hospital informants and surveillance officers
2. The motivation for this extension is that in some countries the SO mainly does aggregated data reporting. Not all facilities in a district are using sormas but the SO is expected to submit a complete report (representing the sum of reports of all facilities in their districts) for all notifiable diseases.
3. As a SO, I should be able to create a report for either 3.1 my districts: this is a report representing the sum of all reports in my district. I think we should not validate the counts using the individual reports for all facilities because some of the facilities in the districts may not be using sormas. 3.2 a facility in my district: if the majority of facilities in my district are using sormas, then I may just need to add a report for the facilities that have not been reported to obtain my report for the week. 3.3 Maybe there is a better solution but I can suggest that we should not combine reports submitted for a district with those submitted for a facility. We can add a filter for users to decide which of the reports to export
4. Those who view the report are all users. Those who export the report analysis are all users also, but predominantly regional and national users.
5. why export data: to do analysis to write situation reports
6. When: every week, the calendar date range for the report can be the current week or all the weeks in the past years. That is why we need the option to export on weekly basis all the reports for the last 2 years for example
7. Where: on the web app only. the current export on the web is not on weekly scale but combined for the whole time interval. We can add a checkbox like "weekly interval"

[MartinWahnschaffe]

Ok, I'd suggest the following:

First step

We start with adding age groups to the system (#8967) and adding the additional columns,the grouping per week and the option to pick on which level data should be aggregated to the aggregated reports view & export of the UI (#8974). ~~Maybe we can already allow surveillance officers to create reports - those will face the issues mentioned above, though. I'll look into this.~~ Update: I don't think this would be a good idea for the first step. Allowing surveillance officers to create reports for their district will mess up the total numbers of that district, as long, as we don't consider it when aggregating numbers, so this should instead be done as a part of the second step.

Second step

Next we only allow one aggregated report per jurisdiction and make sure that all users of that jurisdiction have access to it and can edit it (#9039 and #9073). Surveillance officers need to be able to create reports for their district (#9052). I'd suggest that when creating a district report, the system could automatically sum up the numbers from the facilities+PoEs and pre-fill the creation form. Furthermore we add a view to the mobile app to display aggregated reports of facilities and PoEs (#9084). Finally we no longer combine reports of different jurisdiction levels in the report view of the UI. E.g. when data is aggregated on district level, the system will rely on the reports directly created for the district and only fall-back to aggregating facility-level reports, when there is no report for the district (#9068).

I'll now start by refining the issues for the first step and then go on to create the four issues for the second step.

[MartinWahnschaffe]

@bernardsilenou In the examples you are using COVID, Cholera and other disease that currently are entered case-based. Is this just coincidence or is there a plan to use it like this in another country?

[MartinWahnschaffe]

@bernardsilenou @KristinaBorch @Juliane-D

I went through all requirements that you have provided and tried to address everything in the tickets created by you and a few more. Please go through this epic and all the issues linked here and let me know whether I got you right and the proposed solution makes sense to you. Some aspects of it are a bit tricky and technical, so if anything is not clear, just ask - it's very likely that the same question will come up later during implementation anyway.

[bernardsilenou]

@MartinWahnschaffe https://github.com/hzi-braunschweig/SORMAS-Project/issues/9038#issuecomment-1117229581 It is not a mistake, rubella exists in both reporting systems, it all depends on the country. I hope this is not an issue since we do not mix disease from aggregate and case based-module

[adinaflorea9]

Aggregated reports can be set in the future: in the 'Create new aggregated report' form, by selecting the option 'Specify', the user can edit the year and epi week of the report they are creating.

They can select any epi week, even from the future.

Proposed change Add a date validation for the 'Epi Week' field in the 'Create new aggregated report' form. Trigger the date validation if users select an epi week that is after the current epi week (any epi week in the future).

Additional Information: With the changes brought by #9068, in the 'Aggregate reporting' tab, the reports without jurisdiction are visible only when the 'Grouping' and the 'Region/District/Facility/Point of Entry' fields are cleared. This could be counter intuitive for users if they create a report without jurisdiction, as the grouping is by default set to 'Region'.

[adinaflorea9]

#9822 - logged today by @bernardsilenou covers the behavior described in the comment above regarding the reports that are set in the future.