button.
The Internal Trigger is an attribute of an Arezzo task. You can specify an Internal Trigger to activate an eForm or visit when certain conditions become true. This works differently from a Task's Precondition. See below for a comparison of the two.
For example, you may wish to only activate certain forms once registration is complete, or once you know the gender of the subject.
The Arezzo Terms report in the Study Data Diagnostic Utility module can be used to list all existing internal triggers and preconditions in a study definition.
You do not need to add scheduling constraints to eForms or visits which have Internal Triggers; because they will automatically remain inactive until their Trigger conditions become true.
You cannot deactivate a visit or eForm once its Trigger conditions have become true – once activated it will remain active, even if the Trigger conditions subsequently become false.
A task’s Internal Trigger is different from its Trigger property. The Trigger property is for advanced Arezzo users and is not directly supported within MACRO.
An Internal Trigger on an eForm does not affect the completion of the visit so the eForm does not have to be filled in for the visit to be 'complete'. In particular, if a cycling visit only contains eForms with internal triggers, all visit cycles will be created immediately (because each visit cycle is immediately complete). For a cycling visit, it is advised to always include at least one eForm that is not cycling and has no internal trigger.
Start the Arezzo Composer application for a study.
Select the Plan task (pink rectangle) representing the visit or eForm for which you want to add an internal trigger. Never add an internal trigger to an Action task (blue square) as this is likely to disrupt the correct functioning of MACRO.
In the Task attributes area, type a condition into the Internal Trigger field.
Note: Make sure you do not enter the condition into the Trigger field.
You can launch the Expression Editor by clicking the button.
i. The Internal Trigger
isknown( person:subjectidentifier )
will only activate a visit or eForm once the subject has been registered (the term person:subjectidentifier refers to a subject’s registration ID).
ii. The Internal Trigger
Screening:Personal:Sex = ′f′
will cause an eForm to remain inactive unless the data entry user enters f for the subject’s sex. If a value of m is entered for the question Sex, the eForm will remain inactive.
iii. If a study contains Adverse Event forms (called AE) in each visit, and the AE form contains a question called Event for the description of the adverse event, the Internal Trigger
count( _:AE:Event ) > 5
will cause an eForm to be activated if more than 5 adverse events are reported.
Note: The underscore character used here in the place of the visit identifier refers to 'any visit'.
We recommend that you use Internal Triggers rather than Preconditions if you want to activate eForms and visits selectively.
If a task has a Precondition attached, the task will not be activated unless the Precondition is true. However, a Precondition is evaluated once only, and if it is false, the task is permanently "discarded" and will never become active (even if the Precondition subsequently becomes true). The time at which a Precondition is evaluated is when the task is "scheduled". If a task has no Scheduling Constraints (and is not inside a plan that has Scheduling Constraints), it becomes scheduled at the point a new subject is created. So any Preconditions which refer to MACRO data are always going to be false at this point because no data has been entered yet. If a task has Scheduling Constraints, its Precondition will be evaluated when the Scheduling Constraints are satisfied. So if a task has a Precondition which refers to MACRO data, it must be scheduled after the eForm which contains the relevant data (and the data must be Mandatory).
By contrast, an Internal Trigger is continually evaluated, and the task is activated when it eventually becomes true, which can be when the relevant data becomes available. It's like a "waiting Precondition". No scheduling constraints are required.
The only situation in which using Preconditions may be preferable is when a study contains hundreds of tasks with Triggers. Replacing some of the Triggers with Preconditions may improve performance.