En esta sesión vamos a investigar la estructura de las bases de datos del registro de diabetes de Dinamarca, basándonos en datos simulados. Esto quiere decir que todos los datos que veremos son generados aleatóreamente y no pertenecen a ninguna persona real.
9.2 Explorando el paquete OSDC
Para éste taller usaremos el paquete “osdc” (Open Source Diabetes Classifier). Antes de iniciar esta sesión debes haber completado las tareas pre-taller, incluyendo la instalación de paquetes.
El paquete ‘osdc’ contiene varias funciones, pero también documentación en forma de guías o viñetas. Podemos revisarlas dentro del ambiente R.
La primera nos da la documentación del algoritmo
vignette("algorithm")
starting httpd help server ... done
El siguiente paso es revisar todas las fuentes de datos que son necesarias para crear el registro.
vignette("data-sources")
9.3 Registros y variables
Como se puede ver, hay 5 registros, pero en algunos casos un solo registro tiene varias tablas temáticas que se acceden como bases separadas (Landspatientregisterets) o separadas en el tiempo (Sygesikringsregisteret)
La segunda tabla nos muestra todas las variables de cada registro que son necesarias para construir el registro de diabetes.
Podemos consultar estos datos al detalle generando una variable que contiene la lista de registros.
El paquete requiere que los datos estén en formato DuckDB. Esta es una base de datos de alta performancia que puede manejar volúmenes grandes de datos sin que sea necesario cargarlos todos a memoria en una sola vez.
Para este ejemplo generaremos datos simulados del formato de registro con el comando simulate_registers() y luego los convertiremos al formato DuckDB:
register_data <-registers() |>names() |>simulate_registers(n=10000) |> purrr::map(duckplyr::as_duckdb_tibble) |># Convert to a DuckDB connection, as duckplyr is still# in early development, while the DBI-DuckDB connection# is more stable. purrr::map(duckplyr::as_tbl)
duckdb keeps downloaded extensions and secrets in a temporary directory:
ℹ /tmp/RtmpHXttXR/duckdb
This is removed when the R session ends.
• Extensions are re-downloaded each session.
• Secrets are lost.
ℹ Run duckdb(shared_home = TRUE) (or create ~/.duckdb) to keep them (suitable for most users).
ℹ Run duckdb(shared_home = FALSE) to accept the temporary directory (and silence this message).
ℹ See ?duckdb_storage for details and alternatives.
El resultado es una lista con nombres, donde cada elemento corresponde a un registro en forma de una tabla de DuckDB. Los datos del LPR abarcan múltiples versiones (LPR2 y LPR3), que deben prepararse y unirse en una única tabla antes de utilizarse como entrada para classify_diabetes(). Lo mismo ocurre con los registros de los servicios de salud (SSSY y SYSI). osdc proporciona funciones auxiliares para realizar esta tarea.
Como se puede ver, este proceso devuelve una tabla de DuckDB con los individuos clasificados como personas con diabetes tipo 1 (DM1) o diabetes tipo 2 (DM2), junto con la fecha de la clasificación. Cada una de las columnas de la salida se explica en la Section 9.5.3.1 más adelante.
9.5.3 Transferencia de los datos a formato R
Por ahora los datos están guardados en formato DuckDB, lo que quiere decir que no han sido cargados directamente a la memoria de R. Para transferir los datos a R usamos dplyr::collect():
Ahora vemos que en los datos simulados 954 individuos han sido clasificados con un diagnóstico de diabetes.
9.5.3.1 Cómo entender los datos
El resultado es una tabla con una fila por individuo clasificado y cinco columnas:
Columna
Descripción
pnr
El número identificador individual pseudonimizado.
stable_inclusion_date
La fecha del segundo evento de inclusión, si cae después de stable_inclusion_start_date (valor predeterminado: 1998). NA para fechas anteriores.
raw_inclusion_date
La fecha del segundo evento de inclusión sin imponer NA para fechas anteriores a stable_inclusion_start_date.
has_t1d
TRUE si el individuo se clasifica como caso de diabetes tipo 1, FALSE en otros casos.
has_t2d
TRUE si el individuo se clasifica como caso de diabetes tipo 2, FALSE en otros casos.
Note
9.5.4 Acerca de stable_inclusion_date y raw_inclusion_date
La raw_inclusion_date corresponde simplemente a la fecha del segundo evento que cumple los criterios de clasificación. Sin embargo, para los eventos anteriores a 1998, los datos de los registros pueden no tener una cobertura suficiente para distinguir de forma fiable entre casos nuevos (incidentes) y casos ya existentes (prevalentes). Por ello, la columna stable_inclusion_date se establece como NA para esas fechas más tempranas, con el fin de señalar esta incertidumbre.
La función classify_diabetes() incluye el parámetro stable_inclusion_start_date, cuyo valor predeterminado es 01-01-1998. Esto significa que es posible modificar la fecha a partir de la cual la clasificación se considera estable.
Véase la sección ‘Interface’ bajo vignette("design") para mayor información sobre los datos resultantes.
9.5.5 Borrar variables ya usadas
Antes de continuar vamos a hacer algo de limpieza, eliminando las variables que ya no vamos a necesitar.