Fiche pratique data manager - PMSI (séjour hospitalier / RUM)

Nom technique : pmsi

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

Vocation

Le signalement PMSI décrit un séjour hospitalier vu à travers le Programme de Médicalisation des Systèmes d’Information. La source est l’export PMSI de l’établissement (issu des RSS / RUM produits pour la facturation : DP, DR, DAS codés en CIM-10, actes CCAM, dates et modes d’entrée/sortie). On en attend l’identification des passages hospitaliers liés à un cancer (chirurgie, chimio, radiothérapie, hospitalisation diagnostique) et le rattachement de ces séjours aux patients et tumeurs du registre. Qualité a priori : volume très élevé, exhaustivité administrative forte, mais codage orienté facturation - beaucoup de bruit non-cancer, des codes de séance (Z51.*) ou d’antécédent (Z85) en diagnostic principal, et un cancer réel souvent porté par le DR ou un DAS plutôt que le DP. Le tri de pertinence oncologique est donc largement à la charge du data manager en amont (aucun filtre côté outil).

Format canonique d’import

Une ligne = un RUM (Résumé d’Unité Médicale = passage dans un service). Une hospitalisation produit plusieurs RUM : par exemple 30 séances de chimio = 30 lignes partageant les mêmes dates d’hospitalisation mais portant chacune leur propre identifiant de RUM.

Séparateur de colonnes : ; (ou ,, auto-détecté). Encadrez de guillemets "…" toute valeur contenant le séparateur. Les colonnes packées utilisent le séparateur d’entrées | et, pour les actes, le sous-séparateur :.

Colonnes attendues, dans l’ordre du manifeste (toutes fournies) :

Colonne (csvKey)	Libellé	Format attendu	Obligatoire	Nature
finess	FINESS	code (majuscules, points/espaces retirés)	-	Établissement
nrss	N° RSS	code	- (voir note)	Identifiant RUM
nadm	N° admission	code	- (voir note)	Identifiant RUM
nrum	N° RUM	code	-	Identifiant RUM
ghm	GHM	texte	-	Séjour
uf_code	Code UF	texte	-	Unité fonctionnelle
uf_label	Libellé UF	texte	-	Unité fonctionnelle
entry_date	Date entrée hôpital	date JJ/MM/AAAA ou AAAA-MM-JJ	oui	Date (hospitalisation)
exit_date	Date sortie hôpital	date	-	Date (hospitalisation)
entry_mode	Mode entrée	entier	-	Séjour
entry_provenance	Provenance	texte	-	Séjour
exit_mode	Mode sortie	entier	-	Séjour
exit_destination	Destination	texte	-	Séjour
dp	Diagnostic principal (DP)	code CIM-10	oui	Diagnostic
dr	Diagnostic relié (DR)	code CIM-10	-	Diagnostic
das_codes	Codes DAS	liste de codes CIM-10 packés par |	-	Diagnostics (table fille)
actes	Actes CCAM	entrées packées par |, chaque acte = date:CCAM:phase:activité (4 champs séparés par :)	-	Actes (table fille)
patient_last_name	Nom	texte	-	Identité patient
patient_first_name	Prénom	texte	-	Identité patient
patient_birth_name	Nom de naissance	texte	-	Identité patient
patient_birth_date	Date de naissance	date	-	Identité patient
patient_sex	Sexe	texte (M/F)	-	Identité patient
patient_ipp	IPP	texte	-	Identité patient
patient_secu	N° Sécu (NIR)	NIR (seuls les 10 premiers chiffres conservés)	-	Identité patient
patient_address	Adresse	texte	-	Adresse
patient_postal_code	Code postal	code postal (zéros de tête restaurés)	-	Adresse
patient_city	Ville	texte	-	Adresse
patient_birth_commune	Commune de naissance	texte	-	Lieu de naissance
patient_birth_postal_code	Code postal de naissance	code postal	-	Lieu de naissance
patient_birth_insee_code	Code INSEE de naissance	texte (5 chiffres)	-	Lieu de naissance
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

Note identifiants : finess, nrss et nadm sont individuellement non obligatoires dans le manifeste, mais une règle transverse impose qu’au moins un de nrss ou nadm soit rempli (sinon la ligne est rejetée). Renseignez nrum dès qu’il est disponible.

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

