On 11 March 2020, the World Health Organization (WHO) considers the COVID-19 epidemic a pandemic. The virus develops in more or less dangerous forms. The most severe form affects the lungs, resulting in respiratory failure. The patient must then be placed in resuscitation for a period of one to fifteen days.
Nancyclotep is a nuclear imaging research laboratory founded by Professor Gilles Karcher in 2007.
As a result, Nancyclotep enlisted the help of Polytech Services Nancy (PSN), which, despite the containment, with the help of a team of students, implemented a software solution to assist doctors in their function.
As noted above, some cases of COVID-19 require hospitalization in the resuscitation room and equipment to provide effective care.
The number of equipped seats available is limited. It is therefore imperative to be able to determine the evolution of the number of patients in the short term (a few days), and medium term (a few weeks). This allows the means to be adapted accordingly.
The project involved designing a web application to predict the flow of patients into the resuscitation room (training management).
This application had to be modular, fast and available on multiple media (computer, mobile, tablet).
This article traces the progress of the project from its development to its commissioning.
This project took place in five phases:
- A phase of need analysis,
- Another set-up of the production environment,
- A phase of development of the internship management modules,
- Another phase of integrating multilingual content,
- A final phase of testing and online.
Phase 1: Need Analysis
PSN analyzed the sponsor's need and identified the tools to be put in place to specifically address this need. So we wrote the specifications (detailed afterwards). It is an essential document in the development and implementation of a project. It formalizes the expectations and needs of the sponsor, setting a course of action for the project.
Phase 2: Setting up the software architecture and databases
The students set up the architecture of the software with diagrams, especially under UML (language used to schematically represent the organization of a system) in order to have a base on which the application relies. The UML diagram was translated into a MySQL database (database management software) that contains the information to be processed in the back-end.
Phase 3: Back-end and front-end development
(The front-end is the user interface and the back-end is the part inaccessible to the user).
After developing the structure of the software, his back-end development was carried out. To do this, the team used the Flask and Python 3 web framework (language to provide an optimized development space) coupled with the developed database.
In parallel with the development of the back-end, the front-end part was developed. This is using web languages: HTML, CSS, JavaScript (classic language of web applications or websites) in a format compatible with internet browsers used by doctors (especially Internet Explorer 11 and Firefox).
Phase 4: Testing and corrections and writing documentation
The development was followed by a phase of tests to correct any problems encountered. This phase allowed the software to be refined with the consideration of the caregivers' comments.
Phase 5: Deployment and automation of start-up
Accompanied by Doxaca, the application was deployed on the CRHU server. The production was automated using Jenkins and Sonarqube software (in order to carry out a quality control of the code).
After this part was completed and the software operated, the deliverables were defined.
The deliverables correspond to the entire commentary code of the application as well as the instructions for the use of the software. A document explaining how the algorithm works was provided in PDF format.
Specifications
Basic principle and assumptions
We started with epidemiological hypotheses and models that provided an estimate of the evolution over time of the number of infected patients in a territory, and which allowed an estimate of the number of severe forms justifying a passage to resuscitation. This curve was the "entry function": E(t).
It made it possible to make short- and medium-term estimates. It was updated and re-evaluated, improving its accuracy with new data over time.
We chose a hypothesis on the likelihood of a patient's length of stay in resuscitation:
- P(n) – probability of a patient remaining in resuscitation (n – 1 to 15)
- This P(n) curve represents the "impulse response" of the system. The number of patients remaining in resuscitation can be deduced in the days following a sudden arrival of 100 patients.
- Several hypotheses can be generated and tested (depending on feedback).
Simplistically, the number of patients in resuscitation was the convolution product of the E input function and the "impulse response" P.
Simple medium-term simulation
We chose and imported an epidemiological curve E(t). Then we selected the impulse response P. Finally, we calculated (digital convolution product) the predictive curve of the number of patients in S(t) resuscitation.
You had to pay attention to the initial conditions:
- Choose the most recent epidemiological estimate , (hence frequent updates)
- At J0 (day 0), there are already patients in resuscitation and the question of their "seniority" at J0, to supplement the entry data prior to J0 (from J0 to J-15)
- Either we're able to get to know her.
- Either an estimate is mad
eThis allowed a simple medium-term estimate of the occupation of the resuscitation places, very dependent on hypotheses and in particular epidemiological hypotheses. The virus is still unknown at the time of completion of this project.
Simulation tools can be used to test the impact on resuscitation occupancy: - Several epidemiological hypotheses (plan to implement epidemiological parametric models)
- Several exit strategies for resuscitation patients
Short-term monitoring and forecasting tools
From the previous base, we needed to be able to adapt the model to reflect the observed reality, changes in epidemiological forecasts and one-off events.
Every day we had to be able to:
- Define the new initial conditions based on the actual occupation observed
- Update new epidemiological forecasts
- Changing the management of patient discharges in resuscitation P(n)