Basic REDCap Terminology

Project

Web based databases made of data collection instruments. Projects can contain one or multiple instruments. Upon creation of a project, only the person who created the project has access to that project. Additional people can be added to the project using the User Rights application. When adding someone to the project, they can be given the ability to add additional users. Projects are in Development Status by default when they are created.

Development Status

Default status when a project is created.  It allows for easy building, testing, and modification of REDCap projects.  Data in projects with development status are not HIPAA compliant.  Projects in development status allow 1) any project modifications in real time, 2) adding and deleting test records, 3) enabling any features that users are allowed to enable.  These features allow for comprehensive testing of a project prior to moving to production status.  Once a project has been tested and you are prepared to begin collecting data from real study participants, you must request that your project be moved to production status.  To do this, go to project setup, scroll to the bottom of the page, and click Move to Production Status. Data collected and stored in a project that is in Development Status are not considered HIPAA compliant. Therefore, collection and/or storage of PHI or other sensitive data ("real data") are not permitted while the project is in Development Status. Data are not backed-up when the project is in Development Status so collecting so real study data collected in development are at risk of permanent data loss. 

Production Status

Intended for IRB-approved projects or projects with IRB waivers.  Data in projects in Production Status are considered HIPAA compliant and can contain PHI and other study data ("real data," defined below).  Once projects are in Production Status, data are continually backed up to facilitate PITR (point in time recovery) methods and are stored for approximately 30 days. Please note, while data are backed up on the production server, if you or anyone added to your project purposely deletes data, for example by deleting records, fields, or instruments, or changing variable names or multiple choice codes, there will be a fee associated with recovering data.

It is important to note that you can still make modifications to your project in production status.  Some modifications may require administrator review in order to reduce the risk data loss or project corruption. A good practice to reduce the risk of data loss is to only add to project and do not delete anything. If you no longer need instruments, fields, or field choices, these can all be hidden while data are preserved.

Principal Investigator (PI)

REDCap is designed for primarily for research so has a requirement that any project moved to production has a PI designated. This is true even if the project purpose is defined as Operational Support or Quality Improvement and you are collecting non-research data (i.e. was exempt from IRB review). Therefore, we provide a definition for both research and non-research projects.

Research Project: This will be the same as the person listed as PI in an approved IRB protocol even if that person will have limited or no involvement with REDCap. This is because the person listed as the PI in REDCap will will assume responsibility for storing the data after project is closed in the IRB (Wash U policy is to keep data for seven years after closed out in the myIRB system. You may have other funder requirements for storing data internally). If the protocol is not yet approved by an IRB, list the person who will be when it is approved. The PI assumes responsibilities for data in the project as outlined in the Washington University Research Data and Materials Policy. Typically, the PI is a faculty member on the investigator or research track (Assistant, Associate, Full Professor) or physician with protected time for research.

Operational Support or Quality Improvement Project (non-research): Person who will be responsible for ensuring the project does not need IRB oversight and assumes responsibility for the data that is in the project. Depending on the nature of the project, this could research faculty or staff, clinical faculty or staff, or administrative staff. However, it should be a person who is likely to be associated with the university for the duration of the time the data are stored in REDCap. For example, this could be a Professor of any rank, Research Coordinator, or Nurse if the project is related to operational support of research or clinical projects, respectively. This also could be a Program Manager, Program Coordinator, or other administrative staff if the project is collecting applications to a program or collecting administrative (non-research) data related to an academic program.

Project Administrator (PA)

The PA is the person who will most closely manage the day to day operations of a REDCap project, including adding people to projects, setting User Rights, and removing people from the project when necessary. In some cases this will be the same person as the PI but not in all cases. Other common job titles for people in the PA role are Clinical Research Coordinator, Senior Research Coordinator, Research Nurse Coordinator.

Study Team Member

Any person who created or is added to the REDCap Project and is listed in the Current Users table on the Project Home page. This does not include people who have been removed from the project in REDCap. Technically, there is no “Study Team Member” designation that is built-in to REDCap as with most other terms on this list, however, the term is used frequently in REDCap documentation, training materials, and user guides that it is worth defining here.

User Rights

