REDCap Project Development

REDCap Project Development Guide

Thoughtful project development is essential to building a REDCap project that is usable, secure, and ready for accurate data collection.

Before collecting real study data, project teams should use the Development environment to plan the project structure, configure settings, build instruments, test workflows, and review exports.

Important: The Development environment is for building and testing only. Real data, PII, PHI, and other sensitive data should not be collected in Development.
Core Workflow: Create → Configure → Build → Test → Review → Move to Production

Create a New Project

When creating a new REDCap project, enter the project title, select the project purpose (typically research), and provide required details such as PI and IRB number.

Choose a project creation method:

  • Empty project (recommended for most users)
  • Upload REDCap XML (CDISC ODM)
  • Use a template
Best practice: Start simple. Build the minimum structure needed and expand only as your workflow requires.

Choose Core Project Settings

  • Will the project use surveys?
  • Will it be longitudinal or single-timepoint?

Enable longitudinal design if data will be collected across multiple visits or time points. Enable surveys if participants will complete instruments directly.

Best practice: Decide early on project type (classic, longitudinal, survey-based, or hybrid). This impacts structure, workflow, and reporting.

Build Data Collection Instruments

  • Online Designer (recommended)
  • Data Dictionary (for advanced builds)

Start with the default instrument and add additional instruments based on workflow.

Best practice: Design instruments around real workflows (visit, role, or task), not as one long form.

Set Up the Record ID

The first field must be a unique record identifier. It cannot be deleted but can be renamed.

Important: Do not use PHI (e.g., MRN, DOB, initials) as the record ID.
Best practice: Use a neutral study ID that does not contain identifying information.

Select Appropriate Field Types

  • Validated text (dates, email, numeric)
  • Dropdowns, radio buttons, checkboxes
  • Calculated fields (use sparingly)
  • File uploads, signatures, sliders
  • Descriptive text and section headers
Best practice: Use structured and validated fields whenever possible to improve data quality.

Branching Logic & Piping

Branching logic controls when fields are displayed. Piping allows previously entered values to be reused in later fields or survey text.

Best practice: Keep logic clear and test every pathway. Confirm piped values display correctly in all scenarios.

Surveys & Optional Modules

  • Auto-numbering
  • Repeating instruments/events
  • Scheduling
  • Randomization
  • Data resolution workflow
Best practice: Enable only what your study requires to avoid unnecessary complexity.

User Rights

Role Typical Access
Study Coordinator Data entry, limited reports
Data Manager Reports, exports, data quality
Principal Investigator Oversight, read-only or reporting
Important: Apply the principle of least privilege. Review permissions before go-live.

Testing in Development

  • Enter test records
  • Test logic and calculations
  • Complete surveys
  • Review dashboards and reports
  • Export and validate data
  • Have others test workflows
Best practice: Test full workflows, not just individual fields.

Move to Production

Projects should only move to Production once fully tested and validated.

After moving to Production, changes must be made in Draft Mode and reviewed before approval.

Best practice: Limit changes after Production and ensure all updates are reviewed carefully.

Development Best Practices

  • Use validation and structured fields
  • Keep variable names consistent
  • Minimize free text
  • Use consistent coding (Yes/No, Unknown)
  • Identify PHI appropriately
  • Use clear units and field notes
  • Limit calculated fields
  • Handle partial/inexact dates thoughtfully
  • Use standard instruments when available

Additional Resources