Create/Update/Delete of vaccination/immunization should be considered as change of a case for reporting tool [3]

[SORMAS-ChristopherMeyer]

Problem Description

When vaccination data is updated in a case, this case is not treated as changed afterwards.

immunization data is generally attached to the person, but should always mark the case as changed when a change is made.

otherwise, when using the filter "only cases changed since last shared with reporting tool", this case will not be displayed.

Steps to Reproduce

1. Open a case (make sure it was send to the reporting tool at least once before)
2. apply changes to vaccinations
3. save
4. open the case directory
5. look for the filter "only cases changed since last shared with reporting tool"
6. the case will not appear

Proposed Change

Based on discussion below:

• [x] Extend CaseService.createChangeDateFilter method with an optional param to include the change dates of relevant vaccinations AND immunizations. The relevance of a vaccination is defined by it's vaccination date being before the case's onset date or if that is not defined the report date (see VaccinationService.isVaccinationRelevant). Make sure to either let VacciantionService provide this part of the criteria or at least link both aspects of the logic.
• [x] When deleting a vaccination, the change date of the parent immunization has to be incremented. This can probably be best done by added a "incrementChangeDate" method to the BaseAdoService which calls lock(immunization, LockMode.OPTIMISTIC_FORCE_INCREMENT) on the JPA session.
• [x] Call createChangeDateFilter with includeExtendedChangeDateFilters, because person and samples should also be considered for the reporting tool filter.

Acceptance Criteria

1. A case is shown in the filter when either a related vaccination is created, update or deleted.
2. A case is shown in the filter when it's persons armedForcesRelationType is changed
3. A case is shown in the filter when a sample is created, updated or deleted.

Additional Information

Technically the behavior is not wrong because something was changed on the person and not on the case. but with other personal data like date of birth this filter works. therefore it is a bug.

[MateStrysewske]

@cmeyerhzi I don't consider this a bug because it was never specified like that, and also is a semantic change from how the system operates. Changed the labels accordingly.

[markusmann-vg]

As the immunizations/vaccinations are linked to a person and not a case, a wanted change in the specific case has to be specified separately and cannot be expected. So it's a change and not a bug.

[SORMAS-ChristopherMeyer]

That's right. But why does it work with other personal data like date of birth?

[kwa20]

@MateStrysewske When you say it would be a semantic change to how the system operates, does that imply that changing this might be a problem or rather difficult? From a contextual perspective, it would make sense to include this for the filter, even if the case change date itself wouldn't change. I assume that this would have performance implications, though, which we were able to get rid of previously

[MateStrysewske]

@cmeyerhzi Because that was also specifically requested at some point in the past. @kwa20 Not quite sure about the difficulty, probably not that difficult, but it would indeed have potentially significant performance implications

[MartinWahnschaffe]

We ran into a problem when trying to estimate it, so I had another look at it.

There first question is about how to change the filter logic. The logic is currently implemented based on a call ExternalShareInfoService.buildShareCriteriaFilter (which then calls buildLatestSurvToolShareDateFilter) in combination with a predicate provided by CaseService.createChangeDateFilter. Interestingly this predicate does not include the person's change date so in theory a change to the date of birth would not lead to the case being synced again. Nevertheless, this is still working, because a change to the date of birth will re-calculate the age of the case and thus change the case itself. The best way to include the change date of relevant vaccinations here would probably be to extend the CaseService.createChangeDateFilter method with an optional param to include the change dates of relevant vaccinations. An alternative to this would be solution (2) of the points mentioned below.

This will work when a vaccination is created or updated (with the exception below). It will not work when deleting a vaccination or when changing the vaccination date to a value that is no longer relevant for the case. There are multiple options how to deal with this:

