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
Add the following to CONDITION_GROUP or DECISION_GROUP:
...
We may need a new kind of Task representing the system generating an EVENT_ACTION.
Exceptions
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.
...
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.
...
The above is shown in the bottom half of the following diagram.
...
Repeat/Until
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.
...
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
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.
...
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.
...
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:
...
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
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:
...
Reminders and Notifications
TP-VML
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
ADL
Default values
Importing/Exporting from other Formalisms
Visio tabular format for Moscow.
...