Analyse des codes erreurs de la fonction de groupage

Introduction

On convient de faire référence ici aux codes erreurs de la fonction de groupage (FG) tels que définis dans le manuel d’utilisation GENRSA (exemple C170 EXTENSION DOCUMENTAIRE OBLIGATOIRE POUR UN ACTE CCAM MAIS ABSENTE) et on suppose que le lecteur s’est déjà confronté à la problématique, classique en PMSI, de repérage et correction, si possible, de ces erreurs.

Rappel : préfixe C = erreur de contrôle, G = erreur de groupage, PG = erreur dans le FICHOMP PORG (prélèvement d’organe). Ces erreurs peuvent être bloquantes ou non bloquantes.

On s’intéresse ici aux erreurs en C non bloquantes, relevant d’une politique de contrôle qualité en continu, et à aux approches possibles pour les repérer.

Complément : une documentation ATIH des erreurs de la FG 2019 avec des interprétations par code erreur, des commentaires et un classement intéressant en familles d’erreurs (excel)

Liste des codes erreurs cités :
C093 DIAGNOSTIC ASSOCIÉ IMPRECIS
C102 ACTE CCAM : DATE DE REALISATION DE L’ACTE INCOHERENTE
C170 EXTENSION DOCUMENTAIRE OBLIGATOIRE POUR UN ACTE CCAM MAIS ABSENTE
C252 INDICATEUR DE SÉJOUR NON PROGRAMMÉ ATTENDU MAIS NON RENSEIGNÉ

Première approche : la variable «Code retour» dans les RSS et RSA

Cette variable, codée par RUM sur 3 positions (correspondant aux 3 dernières positions des code erreurs, « 000 » si pas d’erreur), correspond à une erreur rencontrée lors du groupage du RUM et de son séjour.

Première remarque : on perd l’information de préfixe des codes erreurs (par exemple 170 au lieu de C170). Généralement l’information restante (170 dans notre exemple) suffit, à partir du référentiel des codes erreurs, à retrouver le préfixe, mais cela suppose une retraitement des données.

Mais, plus grave, s’il y a plusieurs erreurs dans un RUM, seule une (à priori, soit la 1ere non bloquante, soit une bloquante) est retenue : on perd donc des informations essentielles, sans savoir celles qui manquent.

Par exemple avec les erreurs C170, il est très fréquent d’avoir plusieurs actes CCAM concernés par l’erreur dans un RUM.

Conclusion pratique : cette variable «Code retour» n’est pas exploitable en analyse.

Deuxième approche : le fichier LEG (Liste des Erreurs de Groupage)

Ce fichier est produit au groupage et logé dans le zip .out

Son cahier des charges, très simple (1 ligne par séjour concerné par au moins 1 erreur), est disponible dans le manuel GENRSA (« Format du Fichier LEG »). Pour chaque séjour repéré, on a la liste exhaustive des codes erreurs rencontrés dans le séjour.

Exemple : une suite «C170;C102;C170» pour un séjour = 2 erreurs C170 et 1 erreur C102

Ce fichier est lu et présenté dans OVALIDE dans les tableaux «[1.Q.1.EG] Synthèse des erreurs de groupage», avec un tableau pour les erreurs non bloquantes et un tableau pour les erreurs bloquantes s’il y en a.

Cette approche commence à être exploitable mais avec 2 inconvénients majeurs en pratique :

On a perdu le lien avec les RUM et donc, pour les séjours multi-RUM, on ne sait pas, à priori, quel RUM est concerné par une erreur.

Mais surtout, pour de nombreux codes erreurs (ceux liés aux codage CCAM et CIM = la très grande majorité des codes erreurs détectés en pratique), le code erreur est déclenché une seule fois par RUM si au moins une occurrence du problème est rencontré et c’est tout.

Pour ces codes erreurs, cela signifie donc que le le fichier LEG (et sa visualisation dans OVALIDE) ne permet pas de repérer toutes les situations de codage en erreur.

Reprenons notre fake séquence ci-dessus «C170;C102;C170» pour illustrer : on a 2 C170, donc 2 RUM du séjour qui ont déclenché C170, donc 2 RUM qui ont au moins un acte d’anesthésie (identifiée avec la variable activité de l’acte = 4) sans extension documentaire associée (en pratique, ce sont les seules situations de codage CCAM pour lesquelles le codage d’une extension documentaire est obligatoire).

Mais on ne sait pas combien réellement d’actes CCAM d’anesthésie sont concernés par le non codage de leur extension documentaire.

Autre exemple avec le code erreur C093 pour lequel on ne connaît pas le nombre exact de DAS imprécis, mais uniquement le nombre de RUM avec au moins un DAS imprécis

C’est problématique pour, par exemple, calibrer un temps TIM nécessaire à la correction d’un type d’erreur.

A ce propos, même si la documentation OVALIDE est explicite, signalons que le libellé affiché « Nombre d’erreurs » dans le tableau [1.Q.1.EG] est ambigu et est à lire « Nombre de RUM avec au moins une fois l’erreur »

Un contre-exemple de code erreur pour lequel l’exploitation du fichier LEG est suffisant : le code erreur C252 qui concerne un codage unique (la variable «Non programmé») au niveau séjour. Dans ce cas, on a total C252 = total des erreurs.

Troisième approche : recalculer les erreurs

Pour les erreurs concernées, il ne reste donc plus qu’à re-identifier (en R, Python, via logiciel d’analyse PMSI) les codages concernés.

Heureusement, l’immense majorité des erreurs répond à une requête simple et en pratique, un établissement tourne généralement avec un nombre limité d’erreurs qui reviennent.

Et donc, via une bibliothèque de scripts maison et/ou un logiciel, un établissement peut raisonnablement, aujourd’hui, disposer d’une solution réaliste pour calculer en routine les nombres réels d’erreurs, les repérer et arbitrer, en connaissance de cause : extraire les listes de codages en erreur pour correction ou assumer de laisser passer.

Pour aller + loin :

Pour ceux que cela intéresse, code R pour identifier les actes CCAM déclenchant le code erreur C170

La liste des codages CCAM avec clé d’identification des RUM est obtenue par extraction d’un logiciel de production si possible, un outillage maison en routine ou dans un fichier JSON via l’accès Standard à PMSISoft MCO en ligne, gratuit, sans limite de durée, proposé à tout établissement de santé MCO qui en fait la demande.