Task Planning post 1.5.0 issues

Partial Data-set saving

Use case: parts of a complete template are captured in multiple performable Tasks; at some Task, the data-st is technically complete (all sections completed) and can be signed and saved. The need is to identify when (at what Task) the data-set is considered complete, and also to allow saving of partially complete forms.

Model changes proposed

  • CAPTURE_DATASET_SPEC: add optional DATASPEC_COMMIT_GROUP class; with commit_group_id: String[1]; complete_step: Boolean[1]

  • Final save causes change to complete.

  • In RM: allow for template-invalid data with lifecycle state = incomplete - means data set is technically incomplete (i.e. not all mandatory data present).

    • alternative - create a new lifecycle state: partial

  • AQL: incomplete data does not appear in AQL results

Decision Else processing

Currently there is no guarantee of a condition being matched in a CONDITION_GROUP or DECISION_GROUP, so it is not clear what the TP engine should do in this case.

At a minimum, it should be easy to create an ‘else’ path, with no condition attached (logically, condition = True, or in Decision case, it is like an ‘all other values’ branch).

Proposed model/spec changes


  • attribute ‘else_branch’ of type ELSE_BRANCH, a simple descendant type of CHOICE_BRANCH.

MP: other possibility might have been to just use an EVENT_ACTION.

We may need a new kind of Task representing the system generating an EVENT_ACTION.


Use case: the patient state changes such that it is judged that the current routine care will stop and a plan specific to the adverse event / emergency be pursued. E.g., during childbirth, fetal distress is detected; maternal haemorrhage detected.

Various approaches to this appear possible.

Exception Task Plans

The first is the use of exception Task Plan(s) within the same Work Plan. Each such TP would have a wait state on its top-level Task Group, with an event trigger for the particular kind of event, e.g. $fetal_distress.

The following illustrates.


In this approach, we need to work out some details:

  • if an event (e.g. $fetal_distress) occurs, does the system:

    • jump to that Task Plan, execute there, and when done … return? This would be reasonable in many cases, but other cases may mean the original plan is no longer appropriate, e.g. an emergency C-section is needed

      • has to be user selected

    • detect the event, and only propose to the workers to jump to an available TP?

    • something else?

  • an exception TP is for one performer; if we want a team approach, we either have multiple TPs for fetal distress, one for each performer needed (note - may need different team structure, e.g. Obs is called in)

Exception TP sets

The general case is that there is not just one TP for a given exception condition, but one for each role needed to work in the exceptional case. Therefore the above model should be factored somewhat differently.

Exception Work Plans

In many cases, it may make more sense to provide a separate WP for each major exception plan - for one thing, the team structure may be different. However, in this case, we need a way of indicating the connection between the routine normal-path WP and related exception handlers. Conceptually, something like this:


Currently, we don’t have a way to specify the lower condition/action rules.

General issues

Nested exceptions

Proposed Model/Spec Changes

Variations are possible to achieve what we want.


    • change top_level_plans to ‘normal_path_plans’ : List<TASK_PLAN>

    • add ‘exception_plans’: List<TEAM_PLAN_GROUP>

    • add ‘adhoc_plans’: List<EVENT_GROUP>


    • description: String

    • events: List<PLAN_EVENT>


    • inherit TEAM_PLAN_GROUP

    • task_plans: List<TASK_PLAN>


    • inherit TEAM_PLAN_GROUP

    • work_plan: WORK_PLAN

Add documentation on Exception processing.

The above is shown in the bottom half of the following diagram.



Materialise one instance; test condition when execution arrives there

Proposed Model/Spec Changes

Add some documentation on this. No formal changes needed.

Custom Runtime Tasks

A 'custom runtime' adjustment to a Task Plan is understood as any adjustment made to the Plan after it has been instantiated and activated.

Requirement is to be able to record extra Tasks done as if they had been part of the original Plan, at least:

  • description

  • where they appeared in the execution order

  • possibly what data sets viewed / captured

  • time-stamp, user etc


  • add Task(s) to non-materialised part of Plan - e.g. more distant in time

  • add Task(s) to already materialised part of Plan - i.e. current execution window, e.g. current shift / few hours / days etc.