When someone is added to a project, the user adding them must select what they are able to do in the project. There is a table that contains each User Right or “Privilege” that can be assigned to a study team member being added to a project. When adding a user to a project, you should give them the minimum rights necessary for them to complete their assigned task. For example, if someone will only enter data they do not need the Project Setup and Design privilege checked. See the User Rights page for a definition of each user right or privilege.

Data Collection Instruments

Forms that are opened as webpages. The forms consist of a series of data entry points called fields. REDCap Forms are often adapted from forms that would normally be printed as paper copies for a similar research project such as questionnaires, clinical intake forms, Case Report Forms (CRFs), etc. When planning to create data collection instruments, study teams often compile which forms that would have printed in previous studies without REDCap and determine how they will create them in REDCap. Data collections instruments can be used as Data Entry Forms or Surveys.

Data Entry Form

Data collection instrument that can only be accessed by study team members when logged into REDCap. Data entry form is the default setting of an instrument when created. Data entry forms are often used when study members will be manually entering data. Important: Participants or any non-study team member should never enter data into a data entry form! If they are entering data into a data entry form they are in a REDCap account that does not belong to them and they could access all data associated with the account.

1. Participant population would have difficulty completing surveys on a computer or device so they complete on pencil and paper. Study team subsequently enters data.

2. Participant is being asked questions by study team member who is entering data directly into REDCap such as in a clinical setting

Surveys

Data collection instrument delivered via email, public survey link, QR code, or other method so that data can be entered without logging in to REDCap.

Field

Most commonly a Field is a data entry points that is created on a Data Collection Instrument by defining a specific set of Field Attributes. Some fields do not have a data entry point but rather serve as section dividers, provide messages to the person entering data to the instrument, or other specific uses. Fields can be created with point-and-click functionality in the Online Designer and by defining specific parameters in a Data Dictionary csv file then uploading to the REDCap project. Field Attributes and Field Types are defined in the Basic REDCap Terminology | Basic Terminology for Building a Data Collection Instrument table below.

Variable Names

Each field is given a variable name that can only contain lower case letters, numbers and underscores (_). Variable names are not seen during data entry and are considered “machine readable.” Any data entered to to a field is connected to the field via the variable name and Record ID in the REDCap database. Therefore, variable names should not be changed once you are collecting real data as you may lose data or cause issues to your project down the road.

Field Labels

Field labels are the text that the person entering data will see when they are entering data to a field. Field labels are considered “human readable.” The text and other information contained in field labels may be created by the study team or may from a standardized research instrument (e.g. PROMIS surveys). While most fields have something in the field label, it is not required. Field labels can be modified after a project is in production without affecting data collected in the field, however, you should consider whether changing the field label will affect how the person entering the data before making modifications.

Record

Practically, a record can be an individual participant in a clinical study, a single specimen in a repository, or whatever makes up the sample size or population that will be stored in your project.

Technically, the record provides a name and unique identifier for the REDCap database. This field is critical to the proper function of REDCap projects. It should never be modified after real data collection has begun. It should always appear on the first instrument and the first event.

Record ID Field

The first field on the first instrument in any project is the Record ID. The Record ID is a unique identifier which links all data in the REDCap database to specific variable names of fields (data entry points). The record ID can often be thought of as the row and the variable name a column of a data export from REDCap. By default the record ID field has a variable name [record_id] and field label “Record ID” when a project is created. These can be modified, for example to [study_id] and “Study ID” or other name that makes sense for your project. However, the first field of the first instrument will always serve as the Record ID from a technical sense as described above. As such the Record ID field should never be modified after a project is in production status and collecting real data. The project ID field should always be on the first event in a longitudinal project.

It is best practice to not change a Record ID after a record is added to a project. If you create a Record with an incorrect ID, you can change the Record ID if you have the proper user rights. However, we recommend only doing this when necessary. Do not make changing Record IDs part of your study workflow.

If you regularly edit or manipulate data entered into the Record ID Field after the record has been created, you are at risk of losing data or having functionality issues with your project.

Real Data

In REDCap documentation and training materials, the term “Real Data” refers to the actual data intended to be collected and stored in the REDCap project. For example, if your project is for a clinic trial, real data is data collected from actual people be screened or enrolled in the trial. Real data should only be collected after a project has 1) a protocol approved by an IRB, 2) been thoroughly tested by the study team, and 3) moved to Production Status.

Test Records and Data

