Issue with Survey Queue and Event Chronology in REDCap

[Laure Sillis]

Dear REDCap Community,

We are experiencing a recurring issue with the survey queue in our longitudinal REDCap project and are seeking advice or solutions.

Situation: Participants are sometimes redirected to an earlier follow-up survey if a certain instrument is not complete. This issue seems to arise because REDCap does not recognize the chronology of events and places "old" surveys in the queue.

Project Details: Our project involves multiple events, and we use automated invitations and the survey queue to display the appropriate instruments to participants at each stage.

Example: Participants reported that after completing a follow-up survey, they were redirected to an earlier instrument from a previous event. This occurred because there is no automatic fallthrough in the queue between certain events (certain conditions need to be fulfilled). We attempted to resolve this by adding additional conditions to the survey queue, such as for event 1:
[event_1_arm_1][status] = '1' AND [event_2_arm_1][status] = '' AND [event_3_arm_1][status] = '' AND [event_4_arm_1][status] = '' AND [event_5_arm_1][status] = '' AND [event_6_arm_1][status] = '' AND [event_7_arm_1][status] = '' AND [event_8_arm_1][status] = '' AND [event_9_arm_1][status] = '' ...  (similar conditions were made for the other events)

Questions:

• Has anyone experienced a similar issue, and how did you resolve it?
• Are there better ways to configure the survey queue to prevent old surveys from reappearing when a participant has progressed to later follow-up surveys?

Any help or suggestions would be greatly appreciated! Have a nice day.

Best regards,

Laure Sillis

PhD researcher KU Leuven, Belgium

[Ken Eaton]

We had similar issues and added criteria to each instrument in the queue that compared the visit date for the event against today's date. i.e. if the event was the enrollment event, we had an instrument that captured the visit date and used criteria like:
datediff([enrollment_arm_1],[visit_dt],'today','d')<14
This fixed our problem.

Ken Eaton

--
You received this message because you are subscribed to the Google Groups "Redcap Open" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redcap_open...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/redcap_open/4fa0d75b-b3c6-4c73-8d42-464dd1ae2632n%40googlegroups.com.

[Joachim Geeraert]

Hi Mrs Sillis,

Many project face the same issue because the Survey Queue is/was often abused for directing participants through a list of surveys.

At our institute, users who try to start a project where the Survey Queue contains multiple starting points without a strict sequential dependency ..

e.g.
→ In a longitudinal project, the start of a second event is not dependent on fully completing the first event.
→ (Using survey-specific email invitation fields), multiple recipients in one record are asked to complete their part of the queue
→ In a simple project, a second ASI is not dependent on the full completion of the first part of the queue

..will get a warning:

The conditional logic used in the Survey Queue will be evaluated at the record level for ALL events, so not within the context of ONE event.
When using the Survey Queue in a project with multiple starting points, there is a possibility that unfinished surveys (from a previous event, previous part of the queue or meant for a different recipient) will reappear at a wrong time or for the wrong respondent. This could lead to confusion, data loss, incorrect answers and even data leakage.

.. and we suggest to avoid using the Survey Queue functionality for directing participants through surveys. If you want to direct respondents through a pathway of specific surveys based on logic, please consider
→ disabling the Survey Queue
→ using Auto-continue with optional Conditional logic to guide a respondent through a list of surveys
→ Form Display Logic with "enabled support for Survey Auto-Continue" to conditionally skip surveys (in some/all events)

So the suggestion is not to add conditions to the Survey Queue but to evaluate (e.g. in a TEST COPY) if the project can safely be transformed away from the survey queue.

Sincerely,

Joachim