HES_pipeline
1.0.0
Pipeline open source R pour nettoyer et traiter les données de la mortalité par l'hôpital de niveau patient (HES) et les données de mortalité ONS liées, dans le but de produire des ensembles de données prêts pour l'analyse pour un programme d'analyses défini.
Les statistiques des épisodes d'hôpital (HES) sont une base de données contenant des détails sur toutes les admissions hosptiales, les participations A&E et les nominations ambulatoires dans les hôpitaux du NHS en Angleterre.
Avant qu'il puisse être utilisé pour l'analyse, les données HES nécessitent le nettoyage, le contrôle de la qualité et le traitement pour dériver des variables supplémentaires. La structure record complexe de HES, le grand nombre de variables et la taille des ensembles de données en font une tâche difficile à la fois d'un point de vue analytique et de calcul.
Le flux de travail semi-automatisé que nous développons dans ce référentiel processus Hes Data de manière cohérente et reproductible, que toutes les étapes de traitement sont documentées, conçues pour garantir que chaque projets d'analyse approuvés est basé sur les mêmes données propres.
Nous utilisons des données HES liées aux données de mortalité ONS de 2008/09 jusqu'à la dernière version trimestrielle. Notre application de données a été approuvée par le service NHS Digital [Data Access Request Service Data Access Request Service (DARS).
Les données seront accessibles dans l'environnement de données sécurisé de la Fondation Health; Une installation d'analyse de données sécurisée (accréditée avec la norme de sécurité des informations ISO27001, et reconnue pour la boîte à outils NHS numérique de sécurité et de protection). Aucune information qui pourrait identifier directement un patient ou une autre personne ne sera utilisée.
Le dossier DOC contient des informations sur:
De plus, les sections ci-dessous décrivent
Comme les données HES préparées dans ce pipeline ne sont pas accessibles au public, le code ne peut pas être utilisé pour reproduire les mêmes données et base de données propres. Cependant, le code peut être utilisé sur des extraits HES au niveau du patient similaires pour préparer les ensembles de données pour l'analyse. Pour des informations plus détaillées sur le fonctionnement du pipeline ci-dessous ou se référer au document de processus.
Le document de processus décrit la conception globale du pipeline, répertorie les entrées nécessaires et une description de haut niveau des étapes du flux de travail.
L'organigramme montre comment l'entrée et les données des utilisateurs se déplacent dans les différentes fonctions de pipeline.
Le pipeline peut être exécuté en deux modes:
update = TRUE ). Les mises à jour des données HES au cours de la même année se chevauchent, donc certaines des anciennes données seront supprimées et remplacées par la nouvelle mise à jour. Les données de mortalité ONS sont complètement actualisées avec chaque mise à jour des données.En mode build , le pipeline
En mode mise à jour , le pipeline
Le dossier de décision d'architecture (ADR) capture les choix de décision et de conception architecturaux, ainsi que leur contexte, leur justification et leurs conséquences. De plus, nous avons enregistré quelques décisions analytiques.
Jusqu'à présent, nous avons enregistré des décisions concernant
Le pipeline HES a été construit sous R version 3.6.2 (2019-12-12) - "Dark and Stormy Night".
Les forfaits R suivants, qui sont disponibles sur CRAN, sont nécessaires pour exécuter le pipeline HES:
L'emplacement où la base de données est créée doit avoir suffisamment d'espace de stockage disponible, à peu près équivalent à la taille combinée du fichier de l'extrait de données HES bruts plus 2 être ajouté).
Certaines des étapes de traitement ne sont pas effectuées en mémoire mais sous forme de requêtes SQLite. Cela inclut l'algorithme de signalisation en double, la création de sorts et la création de tables de statistiques sommaires sur les données propres. Selon la taille de l'ensemble de données, ces étapes créent de grandes bases de données SQLite temporaires (fichiers .etiqls), qui sont automatiquement supprimées une fois la requête exécutée. Par défaut, ceux-ci sont créés dans le répertoire R Home, qui est souvent situé sur un lecteur avec une capacité de stockage restreinte.
Nous avons constaté que l'exécution du piéline échoue lorsque le stockage temporaire n'est pas suffisant (message d'erreur «la base de données ou le disque est complet»). Cela peut être corrigé en modifiant l'emplacement où des bases de données SQLite temporaires sont créées. Sur Windows, l'emplacement de stockage temporaire est contrôlé par la variable environnementale "TMP". Nous avons recommandé de créer un fichier .Renviron au niveau du projet pour définir TMP sur un emplacement avec une capacité de stockage suffisante.
data_path Chemin vers l'extrait de données HES.
Le pipeline peut traiter l'un des ensembles de données de niveau de patient suivants: Hes admis aux soins aux patients, accidents et urgences HES, soins hes ouptatient, soins critiques HES et dossiers de mortalité ONS (y compris le fichier de pont le liant à HES). Cela nécessite au moins l'un d'entre eux. Les fichiers de données bruts doivent être situés dans le même dossier.
database_path Path vers un dossier où la base de données SQLite sera construite.
data_set_codes ENSEMBLE DES DATAASEZ HES dans le dossier data_path .
Cela devrait être un ou plusieurs "APC", "AE", "CC" et "OP". Ces identifiants sont associés aux noms des fichiers bruts, ce qui devrait être le cas pour les fichiers HES bruts reçus de NHS Digital. Les enregistrements de mortalité ONS et les fichiers de ponts ONS-HES sont traités par défaut s'ils sont présents. Les noms de fichiers pour les enregistrements de mortalité et les fichiers de pont doivent contenir respectivement "ONS" et "BF".
PATAINS expected_headers_file vers un fichier CSV avec des noms de colonne attendus pour chaque ensemble de données.
Ce fichier CSV a au moins deux colonnes, nommées colnames et dataset , similaire à ce modèle. Les en-têtes de colonne dans les données sont automatiquement capitalisés pendant que les données sont lues, de sorte que les noms de colonne dans le fichier CSV doivent être tous les plafonds. Ces informations seront utilisées pour vérifier si chaque fichier de données brutes contient toutes les colonnes attendues.
Les arguments suivants ont un paramètre par défaut:
chunk_sizes Nombre de lignes par morceau pour chaque ensemble de données.
Chaque fichier de données est lu et traité en morceaux de défié un certain nombre de lignes. La taille par défaut est de 1 million de lignes par morceau, mais cela peut être modifié par l'utilisateur. Des tailles de morceaux plus grandes, résultant en un plus petit nombre de morceaux par fichier, diminuent le temps de traitement global. Ceci est probablement parce que pour chaque morceau dans un fichier donné, fread() a besoin progressivement plus longtemps pour passer au numéro de ligne spécifié pour commencer à lire les données. Cependant, de grandes tailles de morceaux augmentent également le temps de TAP pour traiter chaque morceau en mémoire. La taille optimale du morceau équilibre le temps de traitement avec le temps de lecture et dépend du système et de l'ensemble de données, car chaque ensemble de données peut avoir un nombre différent de variables, et nécessite donc différentes quantités de mémoire par ligne. Il est recommandé d'exécuter d'abord des tests sur un sous-ensemble de données plus petit, car de très grandes tailles de morceaux peuvent provoquer une écrasement de RSTUDIO.
coerce les types de données contraignants.
Par défaut, la fonction fread() utilisée pour lire dans les données détectera automatiquement les types de colonnes.
Alternativement, les types de données peuvent être contraints aux types définis par l'utilisateur en définissant cet argument sur TRUE . Les types de colonnes sont fournis dans la troisième colonne, appelée type , dans le fichier CSV avec les noms de colonne attendus, voir ce modèle. Notez que SQLite n'a pas de type de données de date. Les variables de date doivent être stockées en caractères et doivent donc être répertoriées comme des caractères dans le fichier CSV.
IMD_2014_csv , IMD_2019_csv et CCG_xlsx Paths vers les fichiers contenant des données de référence à fusionner.
Les données de référence supplémentaires qui peuvent être fusionnées à chaque enregistrement incluent actuellement l'indice des versions de privation multiple (IMD), 2015 et / ou 2019 et des identificateurs CCG. Les chemins des fichiers vers les fichiers de référence doivent être fournis comme arguments et seront joints sur le patient LSOA11. Les fichiers CSV contenant des mappages LSOA11 à IMD doivent avoir un nom de colonne qui commence par "Code LSOA", un nom de colonne qui contient "l'index de la privation multiple (IMD) Rank" et un nom de colonne qui contient "l'index de la privation multiple (Imd) décile ". Les fichiers de recherche pour IMD 2015 et IMD 2019 peuvent être téléchargés à partir de Gov.uk (fichier 7: tous les rangs, déciles et scores pour les indices de privation et les dénominateurs de population). Le fichier de recherche pour les identifiants CCG peut être téléchargé à partir de NHS Digital (fichier: x - modifications des mappages CCG-DCO-STP au fil du temps).
update le mode du pipeline de commutation.
Le mode Pipeline est passé du mode Build to Update en définissant cet argument sur TRUE .
duplicate Flagging Duplicat Records.
Des colonnes supplémentaires seront créées dans l'ensemble de données APC, A&E et OP qui indique si un enregistrement est susceptible d'être un duplicata si cet argume est défini sur TRUE . Les règles de définition et de dérivation peuvent être trouvées dans (Derived_variables.md). AVERTISSEMENT: Cela augmentera considérablement le temps d'exécution du pipeline.
comorbiditees signalant les comorbidités.
Des colonnes supplémentaires seront créées dans l'ensemble de données APC, y compris des drapeaux pour les conditions individuelles et les scores Charlson et Elixhauser pondérés et non pondérés si cet argument est défini sur TRUE (voir également le documentaion de la comorbidité du package R). De plus, le pipeline indique les conditions liées à la fragilité et calcule un indice de fragilité personnalisé (voir?). Avertissement: Cela augmentera considérablement le temps d'exécution du pipeline.
Actuellement, le pipeline est conçu pour s'exécuter dans une session RSTUDIO. À partir de la console R compiler le code:
> source("pipeline.R")
Ensuite, appelez pipeline() , en fournissant comme arguments un chemin d'accès au répertoire de données, un chemin d'accès à un répertoire pour une base de données SQLite, un vecteur de codes de jeu de données, un chemin d'accès à un CSV avec des colonnes attendues, des codes de jeu de données et des types de données facultatifs. Vector du nombre de lignes à lire à la fois par ensemble de données et, si nécessaire, et un booléen pour permettre la coercition. Les données seront traitées et écrites dans la base de données. NB C'est un processus lent et prend une bonne quantité de mémoire à exécuter.
Exemple de course:
> 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)
Pour des guides sur la façon de demander des bases de données SQLite de R, par exemple, consultez les bases de données du didacticiel RStudio à l'aide de R.
La base de données peut être interrogée:
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 vous utilisez DBI, utilisez la fonction dbGetQuery() . Évitez d'utiliser des fonctions qui pourraient modifier la base de données sous-jacente, telle que dbExecute() , dbSendQuery() ou dbSendStatement() .
Ce projet est autorisé sous la licence du MIT.
