In IM-APHP/pmeasyr: Donnees PMSI avec R
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.
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.
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.
# 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 :
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.
# 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
# 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 :
knitr::kable(pmeasyr::vvr_libelles_valo('lib_type_sej'))
et de reproduire les rubriques de valorisation par type de recette:
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.)
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).
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).
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 :
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 :
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, 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.
IM-APHP/pmeasyr documentation built on Feb. 19, 2025, 6:17 a.m.
R Package Documentation
Browse R Packages
We want your feedback!
Note that we can't provide technical support on individual packages. You should contact the package authors for that.
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.
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.
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.
# 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 :
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.
# 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
# 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 :
knitr::kable(pmeasyr::vvr_libelles_valo('lib_type_sej'))
et de reproduire les rubriques de valorisation par type de recette:
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.)
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).
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).
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 :
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 :
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, 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.
R Package Documentation
Browse R Packages
We want your feedback!
Note that we can't provide technical support on individual packages. You should contact the package authors for that.
Embedding an R snippet on your website
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.