Tallis Training

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:
  • HIGH (greater than 25% lifetime risk)
  • LOW (less than 17% lifetime risk)
  • MEDIUM (17 - 25% lifetime risk)
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
  1. The task does not execute unless the trigger is invoked, even if scheduling conditions are met.
  2. When the trigger is invoked, the task executes, even if scheduling conditions are not met.
  3. The task state returns to dormant after completion.

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:
  • Plan & Enquiry: The automatic property is not applicable for plans and enquiries
  • Action: The action is confirmed automatically by the engine (the procedure is not displayed to the end-user).
  • Decision: The recommended candidate(s) are committed automatically (the candidates are not displayed to the end-user).
Top | «Prev | Next»

Last update: