New gateway for transferring hospitalization data from PIA into SORMAS.

[jkheise]

Situation Description

Hospitalization data can be entered into SORMAS for cases.

Feature Description

In PIA, there will be a questionnaire to ask for hospitalization data of cases. The variables will be exactly the same as in SORMAS. These variables are to be transferred from PIA to SORMAS. A new gateway is needed for this.

[jkheise]

@FredrikSchaeferVitagroup @ghdoergeloh

[FredrikSchaefer]

Okay, that's quite a big thing. @jkheise One first question: is one hospital supposed to report to one health department (one sormas instance), or to several different ones?

[jkheise]

@FredrikSchaeferVitagroup It is supposed to be a user of SORMAS-SB, i.e. a case or a contact person who gives the information, which is then transmitted in SORMAS. Similar to the symptom transfer. Then it would refer to one specific SORMAS instance.

[FredrikSchaefer]

@ghdoergeloh @jkheise Okay, so we do everything as for the symptom diary (registration of persons etc..), just along with PIA uploading visits, there should be a way to transfer hospitalization data for a person?

One problem I see here is that the communication between PIA and SORMAS is person based. Hospitalization data is case specific. So PIA will send hospitalization data along with a person UUID. Shall SORMAS then attach the hospitalization data to the last created case of that person?

[FredrikSchaefer]

@jkheise Also, should it be indicated in SORMAS whether the hospitalization data was transferred from SORMAS-SB or not? One could, for example, show a small non-editable checkbox in the SORMAS-UI saying: Hopsitalization data transferred from external system. This would align with the visits data where it shows when the visit was uploaded from an external symptom journal like PIA.

[jkheise]

@FredrikSchaeferVitagroup yes, the person (cases) using SORMAS-SB for symptom transmission should also have the ability to transmit hospital data in addition to symptoms. Thus, there should be no new registration for this. It is only intended to be an additional questionnaire to the symptom questionnaire or even integratet in the symptom questionnaire.

[jkheise]

@FredrikSchaeferVitagroup your idea with the checkbox in the UI saying if the information is uploaded from an external symptom diary is great.

[FredrikSchaefer]

Then I would propose to

• [ ] Rename the VisitOrigin class to EntryOrigin

Use the EntryOrigin for visits (as before was used the VisitOrigin) and hospitalizations. This means to

• [ ] add an origin column to the hospitalization and hospitalization_history table (also in the mobile app). For existing hositalizations, this column should be set to (EntryOrigin.)USER, analogous to the implementation for visits.
• [ ] add the origin to the hospitalization dto and entity (also for the mobile app)
• [ ] implement that, for hospitalizations entered via the UI, the origin is automatically set to (EntryOrigin.)USER (also in mobile app)

Provide a new POST API endpoint [server-url]/hospitalizations-external/hospitalizations . This means to

• [ ] Create a new ExternalHospitalizationsRessource
• [ ] Add this endpoint to the ExternalHospitalizationsRessource and implement the required backend methods. It can be done similar to the POST endpoint for uploading visits in the ExternalVisitsResource. This endpoint should accept a list of ExternalHospitalizationDtos as input and link the data provided to the last created case for persons. If that does not work (e.g. because a person with the uuid provided in the ExternalHospitalizationDto does not exist, or when there is no case for the person), meaningful error messages should be returned.
• [ ] Add documentation of the new endpoint to the ExternalHospitalizationsRessource
• [ ] The origin of Hospitalizations added via the ExternalHospitalizationsRessource should automatically be set to EntryOrigin.EXTERNAL_JOURNAL
• [ ] Write a test similar to the ExternalVisitsResourceTest
• [ ] Generate a dedicated journal documentation similar to the implementation in this commit, so external developers relying on this API endpoint can monitor it for changes
• [ ] Write a summary of the changes related to the API endpoints, so external developers can be informed