dmhct

{dmhct} extracts and prepares data for the MLinHCT project. The main functionality is wrapped into a single function, dm_hct(), that produces a dm object (from the {dm} package) containing cleaned data tables from an SQL Server database.

Installation and Setup

You can install {dmhct} from Github with:

# install.packages("remotes")
# remotes::install_github("jesse-smith/dmhct")
install.packages("dmhct", repos = c('https://jesse-smith.r-universe.dev', 'https://cloud.r-project.org'))

To use the package, you will need access to the SQL Server instance containing the data. This is provided by St. Jude IT; contact Jesse Smith to learn how to gain access.

Introduction

{dmhct} is designed to get data from the SQL server database to your local machine in a standardized fashion. As noted above, the main entry point to this functionality is the dm_hct() function, which may be all you ever need to use. It wraps the entire pipeline into a single call:

library(dmhct)
dm <- dm_hct()
#> Creating remote `dm` object
#> Extracting database tables (1/4)
#> Extracting `adverse_events_v2`
#> Extracting `adverse_events_v3`
#> Extracting `adverse_events_v4_1`
#> Extracting `adverse_events_v4_2`
#> Extracting `cerner_obs`
#> Extracting `cerner1`
#> Extracting `cerner2`
#> Extracting `cerner3`
#> Extracting `chimerism`
#> Extracting `death`
#> Extracting `disease_status`
#> Extracting `encounters`
#> Extracting `engraftment`
#> Extracting `gvhd`
#> Extracting `hla_donor`
#> Extracting `hla_patient`
#> Extracting `master`
#> Extracting `mrd`
#> Extracting `prior_transplant`
#> Extracting `relapse`
#> Done.
#> Standardizing table columns (2/4)
#> Standardizing `adverse_events_v2`
#> Standardizing `adverse_events_v3`
#> Standardizing `adverse_events_v4_1`
#> Standardizing `adverse_events_v4_2`
#> Standardizing `cerner_obs`
#> Standardizing `cerner1`
#> Standardizing `cerner2`
#> Standardizing `cerner3`
#> Standardizing `chimerism`
#> Standardizing `death`
#> Standardizing `disease_status`
#> Standardizing `encounters`
#> Standardizing `engraftment`
#> Standardizing `gvhd`
#> Standardizing `hla_donor`
#> Standardizing `hla_patient`
#> Standardizing `master`
#> Standardizing `mrd`
#> Standardizing `prior_transplant`
#> Standardizing `relapse`
#> Combining similar tables (3/4)
#> Combining `cerner1`, `cerner2`, `cerner3`
#> Combining hla_donor, hla_patient
#> Done.
#> Pivoting E-A-V tables (4/4)
#> Pivoting `hla`
#> Done.
dm
#> ── Metadata ────────────────────────────────────────────────────────────────────
#> Tables: `adverse_events_v2`, `adverse_events_v3`, `adverse_events_v4_1`, `adverse_events_v4_2`, `cerner`, … (17 total)
#> Columns: 332
#> Primary keys: 0
#> Foreign keys: 0

The pipeline can be decompsed into 4 steps, which are each responsible for a set of tasks:

  1. dm_extract() pulls the database from the SQL server onto your local machine
  2. dm_standardize() ensures that column names, types, and contents are consistent and in a standard format
  3. dm_combine() combines certain sets of tables into single tables
  4. dm_pivot() pivots long-format datasets that can be widened without losing information

Running these functions in order will produce the same results as running dm_hct():

dm2 <- dm_extract() %>%
  dm_standardize() %>%
  dm_combine() %>%
  dm_pivot()
#> Creating remote `dm` object
#> Extracting `adverse_events_v2`
#> Extracting `adverse_events_v3`
#> Extracting `adverse_events_v4_1`
#> Extracting `adverse_events_v4_2`
#> Extracting `cerner_obs`
#> Extracting `cerner1`
#> Extracting `cerner2`
#> Extracting `cerner3`
#> Extracting `chimerism`
#> Extracting `death`
#> Extracting `disease_status`
#> Extracting `encounters`
#> Extracting `engraftment`
#> Extracting `gvhd`
#> Extracting `hla_donor`
#> Extracting `hla_patient`
#> Extracting `master`
#> Extracting `mrd`
#> Extracting `prior_transplant`
#> Extracting `relapse`
#> Standardizing `adverse_events_v2`
#> Standardizing `adverse_events_v3`
#> Standardizing `adverse_events_v4_1`
#> Standardizing `adverse_events_v4_2`
#> Standardizing `cerner_obs`
#> Standardizing `cerner1`
#> Standardizing `cerner2`
#> Standardizing `cerner3`
#> Standardizing `chimerism`
#> Standardizing `death`
#> Standardizing `disease_status`
#> Standardizing `encounters`
#> Standardizing `engraftment`
#> Standardizing `gvhd`
#> Standardizing `hla_donor`
#> Standardizing `hla_patient`
#> Standardizing `master`
#> Standardizing `mrd`
#> Standardizing `prior_transplant`
#> Standardizing `relapse`
#> Combining `cerner1`, `cerner2`, `cerner3`
#> Combining hla_donor, hla_patient
#> Pivoting `hla`

identical(dm, dm2)
#> [1] FALSE

Changes from previous versions

The previous iteration of this package used the dm_elt() function as the wrapper and attempted to thoroughly clean all datasets. Unfortunately, this requires many ad hoc decisions, hard-coded transformations, and frequent revisions; the resulting codebase was very difficult to maintain and frequently made decisions that would be better left to the user. The updated version of this package attempts to do much less; its goal is to provide the database in a standardized format, with all information from the original data preserved. This passes the task of interpreting the data to the user.

Note that dm_elt() and its components are still exported; dm_extract(.legacy = TRUE) and dm_transform() are the components of this pipeline. However, these functions (and the .legacy argument of dm_extract()) are deprecated, and their use is discouraged.

Variable Typing System

Variables names are snakecased, with a prefix describing the content of the variable. This mostly maps to familiar R classes: num_ and pct_ variables are numeric (with pct_ taking values between 0 and 100), lgl_ variables are logical, and chr_ variables are character. There are exceptions, though; these come in two forms. The first are variable prefixes that could map to an R type, but do not because the underlying data may need additional cleaning. This is currently true for cat_ variable, which are conceptually factors but are stored as character, and dt_ variables, which may be stored as either Date or POSIXct class, depending on whether time information is included. The second form of exception are variables that have no equivalent base R type; this is currently true for mcat_ variables, which represent categorical variables that can take multiple values simultaneously, and intvl_ variables, which are interval-valued numerics. Both are stored as character, with mcat_ values separated by a comma and intvl_ represented in standard interval notation.

Helper Functions

{dmhct} exports several sets of helper functions. These are used internally to make data extraction and cleaning a bit easier. The functions are listed below; see each function’s documentation for more information.

Data cleaning

Database Interaction