alt-R native

pmsi-io 0.4.1 et Transcoder 0.2.0

Sun, 12 Jul 2026 14:05:05 +0000

Je partage ici deux travaux réalisés ces dernières semaines : une mise à jour de pmsi-io, l’application bureau de traitement des données PMSI MCO, et une nouveauté en application de bureau et WebAssembly, Transcoder, port natif de l’application Shiny de transcodage de listes de codes.

pmsi-io 0.4.1

pmsi-io est une application bureau pour le traitement des données PMSI MCO (RSA, RSS, fichiers ATIH). Elle tourne entièrement en local.

0.4.0 : refonte majeure

La 0.4.0 représente une extension significative sur deux axes.

Deux nouveaux onglets :

Requêtes : sélection et exécution de requêtes PMSI pré-établies par thématique
Requête Lab’ : constructeur de requêtes personnalisées (GHM, diagnostics, actes, âge, poids, durée), sauvegarde, export JSON, partage entre utilisateurs

Robustesse Rust :

Type d’erreur unifié PmsiError via thiserror : les erreurs remontent proprement jusqu’au frontend
Migration Tauri v1 → v2, migration Svelte 4 → Svelte 5 (runes)

0.4.1 : Explorateur de données

Le gros ajout de cette version : un onglet Explorer pour analyser visuellement les résultats de requêtes RSA sans export disque.

Pivot table : sélection des axes lignes/colonnes, agrégations (count, somme, moyenne, min, max), tri alphabétique ou par effectif
6 types de graphiques interactifs via ECharts : barres, courbes, camembert, heatmap, river, pyramide des âges
Calcul pivot entièrement côté Rust/Polars (group_by + agrégation sur LazyFrame) : aucune écriture sur disque
Tutoriel : pastilles numérotées ① à ⑥ guidant les nouveaux utilisateurs, désactivables
Switcher de thème clair/sombre persisté
Frontend : SvelteKit 2 + Svelte 5
Backend : Rust + Polars
environnement de développement : Tauri 2

Transcoder 0.2.0

Transcoder est le port natif de la Shiny app stringfix/transcoder, un outil du quotidien en info médicale pour reformater des listes de codes (CIM-10, CCAM, FINESS, identifiants patients) entre différents formats : liste vecteurs quotés, clause SQL %LIKE%, pipe pour les regexp.

Application bureau (Tauri)

La version 0.2.0 apporte par rapport à la Shiny originale :

Thème clair / sombre avec persistance
Historique des 50 dernières transformations (dédoublonné, non persistant, comme les listes peuvent contenir des données patients)
Copie automatique dans le presse-papier à chaque transformation
Raccourcis clavier : Ctrl+Entrée, Ctrl+1/2/3, Ctrl+H, Ctrl+L

Version web (WASM)

La logique de transcodage Rust est compilée en WebAssembly via wasm-pack et tourne directement dans le navigateur : sans serveur, sans installation, sans données envoyées à l’extérieur.

guillaumepressiat.github.io/transcoder

Le résultat est une page statique hébergée sur GitHub Pages. Le code source de la version web est dans la branche wasm.

Logique : Rust → WASM (wasm-pack)
Frontend : SvelteKit 2 + Svelte 5
Deploy : GitHub Pages (Actions)

Installer les applications

Les versions en application de bureau, pour mac (dmg, arm, intel ou universal), windows (exe ou msi) et linux (rpm, deb ou appimage) sont disponibles aux pages suivantes :

pmsi-io · transcoder

Les deux applications tournent entièrement en local, souhaitable dans un environnement hospitalier.

Code source : github.com/GuillaumePressiat

logrittr: A Verbose Pipe Operator for Logging dplyr Pipelines

Wed, 29 Apr 2026 08:05:55 +0000

dplyr verbs are descriptive: let’s make them more verbose!

Yet another pipe for R.

Repost for better image handling on r-bloggers.

Motivation

In SAS, every DATA step prints a log:

NOTE: There were 120000 observations read from WORK.SALES.
NOTE: 7153 observations were deleted.
NOTE: The data set WORK.RESULT has 112847 observations and 11 variables.

R’s dplyr pipelines are silent. logrittr fills that gap with %>=%, a drop-in pipe that logs row counts, column counts, added/dropped columns, and timing at every step, with no function masking.

With Fira Code ligatures, %>=% renders as a single wide arrow visually similar to %>% with an underline added, like a subtitle or, say, to read between the lines of a pipeline (what happened).

Multiples contexts

Things happens:

NOTE: There were 120000 observations read from WORK.SALES.
NOTE: 120000 observations were deleted.
NOTE: The data set WORK.RESULT has 0 observations and 11 variables.

“It’s here we’ve lost all rows in script execution”.

Pro

Reading this a long time after execution of a script helps you see:

what happened at each stage of data processing without having to rerun the code, for example in a production environment where the input data is constantly changing
monitor key processes
Make sure you can explain what happened (an audit, for example)

In professional contexts it’s often needed.

Educational

This will also be clearer thanks to a console log for those with little experience with the tidyverse: people who are taking their first steps in programming by following a tutorial or teaching themselves.

Installation

install.packages('logrittr', repos = 'https://guillaumepressiat.r-universe.dev')

# or from github
# devtools::install_github("GuillaumePressiat/logrittr")

See github or r-universe.

Usage

library(logrittr)
library(dplyr)

iris %>=%
  as_tibble() %>=%
  filter(Sepal.Length < 5)  %>=%
  mutate(rn = row_number()) %>=%
  semi_join(
    iris %>% as_tibble() %>=%
      filter(Species == "setosa"),
    by = "Species"
  )  %>=%
  group_by(Species) %>=%
  summarise(n = n_distinct(rn))

── iris  [rows:       150  cols:    5] ─────────────────────────────────────────────────────
ℹ as_tibble()                            rows:       150 +0        cols:    5 +0    [   0.0 ms]
ℹ filter(Sepal.Length < 5)               rows:        22 -128      cols:    5 +0    [   3.0 ms]
ℹ mutate(rn = row_number())              rows:        22 +0        cols:    6 +1    [   1.0 ms]
  added: rn
ℹ > filter(Species == "setosa")          rows:        50 -100      cols:    5 +0    [   1.0 ms]
ℹ semi_join(iris %>% as_tibble() %>=%    rows:        20 -2        cols:    6 +0    [   5.0 ms]
  filter(Species == "setosa"), by =
  "Species")
ℹ group_by(Species)                      rows:        20 +0        cols:    6 +0    [   3.0 ms]
ℹ summarise(n = n_distinct(rn))          rows:         1 -19       cols:    2 -4    [   2.0 ms]
  dropped: Sepal.Length, Sepal.Width, Petal.Length, Petal.Width, rn
  added: n

Screenshot

library(dplyr)
library(logrittr)

logrittr_options(lang = "en", big_mark = ",", wrap_width = NULL, max_cols = 3)

nycflights13::flights %>=% 
  as_tibble() %>=%
  group_by(year, month, day) %>=% 
  count() %>=% 
  tidyr::pivot_wider(values_from = "n", names_from = "day") %>=% 
  glimpse()

Related package: `tidylog`

tidylog is a really neat package that gives me motivation for this one. tidylog works by masking dplyr functions, which doesn’t seem ideal to me.

Anyway this also was a moment for me to test a new programmer tool that is used a lot for programming at this time.

logrittr uses a custom pipe operator and never touches the dplyr namespace. Its console output is colorful and informative thanks to the cli package.

Working with `lumberjack`

If you already know the lumberjack package, compatibility is available with logrittr (timings are approximates).

Calling logrittr_logger$new():

library(lumberjack)
library(dplyr)

l <- logrittr_logger$new(verbose = TRUE)
logfile <- tempfile(fileext=".-r.log.csv")

iris %L>%
   start_log(log = l, label = "iris step") %L>%
   as_tibble() %L>%
   filter(Sepal.Length < 5) %L>%
   mutate(rn = row_number()) %L>%
   group_by(Species) %L>%
   summarise(n = n_distinct(rn)) %L>%
   dump_log(file=logfile, stop = FALSE)
   

mtcars %>% 
  start_log(log = l, label = "mtcars step") %L>%
   count() %L>%
   dump_log(file=logfile, stop = TRUE)


logdata <- read.csv(logfile)

Will write logrittr log content of multiple data steps in the same csv file.

Limitations

Like tidylog, logrittr only works with dplyr pipelines on R data.frames (in memory) and is not able to do so with dbplyr pipelines from databases (remote/lazy table).
Join cardinalities nicely done in tidylog are difficult to have from the pipe as join is already done, at this time we only show N row and N col evolution (before / after).
Yes it’s another pipe, not ideal. We can dream of a with_logging(TRUE) context that will activate behaviour of logrittr pipe in |> or in %>%.

Take another pipe for a spin

logrittr prioritizes the user experience with a structured and colorful display in the console.

For now, this package is just a proof of concept that gave me a chance to experiment a bit with the cli package and few other things. But I think there’s a need for that in R, in a specific area where SAS outputs are so informative.

Fun pictures with ggplot2 and scico packages

Sat, 18 Apr 2026 09:05:05 +0000

This wonderful post from Jonathan Carroll give me idea to play with ggplot2 code and scico color palettes:

Also see this toot from Stefan Siegert, inspiring!

I took the code from the toot mentioned above, modified it, and used it to have a little fun creating graphics that look like paintings with imperfections around the edges, among other things.

All in all, I think it’s a good way to test color palettes.

When you get higher dot per inch images, it can be really cool.

# https://mastodon.social/@safest_integer/114296256313964335
library(tidyverse)
crossing(x=0:10, y=x) |>
  mutate(dx = rnorm(n(), 0, (y/20)^1.5),
         dy = rnorm(n(), 0, (y/20)^1.5)) |>
ggplot() +
geom_tile(aes(x=x+dx, y=y+dy, fill=y), colour='black',
          lwd=2, width=1, height=1, alpha=0.8, show.legend=FALSE) +
scale_fill_gradient(high='#9f025e', low='#f9c929') +
scale_y_reverse() + theme_void()

library(tidyverse)

crossing(x=8:300, y=x[1:100]) |>
  mutate(dx = rnorm(n(), 0, (y/200)^1.5),
         dy = rnorm(n(), 0, (y/100)^1.5)) |>
  ggplot() +
  geom_tile(aes(x=x+dx, y=y+dy, fill=y), colour=NA,
            lwd=4, width=8, height=4, alpha=0.1, 
            show.legend=FALSE) +
  scale_fill_gradient(high='#9f025e', low='#f9c929') +
  scale_y_reverse() + theme_void() + 
  coord_fixed()

Here is the “Oleron” color palette from scico. What a beautiful palette for those who know this french island!

library(tidyverse)

crossing(x=8:300, y=x[1:100]) |>
  mutate(dx = rnorm(n(), 0, (y/200)^1.5),
         dy = rnorm(n(), 0, (y/100)^1.5)) |>
  ggplot() +
  geom_tile(aes(x=x+dx, y=y+dy, fill=y), colour=NA,
            lwd=4, width=8, height=4, alpha=0.1, 
            show.legend=FALSE) +
  scico::scale_fill_scico(palette = "oleron", 
  direction = 1) +
  scale_y_reverse() + theme_void() + 
  coord_fixed()

Now drawing waves, view at the top of the dune:

crossing(x=8:300, y=x[1:100]) |>
  mutate(dx = rnorm(n(), 0, (y/200)^1.5),
         dy = ifelse(y < 52, 
                     rnorm(n(), 0, (y/100)^1.5)+ 
                       ifelse(x %% 2 == 0, 
                              cos(x * 3 + y / 5)*4 +
                                sin(x * 3 + y / 2)*2, 0) / 1.7,
                     rnorm(n(), 0, (y/100)^1.5))) |>
  ggplot() +
  geom_tile(aes(x=x+dx, y=y+dy, fill=y), colour=NA,
            lwd=4, width=8, height=4, alpha=0.2, 
            show.legend=FALSE) +
  scico::scale_fill_scico(palette = "oleron", #begin = 0.6,
                          direction = 1) +
  scale_y_reverse() + theme_void() + 
  coord_fixed()

The green might be vegetation from the dunes, or maybe seaweed. The blue might also be sky and wind, blue hour, there is definitely sand.

Back to bigger rectangles with a cyclic scico palette: romaO.

crossing(x=1:280, y=x) |>
  mutate(dx = rnorm(n(), 0, (x/40)^1.5),
         dy = rnorm(n(), 0, (y/40)^1.5)) |>
  ggplot() +
  geom_tile(aes(x=x+dx, y=y-dy*3, fill=y), colour='white',
            lwd=0.03, width=13, height=6, alpha=0.4, 
            show.legend=FALSE) +
  scico::scale_fill_scico(palette = "romaO", #begin = 0.6,
                          direction = 1) +
  scale_y_reverse() + theme_void() + 
  theme(panel.background = element_rect(fill = "#2b2828")) +
  coord_fixed()

Now just play with a bit more magic: coord_polar

crossing(x=1:280, y=x) |>
  mutate(dx = rnorm(n(), 0, (x/40)^1.5),
         dy = rnorm(n(), 0, (y/40)^1.5)) |>
  ggplot() +
  geom_tile(aes(x=x+dx, y=y-dy*3, fill=y), colour='white',
            lwd=0.03, width=13, height=6, alpha=0.4, 
            show.legend=FALSE) +
  scico::scale_fill_scico(palette = "romaO", #begin = 0.6,
  direction = 1) +
  scale_y_reverse() + theme_void() + 
  theme(panel.background = element_rect(fill = "#2b2828")) +
  coord_polar()

Another one with vikO palette:

crossing(x=8:70, y=x[1:30]) |>
  mutate(dx = rnorm(n(), 0, (y/20)^1.5),
         dy = rnorm(n(), 0, (y/10)^1.5)+ ifelse(x %%2 == 0, cos(x * 3 + y / 5)*10, 0)) |>
  ggplot() +
  geom_tile(aes(x=x+dx, y=y+dy, fill=y), colour='grey70',
            lwd=0.1, width=8, height=4, alpha=0.6,
            show.legend=FALSE) +
  scico::scale_fill_scico(palette = "vikO", #begin = 0.6,
                          direction = -1) +
  scale_y_reverse() +
  theme_void() +
  theme(panel.background = element_rect(fill = "#2b2828")) +
  coord_polar(theta = "x")

Finally back to Oleron palette with coord_polar:

crossing(x=8:70, y=x[1:30]) |>
  mutate(dx = rnorm(n(), 0, (y/20)^1.5),
         dy = rnorm(n(), 0, (y/10)^1.5)+ ifelse(x %%2 == 0, cos(x * 3 + y / 5)*10, 0)) |>
  ggplot() +
  geom_tile(aes(x=x+dx, y=y+dy, fill=y), colour=NA,
            lwd=1, width=8, height=4, alpha=0.4,
            show.legend=FALSE) +
  scico::scale_fill_scico(palette = "oleron", #begin = 0.6,
                          direction = 1) +
  scale_y_reverse() +
  theme_void() +
  theme(panel.background = element_rect(fill = "grey5")) + ##2b2828
  coord_polar(theta = "x")

Kind of like Earth, but not from the Moon. Just from R.

bukavu palette:

crossing(x=8:70, y=x[1:30]) |>
  mutate(dx = rnorm(n(), 0, (y/20)^1.5),
         dy = rnorm(n(), 0, (y/10)^1.5)+ ifelse(x %%2 == 0, cos(x * 3 + y / 5)*10, 0)) |>
  ggplot() +
  geom_tile(aes(x=x+dx, y=y+dy, fill=y), colour='grey5',
            lwd=0.2, width=8, height=4, alpha=0.4,
            show.legend=FALSE) +
  scico::scale_fill_scico(palette = "bukavu", #begin = 0.6,
                          direction = 1) +
  scale_y_reverse() +
  theme_void() +
  theme(panel.background = element_rect(fill = "#2b2828")) +
  coord_polar(theta = "x")

Many thanks to:

Thomas Lin Pedersen for this package: thomasp85/scico and Fabio Crameri for the palettes.
Stefan Siegert
Jonathan Carroll
ggplot2 author and maintainers.

logrittr: A Verbose Pipe Operator for Logging dplyr Pipelines

Wed, 15 Apr 2026 09:10:05 +0000

dplyr verbs are descriptive: let’s make them more verbose!

Yet another pipe for R.

Motivation

In SAS, every DATA step prints a log:

NOTE: There were 120000 observations read from WORK.SALES.
NOTE: 7153 observations were deleted.
NOTE: The data set WORK.RESULT has 112847 observations and 11 variables.

With Fira Code ligatures, %>=% renders as a single wide arrow visually similar to %>% with an underline added, like a subtitle or, say, to read between the lines of a pipeline (what happened).

Multiples contexts

Things happens:

NOTE: There were 120000 observations read from WORK.SALES.
NOTE: 120000 observations were deleted.
NOTE: The data set WORK.RESULT has 0 observations and 11 variables.

“It’s here we’ve lost all rows in script execution”.

Pro

Reading this a long time after execution of a script helps you see:

what happened at each stage of data processing without having to rerun the code, for example in a production environment where the input data is constantly changing
monitor key processes
Make sure you can explain what happened (an audit, for example)

In professional contexts it’s often needed.

Educational

Installation

install.packages('logrittr', repos = 'https://guillaumepressiat.r-universe.dev')

# or from github
# devtools::install_github("GuillaumePressiat/logrittr")

See github or r-universe.

Usage

library(logrittr)
library(dplyr)

iris %>=%
  as_tibble() %>=%
  filter(Sepal.Length < 5)  %>=%
  mutate(rn = row_number()) %>=%
  semi_join(
    iris %>% as_tibble() %>=%
      filter(Species == "setosa"),
    by = "Species"
  )  %>=%
  group_by(Species) %>=%
  summarise(n = n_distinct(rn))

── iris  [rows:       150  cols:    5] ─────────────────────────────────────────────────────
ℹ as_tibble()                            rows:       150 +0        cols:    5 +0    [   0.0 ms]
ℹ filter(Sepal.Length < 5)               rows:        22 -128      cols:    5 +0    [   3.0 ms]
ℹ mutate(rn = row_number())              rows:        22 +0        cols:    6 +1    [   1.0 ms]
  added: rn
ℹ > filter(Species == "setosa")          rows:        50 -100      cols:    5 +0    [   1.0 ms]
ℹ semi_join(iris %>% as_tibble() %>=%    rows:        20 -2        cols:    6 +0    [   5.0 ms]
  filter(Species == "setosa"), by =
  "Species")
ℹ group_by(Species)                      rows:        20 +0        cols:    6 +0    [   3.0 ms]
ℹ summarise(n = n_distinct(rn))          rows:         1 -19       cols:    2 -4    [   2.0 ms]
  dropped: Sepal.Length, Sepal.Width, Petal.Length, Petal.Width, rn
  added: n

Screenshot

library(dplyr)
library(logrittr)

logrittr_options(lang = "en", big_mark = ",", wrap_width = NULL, max_cols = 3)

nycflights13::flights %>=% 
  as_tibble() %>=%
  group_by(year, month, day) %>=% 
  count() %>=% 
  tidyr::pivot_wider(values_from = "n", names_from = "day") %>=% 
  glimpse()

Related package: `tidylog`

tidylog is a really neat package that gives me motivation for this one. tidylog works by masking dplyr functions, which doesn’t seem ideal to me.

Anyway this also was a moment for me to test a new programmer tool that is used a lot for programming at this time.

logrittr uses a custom pipe operator and never touches the dplyr namespace. Its console output is colorful and informative thanks to the cli package.

Working with `lumberjack`

If you already know the lumberjack package, compatibility is available with logrittr (timings are approximates).

Calling logrittr_logger$new():

library(lumberjack)
library(dplyr)

l <- logrittr_logger$new(verbose = TRUE)
logfile <- tempfile(fileext=".-r.log.csv")

iris %L>%
   start_log(log = l, label = "iris step") %L>%
   as_tibble() %L>%
   filter(Sepal.Length < 5) %L>%
   mutate(rn = row_number()) %L>%
   group_by(Species) %L>%
   summarise(n = n_distinct(rn)) %L>%
   dump_log(file=logfile, stop = FALSE)
   

