Vue d'ensemble

Livrable du groupe de travail Data Managers - synthèse du travail de modélisation mené sur les 5 ateliers Signalements (ACP, PMSI, ALD, génériques, Dépistage/RCP) et les immersions terrain (Gironde, Grenoble, Amiens, Poitou-Charentes, RNCE).

Cette documentation décrit le modèle de données tel qu’il est implémenté aujourd’hui dans le SI Registres. Elle a deux usages : servir de support de relecture/validation au groupe de travail, puis être diffusée à l’ensemble des data managers pour information. Le détail opérationnel par typologie (colonnes exactes, pré-traitement de la source) vit dans les fiches pratiques ; les grandes décisions de modélisation sont récapitulées dans les décisions de modélisation.

Objet et périmètre

Les registres ingèrent, dédoublonnent et consolident des documents source issus de filières très différentes : comptes-rendus d’anatomie et cytologie pathologiques, séjours hospitaliers, déclarations d’affection longue durée, réunions de concertation pluridisciplinaire, dépistages organisés. À l’import, chaque ligne d’un de ces documents devient un signalement.

Cette documentation couvre : ce qu’est un signalement et l’articulation des 6 typologies (cette page), puis le tronc commun, le codage cancer, le cycle de vie et le format d’import canonique (page Modèle de données).

Elle ne couvre pas : le parcours utilisateur d’import (interfaces, écrans, objet d’un travail ultérieur), l’algorithme de réconciliation d’identité, ni les conditions et automatisations autour de la création d’une tumeur.

Qu’est-ce qu’un signalement ?

Un signalement (report) est la trace du passage d’un patient dans son parcours de soins ou de détection (un compte-rendu d’ACP, un séjour hospitalier, une ALD, un test de dépistage…), rapportée au registre par une source. Tout signalement est une ligne de la table parente reports, qui porte un discriminant report_type et les attributs transverses (contrôles d’import, exclusion). Chaque ligne reports est complétée par exactement une ligne dans la table enfant propre à sa typologie (relation 1:1).

Cette architecture par héritage (un tronc générique + une table spécialisée par typologie) nous permet de paginer et requêter tous les signalements par date sur la seule table reports, l’affichage spécialisé (ACP, PMSI…) n’étant résolu qu’au besoin.

graph TD
    R["<b>reports</b> (tronc commun)<br/>report_type<br/>report controls · exclusion"]
    R -->|1:1| ACP["report_acps"]
    R -->|1:1| PMSI["report_pmsis"]
    R -->|1:1| ALD["report_alds"]
    R -->|1:1| RCP["report_rcps"]
    R -->|1:1| DEP["report_depistages"]
    R -->|1:1| GEN["report_generics"]

    ACP -->|1:N| ACPA["report_acp_adicap_codes"]
    ACP -->|1:N| ACPS["report_acp_snomed_codes"]
    PMSI -->|1:N| PDAS["report_pmsi_das"]
    PMSI -->|1:N| PACT["report_pmsi_actes"]
    RCP -->|1:N| RTUM["report_rcp_tumors"]
    RCP -->|1:N| RPAR["report_rcp_participants"]

Trois typologies n’ont pas de table fille (un signalement = une ligne, point) : ALD, Dépistage, Générique. Les trois autres éclatent leurs valeurs multiples en tables 1:N : codes ADICAP/SNOMED pour l’ACP, diagnostics associés et actes pour le PMSI, tumeurs et participants pour la RCP.

Les six typologies

L’objectif est de structurer un maximum de champs. Typer une source (lui donner un modèle dédié plutôt que de la verser dans le générique) sert alors trois buts : automatiser les traitements (transcodage, champs calculés, dédoublonnage), requêter des cas bien précis pour la recherche, et distinguer/filtrer aisément les typologies dans l’interface. Le générique reste un filet de secours, pour les sources n’intéressant qu’un seul ou quelques registres, où un modèle dédié ne se justifie pas.

ACP

Nom technique : acp

Le compte-rendu d’anatomie et cytologie pathologiques, la source la plus riche des registres : on en attend l’identification des cancers incidents et leur caractérisation morphologique et topographique.

