Modèle de données

Le tronc commun harmonisé

Les six typologies décrivent toutes une identité patient et la même réalité administrative (qui l’a soigné, où, quand). Plutôt que de redéclarer ces champs dans chaque table avec des noms différents, ils sont regroupés en blocs de champs communs, réutilisés à l’identique partout où la réalité sous-jacente est la même. Bénéfice direct : un data manager peut réutiliser le même mapping d’identité quelle que soit la source.

Blocs partagés (portés par la table enfant)

Bloc	Champs
Identité patient	`patient_last_name`, `patient_first_name`, `patient_birth_name`, `patient_birth_date`, `patient_sex`
NIR	`patient_nir_partial` (10 premiers chiffres)
Adresse patient	`patient_address`, `patient_postal_code`, `patient_city`
Lieu de naissance	`patient_birth_commune`, `patient_birth_postal_code`, `patient_birth_insee_code`
Source & structure	`source_structure_id`, `source_structure_label` (+ `finess` pour traçabilité)
Prescripteur / médecin	`prescriber_name`, `prescriber_address`, `prescriber_postal_code`, `prescriber_city`, `prescriber_rpps`

À savoir - le NIR complet n’est jamais stocké : seuls les 10 premiers chiffres sont conservés. La troncature est faite par le SI Registres à l’import ; le data manager peut, par prudence, ne transmettre que ces 10 chiffres.

Attributs portés par le parent `reports`

Ces familles d’attributs sont les mêmes pour toutes les typologies et vivent donc sur la table parente, jamais dupliquées sur les enfants :

Réconciliation - [⚠️ À RÉDIGER] (modèle en cours de revue, probablement une table enfant).
Report controls - les décisions d’import par ligne (can_create_patient, can_create_tumor) - voir Report controls plus bas.
Exclusion - excluded, exclusion_origin, exclusion_reason_id, etc. - voir Exclusion plus bas.
Date de signalement (notification_date) - la date pivot du signalement : chaque pipeline la remplit avec la date clinique la plus pertinente de sa source, ce qui donne à toutes les typologies une seule colonne pour trier et paginer, indépendamment de la source.
- ACP : prélèvement → enregistrement → validation (1ʳᵉ non nulle)
- PMSI : entrée en hospitalisation
- ALD : date d’ouverture
- RCP : date de la RCP
- Dépistage : date du test
- Générique : la date saisie dans la colonne report_date à l’import

Codage cancer

Le registre vise un codage CIM-O-3 (oncologie), composé d’une topographie (le site, Cxx.x) et d’une morphologie (l’histologie + le comportement, ex. 8140/3). Les sources, elles, arrivent dans des codages différents - d’où des transcodages distincts par typologie.

Typologie	Codage source	Transcodage vers CIM-O-3
ACP	ADICAP, SNOMED, ou texte libre	Éclatement du code (organe → topo, lésion → morpho) via tables de référence ; fallback code générique `C80.9` / `8000/3`
PMSI, ALD	CIM-10 (administratif)	Topo = recopie du CIM-10 ; morpho dérivée par règle de préfixe (voir ci-dessous)
RCP	CIM-O-3 natif (topo issue du CIM-10, morpho déjà en CIM-O)	Aucun - codes conservés tels quels (warning si inconnu, jamais de rejet)
Dépistage	aucun	Topo grossière dérivée du programme (`breast`→`C50`, `colorectal`→`C18`, `cervix`→`C53`) ; pas de morphologie
Générique	CIM-O-3 saisi	Aucun - stocké tel quel, pas de rejet si hors référentiel

Règle de préfixe CIM-10 → comportement morphologique (PMSI, ALD) : C* → /3 (malin), D00–D09 → /2 (in situ), D10–D36 → /0 (bénin), D37–D48 → /1 (incertain).

Code caractérisant (PMSI, ALD) - sur une source transcodée, le code CIM-10 retenu comme code cancer du signalement une fois passé le test « code cancer valide ». Quand le code n’est pas un cancer, le code caractérisant est NULL : le signalement est conservé (audit) mais ne produit pas de tumeur candidate. Pour le PMSI, qui porte plusieurs diagnostics par séjour, le code caractérisant est choisi par priorité DP → DR → DAS.

⚠️ Le périmètre précis des codes cancer valides se consolide encore et peut évoluer.

⚠️ Berg group / topo IARC - Encore en chantier : les référentiels topographiques et morphologiques européens servant de base à cette catégorisation restent à valider.

Cycle de vie d’un signalement

De l’import à la tumeur

L’import et la réconciliation sont deux étapes séparées. Le pipeline d’import se borne à valider, transcoder, mettre en qualité puis injecter ; un worker de réconciliation distinct, en aval, tente ensuite de rapprocher le signalement d’une identité patient et décide de la suite.