mtcars %>% 
  start_log(log = l, label = "mtcars step") %L>%
   count() %L>%
   dump_log(file=logfile, stop = TRUE)


logdata <- read.csv(logfile)

Will write logrittr log content of multiple data steps in the same csv file.

Limitations

Like tidylog, logrittr only works with dplyr pipelines on R data.frames (in memory) and is not able to do so with dbplyr pipelines from databases (remote/lazy table).
Join cardinalities nicely done in tidylog are difficult to have from the pipe as join is already done, at this time we only show N row and N col evolution (before / after).
Yes it’s another pipe, not ideal. We can dream of a with_logging(TRUE) context that will activate behaviour of logrittr pipe in |> or in %>%.

Take another pipe for a spin

logrittr prioritizes the user experience with a structured and colorful display in the console.

dplyr and Oracle database with DatabaseConnector and JDBC on Windows

Tue, 02 Dec 2025 08:05:50 +0000

In a rather old post on this blog, I wrote about an Oracle database connection from R on Windows with ODBC when you have old Oracle clients (32 bit version) installed in an enterprise setup.

It’s still working on R 32 bit. But now R new releases are only delivered in 64 bit version. Hard to stay with a R 4.1 (last 32bit) when we are now at R 4.5…

In such a situation, are there any alternatives?

An alternative with JDBC

Java to the rescue?

With JDBC clients and jar files, DBeaver is able to connect to all types of databases, so R should also be able to do so, both in 32b or 64b and on the most recent versions only with JDBC drivers?

Yes, it works too, see OHDSI’s DatabaseConnector package.

I am posting an example of use here.

Sys.setenv("DATABASECONNECTOR_JAR_FOLDER" = "~/drivers_dbeaver/oracle")

library(DatabaseConnector)
library(dplyr)
library(dbplyr)

conn <- connect(
  createConnectionDetails(
    dbms="oracle", 
    connectionString = "jdbc:oracle:thin:@db-server.fr:1521/APPNAME",
    user = "resu",
    password = "drowssap"
  )
)

# SQL
querySql(conn,"SELECT COUNT(*) FROM appname.table_a")
# dplyr / dbplyr
tbl(conn, in_schema('APPNAME', 'TABLE_A')) %>% count()

disconnect(conn)

This package seems very interesting and is not limited to Windows and Oracle support, see here for more informations: https://github.com/OHDSI/DatabaseConnector/

Mise à jour des outils pour s'adapter aux sorties de Druides

Sun, 19 Oct 2025 15:00:00 +0000

Utiliser les outils sur les données en sortie de Druides de manière transparente

Le package pmeasyr, pypmsi, pmsi-io permettent d’intégrer les données 2025 M01 et M12, et fonctionnent encore sur les données passées de manière fluide. Pour profiter de cela, il faut les mettre à jour.

pmeasyr

https://github.com/GuillaumePressiat/pmeasyr

Version 0.5.0

Au plus simple :

install.packages('pmeasyr', repos = 'https://guillaumepressiat.r-universe.dev')

En attendant la prochaine mise à jour liée à l’actualité 2026 qui ne se fait pas attendre, et où il faudra de nouveau faire la mise à jour.

pypmsi

https://github.com/GuillaumePressiat/pypmsi

Version 0.3.0

pip install https://github.com/GuillaumePressiat/pypmsi/releases/latest/download/pypmsi-0.2.8-py3-none-any.whl

Astuce :

Télécharger automatiquement la dernière roue python (latest github release, wheel artifact) :

pip install "git+https://github.com/GuillaumePressiat/pypmsi@$(curl -s https://api.github.com/repos/GuillaumePressiat/pypmsi/releases/latest | jq -r ".tag_name")"

pmsi-io / pmsi-clio

voir sur cette page.

https://github.com/GuillaumePressiat/pmsi-io

Version 0.2.0

pmsi-io

Cette version embarque quelques améliorations (sauvegarde des paramètres d’une session à une autre).

pmsi-clio

Mise à jour de pmsi-io et information concernant le nommage des fichiers par Druides

Sun, 28 Sep 2025 13:05:50 +0000

Utiliser les outils sur les données M01 à M12 2025, en attendant 2026.

Le package pmeasyr, pypmsi, pmsi-io permettent d’intégrer les données 2025 M01 à M12, il faut pour cela les mettre à jour.

pmsi-io / pmsi-clio

voir sur cette page.

https://github.com/GuillaumePressiat/pmsi-io

Version 0.1.10

pmsi-io

pmsi-clio

Modifications à venir / nommage des fichiers PMSI avec Druides

Des modifications assez importantes suivront d’ici la fin de l’année dans les trois outils (pmeasyr, pypmsi, pmsi-io/pmsi-clio).

En effet, la charte de nommage des fichiers PMSI évolue légèrement avec Druides sur les 4 champs (fichiers texte, archives zip) et nécessite désormais de fastidieuses actions manuelles pour continuer à utiliser les programmes habituels de lecture des données (avec pmeasyr notamment).

En détail,

pour les fichiers de données, ces changements vont de l’extension même des fichiers au formattage du mois sur 1 ou 2 caractères (01, 02, 09, etc. ou 1, 2, 9, etc.).
pour les archives, le nom des archives zip contient désormais le nom du champ PMSI, hormis pour le MCO jusqu’à M07 2025 qui jusque-là gardait le nommage des in/out historique.

L’idée est d’attendre que tous ces changements se sédimentent avant d’acter une stratégie définitive et homogène pour les différents outils.

Mise à jour des outils, février en attendant... 2025, M01 & M02

Sun, 23 Feb 2025 13:05:50 +0000

Utiliser les outils sur les données M01 et M02 2025, en attendant M03.

Le package pmeasyr, pypmsi, pmsi-io permettent d’intégrer les données 2025 M01 et M02, il faut pour cela les mettre à jour.

pmeasyr

https://github.com/GuillaumePressiat/pmeasyr

Version 0.4.1

Au plus simple :

install.packages('pmeasyr', repos = 'https://guillaumepressiat.r-universe.dev')

En attendant la prochaine mise à jour liée à l’envoi M03 où il faudra de nouveau faire la mise à jour.

pypmsi

https://github.com/GuillaumePressiat/pypmsi

Version 0.2.8

pip install https://github.com/GuillaumePressiat/pypmsi/releases/latest/download/pypmsi-0.2.8-py3-none-any.whl

Astuce :

Télécharger automatiquement la dernière roue python (latest github release, wheel artifact) :

pip install "git+https://github.com/GuillaumePressiat/pypmsi@$(curl -s https://api.github.com/repos/GuillaumePressiat/pypmsi/releases/latest | jq -r ".tag_name")"

pmsi-io / pmsi-clio

voir sur cette page.

https://github.com/GuillaumePressiat/pmsi-io

Version 0.1.8

pmsi-io

pmsi-clio

Retour sur les communications réalisées en 2024

Sun, 23 Feb 2025 10:00:00 +0000

L’année 2024 étant achevée, il est peut-être temps de faire le bilan des présentations et de l’atelier que j’ai eu l’occasion de faire cette année.

La dernière, communication lors d’un « meetup du Health Data Hub » #22, est disponible en ligne.

Point de départ, fin 2023, le comité scientifique du congrès EMOIS m’a proposé de réaliser un poster et d’animer un atelier sur la manipulation de données PMSI avec R dans le cadre du congrès EMOIS 2024 à Lille.

C’était l’occasion de mettre en valeur les travaux, et cela a fait boule de neige puisque j’ai finalement fait 4 déplacements.

Cela a permis de parler des travaux réalisés autour de R, Python et Rust sur le PMSI en y ajoutant certains messages :

à l’échelle des établissements : le lien fort qui existe entre information médicale et données de santé (autrement dit DIM + EDS)
à l’échelle nationale : mettre en avant l’importance de considérer les données comme des « obtenues », des informations qui viennent du « terrain », et donc l’intérêt qu’il y a à considérer tous les acteurs et toutes les expertises autour de la donnée de santé à différentes échelles du territoire (agences nationales et établissements de santé). Ce point avait déjà été abordé dans un précédent billet de ce blog.

Voici le lien vers les supports des communications :

présentation à la rencontre des EDS du Grand Ouest organisée cette année par le CHU de Brest, à Saint Jacut de la Mer, le 26/03/2024
Poster et atelier au congrès d’information médicale EMOIS 2024 à Lille le 05/04/2024
Communication à la journée de l’association d’information médicale bretonne ABIMES à Quimper le 11/10/2024
Communication au « meetup #22 SNDS / HDH » le 07/11/2024, dont voici la présentation en pdf mais elle a aussi été enregistrée en vidéo.. (le meetup était retransmis en direct en streaming)

Lire des fichiers H'XML / HPRIM-XML avec python/pola.rs ou R

Sat, 21 Sep 2024 10:00:00 +0000

Comment lire facilement des fichiers H’XML avec Python ou R ? Plusieurs solutions abordées dans ce billet.

Introduction

De quoi parle-t-on ?

Dans les hôpitaux, il y a de nombreux logiciels qui s’organisent autour du soin, on parle de système d’information hospitalier (SIH). Une caractéristique importante de ce système, c’est la nécessité que les logiciels communiquent des informations en cohérence les uns avec les autres.

Par exemple :

les données identifiant les patients : nom, prénoms, date de naissance, etc.
leur localisation : où et par qui sont pris en charge les patients à un instant T, où seront-ils à T+1 ?
pour le reste, en résumé : toutes les informations relatives à leur prise en charge (médicaments, examens, analyses, diagnostics, actes médicaux, chirurgicaux, etc.)

Les enjeux sont importants et on parle d’interopérabilité, de logique évenementielle, d’atomicité de l’information. Bref, tout cela rentre dans un cadre plus large que l’on appelle l’urbanisation d’un système d’information.

Afin que ces échanges entre logiciels se passent le mieux possible, des normes, standards et recommandations ont été mis en place au niveau international (il y a un jargon, on citera HL7¹, IHE²) mais également au niveau national avec HPRIM³ car certaines données sont propres au cadre réglementaire français, notamment les spécificités du PMSI⁴.

En termes de format informatique, les données peuvent prendre la forme de fichiers texte où l’information est séparée par des barres verticales, de fichiers json mais aussi, souvent, de fichiers XML.

C’est ce dernier point qui est abordé dans ce billet avec le cas des fichiers HPRIM-XML. Les objectifs de ce standard tiennent dans les deux axes suivants, originellement en lien avec la FIDES Séjours⁵ :

Remontée des informations d’activité vers le DIM (exhaustivité, qualité et validation des informations médicales)
Alimentation du processus de facturation individuelle des séjours (exhaustivité, qualité et validation des informations de facturation)

Contexte

Imaginons que l’on se trouve entre deux logiciels qui échangent ce type d’informations (des informations typiquement du domaine de l’information médicale). On a besoin d’en interroger le contenu (et bien sûr, on a l’autorisation). Comment faire sans être un expert XSL⁶, ni spécialiste interopérabilité⁷ ?

Pour donner un aperçu, l’entête de ces fichiers XML ressemble à ceci :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<evenementsServeurEtatsPatient acquittementAttendu="non" version="2.00" xmlns="http://www.hprim.org/hprimXML">
	<enteteMessage>
		<identifiantMessage>00001_esep</identifiantMessage>
		<dateHeureProduction>2024-01-01T01:01:01</dateHeureProduction>
		<emetteur>
			<agents>
				<agent categorie="application">
					<code>TEST</code>
				</agent>
			</agents>
		</emetteur>
<etc.../>

Des fichiers d’exemples sont aussi disponibles :

https://github.com/GuillaumePressiat/pyhprimxml/tree/main/data/xml_tests

Nous présentons dans ce billet plusieurs options pour lire les données de fichiers HPRIM-XML par l’exemple.

Utiliser xpath pour aller vite

Finalement, le problème peut être résumé à la lecture de fichiers XML, ces fichiers sont des fichiers où l’information est hiérarchisée, relationnelle.

Comme pour scraper le contenu d’une page web, on peut utiliser XPath⁸ pour se “balader” dans les informations d’un fichier XML. Le principe de XPath est le suivant : si on connait le chemin, on peut accéder à l’information.

Voici deux implémentations très basiques pour le faire avec Python et R.

Avec python

Avec python ici, une solution parmi d’autres :

https://guillaumepressiat.github.io/pyhprimxml/xpath_xml.html

Avec R

Le même exemple (très court) avec R ici :

https://guillaumepressiat.github.io/pyhprimxml/xpath_xml_r.html

Package pyhprimxml

Avec les deux solutions simplistes ci-dessus, on a l’information mais on perd la dimension hiérarchique des fichiers XML, donc on perd de l’information en la simplifiant.

Le package pyhprimxml permet de convertir l’information d’un fichier HPRIM-XML en un DataFrame pola.rs : on peut ensuite se reposer sur la syntaxe de pola.rs pour extraire les informations.

Bibliothèques utilisées

lxml : pour enlever le namespace xmlns avec un script xslt
xmltodict : pour convertir le xml en dict python
json : pour encapsuler le dict en json pour la lecture avec pl.read_json
polars : pour les étapes de déstructuration de la donnée hiérarchique issue des XML
io, os, glob : pour les étapes de manipulations de fichiers dans le système

https://github.com/GuillaumePressiat/pyhprimxml

Une présentation de ce package est faite ici :

https://guillaumepressiat.github.io/pyhprimxml/

La voici embarquée dans cette page :

Pour en savoir plus, le repo github est ici :

https://github.com/GuillaumePressiat/pyhprimxml

HL7 ↩
IHE ↩
HPRIM : Harmoniser et PRomouvoir l’Informatique Médicale, initialement développé pour les laboratoires d’analyse médicale pour lesquels l’enjeu d’un échange de données efficient est rapidement apparu comme crucial ↩
PMSI : Programme de médicalisation des systèmes d’information ↩
FIDES Séjours : facturation individuelle des établissements de santé, voir doc simphonie dgos ↩
https://fr.wikipedia.org/wiki/Extensible_stylesheet_language ↩
interopérabilité : Capacité de matériels, de logiciels ou de protocoles différents à fonctionner ensemble et à partager des informations ↩
https://fr.wikipedia.org/wiki/XPath est un langage de requête pour localiser une portion d’un document XML très lié au départ aux spécifications XSL. ↩

Découverte de delta lake avec pola.rs et pypmsi

Sat, 21 Sep 2024 09:00:00 +0000

Take delta lake for a spin

Introduction

L’an dernier lors de la montée en charge de pola.rs, j’ai voulu tester l’écriture de fichiers parquet avec pola.rs sous le framework delta lake.

Delta Lake est un framework open source qui permet d’ajouter une couche ACID¹ au stockage de données type lakehouse, c’est-à-dire que quand on souhaite mettre à jour, supprimer, ajouter des données, l’ensemble des opérations sont historisées. De cette manière il est sécurisant d’opérer des actions d’administration sur les données.

Dans cet article, je pointe vers le code que j’ai écrit pour intégrer les données PMSI rsa sous forme de delta lake. Ce code a été initialement écrit l’été dernier en 2023 et je le place ici principalement pour ne pas le perdre. Je me dis aussi que cela peut intéresser d’autres personnes d’où ce billet.

Version des packages utilisés

À l’heure actuelle, tout l’écosystème pola.rs / delta lake n’est pas encore parfaitement stabilisé. Sans fichier requirements mais juste en listing voici les packages utilisés :

polars==1.6.0
pypmsi=0.2.6
delta==0.4.2
delta-spark==2.4.0
deltalake==0.19.2
pyspark==3.4.3
pandas==2.0.2

Notebook

Autonome en termes de présentation du code le notebook qui initie le delta lake permet de :

définir un schéma homogène de données PMSI d’un point de vue longitudinal (2013 – 2023) au préalable de l’insertion des données, un pré-requis de deltalake
charger les données RSA, ACTES, DIAGS et UM pour toutes les années avec l’ajout des identifiants NAS/IEP et NORSS
tester les fonctionalités de déletion de données (pyspark requis pour le moment) : DELETE FROM ... WHERE ANSOR = '2024'
tester la rapidité des requêtes et dénombrements au travers de la syntaxe pola.rs
un ensemble de fonctions est défini dans le notebook pour réaliser ces différentes actions
un sucre syntaxique appelé via une fonction remote_table est bricolé pour faciliter l’interrogation des données : rsa@actes permet de requêter la table actes des RSA, dans l’idée de proposer une organisation hiérarchique des données PMSI dans le lac/delta lac.

Ce notebook est accessible ici :

https://github.com/GuillaumePressiat/pmsi_rsa_for_deltalake

Il a ensuite été mis en forme pour être un peu plus joli avec quarto, ici en html:

https://guillaumepressiat.github.io/pmsi_rsa_for_deltalake/

Le voici embarqué dans cette page :

ACID : Atomicité, cohérence, isolation et durabilité ↩

pmeasyr au congrès EMOIS 2024

Wed, 03 Apr 2024 10:32:00 +0000

Un poster “pmeasyr / pypmsi : des communs en santé pour l’information médicale des établissements, et plus si affinités” sera présenté au congrès EMOIS 2024 qui se déroulera au Grand Palais de Lille les 4 et 5 avril 2024.

Retrouvez l’intégralité du programme ici :

https://www.emois.org

Un atelier nommé “R pour le PMSI” aura également lieu vendredi matin.

Voici deux liens pour visualiser :

Poster

Atelier

pmsi-io : un logiciel pour lire les in / out du PMSi et les exporter en csv, xlsx, txt, json et parquet

Wed, 03 Apr 2024 09:32:00 +0000

Contexte / objectifs

Depuis 2017, pmeasyr est une bibliothèque R accessible à tous qui permet de lire les fichiers PMSI et dont l’objectif est de pouvoir partager les connaissances autour de ces données.

En 2023, avec pypmsi, l’équivalent de pmeasyr en python, j’ai souhaité reproduire ce travail avec un autre langage, pour rendre possible les échanges avec un communauté plus large d’utilisateurs, parfois plus tournés vers le versant (bio-)informatique des choses, les entrepôts de données de santé, ou bien, plus prosaïquement, rebutés par R.

pypmsi utilise la bibliothèque pola.rs, qui est codée en Rust avec un portage en python éponyme.

Par curiosité et pour poursuivre l’extension d’une communauté autour du PMSI riche par sa diversité d’acteurs et de disciplines, je me suis intéressé au langage Rust, un langage compilé.

pmsio::io est justement codé en Rust en arrière-plan et son interface repose sur le framework SvelteKit.

L’objectif de cette application est de permettre un accès facilité et à visée pédagogique aux données PMSI en sortie de GenRSA et de Druides, les logiciels de l’ATIH, via une interface graphique simple en particulier pour ceux qui n’ont pas d’appétence particulière pour les lignes de codes.

Avec cet outil, les fichiers in/out sont découpés en plusieurs tables (partie fixe, actes, diagnostics, passages RUM) puis exportées dans des formats plus accessibles que les in/out (csv, parquet, txt, json et même xlsx). Pour les non codeurs, cette étape pourrait faciliter la compréhension des résultats d’e-PMSI ou des atypies qui y sont relevées (un code retour FG, une atypie de mouvement, un code indication incorrect, une variable de facturation mal renseignée, etc.).

Dans le nom pmsi::io, io fait donc référence à :

in/out, les fichiers en entrée/sortie des logiciels de l’ATIH
input / output car on produit de ces in/out une nouvelle sortie, de nouveaux out.

Vidéo

https://www.youtube.com/watch?v=sDyYsXLEjx4

Résultat

Un exemple ci-dessous avec le découpage des RSS et RSA partie fixe et variables et l’ajout du fichier tra aux données 2023 M12 du CHU de Brest.

À noter : les traitements sont très rapides pour toutes les sorties hormis les fichiers xlsx qui sont un peu plus exigeants à écrire.

À ce stade, l’application permet de :

dézipper les fichiers in / out en deux clics
convertir les fichiers PMSi in / out du champ MCO en tableaux de données (csv, Excel, parquet, txt, json)
ajouter le fichier tra aux données anonymisées du out
les fichiers pris en charge sont :
- RSS (fixe et variable)
- RSA (fixe et variable)
- anohosp (in / out)
- dmi (in / out)
- med / medatu (in / out)
- porg (in / out)
- diap (out)
- tra

