[DEMIS2SORMAS] Introduce processing for physician reports [8]

[kwa20]

Situation Description

DEMIS introduced physician reports as a new option to notify health departments about notifiable infections. Thus, in addition to providing initial UI support, it is also necessary to let users properly process such messages to make the work in health departments more efficient.

Feature Description

Introduce the option to process physician reports

• [x] Add a PROCESS button to messages of the type PHYSICIANS_REPORT
  • [x] Open the Pick or create person pop-up with the same behaviour as seen for lab messages
  • [x] Only provide the option to create select or create cases when processing physician reports
    • [x] If a user creates a new person, open the case creation form immediately
    • [x] If a user selects an existing person, display a list of cases associated to the person if any exist and provide the option to alternatively create a new case as seen for lab messages
    • [x] If a user selects an existing person but the person does not have an associated case, open the case creation form immediately
      • [x] In that scenario, the selected person might have associated contacts or event participants. If that is correct, follow up the case saving with the Conversion to case pop-up if applicable before proceeding with further processing windows.
  • [x] When the case was saved, open a side by side view with the following case tabs, jumping directly into the hospitalization tab.
    • Case, Case person, Hospitalization, Symptoms, Epidemiological data, Immunizations (new view compared to existing case tabs)
  • [x] Add BACK, DISCARD and NEXT buttons to the respective forms
    • [x] The BACK and NEXT buttons should allow the user to navigate through the tabs in the displayed order (BACK: one tab to the left, NEXT: one tab to the right).
    • [x] When the user navigates tabs, the respective tab should be highlighted as seen in other forms so users know which section they are currently working on.
    • [x] When clicking DISCARD, the processing should be canceled and the user should get redirected back to the messages directory.
    • [x] The last tab should have SAVE AND OPEN CASE and SAVE buttons instead of the NEXT button. Those buttons behave the same as seen when processing lab messages. Instead of relating the lab message to a chosen sample, relate it to the chosen case (create a case_id column in the labmessage table for it).
    • [x] The Case tab (the first one) should have no BACK button.

Side by side view:

• [x] Create a side by side view of the mentioned tabs above and display the same forms as seen in cases without additional cards on the right side. Otherwise, the tabs should contain all the information that the forms usually have
• [x] Create a specific immunization tab for processing the physician report (in contrast to card in case entity)
  • [x] For Immunizations, only list the vaccinations for the related disease
  • [x] There should be an extended editable form view and a collapsed view
    • [x] Editable view: The form should have a ADD VACCINATION button which opens a new vaccination creation form. At the end of that form, there should be a DONE button for finishing the edit and adding the vaccination. There should also be a CANCEL button in order to simply close an edit form without adding a vaccination.
    • [x] Collapsed view: When a vaccination exists or was edit, it should get displayed in this view. The view should display the vaccineName and the vaccinationDate.
      • [x] Add an edit button: upon clicking, extend the form so it becomes editable again. Clicking on DONE will collapse the edited vaccination entry again. Only save the edited entry when saving the overall form. A CANCEL button should also collapse the expanded edit form again without keeping the edited fields.
      • [x] Add a deletion icon as a button: upon clicking, remove the entry from the list. Only delete the vaccination entry if the overall form is saved.

Some remarks regarding saving

• [x] Whenever the user clicks SAVE or NEXT, the currently shown data should be saved. Before saving, a processed-in-meantime check should be performed, just like for lab messages. Similarly, when the physician's report was processed in meantime, and a new case was created by the (interrupted) user, add a button to delete that case.
• [x] Whenever a user clicks BACK or navigates to another tab by clicking on the tab directly (instead of clicking NEXT), show the usual UnsavedChanges popup if necessary.

-> This means that the DISCARD button just discards changes from the current view/tab, not previous creations/changes.

Possible Alternatives

Additional Information

[FredrikSchaefer]

We probably need to decide when to save what... From a functional perspective, it would probably be best to not save anything, until the processing is finalized. But that is probably hard to implement (and also is not done for lab messages).

There is not lifecycle management for physician's reports (yet). So there should not be any physician's reports relating to each other. Still, what to do when a user selects an existing case when processsing, and the case data differs from the physician's report's data? E.g. what to do when the first name is different? Do nothing?

After processing, should the physician's report be related to the case?

[abrudanancuta]

Validated on local env with the version: 1.73.0-SNAPSHOT (3d0fd59)