---
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*.

