REDCapTidieR

Making analysts lives easier through the power of tidy tibbles

Richard Hanna

8/18/22

Who am I?

• CGT DataOps Data Scientist
• 5 years at CHOP
• Engineering background
• Trying to implement quarto today¹

I am a data scientist in the Cell & Gene Therapy Data Operations team. I joined CHOP about 5 years ago coming from a mechanical engineering background and about 4 years ago found my way into coding with R to solve problems, make products, you name it. Around that same time I met Stephan Kadauke who leads the DataOps team and helped found the R User Group and that more or less brings me in front of you today.

Around the same time I started using R I was working with REDCap, and I found that the two go hand in hand rather well. Today I’m excited to talk to you about a package we’re developing that, for those of you also working with both R and REDCap, may hopefully become a useful tool to help your analytic processes.

A quick shoutout also to Jake Riley. This is my first time doing a quarto presentation (quarto is the new rmarkdown) and he helped considerably with my frustrations over getting tables to render better in the slides. So thanks Jake!

1. Huge shoutout to Jake Riley for helping troubleshoot quarto and kableExtra

R / Medicine 2022

https://events.linuxfoundation.org/r-medicine/

Real quick, before we jump into our talk wanted to give a brief announcement to remind or alert everyone to the upcoming R / Medicine conference. This will be an entirely virtual conference with the first two days dedicated to some excellent workshops and a series of speakers for the latter two, all of which can be found on the schedule at the website here.

R / Medicine 2022 - Workshops

Discount Code: RMED22CHOP for 10% off!

R / Medicine 2022 - Speaker Highlights

• Stephan Kadauke (CHOP CGT DataOps)

  • R/Medicine 101: Intro to R for Clinical Data

  • Should we Teach Data Science to Physicians-in-Training?

• Joy Payton (CHOP Arcus Education)
  • Using Public Data and Maps for Powerful Data Visualizations
• Lihai Song (CHOP Data Scientist)
  • Automation of statistics summary and analysis using R Shiny
• Jaclyn Janis (RStudio/Posit, CHOP Representative)
  • It’s time for nurses to learn R

We also have some familiar faces who will be delivering workdshops and talks including Stephan Kadauke, Joy Payton, and Lihai Song from CHOP as well as Jaclyn Janis our customer success rep from RStudio (now known as Posit).

Agenda

In today’s talk we will:

• Review what REDCap is 💡
• Review REDCapR as an extraction tool for the API 🔌
• Implement REDCapTidieR to make our lives easier 🧹

What you need:

• Familiarity with R 💻
• Familiarity with REDCap 🧢

Today’s talk will primarily be beneficial to those of you who have some familiarity with R, namely how to work your way around with the tidyverse and especially those familiar with the REDCapR package, but we will also briefly touch on what REDCap is, how REDCapR works, and the use case that called for REDCapTidieR in the first place.

What is REDCap?

• Free¹ database solution for research
• Secure and accessible from a web browser
• Can collect “any type of data in any environment”
• Particularly useful for compliance with 21 CFR Part 11, HIPAA, etc.
• Requires little to get up and running, but offers complexity as needed

REDCap is a powerful database solution used by many research institutions. The web interface offers a secure, accessible way to architect databases of varying complexity at no cost to the institution for joining the REDCap consortium.

You can access REDCap on the web from anywhere, and it can store any data you can realistically imagine for research purposes. It is also attractive to research institutions for being capable of clearance for various compliance requirements.

In my opinion, REDCap is strongest in it’s front end UI ability to supply users with the tools to make databases quickly and with plenty of customization, but also provides complexity to those who wish to use it.

1. For participants of the REDCap consortium

What is REDCap?

Record Status Dashboard

Front-End Data Entry UI

REDCap functions as a large data table, but data distribution can be complex depending on architectural choices.

Repeating instances can create headaches on the backend.

The REDCap front-end consists of many tools but the two we’re interested in are the top-level database display, known as the record status dashboard, and the actual area that data entry personnel enter data.

Here on the left is a visual representation of what essentially amounts to a tabular structure. We have a record ID, and two “instruments” with underlying data. The first is a single sub-table or “form”, while the second is stacked or “repeating.” We’ll touch more on these shortly but they can be a bit cumbersome to work with.

On the right is a drilled-down display where the data gets entered. Here we see all of the Heroes Information associated with Record ID number 0. You can think of these as the column data elements tied to a single row for the hero A-Bomb.

