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.

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

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.

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.

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.

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.

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

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

Select F11 to maximize the active window. Select F11 again to minimize the window when done.

If you plan to do double data entry for your project, contact the CRI REDCap Administrator to set this up before you begin collecting any data.

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.

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

REDCap’s advanced functions are case-sensitive and will not work if caps are included.

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!

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.

Yes. There are specific instructions to export the data into SPSS so that it will automatically read in all data with the field labels and option values.

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.

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.

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.

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. 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.

REDCap has been adopted by over 1,300 institutions worldwide. Deployment at these institutions has provided access to many other partnering institutions that do not have their own instance of REDCap. Several features offered by REDCap focus on fostering and supporting multi-site and inter-institutional collaborations and partnerships. REDCap has “Data Access Groups” capability which allows sequestering data by groups so that they can use the same capture instruments but only members at each site can see data they have collected. This allows standardized data capture and results in data integration and and economies of scale to achieve the large datasets needed for statistical validation of findings. With REDCap, it is easy to export the data dictionary or “codebook.” This allows various investigators to share their data capture instruments and easily create SOPs among their collaborations and within consortia. If you would like to publicly share your instruments, REDCap offers a community “Shared Library.” Due to its many deployments, REDCap acts as a platform, where the “Shared Library” acts like AppStore™, or rather an Instrument Store, where you can browse and download standardized instruments freely into your REDCap database and modify the forms as needed. Peripherally, REDCap has fostered development of reciprocal IRB relationships in the community, thereby reducing duplication of effort and encouraging and supporting multi-center studies.