Le 11 mars 2020, l’Organisation Mondiale de la Santé (OMS) considère l’épidémie de COVID-19 comme une pandémie. Le virus se développe sous des formes plus ou moins dangereuses. La forme la plus grave atteint les poumons, entraînant une insuffisance respiratoire. Le patient doit alors être placé en réanimation pendant une durée allant d’un à quinze jours.
Nancyclotep est un laboratoire de recherche en imagerie nucléaire fondé par le Professeur Gilles Karcher en 2007.
De ce fait, Nancyclotep a fait appel à Polytech Services Nancy (PSN), qui, malgré le confinement a, avec l’aide d’une équipe d’élèves mis en place une solution logicielle permettant d’aider les médecins dans leur fonction.
Comme énoncé précédemment, certains cas de COVID-19 nécessitent une hospitalisation en salle de réanimation et du matériel afin d’apporter des soins efficaces.
Le nombre de places équipées disponibles est limité. Il est donc impératif de pouvoir déterminer l’évolution du nombre de patient à court terme (quelques jours), et moyen terme (quelques semaines). Cela permet d’adapter les moyens en conséquence.
Le projet consistait à concevoir une application web dans le but de prévoir le flux de patient en salle de réanimation (gestion de stages).
Cette application devait être modulaire, rapide et disponible sur plusieurs supports (ordinateur, mobile, tablette).
Cet article retrace le déroulement du projet de son développement à sa mise en service.
Ce projet s’est déroulé en cinq phases :
- Une phase d’analyse du besoin,
- Une autre de mise en place de l’environnement de production,
- Une phase de développement des modules de gestion de stage,
- Une autre phase d’intégration d’un contenu multilingue,
- Une dernière phase de test et mise en ligne.
Phase 1 : analyse du besoin
PSN a analysé le besoin du commanditaire et a déterminé les outils à mettre en place afin de répondre précisément à ce besoin. Ainsi nous avons rédigé le cahier des charges (détaillées ensuite). C’est un document essentiel à l’élaboration et la réalisation d’un projet. Il permet de formaliser les attentes et les besoins du commanditaire, fixant une ligne de conduite au projet.
Phase 2 : Mise en place de l’architecture du logiciel et des bases de données
Les étudiants ont mis en place l’architecture du logiciel avec des diagrammes, notamment sous UML (langage utilisé afin de représenter schématiquement l’organisation d’un système) afin d’avoir un socle sur lequel l’application se repose. Le diagramme UML fut traduit en une base de données MySQL (logiciel de gestion de base de données) qui contient les informations à traiter dans le back-end.
Phase 3 : Développement back-end et front-end
(Le front-end c’est l’interface utilisateur et le back-end c’est la partie inaccessible à l’utilisateur).
Après avoir mis au point la structure du logiciel son développement back-end fut effectué. Pour ce faire, l’équipe a utilisé le framework web Flask et Python 3 (langage permettant de constituer un espace de développement optimisé) couplés à la base de données développée.
En parallèle du développement du back-end, la partie front-end fut développée. Cela en utilisant des langages web : HTML, CSS, JavaScript (langage classique des applications web ou sites internet) dans un format compatible avec les navigateurs internet utilisés par les médecins (en particulier Internet Explorer 11 et Firefox).
Phase 4 : Phase de tests et corrections et rédaction de la documentation
Le développement fut suivi d’une phase de tests afin de corriger les éventuels problèmes rencontrés. Cette phase a permis d’affiner le logiciel avec la prise en compte des remarques des soignants.
Phase 5 : Déploiement et automatisation de la mise en production
Accompagnée par Doxaca, l’application fut déployée sur le serveur du CRHU. La mise en production fut automatisée grâce au logiciel Jenkins et Sonarqube (afin d’effectuer un contrôle de la qualité du code).
Après que cette partie soit terminée et le logiciel opérationnel, les livrables furent définis.
Les livrables correspondent à l’intégralité du code commenté de l’application ainsi que de la notice d’utilisation du logiciel. Un document explicatif du fonctionnement de l’algorithme a ainsi été fourni au format PDF.
Cahier des charges
Principe de base et hypothèses
Nous sommes partis des hypothèses et modèles épidémiologiques qui fournissaient une estimation de l’évolution dans le temps du nombre de patients infectés dans un territoire, et qui permettaient d’en déduire une estimation du nombre de formes graves justifiant un passage en réanimation. Cette courbe constituait la « fonction d’entrée » : E(t).
Elle permettait de faire des estimations à court et moyen terme. Elle fut mise à jour et réévaluée, permettant d’améliorer sa précision grâce aux nouvelles données apportées au cours du temps.
Nous avons choisi une hypothèse sur la probabilité de durée de séjour d’un patient en réanimation :
- P(n) = probabilité qu’un patient reste n jour(s) en réanimation (n = 1 à 15)
- Cette courbe P(n) représente la « réponse impulsionnelle » du système. On peut en effet en déduire le nombre de patients restant en réanimation dans les jours qui suivent une arrivée brutale de 100 patients.
- Plusieurs hypothèses peuvent être générées et testées (en fonction du retour d’expérience).
De manière simpliste, le nombre de patients en réanimation était le produit de convolution de la fonction d’entrée E et de la « réponse impulsionnelle » P.
Simulation simple à moyen terme
Nous choisissions et importions une courbe épidémiologique E(t). Ensuite, nous sélectionnions la réponse impulsionnelle P. Enfin, nous calculions (produit de convolution numérique) la courbe prévisionnelle du nombre de patients en réanimation S(t).
Il fallait être attentif aux conditions initiales :
- Choisir l’estimation épidémiologique la plus récente, (d’où des mises à jour fréquentes)
- À J0 (jour 0), il y a déjà des patients en réanimation et se pose la question de leur « ancienneté » à J0, pour compléter les données d’entrée antérieures à J0 (de J0 à J-15)
- Soit on est en capacité de la connaître
- Soit on fait une estimation
Ceci a permis une estimation simple à moyen terme de l’occupation des places de réanimation, très dépendante des hypothèses et en particulier des hypothèses épidémiologiques. Le virus étant encore méconnu à la date de réalisation de ce projet.
On peut se servir d’outils de simulation pour tester l’impact sur l’occupation des réanimations : - De plusieurs hypothèses épidémiologiques (prévoir d’implémenter des modèles paramétriques épidémiologiques)
- De plusieurs stratégies de sortie des patients de réanimation
Outils de suivi et prévision à court terme
À partir de la base précédente, nous devions pouvoir adapter le modèle en fonction de la réalité observée, des évolutions des prévisions épidémiologiques et des événements ponctuels.
Il fallait chaque jour pouvoir :
- Définir les nouvelles conditions initiales en fonction de l’occupation réellement observée
- Mettre à jour les nouvelles prévisions épidémiologiques
- Modifier la gestion des sorties de patients en réanimation P(n)