Retour de Hackathon: Projet de gestion des files d'attentes dans les services d'urgences

Le projet que notre équipe a retenu est le suivant : Comment répondre à l’incompréhension en salle d’attente dans les services d’urgences ? Les patients en service d’urgence sont souvent dans l’incompréhension : pourquoi d’autres personnes sont-elles prises en charge avant eux ? Pourquoi l’attente est-elle aussi longue ? Autant de question pour lesquelles le patient en salle d’attente n’a pas de réponse. Pour résoudre ces problématiques, nous souhaitions développer une application Web reliée à un système en salle d’attente. Celui-ci afficherait un ordre de passage anonyme intégrant un code couleur selon l’urgence de l’intervention.

Pour répondre à cette problématique, nous avons choisi de concevoir une plateforme SaaS avec une architecture Microservice. Le modèle SaaS nous permet de déployer rapidement le système dans tous les services d’urgence qui en aurait besoins. De plus, l’architecture Microservice nous permet d’être plus souple au niveau des technologies utilisés (stockage ou code), de la mise à jour des services et de l’hébergement. Vous trouverez ci-dessous la liste des technologies que nous avons utilisez pour mettre en œuvre notre solution :

  • ASP.NET Core Web API pour les APIs de la plateforme ;
  • Entity Framework Core pour le requêtage en base de données ;
  • Angular pour la partie front ;
  • Azure pour l’hébergement ;
  • SQL Database pour le stockage des comptes utilisateurs ;
  • Azure Table Storage pour le stockage des patients et de leur statut ;
  • Azure API Management pour la traçabilité et la sécurité des APIs exposées ;
  • Optical Character Recognition pour la détection de carte vitale ;

Notre application s’articule autour de 3 écrans principaux. Le flux d’échange de l’information est le suivant :

  • Formulaire de saisie des informations pour le patient, indiquant la où se trouve la douleur et quel est son degré d’intensité. Un numéro unique lui est alors attribué pour suivre son avancement dans la chaîne décisionnel ;
  • Envoi des infos au médecin du service afin qu’il évalue le degré de sévérité de l’urgence (urgent, peu urgent, pas du tout urgent …) selon les informations saisies par l’utilisateur. Il dispose tout de même du numéro du patient pour demander des informations si besoin ;
  • Liste des numéros de patient (pour la confidentialité) afin qu’il puisse suivre son avancement dans la salle d’attente.

Le premier écran est donc le formulaire de saisie. Nous avons utilisé Angular Material pour les composants graphiques, et nous avons rajouté un peu d’intelligence dans le formulaire : le patient peut prendre en photo sa carte vitale afin de préremplir ses informations. Cela permet notamment d’aller plus vite lors de l’arrivée de patient. Pour faire la détection de texte, nous utilisons OCR dans Azure qui sait analyser une photo et nous renvoyer les textes de la photo.
Le deuxième écran concerne la liste des fiches patients en attente de validation par le médecin. Cette liste se met automatiquement à jour lorsqu’un patient à validé son formulaire. Cela est possible grâce à SignalR et les WebSockets qui nous permettent de communiquer en temps réel entre le client Angular et le serveur ASP.NET Core.

Enfin, le troisième écran permet de suivre anonymement la liste d’attente avec les numéros et la couleur qui indique la sévérité de l’urgence.
Au niveau technique, voici l’architecture retenu pour notre solution SaaS :

Nos Web Services sont les suivants :

  • Authentification : connexion à un compte utilisateur (représentant le service d’urgence) via des identifiants. Ces derniers sont stockés dans une base SQL classique requêté via Entity Framework Core. Si l’authentification est correcte, le serveur renvoi un jeton JWT permettant au client de s’authentifier sur le reste de la plateforme ;
  • Data : service de gestion des données des patients. Nous avons utilisé Azure Table Storage pour stockés ces infos pour 2 raisons : c’est du NoSQL et comme nous n’avons pas de liens entre les données, cela nous convenait largement. Ensuite le mécanisme de partitionnement des données via une clé unique nous permet de gérer le côté SaaS de la plateforme au plus près des données. Cette clé unique, appelé PartitionKey, est ainsi le liant fort entre la plateforme SaaS et les données puisque chaque client de la plateforme va devoir rajouter cette clé dans toutes ses requêtes. Cet identifiant est donné lors de l’authentification.
  • OCR : service de reconnaissance de Carte Vital. Cette API accepte un fichier en entré, puis va l’envoyer au système de reconnaissance d’image dans Azure pour effectuer le traitement. L’API va ensuite traiter le résultat et le renvoyer proprement au client.

Le tout respecte les normes REST pour la communication entre le client et la plateforme au travers de Azure API Management. Ce service nous permet de centraliser les APIs des microservices au sein d’un même service de gestion d’API. De ce fait, cela nous permet de monitorer les services, de contrôler les flux entrant et sortant, de rajouter des restrictions et des quotas si besoin. Le client n’a plus qu’à connaître un seul domaine pour requêter la plateforme, et non un domaine par service.
L’hébergement est de l’Azure pour assurer la haute disponibilité de la plateforme SaaS. Nous aurions aimé aussi intégrer Azure Service Fabric comme orchestrateur de nos services afin de garantir un bon niveau de service lors de la monté en charge de la plateforme. Malheureusement nous manquions de temps et de recul sur la fonctionnalité pour le finaliser jusqu’au bout.
Bravo à toute l’équipe pour la réalisation de ce projet innovant quasiment prêt pour une production au bout de 48 heures de développement : Allan, François, Jordan, Pierre et Christophe.

Christophe Gigax

Technical Leader Microsoft et Angular  - MVP Visual Studio & Development Technologies