PMSI SMR

Réflexions sur les calculs de taux d’occupation des UM SSR d’HC

Régulièrement, nous constatons des taux d’occupation de services d’hospitalisation complète en SSR, calculés à partir de données PMSI, qui sont incohérents. 

Nous définirons classiquement le TO d’une UM comme ceci : TO = (nombre de JP* sur la période civile) / (nombre de lits de l’UM sur la période civile)

Ces calculs, à priori « simples », recèlent en effet quelques points d’attention qui doivent être maîtrisés pour être justes et donc exploitables.

# Ne prendre en compte que les JP de la période civile
C’est le principal redressement à opérer et la cause principale des incohérences relevées. Les RHS étant à cheval sur les débuts et fins de périodes civiles, il convient de « rapprocher » les JP issues des RHS des périodes civiles pour éliminer les JP hors de la période choisie.
Exemple avec le calcul du TO sur la période M9 2017 :
a) on ne tient pas compte des RHS des semaines de 2016 jusqu’à la semaine 51 de 2016 pour les séjours avec une partie dans la période
b) dans le RHS de la semaine 52 de 2016, ne retenir que la présence le dimanche, qui correspond au 1er janvier 2017
c) dans le RHS de la semaine 39 de 2017, exclure le dernier jour qui correspond au 1er octobre 2017

