Module Registre du cancer - Guide de conception du système¶
Introduction¶
La boîte à outils DHIS2 pour le Registre du cancer repose sur des normes et principes internationalement reconnus pour l'enregistrement du cancer en population, tels que définis par le Centre international de recherche sur le cancer (CIRC) dans Cancer Registration: Principles and Methods (Publications scientifiques du CIRC n° 160, 2021) et opérationnalisés à travers le logiciel CanReg5 développé par le CIRC. Cette boîte à outils comprend un programme Tracker DHIS2 aligné sur les normes de données de CanReg5 pour l'enregistrement individuel des cas de cancer, permettant le suivi en population au niveau du registre, ainsi qu'une application personnalisée DHIS2 pour exporter les données du programme Tracker au format CanReg5.
La boîte à outils du Registre du cancer est conçue pour aider les registres du cancer en population à renforcer leurs processus de gestion courante des données et à améliorer la qualité, l'exhaustivité et la rapidité de l'enregistrement des cas de cancer. Le Tracker DHIS2 du Registre du cancer n'est pas conçu pour fournir un support à la décision clinique, mais sert plutôt d'outil opérationnel pour la saisie individuelle des cas et de source de données pour la surveillance du cancer et l'analyse épidémiologique. Il est aligné sur les normes de données de CanReg5 pour l'enregistrement individuel des cas de cancer, permettant le suivi en population au niveau du registre.
Ce document de conception du système explique la configuration de référence dans DHIS2 pour le cas d'utilisation du registre du cancer, y compris une description détaillée de la configuration du Tracker DHIS2 et des mécanismes de contrôle de la qualité des données. Ce document ne traite pas des ressources et de l'infrastructure nécessaires à la mise en œuvre d'un tel système (tels que les serveurs, l'alimentation électrique, la connectivité internet, les sauvegardes, la formation et le support aux utilisateurs), qui sont couverts dans le Guide de mise en œuvre du Tracker DHIS2.
Les métadonnées de référence de cette boîte à outils sont disponibles ici : dhis2.org/metadata-downloads.
Remerciements¶
La boîte à outils DHIS2 pour le Registre du cancer a été développée avec le soutien financier de Vital Strategies et l'accompagnement technique du Centre international de recherche sur le cancer (CIRC). Nous remercions le CIRC pour son expertise en matière de normes d'enregistrement du cancer et du modèle de données CanReg5 tout au long de la conception et du développement de ces outils. Nous souhaitons également remercier les Groupes HISP qui ont participé aux consultations et ont contribué par leur expérience de mise en œuvre au développement de cette boîte à outils.
Aperçu de la conception du système¶
Contexte¶
Le cancer représente l'une des principales causes de morbidité et de mortalité dans le monde, la charge mondiale étant de plus en plus concentrée dans les pays à revenu faible et intermédiaire (PRFI) où les systèmes de santé sont souvent les moins équipés pour y faire face. Des données fiables et de haute qualité sur l'incidence du cancer, les caractéristiques des cas et les résultats sont essentielles pour éclairer la planification nationale de la lutte contre le cancer, allouer les ressources, suivre les tendances dans le temps et évaluer l'impact des programmes de prévention et de traitement. Les registres du cancer en population sont le principal instrument pour générer ces données probantes, et leur renforcement systématique est une priorité pour la lutte mondiale contre le cancer.
L'enregistrement individuel des cas de cancer offre des avantages significatifs par rapport à la notification agrégée. Une approche basée sur les cas permet une désagrégation flexible par siège tumoral, morphologie, âge, sexe, origine géographique et d'autres variables cliniquement et épidémiologiquement pertinentes. Elle permet également le suivi longitudinal des cas enregistrés, facilite le dédoublonnage des dossiers provenant de multiples sources de notification et permet l'application de contrôles systématiques de la qualité des données pour identifier et corriger les entrées incomplètes ou incohérentes. Ces capacités sont essentielles dans le contexte du registre du cancer, où les cas sont généralement notifiés à partir de multiples sources — hôpitaux, laboratoires d'anatomopathologie, certificats de décès — et doivent être consolidés en un seul dossier vérifié.
Malgré leur importance, les registres du cancer en population dans de nombreux PRFI font face à des défis persistants en matière d'exhaustivité, de rapidité et de pérennité des données. Les opérations des registres reposent souvent sur des systèmes papier fragmentés ou des outils logiciels autonomes qui sont difficiles à maintenir, s'intègrent mal aux systèmes nationaux d'information sanitaire et nécessitent une capacité technique importante pour fonctionner. CanReg5, développé par le CIRC, est devenu le logiciel standard internationalement reconnu pour l'enregistrement du cancer en population et fournit un modèle de données bien établi ainsi qu'un ensemble de procédures de contrôle de la qualité des données. Cependant, son intégration dans l'infrastructure numérique de santé nationale plus large — y compris les systèmes d'information sanitaire de routine gérés par les ministères de la Santé — reste limitée dans de nombreux contextes.
Le Tracker DHIS2 du Registre du cancer est conçu pour relever ces défis en s'appuyant sur la plateforme DHIS2 — déjà largement déployée dans les systèmes nationaux d'information sanitaire des PRFI — pour prendre en charge l'enregistrement individuel des cas de cancer, aligné sur les normes de données de CanReg5. En mettant en œuvre l'enregistrement du cancer au sein de DHIS2, cette boîte à outils vise à faciliter l'intégration des données de surveillance du cancer dans l'infrastructure nationale d'information sanitaire, à réduire la duplication des efforts de gestion des données et à soutenir le contrôle systématique de la qualité des données au point d'enregistrement.
Cas d'utilisation¶
La boîte à outils DHIS2 du Registre du cancer est conçue pour prendre en charge l'enregistrement individuel courant des cas de cancer alimentant les registres du cancer en population. Le système repose sur le modèle de données Tracker de DHIS2, aligné sur les normes de données et les flux de travail de CanReg5, le logiciel internationalement reconnu pour l'enregistrement du cancer en population, développé par le CIRC.
Le composant de saisie des données en ligne de la conception du système permet au personnel du registre d'enregistrer et de gérer les cas individuels de cancer provenant de multiples sources de notification — y compris les dossiers hospitaliers, les rapports des laboratoires d'anatomopathologie et de cytologie, et les certificats de décès — et de les consolider en un seul dossier de registre vérifié. Le programme Tracker prend en charge la saisie des éléments de données essentiels requis pour l'enregistrement du cancer en population, y compris les données démographiques du patient, les caractéristiques de la tumeur, la base du diagnostic et la source de notification.
Une caractéristique clé de la conception du système est la mise en œuvre de contrôles systématiques de la qualité des données intégrés dans le programme Tracker. Ces contrôles sont conçus pour identifier les entrées incomplètes, incohérentes ou invraisemblables au moment de la saisie des données ou lors des opérations courantes du registre, aidant les registres à maintenir les normes de qualité des données requises pour une analyse épidémiologique valide et une comparabilité internationale.
Bien que le Tracker DHIS2 du Registre du cancer ne soit pas conçu pour prendre en charge la gestion clinique des cas ni le support à la décision, il sert d'outil de registre électronique permettant un enregistrement structuré et standardisé des cas de cancer au sein de l'infrastructure nationale d'information sanitaire DHIS2.
Avertissement
La boîte à outils est conçue comme une configuration de référence, entièrement alignée sur les normes CanReg5 pour un transfert simplifié des données vers CanReg5. Les administrateurs système peuvent avoir besoin de localiser le programme en ajoutant de nouveaux éléments de données ou attributs, mais la modification de la configuration de référence est fortement déconseillée, car cela pourrait rompre l'alignement avec CanReg5 et la logique des règles de programme des contrôles de qualité des données.
Utilisateurs cibles¶
La conception du système du Registre du cancer DHIS2 est destinée à répondre aux besoins des utilisateurs à tous les niveaux du système de registre du cancer. Ces utilisateurs peuvent inclure :
- Responsables et personnel du registre du cancer (national et sous-national) : utilisateurs de données responsables de la supervision de l'exhaustivité et de la qualité de l'enregistrement des cas de cancer, du suivi des opérations du registre et de l'utilisation des données du registre pour soutenir la planification et la notification de la lutte contre le cancer
- Personnel de saisie des données du registre : utilisateurs responsables de la saisie et de la gestion quotidiennes des cas individuels de cancer dans le programme Tracker, y compris l'enregistrement des notifications de cas reçues des hôpitaux, des laboratoires et d'autres sources de notification, et l'application des procédures de contrôle de la qualité des données pour garantir l'exactitude et l'exhaustivité des dossiers du registre
- Gestionnaires de données du programme cancer : utilisateurs responsables de la supervision des flux de collecte de données, de l'assurance qualité des données et des fonctions de notification pour le programme national de registre du cancer
- Administrateurs système / Points focaux SIGS : personnel du ministère de la Santé et/ou équipe DHIS2 centrale responsable de la maintenance du système DHIS2, du soutien à l'adaptation locale de la configuration du registre du cancer et de l'assistance technique aux utilisateurs finaux
- Partenaires de mise en œuvre et prestataires d'assistance technique : organisations fournissant un soutien technique aux registres nationaux du cancer, y compris le CIRC, les Groupes HISP et d'autres partenaires impliqués dans la mise en œuvre du système, la formation et le renforcement des capacités
Tracker¶
Structure du programme Tracker¶
La structure du programme Tracker est la suivante :
| Étape | Description |
|---|---|
| Inscription | L'étape d'inscription collecte les données démographiques de base d'une personne, y compris les identifiants uniques, en tant qu'Attributs d'entité suivie (TEA). Plusieurs de ces TEA essentiels, tels que le Nom de famille et le Prénom, sont partagés entre les programmes Tracker de DHIS2. Le Type d'entité suivie pour le programme du Registre du cancer est « Personne ». |
| Tumeur | Cette étape contient les informations essentielles relatives à la tumeur. L'étape est répétable |
| Sources | Cette étape contient les informations essentielles relatives aux sources associées à chaque tumeur. L'étape est répétable |
| Suivi | Cette étape contient les informations de suivi du patient et n'est associée ni à la tumeur ni aux sources. L'étape est répétable |
Type d'entité suivie¶
Le programme Tracker du Registre du cancer DHIS2 permet l'inscription d'un type d'entité suivie (TET) « personne » dans le programme de registre du cancer. Chaque personne inscrite représente un patient atteint de cancer enregistré dans le registre du cancer en population. Le TET est configuré au niveau du système et peut être partagé avec d'autres programmes Tracker DHIS2 déployés au sein de la même instance nationale, conformément aux pratiques standard de mise en œuvre de DHIS2.
Inscription¶
L'étape d'inscription saisit les informations démographiques essentielles du patient requises pour inscrire un individu dans le programme de registre du cancer. En tant que bonne pratique, le personnel du registre doit d'abord rechercher un dossier existant avant de créer une nouvelle inscription, afin d'éviter les inscriptions en double du même patient.
Les attributs collectés à l'inscription représentent le jeu de données minimum nécessaire pour l'enregistrement du cancer en population et ont été mappés aux exigences standard de données du CIRC. Cinq attributs clés d'entité suivie sont collectés à cette étape. Ces attributs sont configurés au niveau du type d'entité suivie et peuvent donc être partagés entre d'autres programmes Tracker au sein de la même instance DHIS2. Cependant, une attention particulière doit être portée lors du partage de l'attribut Sexe, car l'ensemble d'options assigné à cet attribut utilise des codes numériques qui sont référencés dans de multiples contrôles de qualité des données tout au long du programme. Toute modification de ces codes — ou substitution par un ensemble d'options codé différemment — compromettrait la logique de ces contrôles. L'ensemble d'options Sexe a été mappé avec le dictionnaire CanReg5 correspondant.
Un attribut, l'Identifiant du patient, est généré automatiquement par le système au moment de l'inscription. Le format suit la même convention utilisée dans CanReg5 : l'identifiant est composé de 8 caractères, constitué de l'année en cours au format quatre chiffres suivi d'un numéro séquentiel à quatre chiffres, sous la forme CURRENT_DATE(yyyy)+SEQUENTIAL(####).
Tumeur¶
L'étape Tumeur est le composant central du programme Tracker du Registre du cancer. Elle saisit toutes les informations cliniques et épidémiologiques clés relatives à un cas individuel de cancer, et c'est là que l'ensemble complet des contrôles de qualité des données est appliqué au point d'enregistrement. Pour une description détaillée des contrôles de qualité, se référer à la section dédiée de ce document.
L'étape est structurée en plusieurs sections, dont plusieurs sont masquées de l'interface de saisie des données. Ces sections masquées servent des objectifs fonctionnels spécifiques dans la conception du système : elles prennent en charge la logique de calcul sous-jacente aux contrôles de qualité, contrôlent le flux de saisie des données par les règles de programme, alimentent les sorties analytiques du programme et permettent l'extraction des données via l'application personnalisée DHIS2 du Registre du cancer.
| Sections | Visibilité | Description |
|---|---|---|
| Patient | Visible | Informations sur le patient |
| Tumeur | Visible | Informations sur la tumeur |
| Statut des contrôles | Visible | Exécution de contrôles multiples |
| Contrôles | Non visible | Informations stockées de chaque contrôle individuel |
| Contrôle morphologie topographie | Non visible | Contrôle morphologie topographie en plusieurs étapes |
| Test de tumeurs primitives multiples | Non visible | Test de tumeurs primitives multiples en plusieurs étapes |
| Statut rare | Visible | Visible uniquement pour les utilisateurs pouvant confirmer le statut rare |
| Identifiant de la tumeur | Non visible | Stockage des informations nécessaires à l'exportation CanReg5 |
Éléments obligatoires¶
Le seul élément de données formellement obligatoire dans l'étape Tumeur est le Numéro de tumeur, qui sert de référence reliant chaque enregistrement de tumeur à ses sources correspondantes et est essentiel pour le processus d'extraction des données via l'application personnalisée du Registre du cancer.
Cependant, en pratique, tous les éléments de données des sections patient et tumeur doivent être renseignés pour que les contrôles de qualité des données s'exécutent correctement. La seule exception est le champ Grade, qui n'est pas requis lorsque le code de comportement indique une valeur autre que maligne. Cette exigence est appliquée par la règle de programme CR - Impossible d'exécuter les contrôles si tous les éléments obligatoires n'ont pas de valeurs, qui empêche l'exécution des contrôles lorsque l'un des champs requis est manquant.
Patient¶
La section patient collecte les informations démographiques et géographiques associées au cas de cancer. Le champ de date central dans cette section est la Date d'incidence, qui est la date de référence utilisée pour toutes les sorties analytiques dans CanReg5. La Date d'événement — la date système DHIS2 enregistrée au moment de la saisie des données — est un champ séparé dont la valeur est déterminée par les décisions de mise en œuvre locale : elle peut être fixée à la date de saisie des données, alignée sur la date d'incidence, ou refléter une autre date localement pertinente. La décision de conserver la date d'incidence comme un élément de données dédié plutôt que d'utiliser la date d'événement à cette fin est motivée par les exigences de l'application personnalisée d'extraction du Registre du cancer, qui référence directement l'élément de données.
Le champ Âge doit être saisi manuellement. Il est utilisé dans les contrôles de qualité des données, et une règle de programme vérifie la cohérence entre l'âge saisi, la date de naissance et la date d'incidence, renvoyant un avertissement si une discordance est détectée. De plus amples détails sont fournis dans la section des contrôles de qualité de ce document.
Le champ Adresse utilise un ensemble d'options contenant des valeurs de substitution et doit être personnalisé avant la mise en œuvre pour refléter la géographie administrative du pays ou de la région. Plutôt que d'utiliser un élément de données de type Unité d'organisation pour le codage géographique, l'approche recommandée est d'utiliser des éléments de données de type texte combinés avec des listes déroulantes dépendantes, mises en œuvre via des règles de programme utilisant l'action Afficher le groupe d'options. Cela permet la configuration de menus de sélection en cascade — par exemple, un premier élément listant les régions administratives, suivi d'un second élément qui n'affiche que les districts appartenant à la région sélectionnée. Cette approche est alignée sur la convention CanReg5 pour le codage d'adresse, où la variable d'adresse est composée de deux caractères et encode généralement une combinaison de deux niveaux administratifs.
Tumeur¶
La section tumeur est le principal composant de collecte de données de l'étape Tumeur. Elle saisit les variables clés qui doivent être enregistrées pour chaque cas de cancer, alignées et mappées aux exigences standard de données du CIRC, avec l'ajout du Numéro de tumeur, qui sert de référence locale reliant un enregistrement de tumeur spécifique à ses sources correspondantes.
Le Numéro de tumeur est conçu comme un identifiant unique pour la tumeur au sein du registre. Il peut s'agir d'un numéro séquentiel ou de toute autre valeur définie localement, et possède un ensemble d'options de type texte avec des valeurs numériques assignées. Combiné avec l'Identifiant du patient collecté à l'inscription, le Numéro de tumeur constitue l'Identifiant de la tumeur — l'identifiant composite qui identifie de manière unique un enregistrement de tumeur dans le système.
Pour empêcher qu'un même Numéro de tumeur soit assigné à plus d'une tumeur appartenant au même patient, un mécanisme dédié a été mis en œuvre utilisant un ensemble de règles de programme opérant sur une section masquée Identifiant de la tumeur.
Un élément de données Numéro de tumeur précédent, de type MULTI_TEXT, partage le même ensemble d'options que l'élément Numéro de tumeur. Lorsqu'un nouvel événement tumeur est ouvert, les règles de programme inspectent les valeurs enregistrées dans l'événement tumeur précédent. Si un Numéro de tumeur a été enregistré dans l'événement précédent, cette valeur est assignée à l'élément Numéro de tumeur précédent. Si un Numéro de tumeur et un Numéro de tumeur précédent étaient tous deux présents dans l'événement précédent, les deux valeurs sont concaténées et stockées comme deux valeurs distinctes dans le champ MULTI_TEXT. Une fois le Numéro de tumeur précédent renseigné, une autre règle de programme vérifie si la valeur actuellement saisie dans le champ Numéro de tumeur de l'événement actif existe déjà parmi les valeurs stockées dans le Numéro de tumeur précédent. Si une correspondance est trouvée, un message d'erreur s'affiche informant l'utilisateur que le Numéro de tumeur sélectionné a déjà été attribué à ce patient et qu'une valeur différente doit être choisie.
Les éléments de données restants dans la section tumeur sont alignés et mappés aux normes de données CanReg5 et sont utilisés comme entrées pour les contrôles de qualité des données décrits dans la section dédiée de ce document. À l'exception du champ topographie, tous les éléments sont des entrées à sélection libre. Le champ Topographie est mis en œuvre comme une liste déroulante dépendante : les codes de topographie disponibles sont filtrés en fonction du siège sélectionné par l'utilisateur, de sorte que seules les valeurs de topographie valides pour le siège choisi sont présentées pour la sélection.
Pour simplifier la saisie des données, chaque option inclut le code correspondant dans son nom, permettant au personnel du registre de rechercher directement par code lors de la sélection d'une valeur.
Les ensembles d'options sont mappés avec la version ICDO3.2 de CanReg5 :
Remarque
Les ensembles d'options utilisés dans cette section, et les codes associés à chaque option, sont directement mappés aux normes CanReg5. Il est essentiel que ces codes ne soient pas modifiés lors de la mise en œuvre locale ou de la maintenance du système. Toute modification des codes d'options compromettrait la logique des contrôles de qualité des données, qui s'appuient sur ces valeurs pour leurs calculs
Statut des contrôles¶
Cette section permet au personnel du registre de déclencher l'exécution des contrôles de qualité des données. Lorsque l'utilisateur sélectionne l'option Exécuter les contrôles, un message d'avertissement s'affiche pour chaque contrôle non réussi, permettant à l'utilisateur de vérifier et de corriger les entrées concernées.
Comme indiqué dans la section des éléments obligatoires, tous les éléments de données des sections patient et tumeur doivent avoir une valeur avant que les contrôles puissent être exécutés. La seule exception est le champ Grade, qui est obligatoire uniquement lorsque le code de comportement est malin (3).
Lorsque « Exécuter les contrôles » est sélectionné, la saisie des données pour la section tumeur est bloquée. Si l'utilisateur doit modifier une valeur après l'exécution des contrôles, il doit décocher l'élément pour réactiver la saisie des données. Ce comportement est appliqué par deux règles de programme :
- CR - Bloquer la saisie des données si les contrôles ont été exécutés
- CR - Bloquer la saisie des données si les contrôles ont été exécutés - Grade
Une fois Exécuter les contrôles sélectionné, deux options de contrôle supplémentaires deviennent visibles : Exécuter le contrôle Topographie Morphologie et Exécuter le test de tumeurs primitives multiples. Ceux-ci ont été mis en œuvre comme des étapes distinctes car ils nécessitent une vérification en plusieurs étapes et l'intervention de règles de programme supplémentaires qui ne peuvent pas être exécutées en une seule passe. De plus amples détails sont fournis dans la section Contrôles de ce document. Lorsque l'option principale Exécuter les contrôles est sélectionnée, ces deux contrôles ultérieurs sont obligatoires afin de garantir que l'ensemble complet des contrôles de qualité est exécuté.
Section des contrôles¶
| Éléments de données | Type de valeur |
|---|---|
| CR - Contrôles : Âge Morphologie rare | Booléen |
| CR - Contrôles : Âge Topographie rare | Booléen |
| CR - Contrôles : Âge Topographie Morphologie rare | Booléen |
| CR - Contrôles : Base rare | Booléen |
| CR - Contrôles : Grade invalide | Booléen |
| CR - Contrôles : Sexe Morphologie rare | Booléen |
| CR - Contrôles : Sexe Topographie invalide | Booléen |
| CR - Contrôles : Topographie Comportement rare | Booléen |
| CR - Contrôles : Topographie Morphologie rare | Booléen |
| CR - Contrôles : Résultat du test de tumeurs primitives multiples | Ensemble d'options |
| CR - Rare | Booléen |
| CR - Invalide | Booléen |
Cette section est toujours masquée de l'interface de saisie des données. Elle contient tous les contrôles de qualité des données, chacun mis en œuvre comme un élément de données distinct. Par défaut, tous les contrôles reçoivent une valeur faux par la règle de programme CR - Réinitialiser tous les contrôles, qui réinitialise tous les contrôles ayant précédemment retourné un résultat vrai chaque fois que l'élément Exécuter les contrôles est décoché.
Le seul contrôle avec un type de valeur différent est le Résultat du test de tumeurs primitives multiples, dont la sortie n'est pas un booléen mais l'une des trois valeurs possibles : Tumeur primitive en double, Tumeur primitive multiple ou Topographie inconnue. La logique complète de chaque contrôle est décrite dans la section Contrôles de ce document.
En plus des contrôles individuels, cette section contient deux éléments de classification résumée : Rare et Invalide. Comme les autres éléments de contrôle, les deux sont réinitialisés à faux chaque fois que l'élément Exécuter les contrôles est décoché. Leurs valeurs vraies sont ensuite assignées lors de l'exécution des contrôles : l'élément Rare est défini comme vrai si un contrôle avec un résultat rare retourne un résultat vrai ; l'élément Invalide est défini comme vrai si un contrôle avec un résultat invalide retourne un résultat vrai.
Ces deux éléments servent un double objectif. Ils peuvent être utilisés dans les sorties analytiques pour restreindre les comptages aux tumeurs ayant passé tous les contrôles de qualité, et ils peuvent être appliqués comme filtres dans les listes de travail et les listes de lignes pour identifier et examiner les cas signalés comme rares ou invalides.
Une tumeur est classée comme Rare lorsque la combinaison de valeurs saisies — telles que la morphologie, la topographie, l'âge et d'autres variables — représente une combinaison qui peut rarement survenir, et un superviseur doit confirmer que les données saisies sont correctes. De plus amples détails sont fournis dans la section Statut rare de ce document.
Une tumeur est classée comme Invalide lorsque les données saisies décrivent une combinaison anatomiquement et cliniquement impossible pour une tumeur (par exemple un homme avec une topographie ovarienne).
Conformément à la même logique que CanReg5, le système permet aux utilisateurs de saisir et d'enregistrer toute combinaison de valeurs, y compris celles qui produisent un résultat invalide. Ceci est intentionnel : les enregistrements invalides peuvent être identifiés rétrospectivement et corrigés, et peuvent être exclus des sorties analytiques. Pour garantir l'intégrité analytique, il est essentiel que les trois conditions suivantes soient toujours appliquées comme filtres lors de la génération de toute sortie analytique :
- Exécuter les contrôles = vrai
- Rare = faux OU Rare = vrai ET Confirmer le statut rare = vrai (voir la section Statut rare)
- Invalide = faux
Contrôle morphologie topographie¶
| Éléments de données | Type de valeur |
|---|---|
| CR - Famille morphologique | Ensemble d'options |
| CR - Clé Topographie Morphologie | Ensemble d'options |
| CR - Présent dans la liste DOIT | Booléen |
| CR - Présent dans la liste NE-DOIT-PAS | Booléen |
Cette section est toujours masquée de l'interface de saisie des données. Elle contient les éléments de données utilisés dans le calcul du contrôle Topographie Morphologie rare. La logique complète de ce contrôle est décrite dans la section Contrôles de ce document.
Test de tumeurs primitives multiples¶
| Éléments de données | Type de valeur |
|---|---|
| CR - Groupe de morphologie | Ensemble d'options |
| CR - Groupe de morphologie précédent | Ensemble d'options |
| CR - Groupe de morphologie précédent (multiple) | Ensemble d'options - Multitexte |
| CR - Groupe de topographie | Ensemble d'options |
| CR - Groupe de topographie précédent | Ensemble d'options |
| CR - Groupe de topographie précédent (multiple) | Ensemble d'options - Multitexte |
| CR - Résultat de morphologie | Ensemble d'options |
Cette section est toujours masquée de l'interface de saisie des données. Elle contient les éléments de données utilisés dans le calcul du test de tumeurs primitives multiples. La logique complète de ce contrôle est décrite dans la section Contrôles de ce document.
Statut rare¶
Cette section n'est visible que lorsque la tumeur a été classée comme rare (c'est-à-dire lorsque l'élément Rare est défini comme vrai) et n'est accessible qu'aux utilisateurs ayant le rôle spécifique autorisé à confirmer le statut rare. Elle permet à un superviseur désigné d'examiner le cas signalé et de confirmer que les données saisies sont correctes malgré la combinaison inhabituelle de valeurs.
La logique régissant la classification rare et le flux de confirmation sont décrits en détail dans la section Contrôles de ce document.
Identifiant de la tumeur¶
| Éléments de données | Type de valeur |
|---|---|
| CR - Numéro de tumeur précédent | Ensemble d'options - Multitexte |
| CR - Identifiant du patient | Texte |
| CR - TUMOURID | Texte |
Cette section est toujours masquée de l'interface de saisie des données. Elle contient les éléments de données clés utilisés dans l'extraction des données du registre du cancer depuis DHIS2 et leur importation ultérieure dans CanReg5 via l'application personnalisée du Registre du cancer.
L'élément Numéro de tumeur précédent est renseigné avec les valeurs de numéro de tumeur collectées à partir des événements tumeur précédents pour le même patient. Ce mécanisme empêche l'attribution du même numéro de tumeur à plus d'une tumeur appartenant au même patient. La logique complète est décrite dans la section Tumeur de ce document.
L'élément Identifiant du patient est automatiquement renseigné avec l'Identifiant du patient collecté lors de la phase d'inscription par la règle de programme CR - Assigner la valeur à l'identifiant patient de la tumeur - Tumeur. Cette valeur est ensuite utilisée pour renseigner l'élément TUMOURID, qui sert d'identifiant unique pour l'enregistrement de la tumeur et est utilisé pour relier un ou plusieurs enregistrements de source à une tumeur spécifique lors du processus d'extraction et d'importation. Le TUMOURID est composé en concaténant l'Identifiant du patient, la valeur 01 et le Numéro de tumeur, tel qu'assigné par la règle de programme CR - Assigner la valeur au TUMOURID.
Source¶
L'étape Source est utilisée pour enregistrer les sources de documentation à partir desquelles le cas de cancer a été notifié au registre. Chaque source représente un document — tel qu'un dossier hospitalier, un rapport d'anatomopathologie ou un certificat de décès — qui soutient l'enregistrement d'une tumeur spécifique. L'étape est composée de deux sections :
| Sections | Visibilité | Description |
|---|---|---|
| Source | Visible | Informations sur la source |
| TUMOURIDSOURCETABLE | Non visible | Stockage des informations nécessaires à l'exportation CanReg5 |
Section Source¶
Cette section collecte les informations relatives à l'enregistrement de source individuel. Un aspect clé de l'étape Source est la possibilité de relier chaque source à une tumeur spécifique appartenant au même patient inscrit. Comme décrit dans la section Structure du programme Tracker, une seule tumeur peut avoir plusieurs sources d'information qui lui sont associées. Pour cela, l'utilisateur doit spécifier le Numéro de tumeur auquel la source est reliée au moment de la saisie des données.
Si le numéro de tumeur sélectionné dans l'enregistrement de source n'a pas été préalablement assigné dans un événement tumeur pour le même patient, un message d'erreur s'affiche guidant l'utilisateur vers la sélection d'un numéro de tumeur existant valide. Cette validation est appliquée par la règle de programme CR - Afficher une erreur si le numéro de tumeur n'a été assigné à aucune tumeur.
Le champ Type de source utilise des valeurs de substitution dans la configuration de référence et doit être personnalisé avant la mise en œuvre pour refléter les types de sources pertinents pour le contexte local du registre.
TUMOURIDSOURCETABLE¶
| Éléments de données | Type de valeur |
|---|---|
| CR - Identifiant du patient | Texte |
| CR - TUMOURIDSOURCETABLE | Texte |
Cette section est toujours masquée de l'interface de saisie des données. Elle contient les éléments de données clés utilisés dans l'extraction des données du registre du cancer depuis DHIS2 et leur importation ultérieure dans CanReg5 via l'application personnalisée du Registre du cancer.
L'élément Identifiant du patient est automatiquement renseigné avec l'Identifiant du patient collecté lors de la phase d'inscription par la règle de programme CR - Assigner la valeur à l'identifiant patient de la tumeur - Source. Cette valeur est combinée avec le Numéro de tumeur sélectionné dans la section source pour renseigner l'élément TUMOURIDSOURCETABLE, suivant la même logique de concaténation utilisée pour le TUMOURID dans l'étape Tumeur — Identifiant du patient + 01 + Numéro de tumeur — assignée par la règle de programme CR - Assigner la valeur au TUMOURIDSOURCETABLE.
L'élément TUMOURIDSOURCETABLE est la référence clé utilisée lors du processus d'exportation pour relier chaque enregistrement de source à sa tumeur correspondante, permettant la reconstruction correcte de la relation tumeur-source lorsque les données sont importées dans CanReg5.
Suivi¶
L'étape de Suivi est utilisée pour enregistrer l'état de suivi du patient enregistré au fil du temps. Elle saisit la date du dernier contact avec ou la dernière information concernant le patient, l'état de suivi et — dans les cas où l'état enregistré est le décès — la date de décès.
Contrôles¶
L'une des caractéristiques centrales de la boîte à outils DHIS2 du Registre du cancer est la mise en œuvre des contrôles de qualité des données utilisés dans CanReg5 pour évaluer l'exhaustivité et l'exactitude des cas de cancer enregistrés. Ces contrôles représentent un composant essentiel de la pratique d'enregistrement du cancer en population, garantissant que les données collectées répondent aux normes requises pour une analyse épidémiologique valide et une comparabilité internationale.
Comme décrit dans les sections de l'étape Tumeur ci-dessus, la mise en œuvre de ces contrôles dans DHIS2 nécessite la configuration de multiples règles de programme et de plusieurs éléments de données calculés fonctionnant en combinaison. Les sections ci-dessous décrivent chaque contrôle en détail, y compris les variables impliquées, les conditions évaluées et les résultats attendus.
Les contrôles CanReg5 utilisés comme référence sont disponibles ici : https://github.com/IARC-CSU/CanReg5/tree/release/R45/src/canreg/common/qualitycontrol
Considérations transversales¶
Plusieurs considérations s'appliquent à la plupart ou à l'ensemble des contrôles décrits dans cette section et sont présentées ici pour éviter les répétitions.
Types de valeurs pour les éléments de données et les ensembles d'options¶
Un aspect clé de la mise en œuvre correcte des contrôles est la configuration appropriée des types de valeurs des éléments de données et des ensembles d'options. Dans CanReg5, la plupart des contrôles évaluent des valeurs spécifiques par rapport à une plage de valeurs numériques, en utilisant les codes numériques assignés à chaque option. Il est donc essentiel que dans DHIS2, tant les éléments de données que leurs ensembles d'options associés soient configurés avec un type de valeur Nombre, et que les variables de règles de programme référençant les valeurs d'ensembles d'options utilisent le code plutôt que le nom d'affichage. Les noms d'options peuvent rester du texte descriptif, mais les codes doivent être numériques.
Cette configuration permet de traduire directement les conditions de plage de CanReg5 en expressions de règles de programme DHIS2 sans modification. Par exemple, une condition CanReg5 telle que morphologyNumber >= 8270 && morphologyNumber <= 8281 peut être mise en œuvre dans DHIS2 en utilisant la même expression, sans avoir besoin d'énumérer chaque valeur individuelle dans la plage. Cela réduit considérablement la complexité et la longueur des expressions de règles de programme.
Logique de codes groupés¶
Certains contrôles CanReg5 utilisent une approche de regroupement pour optimiser l'évaluation des codes de topographie, en divisant le code par 10 pour regrouper une plage de valeurs. Par exemple, une fonction peut définir topographyGroup = topographyNumber / 10 puis évaluer topographyGroup == 53 pour couvrir tous les codes de topographie dans la plage 530–539. Étant donné que cette opération de division n'est pas nativement prise en charge dans les règles de programme DHIS2, la logique équivalente doit être exprimée explicitement comme une condition de plage. L'exemple ci-dessus serait traduit dans DHIS2 comme topography >= 530 && topography <= 539.
Âge — Date d'incidence — Date de naissance¶
L'objectif de ce contrôle est de vérifier que l'âge saisi dans l'étape Tumeur est cohérent avec la date d'incidence et la date de naissance enregistrées pour le patient. L'âge attendu est calculé comme la différence entre la date d'incidence et la date de naissance, et un avertissement est déclenché si l'âge saisi ne correspond pas à la valeur calculée. Le message d'avertissement renvoie l'âge attendu pour guider le personnel du registre dans la correction de l'entrée si nécessaire.
Dans DHIS2, ce contrôle est mis en œuvre via la règle de programme CR - Vérifier l'âge, la date d'incidence et la date de naissance.
Le contrôle de qualité CanReg5 correspondant est disponible ici : CheckAgeIncidenceDateBirthDate.java
Âge — Morphologie¶
L'objectif de ce contrôle est d'identifier les combinaisons rares d'âge et de morphologie. Le contrôle évalue les quatre premiers chiffres du code de morphologie par rapport à la valeur de l'âge et renvoie un résultat rare si l'une des conditions suivantes est remplie :
- Âge ≤ 25 et morphologie parmi : 9730, 9823, 9890
- Âge ≥ 15 et morphologie parmi : 8910, 8960, 8961, 8962, 8970, 8981, 8991, 9072, 9470, 9490, 9500, 9687
- Âge < 15 et morphologie parmi : 9724, 9732, 9823
Les variables impliquées dans ce contrôle sont Âge et Morphologie.
Dans DHIS2, ce contrôle est mis en œuvre via la règle de programme CR - Âge Morphologie rare, qui assigne une valeur vrai à l'élément de données CR - Contrôles : Âge Morphologie rare lorsque l'élément Exécuter les contrôles est sélectionné et que l'une des conditions ci-dessus est remplie. La logique suit directement la mise en œuvre CanReg5, car la configuration de type de valeur numérique décrite dans la section Considérations transversales permet d'exprimer les conditions comme des comparaisons de plage et d'égalité équivalentes dans l'expression de la règle de programme.
Le contrôle de qualité CanReg5 correspondant est disponible ici : CheckAgeMorphology.java
Âge — Topographie¶
L'objectif de ce contrôle est d'identifier les combinaisons rares d'âge et de topographie. Le contrôle évalue le code de topographie par rapport à la valeur de l'âge et renvoie un résultat rare si l'une des conditions suivantes est remplie :
- Âge < 5 et topographie dans la plage 530–539 ou 610–619
- Âge < 20 et topographie dans l'une des plages ou valeurs suivantes : 150–159, 190–199, 200–209, 210–219, 230–239, 240–249, 384, 500–509, 530–539, 540–549, 550–559
Les variables impliquées dans ce contrôle sont Âge et Topographie.
Comme décrit dans la section Considérations transversales, la mise en œuvre CanReg5 utilise une approche de regroupement où le code de topographie est divisé par 10 pour créer une valeur groupée qui est ensuite évaluée par rapport à un ensemble de numéros de groupe. Étant donné que cette opération de division n'est pas nativement prise en charge dans les règles de programme DHIS2, chaque condition de groupe est traduite en une expression de plage explicite. Par exemple, la condition CanReg5 topographyGroup == 53 est exprimée dans DHIS2 comme topography >= 530 && topography <= 539.
Dans DHIS2, ce contrôle est mis en œuvre via la règle de programme CR - Âge Topographie rare, qui assigne une valeur vrai à l'élément de données CR - Contrôles : Âge Topographie rare lorsque l'élément Exécuter les contrôles est sélectionné et que l'une des conditions ci-dessus est remplie.
Le contrôle de qualité CanReg5 correspondant est disponible ici : CheckAgeTopography.java
Âge — Topographie — Morphologie¶
L'objectif de ce contrôle est d'identifier les combinaisons rares impliquant l'âge, la topographie et la morphologie conjointement. Le contrôle évalue les trois variables en combinaison et renvoie un résultat rare si l'une des conditions suivantes est remplie :
- Âge < 40 et topographie dans la plage 610–619 et morphologie dans la plage 8140–8149
- Âge < 20 et topographie dans la plage 170–179 et morphologie < 9590
- Âge < 20 et topographie dans la plage 330–339, 340–349, ou 180–189 et morphologie n'est pas dans la plage 8240–8249
- Âge > 5 et morphologie est 9510 ou 9512 et topographie dans la plage 690–699
- Âge < 15 ou âge > 45 et topographie dans la plage 580–589 et morphologie est 9100
Les variables impliquées dans ce contrôle sont Âge, Topographie et Morphologie. Comme pour le contrôle Âge — Topographie, la logique de regroupement CanReg5 appliquée aux codes de topographie et de morphologie est traduite dans DHIS2 en expressions de plage explicites, comme décrit dans la section Considérations transversales.
Dans DHIS2, ce contrôle est mis en œuvre via la règle de programme CR - Âge Topographie Morphologie rare, qui assigne une valeur vrai à l'élément de données CR - Contrôles : Âge Topographie Morphologie rare lorsque l'élément Exécuter les contrôles est sélectionné et que l'une des conditions ci-dessus est remplie.
Le contrôle de qualité CanReg5 correspondant est disponible ici : CheckAgeTopographyMorphology.java
Base du diagnostic¶
L'objectif de ce contrôle est de vérifier que la base du diagnostic est cohérente avec la morphologie et la topographie enregistrées pour la tumeur. Le contrôle classe les codes de base du diagnostic en trois catégories :
- Non confirmé microscopiquement : codes 0–4
- Confirmé microscopiquement : codes 5–8
- Inconnu : code 9
Un ensemble de codes de morphologie — et deux conditions spécifiques à la topographie — sont acceptés quel que soit la base du diagnostic et renvoient toujours un résultat OK. Ce sont : 8000, 8150–8154, 8170, 8270–8281, 8800, 8720 lorsque la topographie est dans la plage 690–699 ou 440–449, 8960, 9050, 9100, 9140, 9350, 9380, 9384, 9500, 9510, 9530–9539, 9590, 9732, 9761 et 9800.
Pour tous les autres codes de morphologie, si la base du diagnostic n'est pas confirmée microscopiquement (c'est-à-dire que le code de base n'est pas dans la plage 5–8), le contrôle renvoie un résultat Rare. Bien que la mise en œuvre originale de CanReg5 renvoie un résultat « Query » pour cette condition, la mise en œuvre DHIS2 traite cela comme une combinaison rare, en cohérence avec l'approche appliquée aux autres contrôles de la boîte à outils.
Les variables impliquées dans ce contrôle sont Base du diagnostic, Morphologie et Topographie.
Dans DHIS2, ce contrôle est mis en œuvre via la règle de programme CR - Base rare, qui assigne une valeur vrai à l'élément de données de contrôle correspondant lorsque l'élément Exécuter les contrôles est sélectionné et que les conditions ci-dessus sont remplies.
Le contrôle de qualité CanReg5 correspondant est disponible ici : CheckBasis.java
Grade¶
L'objectif de ce contrôle est de vérifier que la valeur de grade saisie est cohérente avec le comportement et la morphologie de la tumeur. Les variables impliquées dans ce contrôle sont Comportement, Morphologie et Grade.
Le contrôle applique la logique suivante :
- Cas non malins (comportement ≠ 3) : le champ grade doit être vide ou codé comme 9. Si toute autre valeur de grade est présente, le contrôle renvoie un résultat Invalide. Cas malins (comportement = 3) : le champ grade est obligatoire. S'il est
- vide, le contrôle renvoie un résultat Manquant. Si le code de grade est en dehors de la plage valide 1–9, le contrôle renvoie un résultat Invalide. Lorsqu'un code de grade valide est présent (et différent de 9, qui est ignoré), les règles de cohérence morphologie-grade suivantes sont évaluées, chacune renvoyant un résultat Invalide si elle n'est pas respectée :
Morphologie 8331, 9187 ou 9511 doit avoir grade = 1 (bien différencié)
- Morphologie 8249, 8332, 9083, 9243 ou 9372 doit avoir grade = 2 (modérément
- différencié) Morphologie 8631 ou 8634 doit avoir grade = 3 (peu différencié)
- Morphologie 8020, 8021, 8805, 9062, 9082, 9392, 9401, 9451, 9505 ou 9512
- doit avoir grade = 4 (indifférencié/anaplasique) Les codes de grade 5–8 ne sont valides que pour les lymphomes et leucémies (morphologie ≥
- 9590) ; si morphologie < 9590 et grade est dans la plage 5–8, le résultat est Invalide Morphologie 9702, 9705, 9708, 9709, 9716, 9717, 9718, 9719, 9724, 9726,
- 9729, 9827, 9834 ou 9837 (lymphomes à cellules T) doivent avoir grade = 5 Morphologie 9714 (lymphome à cellules T et cellules nulles, anaplasique) doit avoir grade
- = 4, 5 ou 7 Morphologie dans la plage 9700–9719 (lymphomes à cellules T et cellules tueuses) doivent
- avoir grade = 5 ou 8 Morphologie 9670–9699, 9712, 9728, 9737, 9738, 9811–9818, 9823, 9833 ou
- 9836 (lymphomes à cellules B) doivent avoir grade = 6 Morphologie 9948 (cellule tueuse) doit avoir grade = 8
- Dans DHIS2, ce contrôle est mis en œuvre via la règle de programme CR - Vérification du Grade, qui assigne une valeur vrai à l'élément de données Grade invalide lorsque l'élément Exécuter les contrôles est sélectionné et que l'une des conditions ci-dessus est remplie.
Le contrôle de qualité CanReg5 correspondant est disponible ici : CheckGrade.java
Morphologie { #morphology }
L'objectif de ce contrôle est de vérifier que le code de morphologie saisi est un code CIM-O-3 valide, en vérifiant les quatre premiers chiffres de la valeur de morphologie par rapport à un fichier de référence de familles morphologiques reconnues.¶
Dans DHIS2, ce contrôle ne nécessite pas de mise en œuvre dédiée par règle de programme. Étant donné que le champ morphologie est configuré comme un ensemble d'options fermé, les utilisateurs sont contraints de sélectionner uniquement des codes de morphologie valides à partir de la liste prédéfinie. La validité de la valeur saisie est donc garantie par l'interface de saisie des données elle-même, rendant un contrôle programmatique redondant.
Le contrôle de qualité CanReg5 correspondant est disponible ici : CheckMorphology.java
Sexe — Morphologie { #sex-morphology }
L'objectif de ce contrôle est d'identifier les combinaisons rares de sexe et de morphologie. Le contrôle évalue le code de morphologie par rapport au sexe du patient en utilisant un fichier de recherche qui assigne chaque code de morphologie à une famille morphologique, et renvoie un résultat rare si l'une des conditions suivantes est remplie :¶
Sexe = masculin et morphologie appartient à l'une des familles suivantes :
- Vulve/Vagin (22), Utérus (23), Ovaire (24), Organes génitaux féminins et autres tissus (25), ou Placenta (26) Sexe = masculin et morphologie = 9084 avec comportement = 3 (malin uniquement dans l'ovaire)
- Sexe = féminin et morphologie appartient à l'une des familles suivantes :
- Pénis (27), ou Prostate/Testicule (28) Les variables impliquées dans ce contrôle sont Sexe, Morphologie et Comportement.
Dans CanReg5, le regroupement des codes de morphologie en familles est géré par le fichier de recherche MorphFam.txt. Dans DHIS2, ce regroupement est mis en œuvre via une série de règles de programme avec le préfixe CR - Famille morphologique : [nom de la famille morphologique], chacune assignant la valeur de famille correspondante à l'élément de données CR - Famille morphologique, situé dans la section masquée Contrôle Morphologie Topographie. Le contrôle sexe-morphologie évalue ensuite la valeur de cet élément de données plutôt que le code de morphologie directement.
Dans DHIS2, ce contrôle est mis en œuvre via la règle de programme CR - Sexe Morphologie rare, qui assigne une valeur vrai à l'élément de données de contrôle correspondant lorsque l'élément Exécuter les contrôles est sélectionné et que l'une des conditions ci-dessus est remplie.
Le contrôle de qualité CanReg5 correspondant est disponible ici : CheckSexMorphology.java
Sexe — Topographie { #sex-topography }
L'objectif de ce contrôle est d'identifier les combinaisons invalides de sexe et de topographie — spécifiquement, les cas où un siège topographique anatomiquement exclusif à un sexe est enregistré pour un patient du sexe opposé. Contrairement aux contrôles décrits précédemment, ce contrôle renvoie un résultat Invalide plutôt que Rare, car les combinaisons qu'il identifie sont anatomiquement impossibles.¶
Le contrôle renvoie un résultat Invalide si l'une des conditions suivantes est remplie :
Sexe = masculin et topographie dans la plage 510–589 (organes génitaux féminins)
- Sexe = féminin et topographie dans la plage 600–639 (organes génitaux masculins)
- Comme pour le contrôle Âge — Topographie, la logique de regroupement CanReg5 appliquée aux codes de topographie est traduite dans DHIS2 en expressions de plage explicites, comme décrit dans la section Considérations transversales.
Les variables impliquées dans ce contrôle sont Sexe et Topographie.
Dans DHIS2, ce contrôle est mis en œuvre via la règle de programme CR - Sexe Topographie invalide, qui assigne une valeur vrai à l'élément de données de contrôle correspondant lorsque l'élément Exécuter les contrôles est sélectionné et que l'une des conditions ci-dessus est remplie.
Le contrôle de qualité CanReg5 correspondant est disponible ici : CheckSexTopography.java
Topographie { #topography }
L'objectif de ce contrôle est de vérifier que le code de topographie saisi est un code CIM-O-3 valide, en vérifiant la valeur de topographie à trois chiffres par rapport au fichier de recherche de référence O3_10T.txt utilisé dans CanReg5 pour la conversion CIM-O-3 vers CIM-10.¶
Comme pour le contrôle Morphologie, dans DHIS2 ce contrôle ne nécessite pas de mise en œuvre dédiée par règle de programme. Étant donné que le champ topographie est configuré comme un ensemble d'options fermé, les utilisateurs sont contraints de sélectionner uniquement des codes de topographie valides à partir de la liste prédéfinie. La validité de la valeur saisie est donc garantie par l'interface de saisie des données elle-même, rendant un contrôle programmatique redondant.
Le contrôle de qualité CanReg5 correspondant est disponible ici : CheckTopography.java
Topographie — Comportement { #topography-behaviour }
L'objectif de ce contrôle est d'identifier les combinaisons rares de topographie et de comportement. Spécifiquement, il signale les cas où un code de comportement in situ (2) est enregistré pour des sièges topographiques où les tumeurs in situ sont considérées comme rares. Le contrôle renvoie un résultat Rare si la condition suivante est remplie :¶
Comportement = 2 (in situ) et topographie dans l'une des plages suivantes :
- 400–409 (os), 410–419 (crâne), 420–429 (sang, moelle osseuse, rate), 470–479 (système nerveux périphérique), 490–499 (tissus mous), ou 700–729 (méninges, cerveau, nerfs) Comme pour les autres contrôles basés sur la topographie, la logique de regroupement CanReg5 est traduite dans DHIS2 en expressions de plage explicites, comme décrit dans la section Considérations transversales.
Les variables impliquées dans ce contrôle sont Topographie et Comportement.
Dans DHIS2, ce contrôle est mis en œuvre via la règle de programme CR - Topographie Comportement rare, qui assigne une valeur vrai à l'élément de données de contrôle correspondant lorsque l'élément Exécuter les contrôles est sélectionné et que la condition ci-dessus est remplie.
Le contrôle de qualité CanReg5 correspondant est disponible ici : CheckTopographyBehaviour.java
Topographie — Morphologie { #topography-morphology }
L'objectif de ce contrôle est d'identifier les combinaisons rares de topographie et de morphologie en évaluant la famille morphologique du code de morphologie saisi par rapport à la topographie à l'aide de deux tables de recherche de référence : une liste MUST (DOIT), contenant les combinaisons où une famille morphologique spécifique doit être associée à des sièges topographiques spécifiques, et une liste MUST-NOT (NE DOIT PAS), contenant les combinaisons où une famille morphologique spécifique ne doit pas être associée à des sièges topographiques spécifiques.¶
Chaque code de morphologie appartient à une famille morphologique, et chaque famille se voit attribuer l'une des trois clés possibles qui détermine quelle table de recherche appliquer et comment interpréter le résultat :
NA (*) : la famille morphologique est acceptée avec toute topographie. Le
- contrôle passe quel que soit la topographie saisie. Plus (+) : la famille morphologique a un ensemble restreint de sièges
- topographiques avec lesquels elle est censée survenir. La combinaison de famille et de topographie est recherchée dans la liste MUST. Si la combinaison est trouvée, le contrôle passe. Si elle n'est pas trouvée, la combinaison est considérée comme rare. Moins (−) : la famille morphologique a un ensemble restreint de sièges
- topographiques avec lesquels elle ne doit pas survenir. La combinaison de famille et de topographie est recherchée dans la liste MUST-NOT. Si la combinaison est trouvée, la combinaison est considérée comme rare. Si elle n'est pas trouvée, le contrôle passe. Les variables impliquées dans ce contrôle sont Topographie et Morphologie.
Étant donné la complexité de cette logique et la dépendance à des tables de recherche qui ne peuvent pas être nativement répliquées dans les règles de programme DHIS2, la mise en œuvre nécessite plusieurs éléments de données intermédiaires calculés à renseigner avant que le résultat final du contrôle puisse être assigné. Les éléments suivants, situés dans la section masquée Contrôle Morphologie Topographie, sont renseignés séquentiellement par des règles de programme dédiées :
Famille morphologique : assignée en fonction du code de morphologie saisi, en utilisant la série de règles de programme avec le préfixe
- CR - Famille morphologique : [nom de la famille morphologique], comme décrit dans la section du contrôle Sexe — Morphologie. 2. Clé Topographie Morphologie : dérivée de la recherche de la famille morphologique, cet élément identifie si la clé de la famille est astérisque, plus ou moins. 3. Présent dans la liste DOIT : lorsque la clé est plus, un ensemble de règles de programme évalue si la combinaison de famille morphologique et de topographie est présente dans la table de recherche DOIT. En raison de la longueur de l'expression requise pour couvrir toutes les combinaisons famille-topographie, cette évaluation a été divisée en 9 règles de programme distinctes, chacune couvrant une plage distincte de familles morphologiques. Ces règles suivent le préfixe de nommage CR - Topographie Morphologie : DOIT - Famille morphologique [plage]. Si la combinaison est trouvée dans l'une de ces règles, l'élément Présent dans la liste DOIT reçoit la valeur vrai ; sinon il reçoit la valeur faux. 4. Présent dans la liste NE-DOIT-PAS : lorsque la clé est moins, une règle de programme évalue si la combinaison de famille morphologique et de topographie est présente dans la table de recherche NE-DOIT-PAS. Si la combinaison est trouvée, cet élément reçoit la valeur vrai ; sinon il reçoit la valeur faux. Le résultat final assigné à l'élément de données de contrôle CR - Contrôles : Topographie Morphologie rare est alors déterminé comme suit : Si la clé est NA : le contrôle passe et faux est assigné à
CR - Contrôles : Topographie Morphologie rare.
- Si la clé est plus et Présent dans la liste DOIT est vrai : le contrôle passe et faux est assigné.
- Si la clé est plus et Présent dans la liste DOIT est faux : la combinaison est rare et vrai est assigné.
- Si la clé est moins et Présent dans la liste NE-DOIT-PAS est vrai : la combinaison est rare et vrai est assigné.
- Si la clé est moins et Présent dans la liste NE-DOIT-PAS est faux : le contrôle passe et faux est assigné.
- Ce contrôle est l'un des plus complexes de la boîte à outils en raison de sa dépendance à la logique de tables de recherche qui doit être approximée dans DHIS2 via une séquence de règles de programme intermédiaires et d'éléments de données calculés. Comme indiqué dans la section Statut des contrôles, ce contrôle nécessite un déclencheur séparé — Exécuter le contrôle Topographie Morphologie — en raison de la nature multi-étapes de son exécution. Le contrôle de qualité CanReg5 correspondant est disponible ici : CheckTopographyMorphology.java
Test de tumeurs primitives multiples { #multiple-primary-tester }
L'objectif de ce contrôle est de déterminer si deux ou plusieurs tumeurs enregistrées pour le même patient représentent des enregistrements en double de la même tumeur ou des tumeurs primitives multiples distinctes. Contrairement à tous les autres contrôles, ce contrôle opère entre les événements tumeur plutôt qu'au sein d'un seul événement, et son résultat n'est pas un booléen mais l'une des trois valeurs possibles : Tumeur primitive en double, Tumeur primitive multiple ou Topographie inconnue.
Le contrôle repose sur deux variables de regroupement intermédiaires — Groupe de morphologie et Groupe de topographie — qui sont dérivées des codes de morphologie et de topographie saisis respectivement, en utilisant la logique de mapping définie dans la classe CanReg5 DefaultMultiplePrimaryTester. Ces valeurs sont assignées à des éléments de données dédiés par une série de règles de programme avant l'exécution du contrôle.¶
Pour permettre la comparaison entre les événements tumeur, les valeurs du Groupe de morphologie et du Groupe de topographie des événements tumeur précédents sont assignées aux éléments de données correspondants Groupe de morphologie précédent et Groupe de topographie précédent. Pour éviter un signalement incorrect de doublons, la logique de concaténation utilisée pour le Numéro de tumeur (décrite dans la section Tumeur) n'est pas appliquée ici : si la même valeur de groupe de morphologie ou de topographie est déjà présente à partir d'un événement précédent, elle n'est pas concaténée à nouveau.
Le contrôle évalue ensuite les valeurs actuelles et précédentes selon la logique suivante :
Évaluation de la morphologie :
Si l'un des groupes de morphologie est invalide (0), le résultat est Topographie inconnue
Si l'un des groupes de morphologie est non spécifié (17), le résultat de la morphologie est
- indécis et l'évaluation de la topographie est effectuée
- Si les deux groupes sont des carcinomes et l'un est un carcinome non spécifié (groupe 5), le résultat de la morphologie est indécis et l'évaluation de la topographie est effectuée
- Si un groupe est hématopoïétique/lymphoïde (8–13) et l'autre est hématopoïétique non spécifié (14), le résultat est Tumeur primitive en double
- Si les deux groupes de morphologie sont égaux et systémiques (groupes 7–15), le résultat est Tumeur primitive en double
- Si les deux groupes de morphologie sont égaux mais non systémiques, le résultat de la morphologie est indécis et l'évaluation de la topographie est effectuée
- Si les deux groupes de morphologie sont différents, le résultat est Tumeur primitive multiple Évaluation de la topographie (effectuée uniquement lorsque le résultat de la morphologie est indécis) :
- Si les deux groupes de topographie sont non spécifiés (80), le résultat est
Tumeur primitive en double
- Si un groupe de topographie est non spécifié (80), le résultat est Topographie inconnue
- Si les deux groupes de topographie sont égaux, le résultat est Tumeur primitive en double Si les deux groupes de topographie sont différents, le résultat est Tumeur primitive multiple
- Comme indiqué dans la section Statut des contrôles, ce contrôle nécessite un déclencheur séparé — Exécuter le test de tumeurs primitives multiples — en raison de la nature multi-étapes de son exécution impliquant le renseignement séquentiel d'éléments de données intermédiaires avant que le résultat final puisse être évalué.
- La mise en œuvre CanReg5 correspondante est disponible ici : DefaultMultiplePrimaryTester.java
Application personnalisée du Registre du cancer { #cancer-registry-custom-application }
Une application DHIS2 personnalisée a été développée pour prendre en charge l'extraction des données du registre du cancer à partir du programme Tracker DHIS2 dans un format compatible avec CanReg5. La nécessité d'une application d'extraction dédiée découle des différences structurelles entre le modèle de données DHIS2 et le format de données attendu par CanReg5 pour l'importation. Alors que DHIS2 stocke les données de cas individuels sur plusieurs étapes de programme — inscription, tumeur et source — CanReg5 attend une structure plate basée sur les enregistrements où les informations sur le patient, la tumeur et la source sont consolidées dans un seul fichier importable. L'application personnalisée comble cette lacune en interrogeant les éléments de données pertinents à travers toutes les étapes, en appliquant les transformations nécessaires et en produisant un fichier de sortie que CanReg5 peut ingérer directement.
Cancer Registry Export Custom application¶
A custom DHIS2 application has been developed to support the extraction of cancer registry data from the DHIS2 tracker program in a format compatible with CanReg5. The need for a dedicated extraction application arises from the structural differences between the DHIS2 data model and the data format expected by CanReg5 for import. While DHIS2 stores individual case data across multiple program stages — enrollment, tumor, and source — CanReg5 expects a flat, record-based structure where patient, tumor, and source information are consolidated into a single importable file. The custom application bridges this gap by querying the relevant data elements across all stages, applying the necessary transformations, and producing an output file that CanReg5 can ingest directly.
De plus amples détails techniques sur l'application, y compris les instructions d'installation, les exigences de configuration et les directives d'utilisation, sont disponibles ici
Groupes d'utilisateurs { #user-groups }
Groupe d'utilisateurs
Métadonnées¶
| Données | CR - Administrateur | Peut modifier et visualiser |
|---|---|---|
| Pas d'accès | CR - Accès | Peut visualiser uniquement |
| Peut visualiser uniquement | CR - Saisie de données | Peut visualiser uniquement |
| Saisie et visualisation | Références { #references } | Bray, F., Colombet, M., Mery, L., Piñeros, M., Znaor, A., Zanetti, R. et Ferlay, J. (éds.) (2017). Cancer Incidence in Five Continents, Vol. XI. Publication scientifique du CIRC n° 166. Lyon : Centre international de recherche sur le cancer. Disponible à : https://ci5.iarc.who.int |
DHIS2. Guide de mise en œuvre du Tracker DHIS2. Oslo : Université d'Oslo. Disponible à : https://docs.dhis2.org¶
DHIS2. Métadonnées de référence pour la boîte à outils DHIS2 du Registre du cancer. Disponible à : https://dhis2.org/metadata-downloads
Ervik, M., Cooke, A. et l'Unité de surveillance du cancer du CIRC. CanReg5 : Logiciel pour les registres du cancer. Lyon : Centre international de recherche sur le cancer. Disponible à : http://www.iacr.com.fr/index.php?option=com_content&view=article&id=9:canreg5&catid=68&Itemid=445
Unité de surveillance du cancer du CIRC. Dépôt de code source CanReg5, version R45. GitHub. Disponible à : https://github.com/IARC-CSU/CanReg5/tree/release/R45
Piñeros, M., Mery, L., Soerjomataram, I., Bray, F. et Steliarova-Foucher, E. (éds.) (2021). Cancer Registration: Principles and Methods. Publications scientifiques du CIRC n° 160. Lyon : Centre international de recherche sur le cancer. Disponible à : https://publications.iarc.who.int/Book-And-Report-Series/Iarc-Scientific-Publications/Cancer-Registration-Principles-And-Methods-2021
IARC Cancer Surveillance Unit. CanReg5 source code repository, release R45. GitHub. Available at: https://github.com/IARC-CSU/CanReg5/tree/release/R45
Piñeros, M., Mery, L., Soerjomataram, I., Bray, F. and Steliarova-Foucher, E. (eds.) (2021). Cancer Registration: Principles and Methods. IARC Scientific Publications No. 160. Lyon: International Agency for Research on Cancer. Available at: https://publications.iarc.who.int/Book-And-Report-Series/Iarc-Scientific-Publications/Cancer-Registration-Principles-And-Methods-2021