Records and data that are entered to a REDCap project in order to ensure the project functions as intended. If these records were added during development and while in development status, they can be safely deleted before moving the project to production mode. If you make modifications to a project in production status, you can create a Test record while in production. It is recommended that you give the test record an obvious Test record ID such as “Test” and enter data that is obviously fake, for example, a Participant Name field may be filled with “Research Participant.” Test records added after the project is in production can be stored or deleted. If they are deleted, ensure you can explain this to anyone auditing your project in the future either in the Logging feature, or by documenting the master log.

Online Designer

Allows you to create, build, and modify data collection instruments very easily using only point-and-click functionality on your web browser. NOTE: While in development status, all field changes will take effect immediately in real time. While in production status, you will need to enter draft mode, make changes, submit changes. Some changes will go through automatically such as adding new fields as this has no affect on data already stored in the project. Some changes will require administrator review. For example, if a test record was created and is now being deleted, this will require admin review.

Data Dictionary

A specifically formatted CSV file that contains all information (metadata) related to the Fields on each Data Collection Instruments in a REDCap project. When an instrument is built in the Online Designer, a Data Dictionary is automatically built within the REDCap project and can be downloaded from several locations including the “Dictionary” link that is always present in the left hand menu. The Data Dictionary also can be used to build and modify data collection instruments and fields. Using the data dictionary to modify fields is NOT RECOMMENDED for projects in production mode or projects with a lot of field label formatting. When you make modifications using the data dictionary, you must upload an entire new data dictionary. Some formatting can be overwritten if the file is not formatted perfectly. If you upload a new data dictionary to a project in production mode, ensure all fields look and feel as they should.

Data Dictionary Snapshot

Saves a CSV of the current data dictionary clicking Create snapshot of instruments in the Online Designer. It is best practice to create a data dictionary snapshot regularly when you are in development mode. This ensures you have a back up of the fields you already created in the project. When in Production Mode, a data dictionary snapshot is created every time every time the project modifications are approved. You can see a list of all data dictionary snapshots for a project by going to Project Home then Project Revision History

Field Attributes

Defined when creating a field that determine the look, feel, and functionality of the field. The required field attributes are Field Type and Variable Name. Field Labels are used on most fields but not all. All other attributes are optional.

Field Type

REDCap gives several options of Field Types that are designed collect all types of data. These field types include Text Box, Notes Box, Dropdown, Radio Boxes, Checkboxes, File Upload, and many others.

Variable Names

Each field is given a variable name that can only contain lower case letters, numbers and underscores (_). Variable names are not seen during data entry and are considered “machine readable.” Any data entered to to a field is connected to the field via the variable name and Record ID in the REDCap database. Therefore, variable names should not be changed once you are collecting real data as you may lose data or cause issues to your project down the road.

Field Labels

Field labels are the text that the person entering data will see when they are entering data to a field. Field labels are considered “human readable.” The text and other information contained in field labels may be created by the study team or may from a standardized research instrument (e.g. PROMIS surveys). While most fields have something in the field label, it is not required. Field labels can be modified after a project is in production without affecting data collected in the field, however, you should consider whether changing the field label will affect how the person entering the data before making modifications.

Field Validation

Assign a specific data type and format to a field. Examples of field validations include email, phone, zip, integer, there are several date and number formats, and several others.

Required

Can mark a field as required. A survey cannot be submitted or moved forward to the next page if a required field is not completed.

Identifier

REDCap gives you the ability to tag fields as identifiers that will have PHI or other identifying data (e.g. notes box with a description of a person event). Tagging a field as an identifier allows additional protections to this data such as being able to restrict who can view and export data from identifier fields.

Custom Alignment

Determine where you would like the data entry point to appear on the field. Especially useful for Radio Buttons and Check Boxes.

Enable Longitudinal

To use the built-in longitudinal design tools in REDCap, you must first enable longitudinal data collection on the Project Setup page. Determining whether a project will be longitudinal should be done prior to moving to Production Status. You should NEVER move a disable longitudinal data collection after you have moved to Production and started collecting real data.

Events

Allow for the collecting data on the same instrument multiple times for a single record (often used when collecting longitudinal data). Events often correspond to data collection events designed in your overall research project such as participant visits or follow up surveys (often defined by a table or flow chart in a grant). Events can also be quality assurance such as a “Submit Participant Payment” event the day after a patient visit.

