Page Comparison

...

Arms can be used in the event that a study has groups of different participants, which follow unique workflows, however we encourage using (FORM DISPLAY LOGIC) for this use case, rather than arms. 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:

  • REDCaps REDCap’s Randomization functionality can only be configured and applied to participants in the first arm of the project.

• 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 1is 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

1. To use ‘Arms’ your project must first be enabled as a longitudinal project

   1. If you project isn’t already longitudinal, this typically indicates you do not/should not utilize the arms functionality! More info: https://utahctsi.atlassian.net/servicedesk/customer/portal/3/article/2341765121?src=1897803665

2. Navigate to your ‘Project Setup’ page and click ‘Define My Events’

3. Here you will see the option to add an addition arm (shown below in red)

   Image RemovedImage Added

   1. Title the additional Arm & Save

   2. Create your Arm 2, Events

   3. Designate instrument(s) to Arm 2 events

      Image RemovedImage Added

      1. Click ‘Designate Instruments for My Events’ tab

      2. Select ‘Arm 2’

      3. Click ‘begin editing’

      4. Select you event/instrument designations

      5. 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.

  1. Classical Branching Equation:

     1. [field1] = '3'

     2. Longitudinal Branching Equation:

        • Can cross both forms and events, so need to indicate event and field

        • [event_3][field1] = '3'