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. Identité, adresse, lieu de naissance, structure source et prescripteur sont mutualisés en blocs partagés réutilisés à l’identique sur toutes les typologies. Motivation : un même mapping d’identité quelle que soit la source, pas de divergence de schéma, et une base plus facile à parcourir (les mêmes champs se retrouvent partout).
- 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. - Signalements orphelins. Un signalement non rattachable et sans droit de création n’est pas jeté silencieusement à l’import : il rejoint une file d’orphelins que le data manager gère comme il l’entend (relancer la réconciliation 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.