Arms

Allows you to group events into 'arms' which you may can have different events from other arms. Arms are often used for projects where there are multiple study groups. Please note, that the arms function does not work with the Randomization module described below. If you are using multiple arms in REDCap, the study group must be defined at the time of record creation. When using the randomization module, the arms are defined AFTER record creation.

Designate Instruments for Events

After creating events, you must define which instruments will be used on each event.

Event Label

The name you choose for the event such as baseline, One year follow up, etc.

Unique Event Name

An automatically generated name that REDCap assigns each event based on the event label.

Scheduling Module

When enabled, can generate a schedule for each record created on the Events created by the study team. The schedule generated for each record automatically is populated on the Calendar application. Scheduling is only available for projects using longitudinal data collection.

Calendar

Can be used as a project calendar to easily view upcoming events. You can update the status of events to scheduled, confirmed, cancelled, no show, which will also color code the event. It will allow you to add or modify calendar events and then view them either in a daily, weekly, or monthly format below. There are options to sync with external calendars.

Enable Surveys

Before you can enable an instrument as a survey, you must first go to project setup and enable “Use surveys for this project.”

Survey Settings

Survey Distribution Tools

A set of data collection tools that become available to once surveys are enabled on a project. The tools include the Public Survey Link, Participant List and Survey Invitation Log.

Public Survey Link

To access this tool, the first instrument of the project must be a Survey. When the first instrument is a survey, the Public Survey Link provides a URL that can be used to access the survey. The Public Survey Link also contains a QR code that allows access to the survey and is often used on flyers, a Survey Access Code that can be used to access the survey from a generic REDCap surveys URL (https://redcap.wustl.edu/redcap/surveys/), and an HTML Embed Code. You also open the survey directly from that page with or without logging out and sending yourself an email with a hyperlink and URL to the survey. This is the only method to send a truly anonymous survey.

Participant List

The Participant List allows you to send customized emails with a record specific survey link to several people at once (i.e. emails are sent to several people simultaneously but each email has a unique link for the specific email address where it was delivered). There are two ways to populate the participant list so that this feature is usable for delivering surveys: 1) Click the Add participants button at the top of the Participant List table or 2) add a record to the project another way and have a field validated as an email field designated for email communications on the Project Setup page. If you use the Add Participants button, please note that you either need to capture identifying information in the survey or add a Participant Identifier to the email address prior to sending in order to identify your records. If you do not, the surveys will be essentially anonymous. If you capture data using the Public Survey Link or other method, the Participant List will populate but it will only be identifiable if you capture an email or other identifying information

Survey Invitation Log

Lists all survey invitations that have already been sent or have been scheduled to be sent to participants in a project. For each invitation the log displays the participant email, participant identifier (if exists), survey name, and the date/time in which the invitation was (or will be) sent. You may even view the invitation email itself by clicking the icon in the 'View Email' column. The Survey Invitation Log is incredibly useful when determining if Automated Survey Invitations scheduled not to be delivered immediately after another instrument and/or conditional logic is met, i.e. if an ASI is scheduled to be delivered 6 months after baseline surveys are completed, you can create a test record, complete the baseline surveys, navigate to the Survey Invitation Log, and see if the invitation has been scheduled correctly.

Automated Survey Invitations

A tool used to schedule email invitations containing survey links to sent when specific conditions are true, for example, after another survey is completed and/or conditional logic becomes true such asking if the participant has had a specific procedure ([had_procedure] = '1').

Survey Queue

The original function of the Survey Queue is to display a list of surveys to a participant on a single page, in which the queue comprises all surveys that are to be completed, like a 'to-do' list, as well as the surveys that the participant has already completed. This is useful if your surveys can be completed in any order. For example, programs that use REDCap for application submissions to training programs often use the Survey Queue for all the surveys that need completed for the submission process. The Survey Queue can be used for survey branching logic as well by including conditional logic for a survey to become available, selecting the “Auto start?” checkbox, and selecting Keep the Survey Queue hidden from participants?

Survey Options

After a record has been created and saved in a project, the Survey options will appear in the upper right of any instrument opened for that record. You can deliver an email invitation with survey link directly from the options or use other survey distribution options within the dropdown menu.