Because of this, as mentioned earlier, REDCap can be about as complex as you want or need it to be.

The Super Heroes Dataset

Open source dataset from SuperHeroDB and available on Kaggle. It contains two tables:

• Super Hero Information (i.e. demographic data)
• Super Hero Powers (i.e. TRUE/FALSE for specific powers)

So by now you’ve noticed we aren’t using patient data, so it’s worth briefly touching on the data we are using. We will be using open source super hero data from SuperHeroDB, delivered via Kaggle. There are two CSV tables available where one contains Hero Information like name, height, weight, eye color, etc. and the other contains a wide table pairing hero names to a boolean of specific powers.

Next let’s look at how we’re actually going to extract this data using the REDCapR package

On the Shoulders of Giants

Some core REDCapR functions:

• redcap_read_oneshot
• redcap_metadata_read
• redcap_event_instruments
  • New as of v1.1.0

Requirements:

• Active REDCap project
• A REDCap API URI¹
• API token²

We’ve been using REDCapR extensively for a while, and at it’s core the package does all the heavy lifting required to extract data and metadata on a REDCap project from the R console. If we all stand on the shoulders of giants, then REDCapR is the giant that REDCapTidieR has to thank.

To get started with API calls through these packages, you need a couple of things. First, an active REDCap database or project. Second, a REDCap API URI (in our case redcap.chop.edu/api/). Third an API token, since this is associated to your user rights you need to make sure you have the appropriate read/write privileges.

Let’s assume I’ve already done the work of preparing and importing this into a REDCap database so we can see what an export of the data looks like via REDCapR.

1. Such as https://redcap.chop.edu/api/

2. Requires user API and Read/Write access

SuperHeroes Output

# Load applicable libraries:
library(dplyr)
library(REDCapR)

superheroes_db <- redcap_read_oneshot(redcap_uri, token, verbose = FALSE)$data

superheroes_db %>% 
  glimpse()

Rows: 6,700
Columns: 16
$ record_id                   <dbl> 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, …
$ redcap_repeat_instrument    <chr> NA, "super_hero_powers", "super_hero_power…
$ redcap_repeat_instance      <dbl> NA, 1, 2, 3, 4, 5, 6, 7, NA, 1, 2, 3, 4, 5…
$ name                        <chr> "A-Bomb", NA, NA, NA, NA, NA, NA, NA, "Abe…
$ gender                      <chr> "Male", NA, NA, NA, NA, NA, NA, NA, "Male"…
$ eye_color                   <chr> "yellow", NA, NA, NA, NA, NA, NA, NA, "blu…
$ race                        <chr> "Human", NA, NA, NA, NA, NA, NA, NA, "Icth…
$ hair_color                  <chr> "No Hair", NA, NA, NA, NA, NA, NA, NA, "No…
$ height                      <dbl> 203, NA, NA, NA, NA, NA, NA, NA, 191, NA, …
$ weight                      <dbl> 441, NA, NA, NA, NA, NA, NA, NA, 65, NA, N…
$ publisher                   <chr> "Marvel Comics", NA, NA, NA, NA, NA, NA, N…
$ skin_color                  <chr> "-", NA, NA, NA, NA, NA, NA, NA, "blue", N…
$ alignment                   <chr> "good", NA, NA, NA, NA, NA, NA, NA, "good"…
$ heroes_information_complete <dbl> 0, NA, NA, NA, NA, NA, NA, NA, 0, NA, NA, …
$ power                       <chr> NA, "Accelerated Healing", "Durability", "…
$ super_hero_powers_complete  <dbl> NA, 0, 0, 0, 0, 0, 0, 0, NA, 0, 0, 0, 0, 0…

Remember redcap_repeat_instrument and redcap_repeat_instance, they’re coming back!

Let’s first load some applicable libraries and extract both the data and metadata of the database. A glimpse of the database shows us 6,700 rows with 16 columns, but oddly we seem to have a lot of NAs/missing data. And what might be a little more confusing is that our record_IDs are being repeated a number of times.

Lastly, there are two variables here (redcap_repeat_instrument and redcap_repeat_instance) which weren’t in our original database from the user side. They’ll be coming up a lot today.

Let’s look at a tibble structure to see if we can piece why this is.

SuperHeroes Output

# View first 10 entries of SuperHeroes db tibble
superheroes_db %>% 
  head(10)

