Click on the magnifying glass to the right. Starting typing a topic you wish to learn about

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

  • Arms can be used in the event that a study has groups of unique participants, which follow unique workflows.

  • There are many considerations to take into account when considering the use of Project Arms.

Important Considerations

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


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)

    1. Title Arm & Save

    2. Create Arm 2, Events

    3. Designate instrument(s) to Arm 2 events

      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!

  • No labels