Fiche pratique data manager - Dépistage organisé

Nom technique : depistage

📥 Télécharger un modèle de CSV

Vocation

Le signalement « Dépistage organisé » enregistre les tests des trois programmes nationaux de dépistage du cancer : sein (breast, mammographie), colorectal (colorectal, test immunologique FIT) et col de l’utérus (cervix, test HPV / frottis). Les données proviennent des CRCDC (centres régionaux de coordination des dépistages des cancers), au format de variables de Santé publique France. Le dépistage organisé de la peau et de la prostate est hors périmètre. Une ligne = un test ; plusieurs lignes par personne sont normales puisque le dépistage est récurrent. Ce signalement n’est pas une déclaration de cancer : un test, même positif, n’est pas un diagnostic - le codage cancer réel (CIM-O-3) vient toujours de l’ACP et/ou du PMSI confirmatoire. L’intérêt registre est le cancer d’intervalle (cancer survenant ≤ 2 ans après un test négatif) : on rattache l’historique de dépistage, dont la date du dernier test négatif, à un patient déjà connu. La qualité a priori est bonne et structurée côté programme/résultat/date, mais hétérogène entre les trois formats sources (sein, colorectal, col), d’où le prétraitement décrit dans Préparer son CSV.

Format canonique d’import

Format canonique imposé (modèle ACP) : le registre fixe les colonnes ; le data manager prétraite ses fichiers CRCDC/SpF vers cette forme unique. Séparateur de colonnes : ; (ou , ; le séparateur est auto-détecté ; entourer de guillemets "…" toute valeur contenant le séparateur). Aucune colonne packée dans cette typologie (pas de séparateur d’entrées |). Toutes les colonnes ci-dessous sont des champs fournis par le data manager, sauf les trois contrôles d’import en fin de tableau.

Colonne (csvKey)	Libellé	Format attendu	Obligatoire	Nature
screening_program	Programme	texte - breast, colorectal ou cervix	oui	fourni
screening_number	N° de dépistage	code (mis en majuscules, points/espaces retirés) - N° SpF, 14 car.	oui	fourni
test_date	Date du test	date (JJ/MM/AAAA ou AAAA-MM-JJ)	oui	fourni
previous_test_date	Date du test précédent	date (JJ/MM/AAAA ou AAAA-MM-JJ)	-	fourni
screening_round	Rang / vague	entier	-	fourni
test_result	Résultat du test	texte normalisé - negative / positive / not_analysable / unknown	-	fourni
final_diagnosis	Situation finale	texte normalisé - normal / benign / suspect / polyp_low_risk / polyp_high_risk / cancer / pending / lost_to_followup / unknown	-	fourni
complementary_exam_result	Résultat examen complémentaire	valeur packée / texte libre (narration du bilan : coloscopie, ACR, colposcopie…)	-	fourni
patient_last_name	Nom	texte (nom marital)	oui	fourni
patient_first_name	Prénom	texte	-	fourni
patient_birth_name	Nom naissance	texte	-	fourni
patient_birth_date	Date naissance	date (JJ/MM/AAAA ou AAAA-MM-JJ)	-	fourni
patient_sex	Sexe	texte (1 car. : F / M)	-	fourni
patient_secu	N° Sécu (NIR)	NIR - seuls les 10 premiers chiffres sont conservés	-	fourni
patient_address	Adresse	texte	-	fourni
patient_postal_code	Code postal	code postal (zéros de tête restaurés)	-	fourni
patient_city	Ville	texte	-	fourni
residence_insee_code	Code INSEE de résidence	texte (5 car.)	-	fourni
finess	FINESS	code (mis en majuscules, points/espaces retirés)	-	fourni
prescriber_name	Prescripteur	texte	-	fourni
prescriber_address	Adresse prescripteur	texte	-	fourni
prescriber_postal_code	CP prescripteur	code postal (zéros de tête restaurés)	-	fourni
prescriber_city	Ville prescripteur	texte	-	fourni
prescriber_rpps	RPPS prescripteur	code (mis en majuscules, points/espaces retirés)	-	fourni
can_create_patient	Peut créer un patient	oui / non	-	contrôle d’import
can_create_tumor	Peut créer une tumeur	oui / non	-	contrôle d’import
excluded	Exclu	entier (0/vide = non exclu ; 1 = motif par défaut ; ≥ 2 = motif registre)	-	contrôle d’import