record_id	redcap_repeat_instrument	redcap_repeat_instance	name	gender	eye_color	race	hair_color	height	weight	publisher	skin_color	alignment	heroes_information_complete	power	super_hero_powers_complete
0	NA	NA	A-Bomb	Male	yellow	Human	No Hair	203	441	Marvel Comics	-	good	0	NA	NA
0	super_hero_powers	1	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	Accelerated Healing	0
0	super_hero_powers	2	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	Durability	0
0	super_hero_powers	3	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	Longevity	0
0	super_hero_powers	4	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	Super Strength	0
0	super_hero_powers	5	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	Stamina	0
0	super_hero_powers	6	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	Camouflage	0
0	super_hero_powers	7	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	Self-Sustenance	0
1	NA	NA	Abe Sapien	Male	blue	Icthyo Sapien	No Hair	191	65	Dark Horse Comics	blue	good	0	NA	NA
1	super_hero_powers	1	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	NA	Agility	0

Perhaps still confusing, but we can at least see a pattern here. Now we can see how all of the NA’s trade off with the redcap_repeat_* variables. Notice how the first row for record_id 0 has all of its hero information filled out, but the repeat variables are NA, and then for the remainder of record_id 0’s rows that behavior reverses.

I want to call out a few things here, this is the way REDCap presents you with a raw database. It’s one massive table, not always the most intuitive, and perhaps not even what we originally expect. This can be very cognitively overloading and a barrier to getting started with working with your data. The introduction of repeating instruments, as shown here, further complicates this.

REDCap Repeating Instruments

Record Status Dashboard

Front-End Data Entry UI

From the user side, this is what a repeating instance and associated instrument look like. Here on the left we have the same record status dashboard but now we have details expanded for two super power forms. Now we can see that heroes can have multiple powers, and heroes can have a different number of powers assigned to them as shown by 7 assigned to A-Bomb while only 3 are assigned to Adam Monroe.

On the drilled-down UI side, while small (my apologies),

Next

we see that A-Bomb’s first power is “Accelerated Healing” under instance 1. The repeating form is a single text box entry field but can be repeated any number of times.

SuperHeroes Repeating Output

superheroes_db %>% 
  filter(record_id == 0) %>% 
  select(record_id, contains("redcap_"), name, power)

record_id	redcap_repeat_instrument	redcap_repeat_instance	name	power
0	NA	NA	A-Bomb	NA
0	super_hero_powers	1	NA	Accelerated Healing
0	super_hero_powers	2	NA	Durability
0	super_hero_powers	3	NA	Longevity
0	super_hero_powers	4	NA	Super Strength
0	super_hero_powers	5	NA	Stamina
0	super_hero_powers	6	NA	Camouflage
0	super_hero_powers	7	NA	Self-Sustenance

record_id, redcap_repeat_instrument, and recap_repeat_instance form a compound key.

A compound key is the combination of 2+ columns necessary to identify a row uniquely in a table

So if we revisit record_id 0, and select variables of interest we can see that his hero information is only associated with non-repeating rows while each of his powers information gets a separate row associated with what repeat instrument and instance it belongs to.

Next

Because of this structure, once repeating instruments are introduced to REDCap they form what’s known as a compound key for identifying individual observations. You can’t rely on the record_id anymore, even though its the primary identifier for our hero.

Next

compound keys are combinations of 2 or more columns that together give the information necessary to uniquely identify a row in a table.

The Problem

• Empty data introduced as an artifact of repeating instruments
• Data export is often times large and unwieldy
• Missing metadata linking field association to instruments
• Row identification is confusing and inconsistent

There are a number of problems with this which anyone here who has worked with repeating instruments or longitudinal REDCap projects has probably run into.

First: empty data shown by all those NA values is not actually indicative of missingness, instead this is an artifact introduced as a side effect of having these compound keys tied to repeating instruments. This can force analysts to go back and either recreate data they need or jump through hoops to make up for data sparsity.

Second: Data exports often wind up becoming much larger than anticipated because of how many rows get introduced, making exports messy and unwieldy.

Third: Without an innate link to the metadata, it isn’t possible from the data export to determine what forms are linked to what instrument. This can be a problem in longitudinal studies when you want to reference variables that only appear in specific events.

Fourth: Row identification is confusing and inconsistent. As we saw, compound keys make for variable row identifiers that may or may not contain all of the data analysts need.

Introducing REDCapTidieR

At a glance:

• Built on top of REDCapR
• Takes two inputs: REDCap URI and REDCap API token
• Returns a set of tidy tibbles
  • One for each REDCap instrument

So we went over the problem, now let’s bring in the solution: REDCapTidieR. At a glance, there are only two main functions relying on the same two inputs from REDCapR: a URI and a valid API token. Under the hood, the package relies on REDCapR for all data extraction but instead does all the work of taking that large, messy table and turning it into a series of tidy tibbles for each project instrument.

• tibbles FYI are just tidy ways of displaying dataframes.

Revisiting Superheroes

library(REDCapTidieR)
superheroes_tidy <- read_redcap(redcap_uri, token)

superheroes_tidy

# A tibble: 2 × 10
  redcap_form_name   redcap_form_label  redcap_data redcap_metadata    structure
  <chr>              <chr>              <list>      <list>             <chr>    
1 heroes_information Heroes Information <tibble>    <tibble [11 × 17]> nonrepea…
2 super_hero_powers  Super Hero Powers  <tibble>    <tibble [2 × 17]>  repeating
# ℹ 5 more variables: data_rows <int>, data_cols <int>, data_size <lbstr_by>,
#   data_na_pct <formttbl>, form_complete_pct <formttbl>

The core REDCapTidieR function is read_redcap, and here we can see the output which might look a little odd, but it’s definitely less overwhelming than the giant table we saw earier. What we have is a tibble where on the left we have the raw names of the instruments from REDCap, these were the two colorful columns on the Record Status Dashboard. On the right is the structure, i.e. “repeating” or “nonrepeating.”

Here in the middle, under data is where processed data resides in a list column.

Revisiting Superheroes

Non-Repeating Hero Information

superheroes_tidy$redcap_data[[2]] %>% 
  head(10)

record_id	redcap_form_instance	power	form_status_complete
0	1	Accelerated Healing	Incomplete
0	2	Durability	Incomplete
0	3	Longevity	Incomplete
0	4	Super Strength	Incomplete
0	5	Stamina	Incomplete
0	6	Camouflage	Incomplete
0	7	Self-Sustenance	Incomplete
1	1	Agility	Incomplete
1	2	Accelerated Healing	Incomplete
1	3	Cold Resistance	Incomplete

Repeating Hero Powers

superheroes_tidy$redcap_data[[1]] %>% 
  head(10)

record_id	name	gender	eye_color	race	hair_color	height	weight	publisher	skin_color	alignment	form_status_complete
0	A-Bomb	Male	yellow	Human	No Hair	203	441	Marvel Comics	-	good	Incomplete
1	Abe Sapien	Male	blue	Icthyo Sapien	No Hair	191	65	Dark Horse Comics	blue	good	Incomplete
2	Abin Sur	Male	blue	Ungaran	No Hair	185	90	DC Comics	red	good	Incomplete
3	Abomination	Male	green	Human / Radiation	No Hair	203	441	Marvel Comics	-	bad	Incomplete
4	Abraxas	Male	blue	Cosmic Entity	Black	-99	-99	Marvel Comics	-	bad	Incomplete
5	Absorbing Man	Male	blue	Human	No Hair	193	122	Marvel Comics	-	bad	Incomplete
6	Adam Monroe	Male	blue	-	Blond	-99	-99	NBC - Heroes	-	good	Incomplete
7	Adam Strange	Male	blue	Human	Blond	185	88	DC Comics	-	good	Incomplete
8	Agent 13	Female	blue	-	Blond	173	61	Marvel Comics	-	good	Incomplete
9	Agent Bob	Male	brown	Human	Brown	178	81	Marvel Comics	-	good	Incomplete

If we expand the list column elements through indexing, we can take a deeper look at the nonrepeating and repeating dataframe outputs. There are a number of things worth noting here:

1. First in both of these tables we see there are no artificially generated NA artifact values.
2. On the left side, the non-repeating table shows that every record_id has a single row. On the right are repeating record_ids forming a compound key with the redcap_repeat_instance
3. Additionally, the redcap_repeat_ variables only appear in repeating sub tables.
4. This means that only the variables associated with the table will appear in it.
5. The presence of the primary key in the nonrepeating hero information table, and the compound key in the repeating hero powers table allows for easy joining.

While this example REDCap only has two tables, most are going to have much more and it is very powerful to be able to join only the data you need and trust that the output contains all the relevant information.

Revisiting Superheroes

Non-Repeating Hero Information

