Fiche pratique data manager - Signalement ALD

Nom technique : ald

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

Vocation

L’ALD (Affection de Longue Durée) est une déclaration administrative remplie par le médecin traitant et adressée à l’Assurance Maladie pour ouvrir une prise en charge à 100 % au titre d’une affection longue et coûteuse. Pour le registre du cancer, la liste des ALD oncologiques (principalement ALD 30 - tumeurs malignes) constitue une source de signalement complémentaire : elle rattrape les cancers diagnostiqués hors hôpital (libéral, ville) que ni l’ACP ni le PMSI n’ont fait remonter. Un signalement ALD se résume au tuple (patient, code CIM-10, médecin déclarant, date d’ouverture) : très peu de variables, pas de PDF, pas d’organe explicite, pas de stade. Les sources habituelles sont les caisses (CNAM / Régime général, MSA, ex-RSI, régimes spéciaux), souvent via un préparateur tiers (p. ex. ISPED Bordeaux pour le RG). Qualité a priori faible : le déclarant n’est pas forcément cancérologue, le codage CIM-10 est moins rigoureux qu’en anapath. La source doit donc rester clairement identifiable comme ALD en aval, et ne crée ni patient ni tumeur sans validation humaine (voir Comportement par défaut à l’import).

Format canonique d’import

Fichier CSV ou xlsx (première feuille uniquement). Séparateur de colonnes ; recommandé (, également auto-détecté) ; entourer de guillemets "…" toute valeur contenant le séparateur. En-têtes en snake_case, identiques aux csvKey ci-dessous, dans cet ordre. Aucune colonne packée pour l’ALD (une seule valeur par cellule, pas de séparateur |).

Colonne (csvKey)	Libellé	Format attendu	Obligatoire	Nature
patient_last_name	Nom	texte	oui	fourni
patient_first_name	Prénom	texte	oui	fourni
patient_birth_name	Nom de naissance	texte	-	fourni
patient_birth_date	Date de naissance	date (JJ/MM/AAAA ou AAAA-MM-JJ)	oui	fourni
patient_sex	Sexe	texte (M/F, ou 1/2)	-	fourni
patient_ipp	IPP (identifiant patient stable)	texte (BENEFIC côté CNAM)	-	fourni
patient_secu	N° Sécu (NIR)	NIR (seuls les 10 premiers chiffres conservés)	-	fourni
beneficiary_type	Type bénéficiaire	assuré / ayant-droit (insured / dependent)	-	fourni
patient_death_date	Date décès	date (JJ/MM/AAAA ou AAAA-MM-JJ)	-	fourni
patient_birth_commune	Commune de naissance	texte	-	fourni
patient_birth_postal_code	Code postal de naissance	code postal (zéros de tête restaurés)	-	fourni
patient_birth_insee_code	Code INSEE de naissance	texte (5 caractères)	-	fourni
patient_address	Adresse	texte (concaténé : rue puis complément)	-	fourni
patient_postal_code	Code postal	code postal (zéros de tête restaurés)	-	fourni
patient_city	Ville	texte	-	fourni
prescriber_name	Prescripteur	texte (nom du médecin déclarant)	-	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 (majuscules, points/espaces retirés ; ou NUM_MED CNAM)	-	fourni
cim10_code	Code CIM-10	code (mis en majuscules, points/espaces retirés)	oui	fourni
ald_opening_date	Date ouverture ALD	date (JJ/MM/AAAA ou AAAA-MM-JJ)	oui	fourni
ald_mutation_date	Date mutation	date (JJ/MM/AAAA ou AAAA-MM-JJ)	-	fourni
source_ald_id	N° protocole de soins	texte (NUM_CP côté CNAM)	-	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, 1, ou ≥ 2)	-	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 travail concret du data manager : transformer l’export de caisse (CNAM/ISPED, MSA, ex-RSI…) vers le CSV canonique ci-dessus. Un fichier par régime (les formats diffèrent) ; cadence annuelle (consolidation vers février N+1, réception mars–juillet).

