How to setup your program schedule

Modified on Fri, 10 Nov 2023 at 05:29 AM

Want to create your own custom workflow within the WeGuide system for your users? This is the guide for you. 


In this article, we will describe the concept of a "program schedule" in WeGuide and how you can set up your own programs. If you have specific questions about setting up a program schedule, please reach out to your implementation manager. View the tutorial underneath to understand the basics, the article will cover more advanced functionalities:




TABLE OF CONTENTS



How to set up your program schedule


In order to set up your program schedule, you will need to follow a few steps. We will explain each step in detail below. In this article, we will show you how to set up a schedule for a complex program. The steps for self-reported programs are the same, just less extensive. 


For more information on the concept of Complex programs, including records and Participants, you can check Records and Participants explained


First, make sure you have created a program


Now, create your first engagement

  • Make sure you're on the Edit Program page of the program that you want to edit and click on the plus icon, as shown underneath.
  • A new engagement will now be created and you can start adding the details. See below for an explanation of how to do this as well as a screenshot of this. 

Image 1: Click on "Add engagements" to start adding your engagements


Image 2: After you click on "Add engagement" the above section will appear, below we explain each field that you can edit


When you're adding an engagement, you need to follow the steps underneath. We will explain each of these steps in detail


StepsDescriptionExamples
1.Select your engagement typeForm --> Daily Question 4 Report

2.Define your trigger condition (logic)After enrollment
After appointment 
After the condition is met 
After actions status is met 
After the record condition is met

 After the participant has completed a survey
 After another engagement is expired/completed
3.Define your trigger condition (time)4 days
4.Define at what time to send it (optional)at 15:00
5. Define to whom to sendProfessor
Doctor
6.Define how often it should be triggeredEvery time the condition becomes true
Only once per participant
7.Set recurrence (optional)Every 1 day, stops after 7 occurrences 
8.Set expiry (optional)After 24 hours
9.Turn on/off the available messageOn.  After  24 hours
10.Turn on/off the reminder messageOff
11.Show record identifier in the app
Off
12.Return resultsOn. 


Step 1. Select engagement type

  • Select your engagement type. Here you can select between a Form and a Message. For the forms, you will be able to select the forms that you've added to your program. For the messages, you will be able to select all the messages that are available in your organisation. 

  • In the example above, we want to schedule a Form and we want to use the Daily 4 Question Report form for it. So this will mean that a form will be sent out to a participant, who will be asked to complete it.


Step 2. Define your trigger condition (time)

"When should we send it" - time

  • We need to specify when and under what condition the engagement should get sent to the participant, so which condition has to be met. The condition always consists of two parts:

    1. Time: a certain time needs to be met. So for example, 5 days after something.

    AND

    2. Logic: a logic condition needs to be met. So for example, after action status is met

    Once these are combined, this creates the logic condition based on which the engagement will be sent, so in this case 5 days after action status is met.


Other important notes

  • If the logic becomes true, but the time is still in the future, then the engagement will be scheduled.
    • E.g. if an engagement is scheduled for 10 days (time) after a condition is met (logic) and the logic becomes true, then the time condition will become true in the future (in 10 days), so the engagement will be scheduled to be sent out in 10 days. 
  • If the logic becomes true, but the time is in the past and can never be met, then the engagement will never be sent or scheduled.
    •  For example, in case a participant is already enrolled for 5 days in the program and a new engagement gets added to the program that is scheduled 0 days or 2 days after enrolment, then the engagement will not be sent or scheduled for this participant. The time condition (0 days after the enrollment date) will never become true.
  • You can specify a time in days, hours or minutes.
Note: if you want an engagement to be available the moment the condition is met (which we will explain underneath) then select 0 days. That will mean that it's going to trigger instantly when the logic condition is met.


Step 3. Define your trigger condition  (logic)

"When should we send it" - logic

