FONCTION GROUPAGE

 

Depuis 1990, le ministère de la Santé mettait à la disposition des intégrateurs infor­ma­tiques le « noyau de programmation » nécessaire au groupage, sous la forme d'une librai­rie informatique complétée de tables, l'ensemble étant appelé fonction groupage (FG). En 1996, le ministère de la Santé introduisit une nouveauté, en mettant le pro­gramme source de cette FG à la disposition des intégrateurs.

 

Les informaticiens peuvent donc l'intégrer dans leurs logiciels groupeurs, ce qui leur permet d'obtenir un groupage conforme à la description du manuel des GHM. Aucune obligation ne leur est faite cependant d'avoir recours à la FG, et certains choix de déve­lop­pement conduisent des informaticiens à développer leur propre moteur de groupage.

 

Pour l'utilisateur final, qui continue de recevoir gratuitement la version annuelle de GENRSA (ou son équivalent intégré dans le logiciel AGRAF pour les établissements pri­vés), la garantie d'un groupage conforme est fournie par les vérifications que réalise ce programme, puisque GENRSA (AGRAF) intègre lui-même la FG : pour produire des RSA, GENRSA (AGRAF) lit un fichier de RSS groupés, c'est-à-dire un fichier de RSS déjà traités par le groupeur de l'utilisateur, et outre le fichier de RSA produit en sortie, il éta­blit un rapport d'exécution dans lequel l'analyse de la conformité de groupage est détail­lée.

 

