Aller au contenu

Fiche pratique data manager - Signalement générique

Nom technique : generic

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

Le type générique est le fourre-tout du SI Registres : il enregistre une donnée en périmètre du registre qui ne rentre dans aucune catégorie établie (ACP, PMSI, ALD, RCP, dépistage). Les sources typiques sont le réseau de surveillance du mésothéliome, l’enquête permanente cancer (EPC), la biologie moléculaire, les protocoles du registre pédiatrique, les examens cytogénétiques, les autopsies - et tout flux ad hoc sans modèle dédié. Chaque ligne porte un source_label libre (« Réseau mésothéliome », « EPC »…) qui joue le rôle de sous-type. Le registre attend de ce type qu’il capte une donnée qui serait sinon perdue, en restant souple sur le contenu : seuls le nom et la date de naissance sont exigés. Par construction, le type générique est non comparable d’un registre à l’autre (chaque registre nomme et alimente ses propres sources). Sa qualité a priori est hétérogène : la donnée peut être très partielle (patient « XY », sans code tumeur), ou au contraire structurée (CIM-O-3 fourni) - le SI ne préjuge de rien et ne rejette qu’en cas d’absence des deux champs obligatoires.

Séparateur de colonnes : ; (le , est aussi accepté, séparateur auto-détecté ; encadrer de guillemets "…" toute valeur contenant le séparateur). Aucune colonne packée dans ce type : une seule valeur par cellule, un seul couple topo/morpho par ligne.

Tableau exhaustif des colonnes attendues, dans l’ordre du manifeste :

Colonne (csvKey)LibelléFormat attenduObligatoireNature
patient_last_nameNomtexteouifourni
patient_first_namePrénomtexte-fourni
patient_birth_nameNom naissancetexte-fourni
patient_birth_dateDate naissancedate (JJ/MM/AAAA ou AAAA-MM-JJ)ouifourni
patient_sexSexetexte (M ou F)-fourni
patient_nipIdentifiant patient (NIP/IPP)texte-fourni
patient_secuN° Sécu (NIR)NIR (seuls les 10 premiers chiffres conservés)-fourni
patient_addressAdressetexte-fourni
patient_postal_codeCode postalcode postal (zéros de tête restaurés)-fourni
patient_cityVilletexte-fourni
patient_birth_communeCommune de naissancetexte-fourni
patient_birth_postal_codeCode postal de naissancecode postal (zéros de tête restaurés)-fourni
patient_birth_insee_codeCode INSEE de naissancetexte (5 caractères)-fourni
finessFINESScode (majuscules, points/espaces retirés)-fourni
prescriber_namePrescripteurtexte (médecin ou structure)-fourni
prescriber_addressAdresse prescripteurtexte-fourni
prescriber_postal_codeCP prescripteurcode postal (zéros de tête restaurés)-fourni
prescriber_cityVille prescripteurtexte-fourni
prescriber_rppsRPPS prescripteurcode (majuscules, points/espaces retirés)-fourni
cimo3_topo_codeCode CIM-O-3 topographiecode (ex. C504) - saisi tel quel, jamais transcodé-fourni
cimo3_morpho_codeCode CIM-O-3 morphologiecode (ex. 8500/3) - saisi tel quel, jamais transcodé-fourni
report_dateDate du documentdate (JJ/MM/AAAA ou AAAA-MM-JJ)-fourni
cr_contentCompte renduvaleur brute (texte libre, conservé tel quel)-fourni
can_create_patientPeut créer un patientoui/non (1/0, vrai/faux, x acceptés)-contrôle
can_create_tumorPeut créer une tumeuroui/non (1/0, vrai/faux, x acceptés)-contrôle
excludedExcluentier (0/vide, 1, ou ≥ 2 = motif registre)-contrôle

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