flowchart TD
    F["Fichier source (CSV/Excel)<br/>au format canonique"] --> V{"Validation<br/>champs requis · formats"}
    V -->|ligne invalide| REJ["Ligne rejetée<br/>(motif au preview)"]
    V -->|ligne valide| T["Transcodage + mise en qualité<br/>(CIM-O-3, code caractérisant, Berg/IARC)"]
    T --> INJ["Injection : reports + table enfant"]
    INJ --> REC{"Worker de réconciliation<br/>(en aval)"}
    REC -->|identité trouvée| ATT["Rattaché au patient"]
    REC -->|identité absente<br/>+ création autorisée| NEWP["Patient créé"]
    REC -->|identité absente<br/>+ création interdite| ORP["Orphelin"]
    ATT --> TUM{"Création tumeur<br/>autorisée ?"}
    NEWP --> TUM
    TUM -->|oui + codage valide| NEWT["Tumeur créée / rattachée"]
    TUM -->|non| FLO["Signalement flottant<br/>(rattaché au patient, pas à une tumeur)"]
    INJ -. "si excluded renseigné" .-> EXC["Marqué exclu : jamais de tumeur<br/>rattaché à un patient, ou orphelin"]

Report controls : `can_create_patient` / `can_create_tumor`

Deux booléens par ligne, fournis par le data manager dans le CSV, pilotent ce que la réconciliation a le droit de faire : créer un nouveau patient / lever une nouvelle tumeur, ou seulement rattacher à ce qui existe déjà (sinon le signalement tombe en orphelin). Le rattachement à un patient connu a toujours lieu ; seules les créations sont contrôlées.

Le défaut dépend de la typologie :

Typologie	`can_create_patient`	`can_create_tumor`
ACP, PMSI, Générique	`true`	`true`
ALD, Dépistage, RCP	`false`	`false` (rattachement seul)

La logique : pour une source de faible qualité (ALD), non diagnostique (Dépistage) ou souvent mal codée (RCP), le comportement sûr doit être le défaut - sinon on fabrique de faux patients et de fausses tumeurs que l’ARC devra nettoyer. Le data manager surcharge par ligne (ou par fichier) au besoin. Une cellule vide garde le défaut de la typologie.

⚠️ Même quand un data manager force can_create_tumor = true (ex. sur un dépistage), des garde-fous métier sont attendus en aval (refus de créer une tumeur sur un dépistage négatif, p. ex. via le diagnostic final). Ce job n’existe pas encore ; le défaut ci-dessus est le filet de sécurité actuel.

Exclusion

Un signalement exclu reste visible sur son patient (sa trace est conservée : dates, provenance) mais est retiré des tumeurs et de la file d’attachement. Distinct de l’orphelin (un exclu peut porter un patient). L’exclusion à l’import se fait via une cellule excluded :

vide / 0 / non → non exclu ;
1 → exclu, motif par défaut non précisé (la ligne globale partagée par tous les registres) ;
2, 3, 4… → exclu avec un motif spécifique que le registre a préalablement créé dans son catalogue de motifs.

excluded prime sur can_create_tumor : si les deux sont à true, aucune tumeur n’est créée - l’exclusion l’emporte et la création automatique de tumeur est ignorée.

Orphelins

Un signalement orphelin ne se rattache ni à un patient ni à une tumeur, et n’a pas le droit d’en créer (can_create_patient = false). Il est conservé à part plutôt que jeté : un onglet dédié permettra de relancer la réconciliation plus tard (ex. après correction d’une date de naissance qui débloque l’appariement) ou de forcer la création a posteriori. La gestion fine des orphelins (purge, rétention) reste à arbitrer.

Le format d’import canonique

Le SI Registres impose un contrat de colonnes par typologie - le format d’import canonique. C’est au data manager de remapper la source vers ce format avant import. Ce contrat est la source de vérité unique : en-têtes, types, champs obligatoires et nature de chaque champ y sont déclarés une seule fois.

Ce travail de remappage se mutualise entre registres : lorsqu’une même source arrive au même format dans plusieurs départements (un même laboratoire, une même caisse), le script de mapping de l’un pourrait servir aux autres.

Trois natures de champs :

Fourni - la valeur vient directement du fichier source (nom du patient, code CIM-10…).
Résolu - déterminé à l’import hors du fichier : choisi dans l’interface (la structure source) ou déduit d’une valeur fournie (structure résolue depuis le FINESS).
Calculé - dérivé par le pipeline (code caractérisant, CIM-O-3, Berg group). Jamais présent dans le fichier source.

Obligatoire à l’import : l’ensemble minimal de champs fournis qu’une ligne doit porter pour être acceptée. Une ligne qui en manque un est rejetée (motif rapporté au preview). À distinguer de la nullabilité en base : un champ peut être obligatoire à l’import mais nullable en stockage. Exemple : le nom du patient (patient_last_name) est obligatoire à l’import ACP, alors que sa colonne reste nullable en base - elle est partagée par toutes les typologies, dont certaines ne l’imposent pas.

Le détail colonne par colonne, le pré-traitement à faire sur chaque source, et un exemple de CSV au format attendu sont dans les fiches pratiques par typologie.