Chapitre 3: Conception et Méthodologie

de Développement de l'Application de
Radiothérapie

3.1 Introduction
Ce chapitre est dédié à l'exploration approfondie de la conception et de la méthodologie
de développement qui ont sous-tendu la création de l'application d'évaluation de la
qualité d'image des systèmes d'imagerie volumique à rayons X. Dans le cadre de ce
Projet de Fin d'Études (PFE), l'application joue un rôle central en fournissant une
plateforme intégrée pour l'analyse comparative des images CT (Computed Tomography)
et CBCT (Cone Beam Computed Tomography) en radiothérapie guidée par l'image
(IGRT). L'objectif principal de cette application est de faciliter l'évaluation précise des
décalages de positionnement des patients et des changements anatomiques, éléments
cruciaux pour l'optimisation des traitements de radiothérapie.

Le développement d'une telle application dans le domaine de l'imagerie médicale

présente des défis uniques. Premièrement, la manipulation des données DICOM (Digital
Imaging and Communications in Medicine), le standard international pour la gestion et
la transmission des images médicales, requiert une compréhension approfondie de ses
structures complexes et de ses métadonnées. Deuxièmement, les volumes de données
générés par les scanners CT et CBCT sont considérables, nécessitant des techniques de
traitement d'image efficaces et optimisées pour garantir des performances acceptables.
Enfin, la précision est primordiale dans un contexte clinique où les décisions basées sur
ces analyses ont un impact direct sur la sécurité et l'efficacité du traitement du patient.
Ce chapitre détaillera comment ces défis ont été abordés à travers une architecture
modulaire, le choix judicieux de technologies et une méthodologie de développement
itérative, aboutissant à une solution robuste et cliniquement pertinente.

3.2 Architecture Générale de l'Application

L'application a été conçue autour d'une architecture modulaire robuste, visant à séparer
les préoccupations et à faciliter le développement, la maintenance et l'évolutivité. Cette
approche modulaire est essentielle pour gérer la complexité inhérente aux applications
d'imagerie médicale, où différentes fonctionnalités (authentification, interfaces
utilisateur, traitement d'image, gestion des données) doivent interagir de manière
cohérente tout en restant indépendantes.

3.2.1 Architecture Modulaire et Orientée Utilisateur

L'architecture de l'application est fortement orientée utilisateur, avec des interfaces

distinctes adaptées aux rôles spécifiques des techniciens et des radiothérapeutes. Cette
séparation des rôles se reflète dans la structure des modules, chacun étant responsable
d'un ensemble de fonctionnalités bien défini. Les principaux modules identifiés sont les
suivants :

• Module d'Authentification et de Gestion des Utilisateurs

( login_system_improved.py ) : Ce module gère l'accès à l'application,
l'authentification des utilisateurs et la gestion de leurs rôles (technicien ou
radiothérapeute). Il assure la sécurité de l'accès et la personnalisation de
l'expérience utilisateur en fonction des permissions.
• Interfaces Utilisateur (Technicien et Radiothérapeute) : Deux modules distincts
( enhanced_technician_interface_updated.py et
radiotherapist_interface_improved.py ) sont dédiés à la présentation des
données et à l'interaction avec l'utilisateur. L'interface technicien est axée sur le
chargement, la visualisation et l'analyse des images, tandis que l'interface
radiothérapeute se concentre sur la revue des analyses et la gestion des
notifications.
• Modules de Traitement et d'Analyse d'Image ( [Link] et
optimized_analysis.py ) : Ces modules constituent le cœur fonctionnel de
l'application, responsables du chargement des données DICOM, du pré-traitement
des images, de la conversion des structures de contour en masques binaires, et du
calcul des métriques de comparaison entre les images CT et CBCT.
• Module de Détermination de la Signification Clinique
( clinical_significance.py ) : Ce module interprète les résultats numériques
des analyses d'image en termes de pertinence clinique. Il applique des seuils
spécifiques à différents types d'organes et génère des recommandations claires
pour les professionnels de la santé.
• Module de Gestion des Notifications ( notification_core.py ) : Ce module
centralise la communication entre les techniciens et les radiothérapeutes. Il permet
l'envoi, la réception, la mise à jour et la persistance des notifications concernant les
analyses d'image, facilitant ainsi le flux de travail collaboratif.

Cette modularité permet une grande flexibilité. Chaque module peut être développé,
testé et mis à jour indépendamment, minimisant les risques d'effets de bord et
améliorant la maintenabilité globale de l'application.
3.2.2 Flux de Travail et Interaction des Modules

Le flux de travail au sein de l'application est conçu pour simuler un processus clinique
typique d'évaluation de la qualité d'image en radiothérapie. Il se déroule en plusieurs
étapes, impliquant une interaction fluide entre les différents modules :

1. Authentification : L'utilisateur se connecte via le LoginDialog

