User Rights Definitions
- Christopher Sorensen
The content on this page has been reviewed and approved by the REDCap Consortium Training Collaboration Committee.
It is important to understand that in the WashU REDCap instance access and user rights to individual REDCap Projects are controlled by the study teams themselves. This means that the individual study team determines who is given access to a project and what tasks that person is able to complete once added (User Rights). This page provides definitions for each User Right or “Privilege” that can be assigned to a study team member when adding them to a project. When adding a user to a project, you should give them the minimum rights necessary to complete their assigned task. For example, if someone will only enter data they do not need the Project Setup and Design privilege. If you are unsure how to add someone to your project, please see this FAQ: How do I add someone to my REDCap project?
It is imperative that you understand these rights prior to adding users to your project so you do not give someone privileges they should not have. If you do give someone higher level privileges than they need, you are at risk for data loss and project corruption. Please submit a ticket for questions with anything on this page. You also can create User Roles if several study team members will be completing the same tasks, for example, data entry.
Please note, you can adjust a study team member’s User Rights at any time. For example, if they are promoted and are given additional roles on the project, or if they leave the lab their rights can be limited to “read only” if they will stay on in a consulting role. They also can be removed from the project entirely if they will no longer work on the project.
If you have questions about the information on this page or any other REDCap questions, please submit a ticket.
If this page does not load correctly, Clear you web browser’s cache. For example, you should see a list of hyperlinks to different sections below this text. If they do not appear, or appear as full web URLs, please try to clear your browser's cache.
Expiration Date
User Right | Description | Additional Considerations |
|---|---|---|
Expiration Date | Set a date for the user’s access to automatically expire. You can adjust this date to earlier or later at any time, if necessary. Once the expiration date has passed, the user will no longer have access to the project but will remain in your user list with the expiration date listed in the column next to their username. You also can click the expiration date to edit if they rejoin the lab or project and need to regain access. You can fully remove them from the project by clicking their username, Edit user privileges, then Remove user. | This works well for study team members that will be on the project for a fixed amount of time such as work study students, fellows, etc. If a user gives their “last day notice,” you can update their rights to include that date. |
Highest Level Privileges
User Right | Description | Additional Considerations |
|---|---|---|
Project Design and Setup | Make edits to the project such as adding, modifying and deleting fields, turning on features such as surveys and longitudinal projects. This should only be given to highest level study team members. | If study team members without proper training and experience are given this privilege, they could inadvertently delete fields or instruments with real data causing data loss, change settings that cause data to be corrupted such as moving an instrument from repeating to not repeating after collecting data, etc. |
User Right | Add other users to the project and assign them user rights. | If study team members without proper training and experience are given this privilege, they could inadvertently add people to the project causing issues described in the Project Setup and Design additional notes |
Data Access Groups | Allows user to assign new record to Data Access Groups (DAGs). DAGs allow a project data to be separated by site so that people from one DAG can only see data entered from people by that DAG. They are commonly used for multi-site studies so study team members from one site can only see data from that site. | If study team members without proper training and experience are given this privilege, they could inadvertently add someone to a DAG that causes them to see PHI from a location where they are not allowed. |
Other Privileges
User Rights pertaining to Surveys and Notifications
User Right | Description | Additional Considerations |
|---|---|---|
Survey Distribution Tools | Distribute surveys using the Public Survey Link, Participants List, Survey Queue, Automated Survey Invitations and any other available survey distribution methods. | Should only be given to study team members that will send communications to participants. |
Alerts & Notifications | User can access and create Alerts & Notifications which can be triggered by nearly any data entry event in REDCap and sent to both study team members and participants. | Should only be given to study team members that will send communications to participants. |
User Rights pertaining to Data Import, Data Comparison Tool, Logging and File Repository
User Right | Description | Additional Considerations |
|---|---|---|
Data Import Tool | User can import data to the project that has been formatted properly in a CSV file | Data can be overwritten when importing data. It is important you understand how to format the csv file with the data prior to uploading and to carefully inspecting the preview table before importing the data. There is a key that will tell you if data already in the project will be overwritten. |
Data Comparison Tool | Allows user to compare data in two records within the same project by developing a comparison table between the two records. |
|
Logging | User can see the logging feature which tracks activity in the project such as changes to the project, data entry, surveys being delivered, etc. Please note, the logging feature allows the user to access all data that has been entered to the project including PHI. | The logging tool is useful when there resolving issues with data in your project or if you are being audited. While Logging is not listed as a “Highest Level Privilege,” you should treat it as such due to the amount of information a user can access if they have this privilege. |
File Repository | Allows user to access any files that have been uploaded to the file repository including Data Export Files, PDF Survey Archive, Miscellaneous File Attachments, and Recycle Bin. Files stored in the 'Miscellaneous File Attachments' folder are auto-added when users upload file attachments into the rich text editor in this project, such as when composing a survey invitation, adding a field label, or creating a project dashboard, among other things. | If you are using the e-consent framework and automatically storing e-consent or other information with PHI in the file repository, only people with access to PHI should be given this privilege. Also note, deleting a file from the Miscellaneous File Attachments folder that is used elsewhere in the project will cause the file's download link to no longer function and become a dead link. |
User Rights pertaining to Calendar and Scheduling
User Right | Description | Additional Considerations |
|---|---|---|
Calendar & Scheduling | Access to the calendar application and can create and modify schedules for records added to the project based on events created. The schedule automatically populates the calendar application. The calendar application is only available in projects that are enabled as longitudinal and the Scheduling module has to be enabled independently of the calendar. | Should only be given to study team members who will add records to the project and will coordinate participant’s study schedule, for example, coordinating follow up visits or surveys. |
User Rights pertaining to Reports and Stats
User Right | Description | Additional Considerations |
|---|---|---|
Add/Edit/Organize Reports | Creating reports allows the user to query all or subsets of the data. The user also can edit individual reports already created and rearrange the list of reports already created. | You can restrict access to individual reports as you create them. So you could restrict access to a single report from people who have this privilege. |
Stats & Charts | User can access the stats and charts page which provides descriptive statistics figures for fields. For example, fields with number or integer validation will have measures of central tendency (mean, median, minimum, maximum, IQR, etc.), and multiple choice fields will have frequencies. |
|
User Rights pertaining to Randomization
The randomization module in REDCap will help implement a defined randomization model within your project, allowing you to randomize participants (i.e. records in your project). In this module, the randomization model with various parameters is defined first.
User Right | Description | Additional Considerations |
|---|---|---|
Setup | It is STRONGLY RECOMMENDED that a statistician have the 'Setup’ randomization user rights. At a minimum, the user with 'Setup’ rights should be working under the guidance of a statistician. See the RANDOMIZATION WARNING for more details. The setup rights allow the user to define the parameters of the Randomization model and create a template allocation table so you can structure a randomization table to import. | WashU REDCap Support does not provide services or user support related to randomization unless we are working directly with a statistician. |
Dashboard | Allows monitoring of overall allocation progress and assignment of randomized participants |
|
Randomize | Allows user to perform randomization. Also allows them to view and modify any existing data already collected for the randomization strata fields (if stratification is used) when they are performing the randomization. | Users with these rights can view the strata fields even if they do not have Data Viewing Rights for the instrument with these fields. Thus, Randomize rights trumps form-level rights in this way, but only for the randomization strata fields. |
User Rights pertaining to Data Quality Rules
The Data Quality module is a page that can help you easily find any data discrepancies or errors in your project data by allowing you to create and execute data quality 'rules'.
User Right | Description | Additional Considerations |
|---|---|---|
Data Quality (Create & edit rules) | If a user has 'create & edits rules' rights for Data Quality, then they will be able to access the Data Quality module and will be able to create, edit, reorder, and delete any of the custom rules in that module. |
|
Data Quality (Execute rules) | Allows access the Data Quality module and will see the 'Execute' buttons on that page and thus be able to execute any of the rules that have been created (including the pre-defined rules), which will display a detailed list of all data discrepancies. |
|
User Rights pertaining to Data Resolution Workflow
If the Data Resolution Workflow is enabled, users will be allowed to open a workflow for documenting the process of resolving issues with data in the project. This data resolution workflow, often called 'data queries' in clinical trials and studies, can be accessed by an icon next to an individual field or on the Data Quality page.
User Right | Description | Additional Considerations |
|---|---|---|
Data Resolution Workflow (No Access) | Unable to create, view or edit any data queries created |
|
Data Resolution Workflow (View Only) | Able to view all opened queries but not modify them or contribute. |
|
Data Resolution Workflow (Respond only to open queries) | Can respond to an opened query (especially if they have been assigned to it), but can neither open nor close a data query |
|
Data Resolution Workflow (Open and respond to queries) | Can open and respond to an opened query (especially if they have been assigned to it), but cannot close a data query |
|
Data Resolution Workflow (Open, close, and respond to queries) | Can open, close and respond to a data query |
|
User Rights pertaining to API
Allows use of external applications to connect to REDCap remotely
User Right | Description | Additional Considerations |
|---|---|---|
API Export | Allows use of external applications to connect to REDCap remotely to export data from a project. This allows for automated data exports. Use of an API requires programming training in the application that will be used such as R, Python, MATLAB, Java, etc. | In addition to this privilege, the user must also request an API token. The API token is for the individual user only and should not be shared with anyone. Each user needs to request their own API token. |
API Import/Update | Allows use of external applications to connect to REDCap remotely to import data to a project or make updates to a project. Data imports can be automated. Use of an API requires programming training in the application that will be used such as R, Python, MATLAB, Java, etc. | In addition to this privilege, the user must also request an API token. The API token is for the individual user only and should not be shared with anyone. Each user needs to request their own API token. |
User Rights pertaining to REDCap Mobile App
The REDCap Mobile App allows users offline data collection. The app is most useful when data collection will be performed where there is no Internet service (e.g., no WiFi or cellular service) or where there is unreliable Internet service. If you are using a device when there is internet service, it is best to log in to REDCap through the devices internet browser rather than use the app.
User Right | Description | Additional Considerations |
|---|---|---|
REDCap Mobile App | Allows user to collect data offline in the mobile app. REDCap Mobile App is an app that can be installed on an Android or iOS tablet or mobile device so that data may then be collected in an offline fashion on that device. At some point later on, it may then be synced back to this project on the REDCap server. | Production changes can impact mobile app data collection. If the mobile app is enabled and a user has Project Design rights but no access to the mobile app, they should be cautioned about making modifications to a project in production. When modifications are made to projects where data are being collected using the mobile app, it is recommended that the user making the modifications coordinate with all users collecting data. Changes must be made in production and synced to the mobile app. |
Allow user to download data for all records to the app | Allows user to sync data collected in REDCap to be synced to the REDCap mobile app in order to have access to data when not connected to the internet. | When data are synced to the app, data already saved to the server can be edited offline on the app. Ensure that you sync the data with the server after editing on the app so any modifications you made to data are synced to the server. |
User Rights pertaining to Project Records
User Right | Description | Additional Considerations |
|---|---|---|
Create Records | Allows user to create new records in the project using the Add / Edit Records or Record Status Dashboard Data Collection tools, and by importing records. | Should be given to anyone who will create records. This may include data entry only study team members. If you are not using Auto-numbering of records, ensure study team member is trained in record naming. For example, if randomization occurs, you may only want specific study team members have this privilege to ensure this goes smoothly. |
Rename Records | Allows user to rename a record after it has been created. Records should only be renamed when they were originally named incorrectly. Do not make changing record names a part of your workflow. Regularly changing record names can lead to issues with the project in the future. | Given records should only be renamed when named incorrectly, this privilege should only be given highest level study personnel such as the PI and PA. |
Delete Records | Allows user to delete records after they have been created. When in production status, only test records or records added in error should be deleted from projects. | Should only be given to highest level study personnel such as the PI and PA. |
User Rights pertaining to Record Locking and E-signatures
Record Locking allows specific users to lock data on a record so that it comes read only.
User Right | Description | Additional Considerations |
|---|---|---|
Record Locking Customizations | Allows user access to customize record locking text. | Sometimes used for regulatory projects to provide “meaning” to the locking action. |
Lock/Unlock Records (instrument level) | Allows users to lock or unlock single instruments for a lock which freezes data for that specific instrument for that record. You can make an e-signature required for unlocking a record after it has been lock. Record level locking is a higher level privilege than instrument level locking. |
|
Lock/Unlock Entire Records (record level) | Allows users to lock or unlock an entire record which freezes data for an entire record. Record level locking is a higher level privilege than instrument level locking. |
|
Privileges for Viewing and Exporting Data
Data Viewing Rights and Data Export Rights are completely separate and do not impact one another.
User Rights pertaining to Data Viewing, Data Entry and Data Editing
Data Viewing Rights pertain to a user's ability to view or edit data on pages in the project (e.g., data entry forms, reports).
User Right | Description | Additional Considerations |
|---|---|---|
Data Viewing Rights | User's ability to view or edit data on pages in the project (e.g., data entry forms, reports). |
|
No Access (Hidden) | If this is selected for an instrument, the user will be unable to view that instrument for any record, nor will they be able to view fields from that instrument on a report. | Useful if certain members of your team don’t need to see PHI or if team members are blinded to some data. |
Read Only | If this is selected for an instrument, the user will be able to view data for that instrument but not edit the data. |
|
View & Edit | If this is selected for an instrument, the user will be able to view and edit the data. |
|
Edit survey responses | If this is selected for an instrument, the user can edit responses submitted on a survey. | Usually this should not be checked. Some examples where it is checked is on an e-consent to allow a study team member to sign the same e-consent survey as the participant. |
User Rights pertaining to Data Exports
Data Export Rights pertain to a user's ability to export data from the project, whether through the Data Exports page, API, Mobile App, or in PDFs of instruments containing record data.
User Right | Description | Additional Considerations |
|---|---|---|
Data Export Rights | Pertain to a user's ability to export data from the project, whether through the Data Exports page, API, Mobile App, or in PDFs of instruments containing record data. |
|
No Access | The user cannot export data for instruments which this is selected. |
|
De-Identified | The user can export data from instruments which this is checked with the exception all free-form text fields, date/time fields, and fields marked as Identifiers. |
|
Remove All Identifier Fields | The user can export data from instruments which this is checked with the exception fields marked as Identifiers. |
|
Full Data Set | The user can export all data. |
|