Basic PROforma Concepts: Task properties
Task properties can be categorised into four groups: general, task specific, scheduling, and execution. This section provides a brief overview of the main task properties.
General Properties
Properties common to all tasks:
| Instance Name | An alphanumeric string representing the ID of the task. Example PatientDetailsEnquiry Note: Tallis indexes tasks by Instance Name, i.e. an alphanumeric string chosen by the author. This property is also used to create the task definition, so for this reason, Instance Names must be chosen to be unique (i.e. you cannot create two tasks called “foo” as the definition names will clash). If you want to create a second instance of an existing task, you need to link them. |
| Caption | A textual label that appears in the tree view and graphical view of the Composer; and as the task’s label when executing via the Tallis engine. Example Patient Details Enquiry |
| Goal | A truth-valued expression indicating the intention of the task. Example blood_pressure < 120 Note: In the current implementation of the Tallis engine goals are ignored, but it is hoped that future releases of Tallis will allow authors to specify the conditions under which the goal of a task is achieved. |
| Description | A textual description of the task. Example This enquiry collects patient demographics. |
Task Specific Properties
Properties specific to the various task types:
| Enquiry: Source | A data item whose value must be supplied. Example In the enquiry “Patient Details” a source could be the patient’s age, or height, or weight, etc. |
| Decision: Candidate | One of a set of options to be selected. Example In a decision called “Familial genetic risk assessment”, the candidates could be:
|
| Action: Procedure | An action to be performed. Example A procedure can be any number of things from a simple message (“reassure and discharge patient”), to instructions for some external system (e.g. update a database). |
Scheduling Properties
Properties that determine when a task should be executed:
| State trigger | An expression that has to be true before the task can be executed. The task remains dormant until it becomes true (even if its scheduling constraints have been met). Example The action “Control blood pressure” should only be executed if and when the expression blood_pressure = HIGH becomes true |
| Precondition | An expression that has to be met before the task can be executed.A task’s precondition is examined when, and only when, its scheduling constraints are met. If at that moment the precondition is false, the task is discarded. Otherwise, it becomes in progress. Example The enquiry “Check pregnancy history” should only be executed if the expression patient_gender = female is true. If it is false (or unknown), then the enquiry is discarded. Note: If the task should instead wait until the specific condition is met, a state trigger should be used. |
| Event trigger | A string that enables the end-user to trigger a task during the execution of the process-description.The event trigger is useful for creating processes that do not have a predefined workflow. During the execution of the process-description, the end-user is able to decide which path to take, by triggering the relevant task. Example A clinician in a patient consultation may choose to invoke one of a number of services, by selecting the relevant event trigger for each (e.g. “perform_biopsy”, or “perform_imaging”, or “discharge_patient”, etc.)Note
|
Execution Properties
Properties that affect the behaviour of a task when it is executed:
| Number of cycles | An integer defining the number of times a task will be repeated. Example The action “Take blood sample” needs to be executed twice in a Glucose Tolerance test. |
| Cycle until | An expression defining the conditions under which a task will stop cycling. Example The action “control_blood_pressure” should continue to cycle until the expression blood_pressure = normal becomes true. |
| Cycle Interval | An integer defining the time interval between cycles. Example The action “administer_drug” should cycle every 4 hours. Note: The time unit is hours. |
| Postcondition | An assertion that is executed when the task has been performed (e.g. a value assigned to a data item). Often used to specify information that will be needed by subsequent tasks. Example Once the action “control_blood_pressure” has completed the postcondition drug_administered = true is applied. |
| Optional | A boolean specifying whether the task must be completed (or discarded) for its parent plan (i.e. the immediately enclosing plan) to complete.By default, tasks are not optional. This means that their patent plan can complete only if the task is completed or discarded. If a task is optional, its parent-plan can complete even if the task remains dormant. |
| Automatic | A task that is automatic does not require confirmation from the end user. This has different implications on different task types:
|