( login_system_improved.py ). Le UserManager vérifie les identifiants et
attribue le rôle approprié (technicien ou radiothérapeute). Une fois authentifié,
l'utilisateur est redirigé vers son interface dédiée.
2. Chargement et Analyse par le Technicien : Un technicien utilise l'interface
EnhancedCTCBCTViewer ( enhanced_technician_interface_updated.py )
pour charger les volumes CT et CBCT d'un patient, ainsi que les structures de
contour (RTSTRUCT). Il peut visualiser les images, ajuster les paramètres de
fenêtrage et lancer l'analyse comparative des régions d'intérêt (ROIs). Les modules
[Link] ou optimized_analysis.py sont alors invoqués pour calculer
les métriques de décalage.
3. Détermination de la Signification Clinique : Les résultats bruts de l'analyse sont
ensuite passés au module clinical_significance.py , qui les interprète et
détermine une signification clinique (par exemple,

"Bon positionnement", "Repositionnement nécessaire"). Cette interprétation est

cruciale pour la prise de décision clinique. 4. Envoi de Notification : Une fois l'analyse
terminée et la signification clinique déterminée, le technicien peut envoyer une
notification au radiothérapeute via le NotificationManager
( notification_core.py ). Cette notification inclut les résultats de l'analyse et la
signification clinique, et est persistée dans un fichier JSON. 5. Revue par le
Radiothérapeute : Le radiothérapeute accède à son interface
( radiotherapist_interface_improved.py ), où il peut visualiser et filtrer les
notifications reçues. Il peut consulter les détails de chaque analyse, y compris les
métriques et la signification clinique. Une visualisation minimale des images CT/CBCT
peut être disponible pour une vérification visuelle. 6. Feedback et Mise à Jour du
Statut : Après examen, le radiothérapeute peut fournir un feedback sur l'analyse via un
FeedbackDialog . Ce feedback, ainsi que le statut de la notification (approuvé, rejeté,
à revoir), est enregistré par le NotificationManager et mis à jour dans le fichier
JSON. Le technicien peut ensuite consulter ce feedback via son interface.

Ce flux de travail itératif et collaboratif est au cœur de la conception de l'application,

permettant une communication efficace et une prise de décision éclairée entre les
différents acteurs du processus de radiothérapie.
3.2.3 Gestion de la Persistance des Données

La persistance des données dans l'application est gérée de manière simple et efficace,
principalement à travers l'utilisation de fichiers au format JSON. Cette approche a été
choisie pour sa légèreté, sa facilité de mise en œuvre et sa lisibilité, particulièrement
adaptée pour un projet de cette envergure. Deux types principaux de données sont
persistés :