Installation

L’application est disponible pour Windows, Ubuntu et Mac.

Télécharger l’application ici

Mac Silicon ••• Mac Intel ••• Mac Universal
Windows exe ••• Windows msi
Ubuntu deb ••• Ubuntu AppImage

Lancer l’installation en fonction du système d’exploitation.

Discussion

Si un tel outil s’avérait utile, au moins dans certains établissements, je n’aurai pas découvert Rust pour rien !

Et si tel était le cas, Druides ne devrait-il pas intégrer ces fonctionnalités ?

À long terme, si la solution en Rust se confirme, il est possible que pmeasyr et pypmsi l’utilisent directement comme dépendance.

Contact

N’hésitez pas à me contacter en cas de problème. Cela reste un logiciel jeune et gratuit, il n’est pas exempt de bugs.

Questionnaire PMSI avec R / python

Wed, 09 Aug 2023 06:05:50 +0000

Un questionnaire a été mis en ligne pour en savoir plus sur les utilisateurs et les utilisations des packages :

pmeasyr
nomensland
pypmsi

Cliquer ici pour répondre au questionnaire !

Merci.

Quarto + pypmsi

Thu, 04 May 2023 08:05:50 +0000

Voir le notebook ici :

Notebook python Quarto (html)

Le fichier Quarto Rmd est disponible également ici :

Notebook python Quarto (qmd source)

Reproduire des in / out MCO à partir des zip.zip.zip de Druides

Tue, 18 Apr 2023 08:05:50 +0000

Comment regénérer avec R des in / out sur la version de test de Druides 0.7.4.0 ?

Contexte

Il est attendu que la version officielle de Druides permette de continuer à générer des fichiers “in” et “out”.

Cela dit, il peut paraitre intéressant de voir comment le faire directement avec les fichiers présents dans le AppData de Druides en version de test si jamais cette fonctionnalité n’était pas disponible dès M03, ou bien par curiosité.

Code

library(dplyr)

# Répertoire de travail temporaire
setwd('~/../Downloads/in_out/')

# druides a tourné et généré ce fichier zip
# 290000017.2023.0.SEJOURS.SEJOURS.xxxxxxxxxxxxxxxx.zip

# Placer ce dernier fichier généré dans par druides dans le répertoire par exemple :
# ~/../Downloads/in_out/druides_out/202302

# Lister les fichiers (récupérer le nom du zip dynamiquement)
liste_in_out <- list.files('druides_out/202302', full.names = TRUE)

# récupérer les paramètres classiques type noyau_pmeasyr depuis le nom du zip
finess <- basename(liste_in_out)[1] %>% stringr::str_split('\\.') %>% .[[1]] %>% .[1]
annee  <- basename(liste_in_out)[1] %>% stringr::str_split('\\.') %>% .[[1]] %>% .[2]
mois   <- basename(liste_in_out)[1] %>% stringr::str_split('\\.') %>% .[[1]] %>% .[3]

# générer un timestamp sur la date de création du zip
# TODO : case when si plateforme unix alors ctime, sinon mtime (windows) : à vérifier
timestamp_druides <- file.info(liste_in_out[1])$mtime %>% format('%d%m%Y%H%M%S')
# générer deux noms de répertoires type in et out horodaté ; finess.annee.mois.horodate.in et out
in_repos <- paste0(finess, '.', annee, '.', mois, '.', timestamp_druides, '.in')
out_repos <- paste0(finess, '.', annee, '.', mois, '.', timestamp_druides, '.out')

# On extrait les fichiers "matriochkas"
unzip(liste_in_out[grepl('zip', liste_in_out)], exdir = 'temp____00')
# pour le in > in4ctl ne contient que um et rss ré-arrangé, et un tra formaté csv
unzip(list.files('temp____00', pattern = 'data.zip', full.names = TRUE), exdir = 'temp____01')
unzip(list.files('temp____01', pattern = 'in4ctl.zip', full.names = TRUE), exdir = in_repos)
R.utils::gunzip(list.files('temp____01', pattern = 'in.gzip', full.names = TRUE), ext = "gzip")

# pour le out > basket contient tout le out.zip sauf le tra
unzip(list.files('temp____01', pattern = 'basket.zip', full.names = TRUE), exdir = 'temp_out_01')
unzip(list.files('temp____01', pattern = 'log', full.names = TRUE), exdir = 'temp_out_01')
unzip(list.files('temp_out_01', pattern = 'data.zip', full.names = TRUE), exdir = 'temp_out_02')
unzip(list.files('temp_out_02', pattern = 'data2.zip', full.names = TRUE), exdir = out_repos)



# move tra > et le reformater "comme avant"
tra_link <- list.files(in_repos, pattern = '\\.tra', full.names = TRUE)
tra_l <- readr::read_csv2(tra_link, col_names = c('finess', 'pkrsa', 'nas', 'norss', 'dtent', 'dtsort', 'filler'))
tra_l <- tra_l %>% 
  mutate(dtent = format(dtent, '%d%m%Y'),
         ghm = '      ',
         no_rss_ent = stringr::str_pad('',10, 'right', '0'),
         norss = stringr::str_pad(norss, 20, 'right', ' '),
         nas = stringr::str_pad(nas, 20, 'right', ' '),
         dtsort = format(dtsort, '%d%m%Y')) %>% 
  glue::glue_data('{pkrsa}{norss}{no_rss_ent}{nas}{dtent}{ghm}{dtsort}')

readr::write_lines(tra_l, file.path(out_repos, basename(tra_link)))
# file.copy(tra_link, out_repos)

file_in_sejours <- list.files('temp____01', pattern = 'SEJOURS\\.SEJOURS.*\\.in$', full.names = FALSE)

# pour la partie RSS et les in on utilise le json
json_rss <- jsonlite::read_json(paste0('temp____01/',
                                       file_in_sejours), simplifyVector = TRUE)

contenus <- names(json_rss$dossiers[[1]])

mappe_in <- tibble::tribble(
  ~contenu,      ~file_in,
  "dossierId",        NA,
  "dateEntreeSejour", NA,
  "dateSortieSejour", NA,
  "dateNaissance",    NA,
  "topmaisnais",      NA,
  "anohosp",          "ano.txt",
  "rums",             "rss.txt",
  "iums",             "ium.txt",
  "meds",             "med.txt",
  "dmis",             "dmi.txt",
  "porgs",            "porg.txt",
  "pies",             "pie.txt",
  "dips",             "diap.txt",
  "ivgs",             "ivg.txt",
  "maisnaiss",        NA,
  "transps",          "transp.txt",
  "immunos",          NA,
  "dmintraghs",       NA,
  "sexe",             NA,
  "estDecede",        NA
)

extract_json_in <- function(json_rss, contenu){
  json_rss$dossiers %>% 
    purrr::map(contenu) %>% 
    unlist() %>% 
    .[!is.na(.)]
}

# contenu1 <- 'dmis'
write_like_in <- function(contenu1, json_rss,  mappe_in){
  file_in <- mappe_in %>% filter(contenu == contenu1) %>% pull(file_in)
  extract_json_in(json_rss, contenu1) -> temp
  
  if (contenu1 == 'iums'){
    temp <- unique(temp)
  }
  readr::write_lines(temp, paste0(in_repos, '/', finess, '.', annee, '.', mois,'.', file_in))
  TRUE
}


mappe_in %>% 
  filter(!is.na(file_in)) %>% 
  pull(contenu) %>% 
  # .[1:2] %>% 
  purrr::map(write_like_in, json_rss, mappe_in)


# remap mois2 to mois1
to_rename <- list.files(in_repos, full.names = TRUE)
fichier <- to_rename[1]
rename_mois <- function(fichier, finess, annee, mois){
  fichier_renome <- stringr::str_replace(fichier, 
                                         paste0('\\/', finess, '.', annee, '.', stringr::str_pad(mois, 2, 'left', '0')),
                                         # paste0('\\/', finess, '.', annee, '.', mois)
                                         paste0('\\/', finess, '.', annee, '.', 2)
                                         )
  file.rename(fichier, fichier_renome)
}

purrr::map(to_rename, rename_mois, finess, annee, mois)
to_rename <- list.files(out_repos, full.names = TRUE)
purrr::map(to_rename, rename_mois, finess, annee, mois)

log_file <- list.files('temp_out_01/', pattern = "log.json", full.names = TRUE)
log_json <- jsonlite::read_json(log_file, simplifyVector = TRUE)

unnest_errors <- function(log_json, type1){
  log_json %>% 
    as_tibble() %>% 
    filter(Type == type1) %>% 
    mutate(nb_errors = purrr::map_dbl(Errors, function(x)length(x))) %>% 
    filter(nb_errors > 0) %>% 
    select(-Type) %>% 
    group_by(Id) %>% 
    tidyr::unnest(Errors) %>% 
    ungroup %>% 
    tidyr::separate(Id, c('nas', 'norss', 'dtent', 'dtsort'), sep = "\\@")
}

liste_type <- count(log_json, Type) %>% pull(Type)

liste_erreurs <- purrr::map(liste_type, unnest_errors, log_json = log_json)
names(liste_erreurs) <- liste_type

toutes_erreurs <- bind_rows(liste_erreurs)

readr::write_csv2(toutes_erreurs, paste0(out_repos, '/', finess, '.', annee, '.', mois, '.', 'erreurs.csv'))

zip(zipfile = paste0(in_repos, '.zip'), files = list.files(in_repos, full.names = TRUE),
         flags = '-r9Xj')
zip(paste0(out_repos, '.zip'), list.files(out_repos, full.names = TRUE),
    flags = '-r9Xj')


unlink(list.files(pattern = 'temp_'), recursive = TRUE)

# library(pmeasyr)
# adezip(290000017, 2023, 0, '.', type = "out")
# 
# irsa(290000017, 2023, 2, '.')
# 
# iano_mco(290000017, 2023, 2, '.') %>% count(FACTAM)
# 
# imed_mco(290000017, 2023, 2, '.')
# 
# adelete(290000017, 2023, 2, '.')
#

pypmsi : lire des fichiers PMSI avec python / polars

Sat, 11 Mar 2023 08:05:50 +0000

pypmsi est un package python pour lire les fichiers du PMSI ; dans la suite de pmeasyr.

Ce code, qui en est à ses débuts, a été initié au sein du département d’information médicale du CHU de Brest en conjonction avec son centre de données cliniques (CDC, entrepôt de données de santé) et dans la continuité des travaux réalisés avec le DIM de l’AP-HP.

Le découpage d’un fichier .rsa de 130 000 RSA prend selon les types d’imports :

<= 1 seconde, découpage partie fixe (< 300 ms avec puce silicon)
<= 4 secondes, découpage partie fixe + parties variables actes, diags, ums (< 1 seconde avec puce silicon)

Le découpage d’un fichier .rss de 140 000 lignes prend selon les types d’imports :

<= 1 seconde, découpage partie fixe (~ 150 ms avec puce silicon)
<= 3 secondes, découpage partie fixe + parties variables actes, diags (< 600 ms seconde avec puce silicon)

Le découpage d’un fichier .rsfa avec pypmsi sur puce silicon met :

773 ms pour 1 million de lignes rafael
1,4 secondes pour 2 millions
3 secondes pour 5 millions
7 secondes pour 10 millions
14 secondes pour 20 millions
35 secondes pour 30 millions
1min 35sec secondes pour 50 millions

Installation

pip install https://github.com/GuillaumePressiat/pypmsi/releases/latest/download/pypmsi-0.5.0-py3-none-any.whl

ou télécharger la dernière version directement sur github avec votre navigateur et l’installer ainsi :

pip install pypmsi-X.Y.Z-py3-none-any.whl

en remplaçant X Y et Z par ce qu’il faut.

Dépôt

https://github.com/GuillaumePressiat/pypmsi

Documentation

https://guillaumepressiat.github.io/pypmsi/

pola.rs ?

Lightning-fast DataFrame library for Rust and Python

Utilisation de pypmsi

import polars
import pypmsi as pm

3 manières de lire un fichier

Spécifier les paramètres dans la fonction

rsa = pm.irsa(290000017, 2021,5, '~/Documents/data/mco', typi = 4)
rsa

Définir un noyau de paramètres

p = pm.noyau_pmsi(finess = 290000017, annee = 2021, mois = 5, path = '~/Documents/data/mco')
rsa = p.irsa()
rsa

indiquer le chemin du fichier et l’année, et le lire

mon_rsa = pm.chemin_pmsi(filepath = '~/Documents/data/mco/290000017.2021.5.rsa', annee = 2021)
rsa = mon_rsa.read_rsa()
rsa

(du coup le nom du fichier peut-être formaté différement : export_rock_n_roll.rss).

On peut modifier en ligne les paramètres, exemple :

p = pm.noyau_pmsi(finess = 290000017, annee = 2021, mois = 12, path = '~/Documents/data/mco')
# lire les données 2022
rsa = p.irsa(annee = 2022)
rsa

Exemple sur les rsa

rsa

{'rsa': shape: (57140, 88)
┌───────────┬────────┬────────────┬────────┬─────┬───────┬──────┬─────┬─────────┐
│ nofiness  ┆ novrsa ┆ cle_rsa    ┆ novrss ┆ ... ┆ dr    ┆ ndas ┆ na  ┆ filler6 │
│ ---       ┆ ---    ┆ ---        ┆ ---    ┆     ┆ ---   ┆ ---  ┆ --- ┆ ---     │
│ str       ┆ str    ┆ str        ┆ str    ┆     ┆ str   ┆ i32  ┆ i32 ┆ str     │
╞═══════════╪════════╪════════════╪════════╪═════╪═══════╪══════╪═════╪═════════╡
│ 290000017 ┆ 226    ┆ 00000xxxxx ┆ 120    ┆ ... ┆ R5210 ┆ 0    ┆ 0   ┆         │
│ 290000017 ┆ 226    ┆ 00000xxxxx ┆ 120    ┆ ... ┆ G628  ┆ 0    ┆ 0   ┆         │
│ 290000017 ┆ 226    ┆ 00000xxxxx ┆ 120    ┆ ... ┆ M341  ┆ 0    ┆ 5   ┆         │
│ 290000017 ┆ 226    ┆ 00000xxxxx ┆ 120    ┆ ... ┆       ┆ 16   ┆ 27  ┆         │
│ ...       ┆ ...    ┆ ...        ┆ ...    ┆ ... ┆ ...   ┆ ...  ┆ ... ┆ ...     │
│ 290000017 ┆ 226    ┆ 00000xxxxx ┆ 120    ┆ ... ┆       ┆ 0    ┆ 4   ┆         │
│ 290000017 ┆ 226    ┆ 00000xxxxx ┆ 120    ┆ ... ┆ N185  ┆ 0    ┆ 1   ┆         │
│ 290000017 ┆ 226    ┆ 00000xxxxx ┆ 120    ┆ ... ┆ C504  ┆ 0    ┆ 1   ┆         │
│ 290000017 ┆ 226    ┆ 00000xxxxx ┆ 120    ┆ ... ┆       ┆ 6    ┆ 25  ┆         │
└───────────┴────────┴────────────┴────────┴─────┴───────┴──────┴─────┴─────────┘, 

'actes': shape: (166028, 13)
┌────────────┬───────┬─────────┬────────┬─────┬────────┬────────┬────────┬─────────┐
│ cle_rsa    ┆ delai ┆ cdccam  ┆ descri ┆ ... ┆ assonp ┆ nbexec ┆ indval ┆ nseqrum │
│ ---        ┆ ---   ┆ ---     ┆ ---    ┆     ┆ ---    ┆ ---    ┆ ---    ┆ ---     │
│ str        ┆ i32   ┆ str     ┆ str    ┆     ┆ str    ┆ i32    ┆ str    ┆ str     │
╞════════════╪═══════╪═════════╪════════╪═════╪════════╪════════╪════════╪═════════╡
│ 00000xxxxx ┆ 0     ┆ GLQP002 ┆        ┆ ... ┆ 1      ┆ 1      ┆ 1      ┆ 01      │
│ 00000xxxxx ┆ 0     ┆ PBQM003 ┆        ┆ ... ┆        ┆ 1      ┆ 1      ┆ 01      │
│ 00000xxxxx ┆ 0     ┆ YYYY076 ┆        ┆ ... ┆ 2      ┆ 1      ┆ 1      ┆ 01      │
│ 00000xxxxx ┆ 0     ┆ ZZQX069 ┆        ┆ ... ┆ 4      ┆ 1      ┆ 1      ┆ 01      │
│ ...        ┆ ...   ┆ ...     ┆ ...    ┆ ... ┆ ...    ┆ ...    ┆ ...    ┆ ...     │
│ 00000xxxxx ┆ 4     ┆ DEQP004 ┆        ┆ ... ┆        ┆ 1      ┆ 1      ┆ 02      │
│ 00000xxxxx ┆ 4     ┆ YYYY020 ┆        ┆ ... ┆        ┆ 1      ┆ 1      ┆ 02      │
│ 00000xxxxx ┆ 4     ┆ YYYY020 ┆        ┆ ... ┆        ┆ 1      ┆ 1      ┆ 02      │
│ 00000xxxxx ┆ 4     ┆ YYYY020 ┆        ┆ ... ┆        ┆ 1      ┆ 1      ┆ 02      │
└────────────┴───────┴─────────┴────────┴─────┴────────┴────────┴────────┴─────────┘, 

'diags': shape: (177176, 4)
┌────────────┬─────────┬───────┬──────────┐
│ cle_rsa    ┆ nseqrum ┆ diag  ┆ position │
│ ---        ┆ ---     ┆ ---   ┆ ---      │
│ str        ┆ str     ┆ str   ┆ i32      │
╞════════════╪═════════╪═══════╪══════════╡
│ 00000xxxxx ┆ 01      ┆ Z4180 ┆ 1        │
│ 00000xxxxx ┆ 01      ┆ Z512  ┆ 1        │
│ 00000xxxxx ┆ 01      ┆ Z092  ┆ 1        │
│ 00000xxxxx ┆ 01      ┆ D462  ┆ 1        │
│ ...        ┆ ...     ┆ ...   ┆ ...      │
│ 00000xxxxx ┆ 01      ┆ M0699 ┆ 4        │
│ 00000xxxxx ┆ 01      ┆ C629  ┆ 4        │
│ 00000xxxxx ┆ 01      ┆ N185  ┆ 4        │
│ 00000xxxxx ┆ 01      ┆ C504  ┆ 4        │
└────────────┴─────────┴───────┴──────────┘, 

'rsa_um': shape: (63199, 17)
┌────────────┬─────────┬────────┬───────────┬─────┬─────────┬─────────┬──────────┬─────────┐
│ cle_rsa    ┆ nseqrum ┆ nsequm ┆ nohop1    ┆ ... ┆ nbsupp1 ┆ typaut2 ┆ natsupp2 ┆ nbsupp2 │
│ ---        ┆ ---     ┆ ---    ┆ ---       ┆     ┆ ---     ┆ ---     ┆ ---      ┆ ---     │
│ str        ┆ str     ┆ str    ┆ str       ┆     ┆ i32     ┆ str     ┆ str      ┆ str     │
╞════════════╪═════════╪════════╪═══════════╪═════╪═════════╪═════════╪══════════╪═════════╡
│ 00000xxxxx ┆ 01      ┆ 0028   ┆ 29000xxxx ┆ ... ┆ 0       ┆         ┆          ┆         │
│ 00000xxxxx ┆ 01      ┆ 0021   ┆ 29000xxxx ┆ ... ┆ 0       ┆         ┆          ┆         │
│ 00000xxxxx ┆ 01      ┆ 0022   ┆ 29000xxxx ┆ ... ┆ 0       ┆         ┆          ┆         │
│ 00000xxxxx ┆ 01      ┆ 0076   ┆ 29000xxxx ┆ ... ┆ 109     ┆         ┆          ┆         │
│ ...        ┆ ...     ┆ ...    ┆ ...       ┆ ... ┆ ...     ┆ ...     ┆ ...      ┆ ...     │
│ 00000xxxxx ┆ 02      ┆ 0039   ┆ 29000xxxx ┆ ... ┆ 0       ┆         ┆          ┆         │
│ 00000xxxxx ┆ 03      ┆ 0039   ┆ 29000xxxx ┆ ... ┆ 0       ┆         ┆          ┆         │
│ 00000xxxxx ┆ 04      ┆ 0085   ┆ 29000xxxx ┆ ... ┆ 0       ┆         ┆          ┆         │
│ 00000xxxxx ┆ 05      ┆ 0085   ┆ 29000xxxx ┆ ... ┆ 0       ┆         ┆          ┆         │
└────────────┴─────────┴────────┴───────────┴─────┴─────────┴─────────┴──────────┴─────────┘}