Le travail du data manager consiste à aplatir SA source (export réseau, EPC, CR biomol, protocole pédiatrique, CR d’autopsie, fichier ad hoc…) vers les colonnes ci-dessus. Check-list :

  1. Une source = un import = un source_label. Si vous mélangez plusieurs origines (mésothéliome + biomol), faites plusieurs imports : le source_label est saisi une fois dans la modale et s’applique à tout le fichier. Choisissez un libellé stable et parlant, c’est lui qui servira de sous-type pour les filtres ultérieurs.
  2. Mapper les colonnes locales vers les csvKey. Reprenez l’en-tête de l’exemple. L’auto-mapping reconnaît aussi quelques alias d’en-tête (NIR pour patient_secu, Commune naissance, CP naissance, Code INSEE naissance), mais le plus sûr est de coller exactement les csvKey.
  3. Garantir les deux obligatoires. Chaque ligne doit avoir patient_last_name ET patient_birth_date non vides, même partiels : nom « XY » ou trois lettres, date approximative acceptée tant qu’elle est au format date. Une ligne sans l’un des deux est rejetée (voir Points d’attention).
  4. Normaliser les dates (patient_birth_date, report_date) en JJ/MM/AAAA ou AAAA-MM-JJ. Tout autre format (ex. JJ-MM-AAAA, dates Excel sérialisées, mois en lettres) est lu comme vide → rejet si c’est la date de naissance.
  5. Préparer le NIR (patient_secu). Vous pouvez fournir le NIR complet (13 ou 15 chiffres) : le SI ne conserve que les 10 premiers chiffres (sexe, année, mois, lieu de naissance) - non ré-identifiants. Inutile de tronquer en amont, mais retirez tout caractère non numérique parasite.
  6. Codes (finess, prescriber_rpps). Saisis tels quels : le SI passe en majuscules et retire points et espaces. Les codes postaux (*_postal_code) tronqués par un passage en numérique (ex. 1000) sont re-complétés à 5 chiffres (01000) automatiquement.
  7. CIM-O-3 - optionnel et brut. Un seul couple cimo3_topo_code / cimo3_morpho_code par ligne (topo type C504, morpho type 8500/3). Aucun transcodage côté SI : si votre source code en CIM-10 ou SNOMED, transcodez en CIM-O-3 EN AMONT. Pas de champ topo/morpho en texte libre (contrairement à l’ACP). Si vous n’avez pas de code, laissez vide.
  8. Plusieurs tumeurs = plusieurs lignes. Le type générique est mono-code : pour deux localisations sur le même patient, dupliquez la ligne identité et changez le couple topo/morpho. Ne tentez pas de packer plusieurs codes dans une cellule.
  9. Données non structurées → cr_content. Mutation EGFR, résultat de caryotype, conclusion d’autopsie, texte de protocole : tout le texte libre va dans cr_content, conservé tel quel. Encadrez de guillemets "…" toute cellule contenant un ;.
  10. FINESS par ligne (optionnel). Renseignez finess quand la ligne provient d’un établissement précis et identifiable ; sinon laissez vide, la ligne prendra la structure choisie dans la modale. Un FINESS inconnu retombe aussi sur la structure de la modale (le FINESS reste tracé tel quel).
  11. Exclusions et droits de création : voir Comportement par défaut à l’import - gérés ligne par ligne via can_create_patient, can_create_tumor, excluded.
  12. Dédoublonner EN AMONT. Il n’y a aucune déduplication à l’import : chaque ligne crée un signalement. Si votre source contient des doublons, nettoyez-les avant l’import (voir Spécificités et Points d’attention).
ContrôleDéfaut génériqueEffet
can_create_patienttrueUne ligne peut créer un nouveau patient s’il n’existe pas
can_create_tumortrueUne ligne peut créer une tumeur (si un code CIM-O-3 valide est présent)

Le type générique n’est PAS en « rattachement seul » : par défaut une ligne peut créer aussi bien le patient que la tumeur. C’est cohérent avec sa vocation de captation - la donnée générique est souvent la seule trace d’un cas (mésothéliome, pédiatrie…), il faut donc pouvoir matérialiser patient et tumeur, pas seulement rattacher à un existant.