• Informations Utilisateurs : Les données relatives aux utilisateurs (nom

d'utilisateur, rôle, nom complet, dernière connexion) sont stockées dans le fichier
[Link] . Le UserManager est responsable du chargement et de la
sauvegarde de ces informations, y compris la création d'utilisateurs par défaut si le
fichier n'existe pas. Cela permet de maintenir les comptes utilisateurs et leurs rôles
entre les sessions de l'application.
• Notifications : Toutes les notifications générées par les techniciens et les
feedbacks des radiothérapeutes sont stockés dans le fichier
[Link] . Le NotificationManager gère le cycle de vie de ces
notifications, y compris leur ajout, mise à jour (statut, feedback, urgence) et
récupération. Chaque notification est identifiée par un ID unique ( uuid ) et
contient des détails sur le patient, la ROI, les résultats d'analyse, les utilisateurs
impliqués, et la signification clinique.

L'utilisation de JSON pour la persistance des données offre plusieurs avantages : elle est
facile à parser et à générer en Python, ne nécessite pas de configuration de base de
données complexe, et les fichiers sont lisibles par un humain, ce qui facilite le débogage.
Cependant, elle présente également des limites pour des applications à grande échelle,
notamment en termes de performances pour de très grands volumes de données, de
gestion des accès concurrents et de requêtes complexes. Pour les besoins de ce PFE,
cette solution s'est avérée suffisante et appropriée, offrant un bon équilibre entre
simplicité de développement et fonctionnalité requise.

3.3 Technologies et Outils Utilisés

Le développement de cette application a reposé sur un ensemble de technologies et
d'outils open-source, choisis pour leur robustesse, leur flexibilité et leur adéquation aux
exigences spécifiques de l'imagerie médicale et du traitement de données scientifiques.
Le choix de Python comme langage de programmation principal a permis de tirer parti
d'un vaste écosystème de bibliothèques dédiées à ces domaines.
3.3.1 Langage de Programmation: Python

Python a été sélectionné comme langage de programmation principal pour plusieurs

raisons. Sa syntaxe claire et concise favorise une écriture de code rapide et une meilleure
lisibilité, ce qui est crucial pour la maintenance et la collaboration. Plus important
encore, Python bénéficie d'un écosystème riche et mature de bibliothèques scientifiques
et de traitement d'image, ce qui a grandement facilité l'implémentation des
fonctionnalités complexes de l'application. Sa capacité à s'intégrer avec des frameworks
d'interface graphique comme PyQt5 en fait un choix polyvalent pour le développement
d'applications de bureau interactives.

3.3.2 Framework d'Interface Utilisateur: PyQt5

PyQt5 est le framework choisi pour le développement de l'interface utilisateur

graphique (GUI) de l'application. C'est un ensemble de liaisons Python pour la
bibliothèque GUI Qt, l'une des plus puissantes et des plus populaires pour la création
d'applications de bureau multiplateformes. Les avantages de PyQt5 incluent :

• Richesse des Widgets : PyQt5 offre une vaste collection de widgets (boutons,
tableaux, listes, champs de texte, etc.) qui permettent de construire des interfaces
utilisateur sophistiquées et intuitives.
• Flexibilité et Personnalisation : Il permet une personnalisation poussée de
l'apparence et du comportement des éléments de l'interface, notamment via
l'utilisation de feuilles de style QSS (Qt Style Sheets).
• Gestion des Événements et des Signaux/Slots : Le modèle de programmation
basé sur les signaux et les slots de Qt facilite la gestion des interactions utilisateur
et la communication entre les différents composants de l'interface.
• Performance : Bien que Python soit un langage interprété, PyQt5 s'appuie sur la
bibliothèque Qt écrite en C++, offrant ainsi de bonnes performances pour les
applications graphiques.

L'application utilise spécifiquement le fichier professional_style.qss pour

appliquer un thème visuel cohérent et professionnel à l'ensemble de l'interface. Ce
fichier QSS permet de définir des propriétés de style (couleurs, polices, bordures, etc.) de
manière centralisée, assurant une expérience utilisateur agréable et uniforme.

3.3.3 Bibliothèques de Traitement d'Image Médicale et Scientifique

Le cœur fonctionnel de l'application repose sur l'utilisation de plusieurs bibliothèques

Python spécialisées dans le traitement d'image et le calcul scientifique. Ces
bibliothèques ont été essentielles pour manipuler les données DICOM, effectuer des
calculs complexes et implémenter les algorithmes d'analyse d'image :

• pydicom : Cette bibliothèque est fondamentale pour la lecture, l'écriture et la

manipulation des fichiers DICOM. Elle permet d'accéder aux métadonnées (comme
l'espacement des pixels, la position de l'image, les informations de fenêtrage) et
aux données de pixels des images CT, CBCT, et des structures de contour
(RTSTRUCT). pydicom est indispensable pour interpréter correctement les
données d'imagerie médicale et extraire les informations nécessaires à l'analyse
[1].
• numpy : La bibliothèque numpy est la pierre angulaire du calcul numérique en
Python. Elle est utilisée intensivement pour toutes les opérations impliquant des
tableaux multidimensionnels (les volumes d'images), permettant des calculs
rapides et efficaces sur de grandes quantités de données. Les masques binaires, les
volumes d'images et les résultats des calculs de métriques sont tous représentés et
manipulés comme des tableaux numpy .
• scipy : scipy est une bibliothèque de fonctions scientifiques et techniques
construite sur numpy . Dans cette application, elle est utilisée notamment pour les
fonctions de traitement d'image ( [Link] ), telles que le calcul du centre
de masse ( center_of_mass ) et la transformation de distance euclidienne
( distance_transform_edt ), qui sont cruciales pour le calcul des métriques de
comparaison comme la distance de Hausdorff [2].
• scikit-image ( skimage ) : Cette bibliothèque est dédiée au traitement
d'image. Elle fournit des algorithmes pour la segmentation, la transformation
géométrique, l'analyse de régions, etc. L'application l'utilise spécifiquement pour
l'étiquetage des régions connectées ( [Link] ) afin d'isoler la
plus grande composante connexe d'un masque, et pour la génération de polygones
( [Link] ) pour la conversion des contours RTSTRUCT en
masques binaires [3].
• SimpleITK : Bien que son utilisation directe ne soit pas prédominante dans les
extraits de code fournis, SimpleITK est une bibliothèque puissante pour l'analyse
d'images médicales, offrant des outils pour le rééchantillonnage, l'enregistrement
et la segmentation. Sa présence dans les imports suggère une considération pour
des opérations plus avancées de manipulation de volumes, notamment pour
l'alignement des images CBCT sur la grille CT [4].
• opencv-python ( cv2 ) : OpenCV est une bibliothèque de vision par ordinateur.
Elle est employée pour des opérations de traitement d'image de bas niveau telles
que le redimensionnement ( [Link] ), la fusion d'images
( [Link] , [Link] ) et la détection de contours
( [Link] ). Ces fonctions sont utilisées pour la visualisation des
 images et des masques, ainsi que pour la création d'images de fusion pour une
meilleure perception visuelle des décalages [5].

3.3.4 Gestion des Logs

Le module logging de Python est intégré à l'application pour le suivi des opérations et
le débogage. Il permet d'enregistrer des messages d'information, d'avertissement et
d'erreur à différentes étapes de l'exécution. Cette fonctionnalité est essentielle pour
comprendre le comportement de l'application, diagnostiquer les problèmes et surveiller
les processus d'analyse, en particulier lors de la manipulation de données complexes et
de calculs intensifs. Les logs sont configurés pour enregistrer les messages avec des
horodatages, des niveaux de gravité et des messages descriptifs, facilitant ainsi le
traçage des événements.

3.4 Conception Détaillée des Modules Clés

Cette section explore en détail la conception et l'implémentation des modules
fondamentaux de l'application, en mettant en lumière les classes, les fonctions et les
logiques métier qui sous-tendent leurs fonctionnalités.

3.4.1 Module d'Authentification et de Gestion des Utilisateurs

( login_system_improved.py )

Le module login_system_improved.py est la porte d'entrée de l'application,

assurant la sécurité et la personnalisation de l'accès. Il est structuré autour de trois
composants principaux : la classe User , la classe UserManager et la boîte de dialogue
LoginDialog .

• Classe User : Représente un utilisateur de l'application. Chaque instance de

User encapsule des attributs tels que le nom d'utilisateur ( username ), le rôle
( role - 'technicien' ou 'radiotherapeute'), le nom complet ( full_name ), la date
de dernière connexion ( last_login ), et un statut d'authentification
( is_authenticated ). Cette classe inclut des méthodes pour sérialiser
( to_dict ) et désérialiser ( from_dict ) les données utilisateur, facilitant leur
persistance.

• Classe UserManager : C'est le cœur du système de gestion des utilisateurs. Il est

responsable du chargement et de la sauvegarde des données utilisateur depuis et
vers un fichier JSON ( [Link] ). Le UserManager maintient un dictionnaire
des utilisateurs enregistrés et gère le processus d'authentification. La méthode
authenticate vérifie les identifiants fournis et met à jour le statut de l'utilisateur
 courant. Pour des raisons de démonstration, les mots de passe sont simplifiés (par
exemple, tech123 pour l'utilisateur tech ), mais dans un environnement de
production, une gestion plus robuste des mots de passe (hachage, salage) serait
impérative.

• LoginDialog : Il s'agit de l'interface graphique de connexion, construite avec

PyQt5. Cette boîte de dialogue permet aux utilisateurs de saisir leur nom
d'utilisateur et leur mot de passe. Elle interagit avec le UserManager pour valider
les informations. En cas de succès, un signal login_successful est émis,
transmettant l'objet User authentifié à la fenêtre principale de l'application.
L'interface de LoginDialog est visuellement améliorée avec des logos et un style
personnalisé via QSS, offrant une expérience utilisateur agréable dès le démarrage.

3.4.2 Modules d'Analyse d'Image ( [Link] et

optimized_analysis.py )

Ces modules sont au centre de la fonctionnalité d'évaluation de la qualité d'image. Ils

sont responsables du chargement, du pré-traitement et de l'analyse quantitative des
données d'imagerie médicale. Le module optimized_analysis.py représente une
version améliorée de [Link] , intégrant des optimisations et des fonctionnalités
supplémentaires.

Chargement et Pré-traitement des Données

Le processus commence par le chargement des données DICOM, géré principalement

par les fonctions du module [Link] (qui est intégré dans
enhanced_technician_interface_updated.py ).

• Lecture DICOM : La fonction load_dicom_volume utilise pydicom pour lire les

fichiers .dcm d'un dossier spécifié. Elle extrait les données de pixels pour
construire un volume 3D ( [Link] ) et récupère les métadonnées
essentielles telles que l'espacement des pixels ( PixelSpacing ) et l'épaisseur de
coupe ( SliceThickness ), qui sont cruciales pour les calculs de volume et de
distance en unités physiques (mm).

• Conversion en Unités Hounsfield (HU) : Les données brutes des scanners CT sont
converties en unités Hounsfield en appliquant les facteurs RescaleSlope et
RescaleIntercept présents dans les en-têtes DICOM. Cette étape est essentielle
pour obtenir des valeurs de densité radiologique standardisées et cliniquement
interprétables.
 • Fenêtrage (Windowing) : Les fonctions get_window_presets et
apply_window permettent d'ajuster le contraste et la luminosité des images pour
la visualisation. Le fenêtrage est appliqué en définissant une fenêtre de valeurs
(centre et largeur) et en mappant ces valeurs à une échelle de gris de 0 à 255. Des
préréglages spécifiques (poumon, tissus mous, os) sont fournis pour faciliter
l'inspection visuelle des différentes structures anatomiques.

• Conversion RTSTRUCT en Masques Binaires 3D : Les fichiers RTSTRUCT, qui

contiennent les contours des régions d'intérêt (ROIs) délinéées par les cliniciens,
sont traités par les fonctions load_rtstruct , get_structure_contours , et
contours_to_mask . Ces fonctions extraient les coordonnées 3D des contours et
les convertissent en masques binaires 3D ( [Link] ) qui ont la même
dimension que le volume d'image. Cette conversion est complexe car elle implique
de projeter les contours 2D sur les coupes correspondantes du volume 3D et de
remplir les polygones pour créer des régions binaires. La fonction
[Link] est utilisée pour cette tâche.

• Rééchantillonnage et Alignement : Pour comparer les images CT et CBCT, il est

impératif qu'elles soient sur la même grille spatiale. La fonction
resample_sitk_image_to_reference (utilisant SimpleITK ) est conçue pour
rééchantillonner le volume CBCT sur la grille du CT de référence. Cela garantit que
chaque voxel des deux volumes correspond à la même position physique dans
l'espace patient, permettant des comparaisons directes et précises des masques et
des métriques.

Calcul des Métriques de Comparaison

Les modules [Link] et optimized_analysis.py implémentent plusieurs

métriques clés pour quantifier la différence entre les masques de ROI du CT et du CBCT.
Ces métriques sont calculées par la fonction analyze_roi_pair .

• Volume ( calculate_volume ) : Calcule le volume d'un masque binaire 3D en

multipliant le nombre de voxels actifs par le volume d'un voxel (déterminé par
l'espacement des pixels). Le module [Link] inclut une logique pour ne
conserver que la plus grande composante connexe, réduisant ainsi l'impact des
artefacts ou des petites régions disjointes.

• Coefficient de Dice ( dice_coefficient ) : Le coefficient de Dice est une

métrique de superposition qui mesure la similarité spatiale entre deux masques
binaires. Il est défini comme deux fois l'intersection des deux masques divisée par
la somme de leurs volumes. Une valeur de 1 indique une superposition parfaite,
 tandis que 0 indique aucune superposition. C'est une métrique largement utilisée
pour évaluer la précision de la segmentation [6].

• Distance de Hausdorff (HD) et 95ème Percentile (HD95)

( hausdorff_distance_and_95th ) : La distance de Hausdorff est une métrique
de contour qui mesure la distance maximale entre les points des surfaces de deux
masques. Elle est très sensible aux petites déviations. La 95ème percentile de la
distance de Hausdorff (HD95) est souvent préférée en clinique car elle est moins
sensible aux valeurs aberrantes (outliers) et aux bruits. Ces métriques sont
calculées en utilisant la transformation de distance euclidienne
( [Link].distance_transform_edt ) pour trouver la distance de
chaque point d'un masque à l'autre [7].

• Distance entre Centres de Masse (CoM) ( center_of_mass_distance ) : Cette

métrique calcule la distance euclidienne entre les centres de masse des deux
masques. Le centre de masse est calculé en utilisant
[Link].center_of_mass . Cette métrique fournit une indication
globale du décalage de positionnement entre les deux structures,
indépendamment de leur forme exacte [8].

Optimisations dans optimized_analysis.py

Le module optimized_analysis.py a été développé pour améliorer les

performances et la robustesse de l'analyse. Bien que les fonctions de calcul des
métriques soient similaires, optimized_analysis.py intègre des appels directs aux
fonctions optimisées et une gestion plus structurée des erreurs. Il est également le point
d'intégration avec le module clinical_significance.py , permettant d'enrichir les
résultats d'analyse avec une interprétation clinique immédiate. L'objectif de cette
optimisation est de fournir des résultats plus rapidement et de manière plus fiable, ce
qui est essentiel dans un environnement clinique où le temps est un facteur critique.

3.4.3 Module de Détermination de la Signification Clinique

( clinical_significance.py )

Ce module est crucial pour transformer les résultats numériques bruts des analyses
d'image en informations cliniquement exploitables. Il fournit une interprétation
automatisée des métriques de comparaison et des recommandations basées sur des
seuils prédéfinis.

• OrganType et THRESHOLDS : Le module définit une énumération OrganType

(par exemple, LUNG , SOFT_TISSUE , BONE , UNKNOWN ) pour catégoriser les
régions d'intérêt. Des dictionnaires THRESHOLDS sont définis pour chaque type
 d'organe, contenant des seuils spécifiques pour le Dice, la HD95, la distance CoM et
la différence de volume. Ces seuils sont basés sur des considérations cliniques et
peuvent être ajustés pour refléter les meilleures pratiques ou les exigences
spécifiques d'un protocole de traitement.

• detect_organ_type : Cette fonction analyse le nom de la ROI (par exemple,

"LUNG_R", "Stomach_duodenum") pour déterminer automatiquement le type d'organe

associé. Cette détection permet d'appliquer les seuils cliniques les plus pertinents pour
l'évaluation.

• calculate_confidence_score : Cette fonction innovante calcule un score de

confiance pondéré basé sur l'ensemble des métriques (Dice, HD95, CoM, différence
de volume). Les poids attribués à chaque métrique peuvent être ajustés pour
refléter leur importance clinique relative (par exemple, le Dice est souvent plus
critique pour la superposition, tandis que la HD95 est cruciale pour les contours).
Ce score agrégé fournit une évaluation globale de la qualité de l'alignement,
facilitant une prise de décision rapide.

• get_clinical_significance : C'est la fonction principale de ce module. Elle

prend les résultats d'analyse et, en utilisant les seuils spécifiques au type d'organe
et le score de confiance, détermine une signification clinique. La logique de
décision est hiérarchisée, priorisant les problèmes majeurs (comme un

changement anatomique suspecté ou un repositionnement nécessaire) avant d'évaluer

des déviations plus subtiles. Elle retourne une chaîne de caractères décrivant la
signification (par exemple, "Alignement excellent", "Repositionnement nécessaire") et
une couleur associée pour une visualisation rapide dans l'interface utilisateur.

• get_detailed_analysis : Cette fonction génère une analyse textuelle plus

approfondie des résultats, incluant des recommandations personnalisées basées
sur la signification clinique déterminée. Elle fournit des détails sur les métriques
individuelles et suggère des actions spécifiques (par exemple, "Aucune action
requise", "Petit ajustement de table recommandé", "Vérifier les changements
anatomiques possibles"). Cette analyse détaillée est précieuse pour les techniciens
et les radiothérapeutes pour comprendre les raisons d'une classification donnée et
les étapes suivantes à entreprendre.

3.4.4 Module de Gestion des Notifications ( notification_core.py )

Le module notification_core.py est le pivot de la communication asynchrone

entre les techniciens et les radiothérapeutes. Il est conçu pour gérer le cycle de vie
complet des notifications, de leur création à leur archivage, en passant par leur mise à
jour et leur consultation.

• Classe Notification : Représente une notification individuelle. Chaque

notification est identifiée par un identifiant unique ( id généré par uuid ). Elle
contient des informations détaillées sur l'analyse (ID patient, date d'étude, nom de
la ROI, résultats d'analyse bruts), les utilisateurs impliqués ( from_user ,
to_user ), son statut ( pending , approved , rejected , needs_review ), un
champ pour le feedback du radiothérapeute, des horodatages ( created_at ,
updated_at ), et des indicateurs ( is_read , is_urgent ). La signification
clinique et la couleur associée, déterminées par clinical_significance.py ,
sont également intégrées directement dans l'objet notification pour une
consultation rapide.

• Classe NotificationManager : Ce gestionnaire centralise toutes les opérations

liées aux notifications. Il est responsable du chargement et de la sauvegarde des
notifications depuis et vers le fichier [Link] . Ses méthodes
incluent :

◦ add_notification : Pour enregistrer une nouvelle notification envoyée par

un technicien.
◦ update_notification : Pour modifier le statut, ajouter un feedback ou
marquer une notification comme urgente par le radiothérapeute.
◦ mark_as_read : Pour indiquer qu'une notification a été consultée.
◦ get_notification , get_notifications_for_user ,
get_unread_count , etc. : Pour récupérer et filtrer les notifications en
fonction de divers critères (utilisateur, patient, statut, signification).

Le NotificationManager utilise un signal notifications_updated (PyQt5

pyqtSignal ) pour informer les interfaces utilisateur (notamment la
RadiotherapistMainWindow et la TechnicianMainWindow ) de tout changement
dans la liste des notifications. Cela permet une mise à jour dynamique de l'affichage
sans nécessiter de rafraîchissement manuel, améliorant ainsi la réactivité de
l'application.

3.4.5 Interfaces Utilisateur Spécifiques

L'application propose deux interfaces utilisateur distinctes, adaptées aux besoins et aux
flux de travail des techniciens et des radiothérapeutes, garantissant une expérience
utilisateur optimisée pour chaque rôle.
Interface Technicien ( enhanced_technician_interface_updated.py basée sur
[Link] )

L'interface technicien est l'environnement principal où les analyses d'images sont

effectuées. Elle est encapsulée dans la classe TechnicianMainWindow , qui héberge
une instance de EnhancedCTCBCTViewer . Cette dernière est une version améliorée de
la classe CTCBCTViewer originale ( [Link] ), intégrant des fonctionnalités
spécifiques au nouveau système.

• TechnicianMainWindow : Cette fenêtre principale fournit le cadre de l'interface

technicien. Elle intègre une barre d'outils ( QToolBar ) pour des actions rapides
comme la définition de l'ID patient, l'accès aux notifications reçues (feedbacks des
radiothérapeutes) et la déconnexion. Une barre de statut ( QStatusBar ) affiche
des informations contextuelles, telles que l'ID du patient courant et l'utilisateur
connecté. Le bouton de notifications est dynamiquement mis à jour pour afficher le
nombre de notifications non lues, alertant le technicien des nouveaux feedbacks.

• EnhancedCTCBCTViewer : Ce composant est le cœur visuel et fonctionnel de

l'interface technicien. Il étend les capacités de visualisation et de manipulation
d'images DICOM de la version de base ( [Link] ). Ses fonctionnalités clés
incluent :

◦ Chargement et Visualisation : Permet de charger des volumes CT et CBCT,

ainsi que des fichiers RTSTRUCT. Les images peuvent être visualisées en vues
axiale, coronale et sagittale, avec des options de fenêtrage et de fusion (alpha
blending, checkerboard, color overlay) pour faciliter la comparaison visuelle
des deux modalités.
◦ Analyse des ROIs : Le technicien peut sélectionner des régions d'intérêt
(ROIs) et lancer une analyse comparative. Les résultats des métriques (Dice,
HD95, CoM, volume) sont affichés dans un tableau, et la signification clinique
est déterminée et présentée visuellement.
◦ Envoi de Notifications : Une fois l'analyse terminée, le technicien peut
envoyer les résultats au radiothérapeute via le NotificationManager .
Cette action crée une nouvelle notification avec tous les détails pertinents.
◦ Gestion des Feedbacks : Le technicien peut consulter les feedbacks envoyés
par les radiothérapeutes via une boîte de dialogue dédiée. Cela lui permet de
voir le statut de ses analyses (approuvé, rejeté, à revoir) et les commentaires
associés, facilitant ainsi l'apprentissage et l'amélioration continue.
Interface Radiothérapeute ( radiotherapist_interface_improved.py )

L'interface radiothérapeute est conçue pour la revue et la validation des analyses

effectuées par les techniciens. Elle est implémentée dans la classe
RadiotherapistMainWindow .

• RadiotherapistMainWindow : Cette fenêtre principale organise l'affichage des

notifications. Elle est divisée en plusieurs sections, incluant un panneau de filtres,
un tableau des notifications et un panneau de détails/actions. Un minuteur
( QTimer ) est utilisé pour rafraîchir périodiquement la liste des notifications,
assurant que le radiothérapeute dispose toujours des informations les plus
récentes.

• NotificationFilterPanel : Ce panneau permet au radiothérapeute de filtrer

la liste des notifications en fonction de divers critères : ID patient, nom de la ROI,
statut (en attente, approuvé, rejeté, à revoir), signification clinique, période de
temps, et urgence/état de lecture. Cela est essentiel pour gérer un grand volume de
notifications et se concentrer sur les cas les plus pertinents.

• FeedbackDialog : Lorsqu'une notification est sélectionnée, le radiothérapeute

peut ouvrir un FeedbackDialog pour évaluer l'analyse. Dans cette boîte de
dialogue, il peut définir le statut de la notification (approuvé, rejeté, à revoir),
ajouter un commentaire détaillé et marquer la notification comme urgente pour le
technicien. Le feedback est ensuite enregistré via le NotificationManager .

• RadiotherapistMinimalViewer : Cette classe fournit une capacité de

visualisation des images CT/CBCT et RTSTRUCT en mode lecture seule. Elle permet
au radiothérapeute de revoir visuellement les images et les contours associés à une
notification spécifique, sans les fonctionnalités d'analyse ou de modification
disponibles pour le technicien. Cela est utile pour une vérification rapide et
contextuelle des résultats d'analyse.

3.5 Méthodologie de Développement

Le développement de cette application a suivi une approche pragmatique, combinant
des principes de développement agile avec une attention particulière à la modularité et
à la qualité du code. Cette section décrit les aspects clés de la méthodologie adoptée.

3.5.1 Approche Modulaire et Itérative

Le projet a été mené selon une approche modulaire et itérative. Plutôt que de tenter de
construire l'application monolithique en une seule fois, le développement a procédé par
l'ajout et l'amélioration progressive de modules distincts. Cela est particulièrement
visible à travers la présence de fichiers comme login_system_improved.py ,
optimized_analysis.py , et enhanced_technician_interface_updated.py ,
qui témoignent d'un processus d'itération et de raffinement des fonctionnalités
existantes. Cette approche a permis de :

• Gérer la Complexité : En divisant le projet en composants plus petits et gérables,

la complexité globale a été réduite.
• Faciliter le Débogage : Les problèmes peuvent être isolés plus facilement au sein
de modules spécifiques.
• Permettre des Améliorations Progressives : De nouvelles fonctionnalités ou des
optimisations peuvent être intégrées sans perturber l'ensemble du système.
• Encourager la Réutilisation du Code : Les modules bien définis peuvent être
réutilisés dans différentes parties de l'application ou même dans d'autres projets.

3.5.2 Gestion des Dépendances

L'installation et la gestion des bibliothèques Python nécessaires ont été réalisées via
pip , le gestionnaire de paquets standard pour Python. Un fichier [Link]
(implicite dans le projet) aurait listé toutes les dépendances ( pydicom , numpy ,
scipy , scikit-image , SimpleITK , opencv-python , PyQt5 , etc.), permettant
une reproduction facile de l'environnement de développement. Cette pratique assure
que tous les développeurs (ou utilisateurs) disposent des versions correctes des
bibliothèques, évitant ainsi les problèmes de compatibilité.

3.5.3 Persistance Simple des Données

Comme détaillé précédemment, le choix des fichiers JSON pour la persistance des
données ( [Link] , [Link] ) reflète une volonté de simplicité et de
légèreté. Cette approche a été privilégiée pour éviter la complexité et la surcharge liées à
la mise en place et à la gestion d'un système de base de données relationnel (comme
SQL) ou non-relationnel (NoSQL), qui n'était pas jugée nécessaire pour les besoins de ce
projet de PFE. Bien que limitée pour des applications à grande échelle, cette solution est
parfaitement adéquate pour un prototype ou une application de démonstration, offrant
une persistance fiable et facile à inspecter.

