Interview Items and Other Data Collection Fields
REDCap offers a wide variety of survey and interview item types.
- Text box (short text, number, date/time, etc)
- Notes box (paragraph text)
- Calculated field (derived from other fields)
- Multiple choice (drop-down list OR radio buttons)
- Checkboxes (check all that apply)
- Signature (with mouse, finger, or other device)
- Slider/Visual Analog
- File upload
- Descriptive text
Branching logic is the way REDCap refers to interview skip patterns. These are employed when fields need to be hidden during certain circumstances. For instance, you may want to hide the question “How many hours per week do you watch TV?” until a ‘Yes’ answer is checked for the previous question, “Do you watch TV?”.
Piping refers to inserting the response from an earlier data collection element into the content of a later data collection element. Collected data can be piped not just to the field label of a subsequent field, but to any of the following places:
- Field Label
- Field Note
- Section Header
- Matrix field column headers
- Option labels for multiple choice fields (radio, drop-down, checkbox)
- Slider field labels (i.e. text displayed above slider bar)
- Custom record locking text (if defined, displayed at bottom of form)
- Survey Instructions
- Survey Completion Text
- Survey invitation emails (sent via Participant List or Automated Invitations) – includes both subject and message
- Custom text displayed at top of Survey Queue
- Inside the URL for a survey’s ‘Redirect to a URL’ setting
All you need to do to pipe a data value into any of these valid places is insert into your text the variable name inside square brackets.
Calculations should be considered a tool not data. Calculations should be reapplied during data analysis. Do not reference calculated fields within calculated fields. When multiple calculations are performed on the same data entry form, the order of execution is determined by the alphabetical order of the associated field names.
Problem: Here, Calculation 2 will occur before Calculation 1!
Calculation 1 [weight_met]=[weight]*.45359237
Calculation 2 [BMI]=[weight_met]/([height]^2)
To avoid this problem, calculate BMI in one step.
Data validation provides ways to ensure collected data is entered in an expected format or falls within an expected range. For example, a field collecting participant age in years could specify that only whole numbers from 0 to 150 are allowed. When a response outside of the allowed range is given, REDCap will prompt the survey respondent or staff entering data to revise the entry.
Forms vs. Surveys for Data Collection
Two ways of collecting/entering data in REDCap are Forms and Surveys. Forms are for data entered by project staff, not directly by participants. Forms might be used to enter the results of biological testing or responses to items in a staff-administered personal interview. Surveys are for data entered directly by participants. Surveys may take place at a study field site, as an audio computer-assisted self-interview, or participants could be invited by email (or in other ways) to complete a survey in a location of their choice and with some flexibility around exactly when it happens (e.g., a participant could take a survey by following a link on their home computer at 9:45pm on a Sunday).
Events and Arms
The entry point for setting up events within REDCap is the Project Setup tab. This is where one can define study events and designate instruments used for each event.
Figure 7. Defining Events
Each arm in the project is a collection of events in a sequence. In a MOST study, each condition may have a unique sequence of study events, and arms in REDCap are a way to specify different events for different participants. For study conditions which receive multiple components, REDCap setup is an opportunity to consider the order in which those components will be delivered to participants, and whether temporal overlap among components is permissible or not. REDCap setup is a good time to consider how intervention component activities and assessment activities are temporally organized.
Think about the timeline of study events for an individual study participant. All potential participants start with screening events used to determine eligibility. This is a one of the events which will be common to all participants. Other events common to all participants may be: 1) a baseline interview; 2) randomization to a condition; and 3) one or more follow-up interviews. Based on the results of randomization, condition-specific events will come into play. The typical MOST study will need at least one arm for the common events occurring prior to randomization as well as arms for each unique study condition. For example, a 2 * 2 * 2 full factorial design with 8 unique conditions would have at least nine arms in REDCap. If you organize the project for your MOST study in this way, REDCap will warn you that a record (participant) is present in more than one arm of the project. But it does allow this, and with the same participant in more than one arm you benefit from REDCap handling randomization, study activities before randomization, as well as condition-specific events.
Days-offset is part of defining events for an arm. When the scheduling module is turned on, days-offset specifies the “ideal” time for an activity as well as a range during which the activity can be completed. Implicitly, days-offset also specifies the order in which events for an arm will take place, as well as the interval of time between events. Offset Range puts a window around the event time, providing flexibility in the exact timing of the event. Each arm has its own definition of events, including days offset.
Defining Longitudinal Events (5 min)
Designating Instruments for Events
Each event can be connected with one or more data collection instruments to be completed during the event. This allows the same instrument to be completed on more than one occasion. Think of a grid with specific data collection instruments as row names and specific events as column names. The designation of instrument for events entails identifying which instruments should be administered during each event. As each arm has a unique set of events, designation of instruments is done separately for each arm.
Designating Instruments for Events (3 min)
Events and instruments can be repeated in a longitudinal project
There are at least three ways to repeat collection of the same data fields over time.
One approach is to embed the same interview item in different instruments (with different variable names). This is an attractive approach if you have fairly long baseline and follow-up interviews which need small changes from one time point to another and you do not want to break up the interview into many smaller instruments. Having the baseline interview as a single instrument will mean less starting and stopping within a long interview session. Also, if create distinct instruments with overlapping items, you can customize aspects of each interview. For example, piping can be used to remind the participant of the last interview date.
A second approach is to specify every event ahead of time and repeat one or more instruments across multiple events. This approach is attractive for elements of study activities that are more structured and planned out ahead of time. For example, you may have a baseline interview and a small number of follow-up interviews which need to take place within a specific window of time. An instrument you plan to administer multiple times can be specified once. The time points at which interviews will be administered are specified as events. Then instruments are linked to events as described under Designating Instruments for Events. This approach allows you to use REDCap to schedule when each of the planned events will happen for individual participants.
A third approach is to turn on functionality for repeating instruments or, in a longitudinal project, repeating instruments and/or events an unlimited and unknown number of times. The is useful when an event needs to be repeated frequently or an unknown number of times. One example of where this may be the most efficient approach is asking about contacts in an intensive intervention component. The number and spacing of contacts will vary across participants and will not be known in advance. Rather than generating many contact events or fields, a small set of fields related to a contact (date, mode, staff, duration, outcome) can be repeated as often as needed.
A mix of these approaches can be used for different instruments. The approach used has implications for how data will be organized when exported (longer vs. wider format). Be prepared to figure out how the exported data are organized and to do some reshaping of the exported data.
Repeating Instruments and Events (33 min)
Scheduling and Calendar Application
When a participant experiences the first event in an arm, other events in that arm are scheduled based on defined events and their days-offset. It is very common to make changes to a participant’s default schedule to a time more convenient for the project and participant (e.g., moving an event from a Sunday to a Monday). Record-specific scheduled events will appear on the project’s calendar, along with the record’s unique identifier.
Scheduling Module (7 min)
Calendar can be used to see what record-specific events are scheduled and to enter a data collection form associated with the scheduled event (e.g., if the scheduled event is a baseline interview, following the calendar link will open the baseline interview data collection forms). The calendar shows the event and the unique identifier, so project staff know which participants need which events on a given day.
The Calendar (7 min)
The randomization module sets up REDCap to randomly assign participants to specific study groups.
Setup includes the following steps:
- Define your randomization model
- Download template allocation tables (as Excel/CSV files)
- Upload your allocation table (CSV file)
Randomization can be stratified by one or more variables collected before the randomization step. User rights functionality can control which project staff are allowed to randomize. After the value of the random group is assigned, the random group field becomes read-only and the value cannot be changed (by design!).
The table of allocations used by REDCap is generated outside of REDCap and saved in comma-delimited format. The comma-delimited allocation table is uploaded to REDCap as the third and final step in setting up the randomization module. In the example shown in the figure below, participants are assigned to one of eight study conditions and random assignment is stratified by gender.
Include more assignments than you believe you will need in the table of allocations to allow for participant drop-out and drop-in as well as uncertainty in the proportion of participants enrolled in each strata. For example, if the study design calls for randomization to eight conditions stratified by gender and forty participants in each condition, you might generate an allocation table with sixty assignments per condition in each strata (i.e., a total of 60 * 8 * 2 = 960).
Here is an example of generating the allocation table for stratified random assignment using R:
DF <- expand.grid(Person = 1:800, scr1_gender = 1:2)
DF <- DF %>% mutate(Block = cut(Person, 100))
DF <- DF %>%
group_by(scr1_gender, Block) %>%
mutate(rand_scond = sample(3:10)) %>%
write.table(DF %>% select(rand_scond, scr1_gender), file = “atab.csv”, row.names = FALSE, sep = “,”)
When the project is underway, and some participants have been assigned to conditions, the Randomization Module includes a dashboard showing the number of participants (records) assigned to each condition in each strata, which is useful for tracking enrollment progress.
Figure 8. Randomization Module Dashboard
Reports can show data fields to understand collected data and facilitate project management.
There are four steps to building a report:
- Select users who can access the report
- Select data fields to include in the report
- Select cases to include using logic applied to data fields (e.g., only show female participants)
- Select data fields used to order the results (e.g., sort report by age)
Figure 9. Reports Example
Record Status Dashboard
The Record Status Dashboard allows project staff to see which data entry forms have been completed for different individual participants.
Figure 10. Record Status Dashboard
Pulling REDCap data by API
REDCap project data can be exported using an “Application Programming Interface” (API), which is just a way to request the export within a program rather than manually pointing and clicking. Thus, API makes the process of regularly exporting data for summaries and project management smoother and more efficient. Using API for export will most likely require a user- and project-specific token which is requested from your institution’s REDCap administrator. The token is a security measure used to authenticate a user’s identity and rights to work with the data programmatically for a specific REDCap project. API is likely something only one or a very limited number of project staff will need and have rights to use.
Here is an example of an R program which exports all data from a REDCap project and saves it in Rdata format:
tkns <- read.xlsx(“tkns.xlsx”)
rcon <- redcapConnection(url = ‘https://openredcap.nyumc.org/apps/redcap/api/’, token=tkns[4,3])
projdata <- exportRecords(rcon, batch.size = 700)
save(list=c(‘projdata’), file = “projdata.Rdata”)
The MS-Excel file contains the token needed for authentication. Reading it from a file this way keeps the token private. The combination of the institution’s REDCap server, the user’s identity, and the token uniquely identify the project from which data should be exported.
For these steps to work, you may need to be behind your institution’s firewall, or may need to establish a secure VPN connection with your institution if working remotely. Contact your institution’s REDCap administrator if you have problems getting data export via API to work.
Once the exported data have been saved locally or in a secure shared folder, detailed regular summaries can be run.
Data from smaller projects can be exported manually within REDCap too
REDCap can export to the following formats: comma-delimited; SPSS; SAS; R; Stata; and XML. The export interface can be accessed from the Project Home tab of your REDCap project.
Figure 11. Manual Data Export within REDCap
Things more easily done outside of REDCap
It is very likely you will want and need to do things with the collected data that are impossible or difficult to do within the REDCap system. A fairly efficient approach is to regularly export data from REDCap, and then generate the summaries and files needed to facilitate project management. The ability to use an application programming interface (API) to pull data from REDCap in a program greatly improves the efficiency of this workflow. I have used a combination of tools including various R packages and GitHub to support the Heart-to-Heart 2 MOST study. The redcapAPI R package uses the REDCap API to pull current project data, then there are many data management, summarizing, and list making steps in R, and web pages generated in R are hosted on GitHub. GitHub and similar tools have options for both public and private repositories. In addition to the web pages, it can be useful to generate MS-Excel files which list individual participants and highlight completed and needed study activities. The openxlsx R package can be used to write MS-Excel files from R.
Review intervention activity gaps
Generating a simple list of participants with intervention activity due and completion dates can be useful for managing and driving completion of intervention activities. This can be a useful supplement to what can be achieved within REDCap with Reports and the Record Status Dashboard.
Figure 12. MS-Excel Intervention Activity Tracking List
Review follow-up interviewing gaps
Generating a simple list of participants with interview target, earliest, and due dates, as well as days remaining and interview completion, can be useful for managing and driving completion of interviews. This can be a useful supplement to what can be achieved within REDCap with Reports and the Record Status Dashboard.
Figure 13. MS-Excel Interview Tracking List
REDCap Development and Production Modes
REDCap has a development and a production mode. The development mode allows one to incrementally build and test project components. The production mode is meant for real data collection and project management. It is possible to make some changes after moving the project from the development to the production mode, but once in production changes should be made with extreme care.
REDCap is actively developed
Researchers using REDCap to manage MOST and other types of studies need to be aware of new features and system changes which may impact aspects of your project. These changes are generally enhancements (new features) which don’t have to be adopted in the middle of a project. New REDCap features may require changes to this manual over time.
A MOST REDCap project providing an example
The example illustrates the steps to set up a REDCap project for a 2 x 2 x 2 full factorial design. The intervention components in the example project are: 1) video; 2) support groups; and 3) text messages. Video has brief and detailed levels while the other two intervention components are either on or off.