There are multiple logic conditions available, to define based on what the engagement should be triggered. Let's look at the options:

  • After enrolment. The moment a participant joins a program, their enrolment date and time are saved. You can schedule an engagement based on this enrolment date & time. You will be able to select which participant(s) need to enroll in order to trigger the engagement. 
    •  If a participant enrols on the 1st of October and the engagement is scheduled for 5 days after enrolment, then the engagement will be sent 5 days later, so on the 6th of October. If you select 0 days after enrolment, a participant will receive the engagement as soon as they enrol.
    • Note - In case a participant is already enrolled for 5 days in the program and a new engagement gets added to the live program that is scheduled 0 days or 2 days after enrolment, then the participant will not receive this engagement, since the condition (0 days after enrolment date) will never become true.


  • Before/after an appointment. WeGuide can be integrated with external appointment systems so that we can get appointments from other systems into the WeGuide system. If you have this enabled, you can then schedule engagements based on appointment dates. You can send an engagement before or after an appointment date.
    • So if a patient has an appointment on the 25th of March at 09:00 and an engagement is scheduled 5 days before the appointment date, then the user would receive the engagement on the 20th of March at 09:00, in case no sent time is specified.
      • In case the appointment only gets added on the 23rd of March, then no engagement will be scheduled, since the time condition (send 5 days before the appointment) will never become true.

  • After treatment is completed. WeGuide can be integrated with external systems to get treatment information. In case you have this integration enabled, you can trigger engagements based on when the treatment is completed.

  • After previous engagements are completed. Schedule a survey when another engagement is completed by the participant.
    • "Completed" is defined as an engagement being completed by the participant
      • In the case of a recurring engagement, a single instance of the engagement will need to be completed for this to trigger. 
      • Note: you will only be able to schedule based on previous engagements when you have added and saved at least 1 engagement to your program. The options for selecting previous engagements won't show up if you have not saved any engagements.

  • After the condition is met. If the above options are not suitable for you, you can specify your own condition and create your own logic. How logic works in WeGuide is described here, but underneath are a few examples of what you're able to do:
    • Schedule based on a response in a previous survey.
      • [lifestyle_age] >= 10
      • [lifestyle_food_option_1415] = true
    • Schedule based on the score of a previous survey.
      • [lifestyle_age_score] > 5
    • Scheduled based on the status of a previous engagement
      • [engagement_1] == 'expired' || [engagement_2] == 'expired' 
        • In case an engagement is recurring, then:
          • Expired: all instances of the engagement needs to be missed in order for an engagement to have the status 'expired'.
          • Completed: If the user has completed all instances of the recurrence, then it will be marked as'completed'.
          • Available: If all instance of the recurrence are available to the participant, then the engagement will be marked as 'available'.
          • Cancelled: If all instance of the recurrence are cancelled from the admin portal, then the engagement will be marked as 'cancelled'.
          • Queued: If all instance of the recurrence are queued to be sent , then the engagement will be marked as 'queued'.
  • After the record condition is met. This allows you to schedule engagements based on conditions that are related to mandatoryrecord attributes. Scheduling based on optional attributes is currently not supported. You can schedule based on date fields and/or text fields:
    • Schedule based on record attribute (date field)
      • In case you have added a date field to your record attribute, you will be able to schedule based on this. An example:
        • On your record, you have added a Vaccination Date field that is called vaccination_date
        • Fields can be referenced by using [record_<name of the field>]. So in the case of vaccination_date, you can refer to the field by using the variable  [record_vaccination_date]
        • You can now use this field to trigger logic. So you can for example do this:
          • After condition is met: [record_vaccination_date] + 90 == today()
          • In this case, the engagement will be triggered 90 days after the vaccination date of the individual record. When it's actually sent is dependent on the time condition.
        • You can also combine it with other record attributes. An example:
          • [record_dob] + 90 == today() && [record_deceased] == 'false' 
            • In this case, the engagement will be triggered 90 days after the date of birth from the individual record, but only when the deceased status for the record is false. When it's actually sent is dependent on the time condition.


