FAQ

One of the most common questions we receive is “What is the difference between a data collection form and a survey?” Below we highlight the differences. Data Collection Forms:

• Must be filled out by a user who logs into REDCap.
• Simply add the users to your project and have them click on “Add/Edit Records”
• Advantages:
  • Users entering data have the ability to see all data they’ve previously entered, edit previous responses, or check for updates.
  • Users not only have access to data entry, but all other REDCap features (reports/exports, Training Videos, File Repository, Data Quality checks, etc.).
  • Easier to troubleshoot errors because of the log that accompanies data entry.
  • All entries are logged with a timestamp. REDCap tracks who entered data, any changes with old and new values, the IP address where it was entered, the date and time, etc. NOTE: This timestamp is not included in reports or exports though.
  • User have the ability to give a form a status, marking it as “complete” or “incomplete” depending on what is most useful for workflow.

Surveys:

• Intended to be filled out by participants (non-REDCap users)
• No login required.
• Responses are anonymous unless survey invitations are used and combined with a Participant Identifier (different from marking a field as an identifier in the Online Designer).
• Web interface has a sleeker design and can be customized with Logos and instructions.
• Advantages
  • Survey responses are anonymous (can also be a disadvantage).
  • All completed surveys have a date and timestamp that can be included in reports and exports.
  • Easier to enter responses from a smartphone or tablet.
  • No need for logging in or adding users.

Adding and enabling surveys in your project can be accomplished in just a few clicks. Here’s how:

1. In Main project settings, select Enable button next to Use surveys in this project?
   
2. In Project Setup, select Online Designer:

   

3. In Online Designer, select Survey Settings:

   

A field is defined by the following attributes: type, label, name, validation, required, identifier, note.

Available field types:

• Text Box: single-line text box (for text and numbers)
• Notes Box: large text box for lots of text
• Calculated Field: perform real-time calculations
• Multiple Choice – Drop-down List: options for single answer
• Multiple Choice – Radio Buttons: options for single answer
• Checkboxes: checkboxes to allow selection of more than one answer
• Yes – No: radio buttons with yes and no options; coded as 1, Yes | 0, No
• True – False: radio buttons with true and false options; coded as 1, True | 0, False
• Signature: draw signature with mouse or finger
• Upload File: upload a document
• Slider/Visual Analog Scale: coded as 0-100
• File Upload: upload a document
• Descriptive Text (with optional image/file/video/audio attachment): optional formatting feature
• Begin New Section (with optional text): starts new section

In addition, branching logic can be applied to specify whether or not a question will be displayed, depending on values entered in previous question(s).

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.

If you can estimate what 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:

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 the 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:

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.

Production mode is designed to protect your data from unintentional data corruption or deletions which could wreak havoc on your carefully planned and constructed project. It does not unlock any additional features for the end-user and is only there as a safety measure to protect your data from your own mistakes. When you are in production mode, each version of your data dictionary is kept in Project Revision History and can be reverted to in the event of a mistake or to see when changes were made to a project. This is great when an accident, such as uploading a partial data dictionary occurs. Development mode does not have Project Revision History.

When you start a new database in REDCap, it is in development mode. Here you can easily create new forms, delete forms, change fields, and more. While this flexibility is great for designing and testing your database, it could easily cause problems once you’re ready to collect your real study information. When you are in production mode, any change to the data dictionary that could result in the loss of data will require approval (which can mean a 24 hour delay).

If the thought of losing the data you have entered into your REDCap project sounds painful, then you should be in Production mode. Production mode helps protect your data from accidental mistakes.

In general, we recommend you enter at least 3 test records in development mode, verifying ALL branching logic, survey flow, etc. If testing went really well and you have a bunch of good data in your project, you can move to production mode and KEEP existing data (uncheck the box to delete). In most cases, however, you will delete all your test data and start from scratch once in production mode.

When you’re ready to move your project to production, click the “Move project to production” button at the bottom of Project Setup

You’ll get a NOTICE that asks you to verify that you’ve thoroughly tested your project and that you understand future changes may require the approval of a REDCap Administrator.

You will also be asked to fill out a move to Production Survey that can be found here.

After you click "I agree" you will get one more prompt that asks that you’ve checked for identifiers and if you want to KEEP or DELETE all the data you’ve submitted so far.

For Research projects, your IRB must be in approved status.

For Clinical projects, the EMR Governance Committee must approve your project in REDCap before it can move to production and real clinical data can be entered.

For Operational, Quality Improvement or Other projects, there is no official oversight, but we encourage you to have your project reviewed by any appropriate groups or persons.

There is no reason to move a ‘test’ project into production mode. There are NO additional features that are enabled when moving to production. You can test and even collect data in development mode.

No. While REDCap is available at no charge to consortium partners, and the application is built using some Open Source components, the REDCap application is not Open Source. Vanderbilt University retains control over new functionality, bug fixes, and the release process.

NJH IST performs monthly patches to the REDCap servers. REDCap will have a very brief downtime between 6:00pm and 11:59pm on the fourth Thursday of every month. Typically, the downtime will last less than 5 minutes. If REDCap ever needs to be taken offline outside of this regular schedule, users will be notified via email ahead of time.

To retain all the special characters in your REDCap project:

When you download a data dictionary file from REDCap, it comes out encoded as UTF-8, which is correct if you want the special characters to display correctly. As soon as you open it in Excel and save it, Excel automatically changes the encoding back to ANSI. When you upload that dictionary back into REDCap you see jumbled characters.

There are two solutions to this problem:

1. Downloading this addin to Excel: http://jaimonmathew.wordpress.com/2011/08/23/excel_addin_to_work_with_unicode_csv/

   • When saving a data dictionary with special characters, just click the “Unicode CSV” tab and click Save, instead of saving it regularly. Upload this saved dictionary to REDCap.
2. Alternatively, you can save the data dictionary in Excel, then open it in Notepad or Notepad++, and then click save as to change the encoding to UTF-8.

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.

If you’ve ever asked for help from a REDCap Administrator, it’s likely you’ve heard the question, “Do you know your project ID?” Each project in REDCap has a unique ID number known as the “Project ID” or “pid”. Your project ID is the easiest way for REDCap Administrators to navigate to your project to help answer your questions. PLEASE INCLUDE YOUR PROJECT ID in any email request you send.

To find your project ID:

1. Click on “My Projects” then the specific project you need help.
2. The next screen will take you to the Project Home page (if you are in production) or the Project Setup page (if you are in development).
3. Your project ID will appear as “pid=xxxx” in the URL (aka web address) of any page within REDCap if you are inside of a particular project.