Surcharge ligne par ligne (colonnes de contrôle, dernières du CSV) :

  • can_create_patient / can_create_tumor : mettez non (ou 0/faux) pour interdire la création sur une ligne précise (ex. donnée trop incertaine, on veut seulement tenter un rattachement). Vide = on garde le défaut true.
  • excluded : 0 ou vide = ligne non exclue ; 1 = exclusion avec motif par défaut (cause non spécifiée) ; ≥ 2 = numéro d’un motif d’exclusion spécifique au catalogue du registre. Une orthographe « vraie » sans numéro (oui/x/true) est interprétée comme 1. Un numéro inconnu du catalogue du registre fait rejeter la ligne côté worker.

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

  1. Validation - champs obligatoires (nom, date de naissance) et formats de dates. Une ligne invalide est rejetée, motif affiché dans l’aperçu avant import.
  2. Mise en qualité - très légère : les codes CIM-O-3 sont conservés tels quels (pas de transcodage, ni de groupes Berg/IARC, ni de code caractérisant). La validité d’un code n’est vérifiée qu’à la création de tumeur, pas à l’import.
  3. Enregistrement - les lignes valides deviennent des signalements (une ligne = un signalement, pas de table fille, pas de déduplication).

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

  • Pas de table fille : le générique est en 1:1 avec reports (report_generics), aucun éclatement vers une table enfant (pas de DAS, d’actes, de tumeurs multiples…).
  • Aucune déduplication, aucun upsert : pas de dedup_hash ni de source_record_id. Réimporter le même fichier recrée des doublons - comme le type ALD. La maîtrise des doublons est entièrement à la charge du data manager, en amont.
  • CIM-O-3 sans transcodage ni dérivation : les codes sont stockés bruts. Pas de berg_group, pas de topo_iarc, pas de code caractérisant calculé. La validation des codes ne joue pas à l’import mais à la consommation (création de tumeur) : un code hors référentiel est conservé mais ne produira pas de tumeur.
  • source_label = sous-type : champ libre saisi dans la modale, propre à chaque registre - d’où la non-comparabilité inter-registres.
  • prescriber_name polyvalent : un seul champ pour le médecin ou la structure prescriptrice (comme en ALD) ; il n’y a pas de champ practitioner_name séparé.
  • cr_raw_content : champ texte libre (colonne CSV cr_content) pour les données non structurées - même rôle que le fallback ACP.
  • Rejet de ligne : absence ou format invalide de patient_last_name ou patient_birth_date. Ce sont les seuls champs obligatoires - tout le reste, CIM-O-3 compris, peut être vide sans rejet.
  • Date au mauvais format = champ vide : seuls JJ/MM/AAAA, AAAA/MM/JJ et AAAA-MM-JJ sont reconnus. Une patient_birth_date mal formatée n’est pas « tolérée » - elle est lue comme vide, donc la ligne est rejetée. Une report_date mal formatée est juste perdue (silencieusement vide).
  • CIM-O-3 hors référentiel : conservé, mais pas de tumeur. Aucun rejet à l’import, mais aucune tumeur ne sera créée à partir d’un code inconnu - le cas reste visible pour l’ARC mais « orphelin » de tumeur. Vérifiez vos codes en amont si vous voulez que la tumeur soit créée.
  • Transcodage à votre charge : CIM-10 / SNOMED non gérés. Un code non-CIM-O-3 sera stocké tel quel et ne donnera pas de tumeur valide. Pas non plus de topo/morpho en texte.
  • excluded ≥ 2 inconnu du catalogue du registre → rejet de la ligne par le worker. Utilisez 1 si vous voulez juste exclure sans motif précis.
  • Doublons silencieux : aucune protection. Un réimport ou des lignes redondantes créent autant de signalements. À nettoyer avant import.
  • source_label n’est pas une colonne : ne l’ajoutez pas au CSV, il serait ignoré. Il se saisit dans la modale et vaut pour tout le fichier - d’où un import par source.
  • Sentinelle ? : une cellule contenant uniquement ? est traitée comme vide (convention de certaines sources). Si ? est une vraie valeur dans votre source, remplacez-la avant import.
  • Mono-code : packer plusieurs couples topo/morpho dans une cellule ne fonctionne pas ; il faut dupliquer la ligne. Tout caractère superflu dans un code (8500 / 3) est nettoyé (points/espaces retirés, majuscules).