...
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
...
. Characterised by:
- description: Text (mand)
- principal_performer: TASK_PARTICIPATION - can be visualised as the role, which is usually a kind of person
- definition: the root Task Group containing the contents of the plan
- subject: may be set to a particular patient, in which case something might be visualised, to show it is a personal plan.
The other properties can be shown on a meta-data panel. Ignore properties whose names are in grey.
Task Group
The principal type of container of Plan Item Nodes in a Task Plan. A Task Group is characterised by:
- description: Text (mandatory)
- wait_spec: TASK WAIT (see below) that acts as a wait state for the whole group (optional)
- repeat_spec: a TASK_REPEAT object (= range of integers, and possible stopping condition) (optional)
- members: a list of the Plan Items, which can be Tasks, more Task Groups, decision/ condition nodes etc.
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.
...
A Task is a 'doing' object, i.e. represents an item of work. The
Kinds of Task
xxx
xxx. There are different kinds of Task, in two groups - Dispatchable (someone else or something else will do this Task) or Performable (the principal_performer will do the task).
The sub-types are only 5 - 3 kinds of Dispatchable and 2 kinds of Performable Task:
Dispatchable Task
Hand-off
In addition to Dispatchable Task properties, Hand-off has a 'target' reference to another Task Plan in the same Work Plan - one with a different principal performer. Maybe visualise with arrow + icon representing Task Plan? See also Sub-plan below.
External Request
In addition to Dispatchable Task properties, an External Request has some properties representing the external organisastion to be sent a request. The organisation name could potentially be displayed.
System Request
In addition to Dispatchable Task properties, a System Request has a reference to a System Call, which defines a call into another system. Maybe display as some kind of icon representing the idea of a call into a system, include the SYSTEM_CALL.name (i.e. which system)?
Performable Task
All performable Tasks (Sub-plan and Defined Task) have the following items that could be visualised. 'action' is visualised by visualising the concrete subtype, below.
Sub-plan
In addition to Performable Task attributes above, Sub-plan 'target' is a reference to another Task Plan - could be visualised with an arrow and icon for TASK PLAN?
NB: A sub-plan is a more detailed part of the current plan - same principal_performer.
Defined Task
In addition to Performable Task attributes above, the 'prototype' is a reference to one or more existing archetypes; it might be visualised with the standard icon for ENTRY subtypes, i.e. OBSERVATION, EVALUATION etc - as used in ADL-Designer. Clicking that or hover might display the archetype id.
Task Wait
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_NOTIFICATIONorMANUAL_,NOTIFICATIONSYSTEM_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
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 symbolTIMELINE_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.