Longitudinal projects provide collection of data over time in order to track changes and progress. Longitudinal projects are useful in the following situations:
Long Term Studies
Clinical Trials
Recruitment & Enrollment Combinations
Multi-Site Studies
Repeating Surveys It is extremely important to give much consideration to the design, development and testing of your Longitudinal Project. Understanding reporting considerations & needs is critical. Thorough testing is essential for success.
INITIAL CONSIDERATIONS
Enabling longitudinal feature allows any form or survey to be reused over the course of time and provides opportunity to designate specific instruments at specific time points (events). Longitudinal instruments eliminate the need to recreate the same form for multiple time points. Instead, the form is created once and then assigned to various time points throughout the project. Examples of forms used in longitudinal mode include:
Medications
Lab results
Adverse events forms
NOTE: You must EXPAND the below section(s) to view the full content. Click the (>) carrot to expand.
These are the basic steps involved in setting up a Longitudinal Project. A step by step process is described in-depth below.
2. Enable Longitudinal Functionality
3. Set up User Rights, Roles, &/or DAG’s
Assigning User Rights to team members should be a carefully thought out decision. The consequences of poor user rights decisions could be damaging to the security and integrity of the project. See Knowledge Article User Rights & Roles
The User Rights page can be used to determine the roles that a user can assume within a REDCap database. The Data Access Group on the other hand determines the data visibility of a user within a REDCap database. A typical use of Data Access Groups is a multi-site study where users at each site should only be able to view data from their site but not any other sites. Users at each site are assigned to a group, and will only be able to see records created by users within their group. See Knowledge Article Data Access Groups
4. Define Events (and/or) Arms
5. Designate Instruments to Events
6. Test, Test & Test
a. It is strongly recommended that you test your projects prior to moving to Production to ensure the project works as desired and reports are presented in the desired format with complete data.
b. Use test data as close to real as possible and simulate the workflow you intend to use.
c. Knowledge Article – Testing Your Project
7. Setup Schedules (Optional feature- not required)
a. While setting up scheduling is options, it can only be used with Longitudinal projects, expand the below section to review Scheduling setup & functionality
Advanced Longitudinal Study
Two Arms and 3 Events are shown here, but you can have as many Arms & Events as you want / need for your study
Additional Considerations
Best practice to always add Record ID to every arm to prevent REDCap issues, especially if using surveys
Create a "single landing page" with just Record ID. Can be invisible to user with a "Thanks for Participating Page" with Submit to continue. See Knowledge Article Longitudinal Surveys
Actions that can cause data loss in Longitudinal Projects:
Deleting Events
Deleting Arms
Decoupling Forms from Events
If you create additional forms once project is in Production, need to request REDCap support to link forms to Events.
Give much consideration to User Rights. If you want to segregate data based on location but have a form that is common to both sites, a user with rights to that form will see data from both sites. Create Data Access Groups
Branching logic in a Longitudinal Project must identify the arm and the field name.
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'
Survey Expiration
Is server time, not what is on your computer
Survey expiration takes all copies of the survey offline.
Warning: If you have survey that is used multiple times in a longitudinal survey if you expire the survey after the first event, be aware that it will expire all the surveys in following events
Save and return later
The User Code is often lost and user can't find the code when they want to return to complete the survey.
Alternative is to design shorter surveys and poll multiple times via automatic invites
Deleting or Disabling a survey in Survey Settings.
There are 2 "delete" buttons for any given project.
1 is in Online Designer – deletes entire form and data is lost
1 is in Survey Settings – reverts survey back to a form. Data is still available
When defining Events it is important to think about the days offset and use an accurate representation in case you ever want to use scheduling