Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Logical Containment Structures

Work Plan

The top-level formal concept defined is the Work Plan, which

  • consists of one or more Task Plans;
  • is a definition of work to be performed by one or more workers in order to achieve a defined goal with respect to a subject of care.
  • is assumed to be executable within a single computational context (e.g. a 'Task Planning engine'), in which methods of notification and worker communication are available, enabling the state of progress of the work defined in the Plan to be fully represented. 

Task Plan

Within a Work Plan, each included Task Plan is:

  • a definition of work to be performed in a single work context, by a 'principal performer' and possibly other participants. 

Task Group

The principal type of container of Nodes in a Task Plan.

Nodes

Decision Nodes

Technically, these are currently special kinds of Task Group, but we will probably change that in v2. The general concept is a decision group consists of a root node followed by 2 or more branches. Each branch does work like a Task Group in that it contains elements.

Condition group / Condition Branch

This is like an if / then / elseif statement, where every branch contains a Boolean-valued expression, eg. '$sys_bp > 160 or $body_temp > 40', '$sys_bp > 180' etc.

For this kind of structure, each outgoing branch carries a potentially complex expression (might be too big to display by default in its entirety)

Decision Group / Decision Branch

This structure is like a case or switch statement: the root node carries a single potentially complex expression of the form $xxx = a + b / c whose result can be Boolean, Numeric, Time duration etc, and the branches contain range expressions like 

  • boolean: $xxx = True, $xxx = False
  • numeric: $xxx >= 100, 14 < $xxx <= 62, etc
  • duration: $xxx > 4 days, 28w <= $xxx <= 39w.
  • coded: $xxx = high; $xxx = medium, $xxx matches {low, very low}

You could display the ranges in other ways e.g. $xxx matches |0.0 .. 100.0| or similar.

Event Group / Event Branch

This is a wait state, each branch is like a when/then rule. When one of the conditions becomes True, that branch is followed. The 'when' part is expressed as a 'Task Wait' entity (see below).

Task

A Task is a 'doing' object, i.e. represents an item of work. The 

Kinds of Task

xxx

xxx

Task Wait

UML diag ref; UML class spec.

Object representing a point in time in terms of one or more events. The start_window is used to add an 'acceptable delay' time within which the Task should be start with respect to the intended start time. The timeout attribute can be used for non-deterministic Events.

  • clock time: event = TIMELINE_MOMENT, CALENDAR_EVENT;

  • notification-based: event = CALLBACK_NOTIFICATION or MANUAL_NOTIFICATION, SYSTEM_NOTIFICATION;

  • task-linked: event = TASK_TRANSITION, e.g. 1hr after previous Task done;

  • state-linked: event = STATE_TRIGGER, e.g. 'when systolic BP > 165';

  • any event with added delay: DELAY_EVENT.

Events

UML diag ref;

The various kinds of Event in a Task Wait object can be specified in the following ways:

  • CALENDAR_EVENT: use a date or date/time, e.g. '2018-04-22', possibly with a calendar symbol
  • TIMELINE_MOMENT: is an offset from the time origin of the Task Plan e.g +2d; this can be converted to calendar time once the plan has started, but probably should be displayed in both forms, e.g. '2018-04-22 (+2d)'
  • TASK_TRANSITION: occurs when a Task has undergone a lifecycle state transition, e.g. 'Task 54 {Done, Cancelled}'
  • STATE_TRIGGER: event representing an expression referring to one or more tracked variables, reaching a value or passing a threshold value (here 'state' refers to something in the outside world, usually a patient variable like BP, platelets etc).
  • MANUAL_EVENT: Event type representing the manual notification of a real-world event to the system, such as arrival of a test result, manually taken vital sign value over a threshold etc;
  • SYSTEM_NOTIFICATION: Event type representing a notification from a system of some event, represented by notification type and reference identifier.
  • DELAY_EVENT: any other kind of event, with an added delay;
  • CALLBACK_NOTIFICATION: a callback from elsewhere in the plan has occurred.


  • No labels