Plan Execution History

Overview

The history of execution events from a Work Plan execution is represented in the runtime instances of classes defined in the proc.task_planning.history package, of which EXECUTION_HISTORY is the root.

PROC task planning.history
Figure 1. proc.task_planning.history package

As shown above, two types of execution event are defined:

  • TASK_EVENT_RECORD: type representing a change to one consitutent Task. Thus, if the performer cancels a particular Task within the list, a TASK_EVENT_RECORD will be added to the history, including Task id, time, and reason; notifications can also be recorded on such events;

  • TASK_PLAN_EVENT_RECORD_: type representing any kind of execution event not linked to a specific Task, for example 'plan abandonment', 'new principal performer'.

The first type may also include forward references to EHR Entries that were committed as a result of a Task being performed. This facilitates logical indexing of planned and performed work items.

ISSUE-fwd-refs: entry_instance is a forward reference - which requires updating the Task Plan after the Tasks have beed performed and relevant Entries committed. Is this complication worth the benefit obtained, i.e. directly followable links rather than querying, to find Entries from the Task Plan items? Is being able to determine the resulting Entries starting from the Task Plan even useful?

The Execution history for a Plan execution will grow and might become quite long for some Task Plan executions. How it may be persisted in various ways. The following possibilities are all compatible with both the model, and typical EHR requirements:

  • In the Task Plan application persistence:

    • persist the full history, delete or archive once the Task Plan is fully completed;

  • In the EHR:

    • persist the full history in some or all cases, if useful in the EHR environment (e.g. for teaching);

    • persist a partial / filtered version of the history, e.g. retain only cancel and abort events, on the basis that completed Tasks will show up as ACTIONs elsewhere in the EHR;

    • don’t persist any of the history - rely on the workflow application persistence for it during execution, and forget afterward.

This approach cleanly separates the definitional representation of a Task Plan, which should only change if changes to the plan are made, and the execution state, which is built during the work performance.

Class Descriptions

TASK_PLAN_EXECUTION_HISTORY Class

  • Definition

Class

TASK_PLAN_EXECUTION_HISTORY

Description

History of Task Plan execution events and notifications. May be used by a workflow application to record all events during execution.

May be persisted in the EHR in partial or complete form, or not at all.

Attributes

Signature

Meaning

0..1

task_events: List<TASK_EVENT_RECORD>

Task-level execution time events.

0..1

plan_events: List<TASK_PLAN_EVENT_RECORD>

Execution time events that occurred at the Task Plan level, i.e. not to a particular task. These include events such as Task Plan abandonment.

EVENT_RECORD Class

  • Definition

Class

EVENT_RECORD (abstract)

Description

Abstract parent of types representing execution time events on a Task Plan.

Attributes

Signature

Meaning

1..1

time: Iso8601_date_time

Time the event occurred.

0..1

description: String

Optional description associated with the event. Would typically be populated for Cancel and Abort events.

TASK_PLAN_EVENT_RECORD Class

  • Definition

Class

TASK_PLAN_EVENT_RECORD

Description

Record of an runtime event to a Task Plan, including abandonment, performer allocation and re-allocation and so on.

Inherit

EVENT_RECORD

Attributes

Signature

Meaning

1..1

details: Hash<String, String>

Other details as a name/value list.

TASK_EVENT_RECORD Class

  • Definition

Class

TASK_EVENT_RECORD

Description

Record of an event for a single Task. Records task identifier, time, resulting lifecycle state and optional reason.

Inherit

EVENT_RECORD

Attributes

Signature

Meaning

1..1

task_id: String

Identification of Task in the Task Plan structre using a path of the form /task_group_id/task_group_id.

1..1

lifecycle_state: TASK_LIFECYCLE

The lifecycle state that was reached due to this event.

0..1

notifications_sent: List<TASK_NOTIFICATION_RECORD>

Notifications that were performed as part of this Task Event.

0..1

entry_instances: List<LOCATABLE_REF>

Forward references to Entry (e.g. ACTION, OBSERVATION etc) that was recorded as a result of this Task being performed. If this is set, it indicates that the planned Task is 'done' i.e. checked off the plan.

1..1

preconditions_satisfied: Boolean

Set to True if all preconditions defined on the corresponding Task were satisfied at runtime. If set to False, and there were preconditions, this means that preconditions were overridden by the user at runtime.

1..1

wait_conditions_satisfied: Boolean

Set to True if all wait_conditions for the corresponding Task were satisfied when it was performed. If False, and there were wait_conditions, wait_conditions were overridden by the user at runtime.

0..1

lifecycle_transition_reason: String

Optional reason for lifecycle transition.

TASK_NOTIFICATION_RECORD Class

  • Definition

Class

TASK_NOTIFICATION_RECORD

Description

Record of a notification to another party (i.e. performer).

Attributes

Signature

Meaning

1..1

reciever: PARTY_PROXY

Identification of the receiver party

1..1

receiver_task_plan: String

Identifier of receiving Task Plan.

1..1

details: Hash<String, String>

Other details as a name/value list.