Once you are in your project, you can navigate to the Project setup section, which is effectively a checklist for your project. Working your way through the steps will give you an easy stepwise procedure for building your project.
REDCap is intuitive, so clicking on the next to the various functions will provide further explanation on what each aspect involves.

By default, a project will begin in 'Development mode', what that means is that any changes to the project will be made instantaneously as the project is still in the process of being developed.

The status of a project can be changed to 'production' in the last step of project setup. This signals to your project that real data is being collected and additional safeguards are provided to protect this data. For example, changes to questions in the project will need to be made in 'draft mode' before being applied to the project. If the changes affect existing data (eg. deleting questions with existing data), the REDCap Administrator may need to confirm the changes with you before they are approved.

Surveys

If you would like to utilise surveys, you can enable that functionality here.
A survey enables an instrument to be completed without the respondent needing access to REDCap itself (a link will be created allowing anyone who completes it to contribute data to your project).

To learn more about surveys, there is a more detailed 'REDCap Survey Guide' that can also be accessed in the additional resources. For a video tutorial on creating and managing surveys (5.5 minutes duration) click here.

Longitudinal data collection

Longitudinal data collection allows you to implement a project for a longitudinal study with multiple events.
For example, if you are collecting data for the same instrument (set of questions) at 7 different time-points, you can create 7 events in REDCap and designate that instrument to be tested at the 7 different time-points.
In the example below, there are 7 weekly events where I am collecting data for the 'Research Diary' instrument:

If you selected a longitudinal database when creating a new project, it will be enabled, otherwise you can enable longitudinal collection here in the project setup tab.
Once enabled, you can define your events and designate the relevant instruments to the events in which they will be collected. (More detail is provided on this in Step 3: 'Define your events and designate instruments for them', this step will only appear if the longitudinal data collection has been enabled.)
Click this box if you would like to see the longitudinal section from Step 3 now.

Longitudinal Data collection
Firstly, the events need to be defined through the additional step that appears for longitudinal projects:


Click here for a video tutorial (5.25 minutes) on 'Define My Events'.
Below is an example of a longitudinal project with 7 events defined. The relevant event names were typed in the event name box and 'add new event' selected.

Once completed, the 'Designate Instruments for My Events' tab, can be used to deginate the instrument to the relevant event in which they will be utilised in. 


Within Step 3 of the project setup (now step 4), 'Enable optional modules and customisations', there is the capability to use a scheduling module. 

Scheduling Module:
If a longitudinal project is enabled, the scheduling module can utilise the defined events in the project to link into the calendar to allow for better project management. 

By enabling the scheduling module, you can program in the defined events into the calendar using the days offset column. Click here for a video tutorial (7 minutes) on the Scheduling module.

Below is an example of the scheduling module where the start date has been set as 15/10/2020:


Below is the 'Calendar' with the scheduled events (this calendar is accessible under the Applications tab):

On the 'Project Home' page a calendar preview is also provided of upcoming events in the next 7 days:

There are a couple of options to design your project, the easiest is via the online designer.

The other option is via the data dictionary, which is essentially an excel file of the fields (questions) structured in a certain format. Once you have some fields in your project and wish to make bulk changes related to existing questions you can use the data dictionary to quickly make these changes. For example, the data dictionary could be useful when moving a large number of questions to a different instrument, duplicating existing questions multiple times or even duplicating sets of questions.

Online Designer
In the online designer you can build your project fields from scratch quite easily.
You can build the fields into specific instruments, which are separate pages/ forms for data collection.
To create a new instrument, click on and choose where you would like the instrument to go.
Once created, it can be easily moved. For a video tutorial on instrument development (6.5 minutes), click here.

One of the reasons for creating separate instruments is the capability of restricting access to specific data to certain users.
For example, if sensitive data is being captured in 'My First Instrument', you can limit which users have access to that instrument, either to view and/or edit data. This can be done via user rights which is one of the later steps in the project setup.
 
Other reasons for separating forms into instruments could be to:
- utilise surveys, which allows a link of the instrument to be sent, allowing the respondent to complete it without needing to login to REDCap. By having separate instruments as surveys, respondents can even be sent surveys that are relevant to them as not all instruments may be relevant to them.
- collect data at certain time-points, such as in a longitudinal project or repeated when required by using the repeating instruments feature.

To modify an instrument, simply click on the instrument's name.

Once inside the instrument, you will have the ability to add fields into the project.
If you are modifying the first instrument in your project, there will already be a field for the Record ID.

This field can be modified but cannot be deleted as it allows you to identify the records in your project.

