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.
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
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).
Add the following to CONDITION_GROUP or DECISION_GROUP:
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.
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)
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.
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.
Nested exceptions
Variations are possible to achieve what we want.
WORK_PLAN:
change top_level_plans to ‘normal_path_plans’ : List<TASK_PLAN>
add ‘exception_plans’: List<TEAM_PLAN_GROUP>
add ‘adhoc_plans’: List<EVENT_GROUP>
class TEAM_PLAN_GROUP
description: String
events: List<PLAN_EVENT>
class TP_TEAM_PLAN_GROUP
inherit TEAM_PLAN_GROUP
task_plans: List<TASK_PLAN>
class WP_TEAM_PLAN_GROUP
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
Add some documentation on this. No formal changes needed.
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
Scenarios:
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.
MK:
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
Fabio:
todo list
change name of ADHOC_CHOICE to e.g. FREE_CHOICE; need to reserve ‘ad hoc’ for runtime additions / replacements.
Add facility to generate events or calls on current Task lifecycle transitions.
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.
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.
Use case: in pregnancy care,
Use case:
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.
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
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.
Use statistical analysis of execution history to show common pathways, case-loads for clinics etc.
Add to TASK_COSTING:
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:
Need a visual exit ‘here’ to avoid visually going through all the block close objects.
Visio tabular format for Moscow.