# Travailler au niveau des RHS
Le comptage des JP doit se faire au niveau des RHS en tenant compte de la date de sortie de séjour (voir ci-dessous # Les jours de sortie hors Décès). Cela permet de gérer le cas des séjours multi-UM.

# Traiter ad’hoc le cas particulier des séjours terminés avant le 1er mars 2017.
Jusqu’au 1er mars 2017, ce n’était pas la règle de présence à minuit qui s’appliquait. Il y avait donc des journées comptées qui ne le sont plus (exemple : une sortie un vendredi soir) et, à l’inverse, des journées non comptées qui le sont depuis lors (exemple : une rentrée de permission un dimanche soir). Globalement, cela s’équilibre et, en pratique, nous ne retraitons pas. Mais il peut y avoir des cas particuliers qui l’imposent.
En 2018, ce cas particulier ne se posera plus.

# Les jours de sortie hors Décès
Les jours de sortie hors Décès ne sont pas cochés comme JP dans les RHS. Il convient pourtant de les réintégrer car, bien que non valorisés, il est raisonnable, en HC, de considérer que le lit est occupé ce jour là et que le jour n’est pas compté 2 fois car il n’y a pas un nouveau patient qui rentre dans le lit le même jour.

# Les permissions
Faut-il exclure ou pas les journées de permissions du nombre de JP calculé pour le calcul des TO ?
Nous ne le pensons pas, car ces lits, bien que non valorisés, sont « bloqués » pendant la permission donc « occupés » de fait.
Cela veut donc dire que le nombre de JP utilisé pour le calcul des TO est différent du nombre de JP absolu.

# Le nombre de lits
Vérifier régulièrement la justesse de ce nombre par UM par rapport aux disponibilités réelles des lits par UM
Adapter le calcul en intra-annuel si nécessaire (par exemple : 30 lits au 1er semestre et 25 lits au 2eme semestre).

Pour aller plus loin :
On a vu que dans le calcul du TO standard, on comptabilisait des journées valorisées en DMA et des journées non valorisées (comme les jours de sortie hors décès). Il peut donc être intéressant de calculer aussi un TO avec les seules JP valorisées en DMA en considérant que les jours de sortie hors décès en ZF sont valorisées par le TZF.

*JP = Journées de Présence au sens PMSI (présence à minuit)

Copyright © Lespmsi.com – Imprimer cet article

Les nouveautés du PMSI SSR 2018

Liste des articles des nouveautés du PMSI SSR 2018 qui entrent en vigueur au 1er mars 2018, en distinguant les nouveautés propres au champ PMSI et les nouveautés communs à tous les champs.

Nouveautés du PMSI SSR en 2018
# Nouveaux tarifs GMT 2018
# Arrêté tarifaire SSR 2018 – financement des activités SSR
Coefficient de transition SSR 2018 – Limite à -1%
Nouveautés du Guide Méthodologique SSR 2018
Version 2018 des GME
# Nouveaux GMT 2018 de soins palliatifs
# Dates des transmissions du PMSI SSR 2018
Nouvelle dépendance à l’habillage ou à la toilette
Nouvelle variable : « Type d’unité spécifique »
Suppression du modulateur BN « Nécessité de recours à un interprète » en 2018
# Pondérations CSARR en 2018
Date de réalisation CSARR obligatoire
Les nouveautés 2018 du référentiel des actes CSARR
# Publication des fichiers texte de référence du CSARR 2018
Codage des ACE réalisés « hors les murs » par les praticiens SSR
# Nouvelle règle de clôture des séjours longs
# Nouveautés du format 2018 des RHS groupés
# Format M1B des RHS groupés en 2018
# Nouveau format FICHCOMP SSR en 2018
# Recueil complémentaire sur la « Nutrition parentérale à façon » en SSR à partir de M7 2018

Nouveautés inter-champs : 
# Nouveautés CIM-10 en 2018
Nouveau format VID-HOSP 2018
# Nouveau format RSF ACE 2018

Projet pmeasyr : interview exclusive

Nous signalons le projet pmeasyr, package en R, le langage dédié aux statistiques bien connu des DIM, qui permet de réaliser des analyses PMSI en toute autonomie, y compris sur de grosses bases PMSI de plusieurs 100 000 lignes. Il s’agit d’un projet open source, né à l’AP-HP, qui gère tous les champs du PMSI (MCO, SSR, PSY, HAD et ACE). Découvrir pmeasyr en vidéo
Quelques résultats possibles avec pmeasyr :
# séjours MCO avec un code ou une famille de codes diagnostics quelles que soient leurs positions DP, DR ou DAS (ex : séjours avec un code d’épilepsie)
# séjours MCO avec l’acte EBLA003 « Pose d’un cathéter relié à une veine profonde » quelle que soit le RUM dans lequel est codé l’acte
# file active des patients avec un code d’obésité en E66 dans l’établissement et/ou selon la position de codage du code d’obésité
# file active d’une chirurgie en distinguant les activités CCAM
# DMS sur les séjours de plus de 0 jour
# DMS par GHM/GHS

Pour en savoir plus, nous avons interviewé Guillaume PRESSIAT, à l’initiative de ce projet, qui a bien voulu répondre à nos questions.

Bonjour Monsieur PRESSIAT. Quelques mots d’introduction sur le projet pmeasyr. Pouvez-vous nous dire comment est né ce projet au sein du DIM de l’AP-HP ? Pour répondre à quels besoins d’analyses PMSI que ne satisfont pas les logiciels actuels d’analyse PMSI et de statistiques ?

Bonjour, au départ l’idée était de privilégier un logiciel que j’ai plaisir à utiliser. Il ne s’agit pas d’abandonner les autres logiciels pour autant, mais R peut concentrer la plupart des étapes d’une étude : importer les données, faire les analyses, produire un document de présentation des résultats en vue de leur communication. On jongle trop souvent entre plusieurs logiciels, ce qui est source d’erreurs et de confusion.

Le projet est donc né d’un besoin que je partage avec des médecins Dim, internes en santé publique et statisticiens d’avoir accès aux données avec une certaine liberté d’usage, au niveau séjour, si possible sans logiciel du marché. Je ne détaillerai pas ici l’historique du projet : essentiellement, en 2016, la création d’un groupe d’utilisateurs R parmi les Dim AP-HP a ouvert le package à d’autres utilisateurs, et permis d’officialiser l’utilisation du package. La diffusion en dehors de l’AP-HP via github a été actée, avec l’idée suivante : ceux qui ont besoin d’une telle solution peuvent l’utiliser, et l’améliorer en participant s’ils le souhaitent.

Les requêtes possibles sont assez illimitées (limitées par les idées de l’utilisateur et les données). Pour donner un exemple différent de ceux présentés sur le site, il est assez aisé et rapide de faire du chaînage intra/inter champs et ainsi de décrire les parcours de patients. On peut aussi aisément faire des cartographies et visualisations interactives dans R.

Quelle équipe travaille aujourd’hui sur le développement de pmeasyr à l’AP-HP ?

Je suis le développeur de pmeasyr et j’ai autour de moi des collègues statisticiens et des médecins Dim qui utilisent le package, m’apportent leurs idées, remarques et commentaires.

Je tiens à remercier les membres du groupe des utilisateurs de R à l’AP-HP. Particulièrement, le Dr Namik Taright (DIM Siège – DOMU – AP-HP) pour son encadrement et ses idées, le Dr Kristel Cosker (HU Pitié Salpêtrière) pour son utilisation du package, sa disponibilité, et l’ensemble de ses remarques ainsi que le Dr Rémi Flicoteaux (HU Saint Louis Lariboisière) pour sa motivation et les pistes de travail qu’il propose.

Les DIM des différents établissements de l’AP-HP travaillent-ils avec pmeasyr ? Quels sont leurs retours ?

Des Dim de l’AP-HP utilisent le package en effet, leurs retours me permettent d’améliorer la documentation et le package lui-même. Des retours positifs concernent justement la documentation qui permet de bien démarrer ; un autre retour m’a été fait sur la facilité d’utilisation du package. Un retour plus négatif concerne les années prises en charge par le package (l’année de départ est 2011), alors que pour certaines études cliniques (cohortes) il est nécessaire d’avoir des données plus anciennes : dans ce cas pmeasyr ne convient pas. J’explique ce point de départ en 2011 par le fait que, à partir de cette année, les formats sont devenus plus homogènes.

Avez-vous des contacts avec d’autres CH ? Certains d’entre eux travaillent-ils déjà ou ont-ils vocation à travailler sur pmeasyr ?

J’ai eu des contacts venant de plusieurs CH de par la France. J’ai découvert cette dimension intéressante dans l’ouverture d’un outil : échanger avec des personnes exerçant le même métier que nous mais dans des catégories d’établissements différentes. Leurs questions concernent l’installation de pmeasyr, le format des données, ou bien sont inhérentes aux outils de l’ATIH et aux transmissions lamda, et parfois concernent R en général. Leurs retours sur le package sont plutôt positifs.

Lors de l’ouverture du package, nous avions pensé à son utilisation dans le cadre de la mise en place des GHT : mise en commun des données PMSI (elles sont au même format), activité, file active, étude des parcours de patients en intra GHT…

Aujourd’hui pmeasyr importe les zip «officielles » .in et .out produits par les logiciels ATIH après groupage dans les différents champs PMSI. Selon notre expérience, pour de nombreux établissements, produire et accéder en toute fluidité à ces .zip n’est pas évident. Est-il prévu que pmeasyr puisse, à l’avenir, importer et travailler à partir de simples fichiers « bruts » de production (fichiers de rss, de rhs, de rpss, vid-hosp, fichcomp, et…) ?

Mon travail se situe entre les hôpitaux et la transmission ATIH (description d’activités, calculs de valorisations, etc.). Donc les données que j’utilise principalement sont les out, prêtes à être transmises sur epmsi et en accord avec la donnée officielle qui figurera dans la base nationale. L’avantage étant qu’il est possible de “faire le pont” avec les données in en récupérant les numéros administratifs locaux des séjours, avec les fichiers tra.

Mais dans les hôpitaux la demande peut être différente, c’est plus le in qui est intéressant. C’est d’ailleurs un autre retour des Dim AP-HP, souvent leur besoin est d’étudier des données avant transmission. Techniquement c’est possible pour le MCO avec pmeasyr puisque l’import des in est pris en charge, il suffit de nommer le fichier brut finess.annee.mois.rss.txt, mais pour le SSR je n’ai pas rédigé les fonctions d’imports des in. Il y a là une piste d’évolution.

Si ce besoin est urgent, une autre piste pour étudier les données brutes avant transmission dans R est de se connecter avec R à la base de données / outil de recueil dans lequel sont les données, ou exporter ces données au format texte (en csv par exemple) et importer dans R ces fichiers texte (avec le package readr par exemple), sans passer par pmeasyr pour l’import des données.

R est maintenant un langage bien connu des DIMs et ses qualités sont reconnues (gratuité, base de connaissances facilement accessible, importante communauté garante de sa pérennité, performance en volume, fonctionnalité et rapidité). Toutefois, d’après nos échanges avec de nombreux DIM, démarrer avec R « fait peur » (interface austère, installation, premiers imports, premières requêtes). Qu’auriez-vous à dire aux DIM à ce sujet ?

Les langages de programmation, dont R fait partie, peuvent faire peur. Prenons une analogie classique : faire du vélo pour la première fois, cela fait un peu peur, pourtant ensuite le “savoir faire” du vélo est une chose utile et agréable. C’est pareil pour la programmation. En plus, avec la communauté R et la documentation sur internet, il devient de plus en plus facile de trouver réponses aux questions que l’on se pose. Si l’on peut avoir peur de débuter, il ne faut pas avoir peur de poser des questions (autour de soi, ou sur internet, avec les moteurs de recherche). Pour bien débuter il faut donc prendre le temps de se poser des questions : pourquoi cela ne fonctionne pas ? Est-ce que je peux le faire autrement ? Etc.

Au sujet des premiers imports dans R, il y a quelques années c’est vrai que c’était parfois fastidieux, les premières lignes d’un programme commençant par read.csv(?, ?, ?) où chaque ? correspondait à au moins une hésitation. Il existe désormais un ensemble de packages, appelé tidyverse qui fonctionnent en harmonie et facilitent toutes les étapes dans R (import avec readr ou readxl, requêtes et manipulations de données avec dplyr et tidyr, etc.). Mon conseil aux Dim serait de se tourner vers ces packages. pmeasyr s’inscrit dans cette veine. Et depuis que ces packages existent, comparé à d’autres langages, R est très accessible, surtout en utilisant l’interface utilisateur RStudio, ou les notebook Jupyter : on peut exécuter un programme et visualiser le résultat, c’est très pratique et cela rend les données plus concrètes et “palpables”. Ces avantages sont visibles dans la vidéo présentant le package.

En plus, on peut utiliser R sur Windows, Mac Os et Linux, sur un ordinateur fixe ou portable. Et le package pmeasyr fonctionne sur toutes ces plateformes.

Dans un tout autre cadre, des médecins et chirurgiens utilisent désormais R pour la recherche, pour accéder à des plateformes de publications médicales en ligne (comme PubMed). L’utilisation de R / RStudio ne concerne donc plus uniquement le champ des traitements statistiques.

En combien de temps un DIM peut-il raisonnablement prendre en main pmeasyr et produire des premiers résultats ?

Le temps pour l’installation de R + RStudio + pmeasyr ne dépasse pas une vingtaine de minutes.

En suivant la documentation on peut réaliser un premier import en quelques minutes.

En considérant les retours de Dim AP-HP, je dirais que quelques heures suffisent largemment pour commencer à exploiter des données d’une année sur un champ spécifique avec pmeasyr. Une fois un premier projet réalisé, il est assez aisé de repartir de celui-ci pour en faire d’autres.

Est-ce qu’avec pmeasyr, les requêtes, une fois codées, sont bien sauvegardées pour une réutilisation ultérieure ?

Oui c’est un des grands avantages de R, comme de la programmation en général : automatiser ce qui n’est pas forcément le plus passionnant à faire pour se concentrer sur des choses plus intéressantes : les données, ce qu’elles contiennent, leur qualité… Que l’on choisisse de procéder avec un simple script (ou programme), ou que l’on s’oriente vers la structuration de projets avec RStudio, chaque requête peut être sauvegardée et réutilisée rapidement par la suite.

Une partie de mon travail à l’AP-HP concerne d’ailleurs ce point : constituer et mettre à disposition un catalogue de requêtes où l’on peut piocher, pour étudier une thématique. Actuellement nous structurons ces listes de requêtes dans une api (web service). Cette api contient également les référentiels métiers usuels (CCAM, Cim-10, Csarr, finess, etc.), et est accessible partout à l’AP-HP à travers notre intranet.

Sous quel délai, après le 1er mars de chaque année, la mise à jour du package pmeasyr sera-t-elle disponible en MCO et SSR pour importer les nouveaux formats ?

Les formats paraissent en même temps que les outils de l’ATIH, c’est un moment crucial où il faut mettre à jour les tables de formats en même temps que les données sont produites avec les outils. Dès que les données AP-HP sont prêtes, je peux tester mes programmes dessus et les valider.

Les données au format du 1er mars sont produites fin mars, c’est à ce moment que je mets à jour les formats. Pour 2017, j’avais informé sur le blog d’une mise à jour le 9 avril 2017. Je considère que c’est un délai raisonnable pour s’assurer du bon fonctionnement dans tous les champs (dans l’ordre de priorité MCO > SSR > HAD > RSF > PSY), d’autant que la première transmission des données sous ce format est réalisée fin avril.

En exclusivité, pourriez-vous nous indiquer quelques exemples de résultats produits par pmeasyr pas encore rendus publics sur le site de pmeasyr ?

Dernièrement, nous avons calculé avec pmeasyr :

  • le taux de recours à l’HAD AP-HP des GH AP-HP
  • les indicateurs de performance et d’activité ATIH (IPA)
  • les indicateurs Périnat à venir
  • les effectifs du recours exceptionnel
  • les délais de prise en charge pour la chirurgie du cancer du sein

Le package intègre désormais des fonctions permettant d’intégrer les données dans une base de données : il n’est plus nécessaire de les réimporter ensuite à chaque fois, elles sont dans la base de données.

Je finalise actuellement des fonctions qui automatisent la rédaction et l’exécution de requêtes, ces fonctions seront bientôt disponibles dans le package

Monsieur PRESSIAT, nous vous remerçions

Evolutions possibles de la classification des GME

Mise à jour 02 janvier 2018 : la version des GME mise en œuvre en mars 2018 et appelée V2018, sera la même que celle de 2017.

Les évolutions décrites ci-dessous ne seront donc pas intégrées en 2018.

Lors d’une récente réunion fin décembre 2017, l’ATIH a présenté une liste d’évolutions possibles de la classification GME.

Principales caractéristiques de cette possible nouvelle classification :

# Création d’un Indice Synthétique de Lourdeur médico-Economique (ISLE), calculé à partir des variables « diagnostics CMA et actes CCAM CMA », « dépendance physique », « dépendance cognitive », « indicateur post-chirurgical » ou « âge » pour classer les séjours et semaines en 3 niveaux de lourdeur, au lieu des 2 niveaux de sévérité actuels.

# Création d’un niveau de classification dit « Sous-GN », subdivision des GN (Groupes Nosologiques), visant à identifier explicitement certaines populations et/ou certaines prises en charge via l’âge ou des actes marqueurs pour une description médicalement lisible des séjours.

# Création de groupes de RR (Rééducation-Réadaptation), calculés à partir des scores RR pour traduire les différents niveaux de rééducation à patient égal.

# Les codes GME passent de 6 positions à 7 positions pour tenir compte de cette nouvelle classification :
4 premiers caractères = classification en GN comme en V2017
+ 1 caractère = classification du sous-GN : P = Pédiatrie, A = Adulte, Z = Indifférencié, J, K, L = selon actes marqueurs
+ 1 caractère =  classification dans un groupe d’ISLE : 0 en HP, 1,2 ou 3 en HC
+ 1 caractère = classification dans un groupe de RR : modéré, élevé, très élevé, indifférencié

Commentaire :
Que ce nouveau modèle s’applique en 2018 ou en 2019, on constate l’importance accrue du codage CSARR dans la classification des GME, donc dans leurs valorisations DMA, via la classification systématique des GME en groupe de RR. Rappelons que le codage CSARR contribue aussi aux recettes DMA via le coefficient de spécialisation. Et comme le socle DMA se calcule sur les années N-1 et N-2, on ne peut qu’inviter les établissements à un effort raisonnable dans leur codage CSARR en 2018.

Les colonnes du fichier DIAGINFO

Le fichier excel DIAGINFO est un des 10 référentiels OVALIDE MCO, diffusé chaque année par l’ATIH au mois de mai pour l’année PMSI en cours.

DIAGINFO est la table des caractéristiques des codes diagnostics CIM-10 issues des données nationales de l’année N-1 avec de nombreuses informations exclusives et très intéressantes pour chaque code CIM-10. Il s’agit d’un référentiel indispensable à utiliser pour tout DIM.

Ces informations sont largement utilisées par les tableaux OVALIDE de tous les champs PMSI et pas seulement en MCO. C’est par exemple dans DIAGINFO que l’on trouve la caractérisation « IMPRECIS » des codes CIM-10.

Le descriptif des colonnes n’est pas évident à trouver. Pour en faciliter la compréhension et l’utilisation de ce fichier, nous détaillons ci-dessous ses 27 colonnes : 
# RARE = Caractère peu fréquent du diagnostic (1 : OUI ; 0 : NON)
# DPCHIR = Diagnostic associé à un acte opératoire (0 : NON ; 60 à 100 : % d’association avec un acte opératoire)
# DAGUE = Diagnostic dague nécessitant obligatoirement un code astérisque (1 : OUI ; 0 : NON)
# SEXD = Diagnostic incompatible avec un sexe (1 : diagnostic uniquement chez l’homme ; 2 : diagnostic uniquement chez la femme ; 0 : pas d’incompatibilité)
# CL1V = Diagnostic improbable pour un âge <= 28 jours (1 : OUI ; 0 : NON)
# CL2V = Diagnostic improbable pour un âge > 28 jours et < 1 an (1 : OUI ; 0 : NON)
# CL3V = Diagnostic improbable pour un âge compris 1 et 9 ans (1 : OUI ; 0 : NON)
# CL4V = Diagnostic improbable pour un âge compris 10 et 19 ans (1 : OUI ; 0 : NON)
# CL5V = Diagnostic improbable pour un âge compris 20 et 64 ans (1 : OUI ; 0 : NON)
# CL6V = Diagnostic improbable pour un âge >= 65 ans (1 : OUI ; 0 : NON)
# ZINHAB = Diagnostic Z inhabituel en DP (0 : RAS ; 1 : INHABITUEL ; 2 : LIMITE)
# IMPRECIS = Imprécision du diagnostic (0 : RAS ; 1 : IMPRECIS ; 2 : TRES IMPRECIS)
# ZAFFCHR = Code Z généralement associé à une affection chronique ou de longue durée (1 : OUI ; 0 : NON)
# CODEXT = Code Cim10 concerné par une extension (0 : RAS ; 1 : PERE ; 2 : FILS)
# CODSEQ = Code représentant une séquelle (1 : OUI ; 0 : NON)
# TIMPRECIS = Codes T (complication) imprécis ne devant pas être utilisé en DP (1 : OUI ; 0 : NON)
# TINTOX = Code d’intoxication (1 : OUI ; 0 : NON)
# CMA = Code considérée comme complication de niveau 2, 3 ou 4 (2, 3 ou 4 : OUI ; 0 : NON)
# DPACTE = Diagnostic associé à un acte (-1 OU 0 : NON ; > 0 à 100 : % d’association avec un acte)
# DGCPT669 = Diagnostic compatible avec la racine 23C02 (1 : OUI ; 0 : NON)
# BRULURE = Diagnostic de ‘brulure’ (1 : OUI ; 0 : NON)
# ESTH = Diagnostic pouvant être associé à un acte de chirurgie esthétique (1 : OUI ; 0 : NON)
# AFFAIG = Diagnostic dont le libellé mentionne le mot « aigue » (1 : OUI ; 0 : NON)
# COMPIMPRECIS = Code concernant une complication (1 : OUI ; 0 : NON)
# AUTRES = Code diagnostic autres (.8) CMA (2 : OUI non CMA 1 : OUI CMA ; 0 : NON)
# BURULUREBIS = Code de cause de brûlure (1 : OUI ; 0 : NON)
# SEANCE = Code de séance (1 : OUI ; 0 : NON) 

Précision méthodologique :
# le fichier DIAGINFO en 2017 a 40 231 lignes, ce qui correspond au nombre exact de codes CIM-10 actifs en 2017
# pour les nouveaux codes CIM-10 introduits en 2017, certaines informations ne sont donc pas disponibles (exemple : le très improbable X341+0 « Victime de tsunami, en pratiquant un sport » n’est pas considéré comme RARE !).
# les codes CIM-10 supprimés en 2017 ne sont plus documentés (exemple : les codes d’obésité comme E6600, E6601, etc..) dans la version 2017.

Source : fichiers OVALIDE MCO 2017 (fichier zip)
Copyright © Lespmsi.com – Imprimer cet article