Page Comparison

Important Considerations

...

Important Considerations

Arms can be used in the event that a study has groups of different participants, which follow unique workflows, however we discourage using Arms encourage using (FORM DISPLAY LOGIC) for this use -case and instead suggest the use of (FORM DISPLAY LOGIC) due to the below calloutscase, 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 Randomization functionality can only be configured

  for a single Arm. It is NOT possible to randomize participants using multiple arms.When adding new records to the project, it’s critical the participant be added to the correct arm

  • 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

  . Once a participant is added to a specific arm, there is no built-in REDCap functionality to move a participant to different arm. This can only be accomplished using manually data enter/export/import. Additionally

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

  having

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

...

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 Added

   1. Title Arm & Save

   2. Create Arm 2, Events

   3. Designate instrument(s) to Arm

   events (just like you would in a single armed, longitudinal project)

   1. Designate & Save

...

1. 1. 2 events

      Image 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!