Access is suspended after a year of no login activity. Contact REDCap Support to request it be unsuspended.

First, check to see if you have access to your project’s User Rights page which is on the left-hand side Applications menu. If you don’t have access, contact REDCap Support or check with other project user who may have access to the page to grant you access.

Next, click on the Add new user box and begin typing your user’s name. Select it once it appears in the list. Click on Add with custom rights. Click on the boxes of the rights to be assigned. Click on Add user.

If you don’t see your user listed in the Add new user box, there are two possible reasons:

1. If you do not find the user listed, and they have logged in before, their access may be suspended due to inactivity. Contact REDCap Support to have their access unsuspended.
2. If they have never logged into REDCap, ask your user to log in and set up their profile with the following form. Once set up, you should be able to find and select their username in the Add new user box.

*Please note!

• Do not enter the user’s email address in the Add new user box, as this will not grant them access.
• If your project has User Roles set up, make sure to add the user to the appropriate role if necessary.

No. To navigate between forms for the current record, select the colored dots indicating form status which appear to the left of the form name when a record is open. If your database is set up as a longitudinal database and you want to navigate between forms associated with different events, select the event grid icon located below the “Add/Edit” data entry link. Note that moving to a new form by selecting the form status indicator or the event grid icon will close the current form without saving entries. In order to save entries, select the “Save and Continue” button located at the bottom of the form before using the form status indicators to move to a new form. Alternatively, you can select the “Save and go to Next Form” button if you wish to move to the next form for the current record.

No. There are no restrictions on the length of forms. However, the best practice guidelines are to keep forms fairly short. Shorter forms are easier for data entry, and also ensure that you are saving your data more frequently so that it is not lost due to a login timeout.

Practically speaking, there is no character limit for either text box or notes field type. The limit is 65,535 single byte characters.

There are 18 pieces of information that are considered identifiers for the purposes of HIPAA compliance. When you indicate a variable as an Identifier, you have the option to “de-identify” your data on data exports. For example, if you do not want your biostats group to see names, addresses, SSNs, etc., then you would set these fields with “identifier = Yes.” In the Data Export Tool, the identifier variables appear in red and there are De-Identification Options you can select prior to exporting the data.

Yes. REDCap can display a matrix group of fields in either Single Answer format (i.e., radio buttons) or Multiple Answer format (i.e., checkboxes). A matrix allows you to display a group of similar multiple choice fields in a very compact area on a page. This makes data entry forms and surveys much shorter looking. Using matrix fields is especially desirable on surveys because survey respondents are much less likely to leave a survey uncompleted if the survey appears shorter, as opposed to looking very long, which can feel daunting — so having compact sections of questions can actually improve a survey’s response rate. A matrix can have as many rows or columns as needed, although the more choices you have, the narrower each choice column will be. Any field in a matrix can optionally have its own branching logic and can be set individually as a required field. A matrix can also optionally have a section header.

For a question with an unknown number of answers, such as how many medications someone is taking, you may want to display the fields only as they are needed. REDCap currently is not able to dynamically produce these fields; however, there is a way to use branching logic to do this. You can estimate the maximum number of fields you will need, create that many copies of your field, and hide/expose them as needed using branching logic. So, for example, if you think 15 is a good maximum, you would create 15 copies of the field. Then you could create a count variable that these fields would branch off of. Your branching logic would look like this: field1: [count]>”0″; field2: [count]>”1″; field3: [count]>”2″; and so on. So, if your variable is medications, and the respondent takes 2 medications, you enter 2 in [count] variable, then the med1 and med2 fields appear; if they take 3, you enter that, and meds1 to med3 fields appear.

Another method is to first create the maximum number of fields that you estimate will be needed, as above, and then hide/expose each field as the previous field receives data. Using this method will cause each field to show up as needed. Your branching logic would look like: field2: [field1] <> “”; field3: [field1] <> “” and [field2] <> “”; field4: [field1] <> “” and [field2] <> “” and [field3] <> “”; and so on.