Quelques statistiques avec polars

(rsa['actes']
  .filter(pl.col('cdccam').str.contains('EBLA'))
  .groupby(['cdccam', 'nbexec'])
  .count()
)

shape: (2, 3)
┌─────────┬────────┬───────┐
│ cdccam  ┆ nbexec ┆ count │
│ ---     ┆ ---    ┆ ---   │
│ str     ┆ i64    ┆ u32   │
╞═════════╪════════╪═══════╡
│ EBLA002 ┆ 1      ┆ 2     │
│ EBLA003 ┆ 1      ┆ 185   │
└─────────┴────────┴───────┘

(rsa['actes']
  .filter(pl.col('cdccam').str.contains('EBLA'))
  .join(rsa['rsa'], on = 'cle_rsa', how = 'inner')
  .pivot('nbexec', 'cdccam', 'rsatype', 'count')
  .fill_null(0)
)

shape: (2, 5)
┌─────────┬─────┬─────┬─────┬─────┐
│ cdccam  ┆ C   ┆ M   ┆ Z   ┆ K   │
│ ---     ┆ --- ┆ --- ┆ --- ┆ --- │
│ str     ┆ u32 ┆ u32 ┆ u32 ┆ u32 │
╞═════════╪═════╪═════╪═════╪═════╡
│ EBLA003 ┆ 24  ┆ 56  ┆ 9   ┆ 96  │
│ EBLA002 ┆ 0   ┆ 1   ┆ 1   ┆ 0   │
└─────────┴─────┴─────┴─────┴─────┘

(rsa['actes']
  .filter(pl.col('cdccam').str.contains('EBLA'))
  .join(rsa['rsa'], on = 'cle_rsa', how = 'inner')
  .pivot('nbexec', 'cdccam', ['rsacmd', 'rsatype'], 'sum')
  .fill_null(0)
)

shape: (2, 19)
┌─────────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┐
│ cdccam  ┆ 17  ┆ 11  ┆ 04  ┆ ... ┆ C   ┆ M   ┆ Z   ┆ K   │
│ ---     ┆ --- ┆ --- ┆ --- ┆     ┆ --- ┆ --- ┆ --- ┆ --- │
│ str     ┆ i64 ┆ i64 ┆ i64 ┆     ┆ i64 ┆ i64 ┆ i64 ┆ i64 │
╞═════════╪═════╪═════╪═════╪═════╪═════╪═════╪═════╪═════╡
│ EBLA003 ┆ 29  ┆ 1   ┆ 13  ┆ ... ┆ 24  ┆ 56  ┆ 9   ┆ 96  │
│ EBLA002 ┆ 0   ┆ 0   ┆ 0   ┆ ... ┆ 0   ┆ 1   ┆ 1   ┆ 0   │
└─────────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┘

Types d’imports

La typologie des imports pour les RUM et les RSA reprend celle du package pmeasyr.

On peut obtenir avec les imports “stream” des colonnes de ce type, ici au niveau des RSA :

┌───────────┬────────┬────────────┬───────────────────┬────────────────────────────┬───────────────────────────┬───────────────┬─────────────┐
│ nofiness  ┆ novrsa ┆ cle_rsa    ┆ stream_actes      ┆ stream_das                 ┆ stream_um                 ┆ stream_dpum   ┆ stream_drum │
│ ---       ┆ ---    ┆ ---        ┆ ---               ┆ ---                        ┆ ---                       ┆ ---           ┆ ---         │
│ str       ┆ str    ┆ str        ┆ str               ┆ str                        ┆ str                       ┆ str           ┆ str         │
╞═══════════╪════════╪════════════╪═══════════════════╪════════════════════════════╪═══════════════════════════╪═══════════════╪═════════════╡
│ 290000017 ┆ 226    ┆ y          ┆ null              ┆ null                       ┆ 61 P                      ┆ Z4180         ┆ R5210       │
│ 290000017 ┆ 226    ┆ y          ┆ null              ┆ null                       ┆ 29 C                      ┆ Z512          ┆ G628        │
│ 290000017 ┆ 226    ┆ y          ┆ YYYY076, GLQP002, ┆ null                       ┆ 29 M                      ┆ Z092          ┆ M341        │
│           ┆        ┆ y          ┆ PBQM003, ZZQX1... ┆                            ┆                           ┆               ┆             │
│ 290000017 ┆ 226    ┆ y          ┆ ZZNL047, ZZML002, ┆ K573, J980, T808, J448,    ┆ 16 C                      ┆ D462          ┆             │
│           ┆        ┆            ┆ YYYY028, ZZML0... ┆ T827, D6...                ┆                           ┆               ┆             │
│ ...       ┆ ...    ┆ ...        ┆ ...               ┆ ...                        ┆ ...                       ┆ ...           ┆ ...         │
│ 290000017 ┆ 226    ┆ y          ┆ QZMA006           ┆ null                       ┆ 53 C                      ┆               ┆             │
│ 290000017 ┆ 226    ┆ y          ┆ JVJF008           ┆ null                       ┆ 21 P                      ┆ Z491          ┆ N185        │
│ 290000017 ┆ 226    ┆ y          ┆ ZZNL051           ┆ null                       ┆ 01 C, 42 P                ┆ Z5101         ┆ C504        │
└───────────┴────────┴────────────┴───────────────────┴────────────────────────────┴───────────────────────────┴───────────────┴─────────────┘

(ici sur les RSA, typi = 3)

On peut alors filtrer sur les actes, les diags etc directement au niveau des RSA, sans jointure entre les tables :

import polars as pl
# Exemple : PTG ou PTH sans RUM avec DP S ou M
(rsa['rsa']
  .filter(pl.col('stream_actes').str.contains('N.KA'))
  .filter(~pl.col('stream_dpum').str.contains('S|M'))
)

RSA : 6 types d’imports (typi)

# 1          : partie fixe uniquement
# 2          : partie fixe + zones streams actes, das
# 3          : partie fixe + zones streams actes, das, dpum, drum, typaut
# 4 (défaut) : partie fixe + partie variable + zones streams actes, das
# 5          : partie fixe + zones streams actes, das, dpum, drum, typaut
# 6          : partie fixe + partie variable + zones streams actes, das, dpum, drum, typaut

RUM : 4 types d’imports (typi)

# 1          : partie fixe uniquement
# 2          : partie fixe + zones streams actes, das, dad
# 3 (défaut) : partie fixe + partie variable
# 4          : partie fixe + partie variable + zones streams actes, das, dad

Comprendre l'évolution de valorisation e-PMSI entre deux envois MCO rsa avec R

Tue, 11 Oct 2022 08:05:50 +0000

Dans une année de collecte des informations du PMSI dans un hôpital,
il y a des périodes où l’on cherche particulièrement à concentrer l’optimisation des envois.

Lorsque ces efforts semblent porter leurs fruits, il peut être intéréssant de détailler :

sur quels types de séjours
sur quelles rubriques e-PMSI
pour quelles raisons (quelles actions)

la revalorisation T2A s’opère.

Ce post présente une manière de le faire concordante avec les tableaux SV et RAV d’ePMSI. Il utilise le package pmeasyr et dplyr.

Contexte

Les évolutions de valorisation peuvent être la conséquence d’actions de différents acteurs :

GHM : codage CMD type GHM + sévérités + actes
Suppléments
Nouveaux séjours
Séjours supprimés (ou « disparus »)
Evolutions de la ligne vid-hosp

Valoriser le travail effectué une fois l’envoi réalisé n’est pas toujours facile à faire car les actions ont été diverses et étalées sur de nombreux secteurs. Savoir valoriser les efforts effectués par les différents acteurs peut amener de la reconnaissance.

Parfois, des séjours peuvent “disparaître” de l’envoi ou de nombreux séjours devenir non facturables ; il est alors précieux de pouvoir les identifier rapidement pour cibler le problème et viser concrêtement à sa résolution sur des exemples précis (rss, nas/iep).

Ce post présente une manière de le faire cohérente avec les tableaux “SV - Séjours valorisés” et “RAV - Récapitulatif Activité Valorisation” d’ePMSI en termes de typologies et de montants.

Emplacement des archives out

On place les archives PMSI des deux envois v1 et v2 dans deux répertoires proches :

~/Documents/data/tests/v1
~/Documents/data/tests/v2

Ensuite on peut dézipper les fichiers ainsi :

library(pmeasyr)
library(dplyr)

noyau_pmeasyr(
  finess = '123456789',
  annee  = 2022,
  mois   = 8,
  path   = '~/Documents/data/tests/v1'
) -> p1

noyau_pmeasyr(
  finess = '123456789',
  annee  = 2022,
  mois   = 8,
  path   = '~/Documents/data/tests/v2'
) -> p2

adezip(p1, type = "out")
adezip(p2, type = "out")

Valorisation T2A des deux envois

On utilise la fonction map pour appliquer la valorisation aux deux archives out.

Le code utilise ici de nombreuses fonctions du package pmeasyr et les tables de tarifs GHS et suppléments présentes dans le package nomensland.

rsa_valo_compile <- purrr::map(list(p1, p2),
                               function(p){
                                 p$tolower_names <- TRUE
                                 vrsa <- vvr_rsa(p)
                                 vano <- vvr_ano_mco(p)
                                 library(nomensland)
                                 tarifs_ghs <- dplyr::distinct(get_table('tarifs_mco_ghs'), 
                                                               ghs, anseqta, .keep_all = TRUE)
                                 
                                 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 = 1,
                                                prudent = 0.993,
                                                bee = FALSE),
                                   vvr_mco_sv(vrsa, vano, ipo(p))
                                 ) %>% inner_tra(itra(p)) %>%
                                   mutate(ansor = as.character(p$annee))
                                 resu %>% select(-nohop) %>%
                                   mutate(envoi = basename(p$path)) %>%
                                   left_join(vrsa %>% select(cle_rsa, ghm))
                               }
)

Reproduire les tableaux SV et RAV d’ePMSI

Dans tous les tableaux, tous les montants et volumes sont mis à zéro

Par exemple sur l’envoi v1

Tableau RAV

epmsi_mco_rav(rsa_valo_compile[[1]]) %>% 
  knitr::kable()

ordre_epmsi	lib_valo	var
1	Valorisation des GHS de base	rec_base
2	Valorisation extrême bas (à déduire)	rec_exb
5	Valorisation journées extrême haut	rec_exh
6	Valorisation actes GHS 9615 en Hospit.	rec_aph
8	Valorisation suppléments antepartum	rec_ant
9	Valorisation actes RDTH en Hospit.	rec_rdt_tot
10	Valorisation suppléments de réanimation	rec_rea
11	Valorisation suppléments de réa pédiatrique	rec_rep
12	Valorisation suppléments de néonat sans SI	rec_nn1
13	Valorisation suppléments de néonat avec SI	rec_nn2
14	Valorisation suppléments de réanimation néonat	rec_nn3
15	Valorisation prélévements d organe	rec_po_tot
16	Valorisation des actes de caissons hyperbares en sus	rec_caishyp
17	Valorisation suppléments de dialyse	rec_dialhosp
20	Valorisation suppléments de surveillance continue	rec_src
21	Valorisation suppléments de soins intensifs	rec_stf
NA	Total valorisation 100% T2A	rec_totale

Tableau SV

 epmsi_mco_sv(rsa_valo_compile[[1]]) %>% 
 knitr::kable()

type_fin	%	lib_type
0	%	Séjours valorisés
1	%	Séjours en CM 90
2	%	Séjours en prestation inter-établissement
3	%	Séjours en GHS 9999
4	%	Séjours avec pb de chainage (hors NN, rdth et PO)
5	%	Séjours avec pb de codage des variables bloquantes
6	%	Séjours en attente de décision sur les droits du patient
7	%	Séjours non facturable à l’AM hors PO

Comparaison des deux envois rss par rss

rsa_v1 <- rsa_valo_compile[[1]] %>%
  select(norss, type_fin, typvidhosp, rec_totale, envoi, ghm) %>%
  left_join(vvr_libelles_valo('lib_type_sej'))

rsa_v2 <- rsa_valo_compile[[2]] %>%
  select(norss, type_fin, typvidhosp, rec_totale, envoi, ghm) %>%
  left_join(vvr_libelles_valo('lib_type_sej'))

rsa_v1 %>%
  full_join(rsa_v2, by = c('norss'), suffix = c('_v1', '_v2')) %>%
  mutate(delta_evol = case_when(
    is.na(type_fin_v1) & type_fin_v2 != "0" ~ 0,
    is.na(type_fin_v1) & type_fin_v2 == "0" ~ rec_totale_v2,
    is.na(type_fin_v2) & type_fin_v1 != "0" ~ 0,
    is.na(type_fin_v2) & type_fin_v1 == "0" ~ -rec_totale_v1,
    type_fin_v1 == "0" & type_fin_v2 != "0" ~ -rec_totale_v1,
    type_fin_v1 != "0" & type_fin_v2 == "0" ~ rec_totale_v2,
    type_fin_v1 != "0" & type_fin_v2 != "0" ~ 0,
    type_fin_v1 == "0" & type_fin_v2 == "0" ~ rec_totale_v2 - rec_totale_v1,
    TRUE ~ 0
  )) -> comparaisons

comparaisons %>%
  group_by(lib_type_v1, lib_type_v2) %>%
  summarise(n = n(),
            valo_v1 = sum(rec_totale_v1, na.rm = TRUE),
            valo_v2 = sum(rec_totale_v2, na.rm = TRUE),
            evol = sum(delta_evol)) %>%
  ungroup %>%
  mutate_if(is.character, tidyr::replace_na, "RSA absent") %>%
  mutate_if(is.numeric, function(x)0) %>% knitr::kable()

Quelques exemples de lignes :

La colonne évol donnera la valorisation correspondante au delta (avec le bon signe) entre les deux envois (les évolutions vont dans les deux sens, valo_v1 et valo_v2 étant les valeurs 100% T2A).

lib_type_v1 et lib_type_v2 seront ici les rubriques du tableau SV des deux envois PMSI réalisés. Lorsqu’un séjour change de rubrique ou que la valorisation change de montant il s’est passé quelque chose dans les données soit DIM (RSS) soit facturation (ano-hosp).

lib_type_v1	lib_type_v2	n	valo_v1	valo_v2	evol
Séjours avec pb de chainage (hors NN, rdth et PO)	Séjours avec pb de chainage (hors NN, rdth et PO)	0	0	0	0
Séjours avec pb de chainage (hors NN, rdth et PO)	Séjours non facturable à l’AM hors PO	0	0	0	0
Séjours avec pb de chainage (hors NN, rdth et PO)	RSA absent	0	0	0	0
Séjours en CM 90	Séjours avec pb de chainage (hors NN, rdth et PO)	0	0	0	0
Séjours en CM 90	Séjours en CM 90	0	0	0	0
Séjours en CM 90	Séjours en GHS 9999	0	0	0	0
Séjours en CM 90	Séjours valorisés	0	0	0	0
Séjours en CM 90	RSA absent	0	0	0	0
Séjours en GHS 9999	Séjours en CM 90	0	0	0	0
Séjours en GHS 9999	Séjours en GHS 9999	0	0	0	0
Séjours en GHS 9999	Séjours valorisés	0	0	0	0
Séjours en prestation inter-établissement	Séjours en prestation inter-établissement	0	0	0	0
Séjours non facturable à l’AM hors PO	Séjours non facturable à l’AM hors PO	0	0	0	0
Séjours valorisés	Séjours avec pb de chainage (hors NN, rdth et PO)	0	0	0	0
Séjours valorisés	Séjours en CM 90	0	0	0	0
Séjours valorisés	Séjours valorisés	0	0	0	0
Séjours valorisés	RSA absent	0	0	0	0
RSA absent	Séjours non facturable à l’AM hors PO	0	0	0	0
RSA absent	Séjours valorisés	0	0	0	0

On peut ensuite trouver les séjours correspondants et les décrire avec dplyr et ggplot (non détaillé ici).

Quelques exemples

# Nouveaux séjours ? (ou séjours disparus à l'inverse)
comparaisons %>%
  filter(is.na(lib_type_v1), lib_type_v2 == "Séjours valorisés") %>%
  group_by(ghm_v2) %>%
  summarise(n = n(),
            evol = sum(delta_evol))

# type GHM et CM(D) identique mais sévérités différentes ?
comparaisons %>%
  filter(substr(ghm_v1,1,3) == substr(ghm_v2,1,3), ghm_v1 != ghm_v2) %>%
  group_by(sev_v1 = substr(ghm_v1,6,6),sev_v2 =  substr(ghm_v2,6,6)) %>%
  summarise(n = n(),
            evol = sum(delta_evol))

# type GHM et CM(D) différents ?
comparaisons %>%
  filter(substr(ghm_v1,1,3) != substr(ghm_v2,1,3)) %>%
  group_by(rsatype_v1 = substr(ghm_v1,3,3), rsatype_v2 =  substr(ghm_v2,3,3)) %>%
  summarise(n = n(),
            evol = sum(delta_evol))

Enfin, voici un exemple de graphique ggplot2 représentant des évolution de sévérités entre deux envois, avec des données fictives :

avec l’exemple de lecture suivant :

165 RSS de niveau 1 en v1 ont basculé en niveau 2 en v2
12 RSS en niveau 2 passent en niveau 3
6 RSS passent du niveau 1 au niveau 4
100 RSS en niveau Z (non codés probablement) sont passés en niveau 1, 20 en niveau 2, etc

Le même genre d’analyse est faisable sur les recettes liées aux fichcomp.

Trying to reproduce a map of the greater Paris area from APUR with ggplot2, a moment for coloring

Sun, 30 Jan 2022 08:05:50 +0000

In 2016, APUR the Paris urbanism agency published a map that described new Greater Paris area, see here.

At this time I was interested to reproduce this map in R with official datas/shapefiles and ggplot2.

A moment for coloring.

I put this code story here to let it somewhere else than my head (I have lost part of the code since 2016) and to share.

Here is the map from APUR:

Trying to mimick with ggplot2

First thing was to define T1 to T12 areas (groups of cities) and use french national geographic institute (IGN) shapefiles to plot a beginning ggplot2 map:

After some efforts, I was able to show this in R:

La Seine and co.

Last thing that was not shown are rivers and canals. I had to find a shapefile for this.

Fortunately, I have found a shapefile from APUR website directly, named PLAN_EAU.

With this data, I have been able to show La Seine, La Marne, le Port de Gennevilliers and Paris canals.

Here I have plotted Grand Paris with “carbon like” colors to highlight this new area and because I find it’s pretty cool like that!

R is really a nice environment.

See here in pdf

Greater Paris map with R

I was able to output something like this.

Code for these maps is not clean but is available here.

In this code, there are several steps:

import shapefiles (rgdal)
define Greater Paris area(s)
union of regions with rgal/rgeos
fortify shapefiles to plot polygons with ggplot2
draw rivers and canals as polygons and paths (geoms)

Last map to mimick APUR map can be seen here in pdf.

Using RSelenium to scrape a paginated HTML table

Mon, 12 Apr 2021 08:05:50 +0000

Trying to answer this question on stackoverflow about understat.com scraping I was interested to take RSelenium for a spin.

Few years ago, Selenium and R weren’t particularly friends (Python+Selenium were more used for instance) but it seems to have changed. Package author and rOpenSci works and documentation did it.

