HES_pipeline
1.0.0
El canal de la tubería R de código abierto para limpiar y procesar estadísticas de episodios del hospital a nivel de paciente (HES) y datos de mortalidad de ONS vinculados, con el objetivo de producir conjuntos de datos listos para el análisis para un programa definido de análisis.
Las estadísticas del episodio del hospital (HES) es una base de datos que contiene detalles de todas las admisiones hospitalarias, asistencias de A&E y citas ambulatorias en los hospitales NHS en Inglaterra.
Antes de que pueda usarse para el análisis, HES Data requiere limpieza, control de calidad y procesamiento para obtener variables adicionales. La compleja estructura de registro de HES, la gran cantidad de variables y el tamaño de los conjuntos de datos hacen de esta una tarea desafiante tanto desde un punto de vista analítico como computacional.
El flujo de trabajo semiautomático que estamos desarrollando en este repositorio procesa los datos HES de manera consistente y reproducible, que se documentan todos los pasos de procesamiento, diseñados para garantizar que cada análisis de análisis aprobado se base en los mismos datos limpios.
Utilizamos datos de HES vinculados a datos de mortalidad de ONS desde 2008/09 hasta el lanzamiento trimestral más reciente. Nuestra aplicación de datos ha sido aprobada por el Servicio de Solicitud de Acceso a Datos (DARS) del NHS Digital [DARS).
Se accederá a los datos en el entorno de datos seguro de la Fundación Health; Una instalación de análisis de datos seguro (acreditado con el estándar de seguridad de la información ISO27001 y reconocido para el Kit de herramientas de seguridad y protección de datos digitales del NHS). No se utilizará información que pueda identificar directamente a un paciente u otro individuo.
La carpeta DOC contiene información sobre:
Además, las secciones a continuación describen
Como los datos HE HES preparados en esta tubería no están disponibles públicamente, el código no puede usarse para replicar los mismos datos limpios y la base de datos. Sin embargo, el código se puede utilizar en extractos de HES a nivel de paciente similares para preparar los conjuntos de datos para el análisis. Para obtener información más detallada sobre cómo funciona la tubería, consulte a continuación o consulte el documento del proceso.
El documento de proceso describe el diseño general de la tubería, enumera las entradas necesarias y una descripción de alto nivel de los pasos en el flujo de trabajo.
El diagrama de flujo muestra cómo la entrada y los datos del usuario se mueven a través de las diferentes funciones de la tubería.
La tubería puede por ejecución en dos modos:
update = TRUE ). Las actualizaciones de datos HES dentro del mismo año se superponen, por lo que algunos de los datos antiguos se eliminarán y reemplazarán con la nueva actualización. Los datos de mortalidad de ONS están completamente renovados con cada actualización de datos.En modo de compilación , la tubería
En el modo de actualización , la tubería
El Registro de Decisión de Arquitectura (ADR) captura la decisión arquitectónica y las opciones de diseño, junto con su contexto, justificación y consecuencias. Además, registramos algunas decisiones analíticas.
Hasta ahora, hemos registrado decisiones sobre
El oleoducto HES se construyó bajo R versión 3.6.2 (2019-12-12)-"Noche oscura y tormentosa".
Se requieren los siguientes paquetes R, que están disponibles en CRAN, para ejecutar la tubería HES:
La ubicación donde se crea la base de datos debe tener suficiente espacio de almacenamiento disponible, más o menos equivalente al tamaño de archivo combinado del extracto de datos HES sin procesar más 2 x tamaño de archivo del conjunto de datos APC (como las tablas para hechizos para pacientes hospitalizados y hechizos de hospitalización continuos ser agregado).
Algunos de los pasos de procesamiento no se realizan en la memoria, sino como consultas SQLite. Esto incluye el algoritmo de marcado duplicado, la creación de hechizos y la creación de tablas de estadísticas de resumen en los datos limpios. Dependiendo del tamaño del conjunto de datos, estos pasos crean grandes bases de datos temporales de SQLite (archivos .etiqls), que se eliminan automáticamente una vez que se ha ejecutado la consulta. Por defecto, estos se crean en el directorio de inicio R, que a menudo se encuentra en una unidad con capacidad de almacenamiento restringida.
Hemos descubierto que la ejecución de la pieline falla cuando no hay suficiente almacenamiento temporal disponible (base de datos o disco de mensaje de error de mensaje de error está lleno '). Esto se puede solucionar cambiando la ubicación donde se crean bases de datos temporales de SQLite. En Windows, la ubicación de almacenamiento temporal está controlada por la variable ambiental "TMP". Recomendamos crear un archivo .Renviron de nivel de proyecto para establecer TMP en una ubicación con suficiente capacidad de almacenamiento.
data_path ruta al extracto de datos HES.
La tubería puede procesar cualquiera de los siguientes conjuntos de datos a nivel de paciente: Hes admitió atención al paciente, accidentes y emergencias, cuidados de compensación, cuidados críticos y registros de mortalidad (incluido el archivo del puente que lo vincula con Hes). Requiere al menos uno de ellos. Los archivos de datos sin procesar deben ubicarse en la misma carpeta.
database_path ruta a una carpeta donde se construirá la base de datos SQLite.
data_set_codes esperaba conjuntos de datos HES en la carpeta data_path .
Esto debería ser uno o varios de "APC", "AE", "CC" y "OP". Estos identificadores coinciden con los nombres de los archivos sin procesar, que deberían ser el caso de los archivos HED de RAW recibidos de NHS Digital. Los registros de mortalidad de ONS y los archivos del puente ONS-HES se procesan de forma predeterminada si están presentes. Los nombres de archivo para registros de mortalidad y archivos de puente deben contener "ONS" y "BF", respectivamente.
ruta expected_headers_file a un archivo CSV con los nombres de columnas esperados para cada conjunto de datos.
Este archivo CSV tiene al menos dos columnas, llamadas colnames and dataset , similar a esta plantilla. Los encabezados de la columna en los datos se capitalizan automáticamente mientras se leen los datos, por lo que los nombres de la columna en el archivo CSV deben ser todos los límites. Esta información se utilizará para verificar si cada archivo de datos sin procesar contiene todas las columnas esperadas.
Los siguientes argumentos tienen una configuración predeterminada:
Número de filas por parte de chunk_sizes para cada conjunto de datos.
Cada archivo de datos se lee y procesa en fragmentos de desafíos de varias filas. El tamaño predeterminado es de 1 millón de líneas por fragmento, pero el usuario puede modificar esto. Los tamaños de fragmentos más grandes, que resulta en un número menor de fragmentos por archivo, disminuyen el tiempo general de procesamiento. Esto probablemente se deba a que para cada fragmento en un archivo determinado, fread() necesita progresivamente más tiempo para moverse al número de fila especificado para comenzar a leer los datos. Sin embargo, los grandes tamaños de fragmentos también aumentan el tiempo para procesar cada fragmento en la memoria. El tamaño óptimo del tamaño de la fragmentación equilibra el tiempo de procesamiento con el tiempo de lectura y depende del sistema y el conjunto de datos, ya que cada conjunto de datos puede tener un número diferente de variables y, por lo tanto, requiere diferentes cantidades de memoria por fila. Se recomienda ejecutar pruebas en un subconjunto de datos más pequeño, ya que los tamaños de fragmentos muy grandes pueden hacer que Rstudio se bloquee.
Tipos de datos de coaccionamiento coerce .
De manera predeterminada, la función fread() utilizada para leer en los datos detectará automáticamente los tipos de columnas.
Alternativamente, los tipos de datos se pueden coaccionar a los tipos definidos por el usuario estableciendo este argumento en TRUE . Los tipos de columnas se suministran en la tercera columna, llamada type , en el archivo CSV con los nombres de columna esperados, consulte esta plantilla. Tenga en cuenta que SQLite no tiene un tipo de datos de fecha. Las variables de fecha deben almacenarse como caracteres y, por lo tanto, deben incluirse como caracteres en el archivo CSV.
IMD_2014_csv , IMD_2019_csv y CCG_xlsx Patinas a archivos que contienen datos de referencia que se fusionarán.
Los datos de referencia adicionales que se pueden fusionar a cada registro actualmente incluyen el índice de privación múltiple (IMD), versiones 2015 y/o 2019, e identificadores CCG. Las rutas de archivos a los archivos de referencia deben suministrarse como argumentos y se unirán en el paciente LSOA11. Los archivos CSV que contienen asignaciones LSOA11 a IMD deben tener un nombre de columna que comience con "código LSOA", un nombre de columna que contiene "índice de rango de privación múltiple (IMD)" y un nombre de columna que contiene "índice de privación múltiple (Imd) decil ". Los archivos de búsqueda para IMD 2015 e IMD 2019 se pueden descargar desde Gov.uk (archivo 7: todos los rangos, decilios y puntajes para los índices de privación y denominadores de población). El archivo de búsqueda para identificadores CCG se puede descargar desde NHS Digital (archivo: X-Cambia a las asignaciones CCG-DCO-STP con el tiempo).
update el modo de tubería de conmutación.
El modo de tubería se cambia del modo de compilación a la actualización configurando este argumento en TRUE .
duplicate Flagador de registros duplicados.
Se crearán columnas adicionales en el conjunto de datos APC, A&E y OP que indica si es probable que un registro sea un duplicado si este argumet se establece en TRUE . Las reglas de definición y derivación se pueden encontrar en (derivado_variables.md). ADVERTENCIA: Esto aumentará significativamente el tiempo de ejecución de la tubería.
comorbiditees que marcan comorbilidades.
Se crearán columnas adicionales en el conjunto de datos APC, incluidos los indicadores para condiciones individuales y puntajes ponderados y no ponderados de Charlson y Elixhauser si este argumento se establece en TRUE (también vea la documentación de la comorbilidad del paquete R). Además, las condiciones de los indicadores de la tubería relacionados con la fragilidad y calculan un índice de fragilidad personalizado (¿ver?). ADVERTENCIA: Esto aumentará significativamente el tiempo de ejecución de la tubería.
Actualmente, la tubería está diseñada para ejecutarse en una sesión RSTUDIO. Desde la consola R compile el código:
> source("pipeline.R")
Luego llame pipeline() , proporcionando como argumentos una ruta al directorio de datos, una ruta a un directorio para una base de datos SQLite, un vector de códigos de conjunto de datos, una ruta a un CSV con columnas esperadas, que incluyen códigos de conjunto de datos y tipos de datos, una opcional Vector del número de filas a leer a la vez por conjuntos de datos y, si es necesario, y un booleano para habilitar la coerción. Los datos serán procesados y escritos en la base de datos. NB Este es un proceso lento y ocupa una buena cantidad de memoria para ejecutarse.
Ejemplo de ejecución:
> pipeline(data_path = "/home/user/raw-data/", database_path = "/home/user/database-dir/", data_set_codes = c("APC", "AE", "CC", "OP"), chunk_sizes = c(2000000, 5000000, 2000000, 3000000), expected_headers_file = "/home/user/expected_columns.csv", IMD_15_csv = "IMD_2015_LSOA.csv", IMD_19_csv = "IMD_2019_LSOA.csv", CCG_xlsx = "xchanges-to-ccg-dco-stp-mappings-over-time.xlsx", coerce = TRUE, update = FALSE, duplicates = FALSE, comorbidities = FALSE)
Para las guías sobre cómo consultar bases de datos SQLite de R, por ejemplo, consulte las bases de datos del tutorial RSTUDIO utilizando R.
Se puede consultar la base de datos:
library( tidyverse )
library( dbplyr )
library ( DBI )
con <- dbConnect( RSQLite :: SQLite(), paste0( database_path , " HES_db.sqlite " ))
# List available tables
dbListTables( con )
# List available variables in the A&E table
dbListFields( con , " AE " )
# Option 1: Query using dbplyr
# Select table
AE <- tbl( con , ' AE ' )
# Look at the first 5 rows
AE % > %
head() % > %
collect()
# Option 2: Query using SQL
dbGetQuery( con , ' SELECT * FROM AE LIMIT 5 ' )
dbDisconnect( con ) Si está utilizando DBI, use la función dbGetQuery() . Evite usar funciones que puedan modificar la base de datos subyacente, como dbExecute() , dbSendQuery() o dbSendStatement() .
Este proyecto tiene licencia bajo la licencia MIT.
