Defining Events

Events are combinations of conditions and actions that specify what workflow should be triggered for participants and when. “Events” tell Discovery how to move participants through the study based on study’s protocol.  For each Study Task that is going to ‘trigger’ any Workflow, an Event Handler is added to that item and then “X” number of Action Groups (an action group is 1 set of conditions for 1 set of actions).

 

There are four types of Events:  Milestone/Study Task Update Events, Scheduled Task Runtime Events, Survey Submit Events and Survey Login Events.

 

1. Update Events are actions to be fired when the status or schedule date of a milestone or Study Task is updated.  For example, a survey might be added to a participant’s workflow, and the participant fails to complete the survey.  That survey’s status might be updated to “final incomplete”.  Upon this update, certain workflow should be triggered.  This is an example of a Survey Study Task Update Event Handler.

2. Scheduled Task Runtime Event – Actions that take place when the Scheduled Task Executes

3. A Survey Submit Event is utilized when the User wants to trigger an action to fire when a survey is submitted.  For example, the User may want to update the Participant Property “Mailing Address” with the value collected in an Illume survey variable.

4. Survey Login Events are utilized when the data captured in one submission of a survey needs to be passed into the datafile of a different submission.  This may be a single survey, wherein the data collect in the first administration of the survey are passed into the second administration of the same survey.  For example, a survey might collect medication usage at each visit.  The second time the survey is taken it might be valuable for participants to be able to see the medications they reported the first time the survey was taken.  Or alternatively, this might be utilized when data collected in one survey need to be passed into an entirely different survey.  For example, the data from a screening survey might be preloaded into a baseline survey taken at a later date.

 

Events can be based on three types of data:

1. Participant Definition Data (i.e. Data stored in Participant Properties)
2. Survey Variable Data
3. Study Task Status Data (status codes)

 

The available Actions for Update and Survey Submit Events are:

1. Email Alert – An email alert is an email that can be sent to [Participant], [Case Owner], or ANY user that has an e-mail address defined.  For example, a study may utilize a survey assessing depression.  If a participant responds in a particular way in the survey indicating suicidality, the study team may want an email sent to a clinician once the survey is submitted, telling the clinician that patient X indicated suicidality. When creating an Email Alert Users may pipe Participant information into the message.
2. SMS Alert – An SMS alert is a Text Message that can be sent to [Participant], [Case Owner], or ANY user that has a text capable phone.

 

Survey data may be piped using {V:VARIABLE-NAME} or {R:VARIABLE-NAME}.  Users may also use {U:PARTICIPANT_PROPERTY_NAME} but this will only use the values stored in Participant Properties at the time the survey was STARTED.

In other words piping in actions (e.g. email alert) specified in the Survey Submit Event works EXACTLY like piping in a survey.

 

3. Update Participant (literal) – – This is used to set a participant field to a fixed value rather than something dynamic. For example, a participant might be exited from a study due to medical reasons.  In this scenario you may want to set the participant property “DATSTAT_EXITREASON” to the appropriate code 3=Medical.  Updating a participant (literal) allows you to select the code from the list of available codes and set that variable to that specific code.
4. Update Participant (event data) – This is used in two different ways.

a. If the event is a ‘survey submit event,’ this can be used to map a participant property to a survey variable.  For example, a participant may indicate that she is a Female in a survey variable called “Gender.”  An event handler could set the participant property “DATSTAT_GENDER” to Female.  The setting of that variable depends on the event, i.e. what data are entered in the survey.  The value that should be set in DATSTAT_GENDER is not known until the event occurs (the event being the submission of the survey)

 

b. If the event is anything other than a survey submission, this can be used to set a participant field variable to some status code information. For example, if you have a participant date field, you can use this to map that participant date field to the date that a particular Study Task status was updated.

 

5. Update Milestone – Update the status of the current milestone
6. Add Milestone (survey submit actions only) – Add a new milestone for the participant AND update the status of the current milestone
7. Update Study Task – Update the status of a Study Task (set status code, change scheduled and/or due date, add a comment)
8. Add Study Task – Add a new Study Task for a participant (study items that are added MUST be marked as ‘Ad hoc’)
9. Custom Hook – Select a registered System Extension  to be run when the conditions are met
10. Randomize Participant -Using Randomization Schedules Participants can be assigned to other Study Arms