After few tries with xpath spellings, I have found RSelenium pretty nice actually. I share here some recipes in this context: when you want to scrape a paginated table that is not purely HTML but a result of embedded javascript execution in browser.

A thing that wans’t particularly easy in Selenium at the beginning was how to extract sub-elements like html table code and not “source page as a whole”. I have used innerHTML attribute for this.

This example explains how emulate clicks can be done to navigate from elements to others in the HTML page, and a more focus point on moving from page to page in a paginated table.

Here is a youtube video with subtitles I have made to illustrate it (no voice).

First step to follow is to download a selenium-server-xxx.jar file here, see this vignette.
and run in the terminal : java -jar selenium-server-standalone-xxx.jar
then you can inspect precisely elements of the HTML page code in browser and go back and forth between RStudio and the emulated browser (right click, inspect element)
at the end use rvest to parse html tables

for instance find an id like league-chemp that we are using with RSelenium:

elem_chemp <- remDr$findElement(using="xpath", value="//*[@id='league-chemp']").

Here is a gist/snippets on github.

Also see the gist embedded below.

# https://stackoverflow.com/q/67021563/10527496


# java -jar selenium-server-standalone-3.9.1.jar 


library(RSelenium)
library(tidyverse)
library(rvest)
library(httr)

remDr <- remoteDriver(
  remoteServerAddr = "localhost",
  port = 4444L, # change port according to terminal 
  browserName = "firefox"
)

remDr$open()
# remDr$getStatus()
remDr$navigate("https://understat.com/league/Ligue_1/")


# find championship table in html via xpath
elem_chemp <- remDr$findElement(using="xpath", value="//*[@id='league-chemp']")

# move to this table via script (optional)
remDr$executeScript("arguments[0].scrollIntoView(true);", args = list(elem_chemp))

# scrape the html table as a tibble
results_champ <- read_html(elem_chemp$getElementAttribute('innerHTML')[[1]]) %>% 
  html_table() %>% .[[1]] %>% 
  slice(-1)


# find player table in html via xpath
elem_player_page_number <- remDr$findElement(using="xpath", value="//*[@id='league-players']")
# find it using html id directly
# elem_player_page_number <- remDr$findElement(using="id", value = "league-players")

# find number of pages of this paginated table
player_page_number <- read_html(elem_player_page_number$getElementAttribute('innerHTML')[[1]]) %>% 
  html_nodes('li.page') %>% 
  html_attr('data-page') %>% 
  as.integer() %>% 
  max()


# move to this table via script
remDr$executeScript("arguments[0].scrollIntoView(true);", args = list(elem_player_page_number))

# or scroll at the bottom of page
# body_b <- remDr$findElement("css", "body")
# body_b$sendKeysToElement(list(key = "end"))
# then you can go to top
# body_b$sendKeysToElement(list(key = "home"))