To add a field simply click on  

Adding a new field

What are the different options when making a field?

Field type: The type of question to be used if collecting data. There are two type of fields that do not collect data, descriptive text fields, which allow information to be displayed, this includes attachments. There is also the 'begin new section' field type which divides your page into sections. If the relevant setting is enabled in survey settings, this field type can be utilised to divide one instrument into multiple pages. More information on field types can be found below.

Field label: The text that will be placed on the page, most often times will be the question that you wish to ask.

Action Tags: Tags that can be attached to the question to customise the data entry experience.
Example uses include hiding answer choices, setting the default value for a field, tagging a multiple choice answer as a 'none of the above' option, setting word or character limits, making a field read only.
For an online tutorial you can visit the following page: Action Tag Demo (+piping)

Variable Name: Short name of the field label to refer to the field in the project.
A variable is often referenced throughout a project in calculations or other features such as piping (examples in the action tag demo above) using square brackets [].

Validation (only for text boxes): 'Validates' text box fields, forcing the data to be entered in a certain format. More detail is provided in the next section.

Required: Marks a field as required .
If a field is marked as required and left empty, a prompt is provided upon the completion of an instrument.

Identifier: Marks a field as an identifier which allows it to be removed when exporting de-identified information from the project.

Custom Alignment: Provides options for the orientation of the field.

Field note: Small text that will be shown directly underneath the field which can function as a reminder or instruction for data entry.

The following video discusses the various REDCap field types.

For text box fields, the following validations are available:


Free text fields should be validated where possible.
For example, it would make sense to capture dates using date validated fields to ensure that dates are actually captured, which allows for easy comparison and filtering of data. By capturing validated dates, these can then be used elsewhere in the project eg. to carry out calculations.

By selecting a numerical validated field for numerical responses, additional parameters can be placed such as a minimum and maximum.  

For dates, there is a limitation that the minimum and maximum might shift based on the current date. For example, the admission and discharge dates cannot be in the future so the minimum and maximums would depend on the current date.

As of REDCap V12.1.0, dynamic minimum and maximums can be inputted. This involves using the word today or even piping other fields from your project into the minimum or maximum box. For example, the maximum value of a date that has occurred or is occurring would usually be today. If you were capturing admission and discharge dates, then the admission date could be set as the minimum value for the discharge date. Prior to this feature, data quality rules could be utilised to ensure data quality for dates. This is explained below. 

Data Quality
In instances where the data restraints fall out of the custom default validations provided by REDCap, you can utilise the module under Applications. Data quality rules can be run to assess the project for any data quality discrepancies. They can also be enabled for real-time execution (ie. to appear during data entry).

Below is an example of a data quality rule that I've set up to provide a warning if the admission date entered is in the future:


I have named this rule 'Admission date is in the future'.
The logic I have used is based on the datediff calculation, comparing the admission date ([admission_date]) with the current date ("today"): datediff("today",[admission_date],'d','dmy',true).
If the calculated value is >0, there is a discrepancy, indicating that the admission date is after 'today's' date.

Since real time execution is enabled, if a page is saved where the admission date is after the current date, a warning will pop up informing the user of the violation.

For this data quality rule, the following calculation was used: datediff("today",[admission_date],'d','dmy',true)>0.

Similarly, to prevent a date from the past being entered, the following calculation could be used: datediff("today",[admission_date],'d','dmy',true)< 0.

Data quality via calculations
Below is an example of date validated text boxes where admission and discharge dates are captured using D-M-Y (date-month-year) format. These dates are then used in a calculated field to calculate length of stay rather than manually typing the length of stay, which would introduce a potential source of error.

Calculations

To create a calculation, select a calculated field type and enter the calculation equation in the designated box. You do not need to remember formulas, if you wish to input a calculation, clicking ‘How do I format the equation?’ will bring you to the REDCap Help & FAQ Calculations section to assist you with formatting your equation. If you have any test records with data, you can test the calculation at the bottom to check if it is working. Alternatively you can test the calculation by entering data in a record.

The following page guides you through a datediff type calculation.

Questions with pre-defined choices

For questions with pre-defined choices, each answer choice will need to be coded.
The codes will be separated from the answer choice by a comma(,).
This code can then be used in calculations or other areas in the project where the answer needs to be referred to in a logic, for example, in a calculation, branching logic or report filter.
When exporting the raw data of the project, the codes will be shown (for data exports there is also the option to export the label, which is the actual answer not the code).
Examples of codes are given below for the Yes-No and True-False questions which are not modifiable:

The other field with previously non-modifiable options is the Slider/visual analog scale which is on a scale from 0-100. As of REDCap V10.8.0, custom minimums and maximums can be inputted. If values are not specified, the default values of 0 and 100 will be used. An example of its utilisation is below:

Multiple Choice Questions
Multiple choice questions allow the project user to define the choices in the question.

There are two multiple choice single answer questions, allowing one answer to be selected; drop-down list and radio buttons. There is another multiple choice question type, Checkboxes, which allow multiple answers to be selected.

In this following example, a respondent can only have one country of birth so I have chosen the single answer field type. Since there are over 100 choices, I have selected drop-down list over radio buttons. This saves space on the screen since the drop down answers only appear when clicked as opposed to the radio buttons which permanently appear on the page.



I have also enabled auto-complete for this drop-down. The result is that I can either click and scroll down the list or begin typing country of birth and the options will narrow down to the relevant options for selection:


Utilising a multiple choice question when you know the potential or expected answers is much more productive than utilising a free text box since the answers will be automatically grouped for analysis.
For example, everyone who selects Australia will automatically be grouped into the Australian answer. Utilising free text opens you up to potential issues such as spelling errors which means answers may need to be changed to the correct spelling prior to being used.
Using multiple choice options allows you to utilise the real-time stats and charts of the data in the project:

Multiple Choice Checkbox questions
The final multiple choice question type, checkboxes, are highlighted below. It provides options with square boxes instead of the circle radio buttons.
Checkbox questions allows multiple answers to be selected:

The final thing to point out in the designer is the capability of linking questions through:
Branching Logic

Once you have created your questions, you can link questions together by using the green branching logic button.

In the example below, we would like the respondent to 'Please specify other hospital' if the respondent answers 'other' to the hospital question. To set up branching logic, I would click on the green branching logic button of the question that I would like to appear like a branch from the original question.

Clicking the green button will open up the branching logic options.

I can use the 2nd option, the drag-n-drop builder to look for the answers I would like to link it to.
If I select multiple answers, I can either choose to show the field if all statements are true (AND statement) or any (OR statement).

Using the drag-n-drop builder automatically populates the logic at the top, which is the alternative and more advanced way to setup branching logic. In the example below, this logic is [hospital] ='2', which represents hospital equals other. Once you become more experienced with REDCap you could easily type this logic directly into the advanced branching logic syntax.

Optional modules and customisations
Step 3 is a set of optional modules and customisations that can be setup.
Short explanations are provided below, but once again, you can click the next to the relevant options in REDCap for more information.

Repeatable Instruments
Repeatable instruments allow you to repeat a data collection instrument as often as you would like. In contrast to a longitudinal setup where you define set timepoints to collect data, repeatable instruments have no designated timepoints or limitations for data collection. For example, if you require ad hoc collections for instruments such as diary entries, a repeatable instrument will allow you to create a new instance of the diary instrument when required:

Auto-numbering for records
Auto-numbering for records automatically assigns a new record to have the next numerical increment from existing record values. If no records exist, the record numbering will begin at '1'.

The add/edit page under data collection will be modified depending on the setting for auto-numbering.

Auto-numbering enabled
Below is the page for adding/editing records with auto-numbering enabled:


Auto-numbering disabled
When auto-numbering is disabled, a user will be able to type in an ID, if this ID already exists, it will take them to that record, if it does not, it will take them to a new record with that ID for creation.

Page for adding/editing records with auto-numbering disabled:

Scheduling Module:
If a longitudinal project is enabled, the scheduling module can utilise the defined events in the project to link into the calendar to allow for better project management.

Longitudinal Data collection
Firstly, the events need to be defined through the additional step that appears for longitudinal projects, step 3, 'Define your events and designate instruments for them':


Click here for a video tutorial (5.25 minutes) on defining longitudinal events.
Below is an example of a longitudinal project with 7 events defined.

Once completed, the 'Designate Instruments for My Events' tab, can be used to deginate the instrument to the relevant event in which they will be utilised in. 


By enabling the scheduling module, you can program in the defined events into the calendar using the days offset column. Click here for a video tutorial (7 minutes) on the Scheduling module.

Below is an example of the scheduling module where the start date has been set as 15/10/2020:


Below is the 'Calendar' with the scheduled events (this calendar is accessible under the Applications tab):

On the 'Project Home' page a calendar preview is also provided of upcoming events in the next 7 days:

Randomisation: 
The randomisation feature allows records to be assigned to different groups based on chance. It's most common use would be in clinical research or clinical trials where a patient is randomised to a particular treatment.