3.5.4 Documentation Interne et Lisibilité du Code

Une attention particulière a été portée à la lisibilité et à la documentation interne du

code. La présence de commentaires explicatifs et de docstrings (chaînes de
documentation) pour les classes et les fonctions est notable dans les fichiers source.
Cette pratique est essentielle pour :

• Compréhension du Code : Facilite la compréhension du code par d'autres

développeurs ou par le développeur lui-même après une longue période.
• Maintenance : Rend le code plus facile à maintenir et à déboguer.
• Collaboration : Améliore la collaboration en fournissant des informations claires
sur l'objectif et l'utilisation de chaque composant.

3.5.5 Tests et Validation

Bien que des tests unitaires formels ne soient pas explicitement détaillés, la présence de
blocs if __name__ == '__main__': dans plusieurs modules ( [Link] ,
clinical_significance.py ) indique l'utilisation de tests intégrés pour valider le
comportement des fonctions clés. Ces blocs permettent d'exécuter des scénarios de test
spécifiques lors de l'exécution directe du module, assurant que les calculs de métriques
et la logique de signification clinique fonctionnent comme prévu. De plus, la validation
visuelle des résultats d'analyse et des masques dans l'interface utilisateur a joué un rôle
crucial dans la vérification de la précision des traitements d'image.

