Participants

Use cases

Design Concepts

Plan Group

It would make sense to have a 'plan group' concept for related TASK_PLANs that are designed to execute together, either for a team (multiple performers) or a single performer (multiple component plans) or any combination.

The EXTERNAL_PLAN (rename to LINKED_PLAN) TASK subtype can only link to a Plan known in the Plan Group.

Data for a PLAN GROUP would include:

Can there be a TASK_PLAN with no PLAN_GROUP?

Order Sets

What is an Order Set: a design level concept from a service catalogue, consisting of Instruction archetypes / templates + potentially Task Plan or Plans, if a Team implicated.

Order catalogue concept:

General picture of order sets:

Levels of semantic representation

Service catalog

Tasks and EHR

Need better criteria for whether Task Plan goes into EHR, and where.

Allocation

Need to better describe allocation concept.

Querying

How queries for 'current state' of Task Plan work (also Team Plan).

Patient Care Context

Need a queryable representation of patient care context, including:

It should be possible to reference these facts from with a Task Plan.

Model Questions

Repetition

simple model is preferred - attach only to Task Plan?

at least repetition period; max repetitions (ex. chemo); while condition?

Some kinds of 'tasks'

More Kinds of Tasks needed

Reflection on the Moscow Stroke workflow indicates that we should probably hard-model some of the Task subtypes that are implicated, as shown below.

Here we distinguish some specific types of Tasks:

The names used for these classes could easily be changed, and it is not clear if any / all are needed. To be discussed.

Possible Modifications

Timing

We need to sort out the details of concrete timing better, e.g. days of week, specific fixed times in day (not offsets). Current model is as follows.

Data Currency scenario

A common scenario is that a specific data item, possibly calculated, e.g. BMI, CHADVASC etc, is required for review, and decisions will be made depending on the value. However, if the data item is not sufficiently recent, the appropriate actions need to be performed to obtain the data item, which might be possible in the current encounter, or it might mean new examination, appointment etc. The following diagram shows how this common kind of situation can be represented with the model.

Other

Alternative to single Task Plan 'definition': setup, main, cleanup, all of type TASK_GROUP - would address task plans with that kind of structure, and make repetition clearer.

Training_level - what granularity: better on a per Task level?

Task Plans with timing need to be adjustable for ward-specific timing

Indications - on Task Plan or Task (or both)?

How to specify absolute times on Task Def, e.g. 'Monday, Tuesday, Wednesday'; 13:00, etc?

Should TASK_PARTICIPATION.roles be multiple? Probably yes.

Retry concept; should tasks be marked as 'retryable'?

Preparatory Task - do at -2d before main Task: should be solvable with current model.

Lifecycle

Could a Group be signed off or Cancelled? IHC approach: this is just a UI short cut for signoff or cancellation of all remaining Tasks in the Group

Better idea of rolled-up state of lifecycle state for Task Group (Bjorn)

i.e. add an 'active' state that results if there are any planned or available Tasks remaining in Group.

Use Cases

Related Questions

Task List (Worker Schedule)

Individual worker's Work list or schedule is the result of all current Task Plans that he/she is / can be included on; merged and possibly optimised. 

Task Scheduling - not in scope, but describe the need. Schedule building requires examination of full resources needed for work items.

Patient Schedule (Patient Diary)

Patient's schedule is merge of all Task Plans targetted to the patient, possibly optimised for time and resources.

Other Notes

How to group Instructions from same Order set at runtime

One Instruction can create multiple Task Plans, e.g. draw blood ; send to lab etc