Télécharger un modèle de CSV au format attendu

Préparer son CSV à partir de la source brute

Le data manager transforme son export CRCDC/SpF (sein, colorectal ou col de l’utérus - formats natifs distincts) vers ce format canonique unique. Check-list :

1. Périmètre. Ne garder que les trois programmes nationaux. Exclure peau et prostate en amont : ils sont hors périmètre et n’ont pas de valeur screening_program valide.
2. Granularité. Une ligne = un test. Ne pas agréger plusieurs tests d’une personne sur une ligne ; ne pas dédupliquer soi-même l’historique (le SI le fait, cf. Spécificités).
3. screening_program (obligatoire) : forcer la valeur d’enum exacte breast / colorectal / cervix selon le fichier source traité.
4. screening_number (obligatoire) : reporter le N° de dépistage SpF (14 car.). C’est la clé de déduplication - sans lui la ligne est rejetée. Ne jamais le recalculer ni le réattribuer : il est fixe par personne, attribué au 1er dépistage et conservé d’une vague sur l’autre.
5. test_result et final_diagnosis : mapper les codes source vers les valeurs d’enum lors du prétraitement - ces deux colonnes doivent arriver déjà normalisées. Exemples de sources à transcoder : ACR (sein) → negative/positive/suspect… ; RESULT_TEST (FIT colorectal), DIAG, HISTO. Tout résultat illisible ou non mappable → unknown côté test_result ; situation finale inconnue → unknown côté final_diagnosis.
6. Dates (test_date, previous_test_date, patient_birth_date) : normaliser en JJ/MM/AAAA (ou AAAA-MM-JJ). Attention à la date de naissance : les sources SpF la livrent en jour/mois/année séparés avec sentinelles d’inconnu (00 pour jour/mois, 9999 pour l’année). Recomposer une date complète seulement si les trois composantes sont connues ; un partiel non résolu doit devenir vide (le SI le passera à null, sans booléen _malformed).
7. NIR (patient_secu) : facultatif. Le SI ne conserve que les 10 premiers chiffres ; inutile de tronquer soi-même, mais ne pas s’appuyer dessus comme identifiant réidentifiant.
8. Codes postaux (patient_postal_code, prescriber_postal_code) : les zéros de tête sont restaurés par le SI ; éviter qu’Excel ne les transforme en nombres tronqués (formater en texte avant export).
9. Topographie / morphologie : NE PAS fournir. Aucune colonne topo/morpho dans le format ; le SI dérive cimo3_topo_code en dur depuis le programme. Toute colonne topo locale est à laisser de côté.
10. Bilan / examen complémentaire : verser la narration libre (résultat coloscopie, ACR, colposcopie, histologie) dans complementary_exam_result. Le détail organe-spécifique structuré n’est pas modélisé ; ce champ texte libre suffit.
11. Prescripteur : renseigner prescriber_name et, si dispo, l’adresse/ville/CP/RPPS. La provenance du prescripteur (ville vs hôpital vs labo) est utile à l’enquête ARC.
12. Contrôles d’import (can_create_patient, can_create_tumor, excluded) : laisser vides dans le cas général (cf. Comportement par défaut à l’import). Les renseigner seulement pour surcharger une ligne précise.

Note sur les négatifs de patients inconnus : un test négatif rattaché à un patient qui n’est pas déjà connu du registre ne sera pas conservé (statut juridique CNIL en attente : la conservation des négatifs n’est autorisée que si le patient est déjà connu). Ces lignes restent orphan en aval sans création de patient. Ne pas s’attendre à les retrouver : les négatifs servent au suivi des patients déjà connus (cancer d’intervalle).

Comportement par défaut à l’import

Cette typologie est en rattachement seul : par défaut can_create_patient = false et can_create_tumor = false. Raison métier : on importe négatifs et positifs sans filtre clinique, et un test n’étant pas un diagnostic, le dépistage ne doit ni créer un nouveau patient ni ouvrir une tumeur - il se rattache à un patient déjà connu, sinon la ligne reste en orphan.

