Page Comparison

Project

Web based databases made of data collection instruments. Projects can contain a 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 https://washu.atlassian.net/wiki/spaces/RDCPPub/pages/458163279/Basic+REDCap+Terminology#Basic-Terminology-for-Building-a-Data-Collection-Instrument tablebelow.

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

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.