superheroes_tidy$redcap_data[[2]] %>% 
  head(5)

record_id	---	form_status_complete
0	...	Incomplete
0	...	Incomplete
0	...	Incomplete
0	...	Incomplete
0	...	Incomplete

Repeating Hero Powers

superheroes_tidy$redcap_data[[1]] %>% 
  head(5)

record_id	---	form_status_complete
0	...	Incomplete
1	...	Incomplete
2	...	Incomplete
3	...	Incomplete
4	...	Incomplete

Change in *_form_status_complete to form_status_complete

One other thing I’d like to point out for those familiar with REDCap is the simplification of the form status completion variable. Typically in a REDCap output you’ll have a “x_form_status_complete” indicating whether a form is complete, incomplete, or unverified.

Since the name of the form is indicated in the super tibble, we have a single variable that doesn’t change name to indicate completeness. This can be helpful if, for example, you’re relying on only complete data for analysis or want to check on the progression of data entry in your project. The form_status_complete variable will always be located at the end of the dataframe.

The Default Output

library(REDCapTidieR)
superheroes_tidy <- read_redcap(redcap_uri, token)

superheroes_tidy

# A tibble: 2 × 10
  redcap_form_name   redcap_form_label  redcap_data redcap_metadata    structure
  <chr>              <chr>              <list>      <list>             <chr>    
1 heroes_information Heroes Information <tibble>    <tibble [11 × 17]> nonrepea…
2 super_hero_powers  Super Hero Powers  <tibble>    <tibble [2 × 17]>  repeating
# ℹ 5 more variables: data_rows <int>, data_cols <int>, data_size <lbstr_by>,
#   data_na_pct <formttbl>, form_complete_pct <formttbl>

However, indexing isn’t always the best way to go about data extraction. So while the initial tibble we showed earlier is extremely helpful we wanted to also provide a way to make the data accessible.

bind_tables Direct to Environment

The function:

# How `bind_tables()` is called:
bind_tables <- function(.data,
                        environment = global_env(),
                        redcap_form_name = NULL,
                        structure = NULL)
  
  # How it looks in practice:
  read_redcap_tidy(redcap_uri, token) %>% 
  bind_tables()

Clear out our envionrment:

rm(list = ls())
ls.str(envir = globalenv())

Empty output, no global environment objects

Reload the superheroes_tidy dataset, pipe to bind_tables, check environment:

superheroes_tidy %>%
  bind_tibbles()

ls.str(envir = globalenv())

heroes_information : tibble [734 × 12] (S3: tbl_df/tbl/data.frame)
super_hero_powers : tibble [5,966 × 4] (S3: tbl_df/tbl/data.frame)
superheroes_tidy : suprtbl [2 × 10] (S3: redcap_supertbl/tbl_df/tbl/data.frame)

The second main function we’ve introduced to REDCapTidieR is Stephan’s brain child. Using the bind_tibbles helper function, we can take the table outputs of the redcap_data column from our TidieR output and place them directly into the global environment or any environment of our choosing.

For those of you who don’t know, environments are essentially a variant of lists in R. The most common one you probably work with is the global environment displayed in the panel of your RStudio IDE, but you can also make other environments to call from.

For this function, you can specify an environment to load to, the repeat/nonrepeat structure you’re interested in, and any specific tables. However, the default behavior with no arguments supplied will load directly to the global environment with all available objects.

bind_tables Direct to Environment

And if you’re used to looking at your environment in RStudio, this is exactly the same as taking your environment window pane on the left and populating it with the objects on the right.

Longitudinal REDCap Projects

	Classic	Longitudinal, one arm	Longitudinal, multi-arm
Nonrepeated	record_id	record_id + redcap_event	record_id + redcap_event + redcap_arm
Repeated	record_id + redcap_repeat_instance	record_id + redcap_repeat_instance + redcap_event	record_id + redcap_repeat_instance + redcap_event + redcap_arm

Now that we have some familiarity with REDCap, its outputs, and what we can expect REDCapTidieR to achieve, I know what you’re asking yourself: but Rich, what about longitudinal REDCap projects with multiple arms? Well don’t worry, because REDCapTidieR handles that too.

If you don’t know what I’m talking about, this table helps break down the three main archetypes of REDCap projects and their repeating/nonrepeating counterparts. There are “Classic” projects which have no longitudinal elements, i.e. no events or arms. There are longitudinal projects with no arms, or 1 by default. And there are projects with many.