Sélection et filtres (en amont) :

• Ne garder que les lignes ayant à la fois un cim10_code et une ald_opening_date. Le code CIM-10 est normalement le critère d’extraction de votre source.
• Vérifier aussi la présence de patient_last_name, patient_first_name, patient_birth_date : toute ligne sans ces 5 champs sera rejetée à l’import.
• Supprimer les lignes vides, séparateurs de section, lignes sentinelles.
• Remplacer toute valeur sentinelle ? (sources CNAM) par une cellule vide ; trimmer le padding par espaces (CNAM padde souvent les chaînes à largeur fixe).

Mapping des colonnes locales → csvKey (exemple ISPED Régime général 33) :

Header source	→ csvKey canonique
BENEFIC	patient_ipp
NIR	patient_secu
NOM_BEN	patient_last_name
PRENOM_BEN	patient_first_name
DATENAISSA	patient_birth_date
NUMER + C + RUE_BEN (concaténés)	patient_address
CODEP (1ʳᵉ occurrence)	patient_postal_code
COMMUNE_BEN	patient_city
NUM_MED	prescriber_rpps
NOM_MED	prescriber_name
NUMERO + RUE_MED (+ COMPLEMENT_MED si ≠ ?)	prescriber_address
CODEP (2ᵉ occurrence)	prescriber_postal_code
COMMUNE_MED	prescriber_city
PATHOLO	cim10_code
DEBUT_CP	ald_opening_date
NUM_CP	source_ald_id
ELSM	supprimé (informationnel, non utilisé)

Normalisation des champs :

• Dates (patient_birth_date, ald_opening_date, patient_death_date, ald_mutation_date) : passer en JJ/MM/AAAA ou AAAA-MM-JJ. Une date non parseable sur un champ obligatoire fait rejeter la ligne.
• cim10_code : le SI le met en majuscules et retire points/espaces - pas besoin de le normaliser, mais vérifier qu’il s’agit bien d’un code unique par ligne (pas de liste).
• NIR (patient_secu) : pas de troncature à faire, le SI ne conserve que les 10 premiers chiffres. Mais voir le piège beneficiary_type ci-dessous.
• beneficiary_type : renseigner assuré ou ayant-droit. Crucial - si ayant-droit, le NIR peut être celui du conjoint/parent ; sans cette mention le SI risque de compléter l’identité (commune de naissance, etc.) depuis un NIR qui n’est pas celui du patient.
• Codes postaux (patient_postal_code, patient_birth_postal_code, prescriber_postal_code) : restaurer les zéros de tête (perdus si la source les a passés en entier sous Excel - p. ex. 1234 → 01234).
• Adresse : concaténer les champs multiples de la source en un seul patient_address, ordre rue puis complément. Idem pour prescriber_address.

Champs facultatifs mais utiles à fournir s’ils existent :

• patient_death_date : déclenche les règles de statut vital à la réconciliation.
• patient_birth_commune / patient_birth_postal_code / patient_birth_insee_code : commune de naissance.
• ald_mutation_date : changement de caisse / département du bénéficiaire.

Dédoublonnage :

• Aucune déduplication automatique côté SI : toutes les lignes sont insérées. Deux médecins peuvent déclarer la même ALD pour un même patient → deux lignes conservées. Dédoublonner en amont si souhaité ; sinon l’ARC tranchera en aval.

Volumétrie de contrôle : ~7 000 à 12 000 lignes / an / département, tous régimes confondus. Distribution attendue dominée par C50 (sein), C61 (prostate), C34 (poumon), C18 (côlon)…

Comportement par défaut à l’import

