knitr::opts_chunk$set(
  collapse = TRUE,
  comment = "#>"
)

Documentation package dimRactivite :

Informations utiles sur les objets importés

Clé permettant de lier les différentes tables

La structure des données importées est basée sur le format des fichiers de remontée en entrée et sortie de GENRSA. La variable identifiante des RSA dans GENRSA est la clé de RSA (cle_rsa) qui est un numéro incrémental basé sur le numéro de ligne du RSA dans le fichier de sortie. En conséquence cette clé n'est pas adaptée pour une utilisation pluri-annuelle et avec la mise en commun des données de plusieurs établissements. Dans le package, la clé d'indentification des RSA est composée de l'association des variables anosr, nofiness, cle_rsa . Ces trois variables sont donc présentes dans toutes les tables finales. La fonction inner_join de dplyr peut en outre être utilisée directement sans nommer ces variables spécifiquement.

Détail sur la valorisation des RUM

Valorisation des RSA

La valorisation des RSA est réalisée grâce aux fonctions de valorisation de pmeasyr

Répartition des recettes par UMA

La répartition des recettes par RUM est réalisée par la fonction vvr_rum_repa. Plusieurs clés ont été proposées pour cette répartition. Le package en implémente 4 qui sont disponibles dans l'objet rum_v (les valeur et les coefficients sont disponibles) :

Calcul du PMCT mono RUM

Cet indicateur est calculé à partir des recettes ghs (sans la valorisation des extrêmes ni des suppléments) pour les séjours dont la variable nbrum = 1 sauf pour les réanimations (autorisations PMSI 01A et 01B) où cette restriction n'a pas été faite. Le périmètre du calcul est le suivant :

Précisions sur le calcul des indicateurs présents dans les tableaux de bord

Dédoublonnage des RUM

Pour les séjours multi UMA, il arrive fréquemment qu'un patient passe deux fois dans un même service au cours de son hospitalisation (ex : ORL - REA - ORL). Dans ce cas le parti pris est de ne compter qu'une seule fois le séjour lors de la détermination du nombre de séjours par service (dans l'exemple ci dessus : nombre de séjours en ORL = 1). Les RUM qui sont répétés sont considérés comme doublonnés. Une variable doublon est ajouté aux jeux de données par la fonction get_data, de façon contre intuitive elle est positionnée à 1 lors que le RUM est à comptabiliser et à 0 dans le cas contraire (dans l'exemple ci dessus : ORL doublon = 1, REA doublon = 1, ORL doublon = 0).

Les situations où cette option est à prendre en considération sont renseignées dans les options par la variable gestion_doublons_rum et en référence au fichier structure. Par exemple, dans l'exemple ci dessus, les variables service et pole sont renseignées dans le fichier structure et le fichier d'option comprend la déclaration suivante :

gestion_doublons_rum:
    service: service
    pole: service

Pour le niveau service, les RUM sont dédoublonnés par service, et de la même façon pour le niveau pole ils également dédoublonnés par service.

Calcul des index de performance et durées de séjours de référence dans la base nationale

L'index de performance de la durée moyenne de séjour (IP DMS) est calculé avec les DMS de référence de la base nationale PMSI de l'année précédente (en fonction de la date de mise à disposition par l'ATIH) selon la méthode mise au point la siège de l'APHP et présentée au congrès EMOIS 2014 (Le-Leplat 2014).

Tableau de bord détail évolution recettes

La procédure permet la production d'un tableau synthétique sur l'ensemble du groupe hospitalier visant à explorer les écarts de recettes :

Pour dont les séjours durée >= 2 jours et < DMS+30 on essaye de décomposer la différentiel de recettes N vs N-1 en sous-parties :

Références

Le-Leplat 2014 - C. Lê-Leplat, F. Guilmineau, N. Taright Un nouveau regard sur l’IP DMS : son calcul, son interprétation - Congrès EMOIS 2014. Doi : 10.1016/j.respe.2014.01.046



24p11/dimRactivite documentation built on March 10, 2021, 8:27 p.m.