i <- 4
one_table_at_a_time <- function(i){
  # move on the desired page
  
  elem_click <- remDr$findElement('xpath', 
                                  glue::glue('//*[@id="league-players"]
                                             //*[normalize-space(@data-page) = "{i}"]'))
  remDr$mouseMoveToLocation(webElement = elem_click)
  elem_click$click()
  
  # get the table for 10 players
  elem_player <- remDr$findElement(using="xpath", value="//*[@id='league-players']")
  results_player <- read_html(elem_player$getElementAttribute('innerHTML')[[1]]) %>% 
    html_table()
  
  message('Player table scraped, page ', i)
  results_player %>% 
    .[[1]] %>% 
    filter(!is.na(Apps)) %>% 
    return()
  
}

# one_table_at_a_time(3) %>% View
# loop over pages
resu <- 1:player_page_number %>% purrr::map_df(one_table_at_a_time)

Eyes on RT-PCR tests with echarts and french open data -- COVID-19

Sun, 31 Jan 2021 04:05:50 +0000

Data on COVID-19 screening tests for France ; a shared dashboard with calendar and other heatmaps

Link for the app: https://guillaumepressiat.shinyapps.io/covid-si-dep

This app download daily csv file from french site data.gouv.fr via its api and build heatmaps updated with last day data available.

I have moved from ggplotly to echarts4r package and really nice e_calendar function, see here: https://echarts4r.john-coene.com or here for full docs https://echarts.apache.org/
shinywidgets with pickerInput lets user choose its departments
data are available mouse on hover
by tweeking URL like this, you can choose which ?departments or ?regions are available on startup:

https://guillaumepressiat.shinyapps.io/covid-si-dep/?reg=11|93|32

https://guillaumepressiat.shinyapps.io/covid-si-dep/?dep=36|23|75|29

Data availables are:

Number of positive tests by day (cases), week and departments and age categories
Incidence of positive tests for 100 000 inhabitants

They come from Santé Publique France.

A visualisation is available showing dispersion over age groups by week.

Code for this app is available here.

data / capta : Interroger le concept de donnée à l'heure du HealthDataHub avec une application portée sur l'information médicale

Fri, 23 Oct 2020 00:01:01 +0000

La tentation de l’idéalisme vient peut-être du mot même de données qui décrit aussi mal que possible ce sur quoi s’appliquent les capacités cognitives ordinaires des érudits, des savants et des intellectuels. Il faudrait remplacer ce terme par celui, beaucoup plus réaliste, d’obtenues et parler par conséquent de bases d’obtenues, de sublata plutôt que de data.¹

Introduction

L’usage courant du terme de donnée nous amène à l’interroger comme concept (et percept par là-même). C’est un préliminaire pour pouvoir interroger tant bien les données elles-mêmes que les différents processus et acteurs amenant à les obtenir. Si un objectif est défini, celui de trouver dans toutes les informations de santé disponibles des réponses à des questions, ainsi que de soulever de nouvelles questions, le moyen d’atteindre cet objectif reste à concevoir : comment respecter la donnée, et, avec elle, respecter les différents acteurs qui s’y investissent ?

Est-on bien sûr que l’analyse des données tient compte de la complexité des processus et du crédit des acteurs qui les réalisent ?

Contexte

En période de crise sanitaire, les hôpitaux ont été en première ligne pour affronter le virus. En parallèle, les pouvoirs publics ont invité les hôpitaux à produire une donnée au fil de l’eau (transmissions hebdomadaires) pour alimenter le nouveau HealthDataHub (HDH).

Les louanges sur la capacité du pays -et des territoires- à trouver des solutions sans l’aide de l’État ont fleuri lors de cette crise, mais l’arrêté² précisant que les données devraient remonter des hôpitaux vers le HDH est passé par un canal on ne peut plus central. Et comme souvent, l’information ensuite enchevêtrée dans les strates administratives ne circule pas : elle sédimente. Il aura donc fallu la chercher partout. Subtile l’efficacité et la clarté en période de crise. (On n’oubliera pas qu’en parallèle les hôpitaux répondaient déjà au relevé pluri-quotidien des patients COVID hospitalisés / en réanimation / décédés ou sortis, à destination des ARS - Santé Publique France - etc.).

Mais, c’est bien normal de vouloir le plus de données possible en période de crise pour avoir toutes les chances de mieux comprendre ce virus. Cela dit les producteurs de données ne sont pas du tout associés ni considérés en ce qui concerne les nouvelles modalités d’analyse de ces données. Pour adopter une formulation organiciste, on déconnecte la tête du corps, et ce n’est pas une bonne chose pour la suite. Il faudrait relier les hôpitaux au HealthDataHub, comme son nom l’indique d’ailleurs, et pas uniquement les données des hôpitaux. À l’échelle des grands hôpitaux, c’est ce qui est réalisé avec les entrepôts de données de santé : l’organisation à cette échelle peut permettre de créer le lien entre les métiers de la donnée et les métiers du soin.

Plus pragmatiquement, la demande de remontées hebdomadaires donne l’impression que la donnée coule de l’hôpital comme d’une source. En pleine crise sanitaire comme en temps normal, ce n’est pas le cas. Cette impression ne s’atténue guère quand le ministre de la santé évoque la perte de temps pour un médecin de saisir ces informations (l’avenir du codage³), alors qu’en même temps, il est demandé aux hôpitaux de fournir ces informations à un rythme accéléré ! Mais qui sont ces médecins qui codent ?

Autre point délicat : le format des données hospitalières (PMSI, voir plus bas), quasiment stable depuis une dizaine d’années est bousculé pour répondre à cette demande du HDH. Il l’est également pour tenir compte des exigences de la CNIL (niveau d’anonymisation des informations patients⁴), erreur / hasard de calendrier. En pleine crise, donc, on déstabilise les systèmes d’informations hospitaliers s’appuyant sur ces données.

Données ou obtenues ?

Mais revenons sur le concept de donnée. Je reprends ici des éléments d’un article d’Arthur Perret dont le paragraphe Épistémologie des données mérite, je crois, le détour.

De la mesure au big data

Suite au développement des expérimentations scientifiques et de l’instrumentation allant avec, le terme donnée apparait au XVIIème siècle.

Données, adj. pris subst. terme de Mathématique, qui signifie certaines choses ou quantités, qu’on suppose être données ou connues, & dont on se sert pour en trouver d’autres qui sont inconnues, & que l’on cherche. Un problème ou une question renferme en général deux sortes de grandeurs, les données & les cherchées, data & quæsita.⁵

Jusque-là, on est en plein dans notre contexte, le souhait d’avoir l’éventail du connu pour trouver, dans les replis, ce qui est pour l’instant inconnu, ce qui reste à chercher et à comprendre dans les données.

The word “data” is commonly used to refer to records or recordings, statistical observations, collections of evidence⁶

Actuellement, nous vivons dans un monde où le terme big data est souvent utilisé, mais là encore, sans forcément bien connaître ni pouvoir comprendre quelles sont les données qui sont derrières.

Obtenues

Dans les années 1990, les sociologues des sciences ont critiqué l’usage du mot « donnée » pour désigner des objets en réalité construits, arrachés au terrain au prix d’un temps et d’efforts parfois considérables. Le mot « obtenue » est notamment suggéré par Bruno Latour comme une alternative souhaitable.⁷

Bruno Latour retourne brillamment ce qu’est une donnée. C’est très intéressant.

La tentation de l’idéalisme vient peut-être du mot même de données qui décrit aussi mal que possible ce sur quoi s’appliquent les capacités cognitives ordinaires des érudits, des savants et des intellectuels. Il faudrait remplacer ce terme par celui, beaucoup plus réaliste, d’obtenues et parler par conséquent de bases d’obtenues, de sublata plutôt que de data.¹

Ce qui est derrière cette notion d’obtenues se voit complété dans le terme “capta”, Johanna Drucker :

Croire que les données sont intrinsèquement quantitatives — évidentes, neutres sur le plan des valeurs et indépendantes de l’observateur — exclut la possibilité de les concevoir comme qualitatives, co-dépendamment constituées — en d’autres termes, de reconnaître que data sont des captas […] Je suggère que nous repensions fondamentalement les données comme des captas en termes d’ambiguïté plutôt que de certitude, et que nous trouvions des moyens d’exprimer graphiquement la complexité de l’interprétation.⁸, [trad. libre]⁷

Dans les deux paragraphes suivants, deux temporalités sont distinguées pour inviter à réfléchir à la pluri-disciplinarité dans les (grandes) données et leur analyse. Dans le premier, on s’interroge, en amont, sur les processus et les acteurs produisant la donnée, on y aborde l’exemple de l’information médicale avec le codage des diagnostics ; dans le deuxième, en aval, aux modalités d’analyses de la donnée comme objet fini, et au travers d’elles les différentes perceptions de la donnée.

Processus et acteurs de la donnée

Les processus de production et les acteurs de la donnée

Interroger le concept de donnée nous amène à réfléchir sur les processus et les acteurs de la donnée :

quels processus permettent d’aboutir à l’obtention des données ?
quelle est la temporalité, l’ordonnancement de ces processus ?
la complexité des processus n’induit-elle pas une complexité de la donnée ? Quels impacts ces processus ont-ils sur la donnée ? Quel est le stade au bout duquel on n’interroge plus le concept de données mais celui d’artefact ?
quels acteurs sont en compétence sur ces processus, lorsque ceux-ci ne sont pas automatiques ?
quelle part d’expertise, retenue par ces “producteurs” de la donnée, n’est pas livrée dans la donnée elle-même ?

Comment assurer par la pluri-disciplinarité la garantie que l’ensemble des acteurs rassemblés autour de ces données partagent une connaissance commune de l’ensemble des processus, de la production à l’analyse ? Autrement dit, prudence : est-on bien sûr que l’analyse des données tient compte de la complexité des processus et du crédit des acteurs qui les réalisent ?

Dans cette étape, on parle de l’observation de processus et d’acteurs, et on s’inscrit avec l’observation dans une pratique scientifique, cette étape modeste de la science où l’on regarde comment sont les choses. Une fois ces processus bien décrits, il deviendrait même tentant de leur appliquer le critère de reproductibilité !

Pour rentrer dans le sujet par un exemple, on propose ici le codage des diagnostics pour les hospitalisations.

Le diagnostic, une donnée de l’hôpital

Lorsqu’un patient est hospitalisé, il débute un épisode de soins qui amène à la production de nombreuses données (données administratives du patient, description de la prise en charge, actes chirurgicaux, diagnostics des pathologies du patient, documents médicaux rédigés par les médecins et le personnel infirmier, médicaments administrés, couts de prises en charge pour l’établissement, données physiologiques, de laboratoire d’analyse).

Nous nous concentrerons ici sur la fabrication des diagnostics décrivant les pathologies dont le patient est atteint.

Du compte rendu d’hospitalisation au diagnostic

Ces diagnostics appartiennent de manière normative à une classification internationale des maladies (CIM-10) basée sur des codes alpha-numériques : pour faire très simple, ‘E66’ signifie par exemple “Obésité”. C’est un code parmi d’autres qui décrit le motif de prise en charge du patient, ses pathologies associées. Ce diagnostic précis, est codé avec 6 caractères au maximum, au sein d’un système robuste, le programme de médicalisation des systèmes d’information (PMSI) ; il alimente régulièrement les bases de données nationales de santé.

Ces codes peuvent être “codés” par le médecin ayant pris en charge le patient, en parallèle de la rédaction d’un compte rendu d’hospitalisation ou d’une lettre de sortie, envoyée au médecin traitant.
Ils peuvent aussi être “codés” par des experts du codage, au sein d’un département spécifique dans l’hôpital : le DIM. Les médecins d’information médicale (MIM) associés à de plus nombreux techniciens (TIM) “convertissent” ce qui a été inscrit dans le compte rendu d’hospitalisation par le médecin ayant pris en charge le patient.
Ils peuvent aussi être codés de manière automatique ou semi-automatique en fonction des prises en charge du patient (certaines prises en charge ambulatoires)

On le voit sur cet exemple, la donnée “diagnostic de la maladie” et les pathologies associées du patient peuvent être produites de différentes manières, avec un nombre d’acteurs et une temporalité différente. Il n’y a rien de standard dans cette production qui peut varier beaucoup plus selon la pathologie du patient et ceux qui le prennent en charge.

L’information qui en découle apparait normée, car elle se réfère à une classification, mais elle résulte le plus souvent de la lecture et de l’analyse forcément subjective d’au moins un document médical par une personne, et cela pour chaque patient.⁹

Synthèse

Cette “donnée” est donc loin de couler comme -et d’être aussi claire que- l’eau d’une source. Elle est obtenue, parfois difficilement.

Voici un exemple des processus qui fabriquent les données et leurs artefacts dans les hôpitaux. À l’heure où la moissonneuse batteuse à données de santé (HDH) va se mettre à récolter et, probablement, mélanger des blés de toutes sortes, de toutes qualités.

La coopérative à données aura des outils intéressants (modèles statistiques, apprentissage profond) pour mesurer la qualité des données, les classifier en différents types de grains, et trouver dans les replis de données massives des réponses à des questions, de nouvelles questions.

Ce qui n’apparaitra pas dans ces replis, c’est la connaissance de terroir du paysan qui travaille pour obtenir et composer cette donnée au quotidien dans l’hôpital. Il aura pourtant bien coopéré.

On développe dans le paragraphe suivant une réflexion sur l’aval : les modalités d’analyses de ces obtenues.

Perspectives de la donnée

La donnée et le kaléidoscope, l’endroit de nos subjectivités

L’analyse de données a ceci de proche de l’analyse mathématique qu’elle joue avec les échelles. Il y a l’infiniment petit d’une mesure, d’une information, d’un “cas particulier” -le grain de la donnée, et l’infiniment grand de l’ensemble. L’infini exprime ici de manière exagérée la combinaison des intervalles finis qui supportent la donnée dans des dimensions et disciplines nombreuses. Le terme d’“infini” accroche l’esprit car on sent que l’on pourrait s’y perdre¹⁰.

Imbriqués dans différentes échelles successives, les processus de production de la donnée se devinent. Si l’on joue comme on le fait en tournant un kaléidoscope, un voyage imagé dans les données, il y aura autant de temps d’arrêts, où le niveau de détail apparait plus net, que de dimensions subjectives et d’expertises requises pour analyser les données. À chaque temps d’arrêt du kaléidoscope, un acteur de la donnée retrouve l’objet de son travail, la netteté dans laquelle il reconnaît une réalité, une familiarité. Il voit net sur sa discipline, mais peut-être un peu flou ailleurs. C’est une expertise qui prend le pouvoir. Ou, pour remplacer l’expertise par un terme moins exclusif, la maîtrise. La formule nous aide : sans elle, la puissance n’est rien. Ou on accélère et tout va plus vite, ce qui est perçu n’est que flou. Ou on élabore en prenant le temps pour éviter ce flou, la maîtrise serait de savoir ce que l’on veut trouver avant de commencer à chercher.

Cette métaphore du kaléidoscope fonctionne aussi pour le partage démocratique. Savant ou non, le constat, c’est que chacun est ancré dans sa subjectivité : il n’y a pas plus de partage de pouvoir qu’il n’existe d’objectivité si pour chacun l’échelle du zoom est figée. Comme dirait l’autre : “il ne faut pas voir les choses par le petit bout de la lorgnette”.

Changer d’angle de vue, de focale, critiquer sa propre position à l’aide d’une nouvelle perspective -celle d’un autre acteur de la donnée par exemple, faciliterait la mise en œuvre d’un partage de connaissances et permettrait ainsi de conquérir le pouvoir complexe qui est dans les données.

Il faut donc inviter tous ces acteurs à se rassembler autour des données, afin que celles-ci fassent sens.

Tout ceci repose bien sur l’idée que ce kaléidoscope est dans les mains de tous, avec un objectif commun.

Le problème actuel, c’est que chacun est atomisé dans sa fonction, producteur d’un type d’informations à temps plein. Chacun sa lorgnette. Rien n’a été prévu pour que l’objectif soit partagé. Pas de regards croisés. La donnée semble encore trop considérée comme pur objet informatique à collecter et forer, et non comme le fruit d’une connaissance et d’une expertise qui serait pourtant utile à l’analyse, comme aux travaux d’intelligence artificielle, par exemple.

Conclusion

L’idée était de remettre en perspective ce qu’est une donnée -tantôt produite, tantôt obtenue, avec la volonté de mettre en lumière le travail d’équipes dans les hôpitaux, grâce à qui toutes ces données sont disponibles. Et de bien avoir en tête que selon la perspective de l’individu y accédant, la donnée est interprétée de bien différentes manières.

Ce qui apparait avec ce HealthDataHub, c’est l’œil du pouvoir : mais il faut saisir le prisme des données dans tous ses sens.

N’oublions pas la phrase d’Alain Desrosières selon laquelle faire des statistiques, c’est faire des choses qui tiennent. Il est frappant de lire les articles exposant les principes schématiques de la data science : prendre des données du terrain, travailler à les modéliser, apprendre et finalement faire un retour à ceux qui récoltent la donnée avec comme finalité d’un cycle l’amélioration du modèle. C’est-à-dire, probablement, l’essence même du travail statistique. Et l’on peut aussi inscrire dans ce cycle vertueux l’amélioration de la qualité des données.

D’où l’intérêt que les hôpitaux participent aux travaux de cette coopérative à données.

Que nous gardions bien en tête que la suite menée au sein du HealthDataHub est rendue possible parce que la donnée a été obtenue.

Perspective avec contre-jour : si cette donnée n’est pas un don du ciel, n’attendons pas le contre-don du ciel.

Guillaume Pressiat

Latour, B., « Pensée retenue, pensée distribuée », 2007, p. 609. ↩ ↩²
Arrêté du 21 avril 2020 complétant l’arrêté du 23 mars 2020 prescrivant les mesures d’organisation et de fonctionnement du système de santé nécessaires pour faire face à l’épidémie de covid-19 dans le cadre de l’état d’urgence sanitaire ↩
https://www.hospimedia.fr/actualite/articles/20200615-gestion-les-medecins-dim-rappellent-l-utilite-du ↩
https://www.atih.sante.fr/mesures-de-securite-de-pseudonymisation-des-logiciels-pmsi ↩
Encyclopédie de Diderot et D’Alembert. ↩
Zins, C., « Conceptual approaches for defining data, information, and knowledge », Février 2007. Journal of the American Society for Information Science and Technology, 58(4):479-493. DOI: 10.1002/asi.20508 ↩
Perret, A. & Le Deuff, O. « Documentarité et données, instrumentation d’un concept ». 12ème Colloque international d’ISKO-France : Données et mégadonnées ouvertes en SHS : de nouveaux enjeux pour l’état et l’organisation des connaissances ? https://hal.archives-ouvertes.fr/hal-02307039. ↩ ↩²
Drucker J., Humanities Approaches to Graphical Display. Digital Humanities Quarterly [en ligne], 2011. Vol. 5, n° 1. Disponible à l’adresse : http://digitalhumanities.org/dhq/vol/5/1/000091/000091.html. ↩
Cette logique structurant l’information hospitalière représente un investissement humain et logiciel pour les hôpitaux réellement conséquent, elle s’inscrit dans le PMSI et a depuis 2008 pour principale finalité le financement des hôpitaux par la tarification à l’activité -et non pas la recherche, ni l’épidémiologie, ni la lutte contre le COVID - les hôpitaux cherchant à équilibrer leurs finances dans ce système (garder le navire à flot). ↩
C’est désormais un océan de données dans lequel nous vivons, un véritable enjeu qu’il ne s’agit pas d’aborder ici : on ne fait que pressentir les conséquences de notre dépendance à la donnée. Y a t-il un sens à tout cela, quelles seront les conséquences politiques, énergétiques et sociales d’une fuite en avant dans l’âpre monde du tout-donnée (smart-cities, etc.) ? ↩

Creative commons in the meantime

Sun, 16 Aug 2020 05:05:50 +0000

Just a little post about sharing code and skills with the unknown.

After posting about covidfrance app, I exchanged with github users wanting to reproduce the app for their country..

I just want to say here that it was really a pleasure to exchange with people around the world like this. It was nice to share skills and to learn new things with problematics on new data.

No matter the manner (yes GitHub is Microsoft), peoples want to share and learn things. For what it’s worth it works. After all I’ve learned from r-bloggers and GitHub, it just seems natural to “return something”.

Eyes on PCR tests with french open data -- COVID-19

Sun, 16 Aug 2020 04:05:50 +0000

Link for the app: https://guillaumepressiat.shinyapps.io/covid-si-dep

This app download daily csv file from french site data.gouv.fr via its api and build heatmaps updated with last day data available.

ggplot2 with geom_tile to plot heatmaps and interactivity with plotly
shinywidgets with pickerInput to let user choose its departments
by tweeking URL like this, you can choose which ?departments or ?regions are available on startup:

https://guillaumepressiat.shinyapps.io/covid-si-dep/?reg=11|93|32

https://guillaumepressiat.shinyapps.io/covid-si-dep/?dep=36|23|75|29

Data availables are:

Number of positive tests by day, week and departments
Incidence of positive tests for 100 000 inhabitants

The idea is to follow horizontally tendancies for each department and to see easily which ones have a particular kinetic. You can also compare departments with incidence heatmap lower on screen. Whereas in covidfrance app, we see indicators day by day in animation, here we want to see time and epidemic effects in the same frame.

At day scale we can see weekdays and week-ends appears in data.

Code for this app is quick code available here.

Like the precedent app, this one is limited on few indicators to keep user mind focused (one app, one goal). Then first advantage is that app will be simple to update if necessary (no nebulous code), not a bad thing in these times.

Once again it’s quite a good thing to have these data available as open data (Santé Publique France data) for people and journalists. Source is here.

Eyes on first wave with french open data -- COVID-19

Fri, 22 May 2020 04:05:50 +0000

Covidfrance app was first developped beginning of April for family, friends (and myself) to automatically know every day how many cases there are in each department where they live, daily along this crisis.

This app download daily csv file from french site data.gouv.fr via its api and build the map updated with last day data.

Scientific colour maps palettes are used with scico package
Population’s ratio statistics are enabled with a switch to have both absolute and relative measures of epidemy.
Overlay of json layers is used with full opacity to render time progression visible
departments shapes are simplified and smoothed with smoothr (Chaikin method) and rmapshaper, really nice packages
to let the map prints each day on animated mode along the time gauge, a delay of 1.7 second is set. It’s a bit long but there are ~ 100 departments to look up each day! (“Almost 2 sec per day, not so much”).

Data availables are:

Hospitalisés: people in hospital on day i
En réanimation: people in intensive care unit on day i
Retours à domicile (cumulés): cumul of returned at home until the day i
Décès (cumulés): cumul of deceases at hospital until the day i

This open data csv is a good way to share data across data-focus people and journalists.

Then an app like this seems a good way to make data more accessible and eye friendly for people, with a geographical and “kinetic” approach.

Code for this app is quick code available here.

Partage et formation à R, au tidyverse : for free - 2

Wed, 20 May 2020 08:35:50 +0000

Des ressources pour découvrir R et s’entraîner

Suite du précédent post sur une communauté R et les formations R payantes, voir ici pour info.

Tutoriels

Ci-dessous, j’oriente ici vers quelques liens, nouveaux fruits des projets qui ont rendu et rendent possible le package pmeasyr.

learnr

À l’origine desquels, on trouve, entre autres, si ce n’est R lui-même, les travaux menés par RStudio.

RStudio a travaillé à l’intégration d’une fonctionnalité “tutoriels”.

learnr est un package qui permet de créer des tutoriels, des questionnaires, qui répondent d’une manière assez unique à la question : comment apprendre ?
des exemples de tutoriels interactifs sont disponibles en ligne
la prochaine version de RStudio prévoit l’intégration de tels tutoriels, ce qui va encore ajouter une dimension pertinente à ce logiciel
ces tutoriels seront à l’avenir intégrable dans chaque package, et permettront de se former au fil de leur utilisation

https://rstudio.github.io/learnr/

Installer R, RStudio, et démarrer

C’est l’étape avec laquelle l’ensemble R + RStudio, tout devient possible !

https://learnr-examples.shinyapps.io/ex-setup-r/

Découvrir les principes de la manipulation de données avec R / dplyr

C’est l’étape où l’on prend conscience que R peut rendre les choses faciles, en peu de verbes :

filter, mutate, arrange, summarise, group_by

Ces tutoriels sont interactifs.

Les bases : https://learnr-examples.shinyapps.io/ex-data-basics/

Synthétiser les données : https://learnr-examples.shinyapps.io/ex-data-summarise/

Filtrer les données : https://learnr-examples.shinyapps.io/ex-data-filter/

Ajouter des colonnes : https://learnr-examples.shinyapps.io/ex-data-mutate/

Ce ne sont que des exemples qui invitent à produire des tutoriels plus détaillés.

R4ds

On en apprend plus en se référant au livre R for data science

analyse-R

Vous trouverez ici une documentation en français qui regroupe l’essentiel pour démarrer et consolider sa connaissance de R :

https://larmarange.github.io/analyse-R/

Documents pmeasyr

https://guillaumepressiat.github.io/pmeasyr-book/

La suite sera certainement l’intégration de tutoriels de type learnr dans pmeasyr et nomensland.

Partage et formation à R, au tidyverse : for free - 1

Wed, 20 May 2020 08:30:50 +0000

Un propos sur la communauté R & PMSI

Propos rédigés avant la crise COVID-19, publication volontairement à retardement

Sur une communauté R & PMSI

R semble désormais être un outil reconnu pour le PMSI, un blog en fait même la promotion, et propose une formation payante.
Il est bon de souligner qu’il existe, déjà, des ressources intéressantes en ligne.

Si certains profitent des projets open source comme d’une poule aux oeufs d’oR pour proposer des prestations payantes (formations, mais surtout logiciels), c’est là au moins une publicité, il faut le reconnaître, pour R.

Il fera tout de même du bien de faire publicité aux travaux qui restent ouverts à tous, c’est l’objet du post suivant.

About a blog…

C’est étonnant de vanter la “gratuité” d’un outil pour en construire un autre avec, payant. C’est qu’il n’y a pas de frontière entre ce “gratuit” et le payant. En réalité, R est un logiciel libre (mais on doit dire gratuit, lapsus, quand ce logiciel permet le fin du fin : faire l’inverse).

Pour R et le PMSI, c’est toujours un plaisir de concourir au profit des autres¹. Que les personnes qui veulent profiter du “gratuit” le fassent au moins avec décence. S’il y a des mots qu’on utilise, comme je l’ai fait ici, pour faire la promotion de R, les lire de la bouche d’un autre a déclenché chez moi un réflexe. Je ne signifie pas que des idées appartiennent à quelqu’un, bien au contraire. Ces idées étaient le fruit d’un groupe d’utilisateurs R. Il y une nette différence entre payer chacun pour un outil et mettre en commmun pmeasyr. Il n’y a pas de règles, c’est ainsi. Je ne parlerais pas des idées ou des développements faits en R dans l’outil en question : comme il n’est pas open-source, je ne peux rien en dire.

Bref, si on se contente d’être soft, cela peut être vu comme un relais dans la promotion de R pour le PMSI.

J’aime penser, comme cela avait été initié à l’AP-HP, qu’une communauté hospitalière d’utilisateurs de R pour le PMSI (et plus largement données de santé) peut s’organiser pour partager les méthodes, sans faire une fois de plus appel à un intervenant “extérieur”. Celui qu’on attendrait toujours, comme un messie, au regard tellement neuf.

Que la balle retourne à l’envoyeur n’est pas tellement mon objectif, travailler en commun s’avérant plutôt être un sport collectif.

M’enfin, que les gens apprennent comme ils préfèrent tant qu’ils le font avec envie !

La suite : publicité aux travaux qui restent ouverts à tous, c’est l’objet du post suivant.

Chat pmeasyr

Pour ceux qui seraient intéréssés par le partage, j’ai initié un chat en ligne pour partager les problèmes, échanger les idées, s’entraider et répondre aux questions autour de R et du PMSI. Vous pouvez me contacter par mail pour y être intégrés. L’adresse pour cela se trouve ici.

Cela peut aussi simplement permettre de faire un retour sur vos utilisations de pmeasyr.

sans même avoir été mis au courant, encore mieux. ↩

Dimonade

Sat, 15 Feb 2020 08:15:50 +0000

Accéder aux nomenclatures et classifications du PMSI sans sourciller

Application dimonade

Dans le PMSI, il y a des nomenclatures et classifications, dimonade regroupe certaines d’entre elles (CCAM, CIM, GHM, GHS).

L’objectif : essayer de ne pas se sentir dominé par la finesse des classifications, trouver facilement le niveau d’agrégat adéquat pour répondre à la question posée. Prendre la classification par les cornes, en quelque sorte.

Et ne pas accumuler les manipulations de nomenclatures dans des tableurs…

dplyr and Oracle database with odbc on windows

Tue, 12 Nov 2019 12:05:50 +0000

RStudio makes Oracle accessibility from R easier via odbc and connections Pane¹.
Personally, I find it’s not so easy.
As it finally works for me, I will detail some snippets here.

After tens of try it seems good to share some tricks². This blog post is also a notepad for me.

Oracle and R configuration is a step where we potentially waste a lot of time.

Many things can cause oracle and R not to work at all:

it depends on which client is installed (32b, 64b ?)
wether odbc driver is correctly installed or not
you have to dissect tnsnames.ora
investigate on many ORA error’s
maybe try to clean install Oracle client

Often ROracle is used and it works well, sometimes it doesn’t (some oci.dll not found³, etc.). But it doesn’t work with dplyr/dbplyr at the moment.

After several years with ROracle, I’m happy to have both possibilities for query writing and collecting (SQL, and now dplyr)

Here we are:

RStudio connection Pane

From connection Pane we take Oracle odbc driver name, we have two here for two Oracle client versions:

And then:

We now have a big component of the connection string.

32b or 64b

If your Oracle client is 32bit, you have to switch to R 32bits, otherwhise it doesn’t work (at least for me).

Connection string

Then stackoverflow history helped me⁴ to structure the entire string:

library(odbc)
library(dplyr)
library(dbplyr)
library(lubridate)
 
my_oracle <- dbConnect(odbc::odbc(), 
                       .connection_string = "Driver={Oracle dans OraClient10g_home1};DBQ=host:port/db_name;UID=woo;PWD=hoo", 
                       timeout = 10)

You will find all these informations in tnsnames.ora. Port is probably 1521.

Some dplyr/dbplyr statements

Simple one

dplyr::tbl(my_oracle, dbplyr::in_schema('SCHEMA_ONE', 'TB_ONE'))

<SQL>
SELECT *
FROM SCHEMA_ONE.TB_ONE

dplyr and dblink

If you have another oracle database with dblinks it may also works like this:

dplyr::tbl(my_oracle, dbplyr::in_schema('SCHEMA_B', 'TC_TWO@MYDBTWOLINK'))

<SQL>
SELECT *
FROM SCHEMA_B.TC_TWO@MYDBTWOLINK

List dblinks

DBI::dbGetQuery(my_oracle, "SELECT * FROM ALL_DB_LINKS")

<SQL>
SELECT *
FROM ALL_DB_LINKS

Catalog of all columns⁵

<SQL>
SELECT *
FROM ALL_TAB_COLUMNS

Decomposing the connection string

In order to ask for password, we split the connection parts:

library(odbc)
library(dplyr)
library(dbplyr)
library(lubridate)
 
my_oracle <- dbConnect(odbc::odbc(),
                       Driver = "Oracle dans OraClient10g_home1",
                       DBQ = "host:port/db_name",
                       SVC = "DB_SCHEMA", # schema when connection opens
                       UID = "woo",
                       PWD = "hoo")

And then:

library(odbc)
library(dplyr)
library(dbplyr)
library(lubridate)
 
my_oracle <- dbConnect(odbc::odbc(),
                       Driver = "Oracle dans OraClient10g_home1",
                       DBQ = "host:port/db_name",
                       SVC = "DB_SCHEMA", 
                       UID = rstudioapi::askForPassword('woo (username)'),
                       PWD = rstudioapi::askForPassword('Open, Sesame (password)'))

RStudio documentation for Oracle connections: https://db.rstudio.com/databases/oracle/ ↩
see here for a readme in a repo on github: https://github.com/GuillaumePressiat/oracle_odbc_connection_template_for_R ↩
see here for ROracle difficulties: https://technology.amis.nl/2017/08/23/r-and-the-oracle-database-using-dplyr-dbplyr-with-roracle-on-windows-10/ ↩
how to make a connection string for oracle that includes hostname, instance name, user id, password using system.data.oracleclient? stackoverflow ↩
for Oracle catalogs, see here: https://docs.oracle.com/pls/db92/db92.catalog_views?remark=homepage ↩

A duck. Giving a look at DuckDB since MonetDBLite was removed from CRAN

Sat, 26 Oct 2019 12:05:50 +0000

You may know that MonetDBLite was removed from CRAN.
DuckDB comming up.

Breaking change

> install.packages('MonetDBLite')
Warning in install.packages :
  package ‘MonetDBLite’ is not available (for R version 3.6.1)

People who based their works on MonetDBLite may ask what happened, what to do. Not to play a risky game with database and tools choices for future works… (“It’s really fast but we may waste some time if we have to replace it by another solution”).

It’s the game with open source. Remember big changes in dplyr 0.7.
Sometimes we want better tools, and most of the time they become better. It’s really great.
And sometimes we don’t have time and energy to adapt our work to tools that became better in a too iterative way. Or in a too subjective way.
We want it to work, not break.
Keeping code as simple as possible (and avoid nebulous dependencies, so, tidy?) is one of the key point.
Stocking data in a database is another one.

All that we can say is that “we’re walking on works in progress”. Like number of eggshells, more works in progress here probably means more breaking changes.

Works in progress for packages, also for (embedded) databases!

From Monet to Duck

MonetDBLite philosophy is to be like a “very very fast SQLite”. But it’s time for change (or it seems to be).
Then we can thanks MonetDBLite developers as it was a nice adventure to play/work with MonetDB speed!
As a question, is there another person, some volunteers, possibilities to maintain MonetDBLite (somewhere a nice tool)?
There are not so many informations for the moment about what happened and that’s why I write this post.

Here, I read that they are now working on a new solution, under MIT License, named DuckDB, see here for more details.

As I’m just a R user and haven’t collaborate to the project, I would just say for short: DuckDB takes good parts from SQLite and PostGreSQL (Parser), see here for complete list, it looks promising. As in MonetDB, philosophy is focused on columns and speed. And dates for instance are handled correctly, not having to convert them in “ISO-8601 - like” character strings.

It can be called from C/C++, Python and R.

Here is a post about python binding.

I also put a link at the bottom of this page which give some explanations about the name of this new tool and DuckDB developers point’s of view about data manipulation and storage¹.

Beginning with duckDB in R

Create / connect to the db

# remotes::install_github("cwida/duckdb/tools/rpkg", build = FALSE)

library(duckdb)
library(dplyr)
library(DBI)

# Create or connect to the db
con_duck <- dbConnect(duckdb::duckdb(), "~/Documents/data/duckdb/my_first.duckdb")
#con <- dbConnect(duckdb::duckdb(), ":memory:")

con_duck

<duckdb_connection bae30 dbdir='/Users/guillaumepressiat/Documents/data/duckdb/my_first.duckdb' database_ref=04e40>

iris

dbWriteTable(con_duck, "iris", iris)
tbl(con, 'iris')

Put some rows and columns in db

> dim(nycflights13::flights)
[1] 336776     19
> object.size(nycflights13::flights) %>% format(units = "Mb")
[1] "38.8 Mb"

Sampling it to get more rows, then duplicating columns, two time.

# Sample to get bigger data.frame
df_test <- nycflights13::flights %>% 
  sample_n(2e6, replace = TRUE) %>% 
  bind_cols(., rename_all(., function(x){paste0(x, '_bind_cols')})) %>% 
  bind_cols(., rename_all(., function(x){paste0(x, '_bind_cols_bis')}))

> dim(df_test)
[1] 2000000      76
> object.size(df_test) %>% format(units = "Mb")
[1] "916.4 Mb"

Write in db

tictoc::tic()
dbWriteTable(con_duck, "df_test", df_test)
tictoc::toc()

It take some times compared to MonetDBLite (no benchmark here, I just run this several times and it was consistent).

# DuckDB      : 23.251 sec elapsed
# SQLite      : 20.23 sec elapsed
# MonetDBLite : 8.4 sec elapsed

The three are pretty fast.
Most importantly if queries are fast, and they are, most of the time we’re allwright.

I want to say here that’s for now it’s a work in progress, we have to wait more communication from DuckDB developers. I just write this to share the news.

Glimpse

> tbl(con_duck, 'df_test') %>% glimpse()
Observations: ??
Variables: 76
Database: duckdb_connection
$ year                                   <int> 2013, 2013, 2013, 2013, 2013, 2013, 2013, 2013, 2013, 2013, 2013, 2013,…
$ month                                  <int> 11, 10, 3, 5, 12, 9, 7, 3, 9, 4, 7, 6, 1, 1, 9, 10, 9, 8, 4, 1, 4, 9, 6…
$ day                                    <int> 29, 7, 1, 2, 18, 18, 20, 7, 15, 25, 22, 1, 29, 18, 30, 27, 27, 22, 19, …
$ dep_time                               <int> 1608, 2218, 1920, NA, 1506, 1917, 1034, 655, 1039, 1752, 2018, 1732, 82…
$ sched_dep_time                         <int> 1612, 2127, 1920, 2159, 1500, 1900, 1030, 700, 1045, 1720, 1629, 1728, …
$ dep_delay                              <dbl> -4, 51, 0, NA, 6, 17, 4, -5, -6, 32, 229, 4, -9, -3, -4, -3, 9, 38, 34,…
$ arr_time                               <int> 1904, 2321, 2102, NA, 1806, 2142, 1337, 938, 1307, 2103, 2314, 1934, 11…
$ sched_arr_time                         <int> 1920, 2237, 2116, 2326, 1806, 2131, 1345, 958, 1313, 2025, 1927, 2011, …
$ arr_delay                              <dbl> -16, 44, -14, NA, 0, 11, -8, -20, -6, 38, 227, -37, -16, -12, -10, -39,…
$ carrier                                <chr> "UA", "EV", "9E", "UA", "DL", "DL", "VX", "UA", "UA", "AA", "B6", "UA",…
$ flight                                 <int> 1242, 4372, 3525, 424, 2181, 2454, 187, 1627, 1409, 695, 1161, 457, 717…
$ tailnum                                <chr> "N24211", "N13994", "N910XJ", NA, "N329NB", "N3749D", "N530VA", "N37281…
$ origin                                 <chr> "EWR", "EWR", "JFK", "EWR", "LGA", "JFK", "EWR", "EWR", "EWR", "JFK", "…
$ dest                                   <chr> "FLL", "DCA", "ORD", "BOS", "MCO", "DEN", "SFO", "PBI", "LAS", "AUS", "…
$ air_time                               <dbl> 155, 42, 116, NA, 131, 217, 346, 134, 301, 230, 153, 276, 217, 83, 36, …
$ distance                               <dbl> 1065, 199, 740, 200, 950, 1626, 2565, 1023, 2227, 1521, 1035, 2133, 138…
$ hour                                   <dbl> 16, 21, 19, 21, 15, 19, 10, 7, 10, 17, 16, 17, 8, 14, 8, 19, 15, 16, 20…
$ minute                                 <dbl> 12, 27, 20, 59, 0, 0, 30, 0, 45, 20, 29, 28, 35, 50, 25, 0, 35, 55, 0, …
$ time_hour                              <dttm> 2013-11-29 21:00:00, 2013-10-08 01:00:00, 2013-03-02 00:00:00, 2013-05…
..                                                                                                                     
..                                                                                                                     
..                                                                                                                     
$ minute_bind_cols                       <dbl> 12, 27, 20, 59, 0, 0, 30, 0, 45, 20, 29, 28, 35, 50, 25, 0, 35, 55, 0, …
$ time_hour_bind_cols                    <dttm> 2013-11-29 21:00:00, 2013-10-08 01:00:00, 2013-03-02 00:00:00, 2013-05…
$ year_bind_cols_bis                     <int> 2013, 2013, 2013, 2013, 2013, 2013, 2013, 2013, 2013, 2013, 2013, 2013,…
$ month_bind_cols_bis                    <int> 11, 10, 3, 5, 12, 9, 7, 3, 9, 4, 7, 6, 1, 1, 9, 10, 9, 8, 4, 1, 4, 9, 6…
$ day_bind_cols_bis                      <int> 29, 7, 1, 2, 18, 18, 20, 7, 15, 25, 22, 1, 29, 18, 30, 27, 27, 22, 19, …
..                                                                                                                     
..                                                                                                                     
..                                                                                                                     
$ distance_bind_cols_bind_cols_bis       <dbl> 1065, 199, 740, 200, 950, 1626, 2565, 1023, 2227, 1521, 1035, 2133, 138…
$ hour_bind_cols_bind_cols_bis           <dbl> 16, 21, 19, 21, 15, 19, 10, 7, 10, 17, 16, 17, 8, 14, 8, 19, 15, 16, 20…
$ minute_bind_cols_bind_cols_bis         <dbl> 12, 27, 20, 59, 0, 0, 30, 0, 45, 20, 29, 28, 35, 50, 25, 0, 35, 55, 0, …
$ time_hour_bind_cols_bind_cols_bis      <dttm> 2013-11-29 21:00:00, 2013-10-08 01:00:00, 2013-03-02 00:00:00, 2013-05…

Count

> tbl(con_duck, 'df_test') %>% count()
# Source:   lazy query [?? x 1]
# Database: duckdb_connection
        n
    <dbl>
1 2000000

Dates

Compared to SQLite it handles dates/times correctly. No need to convert in character.

tbl(con_duck, 'df_test') %>% select(time_hour)

# Source:   lazy query [?? x 1]
# Database: duckdb_connection
   time_hour                 
   <dttm>                    
 1 2013-11-29 21:00:00.000000
 2 2013-10-08 01:00:00.000000
 3 2013-03-02 00:00:00.000000
 4 2013-05-03 01:00:00.000000
 5 2013-12-18 20:00:00.000000
 6 2013-09-18 23:00:00.000000
 7 2013-07-20 14:00:00.000000
 8 2013-03-07 12:00:00.000000
 9 2013-09-15 14:00:00.000000
10 2013-04-25 21:00:00.000000
# … with more rows

tbl(con_sqlite, 'df_test') %>% select(time_hour)

# Source:   lazy query [?? x 1]
# Database: sqlite 3.22.0 [/Users/guillaumepressiat/Documents/data/sqlite.sqlite]
    time_hour
        <dbl>
 1 1385758800
 2 1381194000
 3 1362182400
 4 1367542800
 5 1387396800
 6 1379545200
 7 1374328800
 8 1362657600
 9 1379253600
10 1366923600
# … with more rows

Some querying

Running some queries

dplyr

It already works nicely with dplyr.

> tbl(con_duck, 'iris') %>% 
+   group_by(Species) %>% 
+   summarise(min(Sepal.Width)) %>% 
+   collect()

# A tibble: 3 x 2
  Species    `min(Sepal.Width)`
  <chr>                   <dbl>
1 virginica                 2.2
2 setosa                    2.3
3 versicolor                2

> tbl(con_duck, 'iris') %>% 
+     group_by(Species) %>% 
+     summarise(min(Sepal.Width)) %>% show_query()

<SQL>
SELECT "Species", MIN("Sepal.Width") AS "min(Sepal.Width)"
FROM "iris"
GROUP BY "Species"

sql

Run query as a string

dbGetQuery(con_duck, 'SELECT "Species", MIN("Sepal.Width") FROM iris GROUP BY "Species"')

     Species min(Sepal.Width)
1  virginica              2.2
2     setosa              2.3
3 versicolor              2.0

Like for all data sources with DBI, if the query is more complex, we can write it comfortably in an external file and launch it like this for example:

dbGetQuery(con_duck, readr::read_file('~/Documents/scripts/script.sql'))

“Little” benchmarks

Collecting this big data frame

This has no sense but give some idea of read speed. We collect df_test in memory, from duckdb, monetdb and sqlite.

> microbenchmark::microbenchmark(
+   a = collect(tbl(con_duck, 'df_test')),
+   times = 5)
Unit: seconds
 expr     min       lq     mean   median       uq     max neval
    a 3.58703 3.632507 3.763129 3.676669 3.725148 4.19429     5
> microbenchmark::microbenchmark(
+   b = collect(tbl(con_monet, 'df_test')),
+   times = 5)
Unit: milliseconds
 expr      min       lq     mean   median       uq      max neval
    b 973.1111 990.3699 1003.417 1010.651 1013.858 1029.097     5
> microbenchmark::microbenchmark(
+   d = collect(tbl(con_sqlite, 'df_test')),
+   times = 1)
Unit: seconds
 expr      min       lq     mean   median       uq      max neval
    d 52.08785 52.08785 52.08785 52.08785 52.08785 52.08785     1

Really good !

Simple count

Count then collect aggregate rows.

> microbenchmark::microbenchmark(
+   a = collect(tbl(con_duck, 'df_test') %>% count(year, month)),
+   times = 20)
Unit: milliseconds
 expr      min       lq     mean   median       uq      max neval
    a 50.18014 53.24197 54.87532 54.68203 57.09206 58.94873    20
> microbenchmark::microbenchmark(
+   b = collect(tbl(con_monet, 'df_test') %>% count(year, month)),
+   times = 20)
Unit: milliseconds
 expr     min       lq     mean   median       uq     max neval
    b 151.729 157.9267 160.5727 160.8815 163.8343 167.477    20
> microbenchmark::microbenchmark(
+   d = collect(tbl(con_sqlite, 'df_test') %>% count(year, month)),
+   times = 20)
Unit: seconds
 expr      min       lq     mean  median       uq      max neval
    d 2.167202 2.196288 2.205281 2.20486 2.216594 2.253606    20

Faster !

It remains to test joins, filters, sorts, etc.

Informations

I find that there are not so many communications for the moment about this work and binding for R, so I made this post to highlight it.

MonetDBLite speed is amazing, do you will give DuckDB a try ?

In any case thanks to DuckDB developers and welcome to the new duck.

See here https://github.com/cwida/duckdb.

DuckDB developers point’s of view on data management and explanations about “duck” can be found here.

Here we can read more informations on ALTREP, MonetDBLite and DuckDB, and reasons why MonetDB was finally abandoned (“RIP MonetDBLite”).

What the duck? Explanation slide n° 25 : https://db.in.tum.de/teaching/ss19/moderndbs/duckdb-tum.pdf?lang=de ↩

Under Pi : gganimate test around quadrature of the circle

Thu, 02 May 2019 13:05:50 +0000

An updated look on squaring the circle using gganimate and R code.

It gives a geometric and visual construction, a good and practical representation of what Pi is. As n becomes larger, segments become smaller and smaller, Pi can then be seen as perfection and we almost intuit infinity.

require(sp)
require(rgeos)
library(ggplot2)
library(dplyr, warn.conflicts = FALSE)

x <- 0.5 # center x
y <- 0.5 # center y
n <- 1000 # nr of pts
r <- 0.5 # radius


poly <- function(n){
  library(dplyr, warn.conflicts = FALSE)
  j <- n %% 2
  theta <- (2 - j):(2 * (n) + 1)
  
  u <- tibble(theta = theta, x = cos(theta * 2 * pi / n), y = sin(theta * 2 * pi / n))
  v <- SpatialPolygons(list(Polygons(list(Polygon(cbind(u$x,u$y))), "polygon")))
  v <- ggplot2::fortify(v) %>% mutate(n = n)
  
  return(list(df = u, poly = v))
}

pts <- seq(0, 2 * pi, length.out = n)
plot(sin(pts), cos(pts), type = 'l', asp = 1) # test

nmax = 60
alls <- 3:nmax %>% purrr::map(function(x)poly(x)$poly) %>% bind_rows()  %>% 
  mutate(estimate = round(sqrt(2 - 2 * cos(pi / n)) * n, 9))


circles <- bind_rows(lapply(tibble(x = cos(pts), y = sin(pts)), rep, nmax - 2 )) %>% 
  mutate(n = rep(3:nmax, each = 1000)) %>% 
  as_tibble() %>% 
  mutate(estimate = round(sqrt(2 - 2 * cos(pi / n)) * n, 9),
         estimate = paste0('Pi estimate : ', format(estimate, digits = 10), '\n', 
                           'Difference  : ', format(round(pi - estimate, 9), digits = 9)))

library(ggplot2)
library(gganimate)
p <- ggplot() +
  geom_point(data = circles, aes(x = x, y = y), col = 'cornflowerblue', lwd = 3, alpha = 0.5) + 
  theme_void() + 
  geom_polygon(data = alls, aes(x = long, y = lat, group = n), col = 'grey30', lwd = 1.3, fill = 'cornflowerblue', alpha = 0.5) + 
  geom_text(data = distinct(circles, n, .keep_all = TRUE), aes(x = 0, y = 0, label = estimate), size = 6) + 
  labs(title = 'Segments number : {frame_time}') + 
  transition_time(n)

p

More information and some links of inspirations are here in the code:

https://github.com/Guillaumepressiat/under_pi

And I have made a really long gif here:

https://raw.githubusercontent.com/GuillaumePressiat/under_pi/master/under_pi_patient_geek.gif

Prêt pour M03 2019 - un point sur les nouveautés de pmeasyr

Sat, 13 Apr 2019 23:31:55 +0000

Suite à la mise à jour des formats pour M03 2019, je présente les nouveautés ajoutées dans pmeasyr.

Nouveautés dans les formats PMSI 2019

Parmi les nouveautés je ne détaillerai que la principale, l’ajout pour tous les champs de la variable n° d’identifiant permanent du patient, in et out avec le n° d’identifiant permanent du patient anonymisé dans les données anohosp.

Pour intégrer les données 2019 à partir de M03, il faut réinstalller le package.

devtools::install_github('IM-APHP/pmeasyr')

Nouveautés dans pmeasyr

En plus des formats 2019 disponibles, voici une liste des nouveautés ajoutées et consolidées dans l’année passée :

Valorisation des séjours MCO

https://im-aphp.github.io/pmeasyr/articles/vignette4.html

Un ensemble de fonctions permet de reconstruire pour les établissements ex-DGF la valorisation BR epmsi et ainsi avoir :

une table avec les valorisations GHS et suppléments pour chaque séjour
une table avec les caractères facturables / non facturables exprimés selon les modalités des tableaux epmsi
la conjonction de ces deux points peut permettre de rendre compte de problèmes et d’évolutions de groupage et de facturation au cours du temps, préalablement à la validation sur epmsi (ex: quels séjours deviennent non valorisés, quels séjours changent de GHS, si l’on compare les données de plusieurs remontées successives, lamda ou courant)

Afin de s’assurer de la concordance entre ces valorisations recalculées dans R et celle d’epmsi, deux fonctions permettent de reproduire les tableaux SV et RAV d’epmsi ; et avec un peu d’effort, on peut reconstituer également les tableaux EMM.

Valorisation des sous-séquences d’HAD

https://im-aphp.github.io/pmeasyr/reference/vvr_had_ght.html

Depuis quelques jours, j’ai ajouté la possibilité pour les établissements ex-DGF réalisant de l’activité d’HAD de valoriser l’activité de leurs sous-séquences en accord avec les montants epmsi.

Nouveauté en dehors de pmeasyr

pmsEye est un package pour importer les sorties des logiciels VisualValo*.

https://guillaumepressiat.github.io/pmsEye/

Utilisation du package pmeasyr

Un utilisateur habitué de pmeasyr m’a indiqué avoir fait une mission pour une entreprise, il s’agissait d’intégrer des données PMSI in/out avec pmeasyr dans leur outil de requêtage de “profil patient”. Cette entreprise démarchant ensuite les hôpitaux pour proposer leur produit.

Plusieurs sentiments-réflexes se sont déclenchés chez moi en apprenant cette nouvelle :

la satisfaction : le package est une solution reconnue et une entreprise s’appuie dessus, même si ce n’est pas l’écosystème auquel j’avais pensé, on peut voir cela positivement
l’étonnement : sachant que je ne tire pas de profit financier du partage de ce package, il peut sembler étonnant que l’on m’informe naturellement de cette mission effectuée en utilisant pmeasyr, sans que j’en trouve trace par ailleurs
le besoin de trouver une explication à mon incompréhension : partager un outil, un ensemble de programmes, ce n’est pas partager des valeurs, ni une vision des choses. Je reformule : c’est partager des choses avec des personnes qui ne partagent pas forcément la même vision des choses.
le besoin de réexprimer “ma vision des choses” qui j’en suis sûr n’engage pas que moi, ce que je fais ici
- le package a été diffusé au départ avec l’idée de répondre aux besoins de personnels hospitaliers d’information médicale ; avec comme origine le contexte suivant : “un hôpital A a pu développer un outil qu’un hôpital B n’a pas pu développer mais qui lui serait utile, ou pour lequel un hôpital C a motivation à participer”
- ouvrir et rendre reproductible facilement un ensemble de méthodes courantes du PMSI : rendre ouvertes, gratuites et compréhensibles des méthodes qui peuvent être au choix fermées, payantes et/ou opaques
- travailler en partenariat avec des personnes dont les intérêts sont proches
- travailler avec des outils qui rendent les tâches plus agréables, voire amusantes pour certains d’entre nous

Ce package reste ouvert, même pour des réutilisations commerciales, alors comme une solution sympathique, minimale, je vois : je vous remercie de citer le package si vous l’utilisez. J’apprécierai également que vous me contactiez pour m’informer de comment vous utilisez le package ou pour me remonter vos remarques, adresse mail visible ici.

citation("pmeasyr")

Strength of a Lennon song exposed with R function glue::glue

Mon, 25 Mar 2019 13:05:50 +0000

This post is an actualisation with addendum below.

love_verse <- function(w1, w2, w3){
  glue::glue(
  "Love is {b}, {b} is love
   Love is {y}, {y} love
   Love is {u} to be loved", 
  b = w1, y = w2, u = w3)
}

As a return, parameters sometimes give echoes of poetry.

love_verse('real', 'feeling', 'wanting')

Love is real, real is love
Love is feeling, feeling love
Love is wanting to be loved

love_verse('touch', 'reaching', 'asking')

Love is touch, touch is love
Love is reaching, reaching love
Love is asking to be loved

## refrain

Love is you
You and me
Love is knowing
We can be

love_verse('free', 'living', 'needing')

Love is free, free is love
Love is living, living love
Love is needing to be loved

https://www.youtube.com/watch?v=7er_xx7Wmg8

list(list(w1 = 'real',  w2 = 'feeling',  w3 = 'wanting'),
     list(w1 = 'touch', w2 = 'reaching', w3 = 'asking' ),
     list(w1 = 'free',  w2 = 'living',   w3 = 'needing')) %>% 
  purrr::map(function(x)do.call(love_verse, x))

[[1]]
Love is real, real is love
Love is feeling, feeling love
Love is wanting to be loved

[[2]]
Love is touch, touch is love
Love is reaching, reaching love
Love is asking to be loved

[[3]]
Love is free, free is love
Love is living, living love
Love is needing to be loved

We could also read title of this article as “strength of an R function exposed with a Lennon song”…

If you like it, you can view this code as a gist here.

Addendum

In a more tidyverse way, you could also do this last piping block step using glue_data approach, what I have not thinked about. I haven’t been able to think theses words will fit in a tibble, which is why I have used do.call which sounds a little like old.school!

With a little help from Jim Hester, it’s getting better:

library(magrittr)

tibble::tribble(
  ~a, ~b, ~c,
  "real", "feeling", "wanting",
  "touch", "reaching", "asking",
  "free", "living", "needing"
  ) %>%
  glue::glue_data(
  "Love is {a}, {a} is love
   Love is {b}, {b} love
   Love is {c} to be loved",
  ) %>%
  glue::glue_collapse("\n\n")
#> Love is real, real is love
#> Love is feeling, feeling love
#> Love is wanting to be loved
#> 
#> Love is touch, touch is love
#> Love is reaching, reaching love
#> Love is asking to be loved
#> 
#> Love is free, free is love
#> Love is living, living love
#> Love is needing to be loved

reciproceed : recipe, proceed, reciprocally

Mon, 11 Mar 2019 01:05:50 +0000

use R, YAML and bookdown to automate generation of procedure books

Context: How to do this thing that only your colleague does when he’s not here?

I recently put on github a project that contains a little framework to list procedures in a structured way that can be shared with all your colleagues or buddies.

You may know situations where someone in your team has build a project that he is the only one to mastering. How to make it works when he is not here ? Maybe he has written a doc / procedure that explains his project but you don’t know (or don’t remember) where it is on the network (or on the web)?

As a solution, an index of all procedures can be useful, one that lists:

summary of all procedures (as simple steps)
links to git repositories
links to more detailed procedures (docx, pdf, html)
links to data sources used by projects
etc.

reciproceed sounds like “reciprocally” meaning that once all procedures are listed this way, all the team will be involved reciprocally.

Idea

To do this, an idea is: using a YAML file and bookdown to build a shareable procedure listing like a book.

Example

As an example, I collected some soup recipes and fake procedures, see the source YAML file.

Soup recipes are used as fake data (meaning that they are structured and have chronological steps like procedures) but they are not fake soups. By the way they came from bbcfoods.

And the result book is here:

Soup recipe example

Maybe

Maybe someone else will be interested by this and even will participate to improve it.

It’s here, https://github.com/GuillaumePressiat/reciproceed

stringfix : adding transcoder shiny app

Sun, 10 Feb 2019 01:05:50 +0000

Adding quotes to a character list

Transcoder : Shiny app to tranpose lists to columns (and reciprocally) and formatting tricks

Often I have to take a character list or column and put it in a vector, which means before I have to add quotes. It takes times.

For me and my colleagues I have created the transcoder shiny app. The main goal is to facilitate formatting list of strings (make a vector from a list, from an Excel column, add quotes, put in pipe R format, or in SQL like, etc.).

You can run the app within stringfix package :

stringfix::run_transcoder()

You may have to reinstall the package :

devtools::install_github('GuillaumePressiat/stringfix')

You can also view and explore this little app running on shinyapps.io here.

For instance, here is a screenshot of the app that put a column in grepl pipe format:

Format a column to pipe | format

Other things about stringfix package

I have added a page to present all the functions here.

Three functions in stringfix package are for pasting. From here, you may discover another package that propose to paste strings with infix operators, it’s the pasta package !

pmeasyr en images

Sat, 09 Feb 2019 07:05:50 +0000

Créer des images pour présenter du code à l’aide de carbon.

Étape 0 : définir un noyau de paramètres

Voir ici: https://carbon.now.sh/

Le code de ces exemples est disponible ici.

Étape 1 : dézipper et importer les données

Étape 2 : calcul de case-mix et dms

Étape 3 : des exemples de requêtes

Étape 4 : des données, intégrées dans une base de données

Étape 5 : requêter des données, intégrées dans une base de données

Étape 6 : Valoriser des rsa et retrouver les montants epmsi

stringfix : new R package for string manipulation in a %>% way

Thu, 24 Jan 2019 01:05:50 +0000

I usually write around here in french and mainly report on French Hospitals data managment and the statistical tasks they imply. As today’s post is about a new package I have created, I’ll be writing in english. The package is called stringfix because it uses infix operators to manipulate character strings.

This post is an actualisation on December 2018 post.

Introduction

In Python, the operator + is used to paste two character strings together. For example: 'Hello ' + 'world' gives 'Hello World'. For that matter, building sentences with words and arithmetic symbols seems a very nice way to write. In R, the paste function requires parenthesis in order to be computed. Therefore the use of consecutive functions can make it hard to understand.

+ is a nice operator, and we can use it in R almost as it is used in Python by creating an infix operator.

`%+%` <- function(x,y){
  paste0(x, y)
}

While a ggplot function has already the same name, it is used to override data in a ggplot call and not for pasting character strings, see here. When loading tidyverse, the same ggplot function is called, preventing us from using paste0’s %+%. Otherwise, you can find a hint of character string pasting in the Advanced R book.

In order to create a toolbox around paste0’s %+%, I started collecting some other infix functions for character strings manipulation. The main question was: which functions with a right to left call that I use really often could be reordered in a %>% code. Here is the little family I have since build on : paste, grepl, substring, count, padding. The goal of this package is to use stringr or base functions in backend as a start for an alternative character string manipulation in R.

This package is still at its early begining (kind of a draft for me!) but I thought some other people would enjoy it and may even wish to contribute.

Presentation

"In a manner of coding, I just want to say..." % % "Nothing."
#>[1] "In a manner of coding, I just want to say... Nothing."

Examples

paste

'Hello ' %+% 'world'
#> [1] "Hello world"
'Your pastas taste like ' %+% '%>%'
#> [1] "Your pastas taste like %>%"
'coco' %+% 'bolo'
#> [1] "cocobolo"

'Hello' % % 'world'
#> [1] "Hello world"
'Your pastas taste like' % % '%>%'
#> [1] "Your pastas taste like %>%"
'Hello' %,% 'world...'
#> [1] "Hello, world..."
'Your pastas taste like ' %+% '%>%...' %,% 'or %>>%...'
#> [1] "Your pastas taste like %>%..., or %>>%..."

grepl

Case sensitive

'pig' %g% 'The pig is in the cornfield'
#> [1] TRUE
'Pig' %g% 'The pig is in the cornfield'
#> [1] FALSE

Case insensitive (ignore.case)

'pig' %gic% 'The pig is in the cornfield'
#> [1] TRUE
'PIG' %gic% 'The PiG is in the cornfield'
#> [1] TRUE

substring

'NFKA008' %s% '1.4'
#> [1] "NFKA"
'NFKA008' %s% .4
#> [1] "NFKA"
'where is' % % ('the pig is in the cornfield' %s% '1.7') %+% '?'
#> [1] "where is the pig?"

count

fruit <- c("apple", "banana", "pear", "pineapple")
"a" %count% fruit
#> [1] 1 3 1 1
c("a", "b", "p", "p") %count% fruit
#> [1] 1 1 1 3

pad, lpad and rpad

5 %lpad% '0.5'
#> [1] "00005"
5 %lpad%   .5
#> [1] "00005"
5 %lpad%  '.5'
#> [1] "    5"
5 %lpad% '2.5'
#> [1] "22225"
'é' %lpad% 'é.5'
#> [1] "ééééé"

names of tibbles : tolower and toupper

I have added two functions that I use really often.

library(magrittr)
iris %>% toupper_names %>% head
#>   SEPAL.LENGTH SEPAL.WIDTH PETAL.LENGTH PETAL.WIDTH SPECIES
#> 1          5.1         3.5          1.4         0.2  setosa
#> 2          4.9         3.0          1.4         0.2  setosa
#> 3          4.7         3.2          1.3         0.2  setosa
#> 4          4.6         3.1          1.5         0.2  setosa
#> 5          5.0         3.6          1.4         0.2  setosa
#> 6          5.4         3.9          1.7         0.4  setosa

Finally, I also wanted to outline that the function from the rmngb package : %out% : negation of %in% can be very useful to avoid typing ! x %in% y (you can just type x %out% y instead). This is why I have included it in this package !

More functions and information here : https://github.com/GuillaumePressiat/stringfix

Indications spécialités pharmaceutiques : format des fichcomp med à jour

Thu, 27 Sep 2018 07:05:50 +0000

Aperçu de la table des med out importée avec des indications

Les formats med in et out tiennent désormais compte de la colonne indication pour 2018.

Vous pouvez mettre à jour le package pour pouvoir travailler sur ces nouvelles colonnes.

On trouve la correspondance de ces codes indications sur le site de l’ATIH ou celui de la DGOS.

Historique des coefficients géographiques

Tue, 19 Jun 2018 07:05:50 +0000

Quelles évolutions pour les coefficients géographiques, depuis 2007 ?

Visualisation

Tableau

zone_geographique	coeff_geo	anseqta	departement	categ_zonage
2A Corse du Sud	0.08	2016	2A	Corse
2B Haute Corse	0.08	2016	2B	Corse
75 Paris	0.07	2016	75	Ile-de-France
77 Seine et Marne	0.07	2016	77	Ile-de-France
78 Yvelines	0.07	2016	78	Ile-de-France
91 Essonne	0.07	2016	91	Ile-de-France
92 Haut de Seine	0.07	2016	92	Ile-de-France
93 Seine saint Denis	0.07	2016	93	Ile-de-France
94 Val de Marne	0.07	2016	94	Ile-de-France
95 Val d’Oise	0.07	2016	95	Ile-de-France
971 Guadeloupe	0.26	2016	971	Outre-Mer
972 Martinique	0.26	2016	972	Outre-Mer
973 Guyane	0.26	2016	973	Outre-Mer
974 Réunion	0.31	2016	974	Outre-Mer
2A Corse du Sud	0.11	2017	2A	Corse
2B Haute Corse	0.11	2017	2B	Corse
75 Paris	0.07	2017	75	Ile-de-France
77 Seine et Marne	0.07	2017	77	Ile-de-France
78 Yvelines	0.07	2017	78	Ile-de-France
91 Essonne	0.07	2017	91	Ile-de-France
92 Haut de Seine	0.07	2017	92	Ile-de-France
93 Seine saint Denis	0.07	2017	93	Ile-de-France
94 Val de Marne	0.07	2017	94	Ile-de-France
95 Val d’Oise	0.07	2017	95	Ile-de-France
971 Guadeloupe	0.27	2017	971	Outre-Mer
972 Martinique	0.27	2017	972	Outre-Mer
973 Guyane	0.29	2017	973	Outre-Mer
974 Réunion	0.31	2017	974	Outre-Mer
2A Corse du Sud	0.08	2015	2A	Corse
2B Haute Corse	0.08	2015	2B	Corse
75 Paris	0.07	2015	75	Ile-de-France
77 Seine et Marne	0.07	2015	77	Ile-de-France
78 Yvelines	0.07	2015	78	Ile-de-France
91 Essonne	0.07	2015	91	Ile-de-France
92 Haut de Seine	0.07	2015	92	Ile-de-France
93 Seine saint Denis	0.07	2015	93	Ile-de-France
94 Val de Marne	0.07	2015	94	Ile-de-France
95 Val d’Oise	0.07	2015	95	Ile-de-France
971 Guadeloupe	0.26	2015	971	Outre-Mer
972 Martinique	0.26	2015	972	Outre-Mer
973 Guyane	0.26	2015	973	Outre-Mer
974 Réunion	0.31	2015	974	Outre-Mer
2A Corse du Sud	0.08	2014	2A	Corse
2B Haute Corse	0.08	2014	2B	Corse
75 Paris	0.07	2014	75	Ile-de-France
77 Seine et Marne	0.07	2014	77	Ile-de-France
78 Yvelines	0.07	2014	78	Ile-de-France
91 Essonne	0.07	2014	91	Ile-de-France
92 Haut de Seine	0.07	2014	92	Ile-de-France
93 Seine saint Denis	0.07	2014	93	Ile-de-France
94 Val de Marne	0.07	2014	94	Ile-de-France
95 Val d’Oise	0.07	2014	95	Ile-de-France
971 Guadeloupe	0.26	2014	971	Outre-Mer
972 Martinique	0.26	2014	972	Outre-Mer
973 Guyane	0.26	2014	973	Outre-Mer
974 Réunion	0.31	2014	974	Outre-Mer
2A Corse du Sud	0.08	2013	2A	Corse
2B Haute Corse	0.08	2013	2B	Corse
75 Paris	0.07	2013	75	Ile-de-France
77 Seine et Marne	0.07	2013	77	Ile-de-France
78 Yvelines	0.07	2013	78	Ile-de-France
91 Essonne	0.07	2013	91	Ile-de-France
92 Haut de Seine	0.07	2013	92	Ile-de-France
93 Seine saint Denis	0.07	2013	93	Ile-de-France
94 Val de Marne	0.07	2013	94	Ile-de-France
95 Val d’Oise	0.07	2013	95	Ile-de-France
971 Guadeloupe	0.26	2013	971	Outre-Mer
972 Martinique	0.26	2013	972	Outre-Mer
973 Guyane	0.26	2013	973	Outre-Mer
974 Réunion	0.31	2013	974	Outre-Mer
2A Corse du Sud	0.08	2012	2A	Corse
2B Haute Corse	0.08	2012	2B	Corse
75 Paris	0.07	2012	75	Ile-de-France
77 Seine et Marne	0.07	2012	77	Ile-de-France
78 Yvelines	0.07	2012	78	Ile-de-France
91 Essonne	0.07	2012	91	Ile-de-France
92 Haut de Seine	0.07	2012	92	Ile-de-France
93 Seine saint Denis	0.07	2012	93	Ile-de-France
94 Val de Marne	0.07	2012	94	Ile-de-France
95 Val d’Oise	0.07	2012	95	Ile-de-France
971 Guadeloupe	0.26	2012	971	Outre-Mer
972 Martinique	0.26	2012	972	Outre-Mer
973 Guyane	0.26	2012	973	Outre-Mer
974 Réunion	0.31	2012	974	Outre-Mer
2A Corse du Sud	0.06	2011	2A	Corse
2B Haute Corse	0.06	2011	2B	Corse
75 Paris	0.07	2011	75	Ile-de-France
77 Seine et Marne	0.07	2011	77	Ile-de-France
78 Yvelines	0.07	2011	78	Ile-de-France
91 Essonne	0.07	2011	91	Ile-de-France
92 Haut de Seine	0.07	2011	92	Ile-de-France
93 Seine saint Denis	0.07	2011	93	Ile-de-France
94 Val de Marne	0.07	2011	94	Ile-de-France
95 Val d’Oise	0.07	2011	95	Ile-de-France
971 Guadeloupe	0.25	2011	971	Outre-Mer
972 Martinique	0.25	2011	972	Outre-Mer
973 Guyane	0.25	2011	973	Outre-Mer
974 Réunion	0.30	2011	974	Outre-Mer
2A Corse du Sud	0.05	2010	2A	Corse
2B Haute Corse	0.05	2010	2B	Corse
75 Paris	0.07	2010	75	Ile-de-France
77 Seine et Marne	0.07	2010	77	Ile-de-France
78 Yvelines	0.07	2010	78	Ile-de-France
91 Essonne	0.07	2010	91	Ile-de-France
92 Haut de Seine	0.07	2010	92	Ile-de-France
93 Seine saint Denis	0.07	2010	93	Ile-de-France
94 Val de Marne	0.07	2010	94	Ile-de-France
95 Val d’Oise	0.07	2010	95	Ile-de-France
971 Guadeloupe	0.25	2010	971	Outre-Mer
972 Martinique	0.25	2010	972	Outre-Mer
973 Guyane	0.25	2010	973	Outre-Mer
974 Réunion	0.30	2010	974	Outre-Mer
2A Corse du Sud	0.05	2009	2A	Corse
2B Haute Corse	0.05	2009	2B	Corse
75 Paris	0.07	2009	75	Ile-de-France
77 Seine et Marne	0.07	2009	77	Ile-de-France
78 Yvelines	0.07	2009	78	Ile-de-France
91 Essonne	0.07	2009	91	Ile-de-France
92 Haut de Seine	0.07	2009	92	Ile-de-France
93 Seine saint Denis	0.07	2009	93	Ile-de-France
94 Val de Marne	0.07	2009	94	Ile-de-France
95 Val d’Oise	0.07	2009	95	Ile-de-France
971 Guadeloupe	0.25	2009	971	Outre-Mer
972 Martinique	0.25	2009	972	Outre-Mer
973 Guyane	0.25	2009	973	Outre-Mer
974 Réunion	0.30	2009	974	Outre-Mer
2A Corse du Sud	0.05	2008	2A	Corse
2B Haute Corse	0.05	2008	2B	Corse
75 Paris	0.07	2008	75	Ile-de-France
77 Seine et Marne	0.07	2008	77	Ile-de-France
78 Yvelines	0.07	2008	78	Ile-de-France
91 Essonne	0.07	2008	91	Ile-de-France
92 Haut de Seine	0.07	2008	92	Ile-de-France
93 Seine saint Denis	0.07	2008	93	Ile-de-France
94 Val de Marne	0.07	2008	94	Ile-de-France
95 Val d’Oise	0.07	2008	95	Ile-de-France
971 Guadeloupe	0.25	2008	971	Outre-Mer
972 Martinique	0.25	2008	972	Outre-Mer
973 Guyane	0.25	2008	973	Outre-Mer
974 Réunion	0.30	2008	974	Outre-Mer
2A Corse du Sud	0.05	2007	2A	Corse
2B Haute Corse	0.05	2007	2B	Corse
75 Paris	0.07	2007	75	Ile-de-France
77 Seine et Marne	0.07	2007	77	Ile-de-France
78 Yvelines	0.07	2007	78	Ile-de-France
91 Essonne	0.07	2007	91	Ile-de-France
92 Haut de Seine	0.07	2007	92	Ile-de-France
93 Seine saint Denis	0.07	2007	93	Ile-de-France
94 Val de Marne	0.07	2007	94	Ile-de-France
95 Val d’Oise	0.07	2007	95	Ile-de-France
971 Guadeloupe	0.25	2007	971	Outre-Mer
972 Martinique	0.25	2007	972	Outre-Mer
973 Guyane	0.25	2007	973	Outre-Mer
974 Réunion	0.30	2007	974	Outre-Mer
75 Paris	0.07	2018	75	Ile-de-France
77 Seine et Marne	0.07	2018	77	Ile-de-France
78 Yvelines	0.07	2018	78	Ile-de-France
91 Essonne	0.07	2018	91	Ile-de-France
92 Haut de Seine	0.07	2018	92	Ile-de-France
93 Seine saint Denis	0.07	2018	93	Ile-de-France
94 Val de Marne	0.07	2018	94	Ile-de-France
95 Val d’Oise	0.07	2018	95	Ile-de-France
971 Guadeloupe	0.27	2018	971	Outre-Mer
972 Martinique	0.27	2018	972	Outre-Mer
973 Guyane	0.29	2018	973	Outre-Mer
974 Réunion	0.31	2018	974	Outre-Mer
2A Corse du Sud	0.11	2018	2A	Corse
2B Haute Corse	0.11	2018	2B	Corse

Le saviez-vous ?

Les numéros finess des établissements d’Outre-Mer commencent par 97, et le quatrième caractère permet de reconstruire le département : 1 Guadeloupe, 2 Martinique, 3 Guyane et 4 Réunion, cf ¹.

http://finess.sante.gouv.fr/fininter/jsp/definitions.do?codeDefinition=3. ↩

Lister les travaux connexes avec R et les visualiser

Thu, 07 Jun 2018 07:05:50 +0000

Ce post pour annoncer une visualisation des travaux connexes/annexes à pmeasyr accessibles ici.

alt-R native

pmsi-io 0.4.1 et Transcoder 0.2.0

pmsi-io 0.4.1

0.4.0 : refonte majeure

0.4.1 : Explorateur de données

Transcoder 0.2.0

Application bureau (Tauri)

Version web (WASM)

Installer les applications

logrittr: A Verbose Pipe Operator for Logging dplyr Pipelines

Motivation

Multiples contexts

Pro

Educational

Installation

Usage

Screenshot

Related package: tidylog

Working with lumberjack

Limitations

Take another pipe for a spin

Fun pictures with ggplot2 and scico packages

logrittr: A Verbose Pipe Operator for Logging dplyr Pipelines

Motivation

Multiples contexts

Pro

Educational

Installation

Usage

Screenshot

Related package: tidylog

Working with lumberjack

Limitations

Take another pipe for a spin

dplyr and Oracle database with DatabaseConnector and JDBC on Windows

An alternative with JDBC

Mise à jour des outils pour s'adapter aux sorties de Druides

pmeasyr

pypmsi

pmsi-io / pmsi-clio

pmsi-io

pmsi-clio

Mise à jour de pmsi-io et information concernant le nommage des fichiers par Druides

pmsi-io / pmsi-clio

pmsi-io

pmsi-clio

Modifications à venir / nommage des fichiers PMSI avec Druides

Mise à jour des outils, février en attendant... 2025, M01 & M02

pmeasyr

pypmsi

pmsi-io / pmsi-clio

pmsi-io

pmsi-clio

Retour sur les communications réalisées en 2024

Lire des fichiers H'XML / HPRIM-XML avec python/pola.rs ou R

Introduction

De quoi parle-t-on ?

Contexte

Utiliser xpath pour aller vite

Avec python

Avec R

Package pyhprimxml

Bibliothèques utilisées

Découverte de delta lake avec pola.rs et pypmsi

Introduction

Version des packages utilisés

Notebook

pmeasyr au congrès EMOIS 2024

Poster

Atelier

pmsi-io : un logiciel pour lire les in / out du PMSi et les exporter en csv, xlsx, txt, json et parquet

Contexte / objectifs

Vidéo

Résultat

Installation

Discussion

Contact

Questionnaire PMSI avec R / python

Quarto + pypmsi

Reproduire des in / out MCO à partir des zip.zip.zip de Druides

Related package: `tidylog`

Working with `lumberjack`

Related package: `tidylog`

Working with `lumberjack`