• Rattachement seul. Pour l’ALD, can_create_patient et can_create_tumor valent non par défaut (override automatique à l’ETL). Raison métier : la donnée ALD est trop pauvre pour créer un patient ou une tumeur sans décision humaine - un signalement ALD seul ne suffit jamais, l’ARC valide manuellement.
• Surcharge par ligne. Le data manager peut forcer, ligne par ligne, via les colonnes can_create_patient / can_create_tumor : valeurs acceptées oui/non (ainsi que o/n, true/false). Une cellule vide laisse le défaut (non).
• Colonne excluded : 0 ou vide = ligne non exclue ; 1 (ou une valeur vraie type oui/x/true sans numéro) = exclusion avec motif par défaut (raison globale 1) ; un entier ≥ 2 = motif spécifique du catalogue du registre (un numéro inconnu du catalogue fait rejeter la ligne par le worker).

Ce que fait le système à l’import

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

1. Validation - champs obligatoires (nom, prénom, date de naissance, cim10_code, ald_opening_date) et formats de dates. Une ligne invalide est rejetée, motif affiché dans l’aperçu avant import.
2. Transcodage et mise en qualité - si le code CIM-10 est un code cancer valide, il devient le code caractérisant, traduit en CIM-O-3 (règle de préfixe) avec ses groupes (Berg, IARC) ; sinon la ligne est conservée sans tumeur candidate.
3. Enregistrement - les lignes valides deviennent des signalements (une ligne = un signalement, pas de table fille).

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

• Pas de table fille. 1 ALD = 1 ligne = 1 signalement ; relation 1:1 avec reports. Pas de table d’actes, de séjours ni de codes multiples (contrairement au PMSI ou à l’ACP).
• Code unique par ligne. Un seul cim10_code par déclaration ; pas de code caractérisant multi-codes, pas d’algorithme « DP → DR → DAS ».
• Transcodage CIM-10 → CIM-O-3 par règle de préfixe (calculé par le SI) : C* → malin (80003), D00-D09 → in situ (80102), D10-D36 → bénin (80000), D37-D48 → incertain (80001).
• Prescripteur = médecin déclarant, pas un établissement de soins. prescriber_rpps contient l’identifiant déclarant (souvent un RPPS, parfois un NUM_MED CNAM, parfois vide) ; non normalisé entre sources, pas de lien FINESS.
• Réimport = duplication. Sans déduplication ni dedup_hash, réimporter le même fichier dupliquera toutes ses lignes. Rare en pratique (envoi annuel), mais à éviter.

Points d’attention

• Ligne rejetée si l’un des 5 champs obligatoires manque ou est non parseable : patient_last_name, patient_first_name, patient_birth_date, cim10_code, ald_opening_date. Le preview reporte la raison (missing_last_name, missing_birth_date, missing_opening_date…).
• NIR d’ayant-droit non marqué : si beneficiary_type n’est pas renseigné alors que le NIR est celui du conjoint/parent, le SI peut compléter l’identité du patient à partir d’un NIR erroné. Toujours renseigner assuré / ayant-droit.
• Codes postaux en entier (Excel) : 01234 devient 1234 → restaurer les zéros de tête avant export.
• Sentinelle ? non nettoyée : reste telle quelle si la source n’est pas convertie en amont (l’ETL la mappe vers null pour les sources CNAM connues, mais ne pas compter dessus pour un format inattendu) ; trimmer aussi le padding par espaces.
• Code CIM-10 non-cancer (tout code ne commençant pas par C : D00-D48, Z51.0/Z51.1 de séance, etc.) : la ligne est conservée mais characterizing_code reste vide → aucune tumeur candidate générée, et la ligne est filtrée par défaut côté ARC. À garder en tête si votre extraction laisse passer des codes non oncologiques.
• Codes secondaires / métastases C77*, C78*, C79* : reconnus comme C mais exclus de la recherche du primitif - ne pas s’attendre à ce qu’ils caractérisent une tumeur primitive.
• Doublons non filtrés : toutes les lignes entrent. Si plusieurs déclarations de la même ALD polluent le travail ARC, dédoublonner en amont - le SI ne le fera pas.
• source_ald_id non unique : un même numéro de protocole peut revenir (renouvellements). Ne pas l’utiliser comme clé d’unicité.
• Une seule structure par fichier : ne pas mélanger plusieurs régimes/départements dans un même import ; la structure source est choisie une fois pour tout le fichier dans l’interface.