Elle accepte deux systèmes de codage - ADICAP et SNOMED - et les transcode automatiquement en CIM-O-3 ; en cas d’échec, pas de rejet mais repli sur un code générique que l’ARC complète ensuite. Elle porte aussi le texte du compte-rendu.

Comportement par défaut
Création automatique de patient	oui
Création automatique de tumeur	oui

→ Fiche pratique ACP

PMSI

Nom technique : pmsi

Le séjour hospitalier, et le plus gros volume des registres, mais un codage CIM-10 orienté facturation : beaucoup de bruit non-cancer à filtrer. C’est la source du parcours hospitalier (chimiothérapie, radiothérapie, décès).

Une ligne = un RUM (Résumé d’Unité Médicale) ; ses diagnostics associés et ses actes, multiples, sont éclatés en tables filles. Le CIM-10 est transcodé en CIM-O-3 (règle de préfixe) et le code cancer retenu est choisi par priorité DP → DR → DAS.

Comportement par défaut
Création automatique de patient	oui
Création automatique de tumeur	oui

→ Fiche pratique PMSI

ALD

Nom technique : ald

L’affection de longue durée, une déclaration administrative que le médecin traitant adresse à l’Assurance Maladie. Source complémentaire : elle rattrape des cancers diagnostiqués en ville que ni l’ACP ni le PMSI n’ont fait remonter. Mais de faible qualité - le déclarant n’est pas forcément cancérologue.

Signal mince, réduit à (patient, code CIM-10, médecin déclarant, date d'ouverture), sans table fille. Le CIM-10 est transcodé en CIM-O-3 (règle de préfixe). Aucune déduplication automatique : deux médecins peuvent déclarer la même ALD, l’ARC tranchera.

Comportement par défaut
Création automatique de patient	non
Création automatique de tumeur	non

→ Fiche pratique ALD

RCP

Nom technique : rcp

Le compte-rendu de la réunion de concertation pluridisciplinaire, où les cancérologues arbitrent collectivement un cas. En principe la mieux codée (arbitrée par des spécialistes, CIM-O-3 natif, TNM, latéralité), mais en pratique souvent incomplète et peu structurée.

Le modèle s’aligne sur le futur standard national de l’ANS (le CDA CANCER-FRCP), encore en cours d’harmonisation et pas déployé partout : on vise dès maintenant sa structure cible - une fiche = un signalement, avec ses tumeurs (topographie, TNM, latéralité, rôle primitive/métastase) et ses participants (spécialité, rôle, quorum) en tables filles - tout en restant souple en attendant. Un registre qui n’a qu’un code à offrir peut ainsi ne renseigner qu’une topographie de tumeur, sans le reste.

Comportement par défaut
Création automatique de patient	non
Création automatique de tumeur	non

→ Fiche pratique RCP

Dépistage

Nom technique : depistage

Le dépistage organisé, à travers les trois programmes nationaux (sein, colorectal, col de l’utérus). Ce n’est pas une déclaration de cancer : un test, même positif, n’est pas un diagnostic. Son intérêt pour le registre est le cancer d’intervalle (cancer survenant ≤ 2 ans après un test négatif).

Une ligne = un test, avec son résultat (positif, négatif, non analysable, inconnu) et sa situation finale. Pas de morphologie : seule une topographie grossière est dérivée du programme. Les tests négatifs ne sont conservés que pour un patient déjà connu du registre.

Comportement par défaut
Création automatique de patient	non
Création automatique de tumeur	non

→ Fiche pratique Dépistage

Générique

Nom technique : generic

Le filet de secours pour les sources en périmètre sans catégorie dédiée (réseau mésothéliome, EPC, biologie moléculaire, protocoles pédiatriques, autopsies…).

Il reprend les blocs transverses et un CIM-O-3 saisi directement (optionnel, un seul par ligne, sans transcodage), plus un champ texte compte-rendu. Chaque import porte un libellé de source personnalisable qui identifie son origine.

Comportement par défaut
Création automatique de patient	oui
Création automatique de tumeur	oui

→ Fiche pratique Générique