Décisions de modélisation
Les grands choix de modélisation et leur pourquoi, pour les data managers qui n’étaient pas en séance. Le détail opérationnel par typologie vit dans les fiches pratiques.
Architecture & tronc commun
Section intitulée « Architecture & tronc commun »- Modèle par héritage. Un tronc générique
reports+ une table spécialisée par typologie, en 1:1. Permet de paginer et requêter tous les signalements par date sur la seule table parente, l’affichage spécialisé n’étant résolu qu’au besoin. - Harmonisation des champs transverses. Les traits identifiants (identité, adresse, lieu
de naissance) sont centralisés dans des tables dédiées (
identities,addresses), créées à l’import et partagées par toutes les typologies ; structure source et prescripteur restent des blocs de colonnes communs réutilisés à l’identique sur chaque table de signalement. - NIR tronqué à 10 chiffres. Interdiction de stocker le NIR complet (réidentifiant). Les 10 premiers chiffres suffisent (sexe, année, mois, département de naissance) sans identifier l’individu.
Contrôles, cycle de vie & codage
Section intitulée « Contrôles, cycle de vie & codage »- Contrôles d’import décentralisés dans le CSV. Un registre peut préciser dans le fichier, ligne par ligne, ce que l’import doit faire (créer patient / créer tumeur / exclure) - la logique métier vit là où est la connaissance, chez le registre. Un comportement par défaut par typologie s’applique aux colonnes laissées vides : inutile de renseigner ces contrôles pour importer.
- Défauts de contrôles par typologie.
true/truepour ACP/PMSI/Générique ;false/false(rattachement seul) pour ALD/Dépistage/RCP. Le raisonnement : pour une source de faible qualité, non diagnostique ou souvent mal codée, le comportement sûr doit être le défaut, pas une option que le data manager peut oublier - un oubli fabrique de faux patients et de fausses tumeurs à nettoyer, la direction la plus coûteuse. Règle commune à tous les registres, surchargeable par ligne. - Exclusion avec motif.
excludedn’est pas un booléen mais un code numérique (0 = non, 1 = motif par défaut, ≥2 = motif spécifique du registre), pour tracer pourquoi un signalement est écarté. Comme les motifs diffèrent d’un registre à l’autre, les codes ≥ 2 sont décentralisés : chaque registre définit les siens. Un signalement exclu garde sa trace mais ne crée jamais de tumeur. - Identités orphelines. À l’import, chaque signalement reçoit une identité, orpheline tant qu’elle n’est pas rattachée à un patient. Une identité non rattachable et sans droit de création n’est pas jetée silencieusement : elle rejoint une file d’orphelins que le data manager gère comme il l’entend (relancer l’identito-vigilance plus tard, forcer la création, ou supprimer ; à définir).
- Pas de rejet sur échec de transcodage. Philosophie « aucune condition de rejet sur le
codage » : soit le transcodage passe, soit on retombe sur le code organe, soit sur le code
générique
C80.9/8000/3. L’ARC complète à la main ; l’information non codée reste disponible.
Travail issu des 5 ateliers Data Managers (ACP 2026-04-27, PMSI 2026-05-05, ALD 2026-05-22, génériques 2026-06-02, Dépistage/RCP 2026-06-19) et des immersions terrain (Gironde, Grenoble, Amiens, Poitou-Charentes, RNCE). Détail par typologie : voir les fiches pratiques.