Email field and Twilio for surveys
The following two options allows REDCap to send survey invitations via email and phone respectively.

Designating an email field for surveys requires a field that is validated as an email field. This will allow an email to be listed in the survey distribution tools. If this is enabled, survey confirmation emails in public surveys will be automatically sent rather than asking the respondent for their specific email at the end.

Twilio allows you to make and receive voice calls and SMS text messages, this modules utilises a third party service called Twilio, which has small costs associated with it.

Additional Customisations
In the additional customisations section, there are other features you can utilise, the explanations provided being self-explanatory.

Bookmarks are another optional customisation that can be utilised in the project.
Potential uses for bookmarks could be to highlight particular pages for data entry personnel or shortcuts to commonly used reports. An example use is below.

User Rights
User Rights allows you to control the access levels of each user in your project.

The picture below shows some of the options in user rights:

Data Access Groups

Data Access groups are an additional way to limit the access of users.
In Data Access groups, users are limited to accessing the data of records from their particular data access groups.
Any records they create will also be added to their specific data access group.
A common use case is multi-site studies.

Click here for a video tutorial (7.3 minutes) on Data Access groups.

In the example below, I have created access groups for 8 different sites. When users are assigned to their relevant group, they will only be able to see records from their own group whilst contributing data to the entire project. A user not assigned to any group would be able to see all the records.

Testing a project

It is important to test your project to check that it works as expected.
As mentioned above, pay attention to whether branching logic and calculations work as expected.
To test these functions, create dummy records.
Records can be added via the Data collection tab utilising the record status dashboard or add/edit records options and selecting 'Add New Record'.

When testing, it is important to enter data as though you are capturing real data.
Consider the types of answers that can be provided based on how the questions are currently set up.
For example, if you have a multiple choice question, ensure that the common/ expected answers are actually response options, if not, you can add the response as an option.

Other things to look out for are the validation of your fields and the quality of the data you are capturing. For this, it is useful to test the entry of implausible data. For example, if you are capturing height in cm, it would be advisable to create limits for appropriate maximums and minimums in cm. This would prevent any outliers from data entry errors, such as the entry of height in metres or wildy incorrect typos, the latter being difficult to rectify without the original data source. Either of which would require the data to be cleaned prior to analysis. The project should be created in a way to ensure that only plausible data can be entered where possible. This is where testing and implementing data quality rules will be vital.

Basic things such as whether your questions have typos or make sense should also be considered.

It is also important to test out the practicality of your data collection process. Testing out the data collection process is important to nut out any workflow issues. If you have multiple staff working on a project, will the process of creating a record in the project work? Does every user have the appropriate access based on their role in the project?

If you intend to utilise surveys, test out the process that you will be distributing surveys and also test out completing the forms as surveys, as that is what the participants will be seeing.

If you plan to run specific reports on a regular basis, it is important to test these reports to see if your project has this streamlined.

For an example of some testing in action, please see the Introduction to REDCap Presentation between 37:52 and 49:10. 

If you are interested in specific tips regarding project testing considerations, you can have a look at this guide. The first section is essentially a replica of this page, you can skip to the Testing Tips/ Notes section.

Production Status
Once testing is completed, it is important to move your project to production status.
Production status effectively signals to your project that real data is being collected and additional measures are in place to protect your data.

If you have tested real data whilst in Development mode and would like to keep this data, you can choose to keep this data when you move the project to production mode or start with a blank slate of data.


The main difference in production mode is that changes to the project are not necessarily instantaneous.
To make changes in the online designer, a user would need to enter draft mode:

Once changes are drafted, they will need to be submitted for screening.

Depending on the change being made, there may be a delay in the change being implemented into the project. For example, if you delete a question that already has data collected, this will be flagged. In development mode, this change would be instantaneous. Any changes to the project that affects existing data will be flagged and cross checked by the REDCap administrator prior to being applied.

Example
An example of an existing question with data collected is below:

If we decide to add purple as option 4 with the code 4 (eg. 4, Purple) then the change would not affect existing data and will be approved.
However, if we give purple the code of 3 instead of 4, all existing answers that were coded 3 for yellow will still retain their code of 3 but instead of representing yellow will now appear as purple. As a result, this change would be flagged to the REDCap Administrator before being implemented. If a user is set on using 3 for purple, then any existing answers coded as 3 will need to be recoded.
If a user wishes to just have purple appear as the third option in the list they could do this by placing it with a new code in the 3rd position like below: 

This addition would not affect existing data.

Any changes to the database that do not affect existing data will be applied when submitted. An example of this change is the addition of an entirely new question.