Le data manager surcharge par ligne via les colonnes can_create_patient / can_create_tumor (oui / non). Forcer can_create_tumor = oui ne crée jamais de tumeur sur un dépistage non cancéreux : un garde-fou empêche la création de tumeur dès que final_diagnosis ≠ cancer (detected_cancer = false).

Colonne excluded : vide ou 0 = ligne non exclue ; 1 = exclusion avec le motif par défaut (cause non précisée) ; ≥ 2 = motif d’exclusion spécifique au catalogue du registre. Un numéro de motif inconnu du catalogue fait rejeter la ligne côté worker.

Ce que fait le système à l’import

Une fois votre fichier déposé, le système traite chaque ligne (chaque test) en trois temps :

1. Validation - champs obligatoires (screening_program, screening_number, test_date, nom) et formats. Une ligne invalide est rejetée, motif affiché dans l’aperçu avant import.
2. Mise en qualité - il dérive la topographie CIM-O-3 directement du programme (sein → C50, colorectal → C18, col → C53) et déduit detected_cancer de la situation finale. Pas de transcodage morphologique : un test n’est pas un diagnostic.
3. Enregistrement - les lignes valides deviennent des signalements ; un même test re-livré met à jour la ligne existante (upsert).

Le rapprochement avec un patient (réconciliation) se fait ensuite, dans une étape séparée : rien à préparer pour ça dans le CSV.

Spécificités

• Table fille dédiée report_depistages (1:1 avec reports, report_type = 'depistage'), avec ses champs structurés propres (programme, dates, résultat, situation finale). Réconciliation, contrôles et exclusion sont portés par le parent reports, communs à tous les types.
• Déduplication / réimport : la clé d’un test est screening_number + test_date + screening_program. test_date est volontairement dans la clé - deux tests d’une même personne à des dates différentes ne sont pas des doublons et restent tous deux visibles (parcours ARC). Seul le même test re-livré dans une vague CRCDC ultérieure entre en collision : il est alors upserté (mise à jour de la ligne report_depistages, le parent reports reste intact), ce qui permet de compléter une situation finale arrivée dans une vague suivante. Robuste aux livraisons cumulatives comme incrémentales - le data manager n’a pas à dédupliquer son fichier.
• Transcodage propre : pas de transcodage CIM-O-3 ; la topographie cimo3_topo_code est dérivée en dur du programme (indication d’organe, sans morphologie). Le transcodage des résultats/situations est à la charge du data manager (cf. Préparer son CSV).
• Champs particuliers : screening_number requis à l’import (rare pour un identifiant source) ; previous_test_date propre au calcul du cancer d’intervalle.

Points d’attention

• screening_number manquant ⇒ ligne rejetée (et clé de dédup ambiguë). Idem pour les autres obligatoires : screening_program, test_date, patient_last_name.
• screening_program hors enum (peau, prostate, valeur libre) ⇒ ligne rejetée. Filtrer peau/prostate en amont.
• test_result / final_diagnosis non normalisés : une valeur hors enum n’est pas devinée. Mapper soi-même ; à défaut, unknown.
• Négatif + patient inconnu ⇒ orphelin non conservé : aucune création de patient, ligne orphan (contrainte juridique sur les négatifs). Ne pas compter dessus pour peupler de nouveaux patients.
• Forcer can_create_tumor = oui sur un non-cancer reste sans effet : le garde-fou bloque la création de tumeur si final_diagnosis ≠ cancer. detected_cancer est calculé, jamais importé.
• Date de naissance partielle : composantes à 00/9999 ⇒ ne pas recomposer une fausse date ; laisser vide, le SI met null.
• Topographie/morphologie fournies par erreur : ignorées - le SI dérive cimo3_topo_code du programme. Ne pas tenter de coder le cancer ici.
• Codes postaux à zéro de tête mal exportés par Excel : risque de perte du premier chiffre ; formater en texte.
• Même test re-livré : c’est un upsert, pas un doublon. Inutile (et risqué) de modifier screening_number/test_date pour « éviter » une collision : on perdrait la mise à jour de la situation finale.
• excluded ≥ 2 avec un numéro inconnu du catalogue registre ⇒ rejet côté worker.