Projet RadioCheck

Dans le domaine de la médecine, la radiothérapie est une spécialité ayant pour but le traitement des cancers au moyen d'accélérateurs de particules, machines de haute technicité qui permettent d'émettre des rayonnements ionisants en direction des tumeurs ciblées.

Le Service de radiothérapie du CHU de Bordeaux (situé à l’hôpital Haut-Lévêque à Pessac) est doté de plusieurs de ces accélérateurs pour lesquels de nombreux contrôles qualité sont nécessaires afin de s'assurer de leur bon fonctionnement. Les mesures et vérifications issues de ces contrôles font l'objet de validations systématiques et d'un suivi particulier.

L'application mise en œuvre (RadioCheck) couvre l'ensemble de la chaîne d'information des tests appliquées aux machines de radiothérapie. Cette chaîne d'information fait intervenir plusieurs étapes sur lequelles nous revennons plus en détails ci-dessous.

Les tests sont définis dans l’application comme des procédures de validation ayant pour objectif de vérifier la bonne configuration et le bon fonctionnement des machines du service. Les spécifications de ces tests sont fournis par le "Journal Officiel" et suivent des processus d’amélioration continue.

Les tests sont — dans l’application — caractérisés par les éléments suivants :

• Un ensemble de données d'entrée sous la forme de valeurs numériques et/ou ternaires (oui / non / indéterminée) ;
• Un calcul sur ces données, exprimé par l’intermédiaire d’un script ;
• Un ensemble de résultats (déterminé à partir du calcul sur les données) sous la forme :
  • d'une valeur ternaire (succès / échec / indéterminée) ;
  • d'une chaîne de caractères (déroulement du calcul, affichage de variables, etc.) ;
  • d'une valeur numérique.

Les spécifications de tests pouvant être amenées à évoluer, l'application offre la possibilité de définir et de redéfinir ces procédures. On appellera dans la suite modèle de test (ou simplement modèle), l’objet représentant la structure d'un test (i.e. définissant les trois éléments précédents) et permettant l’instanciation de tests.

La création de modèle est effectuée en deux phases.

Une première phase permet de spécifier l'ensemble des données d'entrée du test. Celles-ci sont représentées par différentes options :

• Un type (numérique ou ternaire) ;
• Un nom (avec possiblement l’unité utilisée) ;
• Des contraintes appliquées :
  • Contrainte d’existence : permettant d’obliger l’utilisateur à renseigner une valeur ;
  • Contrainte d’intervalle : permettant d’obliger l’utilisateur à renseigner une valeur appartenant à un intervalle donné.

Une seconde phase permet de définir le calcul et la structuration du résultat. Cette phase est gérée par l'intermédiaire d'un champ « Expression du calcul ». Dans ce champ est renseignée la procédure de calcul associée au modèle. Cette procédure est un algorithme : une suite d’instructions qui permet de déterminer un résultat à partir d’un ensemble de données d’entrée. Des fonctions de calculs ont été mises en œuvre pour assurer la gestion des nombres à virgule flottante (garantissant ainsi une précision suffisante au besoin du service). Il est possible de faire intervenir dans ce calcul des valeurs de références ou des valeurs métiers spécifiques qui sont gérées dans d'autres sections de l'application (description plus bas).

Afin d'aider à la définition de modèle, un système de vérification permettant de tester le modèle créé a été mise en œuvre. L’application propose également un dispositif de gestion d’erreurs servant à prévenir des possibles incohérences de calculs pouvant advenir.

La plupart des tests appliqués aux machines étant effectués de manière périodique, un système de gestion de tâches (agenda et notifications) assurant l'organisation des échéances de tests a été mise en place. La phase de planification permet d’associer les modèles de tests à appliquer aux machines pour une périodicité donnée (journalière, hebdomadaire, mensuelle, etc.). Ce système offre plusieurs procédures permettant la création d’événements (uniques ou périodiques) tout en gérant les cas particuliers pouvant survenir (jours fériés, week-end, etc.).

Une fois le processus de planification organisé, les utilisateurs de l’application ont la possibilité de résoudre les tests (i.e. de saisir les données d’entrée). Les données d’entrées sont principalement constituées de mesures effectuées sur les machines du service. En fonction du modèle sur lequel est basé le test à effectuer, l’application va générer un formulaire de saisie correspondant. C’est le processus de génération dynamique de formulaire : chaque entrée définie dans le modèle est traduite en un champ de formulaire (avec gestion du type, du nom et des contraintes).

