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

Unresolved include directive in modules/task_planning/pages/model_history.adoc - include::ROOT:partial$classes/task_plan_execution_history.adoc[]

Unresolved include directive in modules/task_planning/pages/model_history.adoc - include::ROOT:partial$classes/event_record.adoc[]

Unresolved include directive in modules/task_planning/pages/model_history.adoc - include::ROOT:partial$classes/task_plan_event_record.adoc[]

Unresolved include directive in modules/task_planning/pages/model_history.adoc - include::ROOT:partial$classes/task_event_record.adoc[]

Unresolved include directive in modules/task_planning/pages/model_history.adoc - include::ROOT:partial$classes/task_notification_record.adoc[]