HES_pipeline
1.0.0
O oleoduto R de código aberto para limpar e processar estatísticas de episódios hospitalares no nível do paciente (HES) e vincular dados de mortalidade no ONS, com o objetivo de produzir conjuntos de dados prontos para análise para um programa definido de análises.
As estatísticas do episódio do hospital (HES) são um banco de dados que contém detalhes de todas as admissões hospitalares, atendimentos de A&E e consultas ambulatoriais nos hospitais do NHS na Inglaterra.
Antes de poder ser usado para análise, os dados HES requer limpeza, controle de qualidade e processamento para derivar variáveis adicionais. A complexa estrutura de registros do HES, o grande número de variáveis e o tamanho dos conjuntos de dados fazem desta uma tarefa desafiadora, tanto do ponto de vista analítico quanto da computação.
O fluxo de trabalho semi-automatizado que estamos desenvolvendo nesse repositório processos de dados HES de forma consistente e reprodutível, que todas as etapas de processamento são documentadas, projetadas para garantir que cada projeto de análise aprovado seja baseado nos mesmos dados limpos.
Usando dados HES vinculados aos dados de mortalidade da ONS de 2008/09 até o lançamento trimestral mais recente. Nosso aplicativo de dados foi aprovado pelo NHS Digital [Serviço de Acesso ao Serviço de Acesso ao Dados (DATS Acesso ao Serviço de Acesso a Dados).
Os dados serão acessados no ambiente de dados seguro da Health Foundation; Um recurso seguro de análise de dados (credenciado com o padrão de segurança da informação ISO27001 e reconhecido pelo NHS Digital Data Security and Protection Toolkit). Nenhuma informação que possa identificar diretamente um paciente ou outro indivíduo será usado.
A pasta Doc contém informações sobre:
Além disso, seções abaixo descrevem
Como os dados HES preparados neste pipeline não estão disponíveis ao público, o código não pode ser usado para replicar os mesmos dados e banco de dados limpos. No entanto, o código pode ser usado em extratos de HES no nível do paciente semelhantes para preparar os conjuntos de dados para análise. Para obter informações mais detalhadas sobre como o pipeline funciona, consulte abaixo ou consulte o documento do processo.
O documento do processo descreve o design geral do pipeline, lista as entradas necessárias e uma descrição de alto nível das etapas no fluxo de trabalho.
O fluxograma mostra como a entrada do usuário e os dados se movem através das diferentes funções de pipeline.
O oleoduto pode ser executado em dois modos:
update = TRUE ). As atualizações de dados HES no mesmo ano estão sobrepostas; portanto, alguns dos dados antigos serão descartados e substituídos pela nova atualização. Os dados de mortalidade no ONS são completamente atualizados com cada atualização de dados.No modo de construção , o pipeline
No modo de atualização , o pipeline
O registro de decisão de arquitetura (ADR) captura as opções de decisão e design arquitetônicas, juntamente com seu contexto, lógica e consequências. Além disso, registramos algumas decisões analíticas.
Até agora, registramos decisões sobre
O oleoduto Hes foi construído sob a versão R.6.2 (2019-12-12)-"Night Dark and Stormy Night".
Os pacotes R a seguir, disponíveis em Cran, devem executar o oleoduto HES:
O local onde o banco de dados é criado precisa ter espaço de armazenamento suficiente disponível, aproximadamente equivalente ao tamanho combinado do arquivo do extrato de dados Raw HES mais 2 x tamanho do arquivo do conjunto de dados APC (como as tabelas para feitiços de pacientes internados e feitiços contínuos de pacientes serão ser adicionado).
Algumas das etapas de processamento não são executadas na memória, mas como consultas de sqlite. Isso inclui o algoritmo de sinalização duplicado, a criação de feitiços e a criação das tabelas de estatísticas de resumo nos dados limpos. Dependendo do tamanho do conjunto de dados, essas etapas criam grandes bancos de dados temporários do SQLite (arquivos .etiqls), que são excluídos automaticamente depois que a consulta for executada. Por padrão, eles são criados no diretório inicial do R, que geralmente está localizado em uma unidade com capacidade de armazenamento restrito.
Descobrimos que a execução do Pieline falha quando não há armazenamento temporário suficiente (Mensagem de erro 'Banco de dados ou disco está cheio'). Isso pode ser corrigido alterando o local onde os bancos de dados temporários do SQLite são criados. No Windows, o local de armazenamento temporário é controlado pela variável ambiental "TMP". Recomendamos criar um arquivo .renviron no nível do projeto para definir o TMP como um local com capacidade de armazenamento suficiente.
data_path Path para o extrato de dados HES.
O oleoduto pode processar qualquer um dos seguintes conjuntos de dados no nível do paciente: ele admitiu atendimento ao paciente, ele acidentes e emergências, seu atendimento ouptatiente, seus cuidados intensivos e registros de mortalidade no ONS (incluindo o arquivo de ponte que o vincula a Hes). Requer pelo menos um deles. Os arquivos de dados brutos devem estar localizados na mesma pasta.
database_path Path para uma pasta em que o banco de dados SQLite será criado.
data_set_codes Os conjuntos de dados HES esperados na pasta data_path .
Este deve ser um ou vários "APC", "AE", "CC" e "OP". Esses identificadores são correspondidos aos nomes dos arquivos brutos, o que deve ser o caso dos arquivos Raw Hes recebidos do NHS Digital. Os registros de mortalidade no ONS e os arquivos da ponte ONS-HES são processados por padrão, se presente. Os nomes dos arquivos para registros de mortalidade e arquivos de ponte devem conter "ONS" e "BF", respectivamente.
PATH expected_headers_file para um arquivo CSV com nomes de colunas esperados para cada conjunto de dados.
Este arquivo CSV possui pelo menos duas colunas, denominadas colnames e dataset , semelhante a este modelo. Os cabeçalhos da coluna nos dados são capitalizados automaticamente enquanto os dados são lidos, portanto, os nomes das colunas no arquivo CSV devem ser todos os Caps. Essas informações serão usadas para verificar se cada arquivo de dados bruto contém todas as colunas esperadas.
Os argumentos a seguir têm uma configuração padrão:
chunk_sizes Número de linhas por pedaço para cada conjunto de dados.
Cada arquivo de dados é lido e processado em pedaços de desafiar várias linhas. O tamanho padrão é de 1 milhão de linhas por pedaço, mas isso pode ser modificado pelo usuário. Tamanhos de bloco maiores, resultando em um número menor de pedaços por arquivo, diminuindo o tempo geral de processamento. Provavelmente, é porque, para cada pedaço em um determinado arquivo, fread() precisa progressivamente para passar para o número da linha especificado para começar a ler os dados. No entanto, grandes tamanhos de pedaços também aumentam o tempo que leva para processar cada pedaço na memória. O tamanho ideal do tamanho do pedaço equilibra o tempo de processamento do tempo de leitura e depende do sistema e do conjunto de dados, pois cada conjunto de dados pode ter um número diferente de variáveis e, portanto, requer diferentes quantidades de memória por linha. Recomenda -se executar testes em um subconjunto menor de dados primeiro, pois os tamanhos de pedaços muito grandes podem fazer com que o RSTUDIO caia.
coerce coagir Tipos de dados.
Por padrão, a função fread() usada para ler nos dados detectará automaticamente os tipos de coluna.
Como alternativa, os tipos de dados podem ser coagidos a tipos definidos pelo usuário, definindo esse argumento como TRUE . Os tipos de colunas são fornecidos na terceira coluna, chamada type , no arquivo CSV com os nomes esperados de colunas, consulte este modelo. Observe que o SQLite não possui um tipo de dados de data. As variáveis de data precisam ser armazenadas como caracteres e, portanto, devem ser listadas como caracteres no arquivo CSV.
IMD_2014_csv , IMD_2019_csv e CCG_xlsx CATOS PARA ARQUIVOS CONTENDO os dados de referência a serem mesclados.
Os dados de referência adicionais que podem ser mesclados a cada registro atualmente incluem o índice de versões de privação múltipla (IMD), 2015 e/ou 2019 e identificadores de CCG. Os caminhos dos arquivos para os arquivos de referência devem ser fornecidos como argumentos e serão unidos no paciente LSOA11. Os arquivos CSV contendo mapeamentos LSOA11-T-IMD precisam ter um nome de coluna que começa com "Código LSOA", um nome de coluna que contém "Índice de Privação Múltipla (IMD)" e um nome de coluna que contém "índice de privação múltipla de privação (IMD) decil ". Os arquivos de pesquisa para o IMD 2015 e o IMD 2019 podem ser baixados do Gov.uk (Arquivo 7: todas as classificações, deciles e pontuações para os índices de privação e denominadores populacionais). O arquivo de pesquisa para identificadores de CCG pode ser baixado do NHS Digital (Arquivo: X-Alterações nos mapeamentos CCG-DCO-STP ao longo do tempo).
update o modo de tubulação do interruptor.
O modo de pipeline é alterado do modo Build to Atualize, definindo esse argumento como TRUE .
duplicate registros duplicados de sinalização.
Colunas adicionais serão criadas no conjunto de dados APC, A&E e OP que indicam se um registro provavelmente será um duplicado se esse argumet estiver definido como TRUE . As regras de definição e derivação podem ser encontradas em (Derived_variables.md). Aviso: isso aumentará significativamente o tempo de execução do pipeline.
comorbiditees sinalizando comorbidades.
Colunas adicionais serão criadas no conjunto de dados da APC, incluindo sinalizadores para condições individuais e pontuações ponderadas e não ponderadas de Charlson e Elixhauser se esse argumento for definido como TRUE (consulte também a documentação da comorbidade do pacote R). Além disso, os sinalizadores de pipeline estão relacionados à fragilidade e calcula um índice de fragilidade personalizado (veja?). Aviso: isso aumentará significativamente o tempo de execução do pipeline.
Atualmente, o pipeline foi projetado para ser executado em uma sessão RStudio. Do console R compilar o código:
> source("pipeline.R")
Em seguida, ligue para pipeline() , fornecendo como argumentos um caminho para o diretório de dados, um caminho para um diretório para um banco de dados sqlite, um vetor de códigos de dados, um caminho para um CSV com colunas esperadas, incluindo códigos de dados e tipos de dados, um opcional vetor do número de linhas a serem lidas no momento por conjunto de dados e, se necessário, e um booleano para permitir a coerção. Os dados serão processados e gravados no banco de dados. NB Este é um processo lento e ocupa uma boa quantidade de memória para ser executada.
Exemplo de execução:
> 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 guias sobre como consultar bancos de dados SQLite de R, por exemplo, consulte os bancos de dados tutoriais do RSTUDIO usando R.
O banco de dados pode ser consultado:
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 ) Se você estiver usando o DBI, use a função dbGetQuery() . Evite usar funções que possam modificar o banco de dados subjacente, como dbExecute() , dbSendQuery() ou dbSendStatement() .
Este projeto está licenciado sob a licença do MIT.