We’re already familiar with record_id and redcap_repeat_instance/instrument. What longitudinal events and arms add are these corresponding event and arm variables that further expand our compound keys. So what you see here are all of the required variables necessary to uniquely identify a row in a project type.

REDCap Projects with Arms

redcap_long_arms_tidy <- read_redcap(redcap_uri, token)

redcap_long_arms_tidy

# A tibble: 3 × 11
  redcap_form_name redcap_form_label redcap_data redcap_metadata   redcap_events
  <chr>            <chr>             <list>      <list>            <list>       
1 nonrepeated      Nonrepeated       <tibble>    <tibble [3 × 17]> <tibble>     
2 nonrepeated2     Nonrepeated2      <tibble>    <tibble [3 × 17]> <tibble>     
3 repeated         Repeated          <tibble>    <tibble [3 × 17]> <tibble>     
# ℹ 6 more variables: structure <chr>, data_rows <int>, data_cols <int>,
#   data_size <lbstr_by>, data_na_pct <formttbl>, form_complete_pct <formttbl>

In the front end UI, we have a rudimentary mockup of a database that has all of these elements as well as multiple arms. Notice the inclusion of Events 1, 2, and 3 and Arms 1 and 2 in separate tabs. You can also notice here how things get pretty complicated. Records 1-3 appear in Arm1, events 1 and 2, but Record 4 is only Arm2, events 1 and 3.

The output of a read_redcap_tidy call is still the same. The forms we expect appear in the form names, we have dataframe elements, and indicative structure details.

REDCap Projects with Arms

redcap_long_arms_tidy$redcap_data[[1]]

record_id	redcap_event	redcap_arm	nonrepeat_1	nonrepeat_2	form_status_complete
1	event_1	1	1	2	Incomplete
1	event_2	1	1	2	Incomplete
2	event_1	1	A	B	Incomplete
2	event_2	1	5	6	Incomplete
4	event_1	2	Red	Blue	Incomplete
4	event_3	2	Green	Yellow	Incomplete

redcap_long_arms_tidy$redcap_data[[3]]

record_id	redcap_event	redcap_arm	redcap_form_instance	repeat_1	repeat_2	form_status_complete
1	event_1	1	1	1	2	Incomplete
1	event_1	1	2	3	4	Incomplete
1	event_1	1	3	5	6	Incomplete
1	event_2	1	1	A	B	Incomplete
1	event_2	1	2	C	D	Incomplete
3	event_1	1	1	C	D	Incomplete
3	event_2	1	1	E	F	Incomplete
3	event_2	1	2	G	H	Incomplete
4	event_3	2	1	R1	R2	Incomplete

And on the backend, despite all this added complexity, the really nice thing is all that’s changed is the addition of redcap_event and redcap_arm which are just two more elements needed for your compound key joins for unique row identification.

One thing I’ll note is REDCapTidieR as a default will automatically detect and remove the arm variable if only 1 arm exists in your longitudinal project.

Try it for Yourself!*

Install from public GitHub and view the pkgdown site

*REDCapTidieR is in early alpha, but hopefully for not for long!

So thank you for sticking with me this far, I realize it can be a bit dry but hopefully you can see how our package can help alleviate some of the mental burden of dealing with raw REDCap data exports. You can learn more on our pkgdown and install the package yourself on our public GitHub repo, just be aware it is still in early development.

Future Work

• raw_or_label compatibility
• extract_table and extract_tables functions
• Release to CRAN

Before I close up, we have a bit more work to do. We want to extend accessibility and compatibility to include appropriate handling of raw data elements as well as labels depending on user specification. Right now the default is to only export raw data, but this is high on our priority list to fix.

We will be adding a few extraction functions to allow for tables to be extracted direct to the console or for variable assignment like you typically would expect so you don’t have to just use environments and binding.

And lastly, hopefully we’ll get this accepted to CRAN! Would be pretty neat and my first CRAN package if possible so stay tuned!

REDCap Metadata

metadata <- redcap_metadata_read(redcap_uri, token)$data

metadata %>%
  kbl(booktabs = T, escape = F, table.attr = "style='width:20%;'") %>%
    # options for HTML output
    kable_styling(bootstrap_options = c("striped", "hover", "bordered"), 
                  position = "center",
                  full_width = F,
                  font_size = 12,
                  fixed_thead = T) %>% 
  column_spec(1, bold = T) %>% 
  scroll_box(width = "100%", height = "300px")