L’envoi M4, c’est ce moment où on doit renvoyer la consolidation RIHN de l’année précédente. Selon la maturité de votre établissement cela peut être une banalité ou un Everest ! Et si nous avions une façon de vérifier que nous ne sommes pas trop loin de la vérité ?
Pour pouvoir vérifier les RIHN, il faudrait avoir un moyen de recouper les données que nous devons déclarer avec celles de nos producteurs1.
Les producteurs peuvent être :
- Un autre établissement de santé
- Notre propre établissement
- Ou enfin un laboratoire extérieur.
Le recueil PMSI
Dans le PMSI, les producteurs doivent alimenter en M12 de l’année N un FICHSUP listant le volume d’actes RIHN réalisés pour un établissement de santé. Inversement, l’établissement bénéficiaire (qui a prescrit l’acte) doit produire un FICHSUP listant le volume d’actes demandés et payés, et à qui. L’enveloppe MERRI servira à financer une partie de ces dépenses qui peuvent grimper très vite en ce basant sur votre recueil.
Pour s’identifier, les différents acteurs utilisent les FINESS établissement (si bénéficiaire différent de producteur), « INTERNE » si l’établissement est producteur et bénéficiaire, et « LABO99999 » si c’est un laboratoire extérieur.
Hmmm… chaque établissement est donc producteur d’un ou des deux fichiers mais n’a pas à disposition les fichiers déclaratifs des autres établissements… et si… et si… nous avions à notre disposition une copie des fichiers de tous les établissements de santé de France et de Navarre !?!
Entrent en scène les bases nationales
Il se trouve que les bases nationales sont mises à jour avec les données M12 pendant le 1er trimestre de l’année N+1 et les tables en question en font partie. Il existe donc une version nationale de ces envois. Ne pourrions nous pas faire une requête dessus pour en tirer partie ?
Se connecter aux bases nationales
Pour cet article, il faut que vous disposiez d’un accès aux bases nationales (via l’accès sécurisé de l’ATIH). Malheureusement si ce n’est pas votre cas, vous ne pourrez pas pratiquer et devrez vous contenter de lire l’article, mais il n’est jamais trop tard pour faire une demande d’ouverture de compte ! Un monde de données PMSI à retraiter en R s’ouvrira à vous !
Accéder à R sur l’espace sécurisé
L’accès aux bases nationales se fait via https://acces-securise.atih.sante.fr/ et en cliquant à droite sur
Selon votre méthode de connexion, vous devrez saisir votre token ou scanner le QR code avec l’application RSA Authenticator afin d’arriver à l’écran d’accueil où vous trouverez RStudio dans la liste et pourrez le mettre en favori pour les prochaines fois en cliquant sur l’étoile correspondante !
En cliquant sur la vignette, RStudio s’ouvre et il faut vous réauthentifier une nouvelle fois pour ouvrir votre espace de travail.
Configurer a minima l’espace de travail
Attention, il faut impérativement changer la version de R pour l’exécution en sélectionnant une récente dans le menu en haut à droite de la fenêtre2.
Le paquet pRathique
l’ATIH met à disposition un petit package pour simplifier l’accès qui se nomme pRatihque. Nous allons avoir besoin de 2 fonctions qui s’y trouvent :
connection_database(): qui comme son nom l’indique va se connecter sans rien avoir à régler à la base Teradataatihble(): qui est un emballage detbl()pour lier une table distante
Et bien sûr nous aurons besoin de dplyr…
library(dplyr)
library(pRathique)La méthodologie
D’abord, des éléments ci-dessus nous pouvons cerner les limites de l’expérimentation : Nous ne pourrons pas requêter les productions de laboratoire externe (qui ne déposent pas de PMSI) et votre service de comptabilité sera plus à même de donner des chiffres justes pour ce qui concerne la production à visée interne.
Pour notre requête nous allons donc uniquement nous concentrer sur les données produites par d’autres établissements de santé à notre destination.
Dans la table des producteurs, le FINESS du bénéficiaire est stocké dans le champ benef. Dans la table consommateurs, c’est le FINESS qui sert de clé principale est se trouve dans le champ… finess…
Nous pouvons donc déjà initialiser la base de données et restreindre les jeux de données dont nous aurons besoin :
FINESS <- "999999999" # Renseignez ici votre propre finess établissement
conn <- connection_database()
rihn_p <- atihble(conn, "PRD_VUE_MCO_2025.rihn_lc_prod") %>% filter(benef == FINESS)
rihn_c <- atihble(conn, "PRD_VUE_MCO_2025.rihn_lc_conso") %>% filter(finess == FINESS)(Je laisse à votre sagacité, la création d’une version multi-année et/ou multi-finess3)
Nous voici donc maintenant avec des requêtes potentielles, il nous suffit donc de créer la jointure. Pour cela nous allons utiliser un full_join() qui va créer une table unique contenant toutes les lignes des tables de gauche et de droite (avec des NA pour les valeurs inexistantes) avec comme pivots le code RIHN et les FINESS producteurs et bénéficiaires présents dans les 2 tables.
rihn_c %>%
full_join(rihn_p,
by = c("code", "finess" = "benef", "finess_prod" = "finess"))A ce stade, nous sommes toujours en face d’une requête dbplyr prête à être jouée sur le serveur. Pour récupérer les données exhaustives, il faut les collecter avec collect().
<...> %>%
collectNous récupérer alors le résultat complet dans un dataframe et il ne reste ensuite plus qu’à faire le traitement local en R (je vous fais le minimum syndical, à vous de faire d’autres retraitements si besoin).
<...> %>%
mutate(nb.x = coalesce(nb.x,0),
nb.y = coalesce(nb.y,0),
N = nb.x - nb.y) %>%
filter(N!=0)Les coalesce() permettent de remplacer les NA par des valeurs à zéro pour la suite des calculs. Nous calculons ensuite N qui contiendra la différence de volume d’actes RIHN entre les fichiers producteur et bénéficiaire par producteur pour un bénéficiaire donné. Et vu que nous sommes intéressés uniquement par les anomalies, nous supprimons les lignes où cette différence est égale à 0.
Le code total
Pour résumer, voici la totalité du code. 14 lignes en écrivant très très lisible !
# RIHN.R
library(pRatihque)
library(dplyr)
FINESS <- "330780529"
conn <- connection_database()
rihn_p <- atihble(conn, "PRD_VUE_MCO_2025.rihn_lc_prod") %>% filter(benef == FINESS)
rihn_c <- atihble(conn, "PRD_VUE_MCO_2025.rihn_lc_conso") %>% filter(finess == FINESS)
rihn_c %>%
full_join(rihn_p,
by = c("code", "finess" = "benef", "finess_prod" = "finess")) %>%
collect %>%
mutate(nb.x = coalesce(nb.x,0),
nb.y = coalesce(nb.y,0),
N = nb.x - nb.y) %>%
filter(N!=0)
Conclusion
Voici comment en quelques lignes de code nous venons de contrôler la cohérence de notre fichier RIHN bénéficiaire avec les déclarations des producteurs (ceux qui produisent un FICHSUP, pour les autres, il n’y a pas d’autre solution que de leur demander en direct). Il ne vous reste plus qu’à transmettre tout cela à votre DAF pour qu’il explore les différences dans ses factures et vous confirme ou infirme les différents delta par producteur.
On aurait pu pré-traiter les montants qui sont aussi dans le fichier, cependant ceux-ci ne sont renseignés que si les factures sont éditées. On aurait aussi pu croiser avec une table des codes et tarifs RIHN pour vérifier qu’ils sont correctement saisis, vérifier les montants facturés, ou anticiper les montants non facturés à M12. Je vous laisse voir ce que vous voulez explorer ensuite !
A une prochaine fois.
- Dans cet article, nous allons réaliser l’interrogation demandeur. Il suffit d’inverser la requête pour faire l’interrogation producteur. Mais cette dernière est rarement utile vu que pour le producteur, c’est surtout de la facturation. ↩︎
- Pour une raison inconnue, le paquet pRatihque n’est pas disponible sous la version de R la plus ancienne qui est proposée… ↩︎
- Si vous calez, mettez un mot dans les commentaires sous l’article, on verra ce que je peux faire pour vous !😊 ↩︎