How to Apply Branching Logic

In the equation you must use the project variable names surrounded by [ ] brackets.

• You may use mathematical operators (=, <, >, <=, >=, <>) and Boolean logic (and/or). You may nest within many parenthetical levels for more complex logic.

You must ALWAYS put single or double quotes around the values in the equation UNLESS you are using > or < with numerical values (i.e., height, weight, BMI – text fields validated as a number).

• Example: [weight] > 80 (the subject’s weight is greater than 80 kg)

The field for which you are constructing the Branching Logic will ONLY be displayed when its equation has been evaluated as TRUE. Please note that for items that are coded numerically, such as dropdowns and radio buttons, you will need to provide the coded numerical value in the equation (rather than the displayed text label). See the examples below.

When you click on the green double arrow icon, you will be taken to the screen below. It is here that you will format the branching/skip logic.

In the example above, the [race_other] field will only appear if [demo_race] = ‘88’ is selected (‘88’ = “More than one race / Other race”).

1. Use the Drag-N-Drop method to create the framework for your advanced logic

2. If you wanted a field to show up the subject is..

   1. Female ([gender] = ‘1’)

   2. AND they are more than 10 years old

   3. AND less than 50 years old ([age]), the branching logic would be:

      [gender] = ‘1’ and ([age] > 10 and [age] < 50)

      

3. Then formatted the logic in the advanced logic syntax box

   

4. Click “Save”

ex) [unique_event_name][variable_name][current-instance].

Can fields from different EVENTS be used in branching logic (longitudinal only)?

Yes, for longitudinal projects (i.e. with multiple events defined), branching logic may utilize fields from other events (i.e. visits, time-points). The branching logic format is somewhat different from the normal format because the unique event name must be specified in the logic for the target event. The unique event name must be prepended (in square brackets) to the beginning of the variable name (in square brackets), i.e. [unique_event_name][variable_name]. Unique event names can be found listed on the project's Define My Event's page on the right-hand side of the events table, in which the unique name is automatically generated from the event name that you have defined (see below).

(found in Project Setup page^)

(Define My Events page showing event names that are used for appending variable names)

For example, if the first event in the project is named "Enrollment", in which the unique event name for it is "enrollment_arm_1", then we can set up the branching logic utilizing the "weight" field from the Enrollment event: ([enrollment_arm_1][weight]/[visit_weight] > 1). Thus, presuming that this field exists on a form that is utilized on multiple events, it will always perform the branching logic using the value of weight from the Enrollment event while using the value of [visit_weight] for the current event the user is on.

1. When referring to a Multiple Choice Single Answer question, the code referring to the answer comes after the “=” sign. 

2. When referring to a Checkbox Multiple Answer question, the code come before the “=” sign in parentheses (). 

Multiple Choice Single Answer Example: Below the first question asks for eye color. Then if eye color is “2” (green), branching logic coded on the following question permits the hair color question to be displayed. The branching logic code is written as:  [field_name] = ‘2’

Checkbox Multiple Choice Answer Example: Below the initial question asks what are you favorite colors? Multiple colors can be checked. However if blue is checked as one of the favorite colors, correct branching logic will display the question asking which shade of blue. It must be written as: [variable_name(2)] = '1' where variable name=[fav_colors], 2 is option number for blue, and “1” indicates True.

Example of INCORRECT branching logic: If the variable is outside of the '=' sign, the equation is initially allowed because it is valid coding. However, this is not the desired outcome because the question related to shades of blue should only happen if “blue” is selected.

While a “valid” equation, the below is incorrect for a Multiple Choice Checklist question

REDCap will display an error message only when you attempt to add records:

This is an example of why TESTING is critical. When creating the equation, REDCap will show either equation as valid because they are both mathematically accurate. However only one equation will provide accurate data for the project.

Wrong equation for the project outcome: The below equation has “mathematically correct branching logic” so REDCap says the equation is valid. However, the equation is invalid & inaccurate for project data:

This is the correct equation for the desired project outcome:

Example:  If your study has a number of questions that could only be answered after a child was born, you may wish to define branching logic based on the date of birth or the expected delivery date.  The branching logic could be defined a couple of different ways. This first method is more complicated and uses calculations.  Thus the second method is preferred.  Both are shown for your benefit.

Method 1 - Branching Logic based on a calculated field:

One way to define branching logic is to use the results of a calculated field as the trigger to display the conditional field.  For example, a calculated field could be created that displays the number of days since the birth of a child.  That field could also display negative values as the number of days in the future until the delivery of the child.  The date, calculated field and the field with the associated branching logic could be built similar to the following:

The formula for the calculated field "Days Until / Since Birth" would be as follows:

Calculated Field Formula "days_birth" 
datediff([child_dob], "today", "d", "mdy", true) 

Branching logic on the "Weight" field would be based on the results of the above calculated field "Days Until / Since Birth".  For example, the branching logic could be defined as follows:
Branching Logic Formula
([dob_days] >= 0) and ([child_dob] <> "")
The second half of the "and" expression specifies that the date of birth field must not be blank.  This will guarantee that the branching logic will not take place until a date of birth is entered.

In this first example below, the child is not to be born until tomorrow, so the calculated "Days Until Birth" is displayed, but the weight field does not show:

In this second example, the child is 3 days old, so the branching logic formula permits the weight field to be displayed:

Method 2 - Embed the datediff function into the branching logic

Alternatively, the "datediff" function could be embedded directly into the branching logic so a calculated field would not be necessary.  The date and associated field with branching logic could be built similar to the following:

Branching Logic Function
( datediff( [child_dob], "today", "d", "dmy", true ) >= 0 ) and ( [dob] <> "" )
Again, the second part of the "and" expression specifies that the date of birth field must not be blank.  This will assure that the branching logic will not take place unless a date of birth is specified.