CHOP-CGTInformatics / REDCapTidieR

Makes it easy to read REDCap Projects into R
https://chop-cgtinformatics.github.io/REDCapTidieR/
Other
33 stars 8 forks source link

[FEATURE] Make REDCap Event Level Order Accessible for Longitudinal Projects #210

Closed rsh52 closed 2 weeks ago

rsh52 commented 1 month ago

Feature Request Description

After #209, we now have expanded information about REDCap events under the redcap_events supertibble for longitudinal projects. Currently, this includes the columns redcap_event, event_name, redcap_arm, arm_name, and repeat_type. Example:

# A tibble: 10 × 5
   redcap_event       event_name             redcap_arm arm_name repeat_type    
   <chr>              <chr>                  <chr>      <chr>    <chr>          
 1 screening__enrollm Screening & Enrollment 1          Arm 1    repeat_separate
 2 21_day_followup    21 Day Follow-Up       1          Arm 1    nonrepeating   
 3 28_day_followup    28 Day Follow-Up       1          Arm 1    nonrepeating

However, each of these columns is a character type. For downstream processing, there is no way to determine the event level order from the supertibble.

Proposed Solution

Instead of having a separate object summary with all events, perhaps we could include a column above for "event_order" or similar that assigns a numeric value to the row equal to the event level order.

# A tibble: 10 × 6
   redcap_event       event_name             redcap_arm arm_name repeat_type     event_order
   <chr>              <chr>                  <chr>      <chr>    <chr>                 <dbl>
 1 screening__enrollm Screening & Enrollment 1          Arm 1    repeat_separate           2
 2 28_day_followup    28 Day Follow-Up       1          Arm 1    nonrepeating              13
 3 2_month_followup   2 Month Follow-Up      1          Arm 1    nonrepeating              14

This can be calculated internally at link_arms() when we grab all the events with REDCapR::redcap_event_read(), the output of it is already in the correct order.

https://github.com/CHOP-CGTInformatics/REDCapTidieR/blob/771a56a35bb065e8354bd4113cb16768011574ca/R/utils.R#L153-L162

Additional Context

This came up while working on REDCapExploreR in an attempt to shift all reliance of the record_status_dashboard() function over to the supertibble, and nix any API requirements for tokens.

We are able to assume the factor level order of the form names because they should be represented by the order they appear in the redcap_form_name column, identically to what comes out of REDCap itself.

Checklist

ezraporter commented 1 month ago

I'm not opposed to this solution but an alternative would be to make event_name a factor that has all the levels in the right order. This is consistent with how we handle categorical variables in the data tibbles so I prefer it but not strongly.

rsh52 commented 1 month ago

I'm not opposed to this solution but an alternative would be to make event_name a factor that has all the levels in the right order. This is consistent with how we handle categorical variables in the data tibbles so I prefer it but not strongly.

Sure that works too, probably preferable! Still would need to come from determination with redcap_event_read() and then implementing the factor change back in after the link_arms() function output here.