Workshop 26 - 27 June 2017

Participants

Use cases

  • On the fly Task Plan creation
  • Create Task plan for time window e.g. 5 days
  • Add 5 more days

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:

  • descriptive meta-data, including author, etc as for archetypes
  • table of 
    • performer-id, List <TASK_PLAN>

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:

  • Order set = Instructions + Task Plan + ?Plan Group
  • for certain roles (permissions)
  • indications
  • meta-data - keywords, authoring etc
  • can add to catalogue at clinical runtime
  • archetypes + templates

General picture of order sets:

  • one or more Instruction templates
  • one or more Task Plans, including a master / coordinating plan
  • documentation
    • indications etc

Levels of semantic representation

  • National / international care pathway - archetypes / templates
  • ?Region / local variant - (specialised) archetypes / templates
  • patient-specific Task Plan, with adjustments - Definition instances
  • execution time form - RT_ class instances

Service catalog

  • archetypes / templates for all above levels
  • 'instance templates', committed to dedicated non-EHR bucket
    • e.g. institution-specific, ward-specific

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:

  • episode
  • reason for admission / presenting complaint (ED)
  • current consultant
  • care team
  • department
  • ward
  • etc

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'

  • Can be repeated after 15 mins, then every hour as needed - means to have a monitoring task every hour.

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:

  • PROXY_TASK - a kind of LINKED_TASK pointing to another TASK_PLAN in the same Plan Group that is performed by the same performer;
  • HAND_OFF - a kind of LINKED_TASK pointing to another TASK_PLAN in the same Plan Group that is performed by a different performer - this probably needs to be distinguished, because any handoff inevitably involves the notion of waiting (or not), time-outs etc;
  • EXTERNAL_HANDOFF - a kind of TASK that hands off to a TASK_PLAN outside the current Plan Group - i.e. a request to an organisation / party to do something, such as an order, referral, or simple task, like 'check patient nutrition';
  • ACTION_TASK - a kind of DEFINED_TASK that is a 'doing' Task, and would be reported using an ACTION Entry;
  • DATA_CAPTURE_TASK - a kind of DEFINED_TASK that involves obtaining data from / about the subject of care, documented with an OBSERVATION;

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

  • principal_performer should be on Task or Task Group?
  • How to handle context-switching?
  • idea of principal responsible?

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)

  • planned / active / complete / cancelled?

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