REDCap Best Practices

Best Practices-Development

Standards/best practices recommended to all users include, but aren’t limited to:

  • The record ID must be the first variable of the first form (Can be changed to study ID, MRN etc.)
  • Keep variable names short, succinct, and meaningful (must be less than 26 characters to avoid truncation)
  • Ensure Instrument names meet the character limit criteria (note that _complete is added to this variable name so include this in your character limit)
  • Use multiple choice questions where possible
  • Minimize the use of free response fields
  • Use field notes to help the data enterers enter information correctly
  • When using free text fields, ensure validation of the data type whenever possible (e.g., date, zip)
  • Keep forms short, with similar types of data grouped together
  • Limit the use of calculations and never use stacked calculations (calculations that include other calculated fields)
  • Be consistent in the coding of multiple-choice questions (1, 2, 3, 4 etc.)
  • Use the 1-Yes 0-No/1-True 0-False convention
  • Use large, negative numbers for answer choices like NA, Prefer Not to Answer, or Other (e.g., 00, 999)
  • Minimize the use of required fields in surveys
  • Test projects thoroughly, including all branching logic, calculations, automation, reports and piping; send test surveys both to yourself and to different email domains (e.g., gmail); practice data entry on a longitudinal project; have other team members practice data entry and pulling data from the project to make sure it is functional
  • Ensure variables are broken into appropriately separated fields for analysis (e.g., address, city, state, zip)
  • Set up data quality rules
  • Ensure that all appropriate REDCap forms/instruments are sent to project manager for review by IRB
  • Take frequent snapshots of the data dictionary
  • Be consistent in how questions are framed
  • Use validated instruments from the REDCap Library where possible
  • Be conscious of copyright issues when using pre-existing forms and translate them as exactly as possible from their paper formats; be aware that if they cannot be properly translated, they are no longer validated instruments
  • Flag identifiers and limit who can access and export them (e.g., deidentified vs. full data set)
  • Be consistent in coding your variables (code to recognizable terms) (e.g., phq9 q1, phq9 q2, etc.)
  • Variable name should not be changed once data collection has begun- this will corrupt your data
  • If you have multiple questions that will use the same answer choices, code them all the same
  • Above all, consider carefully how the data you collect will be used in analysis and code variables appropriately. Make sure to consult, if possible, with the data analyst/statistician who will be reviewing data on the back end
  • Ensure data roles are created and users appropriately assigned with the minimal required rights
  • Consult with Biostatistician for Randomization Setup
  • Utilize File Repository to upload/organize documents
  • Utilize E-consent framework & Auto-archiver for all participant consenting
  • Utilize Auto-archiver for surveys
  • Confirm ALL automated settings PRIOR to moving project into production
  • Ensure any safety alerts are built PRIOR to moving into production
  • Ensure reports that guide workflow are built PRIOR to moving into production
  • Ensure survey settings are finalized PRIOR to moving into production
  • Ensure IRB number is included for any IRB approved projects

Best Practices-Production

Standards/best practices recommended to all users include, but aren’t limited to:

  • DO NOT delete/rearrange events once real data exist in your project – this can result in deletion/data scrambling
  • DO NOT alter your existing automations once real data exist in your project – any changes will ONLY apply to new records, not existing records
  • DO NOT rearrange survey questions/answers once real data exist in your project – this can result in deletion/data scrambling/alteration of existing survey responses
  • AVOID making any major structural changes to your project once it is in production (this does not include minor survey question adjustment, aesthetic changes etc.)
  • Utilize Data Quality Rule H to update calculations in instruments
  • New instruments must be assigned to events in longitudinal projects
  • Download your current data set at least monthly AND before any large data imports
  • PRIOR to making any major changes to the structure of your project, make a copy of your project, including the dataset
  • Consult the REDCap Admin Team PRIOR to making any major changes to your project to formulate a sound plan – Admin team must approve any changes that could alter existing data