Click on the magnifying glass to the right. Starting typing a topic you wish to learn about
Project Arms
Important Considerations
Arms can be used in the event that a study has multiple groups of participants, which follow unique workflows with unique timelines. For example, you could use 2 arms to separate the below groups:
Arm 1 (Intervention): this group has unique ‘Intervention’ instruments that do not apply to the (Waitlist group)
Arm 2 (Waitlist): this group of participants requires completion of different sets of surveys from the (Intervention group) which also occur 8 weeks after the (Intervention group)
ASIs (Automated Survey Invitations) can be setup for each arm to allow instruments to be sent under different conditions and timelines
By default, when a project is created, the project will host only a single arm.
Typically, a single arm is adequate for most project workflows and preferred for ease of use, given the below considerations regarding arms:
Randomization:
REDCap’s Randomization functionality can only be configured and applied to participants within the first arm of the project.
Public Survey Link:
Public survey links are only compatible with the first Arm within a project.
If you have a project containing multiple arms with a public survey link also setup, the public survey link will only create records in Arm 1.
Arm 2 requires manual creation of each record
User Rights:
User rights are not Arm specific, thus you cannot hide nor enforce viewing & access restrictions to specific arms, but instead enforce access rights to instruments as whole across all arms.
Record Keeping:
Using multiple project arms can complicate record keeping. Why?
When adding records to a project with arms, you have to specifically select the Arm you wish to add the record to before clicking ‘add new record’. Often users forget they have multiple arms causing error & confusion when adding new records and inputting record data. Examples of this below:
If auto-numbering is being used and you’ve created records (1-5) in Arm 1, then later navigate to Arm 2, to ‘add new record’, that record will be saved as (record 6), within Arm 2.
Let’s say you are not using auto-numbering and are manually creating each record, the system will not block you from creating duplicate record IDs across arms, but does display a warning message in the event of Record ID duplication.
Record ID duplication tends to cause confusion and mistakes when working throughout the project, especially if (record 1) in Arm 1 is a unique participant, different from the participant being tracked in Arm 2, also listed as (record 1).
NOTE: Once a participant is added to a specific arm, there is no built-in REDCap functionality to move a participant from ‘x' arm to 'y’ arm or vise versa.
The Process
To use ‘Arms’ your project must first be enabled as a longitudinal project
Navigate to your ‘Project Setup’ page and click ‘Define My Events’
Here you will see the option to add an addition arm (shown below in red)
Title the additional Arm & Save
Create your Arm 2, Events
Designate instrument(s) to Arm 2 events
Click ‘Designate Instruments for My Events’ tab
Select ‘Arm 2’
Click ‘begin editing’
Select you event/instrument designations
Save
Additional Considerations
Reporting: Reports will pull data from both arms, unless an Event Arm ‘filter’ is applied to your report
Data Exports: will include the ‘redcap_event_name’ field which indicates which arm the record data was exported from
Renaming Arms (and/or) Events can cause disastrous effects: if any unique arm/event names are utilized in conditional logic, branching logic, calculations, reports filters, data quality rules, etc, said rules/branching/conditions will become broken!
Branching logic in a Longitudinal Project: must append the [event_name] to the front of your field variable in order for branching to work with success.
Classical Branching Equation:
[field1] = '3'
Longitudinal Branching Equation:
Can cross both forms and events, so need to indicate event and field
[event_3][field1] = '3'
Event names differ from arm to arm, even if the event name is titled the same as the arm name is included within the event name that is auto-generated: (shown below in red circle)