An ActionType is specified in the RuleAssignment and determines what should happen when the expression executes. ActionTypes include DiscrepancyNoteAction, EmailAction, NotificationAction, HideAction, InsertAction, ShowAction, and EventAction. A parameter must always be provided that defines when the action will be triggered to execute – either when the expression evaluates to true or to false.
The DiscrepancyNoteAction is used to automatically log discrepancy notes on the target item.
When triggered, this action provides a message, specified in the rule definition, to the data entry user. The user can choose to update the value(s) he has provided that caused the rule to fire, or he may proceed with the values unchanged by clicking save on the information again. In this case the DiscrepancyNoteAction will log a discrepancy note on the Target with a status of New and a type of Failed Validation Check. The color of the discrepancy note flag will turn to red.
In the Description field of the discrepancy note, the text will start with the RuleDef OID followed by a colon. After the colon the Message defined by the rule creator will display.
DiscrepancyNoteAction is executed after CRF validations are executed and as the data is being saved to the database.
If a DiscrepancyNoteAction has already been executed on a given target, and the value has not changed, a second discrepancy note will not be logged on the item again.
The EmailAction is used to send email to an email address or list of addresses.
When triggered, this action provides a message, specified in the rule definition, to the data entry user. The user can choose to update the value(s) he has provided that caused the rule to fire, or he may proceed with the values unchanged by clicking save on the information again. In this case the EmailAction will send an email to the list of addresses specified in the rule definition. These addresses are specified when the Rule is created. No record of the email action is saved in OpenClinica.
EmailAction is executed after CRF validations are executed and as the data is being saved to the database.
The NotificationAction is used to send an SMS and/or email notification to a Study Participant (when used in conjunction with OpenClinica Participate), or to send an email notification to any specified email address.
When triggered, this action provides a notification to the specified recipients. To send a notification to Study Participants, address the message to ${participant}. OpenClinica replaces ${participant} with the communication means for the Participant as specified when the Participant was connected to OpenClinica. The means of communication for Participants can be SMS, email, or both based on the connection information provided. (For more information, see Connect Participants.
The elements of a NotificationAction include the following:
To: ${participant} and/or a specific email address to whom you’re addressing the notification. Separate multiple addresses with a comma.
Subject: The subject of the notification (similar to the Subject line of an email)
Message: The content of the notification.
Parameters can be passed to the “To” and “Message” elements as follows:
Parameter | Description | To | Message |
${participant.firstname} | Participant first name | x | |
${participant.loginurl} | Participant URL with automatic login | x | |
${participate.url} | Participant URL without automatic login (requires an access code) | x | |
${study.name} | The name of the Study as defined in OpenClinica. | x | |
${participant.accessCode} | The single-use code the Participant must use to access OpenClinica Participate. | x | |
${event.name} | The name of the Event as specified in the Build Study task in OpenClinica. | x | |
${participant} | The Participant contact information as provided when the Participant was connected to the Study. This may have been a mobile phone number (for SMS notification), email address, or both. OpenClinica automatically sends the notification to any and all means that were provided for the Participant. | x |
For example, the following Rule will send a notification to any Participant who has an Event scheduled for the following day:
Notice that the Rule Expression uses _CURRENT_DATE and compares it to SE_INITIALTREATMENT.STARTDATE to determine that the Event is scheduled for the next day. (In other words, if TODAY is equal to the day BEFORE the visit and the status is not yet “completed”, send a notification. If you want to send a reminder one day AFTER the visit, you would use _CURRENT_DATE eq SE_INITIALTREATMENT_STARTDATE +1, meaning that the rule will trigger if _CURRENT_DATE is one day AFTER the visit was scheduled and the status is not yet “completed”.)
To force a line break, use n at the end of a line.
The ShowAction is used to show previously hidden CRF items or groups.
Note: A ShowAction Rule must be written in combination with a HideAction Rule. A Rule with a ShowAction will not work properly if there is no HideAction associated with it. Both actions must be created under the same Rule OID.
Within this action type is a DestinationProperty. This property is an OID of either an item or a group. When action is triggered, the items or groups specified will be shown.
To specify more than one item, or more than one group, there must be multiple DestinationProperty OIDs. This can not be a comma separated list of OIDs.
When triggered, and when the CRF items to be shown are in the same section of the CRF, this action provides a message, specified in the rule definition, to the data entry user. The message is used to alert the data entry person of new fields that are shown on their current section. Also, the items that are currently shown will be highlighted in yellow.
If the items are in a different section of the CRF, or another CRF entirely, the user will not see the message nor will they see the items highlighted in yellow to indicate they have been shown.
The Show action is not supported across event definitions.
ShowAction is executed after CRF Validations, and DiscrepancyNote, Email, Insert and Hide actions have been executed. Data has already been saved into the database before the new hidden items are shown.
Note: If the Rule XML ifExpressionEvaluates parameter equals blank (i.e. ifExpressionEvaluates = “”), once imported, the value will default to FALSE.
The HideAction is used to hide previously shown CRF items or groups.
Note: A HideAction Rule must be written in combination with a ShowAction Rule. A Rule with a HideAction will not work properly if there is no ShowAction associated with it. Both actions must be created under the same Rule OID.
Within this action type is a DestinationProperty. This property is an OID of either an item or a group. When the action is triggered, the items or groups specified will be hidden. To specify more than one item, or more than one group, there must be multiple DestinationProperty OIDs. This can not be a comma separated list of OIDs.
Items that contain a value in the database can not be set to hidden and will always be shown.
The Hide action is not supported across event definitions.
HideAction is executed after CRF Validations, and DiscrepancyNote, Email and Insert actions have been executed. Data has already been saved into the database before the items are hidden.
The InsertAction is used to insert data into CRF items.
Within this action type is a DestinationProperty. This property is an OID of an item. When the action is triggered, the specified item(s) will have a value inserted. To specify more than one item, there must be multiple DestinationProperty OIDs. This can not be a comma separated list of OIDs.
Within the DestinationProperty OID is the option to provide either a Value or a ValueExpression.
- Value is a static value you want inserted into the DestinationProperty. To insert a date, the format must be yyyy-mm-dd (e.g., 2014-12-24).
- ValueExpression allows you to calculate a new value or copy a value from one field to another. To use another items value as part of the ValueExpression you must provide a valid Item OID. ValueExpression supports all data types, including date and partial date (pdate).
The Insert action is not supported across event definitions.
The EventAction is used to schedule a future event or events. This is also known as scheduling or calendaring, and allows you to schedule one or multiple events based on the current event.
Within this action, the Target is the trigger that fires the rule. There is an EventDestination, which is the STARTDATE of the future event that the rule will schedule, and there is a ValueExpression that calculates the STARTDATE for the future event.
To define an EventAction, you must identify the Target, define the EventDestination, and ValueExpression, and specify the conditions for when to run the Rule (RunOnStatus). Following are three different techniques for implementing an EventAction:
- Schedule all subsequent events based on the date of the first event (View a sample)
- There is ONE Target (trigger) in this option – the Rule is triggered only for that Target
- If an Event STARTDATE is changed, this Rule does not update future Events
- Schedule all subsequent events based on the date of the current event (View a sample)
- There are MULTIPLE Targets (triggers) in this option – the Rule is triggered for any of the Targets
- If an Event STARTDATEis changed, this Rule dynamically updates all subsequent events
- Schedule the next event (and only the next event) based on the status of the current event (View a sample)
- This option does not display the entire visit schedule. Initially it only displays the first event. Once the first Event is started or completed, it displays the next event – and only the next event. Once the next Event data entry is started or completed, it displays the next event, and so on.