A note of caution: In both of the above examples it is possible for one to enter data into one of the fields but for that field to later not be displayed to the user. This is a general issue whenever using branching/skip logic.

Yes. REDCap can call variables from different forms as part of calculated variables or branching logic. Be very careful when programming calc fields. Calc fields will not automatically update the stored value when data from the equation is entered on another form. Only when the save button is clicked on the form with the calc field will the field re-calculate and store the new value.

Simply previewing a form within the Online Form Editor will display all questions. In order to test the functionality of your branching logic, you must enter new records and test data directly into your forms, or take the survey yourself.

Any user with Locking/Unlocking privileges can unlock a record, regardless of who originally locked the record.

Yes. You or someone who has the rights to access the User Rights page must navigate to your User Rights page and assign the “Delete Record” option. The delete button will appear at the bottom of your forms. This deletes data in ALL forms for the record. In a longitudinal database, the “Delete Record” will delete all data in ALL events. Once you delete the data, there is no way to get it back!

To restrict a user from viewing sensitive fields, you must group all of the sensitive fields on one form and set the user’s data entry rights to “none” for that form. This will prevent the user from viewing the entire form. You cannot selectively prevent a user from viewing certain fields within a form.

Data Access Groups restrict viewing of data within a database. A typical use of Data Access Groups is a multi-site study where users at each site should only be able to view data from their site but not any other sites. Users at each site are assigned to a group, and will only be able to view data entered by users from that group.

A Public Survey Link will only exist for the first survey in a project and only if that survey is the first instrument in the project. The rest of the surveys will have custom survey links that can be emailed to the survey participants.

A survey is anonymous when you cannot link an individual survey participant to their responses. Identified surveys can be linked back to the individual survey participant. Surveys are anonymous when using a Public Survey link, or using the Participant List WITHOUT using Participant Identifiers. Surveys are NOT anonymous when using identifying questions (e.g., DOB, email), using Participant Identifiers in the Participant List, using the designated email field for survey invitations, and/or inviting participants for follow-up surveys AFTER taking a public survey.

Yes. It’s best practice to export your test data for review prior to moving your project into Production. In Development, all the applications function like they would in Production; however, changes in Production cannot be made in real time. It’s best to make sure your database is tested thoroughly, including the data export.

You have the option of deleting or keeping any data you have entered in Development when you move to Production.

To make changes after you have moved your project to Production, select “Enter Draft Mode” in the Online Designer tab. After making your changes, go back to the Online Designer and select “Submit Changes for Review.” The CRI REDCap Administrator will review your changes to make sure there is nothing that could impact data you have already collected. If anything is questionable, you may receive an email from the CRI REDCap Administrator with this information to confirm that you want to make the change. Any changes to the structure of a production database, such as removal of forms or modifying events in a longitudinal project, can only be done by the CRI REDCap Administrator.

Altering a database that is in production can cause data loss. If a production database must be modified, follow these rules to protect your data:

(a) Do not change existing variable names, or data stored for those variables will be lost. To restore data that has been lost in this way, revert to previous variable name(s).

(b) Do not change existing form names via a data dictionary upload, or form completeness data will be lost. Form names may be changed within the online form editor without data loss.

(c) Do not modify the codes and answers for existing dropdown, radio, or checkbox variables, or existing data will be lost or confused. It is only acceptable to add further choices to a dropdown, radio, or checkbox field.

Data from another source can be imported using the Data Import tool. Using the Data Import tool, data is imported in csv (comma separated variables) format. As long as the variable names in the csv match your variable names in REDCap, variables in the import template do not need to be in the same order as in the REDCap data dictionary.

Yes. Data in REDCap is stored in a centralized server that is backed up offsite nightly and hosted in a secure environment maintained by the CRI to ensure security, privacy, and confidentiality of your data. REDCap at the University of Chicago was implemented to allow you to secure your sensitive research data in a manner consistent with BSD policies. The CRI has adopted all applicable BSD Security Policies. REDCap has undergone penetration testing by University of Chicago ITS and is continually tested for any security vulnerabilities.