3.6 Conclusion
L'application d'évaluation de la qualité d'image des systèmes d'imagerie volumique à
rayons X a été développée sur la base d'une conception modulaire et d'une
méthodologie itérative, permettant de relever les défis inhérents à la manipulation et à
l'analyse des données DICOM en radiothérapie. Le choix de Python et de son riche
écosystème de bibliothèques (PyQt5, pydicom, numpy, scipy, scikit-image, SimpleITK,
opencv-python) a été déterminant pour la mise en œuvre des fonctionnalités
complexes, de l'authentification utilisateur à l'analyse avancée des images et à la
communication inter-rôles.

Les points forts de cette implémentation résident dans son architecture claire, la
séparation des préoccupations entre les modules, l'intégration de métriques d'analyse
d'image cliniquement pertinentes, et un système de notification efficace facilitant la
collaboration entre techniciens et radiothérapeutes. L'approche itérative a permis
d'optimiser progressivement les performances et la robustesse de l'application, comme
en témoigne l'évolution des modules d'analyse.

Malgré ses atouts, l'application présente certaines limitations, notamment la persistance

des données via des fichiers JSON, qui pourrait être un goulot d'étranglement pour des
déploiements à plus grande échelle ou nécessitant des requêtes complexes. Les
perspectives d'évolution incluent l'intégration d'une base de données plus robuste,
l'amélioration des algorithmes de rééchantillonnage et d'alignement pour une précision
accrue, l'ajout de fonctionnalités d'apprentissage automatique pour la détection
automatique des changements anatomiques, et l'exploration de solutions de
déploiement en environnement clinique. Cette application constitue une preuve de
concept solide et une base prometteuse pour de futurs développements dans le
domaine de l'IGRT.

Références
[1] Pydicom documentation. Disponible sur : [Link]
[2] SciPy documentation. Disponible sur : [Link] [3]
Scikit-image documentation. Disponible sur : [Link] [4]
SimpleITK documentation. Disponible sur : [Link] [5] OpenCV-Python
Tutorials. Disponible sur : [Link] [6]
Dice, L. R. (1945). Measures of the amount of ecologic association between species.
Ecology, 26(3), 297-302. Disponible sur : [Link]
abs/10.2307/1932409 [7] Hausdorff, F. (1914). Grundzüge der Mengenlehre. Leipzig: Veit.
(Concept de distance de Hausdorff). Disponible sur : [Link]
grundzgedermeng00haugoog/page/n385/mode/2up [8] Center of Mass. Wikipedia.
Disponible sur : [Link]