Click on the magnifying glass to the right. Starting typing a topic you wish to learn about
Surveys - Start to Finish
- Lindsey Brown-Taylor (Unlicensed)
- Alyssa Hill
- Randy Madsen
- Mary Irion
Initial Considerations
REDCap projects can be very simple (a single survey that is one page) or very complex (a multi-site study with several arms and a combination of both surveys and data entry forms for separate groups of participants).
In either case it is crucial to thoughtfully design & plan your REDCap Project in advance, especially if it is going to involve surveys:
A thought-out design and an even more thorough testing of your survey study prior to moving to production will greatly enhance the success of your project and avoid unwanted pitfalls!
The Process
This article will guide you through setting up a survey from start to finish. Please reference the linked Knowledge Articles for detailed insight in specific aspects of designing a survey.
Develop your project instrument(s)
If your project will only be used for data entry, proceed to the testing process
If your project will utilize surveys to capture data from participants you must: Enable Survey and determine if you wish for the survey data being collect to be tracked or anonymous.
For a survey collection to be truly anonymous, you must distribute the survey via public survey link and not collect any identifiable information.
After enabling a survey, the Survey Settings page is displayed. This is where you design your survey, such as choosing the survey title that is displayed to participants, selecting font, text size, and configure its settings, such as the question display format, setting an expiration date/time, enabling Text-to-Speech functionality, entering the survey completion text, and setting up confirmation emails for respondents.
Please review: Survey Settings
Next, determine how you will distribute survey(s), options below:
If there is only a single survey in your project, use a Public Survey Link
If there are multiple survey(s) in your project, we suggest using Automated Survey Invitations (ASI) where needed.
If you use this method, you must also Designate & Enable a survey participant email field
The email field must also be captured within a instrument that comes before the survey you wish to send, otherwise there will be no email on file to send the automated survey invite.
A secondary advanced option is to use: Survey Queues
Otherwise, surveys can be manually composed individually at the record level, or by using the participant contact list.
The above methods are most commonly used, however there are other methods available for use, these methods are linked below:
Once you’ve designed your project, perform testing to ensure accuracy then request the project be moved to ‘Production’:
Ensure applicable fields are marked as PHI/PII:
You should test EVERY instrument in your project and test how you will distribute each survey to ensure the distribution method setup is working with success!
If the project is a simple single survey, without branching logic or anything else, 5 cases should sufficient.
If the project is a Longitudinal Project or uses advanced features such as, Automated Survey Invitations, Randomization, or Branching Logic, etc. then you may require upwards 40+ test records
Follow guides: Moving A Project To Production & Production Approval Process to complete the testing process then request your project be moved to production
Real Data Collection is NOT permitted when your project is in ‘Development’ Mode per University Policy!!
How to know if you project is in Development mode? This will be shown within your project under the ‘Project home and Design’ > Project status section, shown below in red.
Additional Considerations Related to Surveys
Enabling the Survey Specific Email Invitation field within Survey Settings
Allows you to override the project level email field for that specific survey instrument. This is useful when you may have a specific survey that should be associated with a participant record, but needs to be completed by someone other than the participant. For example if your participants are patients battling cancer, and you have many surveys for the participants regarding symptoms, hospital visits, and goals, but you'd also like to collect a survey for participants' caregivers regarding caregiver burden, you can create that survey but assign a different email field to send to.
the email of the caregiver would need to be collected prior to this survey, typically in a data collection form, and validated as an email text field (see article on Field Validation)
Designing instruments to be Automated Invitations even if your project is not a survey.
If your first instrument is a data gathering instrument about an upcoming seminar, you can design a second instrument as a survey whose purpose is to send automated invitations / reminders to interested attendees. You must capture the attendee's email in the first instrument and set the second instrument as a survey itself. Then in the Automated Invite, create logic that will send the event reminder to the attendee at a designated date / time. You must also enable Designate an email field from the Project Set Up page:
In this example, the second instrument will exist as a blank survey instrument. The automated invitation "compose message" section will have default text for a link & URL to the survey, you'll need to delete this default text, since the link/URL would lead the participant to a blank survey. The automated invitation would just be used to schedule a reminder email to participants who meet specific logic from the first instrument (i.e. signed up for an event)
Adding participants after a survey has been distributed:
If users want to use a participant list, it does not need to be entered before the project is moved to production. The participant list can be added during production.
Many studies that want to distribute surveys via email may not have their participant list ahead of time; they may attain them as the recruit participants. This is the typical approach for clinical trials.
As records are added with recruitment, emails get automatically added to the participant list.
Creating anonymous surveys for incentives
Make the survey optional non-anonymous (i.e. put a field at the end something like "Please enter your email if you'd like to be entered into a drawing for a $50 gift card as a thank you for participating in this study" Then you can do a drawing and email the winner(s). People who don't want to list their email don't have to.
Use branching logic to populate a link to a gift card for every Nth participant. Organize hidden fields that will count # of responses, then create N fields for N # gift cards you'd like to give out, each with a link to a gift card that populates at the end of the survey.
Allow each survey respondent to receive a personalized link to the survey
Disable auto-numbering for records in your project so you can assign the [record_id] as the unique study ID that will link their REDCap data to their genomic data
Create an instrument form (not a survey) as the 1st instrument in the project to collect a "fake" email, label this field [email]
designate an email field for sending surveys (in Project Setup) → select [email] as that field
Create your survey instrument that you'd like to distribute via unique link
left menu > designer
after you create the instrument, make sure you click "enable" as a survey
create an excel document with the following headers
add the ID numbers you'd like in remaining rows of column A (this can be as simple as starting a 1 and continuing until you've reached the # of unique links you want to produce (i.e. the number of participants you're recruiting)
add a fake email to every row of column B associated with an ID in column A (for example: test@gmail.com)
save the excel document as a .csv file
import the data to your REDCap project:
left menu > data import > select csv file > import
attain the unique links in your participant list:
left menu > survey distribution tools > participant list > select the desired survey instrument from the dropdown > see individual links for each record here or download all as excel
Re-using data collection surveys (example: pre and post surveys are almost identical) Using longitudinal design for survey at PRE and POST events (time points) vs having 2 surveys: pre-survey and post-survey at a single event.
if the questions asked at both PRE and POST are the same, it is recommended to have 1 survey, and use a longitudinal design with 2 events (PRE and POST) and assign the survey at both events
if the questions are different, or questions at POST depend on answers at PRE, it is recommended to have 2 surveys: pre-survey and post-survey. Branching logic can be used to populate specific questions in post-survey based on pre-survey answers (see branching logic article)
if questions are similar enough that you’d like to create the pre-survey, then copy to create the post-survey which can be modified based on specific needs follow these steps:
(need screen shots for copy instrument)
Adding questions to existing surveys
Adding a question to the existing survey will not delete any data that has already been collected. Existing records will just have a blank for the new question when you export their data.
Adding a question to the existing survey will not change the public survey link, so anyone who has the link already but hasn't completed the survey, can still access it both before and after you make the change.
Prevent a person from leaving the survey before they finish filling it out.
In the Survey Settings enable the option to click the "Save & Return Later" button to stop the survey and return at a later time to complete it
Minimizing Data Loss
For long surveys – consider multiple surveys and group into survey queue, with the auto-start option: surveys will appear to participants as one survey only. Advantages: data will be saved at the completion of each survey; there will be less chance to lose data in case of poor Internet connection
You can also consider splitting survey to multiple pages with section headers
Targeting Surveys to Specific Groups
Survey queues may be used as 'branching logic' at a survey level. For example, if there is a set of questions that are specific to a given gender, instead of adding a branching logic to each question, create a survey with this set of questions only and specify the condition in the survey queue e.g. [gender] = "1"
The same logic can be useful when scheduling automated invitations
Deleting or Disabling a survey in Survey Settings.
There are 2 “delete” buttons for any given project.
1 is in Online Designer – deletes entire form and data is lost
1 is in Survey Settings – reverts survey back to a form. Data is still available
** These Knowledge Articles have been developed by the University of Utah’s REDCap Analysts using data garnered from the REDCap Consortium Library and other REDCap Affiliate members’ online resources and documents.