Une fois le formulaire rempli et soumis, l’application génère un environnement de calcul. C’est dans cet environnement qu’est évalué le script – précédemment défini dans le modèle – sur les données renseignées dans le formulaire.

Recherche et Extraction

Dès lors qu’un test est résolu, l’ensemble des données saisies et l’ensemble des données générées sont stockées dans la base de données. L’application dispose d’un moteur de recherche permettant de naviguer facilement dans ces données. Il est possible d’effectuer une recherche basée sur différents facteurs :

• Recherche par date / par intervalle de temps ;
• Recherche par mots clés ;
• Recherche par critères : Il est possible d’effectuer des recherches aussi précises que possible par la sélection de critères de recherche sur l’ensemble des données constituant les tests (résultats, états de validation, machines concernées, etc.).

L’application traduit les données saisies dans le formulaire de recherche en une requête SQL qui sera ensuite évaluée pour pouvoir présenter les résultats correspondants.

Une fois la requête traduite et exécutée, l’utilisateur a la possibilité d’exporter les données au format CSV. Diverses options lui permettent de trier, et de sélectionner des sous-ensembles de données. Les données exportées peuvent enfin être analysées au travers d’outils externes (logiciel tableur, scripts Python, etc.).

Bien que le cœur de l'application réside dans la gestion des tests, certaines fonctionnalités complémentaires ont été mises en œuvre afin d'intégrer à l'application les processus associés à la vérification des machines ou permettant d’améliorer l’utilisation de l’application.

Tout d’abord, un système d’authentification a été mise en œuvre dans le but de sécuriser l’accès à l’application et à ces données. Le système assure la gestion des utilisateurs et de leurs rôles associés : Manipulateur, Physicien et Administrateur. Cela permet d’associer chaque action à un utilisateur et d’isoler les différentes tâches en minimisant ainsi les possibles erreurs de manipulation. Le schéma suivant présente une carte simplifiée de l’application (les couleurs représentant les rôles d’accès aux différentes fonctionnalités) :

Un cahier des pannes a été réaliser dans l’objectif de déclarer les différents problèmes survenant sur les machines. Cet outil permet le référencement des pannes ; classifiées par type et par degré de criticité. L’utilisateur peut définir de nouveaux types de pannes et signaler les pannes comme « Résolu ». La fonctionnalité de recherche et d’extraction est également disponible dans le cadre du cahier des pannes : les mêmes facteurs de recherches sont disponibles, la recherche par critère étant adaptés aux constituants des pannes (criticité, type, etc.).

Les utilisateurs ont la possibilité de définir des valeurs de références qui pourront être utilisées dans l’expression du calcul des modèles. Cela permet de mettre à jour des données de calculs de manière isolé à la gestion des modèles. En parallèle, la première mise à jour de l’application a permis d’intégrer la gestion de valeurs métiers spécifiques intervenants eux aussi dans l’expression du calcul des modèles. Il s’agit de mesures de températures, de pressions et de charges électriques associées chaque jour à chaque machine (celles-ci sont utilisées dans des tests quotidiens).
L’ensemble de ces valeurs sont utilisées lors de la création d’environnement de calcul.

Afin de naviguer aisément dans de grands ensembles de données, ceux-ci sont présentés sous la forme de tableaux paginés triables. Les utilisateurs ont la possibilité d’imprimer directement depuis le navigateur les fiches correspondantes aux pannes et aux tests.

L’application se présente sous la forme d’une interface d’administration (Dashboard). Elle intègre directement dans le navigateur l’ensemble des interfaces et outils (JavaScript) nécessaire à son utilisation : calendrier, éditeur de code, sélecteurs spécifiques (Date Range, Select2, ...), etc. Des efforts particuliers ont été apportés dans le but d’améliorer l’ergonomie et faciliter la prise en main de l’application (codes couleurs sur les machines, messages d’informations / confirmations, etc.).

Afin d’aider à la prise en main de l’application, un manuel utilisateur (45 pages) a été élaboré et des réunions de formation ont été organisés. RadioCheck est actuellement déployé sur l’un des serveurs du service de radiothérapie. Une phase de tests est en cours avant utilisation quotidienne de l'application au sein du service.

Bien que le projet est conçu pour les besoins du service de radiothérapie, les différents modules constituant l’application sont réutilisables et le principe de fonctionnement est généralisable à différents domaines d’activité. L’application a été développée avec le langage PHP et le framework Symfony.