Step 4. Define at what time to send it (optional)

  • You will be able to specify the exact time when the engagement should be sent out. If you don't enter a time here, then the time will be based on the trigger. Some examples:
    • If the participant enrolled in the program at 09:15 and you have created an engagement that will be triggered 2 days after enrolment, without a time specified, then the engagement will be made available 2 days after the enrolment data, at 09:15.
    • If the participant enrolled in the program at 09:15 and you have created an engagement that will be triggered 2 days after enrolment, with a time specified (16:00), then the engagement will be made available 2 days after the enrolment data, at 16:00.
    • If you schedule an engagement on the same day as the condition becomes true (e.g. 0 days after enrolment) and if the time has already passed, then the engagement will be sent the next day at the set time. Two examples:
      • An engagement is set to "0 days after enrolment", send at 14:00. The participant enrols himself at 15:00. The condition is true (after enrolment), we need to send it straight away (0 days) at a set time (14:00). In this case, it's already passed 14:00 so the engagement will be sent at 15:00 the following day. 
      • An engagement is set to "0 days after the condition is met", send at 14:00. The condition is met at 16:00, the engagement will be scheduled for the next day at 14:00  

Step 5. Define to whom to send

  • In a simple program, there is only one participant and all engagement will by default be sent to this participant. Therefore, this option is not available in a simple program. 
  • In a Complex program, you have multiple participants, so you need to select which participants an engagement will go out to. 
    • For example, you may want to send a "Welcome to the program" engagement to a Patient and their Parent, but you will want to send a "Review Treatment plan" engagement to their Clinician. 
  • With this feature, you can select one or multiple Participants that will receive the engagement. Every participant that you add will receive this engagement.
    • In case the participant type is optional and isn't added for an individual record, then no engagement will be scheduled for this record and participant type since no participant is added to this participant type for the record. In case the participant gets added later to the participant, then the engagements will be scheduled based on condition.
    • In case the condition becomes true, the engagement will be scheduled for the participants selected for this engagement. So for example, engagement 5 gets triggered to the Professor and the Doctor when engagement 4 is completed. So when the Doctor completes engagement 4 (as an example), the condition becomes true and the engagement is triggered to both the participant types: Professor and Doctor. It doesn't matter who completed the engagement, the condition is met, hence the engagement is scheduled. 


Please note, "send to which participant" functionality is not available for self-reported programs since there is only one participant type in these programs


Step 6. Define how often it should be triggered

"Trigger this engagement"

  • You will be able to specify how often this engagement should trigger.
  • There are two options for how often it should be triggered:
    • Every time the condition is met. In this case, every time the condition becomes true, the engagement will get triggered for the participant(s).
    • Only once per patient/participant. In this case, the engagement will only be sent once to each participant in the program. If the participant has already received this engagement (as part of the same record or another record), they won't receive it. 
  • A few examples
    • Engagement: Send 2 days after enrolment.
      • A participant is enrolled into a program as a primary parent for a record. The engagement will get planned for 2 days after their enrolment date
      • A participant is or has enrolled again into a program, as a primary or as a secondary parent for a new record. It doesn't matter what participant type the participant is enrolled in, they are enrolled for the second time in a program, for a new record.
        • If the "trigger this engagement" was set to every time the condition becomes true, then the engagement will be scheduled again for the participant, after they enrol themselves again into the program for the new record.
        • If the "trigger this engagement" was set to only once per patient/participant, then the engagement won't be scheduled again for the participant, after they enrol themselves again into the program for the new record.
    • Engagement 2: Send 0 days to "Covid patient" after the action status becomes "Tested Positive"
      • A record with a participant (Covid Patient) gets created. The record doesn't have an action status yet.
      • The record status is changed to "Receiving test". A few hours later, the status is changed manually or automatic to "Tested Positive"
      • The engagement gets sent to the Covid Patient. 
      • The patient completes isolation and the status is changed to "Recovered"
      • The patient is not feeling well again, the status is changed to "Receiving test". A few hours later, the status is changed manually or automatically again to "Tested Positive"
        • If the "trigger this engagement" was set to every time the condition becomes true, then the engagement will be scheduled again for the participant, every time they receive the "Tested Positive" status.
        • If the "trigger this engagement" was set to only once per patient/participant, then the engagement won't be scheduled again for the participant, only the first time they receive the "Tested Positive" status.
    • Engagement 3: Send 0 days after the condition is met to the participant type Professor. Condition is[engagement_1] == 'expired' || [engagement_2] == 'expired'
      • Engagements 1 and 2 are made available to the professor, with an expiry set.
      • Engagement 1 expires. 
      • Engagement 3 is sent to the professor
      • Engagement 2 expires (later in time or at the same time)
        • If the "trigger this engagement" was set to every time the condition becomes true, then the engagement will be sent again to the participant, since the condition is true again
        • If the "trigger this engagement" was set to only once per patient/participant, then the engagement won't be scheduled again for the participant, since it's already been sent to this participant once.