Préparer son CSV à partir de la source brute

Travail concret pour passer de l’export PMSI (RSS / RUM) au CSV canonique. Check-list :

1. Filtrer le bruit non-cancer EN AMONT. Le PMSI est volumineux et codé pour la facturation. L’outil n’applique aucun filtre : ne transmettez que les séjours d’intérêt oncologique. Repérez-les sur la présence d’un code C* en DP, DR ou DAS, ou d’un code de séance Z51.* pointant vers un cancer en DR/DAS. Écartez les séjours sans aucun code cancer.
2. Une ligne = un RUM. Ne pré-agrégez pas une hospitalisation en une seule ligne : éclatez en autant de lignes que de RUM. Les RUM d’une même hospitalisation partagent entry_date/exit_date mais se distinguent par leur identifiant de RUM.
3. Mapper les colonnes locales vers les csvKey du tableau Format canonique d’import. Les libellés source varient selon l’établissement ; alignez-vous sur les csvKey.
4. Identifiants de RUM : remplissez au moins nrss ou nadm sur chaque ligne, et nrum si disponible. C’est la base de la clé de déduplication (finess + (nadm||nrss) + nrum). Conservez les zéros de tête de nrum (traité comme chaîne).
5. FINESS : obligatoire en pratique mais récupérable depuis la base FINESS nationale (https://finess.esante.gouv.fr/). Un même export peut contenir plusieurs établissements ; le SI listera les FINESS trouvés à l’import et proposera une structure de repli pour les lignes au FINESS absent ou non reconnu.
6. UF : fournissez uf_code et/ou uf_label selon ce dont vous disposez (les deux sont conservés).
7. Dates : JJ/MM/AAAA ou AAAA-MM-JJ, sans heure. Ne confondez pas les 4 dates : entry_date/exit_date = entrée/sortie de l’hospitalisation (dupliquées sur tous les RUM d’une même hospi) ; les dates de RUM/UF, si vous les avez dans votre source, ne sont pas reprises par l’import actuel et ne doivent pas remplacer les dates d’hospitalisation.
8. NIR : ne transmettez que les 10 premiers chiffres dans patient_secu. Le SI tronque de toute façon - ne jamais exporter le NIR complet.
9. Codes diagnostics : dp, dr et les das_codes sont des codes CIM-10. Ils seront mis en majuscules et débarrassés des points/espaces par le SI ; la présence ou non du point n’a pas d’incidence.
10. Packing des DAS : concaténez les codes CIM-10 associés dans das_codes séparés par |, dans l’ordre du RSS (l’ordre compte : voir Points d’attention, règle « 1er DAS valide »). Ex. C77.0|I10.
11. Packing des actes : chaque acte au format date:CCAM:phase:activité, exactement 4 champs séparés par :, les actes séparés par |. Un champ manquant se laisse vide en gardant les :. Ex. 2024-01-10:AAAA001:: (phase et activité vides). Une entrée qui n’a pas ses 4 champs fait rejeter la ligne.
12. Mode de sortie 9 = décès : dans ce cas la date de fin d’hospitalisation (exit_date) vaut date de décès. Vérifiez sa cohérence.
13. Exclusions amont : pour les séjours à exclure du traitement registre sans les retirer du fichier, utilisez la colonne excluded (cf. Comportement par défaut à l’import).

Comportement par défaut à l’import

• Valeurs par défaut : can_create_patient = true et can_create_tumor = true. Le PMSI n’est pas une typologie en « rattachement seul » : un séjour hospitalier oncologique est une source légitime pour créer un patient et une tumeur jusque-là inconnus du registre, d’où l’autorisation par défaut.
• Surcharge par ligne : renseignez can_create_patient et/ou can_create_tumor à oui/non sur la ligne concernée. Une cellule vide laisse le défaut (création autorisée) s’appliquer.
• Exclusion : colonne excluded. 0 ou vide = ligne non exclue ; 1 = exclusion avec motif par défaut (cause non précisée) ; ≥2 = motif spécifique au catalogue du registre. Un numéro inconnu du catalogue est rejeté par le SI.

Ce que fait le système à l’import

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

1. Validation - champs obligatoires (entry_date, dp, au moins un identifiant de RUM) et formats (dates, actes packés). Une ligne invalide est rejetée, motif affiché dans l’aperçu avant import.
2. Transcodage et mise en qualité - il choisit le code cancer caractérisant par priorité DP → DR → DAS, le traduit en CIM-O-3 (règle de préfixe), calcule les groupes (Berg, IARC) et les indicateurs chimio / radiothérapie déduits des actes.
3. Enregistrement - les lignes valides deviennent des signalements, avec leurs tables filles (DAS, actes).

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

• Trois niveaux : la ligne CSV alimente le séjour (report_pmsi) plus deux tables filles 1:N - report_pmsi_das (un DAS par code de das_codes, avec sa position dans le RSS) et report_pmsi_actes (un acte par entrée de actes). DP et DR restent uniques sur le parent.
• Déduplication sans upsert : clé finess + (nadm||nrss) + nrum (nrum vide → "1"). Le codage PMSI ne change pas après envoi (il sert à la facturation) : au réimport d’un même lot, les lignes dont le hash existe déjà sont ignorées (skip), pas mises à jour. Le rapport d’import liste les lignes sautées.
• Transcodage direct CIM-10 → CIM-O-3 : la topographie est recopiée du code CIM-10 (chapitre II), sans passer par une table ADICAP (contrairement à l’ACP). La morphologie suit la règle de préfixe : C* → 80003 (/3 malin), D00-D09 → 80102 (/2 in situ), D10-D36 → 80000 (/0 bénin), D37-D48 → 80001 (/1 incertain).
• Flags actes calculés : has_chemo/has_radiotherapy (séjour) et is_chemo/is_radiotherapy (acte) sont déduits des codes CCAM via les tables de référence - ne pas les fournir.

Points d’attention

• Ligne rejetée si : entry_date ou dp manquant (champs obligatoires) ; ni nrss ni nadm renseigné ; une entrée de actes n’a pas ses 4 champs date:CCAM:phase:activité (gardez les : vides plutôt que de supprimer un champ).
• Code caractérisant par priorité DP → DR → 1er DAS valide. Conséquence directe sur la prep :
  • Un code de séance Z51.* en DP (Z51.1 chimio, Z51.0 radiothérapie) n’est pas un cancer : le vrai cancer doit figurer en DR ou DAS, sinon le séjour part comme non oncologique.
  • Z85 = antécédent de cancer (pas un cancer actif).
  • Un C80 (site primitif inconnu) en DP n’est pas informatif : recherchez le site réel en DR/DAS.
  • Les codes métastases C77*, C78*, C79* ne sont pas retenus comme code primitif caractérisant - ils n’identifient pas l’organe d’origine. Mettez le primitif en DP/DR/DAS si vous le connaissez.
  • Seuls les codes commençant par C (hors C77-C79) sont « cancer valides ». Les codes D00-D48 sont transcodables en CIM-O-3 mais ne sont pas retenus comme code caractérisant.
• Ordre des DAS load-bearing : quand le code caractérisant tombe sur les DAS, c’est le premier DAS valide dans l’ordre du fichier qui est choisi. Respectez l’ordre du RSS dans das_codes.
• Séjour non oncologique : si aucun code cancer valide n’est trouvé (DP, DR, DAS), le séjour est importé mais characterizing_code reste NULL - donnée peu exploitable. Filtrez ces cas en amont (Préparer son CSV, étape 1).
• Multi-organes : si plusieurs codes cancer valides de groupes de Berg différents coexistent, seul le code prioritaire est retenu ; le SI lève has_other_organ_groups et liste les autres - informez-vous-en, mais ne dédoublez pas la ligne.
• NIR complet = fuite : n’exportez jamais plus de 10 chiffres. Le SI tronque, mais ne lui donnez pas la matière.
• Ne pas confondre les 4 dates : entry_date/exit_date = hospitalisation (identiques sur les RUM d’une même hospi) ; les dates de RUM ne sont pas reprises. Coder la date de RUM dans entry_date casse la cohérence inter-RUM.
• Réimport : ne comptez pas sur un import pour corriger un codage déjà envoyé - les lignes déjà vues sont sautées, pas mises à jour. Pour corriger, il faut changer la clé (improbable) ou intervenir hors import.