Cependant, la FG a suivi les évolutions de la classification des GHM, et s'est adaptée aux besoins nouveaux (contenu du RUM en particulier), de sorte que plusieurs versions successives ont été diffusées depuis 1990. Le tableau ci-dessous récapitule d'une manière synthétique ces différentes versions, indiquant notamment leur date de mise en service, les nomenclatures reconnues (CIM, CdAM, CCAM), la version de la classification corres­pon­dante (c'est-à-dire la version des tables), et le format de RUM reconnu.

 

Ce tableau emploie une normalisation de la désignation de la FG : FG a.b, dans la­quelle a représente le numéro de version du moteur de groupage, et b le numéro de ver­sion des tables.


 

Intitulé

Version du moteur de groupage

Version de la classification (tables)

CIM

CdAM

CCAM

Format de RUM

Date de mise en service

GENRSA
(ou remarque)

FG0.0

0

0

9

1985 à 1987

 

86 car

1990

(diffusion restreinte)

FG1.1

1

1

9

1985 à 1991

 

86 car

février 1992

GENRSA 1

FG1.2

1

2

9

1985 à 1991

 

86 car

1993

(Languedoc-Roussillon uniquement)

FG2.2

2

2

9

1985 à 1994

 

86 car

format 002

format 003

février 1994

GENRSA 2

FG2.3

2

3

9 et 10

1985 à 1995

 

86 car

format 002

format 003

juillet 1995

GENRSA 3.3b

FG3.4

3

4

10

1985 à 1996

 

format 003

format 004

format A04

janvier 1997

GENRSA 4

FG4.5

4

5

10

1985 à 1997

 

format 003

format 004

format A04

janvier 1998

GENRSA 4.5

FG5.6

5

6

10

1985 à 2000

 

format 004

format A04

format 005

format A05

janvier 2000

GENRSA 5.6

FG6.7

6

7

10

1985 à 2002

version 0 (2002)

format 007

format 008

janvier 2002

GENRSA 6.7

FG 6.8

6

8

10

1985 à 2002

version 0bis (2003)

format 007 format 008

janvier 2003

GENRSA 6.8

FG 7.9

7

9

10

1985 à 2002

version 0bis (2003)

format 007 format 008

janvier 2004

GENRSA 7.9

 

 

1.1. Lecture des diagnostics

 

Les formats de RUM applicables depuis le 1er janvier 2000 prévoient huit positions par code de diagnostic, afin de permettre la saisie de codes ayant reçu des extensions sur les positions 7 et 8.

 

Or, la saisie des extensions à huit positions n’étant que facultative, la FG pourrait avoir à traiter des RUM dont les uns indiqueraient par exemple S37800 (code S37.800 de Lésion traumatique de la glande surrénale, sans plaie intraabdominale) tandis que d’autres pré­ciseraient S37800XC pour donner une précision qu’une société savante (fictive ici) aurait recommandé de coder avec l’extension XC ; le groupage devrait pourtant dans les deux cas être le même.

 

Aussi la première opération effectuée par la FG, avant de les traiter, est-elle de tron­quer les codes des diagnostics lus dans le RUM pour n’en conserver que les six premiè­res positions.

 

Cependant, dans la plupart des cas où de telles extensions existent – ou existeront – il y a fort peu de chances que les positions 5 et 6, réservées aux extensions « officielles », soient déjà occupées, l’exemple S37.800XC ci-dessus ayant précisément été construit pour la compréhension de la démonstration, mais réalisant une exception notable.

 

Un problème pratique se posait donc pour éviter une confusion de lecture aux opéra­teurs de saisie qui dans les services recueillent les RUM, problème résolu par la générali­sation du principe de « comblement des espaces » déjà appliqué pour les positions 4 et 5 : le symbole « + » est employé comme symbole de remplissage, ce qui par exemple donne actuellement S47.+0, et pourrait donner F38.0++8A pour l’extension 8A.

 

Pour permettre un résultat de groupage cohérent, il faut alors que pour la saisie F380++8A la troncature mentionnée plus haut aboutisse non pas à F380++ mais bien à F380, tandis que S47+0 doit rester inchangé et ne pas aboutir à S470. C’est pourquoi, en complément à la troncature après la sixième position, la FG procède-t-elle ensuite à l’élimination, de la droite vers la gauche, de tous les caractères « + » qu’elle rencontre dans un code de diagnostic, et interrompt cette opération dès qu’elle rencontre un carac­tère au­tre que « + ».

 

Par ailleurs, les données à visée documentaire (DAD) n’interviennent en aucune ma­nière sur le groupage, et sont tout simplement ignorées par la FG, qui peut procéder aux opérations de contrôles (voir plus loin) du moment que la longueur du RUM est en cohé­rence avec les nombres de DAS, DAD et actes mentionnés. Si tel n’est pas le cas, la FG in­terrompt le groupage en mentionnant une erreur de format.

 

 

1.2. Algorithme de détermination du diagnostic principal

 

Dans un grand nombre de cas le RSS est composé de plusieurs RUM et l’on parle alors de RSS multiunité.

 

Il arrive, de manière non exceptionnelle, que le diagnostic principal porté dans les dif­férents RUM d'un tel RSS ne soit pas concordant. Cette situation peut également affecter non plus le diagnostic principal, mais le diagnostic relié. Dans ces deux cas, la FG em­ploie alors un algorithme, détaillé ci-dessous, pour déterminer quel RUM comporte le diagnos­tic principal et le diagnostic relié uniques.

 

Évidemment, il existe deux situations dans laquelle l’algorithme n'a pas à être em­ployé :

·       lorsque le RSS est mono-unité : le diagnostic principal mentionné dans le RUM uni­que est le diagnostic principal du RSS, et le diagnostic relié, s’il en est men­tionné un dans le RUM, est celui du RSS ;

·       lorsque le RSS multiunité comporte des RUM dont d’une part tous les diagnostics principaux sont concordants, et d’autre part tous les diagnostics reliés également, puisque la question ne se pose pas.

 

Cet algorithme se déroule en plusieurs phases, chacune n'étant engagée que si la pré­cédente n'a pas abouti à une solution.

 

Phase 1           La FG repère les RUM qui comportent au moins un acte classant non mi­neur effectué au bloc opératoire (informations obtenues dans les tables, en analysant un par un chacun des actes de chaque RUM). Trois cas peuvent se présenter :

·       un seul RUM comporte un tel acte : dans ce cas, c'est lui qui contient le DP unique ; la recherche prend fin ;

·       aucun RUM ne comporte un tel acte : tous les RUM restent en lice pour la deuxième phase ;

·       deux RUM ou plus comportent un tel acte : seuls les RUM comportant un tel acte res­tent en lice pour la deuxième phase.

 

Phase 2           Parmi les RUM restés en lice, la FG repère ceux dont le DP n’a pas un « code en Z », c'est-à-dire dont le code CIM-10 ne débute pas par la lettre Z. Trois cas peuvent se présenter :

·       un seul RUM répond à cette condition (tous les autres ont un code en Z sauf lui) : dans ce cas, ce RUM comporte le DP unique ; la recherche prend fin ;

·       deux ou plusieurs RUM répondent à cette condition : seuls ces derniers restent en lice pour la troisième phase ;

·       aucun RUM ne répond à cette condition (tous les RUM ont pour DP un code Z) : tous les RUM restent en lice pour la troisième phase.

 

Phase 3           Parmi les RUM restés en lice, la FG repère celui ou ceux dont la durée de sé­jour partielle est la plus longue.

 

Il faut donc calculer la durée de séjour partielle de chaque RUM, c'est-à-dire le nom­bre de journées écoulées entre la date d'entrée et la date de sortie du RUM considéré (cette opération est précédée, le cas échéant, par la fusion des RUM consécutifs dont le code d’unité médicale est identique, cf. paragraphe 4.3). Il s'agit d'une opération arithmétique simple, qui ne doit faire l’objet d’aucune correction (en particulier aucune règle de factu­ration telle que la journée supplémentaire en cas de décès, ou le seuil de 1 journée). Le ré­sultat peut donc être égal à 0.

 

Deux cas peuvent se présenter :

·       un RUM a une durée de séjour plus longue que toutes les autres : dans ce cas, c'est lui qui contient le DP unique ; la recherche prend fin ;

·       deux RUM ou plus sont ex aequo pour la durée de séjour partielle la plus longue : seuls ces RUM ex aequo restent en lice pour la quatrième phase.

 

Phase 4           Parmi les RUM restés en lice, la FG repère ceux qui comportent un acte opéra­toire mineur, information obtenue dans les tables, en analysant un par un chacun des actes de chaque RUM. Trois cas peuvent se présenter :

·       un seul RUM répond à cette condition : dans ce cas, ce RUM comporte le DP uni­que ; la recherche prend fin ;

·       deux RUM ou plus comportent un tel acte : seuls ces derniers restent en lice pour la cinquième phase ;

·       aucun RUM ne comporte un tel acte : tous les RUM restent en lice pour la cin­quième phase.

 

Phase 5           Parmi les RUM restés en lice, la FG repère ceux qui comportent un diagnos­tic relié (DR) renseigné. Trois cas peuvent se présenter :

·       un seul RUM répond à cette condition : dans ce cas, ce RUM comporte le DP uni­que ; la recherche prend fin ;

·       deux RUM ou plus répondent à cette condition : seuls ces derniers restent en lice pour la sixième phase ;

·       aucun RUM ne répond à cette condition (tous les RUM ont un DR non renseigné) : tous les RUM restent en lice pour la sixième phase.

 

Phase 6           Parmi les RUM restés en lice, la FG retient le dernier par ordre chronolo­gique : c'est lui qui contient le DP unique. La recherche prend fin.

 

 

Devenir des autres diagnostics, élimination des doublons de diagnostics et d'actes

 

Le RUM que cet algorithme identifie comme porteur du DP unique est considéré comme porteur également du DR unique. Il est donc à noter que le DR résultant peut être « à blanc ».

 

Tous les diagnostics non retenus dans ce processus comme DP unique sont considérés comme diagnostics associés significatifs (DAS). Il en est de même pour tous les diagnos­tics non retenus comme DR unique. En effet, ces DR complètent des DP « codés en Z », qui ont donc toutes chances d’être éliminés à la phase 2 de la détermination du DP unique, alors qu’ils témoignent d’affections prises en charge au cours du séjour.

 

La FG élimine alors de la liste des diagnostics associés significatifs tous ceux qui font double emploi avec le DP unique retenu, car un diagnostic ne saurait constituer une com­plication de lui-même. Pour les mêmes raisons, la FG élimine tout DAS qui ferait double emploi avec le DR et enfin elle « met à blanc » un DR qui ferait double emploi avec le DP.

 

Ensuite est réorganisée la liste des diagnostics associés significatifs et la liste des actes pour qu'un code donné n'apparaisse qu'une seule fois, même sur des RUM distincts. Cette dernière opération est simple pour les diagnostics (élimination pure et simple des dou­blons) ; dans le cas des actes, dont les zones du RUM disposent depuis le 1er janvier 2002 d’un indicateur de nombre d’occurrences, ces derniers sont additionnés lorsque des zones distinctes d’un même RUM ou de RUM distincts comportent le même code d’acte, afin d’obtenir une seule zone d’acte pour ce code.

 

 

 

 

1.3. Fusion de RUM issus de la même unité médicale

 

Bien qu’observée de manière tout à fait exceptionnelle actuellement dans les RSS, la production de deux RUM jointifs provenant de la même unité médicale là où un seul RUM suffirait est une pratique qui va tendre à s’accroître en raison des adaptations in­dui­tes par le dispositif des prestations interétablissements introduit au 1er janvier 2000. Il autorise en effet l’établissement demandeur, sans toutefois le recommander, à établir un « RUM de pré‑prestation » et un « RUM de post-prestation ».

 

Or, si l’on se réfère au processus de détermination du RUM comportant le DP en cas de séjour multiunité (phase 3 ci-dessus), on constate qu’une telle option peut modifier le choix du DP retenu in fine, en raison de la modification des durées de séjour partielles qu’elle induit.

 

La solution, généralisée à tous les cas ou deux RUM jointifs sont porteurs du même code d’unité médicale, a été introduite avec la FG 5.6 ; elle consiste à fusionner ces RUM jointifs pour constituer un RUM unique dont la date d’entrée est celle du premier et la date sortie est celle du dernier. Le DP et le DR du RUM résultant sont déterminés par l’application de l’algorithme de choix du DP sur les RUM en cause, et le devenir des au­tres diagnostics ainsi que l’élimination des doublons suivent le même processus que celui dé­crit ci-dessus.

 

 

1.4. Les erreurs détectées par la fonction groupage

 

La constitution des RSS étant le résultat d'une suite d'opérations multiples, dont la plu­part sont manuelles, des erreurs peuvent s'y introduire. Ces erreurs peuvent être de plu­sieurs ordres : erreur de codage, erreur de saisie, erreur de hiérarchisation, problème ma­tériel, etc. se traduisant par l'absence d'une donnée, un format de donnée non conforme, une donnée incohérente, etc. Selon les cas, ces erreurs peuvent rendre impos­sible la dé­termination du GHM (absence du DP, par exemple), ou n'être que l’indice d'une qualité de données suspecte, sans conséquence absolue sur le résultat du groupage. Elles peuvent aussi traduire un dysfonctionnement matériel ou logiciel sans rapport avec le RSS traité.

 

C'est pourquoi depuis son origine la FG ne fournit pas seulement en retour la valeur du GHM correspondant au RSS traité, mais aussi un code, dit code retour, dont la valeur permet de savoir si des erreurs ont été détectées. Jusqu’à la version FG 4.5, chaque valeur du code retour indiquait une erreur d'une nature déterminée, tandis que la valeur 00 in­diquait que tout s'était bien passé.

 

Pour diverses raisons, il a semblé nécessaire, à compter de la version FG 5.6, d’améliorer ce dispositif de détection et de signalement des erreurs. L’évolution princi­pale a consisté en une hiérarchisation des erreurs détectées, classées dorénavant en trois caté­gories : les erreurs d’implémentation, les erreurs détectées par les contrôles, et les er­reurs détectées dans le parcours de l’arbre de décision du groupage.

 

Chacune de ces trois catégories dispose dorénavant d’un système propre de numéro­ta­tion des erreurs au lieu du système de numérotation commun qui s’appliquait jusqu’en 1999, ce qui multiplie par trois le nombre de possibilités de numérotation. Pour l’application en l’an 2000 (FG 5.6), on avait conservé dans chaque catégorie les anciens numéros reventilés selon leur nature, et l’on avait évité d’affecter aux nouvelles séries d’erreurs détectées des numéros existant déjà, précautions qui bien entendu ne peuvent pas être maintenues dorénavant en raison des besoins nouveaux.

 

Dans tous les cas, les erreurs de 01 à 59 sont bloquantes, ce qui signifie que le grou­page n’a pas pu être entièrement effectué, tandis que les erreurs de 60 à 99 sont non blo­quantes, certaines même n’étant pas à proprement parler des erreurs mais plutôt des alertes, voire de simples sémaphores. La valeur 00 quant à elle signifie que tout s’est bien déroulé.

 

Pour le cas des erreurs « non catastrophiques », on peut hésiter entre la démarche « laxiste » qui consisterait à grouper comme si de rien n'était (erreur non bloquante), la démarche « sanction » qui consisterait à grouper en effectuant pour la donnée erronée la supposition conduisant au cas le plus défavorable en matière de résultat de groupage (erreur non bloquante), ou encore la démarche « répressive » qui consisterait à refuser de grouper le RSS (erreur bloquante). C'est un compromis entre ces trois voies qui a été choisi pour la mise en œuvre de la FG.

 

Ces choix sont des conventions, et l'on pourrait en justifier d'autres. Cependant, étant donné que la FG fournit un code retour convenu dans une situation déterminée, et que ce code retour est recopié dans le RSS-groupé puis dans le RSA, il est indispensable pour les développeurs informatiques de calquer ces choix s’ils souhaitent réaliser des groupeurs conformes sans employer la FG (tout autre décision serait détectée par GENRSA comme une différence de groupage).

 

Notons enfin que la FG fournit les codes retour sous deux formes distinctes et simul­ta­nées, auxquelles a accès tout programme groupeur intégrant la FG:

·       trois vecteurs de codes retours, récapitulant la totalité des erreurs détectées dans le RSS pour chacune des trois catégories d’erreurs. Ces vecteurs sont riches d'infor­mation, mais ils ne sont pas normalisés ; ils peuvent être exploités de différentes manières par le programme groupeur, voire être complètement ignorés. GENRSA ne teste leur conformité en aucune façon ;

·       un code retour unique, qui doit impérativement être exploité par le programme grou­peur, et que GENRSA retrouvera identique si le RSS n'est pas modifié.

 

Jusqu’à la version FG 5.6, le code retour unique n’était affecté que par les erreurs blo­quantes. Dans la FG 6.7 il pouvait être affecté par le code 80 correspondant au signale­ment d’un GHM « médical » obtenu par évitement des groupes « Actes sans relation avec le diagnostic principal ». À partir de la présente version, le code retour peut être affecté par l’ensemble des codes erreurs bloquants ou non bloquants. Cela signifie que la seule ana­lyse du code  erreur ne permet pas de conclure à l’échec du groupage. En effet, un grou­page dans un GHM hors CM 90 avec un code retour correspondant à une erreur non blo­quante signifierait que le groupage a été correctement réalisé mais qu’une ou plusieurs erreurs non bloquantes ont été détectées.

 

1.4.1 Les erreurs d’implémentation

 

Il s’agit des erreurs provoquées par un dysfonctionnement matériel ou logiciel, comme par exemple la détection d’une capacité de mémoire vive insuffisante, l’absence d’une table nécessaire au groupage, etc. Bien entendu, la détection d’une telle erreur in­terdit au groupage de se poursuivre.

 

La liste de telles erreurs est ouverte, et tout intégrateur peut la compléter à sa guise. Seuls trois codes ont déjà été ventilés dans cette catégorie par la FG 6.7 (voir le tableau ci-dessous).

 

Le code retour prend une valeur comprise entre 01 et 59 selon la liste suivante :

 

04     TABLES ENDOMMAGÉES

08     CORRUPTION D'UNE TABLE

09     TABLE INTROUVABLE

 

Par convention, la détection d’une erreur de cette catégorie s’accompagne du résul­tat de groupage suivant : catégorie majeure 90, groupe 90Z03Z.

     

La plupart du temps, l’utilisateur confronté à ce type d’erreur devra se tourner vers son fournisseur informatique pour en trouver l’explication et la solution.

 

1.4.2 Les erreurs détectées par les contrôles

 

Il s’agit des erreurs mises en évidence par la fonction groupage à la lecture des RUM. La détection de telles erreurs, si elles sont bloquantes, interdit la poursuite du groupage mais autorise la poursuite de la détection d’autres erreurs, afin d’effectuer un diagnostic complet de la validité du RSS traité.

 

Par convention, la détection d’une erreur bloquante de cette catégorie s’accompagne du résultat de groupage suivant : catégorie majeure 90, groupe 90Z00Z.

 

En règle générale, c’est la documentation de la fonction groupage (reproduite ici même) qui permet à l’utilisateur confronté à ce type d’erreur de savoir quelle conduite tenir. En dernier recours, il s’adressera à l’ATIH, développeur de la FG, pour obtenir les précisions nécessaires.

 

Contrôles obligatoires (erreurs bloquantes)

 

Le code retour prend une valeur comprise entre 01 et 59 selon la liste suivante :

 

10     RSS MULTIUNITÉ AVEC NUMÉRO DE RSS INCONSTANT

11     NUMÉRO DE RSS ABSENT

13     DATE DE NAISSANCE ABSENTE

14     DATE DE NAISSANCE NON NUMÉRIQUE

15     DATE DE NAISSANCE IMPROBABLE PAR RAPPORT À LA DATE D'ENTRÉE

16     CODE SEXE ABSENT

17     CODE SEXE ERRONÉ

19     DATE D'ENTRÉE ABSENTE

20     DATE D'ENTRÉE NON NUMÉRIQUE

21     DATE D'ENTRÉE INCOHÉRENTE

23     RSS MULTIUNITÉ : CHAÎNAGE DATE D'ENTRÉE ‑ DATE DE SORTIE INCOHÉRENT

24     MODE D'ENTRÉE ABSENT

25     MODE D'ENTRÉE ERRONÉ OU PROVENANCE ERRONÉE

26     MODE D'ENTRÉE INCORRECT OU PROVENANCE INCORRECTE POUR COMMENCER UN RSS

27     RSS MULTIUNITÉ : MODE D'ENTRÉE INCORRECT OU PROVENANCE INCORRECTE SUR UN RUM DE SUITE

28     DATE DE SORTIE ABSENTE

29     DATE DE SORTIE NON NUMÉRIQUE

30     DATE DE SORTIE INCOHÉRENTE

32     RUM AVEC INCOHÉRENCE DATE DE SORTIE ‑ DATE D'ENTRÉE

33     MODE DE SORTIE ABSENT

34     MODE DE SORTIE ERRONÉ, OU DESTINATION ERRONÉE

35     MODE DE SORTIE INCORRECT OU DESTINATION INCORRECTE POUR CLORE UN RSS

36     NOMBRE DE SÉANCES NON NUMÉRIQUE

37     RSS MULTIUNITÉ : PRÉSENCE DE SÉANCES SUR UN DES RUM

39     DATE DE NAISSANCE INCOHÉRENTE

40     DIAGNOSTIC PRINCIPAL ABSENT

41     CODE DE DIAGNOSTIC PRINCIPAL NE RESPECTANT PAS LE FORMAT DE LA CIM

42     CODE DE DIAGNOSTIC ASSOCIÉ SIGNIFICATIF NE RESPECTANT PAS LE FORMAT DE LA CIM

43     CODE D'ACTE NE RESPECTANT PAS LE  FORMAT DU CDAM NI DE LA CCAM

45     RSS MULTIUNITÉ : DATE DE NAISSANCE INCONSTANTE

46     RSS MULTIUNITÉ : CODE SEXE INCONSTANT

49         RSS MULTIUNITÉ : MODE DE SORTIE INCORRECT OU DESTINATION INCORRECTE POUR UN RUM AUTRE QUE LE DERNIER

50     DÉLAI DE SÉJOUR INCOMPATIBLE AVEC LE PRINCIPE ADMINISTRATIF DE PRESTATION INTERÉTABLISSEMENT

51     CODE DE DIAGNOSTIC RELIÉ NE RESPECTANT PAS LE FORMAT PRÉVU

52     NOMBRE DE RÉALISATIONS D'ACTES NON NUMÉRIQUE, OU ERRONÉ

53     PROVENANCE ABSENTE

54     DESTINATION ABSENTE

55     NOMBRE DE DAS OU DE DAD ABSENT

56     NOMBRE DE DAS OU DE DAD NON NUMÉRIQUE

57     NOMBRE DE ZONES D'ACTES ABSENT

58     NOMBRE DE ZONES D'ACTES NON NUMÉRIQUE

59     FORMAT DE RUM INCONNU

 

 

Contrôles facultatifs (erreurs non bloquantes)

 

L’attribution d’un code retour unique dans le cas de l’absence d’erreur bloquante nécessite la définition d’un ordre de choix lorsque plusieurs erreurs non bloquantes ont été détectées. Cet ordre suit la logique générale de groupage : la priorité va d’abord aux erreurs concernant le diagnostic principal, puis les erreurs concernant les actes, puis les erreurs concernant les diagnostics associés, puis les erreurs concernant le diagnostic relié. Pour chaque catégorie c’est le code de numéro le plus faible qui est retourné en cas d’ex-aequo.

 

61     NUMÉRO DE RSS NON NUMÉRIQUE

62     UNITÉ MÉDICALE NON RENSEIGNÉE

64     DATE SYSTÈME ANTÉRIEURE À LA DATE D'ENTRÉE

65     DATE SYSTÈME ANTÉRIEURE À LA DATE DE SORTIE

66     NOMBRE DE SÉANCES : VALEUR INVRAISEMBLABLE

67     DIAGNOSTIC PRINCIPAL : N'A JAMAIS EXISTÉ DANS LA CIM

68     DIAGNOSTIC PRINCIPAL : N'EXISTE PLUS DANS LA CIM

70     DIAGNOSTIC ASSOCIÉ SIGNIFICATIF : N'A JAMAIS EXISTÉ DANS LA CIM

71     DIAGNOSTIC ASSOCIÉ SIGNIFICATIF : N'EXISTE PLUS DANS LA CIM

73     ACTE : N'A JAMAIS EXISTÉ NI DANS LE CDAM NI DANS LA CCAM

74     ACTE : N'EXISTE PLUS DANS LE CDAM NI DANS LA CCAM

76     NUMÉRO D'ENTITÉ JURIDIQUE NON NUMÉRIQUE

77     DATE D'ENTRÉE IMPROBABLE CAR TROP ANCIENNE

78     DATE D’ENTREE DU RUM INCOMPATIBLE AVEC UTILISATION D’UN ACTE CCAM

79     DATE DE SORTIE DU RUM INCOMPATIBLE AVEC UTILISATION D’UN ACTE CCAM

80     CODE POSTAL NON RENSEIGNÉ

81     CODE POSTAL NON NUMÉRIQUE

82     POIDS D’ENTREE NON NUMÉRIQUE

83     ZONE RÉSERVÉE NON VIDE

84     DIAGNOSTIC PRINCIPAL INVRAISEMBLABLE CAR RARE

85     DIAGNOSTIC PRINCIPAL INVRAISEMBLABLE EN RAISON DE L'ÂGE

86     DIAGNOSTIC PRINCIPAL INCOMPATIBLE AVEC LE SEXE INDIQUÉ

87     DIAGNOSTIC PRINCIPAL IMPRECIS

88     DIAGNOSTIC PRINCIPAL EN « Z » INTERDIT

89     DIAGNOSTIC PRINCIPAL DE TYPE DAGUE

90     DIAGNOSTIC ASSOCIÉ SIGNIFICATIF INVRAISEMBLABLE CAR RARE

91     DIAGNOSTIC ASSOCIÉ SIGNIFICATIF INVRAISEMBLABLE EN RAISON DE L'ÂGE

92     DIAGNOSTIC ASSOCIÉ SIGNIFICATIF INCOMPATIBLE AVEC LE SEXE INDIQUÉ

93     DIAGNOSTIC ASSOCIÉ SIGNIFICATIF IMPRECIS

94     DIAGNOSTIC RELIÉ : N'A JAMAIS EXISTÉ DANS LA CIM

95     DIAGNOSTIC RELIÉ : N'EXISTE PLUS DANS LA CIM

96     DIAGNOSTIC RELIÉ INVRAISEMBLABLE CAR RARE

97     DIAGNOSTIC RELIÉ INVRAISEMBLABLE EN RAISON DE L'ÂGE

98     DIAGNOSTIC RELIÉ INCOMPATIBLE AVEC LE SEXE INDIQUÉ

99     DIAGNOSTIC RELÉ IMPRÉCIS

 

1.4.3 Les erreurs détectées dans le parcours de l’arbre de décision du groupage

 

Il s’agit des erreurs mises en évidence pendant la phase de groupage proprement dite. Dans un cas, il s’agit d’un indicateur et non d’une erreur à proprement parler (code 80).

 

Par convention, la détection d’une erreur bloquante de cette catégorie s’accompagne du résultat de groupage suivant : catégorie majeure 90, groupe 90C01Z, 90Z01Z ou 90Z02Z.

 

En règle générale, c’est le manuel de la classification des GHM qui permet à l’utilisateur confronté à ce type d’erreur de savoir quelle conduite tenir. En dernier recours, il s’adressera à l’ATIH, développeur de la classification, pour obtenir les précisions nécessaires.

 

Erreurs bloquantes

 

Le code retour prend une valeur comprise entre 01 et 59 selon la liste suivante :

 

02     INCOMPATIBILITE SEXE‑DIAGNOSTIC PRINCIPAL

03     DIAGNOSTIC PRINCIPAL INCOHÉRENT

04     TABLES ENDOMMAGÉES

05     DIAGNOSTIC PRINCIPAL : TITRE, INSUFFISAMMENT PRÉCIS POUR LA CLASSIFICATION DES GHM

06     INCOMPATIBILITÉ ACTE‑DIAGNOSTIC

07     POIDS INCOMPATIBLE POUR UN NOUVEAU-NÉ

 

 

Signalements (non bloquants)

 

Le code retour prend une valeur comprise entre 60 et 99 selon la liste suivante :

 

80     GROUPE MÉDICAL OBTENU PAR ÉVITEMENT DU GROUPE 901 (90C01Z)

 

1.4.4 Modalités de sélection du code retour par la FG lorsque plusieurs erreurs ont été détectées

 

Si plusieurs erreurs d’implémentation ont été détectées, c’est celle dont la valeur non nulle est la plus basse qui est retournée par la fonction groupage. Elle s’accompagne du groupage en groupe 90Z03Z (ancien G910), et l’emporte sur les erreurs de groupage ou de contrôles.

 

Si plusieurs erreurs bloquantes ont été détectées par les contrôles, c’est celle dont la valeur non nulle est la plus basse qui est retournée par la fonction groupage. Elle s’accompagne du classement dans le groupe 90Z00Z et l’emporte sur les erreurs de groupage.

 

Si le groupage parvient à se dérouler, c’est-à-dire si aucune erreur d’implémentation ni aucune erreur bloquante de contrôle n’a été détectée, alors la fonction groupage retourne, selon le cas :

·       00 pour signaler un groupage correct ;

·       un code compris entre 60 et 99 pour signaler un GHM obtenu malgré la présence d’une erreur de contrôle non bloquante ;

·       un code compris entre 01 et 59 selon le tableau ci-dessus en cas d’erreur de grou­page.

 

 


Editeur : ATIH
Dernière mise à jour : 16/01/2004