Step 7. Setup recurrence 

  • If you toggle recurring on, you can set up recurrence for your program. You can define how often it should be repeated (every 1 day, every 7 days, etc) and after how many recurrences it should stop (e.g ends after 7 recurrences). Some examples:
    • If you want your engagement to repeat every day for 2 weeks, then turn recurrence on and set the repeat frequency to 1 day and ends after 14 occurrences.
    • If you want your engagement to repeat every week for 8 weeks, then turn recurrence on and set the repeat frequency to 7 days and ends after occurrences.


Note: in case you set an engagement to trigger 5 days after enrollment and you set the recurrence frequency to 1, then the engagement will only be sent 1 time, 5 days after enrollment. The recurrence condition is irrelevant in this case.


Step 8. Set expiry


  • In some cases, you don't want the participant to complete the engagement anymore since it's time-sensitive. For example, if I would like to know what somebody ate for breakfast, you can ask the day after but probably not a week after, since most likely they forgot. In this case, you want to automatically expire the engagement so that the participant doesn't need to complete it. 
  • When you turn the expiry on, you can specify how long the engagement should be available for, until it expires. So if you set this to 24 hours, then the engagement will expire 24 hours after it became available. Inside the application, the participant is able to see when the engagement is about to expire as is shown underneath.


Participants will be able to see when an engagement is expiring inside the application.


Step 9.  Turn on/off the available message

  • In case you want to send a notification to the participant when the new engagement becomes available, then turn this on. In case you want to deliver it silently (no notification will be sent via email, SMS or push but the engagement will be visible in the app), then leave this off. You will be able to specify if it will be sent to their preferred method, non-preferred method and/or via push notification (see step 11). 


Step 10.  Turn on/off the reminder message

  • In case you want to send a notification to the participant when they haven't completed an outstanding engagement within a certain time period, then turn this on and define the time period (e.g. 3 hours). 
  • When the engagement is not completed by the participant within the specified time period, a notification will be sent to the participant to notify them that the engagement is outstanding. 
  • If the user has completed the engagement (or when it would have expired), the reminder won't be sent.
  • For each reminder, you will be able to specify if it will be sent to their preferred method, non-preferred method and/or via push notification (see step 11).
  • You can add more than 1 reminder. Simple press the + Add Reminder button to add an additional reminder to your engagement. 


Step 11. Define how we should reach out to your participant


  • For each available message,reminder and for the engagement type "Message" you can specify how we should reach out to your participant. You can select the following options:
    • Preferred: We will reach out to the participants via their preferred communication method(s). This can be e-mail and/or mobile. 
    • Non-preferred. We will reach out to the participants via their non-preferred communication method(s). This can be e-mail and/or mobile.
    • Push. We will reach out to the participants via push notification, in case they have installed the iOS or Android application and have enabled push notifications.  
  • This functionality is mainly used for the following usecases:
    • You don't want to send e-mail and sms notifications to your participants, but only push messages.
    • You want to guarantee that we reach your participant. This is normally used for the final reminder. In this case, you will select all three options. Please be careful with using this option, since it could frustrate participants if you misuse it. 


Step 12. Show record identifier in the app 


Step 13. Return results

  • In case you want to allow participants to complete surveys in multiple go's and give them the opportunity to view their entries, then this toggle needs to be turned on. We recommend leaving this toggle on by default unless discussed differently with your implementation manager. 


Overview of how an engagement looks when you have set up recurrency, reminders and expiry. 







Was the article missing some information or unclear? Please click on the thumbs down below and let us know how we can improve. Your feedback is always appreciated.











Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select atleast one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article