1. Update the change date of the case when this happens -> very bad design style, because changing a loosely related entity should really not affect the change date of the case. E.g. this would lead to confusions when looking at the history data, it would lead to unnecessary synchronizations and more
2. Introduce a new date field latestSurvToolRelevantChildChangeDate that is always updated when a related entity ("child") that is relevant for the surveillance tool is changed or deleted. Implementing this will be a bit tricky, because it should be done in a way that does not affect the change date of the case itself, because this field should not be considered to be a part of the actual case data, but instead of "management" data for the case. Another example for such a field would be the completeness of the case. A good way to deal with this would be to move both fields into a dedicated entity.
3. Ignore it, because it may not be a relevant use case. Reason: When deleting a vaccination or changing the vaccination date in a way that makes it no longer relevant for the case, the user would also have to manually update the vaccination status of the case anyway, which would then lead to the case showing up in the filter. This would not happen though, when user the forgets to do this OR when the case still has another vaccination, so the vaccination status does not change.

[MartinWahnschaffe]

Discussed with @kwa20 @JaquM-HZI @cmeyerhzi @SahaLinaPrueger: Option 3 is not possible, because these information are subject to reporting.

• [x] In addition we have to make sure that deleting samples also leads to the case being listed.
• [x] Same for changing the person (e.g. armedForcesRelationType)

An alternative to option 2 would be to consider the change date of the related immunizations and to make sure that deleting a vaccination updates the change date of the immunization. Writing this, I realize that this would not be a perfect solution, because we don't have a proper "relevance" criteria for immunizations. Currently all immunizations of the person that have the same disease are relevant for a case.

New question: If a person has two cases (one 2021 and one 2022) and now I delete or add a vaccination, the change date of the related immunization would be updated and both cases would be shown in the filtered list. Would this be ok? The same would happen for any other change that is made to the immunization.

If this is not ok, then using the change date of the immunization would not be an option.

[kwa20]

@MartinWahnschaffe

New question: If a person has two cases (one 2021 and one 2022) and now I delete or add a vaccination, the change date of the related immunization would be updated and both cases would be shown in the filtered list. Would this be ok? The same would happen for any other change that is made to the immunization.

This would actually be good because with how immunizations work in SORMAS, they have implications on all cases related to the same disease and, therefore, changes in the immunization should be taken into account in all related cases. It might show them even if they're false positives but that shouldn't be a problem.

[MartinWahnschaffe]

Ok, it looks like the easiest way to achieve what we need is to do the following:

• Extend CaseService.createChangeDateFilter method with an optional param to include the change dates of relevant vaccinations AND immunizations. The relevance of a vaccination is defined by it's vaccination date being before the case's onset date or if that is not defined the report date (see VaccinationService.isVaccinationRelevant)
• When deleting a vaccination, the change date of the parent immunization has to be incremented. This can probably be best done by added a "incrementChangeDate" method to the BaseAdoService which calls lock(immunization, LockMode.OPTIMISTIC_FORCE_INCREMENT) on the JPA session.
• Call createChangeDateFilter with includeExtendedChangeDateFilters, because person and samples should also be considered for the reporting tool filter.

This approach is clearly easier than introducing a new field that keeps track of this. The down-side is that it will result in false-positives, which is acceptable based on @kwa20 and @SahaLinaPrueger .

I will update the ticket description accordingly.

[leventegal-she]

There is one edge case that couldn't be handled: The deletion of any vaccination results in a changed case since last share because the change date incrementation is done on a generic place, where we can't do it only for relevant vaccines, and it is not possible to create a query filter to check if a delete of a a relevant vaccine caused the change.

[SahaLinaPrueger]

@AndyBakcsy-she @leventegal-she I have one question about this issue: Does this issue only "apply" to changes made in the future or does this issue "apply" to changes made in the past, too? More specifically: when the update to 1.74 is done, will it be the case that when the filter "only cases changed since last shared with reporting tool" is activated, many more cases will suddenly be visible for the health departments? In both cases we need to prepare the health departments, that's why i ask.

[leventegal-she]

@SahaLinaPrueger It will apply to the changes int the past too. So if there are cases where only the vaccination got changed since the last share the will appear. Except where only some vaccination were deleted, we can't mark those as change because we don't really know when they were deleted.