REDCap: Updating Already-Scheduled Automated Survey Invitations (ASIs) or Email Alerts

Updating Already-Scheduled Automated Survey Invitations (ASIs) or Email Alerts

If you are using ASIs or Email Alerts in your project that are sent after a delay, and part-way through your project’s lifetime you make changes to the message content and/or the alert timing, then these changes will not be applied to any email alerts or invitations that have already been scheduled – even if they aren't due to be delivered for months or years!

(You can see a list of all your scheduled-but-not-yet-sent ASIs and email alerts on the Survey Distribution Tools > Survey Invitation Log and Alerts & Notifications > Notification Log screens, respectively.)

(Also, to cut down on the verbiage, from this point on I'll just talk about ASIs, but everything below also applies to any email alerts you have configured via the Alerts & Notifications screen.)

***

Essentially, once an ASI has been triggered and dispatched to the scheduler, its content and configuration is "locked."

The Re-evaluate Auto Invitations function doesn't fix this either (at least, not on its own) – this  just looks at the ASI trigger conditions and either schedules a new email or deletes an already-scheduled one as appropriate. If an already-scheduled ASI should have content or timing changes, these will be ignored.

As such, the only way to update your scheduled ASIs is to delete your existing ones and then regenerate them via multiple uses of the Re-evaluate function.

IMPORTANT NOTE: You can only safely delete and regenerate your ASIs if you are using a field from your project as an anchor date:
Screenshot of portion of REDCap ASI configuration dialog using an anchor dateScreenshot of portion of REDCap ASI configuration dialog without an anchor date If you are using the default option (send after the ASI is triggered), and then follow the instructions below, your newly regenerated invitations will have triggered right now, so their scheduled delivery dates will be N days/hours from now i.e. completely wrong.

(See our ASI Tips & Tricks how-to for more information about using anchor dates.)

Instructions

  1. Log in to REDCap, open your project, and go to the Online Designer.
  2. Open the relevant ASI configuration dialog:
    Screenshot of REDCap ASI configuration dialog
  3. In the STEP 2 section, update the trigger logic so that is impossible to satisfy. The easiest way to do this is to require that a field have a value it cannot be assigned.

    In this example, we currently have trigger logic that says to only send the ASI if the participant isn’t withdrawn (the [withdrawn] field is a yes/no field that can have a value of 0 (no) or 1 (yes)). We could update the logic to look like this:

    [baseline_arm_1][withdrawn] = 2

    -and be confident that the logic is now unsatisfiable.
  4. Hit save, and then click the Re-evaluate button. Untick all ASIs except for the one you just modified, and then click the Re-evaluate selected surveys button.
    Screenshot of REDCap's Re-evaluate Auto Invitations dialog Because it's now impossible to satisfy the trigger logic for these invitations, REDCap will delete any that are scheduled-but-not-yet-sent.
  5. Go back to the configuration dialog and change the trigger logic back to what it was originally. (If you haven’t already made your changes to the message content or the timing that necessitate all this re-evaluating, do so now.)

    Hit save.
  6. Re-evaluate a second time, again limiting to only the invitation that you just modified.

    Now that the trigger logic has been changed back and is (presumably) satisfiable, REDCap will go through all your project records and schedule an invitation for any that satisfy the trigger logic, using  the updated message content and/or timing.

ASI Timing and Reminders

If you change the timing of the ASI, and after regenerating the invitations one or more are now overdue, they will be sent immediately, and this includes any reminders you may have set up!

For example, if you originally had your ASI going out 6 months after participant enrolment, but changed it to 3 months and then used the above guide to re-evaluate, then all the participants that had enrolled between 3 and 6 months ago would receive their invitations immediately.

If you had further set the ASI up so that two reminders should go out, one at 7 days and one at 14 days, then a participant that had e.g. enrolled 4 months ago would get all 3 emails at once (the original plus the two reminders), as the original ASI is now 4 weeks overdue, the first reminder 3 weeks overdue, and the second 2 weeks overdue.

Where you are changing ASI timing similar to this example, and using reminders, I would suggest using some additional trigger logic to essentially split your collection of regenerated invitations in two:

  1. Invitations that are now overdue (in the example above, those that enrolled between 3 and 6 months ago). For these reminders, we'll change Section 3 of the ASI dialog so that the invitations go out immediately (and thus, in this example, their reminders will go out 1/2 weeks from today).
  2. Invitations that are still not due yet (in the example above, those that enrolled within the last 3 months). For these reminders we'll still use the anchor date in Section 3 of the ASI dialog as it was set up originally.

You can split your invitations by including a clause in your trigger logic that references your anchor date, like so:

AND datediff([baseline_arm_1][enrol_date], "today", "d", true) > 90

This clause would mean that only ASIs for records where the participant enrolled more than 90 days ago would trigger.

AND datediff([baseline_arm_1][enrol_date], "today", "d", true) <= 90

Whereas this clause would mean that only ASIs for records where the participant enrolled less than 91 days ago would trigger.

You would perform steps 5 and 6 above twice, once with the first additional trigger clause added, and with the invitations set to go out immediately in Section 3, and then again with the second trigger clause added instead, with our original Section 3 settings.

Finally, you would go back and remove the datediff() clause entirely (as you won't need it going forward for any new participants).

Isn't this all incredibly fiddly and complicated!?

Yes, yes it is.

This is why ideally you don't update your ASIs once your project is in production. But the reality is that protocols can change during the course of the study, and that sometimes it will be necessary to make retrospective changes of this sort.

Remember, you can always contact University of Melbourne REDCap support at red-cap@unimelb.edu.au if you need assistance with updating your ASIs (or Email Alerts).