Firstly we need to clarify what artefact we are modifying:

  • persisted instantiated expression of Plan? (i.e. not archetype level)

    • changes will be permanent; instantiated form will be marked as ‘modified’ somehow (need to prevent over-writing?)

    • new Task(s) will show up in execution history

  • only in-memory form?

    • Might make sense for some Plans - probably only makes sense to already materialised segment for very short-term situations?

    • changes will be invisible in persisted instantiated form, but will show up in execution history

We also need to distinguish this need from exception processing, which will occur via conditional alternative Task Plans.

For long-running plans, inserting Task(s) is probably the same as doing the normal TP authoring process with the usual tool, and modifying part of the plan not yet materialised.


  • insert; document each task, know where the insertion was; record any data set used

  • replace: indicate Task(s) used instead of defined task

  • record resources used, etc for cost tracking


  • todo list

Model changes proposed

  • change name of ADHOC_CHOICE to e.g. FREE_CHOICE; need to reserve ‘ad hoc’ for runtime additions / replacements.


Notification generation

Add facility to generate events or calls on current Task lifecycle transitions.

Redo / retry

Use case: Wrong data entered on Task 1, Task 2, 3, … done, then a decision point entered based on the wrong data follows the incorrect path; clinician then realises, and wants to correct the data.

What if wrong data was sent to another system due to a SYSTEM_CALL from an EVENT_ACTION? => need an ‘update’ or ‘correction’ concept.

E.g. patient was recorded as being diabetic, and a decision branch was entered on that basis; in this branch, an HbA1C was ordered and various unnecessary appointments were made.

Possible approaches:

  • return to Task where error was made; rerun, and then go forward, possibly passing through already done intermediate tasks as ‘cancel not needed'.

  • throw away some materialised part of the plan and regenerate fresh; e.g. before decision point whose wrong branch was taken

  • display already done Tasks e.g. that caused orders, appt bookings

Matija P: try to materialise de novo the intermediate piece, keep the dead branch; but rewire from regenerated segment to previously materialised section not yet performed.

Problems of repeat sections - don't want to undo / cancel actions that might still be done on a subsequent repeat.

Orders/appts done in intermediate section - don’t cancel, since the redo will pass through these Tasks again.

Need to be able to at least construct a list of actions performed that user might want to rescind.

User will have best idea of how to compensate for real world actions already performed.

Model changes proposed


Expression Language

The main conceptual challenge is not actually the EL syntax or semantics as such, but where decision conditional expressions are represented (in the TP, outside?) and what constitutes a ‘variable’? E,g, a TP author might invent logical conditions that don’t exist as EHR data items as such., or might not have a clear formal expression relationship to underlying variables.

Secondly, we (probably) want any such conditions to be modifiable independently of the plan.

Mapped Variables


Context Data


Rules and Decision Structures

Pure ECA Rules

Use case: in pregnancy care,

How to represent a simple Yes/no decision point?


TP System Actions resulting from decision

Use case:

Or Branch - all that apply (aka hit policy)


Data Handling

Describe the data capture / retrieve loop in TP


Data Object and Data Store

Need ability to keep persist SYSTEM_CALL results.

Also Q of what types supported by calls.

Data Object = Business Object

Data Store = commit cache to hide partial data.

Writing to the EHR or other System


Cost Tracking

Use case: Prospective cost estimation likely to be attractive; will rely on:

  • Task-level cost data (e.g. from price lists of insurance etc)

  • fine-grained resource use data (related to individual resource use)

  • depends on traversal scenarios

Use case: post hoc accurate resource use report:

  • requires resource adjustments / usage to be updateable at runtime

  • and process mining analysis on Execution history containing this data

Resource service interface

Potentially store service id to enable SYSTEM_CALL to be made that will obtain resource-related costing info for both prospective analysis and post hoc analysis.

Fully instrumented system

Use statistical analysis of execution history to show common pathways, case-loads for clinics etc.

Proposed Model/spec changes


  • system_call: SYSTEM_CALL; // to enable Task classifier to be converted to pricing info via request to Resource service

  • details: ITEM_STRUCTURE; // archetypable cost details

Consider adding fine-grained meta-data as per this model:


Reminders and Notifications



Terminate here

Need a visual exit ‘here’ to avoid visually going through all the block close objects.

Ad hoc group


How to represent data sets and forms


Symbolic refs for hand-offs and sub-plans


Default values

Importing/Exporting from other Formalisms

Visio tabular format for Moscow.