Fiche pratique - PMSI

Nom technique : pmsi

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

Vocation

Le signalement PMSI décrit un séjour hospitalier, tel que l’établissement l’exporte (RSS / RUM, codage CIM-10 orienté facturation). C’est une source à très haut volume mais bruitée : beaucoup de séjours non-cancer, des codes de séance (Z51.*) ou d’antécédent (Z85), et un cancer souvent porté par le DR ou un DAS plutôt que le DP. Le tri des séjours non-oncologiques est à la charge du data manager en amont (aucun filtre côté outil) ; en revanche, sur un séjour retenu, le système sélectionne lui-même le code cancer par priorité DP → DR → DAS.

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 ; recommandé (, également auto-détecté) ; entourez de guillemets "…" toute cellule contenant le séparateur ou un retour ligne. En-têtes en snake_case, identiques aux csvKey du tableau ci-dessous et dans l’ordre du manifeste. Toutes les colonnes sont des champs fournis par le data manager, sauf les trois contrôles d’import (can_create_patient, can_create_tumor, excluded) en fin de tableau.

Colonnes packées : le séparateur d’entrées est | et, pour les actes, le sous-séparateur :.

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_date_rum	Date entrée RUM	date	-	Date (RUM)
exit_date_rum	Date sortie RUM	date	-	Date (RUM)
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 intégrée au SI. 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. Deux niveaux : entry_date/exit_date = dates d’hospitalisation (dupliquées sur tous les RUM d’une même hospitalisation) ; entry_date_rum/exit_date_rum = dates du RUM (propres à chaque ligne), à renseigner si votre source les distingue. Ne mélangez pas les deux niveaux.

8. NIR (patient_secu) : le système ne conserve que les 10 premiers chiffres (garde-fou : espaces et caractères non numériques retirés, troncature à 10 chiffres). Inutile de le tronquer à la main.

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.

Colonne excluded :

• 0 ou vide = ligne non exclue ;
• 1 (ou une valeur vraie sans numéro : oui/x/true) = exclusion avec le motif par défaut (motif global n°1) ;
• ≥ 2 = motif spécifique du catalogue d’exclusion du registre. Un numéro inconnu du catalogue fait rejeter la ligne.

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 (identito-vigilance) se fait ensuite, dans une étape séparée, sur l’identité créée à l’import : 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"). 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. 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.

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).
• Ordre des DAS : quand le code cancer retenu tombe sur les DAS, c’est le premier DAS valide dans l’ordre du fichier qui est choisi. Respectez donc 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.
• Ne pas confondre les deux niveaux de dates : entry_date/exit_date = hospitalisation (identiques sur tous les RUM d’une même hospitalisation), entry_date_rum/exit_date_rum = RUM (propres à chaque ligne). Ne mettez pas une date de RUM dans les colonnes d’hospitalisation.
• Réimport : un réimport ne corrige pas un codage déjà envoyé - les lignes déjà vues sont ignorées (skip), pas mises à jour.