--- title: "Valoriser les rsa" author: "Guillaume Pressiat" date: 04/03/2019 output: rmarkdown::html_vignette vignette: > %\VignetteIndexEntry{Valoriser les rsa} %\VignetteEngine{knitr::rmarkdown} \usepackage[utf8]{inputenc} --- ```{r eval = F} library(pmeasyr) library(dplyr, warn.conflicts = F) ``` ## Préparer les tables nécessaires Il faut au moins disposer des rsa et des données anohosp. Pour valoriser les suppléments, les tables porg, pie et diap sont aussi nécessaires. Deux possibilités pour préparer les données rsa et ano afin de calculer la valorisation : les importer spécifiquement, ou les collecter depuis une base de données, voir pour cela éventuellement les fonctions autour des bases de données dans `pmeasyr`. ### Import avec pmeasyr et noyau Ici, on utilise les fonctions `vvr_rsa` et `vvr_ano_mco` pour importer les données depuis les fichiers bruts du *out* et sélectionner les variables dont nous avons besoins. ```{r eval = F} library(pmeasyr) noyau_pmeasyr( finess = '750100042', annee = 2018, mois = 12, path = '~/Documents/data/mco', progress = FALSE, lib = FALSE, tolower_names = TRUE ) -> p adezip(p, type = "out") vrsa <- vvr_rsa(p) vano <- vvr_ano_mco(p) ``` Cela produit deux tables `vrsa` et `vano`. ### Collecte des données depuis une db Autre possibilité donc, le recours à une base de données où les tables préexistent, ici, on les collecte en ne sélectionnant que les variables utiles. ```{r eval = F} library(MonetDBLite) dbdir <- "~/Documents/data/monetdb" con <- src_monetdblite(dbdir) vrsa <- vvr_rsa(con, 18) vano <- vvr_ano_mco(con, 18) ``` Cela produit de manière identique deux tables `vrsa` et `vano`. ## Récupérer les tarifs GHS et suppléments Pour valoriser les séjours, nous avons besoin des tarifs officiels. Comme d'autres tables référentiels classiques du PMSI, on peut trouver ces informations tarifaires pour les établissements ex-DGF dans le package [nomensland](https://github.com/GuillaumePressiat/nomensland). ```{r eval = F} # devtools::install_github('GuillaumePressiat/nomensland') library(nomensland) ``` Il reste possible d'utiliser des tables tarifs et suppléments provenant d'une autre source, mais cela nécessite d'avoir les mêmes noms de colonnes que dans les tables de nomensland. Charger ce package donne accès aux fonctions `get_table` et `get_dictionnaire_tables`. ## Valoriser les rsa **Nous ne tenons pas compte de la rubrique "minoration forfaitaire liste en SUS" volontairement car cela nécessite de maintenir la liste des MO en SUS pour 2016 et 2017**. ### Traitement des RSA transmis hors période (voir tableau RTP) Pour les RSA transmis hors période (année précédente, mois d'après, souvent causés par des dossiers à cheval), on force le groupage en erreur comme epmsi le fait. C'est fait avec la fonction `vvr_rsa_hors_periode` : ```{r eval = F} vrsa <- vrsa %>% vvr_rsa_hors_periode(as.character(p$annee), stringr::str_pad(p$mois, 2, "left", '0')) ``` ### Cas d'une valorisation base + Extrême haut - Extrême bas Ici, on se concentre sur la valorisation dite BEE pour "Base + Extrême haut - Extrême bas". En effet par défaut le paramètre `bee` est à `TRUE` dans l'appel de fonction, et les tables vano, porg et diap sont renseignés à vide. ```{r eval = F} # Importer les tarifs GHS tarifs_ghs <- dplyr::distinct(get_table('tarifs_mco_ghs'), ghs, anseqta, .keep_all = TRUE) resu <- vvr_mco( vvr_ghs_supp(rsa = vrsa, ano = vano, tarifs = tarifs_ghs, cgeo = 1L), vvr_mco_sv(vrsa, vano) ) ``` La table `resu` contient une ligne par rsa avec les variables suivantes : ``` cle_rsa rec_totale rec_base rec_exb rec_exh rec_bee type_fin typvidhosp ``` On peut libeller ces variables en faisant appel à la fonction `vvr_libelles_valo`, voir ci-dessous. ### Cas d'une valorisation base + Extrême haut - Extrême bas + suppléments ```{r eval = F} # Importer les tarifs des suppléments tarifs_supp <- get_table('tarifs_mco_supplements') %>% mutate_if(is.numeric, tidyr::replace_na, 0) %>% select(-cgeo) resu <- vvr_mco( vvr_ghs_supp(rsa = vrsa, tarifs = tarifs_ghs, supplements = tarifs_supp, ano = vano, porg = ipo(p), diap = idiap(p), pie = ipie(p), mo = imed_mco(p), full = FALSE, cgeo = 1L, prudent = NULL, bee = FALSE), vvr_mco_sv(vrsa, vano, ipo(p)) ) ``` La table `resu` contient une ligne par rsa avec les variables suivantes : ``` cle_rsa moissor anseqta rec_totale rec_bee rec_base rec_exb rec_exh rec_rep rec_rea rec_stf rec_src rec_nn1 rec_nn2 rec_nn3 rec_dialhosp rec_caishyp rec_aph rec_ant rec_rap rec_rehosp_ghm rec_rdt_tot rec_sdc rec_po_tot type_fin typvidhosp ``` On peut libeller ces variables en faisant appel à la fonction `vvr_libelles_valo`, voir ci-dessous. ## Générer des tableaux type epmsi pour comparaison avec les valo officielles Les variables présentes dans la table `resu` permettent à la fois de dénombrer les séjours par type de valorisation, c'est-à-dire : ```{r eval = TRUE} knitr::kable(pmeasyr::vvr_libelles_valo('lib_type_sej')) ``` et de reproduire les rubriques de valorisation par type de recette: ```{r eval = TRUE} knitr::kable(pmeasyr::vvr_libelles_valo('lib_valo')) ``` ### Types de vidhosp La table resu contient également une colonne `typvidhosp` qui correspond à un type de séjour, croisant plusieurs modalités (factam, nouveaux-nés, séances, 0 jour, autres, etc.) ```{r eval = TRUE} knitr::kable(pmeasyr::vvr_libelles_valo('lib_vidhosp')) ``` ### Séjours valorisés Les séjours sont distribués et les recettes BR * coeffs sont sommées en fonction du type de séjours (lib_type_sej). ```{r eval = F} epmsi_mco_sv(resu) %>% bind_rows(summarise_if(., is.numeric, sum)) ``` ### Récapitulation activité - valorisation Les séjours sont distribués et les recettes BR * coeffs sont sommées en fonction du type de séjours et du type de recette (lib_type_sej * lib_valo). ```{r eval = F} epmsi_mco_rav(resu) ``` ## Connaître en détail la valorisation des séjours Il est possible de garder toutes les variables intermédiaires du calcul de valorisation, c'est le cas en précisant le paramètre `full = TRUE` : ```{r eval = F} resu <- vvr_mco( vvr_ghs_supp(rsa = vrsa, tarifs = tarifs_ghs, supplements = tarifs_supp, ano = vano, porg = ipo(p), diap = idiap(p), pie = ipie(p), full = TRUE, cgeo = 1L, prudent = NULL, bee = FALSE), vvr_mco_sv(vrsa, vano, ipo(p)) ) ``` Dans ce cas, les variables suivantes deviennent accessibles au niveau de chaque séjour : ```{r eval = F} resu %>% summarise_at(vars(starts_with('rec_')), sum) %>% names() %>% cat(sep = "\n") ``` ``` rec_base rec_exh rec_exb rec_bee rec_totale rec_rep rec_rea rec_stf rec_src rec_nn1 rec_nn2 rec_nn3 rec_hhs rec_edpahs rec_edpcahs rec_ehhs rec_dip rec_dialhosp rec_caishyp rec_aph rec_ant rec_rap rec_sdc rec_rdt5 rec_prot rec_ict rec_cyb rec_gam rec_rcon1 rec_rcon2 rec_tciea rec_tcies rec_aie rec_rcon3 rec_rdt_tot rec_poi rec_poii rec_poiii rec_poiv rec_pov rec_povi rec_povii rec_poviii rec_poix rec_poa rec_po_tot rec_rehosp_ghm rec_pie_src rec_pie_stf rec_pie_rea rec_pie_rep rec_pie_nn1 rec_pie_nn2 rec_pie_nn3 ``` ## Remarques sur le mécanisme de valorisation La valorisation des rsa est assez mécanique (c'est un programme), le détail de ce mécanisme peut-être lu en regardant le code source de `pmeasyr` (bien sûr, ce n'est pas le programme officiel). En peu de mots, la logique est celle-ci : - pour chaque GHS, un tarif de base, des tarifs extrème bas et extrème haut en fonction de la durée de séjour. Cette partie est la plus simple - pour chaque supplément, un tarif de supplément. Cette partie est plus complexe car il y a de nombreux types de suppléments ; et chaque type de supplément a sa propre mécanique Si cette mécanique vaut pour la grande majorité, on note quelques exceptions, d'où les deux adaptations suivantes : - en année séquentielle des tarifs 2017 et 2018, la borne basse du GHS 5907 déclenche une valorisation négative de certains séjours, voir [ici](https://applis.atih.sante.fr/agora/ago_action_theme.do?action=voir_sujet&id_sujet=52026#166276), agora, sujet 52026. Nous tenons compte de cette correction dans la valorisation calculée dans R, ainsi que des monoRUM UHCD de 1 jour considérés par l'ATIH comme l'équivalent de séjours 0 jour dans le calcul du nombre de jours extrème bas. *Cette adaptation nécessite d'intégrer l'information mono RUM UHCD lors de la valorisation, on croise donc avec la table UM, ce qui allonge un peu le temps de traitement*. - Fin 2018 et concernant uniquement l'année séquentielle des tarifs 2018, l'ATIH a introduit un switch de GHS pour les séjours présentant une molécule de Kymriah ou de Yescarta, le GHS devient 8973. La solution était provisoire dans l'attente d'un mode de financement spécifique des séjours carT cells, mais nous avons inclus ce switch de GHS. Autrement dit, le couple GHM/GHS présent dans les RSA pour ces séjours ne correspond pas au couple utilisé sur epmsi pour calculer la valorisation réelle, celle présente dans VVS. *Cette adaptation nécessite d'intégrer les mo/atu lors de la valorisation*.