docs/task_planning.html

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 2.0.10">
<meta name="description" content="openEHR Task Planning Specification">
<meta name="keywords" content="workflow, task, planning, EHR, EMR, reference model, openehr">
<title>Task Planning Specification</title>
<link rel="stylesheet" href="https://specifications.openehr.org/styles/openehr.css">
</head>
<body class="book toc2 toc-left">
<div id="header">
<div id="toc" class="toc2">
<div id="toctitle">Table of Contents</div>
<ul class="sectlevel0">
<li><a href="#_task_planning_specification">Task Planning Specification</a>
<ul class="sectlevel1">
<li><a href="#_amendment_record">Amendment Record</a></li>
<li><a href="#_acknowledgements">Acknowledgements</a>
<ul class="sectlevel2">
<li><a href="#_primary_author">Primary Author</a></li>
<li><a href="#_contributors">Contributors</a></li>
<li><a href="#_support">Support</a></li>
<li><a href="#_intellectual_origins">Intellectual Origins</a></li>
<li><a href="#_trademarks">Trademarks</a></li>
</ul>
</li>
<li><a href="#_preface">1. Preface</a>
<ul class="sectlevel2">
<li><a href="#_purpose">1.1. Purpose</a></li>
<li><a href="#_related_documents">1.2. Related Documents</a></li>
<li><a href="#_status">1.3. Status</a></li>
<li><a href="#_feedback">1.4. Feedback</a></li>
<li><a href="#_conformance">1.5. Conformance</a></li>
</ul>
</li>
<li><a href="#_background">2. Background</a>
<ul class="sectlevel2">
<li><a href="#_survey_of_requirements">2.1. Survey of Requirements</a>
<ul class="sectlevel3">
<li><a href="#_how_can_computers_improve_clinical_care_process">2.1.1. How Can Computers Improve Clinical Care Process?</a></li>
<li><a href="#_cognitive_model">2.1.2. Cognitive Model</a>
<ul class="sectlevel4">
<li><a href="#_the_co_pilot_paradigm">2.1.2.1. The Co-pilot Paradigm</a></li>
<li><a href="#_voice_based_hci">2.1.2.2. Voice-based HCI</a></li>
</ul>
</li>
<li><a href="#_care_pathways">2.1.3. Care Pathways</a></li>
<li><a href="#_order_sets">2.1.4. Order Sets</a></li>
<li><a href="#_time_and_work_in_the_real_world">2.1.5. Time and Work in the Real World</a></li>
</ul>
</li>
<li><a href="#_execution_environment">2.2. Execution Environment</a>
<ul class="sectlevel3">
<li><a href="#_general_paradigm">2.2.1. General Paradigm</a></li>
<li><a href="#_distributed_plans">2.2.2. Distributed Plans</a></li>
</ul>
</li>
<li><a href="#_what_task_planning_does_not_do">2.3. What Task Planning Does Not Do</a>
<ul class="sectlevel3">
<li><a href="#_work_plans_versus_task_lists_todo_lists">2.3.1. Work Plans versus Task Lists (TODO Lists)</a></li>
<li><a href="#_appointment_booking_and_management">2.3.2. Appointment Booking and Management</a></li>
</ul>
</li>
<li><a href="#_clinical_decision_support_cds">2.4. Clinical Decision Support (CDS)</a></li>
<li><a href="#_relationship_to_workflow_formalisms_and_systems">2.5. Relationship to Workflow Formalisms and Systems</a></li>
<li><a href="#_limitations_of_the_openehr_standard_entry_model">2.6. Limitations of the openEHR standard Entry Model</a></li>
</ul>
</li>
<li><a href="#_technical_requirements">3. Technical Requirements</a>
<ul class="sectlevel2">
<li><a href="#_flexible_allocation_of_workers">3.1. Flexible Allocation of Workers</a></li>
<li><a href="#_coordinated_teamwork">3.2. Coordinated Teamwork</a></li>
<li><a href="#_planned_tasks_for_an_order">3.3. Planned Tasks for an Order</a></li>
<li><a href="#_tracking_orders_from_plans">3.4. Tracking Orders from Plans</a></li>
<li><a href="#_order_sets_and_protocols">3.5. Order Sets and Protocols</a></li>
<li><a href="#_lookahead_plan">3.6. Lookahead Plan</a></li>
<li><a href="#_recurring_repeatable_tasks">3.7. Recurring / Repeatable Tasks</a></li>
<li><a href="#_checklist_sign_off">3.8. Checklist &amp; Sign-off</a></li>
<li><a href="#_sub_plans">3.9. Sub-plans</a></li>
<li><a href="#_task_grouping_optionality_and_execution_basis">3.10. Task Grouping, Optionality and Execution Basis</a></li>
<li><a href="#_decision_pathways">3.11. Decision Pathways</a></li>
<li><a href="#_different_types_of_cancellation">3.12. Different types of Cancellation</a></li>
<li><a href="#_changes_and_abandonment">3.13. Changes and Abandonment</a></li>
<li><a href="#_rationalising_unrelated_work_plans">3.14. Rationalising Unrelated Work Plans</a></li>
<li><a href="#_support_process_analytics">3.15. Support Process Analytics</a></li>
<li><a href="#_support_for_costing_and_billing_information">3.16. Support for Costing and Billing Information</a></li>
</ul>
</li>
<li><a href="#_design_principles">4. Design Principles</a>
<ul class="sectlevel2">
<li><a href="#_computational_basis">4.1. Computational Basis</a></li>
<li><a href="#_computation_context">4.2. Computation Context</a>
<ul class="sectlevel3">
<li><a href="#_separation_of_definition_and_execution">4.2.1. Separation of Definition and Execution</a></li>
</ul>
</li>
<li><a href="#_conceptual_elements">4.3. Conceptual Elements</a>
<ul class="sectlevel3">
<li><a href="#_work_plan">4.3.1. Work Plan</a></li>
<li><a href="#_task_plan">4.3.2. Task Plan</a>
<ul class="sectlevel4">
<li><a href="#_parallel_and_sequential_execution">4.3.2.1. Parallel and Sequential Execution</a></li>
<li><a href="#_conditional_structures">4.3.2.2. Conditional Structures</a></li>
<li><a href="#_summary">4.3.2.3. Summary</a></li>
</ul>
</li>
<li><a href="#_graph_structure">4.3.3. Graph Structure</a></li>
<li><a href="#_work_context">4.3.4. Work Context</a></li>
<li><a href="#_context_switch_and_fork">4.3.5. Context Switch and Fork</a></li>
<li><a href="#_context_continuity_over_worker_shifts">4.3.6. Context Continuity over Worker Shifts</a></li>
<li><a href="#_principal_performer">4.3.7. Principal Performer</a></li>
<li><a href="#_time_and_wait_states">4.3.8. Time and Wait States</a></li>
</ul>
</li>
<li><a href="#_levels_of_definition_and_representation">4.4. Levels of Definition and Representation</a>
<ul class="sectlevel3">
<li><a href="#_phases_of_work">4.4.1. Phases of Work</a></li>
</ul>
</li>
<li><a href="#_execution_concepts">4.5. Execution Concepts</a>
<ul class="sectlevel3">
<li><a href="#_plan_execution_lifecycle">4.5.1. Plan Execution Lifecycle</a></li>
<li><a href="#_allocation">4.5.2. Allocation</a></li>
<li><a href="#_task_lifecycle">4.5.3. Task Lifecycle</a></li>
<li><a href="#_availability">4.5.4. Availability</a></li>
<li><a href="#_adaptive_modification_and_exception_handling">4.5.5. Adaptive Modification and Exception-handling</a></li>
</ul>
</li>
<li><a href="#_relationship_of_tasks_with_existing_openehr_entry_types">4.6. Relationship of Tasks with existing openEHR Entry Types</a></li>
<li><a href="#_order_semantics_versus_plan_semantics">4.7. Order Semantics versus Plan Semantics</a></li>
</ul>
</li>
<li><a href="#_task_planning_model_overview">5. Task Planning Model Overview</a>
<ul class="sectlevel2">
<li><a href="#_identification_and_referencing">5.1. Identification and Referencing</a></li>
<li><a href="#_plan_data_context">5.2. Plan Data Context</a>
<ul class="sectlevel3">
<li><a href="#_class_descriptions">5.2.1. Class Descriptions</a>
<ul class="sectlevel4">
<li><a href="#_plan_data_context_class">5.2.1.1. PLAN_DATA_CONTEXT Class</a></li>
<li><a href="#_context_valuet_class">5.2.1.2. CONTEXT_VALUE&lt;T&gt; Class</a></li>
<li><a href="#_context_constanttt_class">5.2.1.3. CONTEXT_CONSTANT&lt;TT&gt; Class</a></li>
<li><a href="#_context_variablett_class">5.2.1.4. CONTEXT_VARIABLE&lt;TT&gt; Class</a></li>
<li><a href="#_external_variablett_class">5.2.1.5. EXTERNAL_VARIABLE&lt;TT&gt; Class</a></li>
<li><a href="#_local_variablett_class">5.2.1.6. LOCAL_VARIABLE&lt;TT&gt; Class</a></li>
<li><a href="#_event_variablett_class">5.2.1.7. EVENT_VARIABLE&lt;TT&gt; Class</a></li>
<li><a href="#_continuous_event_variablett_class">5.2.1.8. CONTINUOUS_EVENT_VARIABLE&lt;TT&gt; Class</a></li>
<li><a href="#_state_variablett_class">5.2.1.9. STATE_VARIABLE&lt;TT&gt; Class</a></li>
<li><a href="#_context_expressiontt_class">5.2.1.10. CONTEXT_EXPRESSION&lt;TT&gt; Class</a></li>
<li><a href="#_boolean_context_expression_class">5.2.1.11. BOOLEAN_CONTEXT_EXPRESSION Class</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#_system_calls">5.3. System Calls</a>
<ul class="sectlevel3">
<li><a href="#_generic_api_calls">5.3.1. Generic API calls</a></li>
<li><a href="#_query_calls">5.3.2. Query Calls</a></li>
<li><a href="#_class_descriptions_2">5.3.3. Class Descriptions</a>
<ul class="sectlevel4">
<li><a href="#_system_call_class">5.3.3.1. SYSTEM_CALL Class</a></li>
<li><a href="#_parameter_def_class">5.3.3.2. PARAMETER_DEF Class</a></li>
<li><a href="#_parameter_mapping_class">5.3.3.3. PARAMETER_MAPPING Class</a></li>
<li><a href="#_api_call_class">5.3.3.4. API_CALL Class</a></li>
<li><a href="#_query_call_class">5.3.3.5. QUERY_CALL Class</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#_variable_referencing">5.4. Variable Referencing</a></li>
<li><a href="#_specifying_time">5.5. Specifying Time</a>
<ul class="sectlevel3">
<li><a href="#_class_descriptions_3">5.5.1. Class Descriptions</a>
<ul class="sectlevel4">
<li><a href="#_time_specifier_class">5.5.1.1. TIME_SPECIFIER Class</a></li>
<li><a href="#_clock_time_class">5.5.1.2. CLOCK_TIME Class</a></li>
<li><a href="#_customary_time_class">5.5.1.3. CUSTOMARY_TIME Class</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#_enumerated_types">5.6. Enumerated Types</a>
<ul class="sectlevel3">
<li><a href="#_class_descriptions_4">5.6.1. Class Descriptions</a>
<ul class="sectlevel4">
<li><a href="#_task_lifecycle_enumeration">5.6.1.1. TASK_LIFECYCLE Enumeration</a></li>
<li><a href="#_resume_type_enumeration">5.6.1.2. RESUME_TYPE Enumeration</a></li>
<li><a href="#_temporal_relation_enumeration">5.6.1.3. TEMPORAL_RELATION Enumeration</a></li>
<li><a href="#_execution_type_enumeration">5.6.1.4. EXECUTION_TYPE Enumeration</a></li>
<li><a href="#_plan_time_origin_enumeration">5.6.1.5. PLAN_TIME_ORIGIN Enumeration</a></li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li><a href="#_definition_model">6. Definition Model</a>
<ul class="sectlevel2">
<li><a href="#_overview">6.1. Overview</a></li>
<li><a href="#_plan_structure">6.2. Plan Structure</a>
<ul class="sectlevel3">
<li><a href="#_the_plan_calendar">6.2.1. The Plan Calendar</a></li>
<li><a href="#_plan_items">6.2.2. Plan Items</a>
<ul class="sectlevel4">
<li><a href="#_wait_states">6.2.2.1. Wait States</a></li>
<li><a href="#_repetition">6.2.2.2. Repetition</a></li>
<li><a href="#_other_attributes">6.2.2.3. Other Attributes</a></li>
</ul>
</li>
<li><a href="#_lifecycle_state">6.2.3. Lifecycle State</a>
<ul class="sectlevel4">
<li><a href="#_task_availability">6.2.3.1. Task Availability</a></li>
<li><a href="#_aggregate_process_state">6.2.3.2. Aggregate Process State</a></li>
</ul>
</li>
<li><a href="#_references_to_clinical_quality_artefacts">6.2.4. References to Clinical Quality Artefacts</a></li>
<li><a href="#_class_definitions">6.2.5. Class Definitions</a>
<ul class="sectlevel4">
<li><a href="#_work_plan_class">6.2.5.1. WORK_PLAN Class</a></li>
<li><a href="#_plan_calendar_class">6.2.5.2. PLAN_CALENDAR Class</a></li>
<li><a href="#_plan_timeline_class">6.2.5.3. PLAN_TIMELINE Class</a></li>
<li><a href="#_calendar_entry_class">6.2.5.4. CALENDAR_ENTRY Class</a></li>
<li><a href="#_task_plan_class">6.2.5.5. TASK_PLAN Class</a></li>
<li><a href="#_task_participation_class">6.2.5.6. TASK_PARTICIPATION Class</a></li>
<li><a href="#_plan_item_class">6.2.5.7. PLAN_ITEM Class</a></li>
<li><a href="#_task_repeat_class">6.2.5.8. TASK_REPEAT Class</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#_task_group_structure">6.3. Task Group Structure</a>
<ul class="sectlevel3">
<li><a href="#_sequential_task_groups">6.3.1. Sequential Task Groups</a></li>
<li><a href="#_parallel_task_groups_and_concurrency">6.3.2. Parallel Task Groups and Concurrency</a></li>
<li><a href="#_hierarchical_nesting">6.3.3. Hierarchical Nesting</a></li>
<li><a href="#_generic_execution_time_semantics">6.3.4. Generic Execution-time Semantics</a></li>
<li><a href="#_well_formedness">6.3.5. Well-formedness</a></li>
<li><a href="#_training_level">6.3.6. Training Level</a></li>
<li><a href="#_class_definitions_2">6.3.7. Class Definitions</a>
<ul class="sectlevel4">
<li><a href="#_task_group_class">6.3.7.1. TASK_GROUP Class</a></li>
<li><a href="#_execution_type_enumeration_2">6.3.7.2. EXECUTION_TYPE Enumeration</a></li>
<li><a href="#_concurrency_mode_enumeration">6.3.7.3. CONCURRENCY_MODE Enumeration</a></li>
<li><a href="#_execution_rule_class">6.3.7.4. EXECUTION_RULE Class</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#_general_task_semantics">6.4. General Task Semantics</a>
<ul class="sectlevel3">
<li><a href="#_dispatchable_and_performable_tasks">6.4.1. Dispatchable and Performable Tasks</a></li>
<li><a href="#_class_definitions_3">6.4.2. Class Definitions</a>
<ul class="sectlevel4">
<li><a href="#_taskta_class">6.4.2.1. TASK&lt;TA&gt; Class</a></li>
<li><a href="#_dispatchable_taskta_class">6.4.2.2. DISPATCHABLE_TASK&lt;TA&gt; Class</a></li>
<li><a href="#_performable_taskta_class">6.4.2.3. PERFORMABLE_TASK&lt;TA&gt; Class</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#_task_actions">6.5. Task Actions</a>
<ul class="sectlevel3">
<li><a href="#_performable_actions">6.5.1. Performable Actions</a>
<ul class="sectlevel4">
<li><a href="#_sub_plans_and_re_use">6.5.1.1. Sub-plans and Re-use</a></li>
<li><a href="#_inline_defined_actions">6.5.1.2. Inline Defined Actions</a></li>
</ul>
</li>
<li><a href="#_dispatchable_actions">6.5.2. Dispatchable Actions</a>
<ul class="sectlevel4">
<li><a href="#_hand_offs_and_coordinated_teamwork">6.5.2.1. Hand-offs and Coordinated Teamwork</a></li>
<li><a href="#_external_request">6.5.2.2. External Request</a></li>
<li><a href="#_system_request">6.5.2.3. System Request</a></li>
</ul>
</li>
<li><a href="#_class_definitions_4">6.5.3. Class Definitions</a>
<ul class="sectlevel4">
<li><a href="#_task_action_class">6.5.3.1. TASK_ACTION Class</a></li>
<li><a href="#_subject_precondition_class">6.5.3.2. SUBJECT_PRECONDITION Class</a></li>
<li><a href="#_performable_action_class">6.5.3.3. PERFORMABLE_ACTION Class</a></li>
<li><a href="#_resource_participation_class">6.5.3.4. RESOURCE_PARTICIPATION Class</a></li>
<li><a href="#_defined_action_class">6.5.3.5. DEFINED_ACTION Class</a></li>
<li><a href="#_sub_plan_class">6.5.3.6. SUB_PLAN Class</a></li>
<li><a href="#_dispatchable_action_class">6.5.3.7. DISPATCHABLE_ACTION Class</a></li>
<li><a href="#_hand_off_class">6.5.3.8. HAND_OFF Class</a></li>
<li><a href="#_external_request_class">6.5.3.9. EXTERNAL_REQUEST Class</a></li>
<li><a href="#_system_request_class">6.5.3.10. SYSTEM_REQUEST Class</a></li>
<li><a href="#_linked_plan_class">6.5.3.11. LINKED_PLAN Class</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#_data_sets_and_application_interaction">6.6. Data-sets and Application Interaction</a>
<ul class="sectlevel3">
<li><a href="#_class_definitions_5">6.6.1. Class Definitions</a>
<ul class="sectlevel4">
<li><a href="#_dataset_spec_class">6.6.1.1. DATASET_SPEC Class</a></li>
<li><a href="#_capture_dataset_spec_class">6.6.1.2. CAPTURE_DATASET_SPEC Class</a></li>
<li><a href="#_review_dataset_spec_class">6.6.1.3. REVIEW_DATASET_SPEC Class</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#_decision_structures">6.7. Decision Structures</a>
<ul class="sectlevel3">
<li><a href="#_overview_2">6.7.1. Overview</a></li>
<li><a href="#_condition_group_ifelseifelse">6.7.2. Condition Group (if/elseif/else)</a></li>
<li><a href="#_decision_group_switch">6.7.3. Decision Group (switch)</a></li>
<li><a href="#_event_group">6.7.4. Event Group</a></li>
<li><a href="#_class_definitions_6">6.7.5. Class Definitions</a>
<ul class="sectlevel4">
<li><a href="#_choice_group_class">6.7.5.1. CHOICE_GROUP Class</a></li>
<li><a href="#_override_type_enumeration">6.7.5.2. OVERRIDE_TYPE Enumeration</a></li>
<li><a href="#_choice_branch_class">6.7.5.3. CHOICE_BRANCH Class</a></li>
<li><a href="#_condition_group_class">6.7.5.4. CONDITION_GROUP Class</a></li>
<li><a href="#_condition_branch_class">6.7.5.5. CONDITION_BRANCH Class</a></li>
<li><a href="#_decision_group_class">6.7.5.6. DECISION_GROUP Class</a></li>
<li><a href="#_decision_branch_class">6.7.5.7. DECISION_BRANCH Class</a></li>
<li><a href="#_adhoc_group_class">6.7.5.8. ADHOC_GROUP Class</a></li>
<li><a href="#_adhoc_branch_class">6.7.5.9. ADHOC_BRANCH Class</a></li>
<li><a href="#_event_group_class">6.7.5.10. EVENT_GROUP Class</a></li>
<li><a href="#_event_branch_class">6.7.5.11. EVENT_BRANCH Class</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#_order_tracking">6.8. Order Tracking</a>
<ul class="sectlevel3">
<li><a href="#_tracking_an_existing_order">6.8.1. Tracking an Existing Order</a></li>
<li><a href="#_creating_and_tracking_an_order">6.8.2. Creating and Tracking an Order</a></li>
<li><a href="#_class_definitions_7">6.8.3. Class Definitions</a>
<ul class="sectlevel4">
<li><a href="#_order_ref_class">6.8.3.1. ORDER_REF Class</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#_events">6.9. Events</a>
<ul class="sectlevel3">
<li><a href="#_overview_3">6.9.1. Overview</a></li>
<li><a href="#_event_types">6.9.2. Event Types</a>
<ul class="sectlevel4">
<li><a href="#_timeline_moment">6.9.2.1. TIMELINE_MOMENT</a></li>
</ul>
</li>
<li><a href="#_general_facilities">6.9.3. General Facilities</a>
<ul class="sectlevel4">
<li><a href="#_event_wait_state">6.9.3.1. Event Wait State</a></li>
<li><a href="#_timers">6.9.3.2. Timers</a></li>
<li><a href="#_reminder">6.9.3.3. Reminder</a></li>
</ul>
</li>
<li><a href="#_task_wait_state">6.9.4. Task Wait State</a>
<ul class="sectlevel4">
<li><a href="#_time_outs">6.9.4.1. Time-outs</a></li>
<li><a href="#_reminder_2">6.9.4.2. Reminder</a></li>
<li><a href="#_lifecycle_transition_override">6.9.4.3. Lifecycle Transition Override</a></li>
</ul>
</li>
<li><a href="#_callbacks">6.9.5. Callbacks</a>
<ul class="sectlevel4">
<li><a href="#_callback_processing_for_blocking_tasks">6.9.5.1. Callback Processing for Blocking Tasks</a></li>
<li><a href="#_callback_processing_for_non_blocking_tasks">6.9.5.2. Callback Processing for Non-blocking Tasks</a></li>
<li><a href="#_callback_with_custom_resume_behaviour">6.9.5.3. Callback with Custom Resume Behaviour</a></li>
<li><a href="#_manually_notified_pseudo_callback">6.9.5.4. Manually-notified Pseudo-callback</a></li>
</ul>
</li>
<li><a href="#_class_definitions_8">6.9.6. Class Definitions</a>
<ul class="sectlevel4">
<li><a href="#_task_wait_class">6.9.6.1. TASK_WAIT Class</a></li>
<li><a href="#_event_waitp_class">6.9.6.2. EVENT_WAIT&lt;P&gt; Class</a></li>
<li><a href="#_timer_wait_class">6.9.6.3. TIMER_WAIT Class</a></li>
<li><a href="#_reminder_class">6.9.6.4. REMINDER Class</a></li>
<li><a href="#_callback_wait_class">6.9.6.5. CALLBACK_WAIT Class</a></li>
<li><a href="#_event_action_class">6.9.6.6. EVENT_ACTION Class</a></li>
<li><a href="#_resume_action_class">6.9.6.7. RESUME_ACTION Class</a></li>
<li><a href="#_plan_event_class">6.9.6.8. PLAN_EVENT&lt;&gt; Class</a></li>
<li><a href="#_timer_event_class">6.9.6.9. TIMER_EVENT Class</a></li>
<li><a href="#_calendar_event_class">6.9.6.10. CALENDAR_EVENT Class</a></li>
<li><a href="#_timeline_moment_class">6.9.6.11. TIMELINE_MOMENT Class</a></li>
<li><a href="#_task_transition_class">6.9.6.12. TASK_TRANSITION Class</a></li>
<li><a href="#_manual_notification_class">6.9.6.13. MANUAL_NOTIFICATION Class</a></li>
<li><a href="#_system_notification_class">6.9.6.14. SYSTEM_NOTIFICATION Class</a></li>
<li><a href="#_callback_notification_class">6.9.6.15. CALLBACK_NOTIFICATION Class</a></li>
<li><a href="#_state_trigger_class">6.9.6.16. STATE_TRIGGER Class</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#_cost_tracking">6.10. Cost Tracking</a>
<ul class="sectlevel3">
<li><a href="#_class_definitions_9">6.10.1. Class Definitions</a>
<ul class="sectlevel4">
<li><a href="#_task_costing_class">6.10.1.1. TASK_COSTING Class</a></li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li><a href="#_global_semantics">7. Global Semantics</a>
<ul class="sectlevel2">
<li><a href="#_control_flow">7.1. Control Flow</a>
<ul class="sectlevel3">
<li><a href="#_graph_structure_2">7.1.1. Graph Structure</a></li>
<li><a href="#_general_scheme">7.1.2. General Scheme</a></li>
<li><a href="#_conditional_nodes">7.1.3. Conditional Nodes</a></li>
</ul>
</li>
<li><a href="#_task_dispatching">7.2. Task Dispatching</a>
<ul class="sectlevel3">
<li><a href="#_hand_offs">7.2.1. Hand-offs</a></li>
<li><a href="#_external_requests">7.2.2. External Requests</a></li>
<li><a href="#_system_requests">7.2.3. System Requests</a></li>
<li><a href="#_resume_semantics">7.2.4. Resume Semantics</a></li>
</ul>
</li>
<li><a href="#_aggregate_lifecycle_state">7.3. Aggregate Lifecycle State</a>
<ul class="sectlevel3">
<li><a href="#_sequential_groups">7.3.1. Sequential Groups</a></li>
<li><a href="#_parallel_groups">7.3.2. Parallel Groups</a></li>
<li><a href="#_work_plan_2">7.3.3. Work Plan</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#_execution">8. Execution</a>
<ul class="sectlevel2">
<li><a href="#_phases_of_processing">8.1. Phases of Processing</a>
<ul class="sectlevel3">
<li><a href="#_materialisation">8.1.1. Materialisation</a></li>
<li><a href="#_activation">8.1.2. Activation</a></li>
<li><a href="#_termination">8.1.3. Termination</a></li>
<li><a href="#_allowed_plan_modifications">8.1.4. Allowed Plan Modifications</a></li>
</ul>
</li>
<li><a href="#_execution_processing">8.2. Execution Processing</a>
<ul class="sectlevel3">
<li><a href="#_worker_allocation">8.2.1. Worker Allocation</a></li>
<li><a href="#_worker_de_allocation">8.2.2. Worker De-allocation</a></li>
<li><a href="#_resource_allocation">8.2.3. Resource Allocation</a></li>
</ul>
</li>
<li><a href="#_persistence">8.3. Persistence</a></li>
</ul>
</li>
<li><a href="#_materialised_model">9. Materialised Model</a>
<ul class="sectlevel2">
<li><a href="#_overview_4">9.1. Overview</a></li>
<li><a href="#_class_descriptions_5">9.2. Class Descriptions</a>
<ul class="sectlevel3">
<li><a href="#_m_work_plan_class">9.2.1. M_WORK_PLAN Class</a></li>
<li><a href="#_m_task_plan_class">9.2.2. M_TASK_PLAN Class</a></li>
<li><a href="#_m_performer_allocation_class">9.2.3. M_PERFORMER_ALLOCATION Class</a></li>
<li><a href="#_m_plan_item_class">9.2.4. M_PLAN_ITEM Class</a></li>
<li><a href="#_m_task_group_class">9.2.5. M_TASK_GROUP Class</a></li>
<li><a href="#_m_task_class">9.2.6. M_TASK Class</a></li>
<li><a href="#_m_task_action_class">9.2.7. M_TASK_ACTION Class</a></li>
<li><a href="#_m_dispatchable_action_class">9.2.8. M_DISPATCHABLE_ACTION Class</a></li>
<li><a href="#_m_performable_action_class">9.2.9. M_PERFORMABLE_ACTION Class</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#_plan_execution_history">10. Plan Execution History</a>
<ul class="sectlevel2">
<li><a href="#_overview_5">10.1. Overview</a></li>
<li><a href="#_class_descriptions_6">10.2. Class Descriptions</a>
<ul class="sectlevel3">
<li><a href="#_task_plan_execution_history_class">10.2.1. TASK_PLAN_EXECUTION_HISTORY Class</a></li>
<li><a href="#_event_record_class">10.2.2. EVENT_RECORD Class</a></li>
<li><a href="#_task_plan_event_record_class">10.2.3. TASK_PLAN_EVENT_RECORD Class</a></li>
<li><a href="#_task_event_record_class">10.2.4. TASK_EVENT_RECORD Class</a></li>
<li><a href="#_task_notification_record_class">10.2.5. TASK_NOTIFICATION_RECORD Class</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#_transactional_service_model">11. Transactional Service Model</a>
<ul class="sectlevel2">
<li><a href="#_overview_6">11.1. Overview</a></li>
<li><a href="#_definition_interface">11.2. Definition Interface</a></li>
<li><a href="#_execution_time_interface">11.3. Execution-time Interface</a></li>
<li><a href="#_class_descriptions_7">11.4. Class Descriptions</a>
<ul class="sectlevel3">
<li><a href="#_i_work_plan_definition_interface">11.4.1. I_WORK_PLAN_DEFINITION Interface</a></li>
<li><a href="#_i_task_plan_materialised_interface">11.4.2. I_TASK_PLAN_MATERIALISED Interface</a></li>
<li><a href="#_i_work_plan_definition_interface_2">11.4.3. I_WORK_PLAN_DEFINITION Interface</a></li>
<li><a href="#_i_task_plan_materialised_interface_2">11.4.4. I_TASK_PLAN_MATERIALISED Interface</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#_relationship_with_other_openehr_ehr_artefacts">12. Relationship with other openEHR EHR Artefacts</a>
<ul class="sectlevel2">
<li><a href="#_overview_7">12.1. Overview</a></li>
<li><a href="#_execution_time_ehr_structures">12.2. Execution-time EHR Structures</a></li>
</ul>
</li>
<li><a href="#_references">References</a></li>
</ul>
</li>
</ul>
</div>
</div>
<div id="content">
<div id="preamble">
<div class="sectionbody">
<div class="imageblock text-center">
<div class="content">
<img src="https://specifications.openehr.org/images/openEHR_logo_RGB.svg" alt="openEHR logo">
</div>
</div>
</div>
</div>
<h1 id="_task_planning_specification" class="sect0"><a class="anchor" href="#_task_planning_specification"></a>Task Planning Specification</h1>
<div class="openblock partintro">
<div class="content">
<table class="tableblock frame-all grid-all fit-content spread">
<colgroup>
<col>
<col>
</colgroup>
<thead>
<tr>
<th class="tableblock halign-center valign-top" colspan="2"><strong>Issuer</strong>: <a href="https://www.openehr.org/programs/specification" target="_blank" rel="noopener">openEHR Specification Program</a></th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Release</strong>: PROC Release-1.5.0</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Status</strong>: TRIAL</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Revision</strong>: <a href="#latest_issue">[latest_issue]</a></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Date</strong>: <a href="#latest_issue_date">[latest_issue_date]</a></p></td>
</tr>
<tr>
<td class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>Keywords</strong>: workflow, task, planning, EHR, EMR, reference model, openehr</p></td>
</tr>
</tbody>
</table>
<div class="imageblock text-center">
<div class="content">
<object type="image/svg+xml" data="openehr_block_diagram.svg" width="60%"><span class="alt">openEHR components</span></object>
</div>
</div>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 20%;">
<col style="width: 80%;">
</colgroup>
<thead>
<tr>
<th class="tableblock halign-center valign-top" colspan="2">&#169; 2017 - 2020 The openEHR Foundation</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><a href="https://www.openehr.org" target="_blank" rel="noopener">The openEHR Foundation</a> is an independent, non-profit foundation, facilitating the sharing of health records by consumers and clinicians via open specifications, clinical models and open platform implementations.</p></td>
</tr>
<tr>
<td class="tableblock halign-center valign-top"><p class="tableblock"><strong>Licence</strong></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="image"><img src="https://specifications.openehr.org/images/cc-by-nd-88x31.png" alt="image"></span> Creative Commons Attribution-NoDerivs 3.0 Unported. <a href="https://creativecommons.org/licenses/by-nd/3.0/" class="bare">https://creativecommons.org/licenses/by-nd/3.0/</a></p></td>
</tr>
<tr>
<td class="tableblock halign-center valign-top"><p class="tableblock"><strong>Support</strong></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Issues: <a href="https://specifications.openehr.org/components/PROC/open_issues" target="_blank" rel="noopener">Problem Reports</a><br>
 Web: <a href="https://specifications.openehr.org" target="_blank" rel="noopener">specifications.openEHR.org</a></p></td>
</tr>
</tbody>
</table>
</div>
</div>
<div class="sect1">
<h2 id="_amendment_record"><a class="anchor" href="#_amendment_record"></a>Amendment Record</h2>
<div class="sectionbody">
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 9.0909%;">
<col style="width: 54.5454%;">
<col style="width: 18.1818%;">
<col style="width: 18.1819%;">
</colgroup>
<thead>
<tr>
<th class="tableblock halign-left valign-top">Issue</th>
<th class="tableblock halign-left valign-top">Details</th>
<th class="tableblock halign-left valign-top">Raiser</th>
<th class="tableblock halign-left valign-top">Completed</th>
</tr>
</thead>
<tbody>
<tr>
<th class="tableblock halign-center valign-top" colspan="4"><p class="tableblock"><strong>PROC Release 1.5.0</strong></p></th>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a id="latest_issue"></a>1.5.0</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-34" target="_blank" rel="noopener">SPECPROC-34</a>. Clarify evaluate order and semantics of <code>REPEAT_SPEC</code>.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">M Polajnar,<br>
 T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a id="latest_issue_date"></a>05 May 2020</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-22" target="_blank" rel="noopener">SPECPROC-22</a>. Change method of 'manual notification' for callbacks; remove <code><em>manually_notified</em>: Boolean</code> from <code>CALLBACK_NOTIFICATION</code>.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">M Polajnar,<br>
 T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">16 Apr 2020</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-12" target="_blank" rel="noopener">SPECPROC-12</a>. Define lifecycle state for parallel Task Groups, including decision groups. Moved lifecycle state to 6.2.3; update 6.3.2; update Aggregate Lifecycle State section (7.3).</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">B Naess,<br>
 M Polajnar,<br>
 T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">19 Mar 2020</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-32" target="_blank" rel="noopener">SPECPROC-32</a>. Improve Introduction and Requirements Discussion.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">D Santos Alves,<br>
 T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">26 Jan 2020</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-30" target="_blank" rel="noopener">SPECPROC-30</a>. Adjustments to Events model.<br>
 change <code>TASK_WAIT.<em>start_window</em>: REMINDER[0..1]</code> to <code>PLAN_ITEM.<em>reminders</em>: REMINDER[*]</code>;<br>
 add invariant to <code>TIMER_WAIT</code> to prevent it having a timeout;<br>
 make <code>REMINDER</code> a generic <code>EVENT_WAIT</code> to allow it to be fired by any event, not just a timer event;<br>
 remove <code>DELAY_EVENT</code>; move its <code><em>delay</em></code> attribute to <code>PLAN_EVENT</code>,<br>
 <a href="https://specifications.openehr.org/tickets/SPECPROC-31" target="_blank" rel="noopener">SPECPROC-31</a>. Simplifications to Conditional structures: remove <code>BLOCKING_GROUP</code>, <code>BLOCKING_BRANCH</code>.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">M Polajnar,<br>
 T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">03 Jan 2020</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">1.4.2</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPUB-7" target="_blank" rel="noopener">SPECPUB-7</a>: Convert citations to bibtex form.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">15 Dec 2019</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-28" target="_blank" rel="noopener">SPECPROC-28</a>. Improve definition of <code>TIMELINE_MOMENT</code> and <code>TIMER_EVENT</code>; add <code>PLAN_TIME_ORIGIN</code> enum; remove <code>CALENDAR_TIME</code> class.
 <a href="https://specifications.openehr.org/tickets/SPECPROC-29" target="_blank" rel="noopener">SPECPROC-29</a>. Add <code><em>guideline_step</em></code> to <code>PLAN_ITEM</code>; make Work Plan and Task Plan guideline refs more flexible.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">M Kejžar,<br>
 T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">09 Aug 2019</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">1.4.1</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-26" target="_blank" rel="noopener">SPECPROC-26</a>. Dataset improvements: make <code>DATASET_SPEC</code> inherit from <code>LOCATABLE</code>; support form sub-sections.
 <a href="https://specifications.openehr.org/tickets/SPECPROC-27" target="_blank" rel="noopener">SPECPROC-27</a>. Add <code><em>classification</em></code> attribute to <code>WORK_PLAN</code> and <code>PLAN_ITEM</code>.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">M Kejžar,<br>
 T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">22 Jul 2019</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">1.4.0</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-24" target="_blank" rel="noopener">SPECPROC-24</a>. Add Order tracking to model: add class <code>ORDER_REF</code>; add <code>WORK_PLAN.<em>order_list</em></code>; add <code>TASK_PLAN.<em>order_tags</em></code>.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">M Kejžar,<br>
 M Polajnar,<br>
 T Beale,<br>
 B Naess</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">29 May 2019</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">1.3.0</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-22" target="_blank" rel="noopener">SPECPROC-22</a>. Enable Callbacks to be manually notified - add <code><em>manually_notified</em>: Boolean</code> to <code>CALLBACK_NOTIFICATION</code>.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">01 May 2019</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-23" target="_blank" rel="noopener">SPECPROC-23</a>. Correct <code>CLOCK_TIME.<em>time</em></code> type to <code>Iso8601_time</code>.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">B Fabjan</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">25 Apr 2019</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-20" target="_blank" rel="noopener">SPECPROC-20</a>. Add <code><em>period</em></code> to <code>TASK_REPEAT</code> class.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">M Kejžar,<br>
 T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">12 Apr 2019</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-19" target="_blank" rel="noopener">SPECPROC-19</a>. Refine model of concurrency in <code>TASK_GROUP</code>: add class <code>CONCURRENCY_MODE</code>; improve explanation of <code>TASK_GROUP</code>;<br>
 Add <code><em>concurrency_mode</em> = xor_one_path</code> invariant to <code>CHOICE_GROUP</code>.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">18 Mar 2019</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-18" target="_blank" rel="noopener">SPECPROC-18</a>. Support custom actions for callback receipt of events;<br>
 Improve diagrams and explanation on Task wait states and Events;<br>
 Add <code>CALLBACK_WAIT.<em>custom_actions</em></code>;<br>
 Add <code>REMINDER.<em>repeats</em></code>;<br>
 Add <code>TASK_WAIT.<em>next_state</em></code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">T Beale,<br>
 B Naess</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">11 Mar 2019</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-17" target="_blank" rel="noopener">SPECPROC-17</a>. Specialise <code>DATASET_SPEC</code> into Capture and Review forms.<br>
 <a href="https://specifications.openehr.org/tickets/SPECPROC-16" target="_blank" rel="noopener">SPECPROC-16</a>. Change <code>WORK_PLAN.<em>top_level_plans</em></code> and <code>LINKED_PLAN.<em>target</em></code> to direct links.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">M Kejžar,<br>
 B Naess,<br>
 T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">04 Jan 2019</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">1.2.0</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-15" target="_blank" rel="noopener">SPECPROC-15</a>. Convert <code>DELAY_EVENT.<em>source</em></code> to a direct reference.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">M Polajnar</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">21 Nov 2018</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">1.1.2</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-2" target="_blank" rel="noopener">SPECPROC-2</a>. Change date/time types to <code>Iso8601_xxx</code> types from Foundation Types spec.<br>
 <a href="https://specifications.openehr.org/tickets/SPECPROC-11" target="_blank" rel="noopener">SPECPROC-11</a>. Add <code>WORK_PLAN.<em>indications</em></code>;<br>
 Improve documentation of <code>TIMELINE_MOMENT</code>;<br>
 <a href="https://specifications.openehr.org/tickets/SPECPROC-13" target="_blank" rel="noopener">SPECPROC-13</a>. Clarify Work Plan instantiation and distribution semantics:<br>
 Add section 4.4.1 Phases of Work;<br>
 Add subsection to section 2.5 on Distributed plans.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">B Naess,<br>
 M Kejžar,<br>
 T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">31 Oct 2018</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">1.1.1</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-9" target="_blank" rel="noopener">SPECPROC-9</a>. Add sub-section on Time and Work in Background section.<br>
 <a href="https://specifications.openehr.org/tickets/SPECPROC-10" target="_blank" rel="noopener">SPECPROC-10</a>. Add <code>BLOCKING_GROUP</code> and <code>BLOCKING_BRANCH</code> classes and <code>EVENT_ACTION.<em>receiver_thread_next_state</em></code>.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">21 Jun 2018</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">1.1.0</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-6" target="_blank" rel="noopener">SPECPROC-6</a>. Adjust <code>SYSTEM_CALL</code> definition;<br>
 Add <code>PARAMETER_DEF</code> and <code>PARAMETER_MAPPING</code> types.<br>
 <a href="https://specifications.openehr.org/tickets/SPECPROC-7" target="_blank" rel="noopener">SPECPROC-7</a>. Provide support in decision structures for automated / decision support / ad hoc modes;<br>
 Add <code>CHOICE_GROUP</code>, <code>CHOICE_BRANCH</code>, <code>ADHOC_GROUP</code>, <code>ADHOC_BRANCH</code> classes, and an attribute for marking any group as overridable at execution time.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">T Beale,<br>
 M Kejžar</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">15 Jan 2018</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">1.0.4</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-3" target="_blank" rel="noopener">SPECPROC-3</a>. Context value model adjustments;<br>
 Adjust <code>CONTEXT_EXPRESSION</code> type to have <code><em>name</em></code>;<br>
 Add <code>CONTEXT_CONSTANT</code>, <code>EXTERNAL_VARIABLE</code> and <code>LOCAL_VARIABLE</code> types.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">04 Dec 2017</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">1.0.3</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-5" target="_blank" rel="noopener">SPECPROC-5</a>. Correct <code>DECISION_BRANCH</code> method of specifying value.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">04 Dec 2017</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">1.0.2</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-4" target="_blank" rel="noopener">SPECPROC-4</a>. Refine <code>SYSTEM_CALL</code> model, describe variable referencing.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">M Kejžar,<br>
 M Polajnar,<br>
 T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">02 Dec 2017</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">1.0.1</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-2" target="_blank" rel="noopener">SPECPROC-2</a> Fix various typos; add missed <code>BOOLEAN_CONTEXT_EXPRESSION</code>;
 Remove duplicate attribute <code>WORK_PLAN.<em>events</em></code>.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">M Kejžar</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">24 Oct 2017</p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top" colspan="4"><p class="tableblock"><strong>PROC Release 1.0.0</strong></p></th>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">1.0.0</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-1" target="_blank" rel="noopener">SPECPROC-1</a>. Further documentation improvements;
 Added explanations for resume semantics; added <code>RESUME_ACTION</code> class.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">17 Oct 2017</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">0.9.0</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-1" target="_blank" rel="noopener">SPECPROC-1</a>. Restructure document;
 Various refactoring of Event classes; global calendar, timeline.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">12 Oct 2017</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">0.8.2</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECPROC-1" target="_blank" rel="noopener">SPECPROC-1</a>. Workshop Sep 25-28 and follow-up calls;<br>
 Significant updates to model;<br>
 Include event-based design;<br>
 Moved spec to new PROC openEHR component.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">B Fabjan,<br>
 B Lah,<br>
 B Naess,<br>
 M Kejžar,<br>
 E Leonov,<br>
 V Makarov,<br>
 T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">10 Oct 2017</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">0.8.1</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">New Task subtypes; re-design 'system request' concept; build out callback classes; remove explicit notifications from model.<br>
 Improve performer model. Add more design material. Improved Task state machine.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">25 Aug 2017</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">0.8.0</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Incorporate changes from Workshop 28/29 July. Change principal performer to Group level; add specialised Task types; add system request.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">B Lah,<br>
 B Naess,<br>
 M Kejžar,<br>
 E Leonov,<br>
 T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">06 Jul 2017</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">0.7.2</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Incorporate review comments from Boštjan Lah.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">B Lah,<br>
 T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">20 Jun 2017</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">0.7.1</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Rework runtime model.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">07 Jun 2017</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Incorporate review comments from Pablo Pazos.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">P Pazos,<br>
 T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">06 Jun 2017</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">0.7.0</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Major rewrite, incorporating structure, parallelism, decision paths, and execution history.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">T Beale</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">31 May 2017</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">0.6.0</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://specifications.openehr.org/tickets/SPECRM-58" target="_blank" rel="noopener">SPECRM-58</a>. Initial writing.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">T Beale,<br>
 B Naess,<br>
 I McNicoll</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">26 Jan 2017</p></td>
</tr>
</tbody>
</table>
</div>
</div>
<div class="sect1">
<h2 id="_acknowledgements"><a class="anchor" href="#_acknowledgements"></a>Acknowledgements</h2>
<div class="sectionbody">
<div class="sect2">
<h3 id="_primary_author"><a class="anchor" href="#_primary_author"></a>Primary Author</h3>
<div class="ulist">
<ul>
<li>
<p>Thomas Beale, Ars Semantica (UK); openEHR Foundation Management Board.</p>
</li>
</ul>
</div>
</div>
<div class="sect2">
<h3 id="_contributors"><a class="anchor" href="#_contributors"></a>Contributors</h3>
<div class="paragraph">
<p>This specification benefited from formal and informal input from the openEHR and wider health informatics community. The openEHR Foundation would like to recognise the following people for their contributions.</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Danielle Santos Alves, RN, midwife, Federal University of Pernambuco (UFPE), Brazil</p>
</li>
<li>
<p>Borut Fabjan, Program Manager, Marand, Slovenia</p>
</li>
<li>
<p>Matija Kejžar, Marand, Slovenia</p>
</li>
<li>
<p>Bostjan Lah, Architect, Marand, Slovenia</p>
</li>
<li>
<p>Eugeny Leonov, Solit Clouds, Moscow, Russia</p>
</li>
<li>
<p>Ian McNicoll MD, FreshEHR, UK</p>
</li>
<li>
<p>Bjørn Næss, DIPS, Norway</p>
</li>
<li>
<p>Pablo Pazos Gutierrez, Senior engineer, CaboLabs, Uruguay</p>
</li>
<li>
<p>Pekka Pesola, Engineer, Tieto, Finland</p>
</li>
<li>
<p>Vladimir V Makarov, Department of Information Technologies, City of Moscow</p>
</li>
</ul>
</div>
</div>
<div class="sect2">
<h3 id="_support"><a class="anchor" href="#_support"></a>Support</h3>
<div class="paragraph">
<p>The work reported in this specification has been funded by the following organisations:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>City of Moscow</p>
</li>
<li>
<p>Marand d.o.o., Slovenia</p>
</li>
<li>
<p>DIPS, Norway</p>
</li>
<li>
<p>Ars Semantica, UK</p>
</li>
</ul>
</div>
</div>
<div class="sect2">
<h3 id="_intellectual_origins"><a class="anchor" href="#_intellectual_origins"></a>Intellectual Origins</h3>
<div class="paragraph">
<p>Many of the design ideas presented in this specification came from analysis of use cases from industry sources. In particular, the openEHR implementers Marand and DIPS provided significant detailed requirements, use cases, and design ideas.</p>
</div>
<div class="paragraph">
<p>Additionally the Activity-Based Design (ABD) project at Intermountain Healthcare (2015-), on which the primary author worked part time proved an important source of cross-fertilisation. The latter project is led by David Edwards and Alan James (chief architect), within the clinical quality program, under Dr Brent James, Chief Quality Officer at Intermountain Healthcare. ABD has a sophisticated architecture based on a custom archetype / template framework, adaptive workflow concepts, application generation and real-time speech recognition. It has pioneered a number of concepts used in the current specification, including the separation of definition, materialised and runtime levels of representation.</p>
</div>
<div class="paragraph">
<p>Lastly, a review of research literature and standards was conducted. Many of the ideas in YAWL (<a href="#Hofstede_van_der_Aalst2009">Hofstede&#44; van der Aalst&#44; Adams&#44; &amp; Russell&#44; 2010</a>) and its underlying research influenced this specification. The authors also reviewed various standards, including the OMG&#8217;s <a href="http://www.bpmn.org/" target="_blank" rel="noopener">BPMN</a> and <a href="https://www.omg.org/spec/CMMN/1.0/" target="_blank" rel="noopener">CMMN</a>.</p>
</div>
</div>
<div class="sect2">
<h3 id="_trademarks"><a class="anchor" href="#_trademarks"></a>Trademarks</h3>
<div class="ulist">
<ul>
<li>
<p>'openEHR' is a trademark of the openEHR Foundation.</p>
</li>
<li>
<p>'OMG' is a trademark of the Object Management Group.</p>
</li>
</ul>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_preface"><a class="anchor" href="#_preface"></a>1. Preface</h2>
<div class="sectionbody">
<div class="sect2">
<h3 id="_purpose"><a class="anchor" href="#_purpose"></a>1.1. Purpose</h3>
<div class="paragraph">
<p>This specification of the openEHR Task Planning facility addresses requirements in the area of automated clinical process support in which some form of granular planning of clinical work is required. The central concept is that of a <em>plan</em> (or set of plans) designed to achieve a <em>goal</em> and that relate to an <em>active biological subject</em>.</p>
</div>
<div class="paragraph">
<p>The intended audience includes:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Standards bodies producing health informatics standards;</p>
</li>
<li>
<p>Academic groups using openEHR;</p>
</li>
<li>
<p>The open source healthcare community;</p>
</li>
<li>
<p>Solution vendors;</p>
</li>
<li>
<p>Medical informaticians and clinicians interested in health information.</p>
</li>
<li>
<p>Health data managers.</p>
</li>
</ul>
</div>
</div>
<div class="sect2">
<h3 id="_related_documents"><a class="anchor" href="#_related_documents"></a>1.2. Related Documents</h3>
<div class="paragraph">
<p>Prerequisite documents for reading this document include:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>The <a href="https://specifications.openehr.org/releases/BASE/latest/architecture_overview.html" target="_blank" rel="noopener">openEHR Architecture Overview</a>.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Related documents include:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>The <a href="https://specifications.openehr.org/releases/PROC/Release-1.5.0/tp_vml.html" target="_blank" rel="noopener">Task Planning Visual Modelling Language (TP-VML)</a>;</p>
</li>
<li>
<p>The <a href="https://specifications.openehr.org/releases/RM/latest/ehr.html" target="_blank" rel="noopener">openEHR EHR Information Model</a>;</p>
</li>
</ul>
</div>
</div>
<div class="sect2">
<h3 id="_status"><a class="anchor" href="#_status"></a>1.3. Status</h3>
<div class="paragraph">
<p>This specification is in the TRIAL state. The development version of this document can be found at <a href="https://specifications.openehr.org/releases/PROC/latest/task_planning.html" target="_blank" rel="noopener">https://specifications.openehr.org/releases/PROC/latest/task_planning.html</a>.</p>
</div>
<div class="paragraph">
<p>Known omissions or questions are indicated in the text with a 'to be determined' paragraph, as follows:</p>
</div>
<div class="paragraph tbd">
<p><strong>TBD</strong>: (example To Be Determined paragraph)</p>
</div>
</div>
<div class="sect2">
<h3 id="_feedback"><a class="anchor" href="#_feedback"></a>1.4. Feedback</h3>
<div class="paragraph">
<p>Feedback may be provided on the <a href="https://forums.openehr.org/c/specifications" target="_blank" rel="noopener">technical mailing list</a>.</p>
</div>
<div class="paragraph">
<p>Issues may be raised on the <a href="https://specifications.openehr.org/components/PROC/open_issues" target="_blank" rel="noopener">specifications Problem Report tracker</a>.</p>
</div>
<div class="paragraph">
<p>To see changes made due to previously reported issues, see the <a href="https://specifications.openehr.org/components/PROC/history" target="_blank" rel="noopener">PROC component Change Request tracker</a>.</p>
</div>
</div>
<div class="sect2">
<h3 id="_conformance"><a class="anchor" href="#_conformance"></a>1.5. Conformance</h3>
<div class="paragraph">
<p>Conformance of a data or software artifact to an openEHR specification is determined by a formal test of that artifact against the relevant <a href="https://specifications.openehr.org/releases/ITS/latest/index" target="_blank" rel="noopener">openEHR Implementation Technology Specification(s) (ITSs)</a>, such as an IDL interface or an XML-schema. Since ITSs are formal derivations from underlying models, ITS conformance indicates model conformance.</p>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_background"><a class="anchor" href="#_background"></a>2. Background</h2>
<div class="sectionbody">
<div class="sect2">
<h3 id="_survey_of_requirements"><a class="anchor" href="#_survey_of_requirements"></a>2.1. Survey of Requirements</h3>
<div class="paragraph">
<p>The following sections discuss the requirements for a category of computational system that supports the execution of clinical processes by their performers. The general concept of 'work plans' consisting of 'sub-plans', 'tasks', decision points etc is assumed.</p>
</div>
<div class="sect3">
<h4 id="_how_can_computers_improve_clinical_care_process"><a class="anchor" href="#_how_can_computers_improve_clinical_care_process"></a>2.1.1. How Can Computers Improve Clinical Care Process?</h4>
<div class="paragraph">
<p>Naive approaches to the use of IT to support clinical care process generally assume that the benefits are obvious and automatic, and as a result, often fail to understand in what form computer support may be useful. An error common among IT professionals is to imagine that a clinical workflow system will itself <em>perform</em> the work currently performed by humans, i.e. to replace them. Even with the advent of AI-driven autonomous surgical robots and sophisticated decision support, this view is mistaken, since a clinical process is not the same thing as the work undertaken by one of its performers.</p>
</div>
<div class="paragraph">
<p>To understand the form a clinical workflow / planning system must take to be useful, we need to understand how clinical work is performed in the real world.</p>
</div>
<div class="paragraph">
<p>The first aspect to consider is that a large proportion of the activities of healthcare delivery are not clinical <em>per se</em>, but administrative and logistical, such as registering, booking, scheduling, transfers of care and so on. However, the timing and conditions that govern appointments and transfers are unavoidably clinically driven, for example: the visits during routine ante-natal care; follow-up appointments post breast cancer treatment; determination of when to discharge a patient to home care. This tells us that there will be some representation of long-term planning in a clinical process support system, not just in administrative systems.</p>
</div>
<div class="paragraph">
<p>The second aspect to consider is that clinical professionals don&#8217;t need to be told how to do their routine work. When the moment for performing clinical work arrives, with the exception of pure training situations, professionals already know what to do. What they may need is help with any of the following:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>following care pathways and guidelines</em> for complex conditions e.g. acute stroke, sepsis, complex childbirth; also guidelines that incorporate changing <em>policy</em> on the use of specific types of test whose costs and risks change over time (e.g. CT scan, MRI, certain drugs);</p>
</li>
<li>
<p><em>clinical check lists</em> for multi-step procedures, including surgery, to prevent busy or tired personnel forgetting common steps;</p>
</li>
<li>
<p><em>decision support</em> to determine appropriate treatments, medications from among numerous and/or changing possibilities;</p>
</li>
<li>
<p><em>verification (signing off)</em> of tasks performed for medico-legal reasons, process improvement (including <em>process mining</em>).</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>In general, the above capabilities address three human fallibilities:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>limited capacity to deal with complexity (often denoted as <a href="https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two" target="_blank" rel="noopener">the '7±2' problem</a>);</p>
</li>
<li>
<p>the inability to keep up with change (new medications, research etc); and</p>
</li>
<li>
<p>the failure to perform a simple routine step in an activity due to fatigue, being rushed, or under pressure.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Automated support for the above would significantly aid the short-term, single clinician/patient situation, but much clinical care today is team-based, and also unfolds over a longer time than a single work shift or day. Therefore another important kind of help is needed:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>coordination</em> of:</p>
<div class="ulist">
<ul>
<li>
<p>team members across departments (via e.g. plan-generated notifications); example: acute stroke care;</p>
</li>
<li>
<p>workers undertaking care spanning multiple shifts and personnel, e.g. chemotherapy administration.</p>
</li>
</ul>
</div>
</li>
</ul>
</div>
<div class="paragraph">
<p>Another type of support that process automation can provide is to enable <em>on-the-fly interaction with the EHR</em>, including retrieval and recording. The idea here is to <em>integrate</em> EHR recording (well known as a time-consuming activity <em>additional</em> to clinical care) with execution of clinical work, such that when the work is done, the EHR is up-to-date, or very close to it.</p>
</div>
<div class="paragraph">
<p>A final category of requirement for clinical process automation is <em>training</em>. In this case, the steps of a procedure may be second nature to an experienced clinician but for a trainee nurse or surgeon to whom much is new, a clinical workflow system would potentially represent even the most basic steps (e.g. cannulation, central line insertion, surgery preparation) to the trainee. Since being 'experienced' is not a binary state, but a continuum over one&#8217;s professional life, some level of training support is likely to be useful for any professional of any level of knowledge, e.g. to learn a newly developed surgical method, or revise a procedure not performed for some time. Training support therefore needs to be a flexible capability to be turned on or off at multiple levels of expertise, by any type of professional role, also based on work context.</p>
</div>
<div class="paragraph">
<p>The sections below elucidate some of the topics mentioned above.</p>
</div>
</div>
<div class="sect3">
<h4 id="_cognitive_model"><a class="anchor" href="#_cognitive_model"></a>2.1.2. Cognitive Model</h4>
<div class="sect4">
<h5 id="_the_co_pilot_paradigm"><a class="anchor" href="#_the_co_pilot_paradigm"></a>2.1.2.1. The Co-pilot Paradigm</h5>
<div class="paragraph">
<p>Common to all of the categories of requirement described above is a general need that any clinical process planning system not disturb the cognitive processing of workers, but provide judicious help when needed. In this view, the system acts like a co-pilot, and does not attempt to be the pilot. It may remind, notify, verify, answer questions and perform documentation, but always assumes that the clinical professionals are both the ultimate performers of the work as well as the ultimate deciders. The latter means that workers may at any time <em>override</em> system-proposed tasks or decisions. Similar to a car navigation system, a clinical co-pilot must absorb deviations from original plans and recompute the pathway at each new situation, as it occurs.</p>
</div>
</div>
<div class="sect4">
<h5 id="_voice_based_hci"><a class="anchor" href="#_voice_based_hci"></a>2.1.2.2. Voice-based HCI</h5>
<div class="paragraph">
<p>One kind of technology that is becoming routine is voice-based human/computer interaction (HCI). Voice technology has become a useful convenience for using mobile phones while driving or interacting with home audio-visual systems, where it is replacing the remote control. It is likely to become the principle means of HCI in many clinical situations, since it achieves two things difficult to achieve by other means:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>by replacing physical keyboard interaction with voice, it enables interaction with the system to occur in <em>parallel</em>, and therefore in real-time, with clinical work that typically already occupies the worker&#8217;s hands and eyes;</p>
</li>
<li>
<p>it largely removes the problem of maintaining the <em>sterile field</em> around a patient that would otherwise be jeapordised by multiple workers touching keyboards and touchscreens.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Voice control is also likely to be crucial to enabling a clinical process support system to operate as an intelligent co-pilot rather than an overbearing presence in the work environment, since it starts to emulate the normal conversational abilities of human workers, via which any principal worker may ask for help as needed, but also limit system intervention when it is not needed.</p>
</div>
</div>
</div>
<div class="sect3">
<h4 id="_care_pathways"><a class="anchor" href="#_care_pathways"></a>2.1.3. Care Pathways</h4>
<div class="paragraph">
<p>The <em>task planning</em> model described in this specification is conceptually situated in a larger semantic framework that includes entities at multiple levels, i.e.:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>care pathway</em> - a structured description of care of a condition / ideal patient, typically including or referring to one or more <em>guidelines</em> that describe in detail how to deal with specific situations within the condition (<a href="#Schrijvers_et_al2012">Schrijvers&#44; van Hoorn&#44; &amp; Huiskes&#44; 2012</a>);</p>
</li>
<li>
<p><em>care plan</em> - a general plan for care of an actual patient, possibly using published Care Pathways and/or guidelines and taking into account individual specificities;</p>
</li>
<li>
<p><em>task plan</em> - a concrete definition of a set of fine-grained planned tasks for one or more actors to perform over time to achieve a particular goal.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>These entities and their relationships can be visualised as follows.</p>
</div>
<div id="pathway_plan_triad" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/pathway_plan_triad.svg" alt="pathway plan triad" width="60%">
</div>
<div class="title">Figure 1. The care pathway / care plan / task plan triad</div>
</div>
<div class="paragraph">
<p>The above diagram shows task plans as concrete planning artefacts that result from one or more care plans for a specific patient, and may be partly based on published care pathways and/or clinical guidelines, each of which can be thought of as a basis for task plans for an ideal patient for a given condition (e.g. pregnancy, sepsis, stroke etc). Where care pathways (or parts thereof) can be represented as formal artefacts, they can act as prototypes for task pan structures. However, a care pathway for a model patient is not the same thing as a task plan(s) for an actual patient, since each real patient has his/her own specific combination of conditions, history, preferences and phenotype. Thus, where task plans are based on care pathways, the latter act as prototypes whose ideal form may be modified by the specific care plan and/or as the care team deems appropriate.</p>
</div>
<div class="paragraph">
<p>This specification addresses the representation and semantics of concrete task plans. It does not address the representation of care plans, which normally contain recommendations for prescriptions, rather than granular task plans. However it is likely to be very close to a formal model of care pathways, although further research will be needed to verify this.</p>
</div>
<div class="paragraph">
<p>The task plan model does however assume that a task plan may be <em>created</em> due to a care plan, and that the care plan may in turn have been derived from one or more care pathways or guidelines; accordingly, the means to identify the plan and pathway / guideline are provided.</p>
</div>
</div>
<div class="sect3">
<h4 id="_order_sets"><a class="anchor" href="#_order_sets"></a>2.1.4. Order Sets</h4>
<div class="paragraph">
<p>One common conceptual entity is the so-called <em>order set</em>, which is generally understood as:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>a set of orders for medications and/or other therapies that are used together to achieve a particular clinical goal, e.g. the drugs for a particular chemotherapy regimen are often modelled as an order set;</p>
</li>
<li>
<p>potentially a detailed plan for administration of the items in the order set, which may be a fully planned out schedule of single administrations on particular days and times;</p>
</li>
<li>
<p>descriptive meta-data, including authors, history, evidence base, etc.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>In most EHR/EMR architectures (including openEHR), the first item corresponds to a set of 'orders' or 'prescriptions' (in openEHR, 'Instructions'), while the second is a candidate for representation via the Task Planning facility described in this specification.</p>
</div>
<div class="paragraph">
<p>This specification addresses the lack of fine-grained task planning facilities in most EHR/EMR architectures and products, which are limited to Prescription, Order and Action concepts. These provide ways of stating orders and recording actions performed after the fact, but no way of representing or sharing plans for actions before they are performed. This limitation as it applies to openEHR is described in more detail below.</p>
</div>
<div class="paragraph">
<p>The approach followed here is to specify representations of task plans at various stages in the planning lifecycle, i.e.:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>design time</em>: templates or prototypes of standard task plans are developed and published;</p>
</li>
<li>
<p><em>runtime - planning</em>: task plan prototypes are turned into concrete plans for specific work items for specific patients and activated;</p>
</li>
<li>
<p><em>runtime - work execution</em>: task plans are executed by clinical performers and the plan maintained up to date in real time;</p>
</li>
<li>
<p><em>runtime - work completion</em>: as each task is performed, standard clinical statements (openEHR Entries) are committed to the EHR to record what was done.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The models described here are thus designed to support both design-time modelling (via archetypes, terminology subsetting) and runtime execution with modifications and abandonment possible while the work is being performed.</p>
</div>
</div>
<div class="sect3">
<h4 id="_time_and_work_in_the_real_world"><a class="anchor" href="#_time_and_work_in_the_real_world"></a>2.1.5. Time and Work in the Real World</h4>
<div class="paragraph">
<p>One of the key characteristics of work in the real world is the passage of time, and how it relates to workers. In general human workers are present for a <em>shift</em> or <em>work day</em> of a limited number of hours at a time, with a gap until the next appearance of the same worker. In healthcare, nursing and allied care professionals as well as house residents usually work on a shift basis, in which complete coverage of every 24 hour period is achieved over a series of shifts, while senior physicians and specialists are typically present during normal working hours. In addition, human workers go on holidays, leave job posts and clinics, and themselves die (being only human after all).</p>
</div>
<div class="paragraph">
<p>A similar kind of pattern, although usually with longer periods, applies to machines that may be active parties in organised work (e.g. robotic surgery devices), since all machines eventually need to be serviced, and in the long term, obsoleted and replaced. Service patterns may be a combination of regular planned down-times and unplanned failures.</p>
</div>
<div class="paragraph">
<p>The general picture of workers is therefore one of repeating cycles of presence and thus <em>availability</em> (shifts, work days, in-service periods) during normal 'at-work' periods, punctuated by variable absences for holidays, sickness, downtime, and bounded by commencement and completions of appointments.</p>
</div>
<div class="paragraph">
<p>In contrast to this, the 'work to be done', whether a well-defined procedure (e.g. GP encounter, surgery) or open-ended care situation (diabetes, post-trauma therapy) will usually have its own natural temporal extension. The presence of the patient as the subject in healthcare usually follows this, although may not, such as in the case of pathology and microbiology lab testing, in which tissue samples are proximate subject of the work. Consequently, there are a variety of relationships between the innate temporal structure of the planned work, and that of the work execution by its performers.</p>
</div>
<div class="paragraph">
<p>In some cases, an entire piece of work may be completable within a work <em>session</em>, during which the workers do not change. Most doctor&#8217;s appointments and single surgeries are of this nature. In other cases, an overall task takes some days or weeks, i.e. many shifts and work days. Open-ended care processes will run through shifts, work-days and also longer absences, as well as permanent employment changes. To make things more difficult, it should always be remembered that no process, short or long, is guaranteed to be conveniently contained within a shift or non-holiday period - unplanned worker absence may occur at any time and any point within an executing process.</p>
</div>
<div class="paragraph">
<p>Two conclusions can be drawn from the above. The first is that variable worker availability is a fact of life, and any machine-based process execution engine must deal with it. The second is that, for long running processes, the executing task plan is likely to be the <em>only</em> coherent single record of planned and performed actions on the subject, as shifts and holidays pass, new workers commence, and others leave or retire.</p>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_execution_environment"><a class="anchor" href="#_execution_environment"></a>2.2. Execution Environment</h3>
<div class="sect3">
<h4 id="_general_paradigm"><a class="anchor" href="#_general_paradigm"></a>2.2.1. General Paradigm</h4>
<div class="paragraph">
<p>As soon as the notion of <em>planning</em> is assumed, we enter the workflow space, and it becomes essential to describe the intended paradigm of the human / machine execution environment. This is due to the fact that any description of planned tasks acts as a set of instructions to actors intended to perform the tasks. Since the instructions (task plans) will be represented in the IT layer and the performing actors (generally human, although they may also be autonomous devices or software applications) exist in the real world, an account of the interaction between the computing environment and the real world is required.</p>
</div>
<div class="paragraph">
<p>Firstly, we distinguish the following entities in the work environment:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>computing environment</em>:</p>
<div class="ulist">
<ul>
<li>
<p><strong>work plan definition</strong>: a reusable definition of work to be done, consisting of tasks, potentially standardised according to a guideline or protocol;</p>
</li>
<li>
<p><strong>work plan instance</strong>: a run-time instance of a task plan, potentially with local variations, created for execution by an actor or actors;</p>
</li>
</ul>
</div>
</li>
<li>
<p><em>real world</em>:</p>
<div class="ulist">
<ul>
<li>
<p><strong>performing actor</strong>: an autonomous human, machine or software application that performs tasks in the real world as part of a procedure designed to achieve a goal;</p>
</li>
</ul>
</div>
</li>
</ul>
</div>
<div class="paragraph">
<p>In real-world environments, the actors are not passive recipients of commands from a computer application implementing a work plan, but are instead active agents who normally work together to perform a job. Working together involves peer-to-peer communication, coherent sequencing of tasks and so on. A workflow application provides help by maintaining a representation of the work plan, and a representation of its progress in execution. It is immediately apparent that the application&#8217;s idea of a given work plan execution and the real world state of the same work are not identical, and in fact may be only approximately related. For example, the computable form of the work plan might only include some of the tasks and actors at work in the real world. There are in fact two workflows executing: a virtual workflow and the real world one, and there is accordingly a challenge of <em>synchronisation</em> of the two.</p>
</div>
<div class="paragraph">
<p>There is also a question of the nature of the communication between the workflow application and the real world actors, which we can think of as consisting of:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>commands</em>: signals from the work plan system to a real world actor to do something;</p>
</li>
<li>
<p><em>notifications</em>: signals to and from the work plan system and the real world actors on the status of work, e.g. 'new work item', 'item completed' etc;</p>
</li>
<li>
<p><em>data</em>: data collection from actors and presentation to actors from the system.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>This view of the environment can be illustrated as follows.</p>
</div>
<div id="workflow_execution_paradigm" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/workflow_execution_paradigm.svg" alt="workflow execution paradigm" width="55%">
</div>
<div class="title">Figure 2. Work plan execution paradigm</div>
</div>
</div>
<div class="sect3">
<h4 id="_distributed_plans"><a class="anchor" href="#_distributed_plans"></a>2.2.2. Distributed Plans</h4>
<div class="paragraph">
<p>There is a potentially complicated relationship between IT environments in which computable plans execute and the work-places where the human actors are found. This is because 'systems' in a concrete sense are part of IT installations owned by organisations that may or may not be the employers of the workers, while plans may logically span more than one distinct work-place. For example a clinical plan for diagnosing and resolving angina may contain steps that are performed by:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>an emergency department (part of a hospital);</p>
</li>
<li>
<p>a general practitioner (in a separate health clinic);</p>
</li>
<li>
<p>a cardiologist (within a hospital, possibly a different one to the original ED attendance);</p>
</li>
<li>
<p>a radiology department (usually within a hospital, possibly also different, for reasons of availability, machine type etc).</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>These various healthcare facilities almost certainly have their own IT systems within a managed environment and security boundary, with some possible sharing of systems among some facilities. Consequently, where the notional clinical plan executes in the real world doesn&#8217;t usually cleanly correspond to one IT system in which a plan engine can execute it.</p>
</div>
<div class="paragraph">
<p>On the other hand, in an ideal environment with regional patient-centric hosted services (shared EHR etc), accessible by all healthcare facilities the patient visits, the logical locus of a plan&#8217;s activities - the various HCFs taken together - correspond 1:1 with a location where the plan can be executed by an engine, i.e. the regional system.</p>
</div>
<div class="paragraph">
<p>The following figure illustrates different possible relationships between a logical work plan definition whose work is performed by actors in different enterprises, and the location of work plan engines where such a plan may logically be executed. The particular arrangement shown has one enterprise (on the left) with its own separate IT (typical for most hospitals today) and three other enterprises that share regional health IT services relevant to the patient record and work plan execution (they probably have their own private IT for more mundate purposes as well of course). The work plan is shown as having tasks that are to be performed at all four of the enterprises.</p>
</div>
<div id="distributed_plan_execution" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/distributed_plan_execution.svg" alt="distributed plan execution" width="80%">
</div>
<div class="title">Figure 3. Distributed work plan execution</div>
</div>
<div class="paragraph">
<p>The diagram implies a scheme in which the same plan might be executed in multiple places, presumably with synchronisation, however this is not posited as a requirement. The only hard requirement is that there is <em>some</em> means of enabling the various parts of a plan to execute in the various work-places required.</p>
</div>
<div class="paragraph">
<p>One of the challenges in such distributed work environments, which are the norm in healthcare, is the ownership, creation, maintenance and sharing of work plan definitions that implicate workers across enterprises.</p>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_what_task_planning_does_not_do"><a class="anchor" href="#_what_task_planning_does_not_do"></a>2.3. What Task Planning Does Not Do</h3>
<div class="paragraph">
<p>Some common capabilities related to clinical process management are not directly covered by this specification, as described in the following sub-sections.</p>
</div>
<div class="sect3">
<h4 id="_work_plans_versus_task_lists_todo_lists"><a class="anchor" href="#_work_plans_versus_task_lists_todo_lists"></a>2.3.1. Work Plans versus Task Lists (TODO Lists)</h4>
<div class="paragraph">
<p>The specification is based around the concept of a <em>work plan</em>, which is designed to achieve a goal, and at execution time is applied to a <em>subject</em>, i.e. human or other subject of care. The plan notion is thus goal- and subject-centric.</p>
</div>
<div class="paragraph">
<p>A related concept is that of the <em>task list</em> (aka 'TODO list'), which is a logical list of tasks for a worker to perform. The task list is thus worker-centric, not subject-centric, and as such, task lists must be <em>derived</em> from task plans. Conceptually this is done by processing all extant task plans for some organisational unit (say a hospital department) and allocating particular tasks to particular actors. Allocation may happen in a just-in-time fashion, and may be modified (e.g. due to unforeseen unavailability of workers), such that a task list is essentially a dynamic personal calendar view for the short term (typically days or weeks) whereas task plans may correspond to any length of time, from a few minutes to years.</p>
</div>
<div class="paragraph">
<p>This specification does not cover the model of worker task lists or extracted calendar views, although it provides some guidance on how to generate task lists for workers.</p>
</div>
</div>
<div class="sect3">
<h4 id="_appointment_booking_and_management"><a class="anchor" href="#_appointment_booking_and_management"></a>2.3.2. Appointment Booking and Management</h4>
<div class="paragraph">
<p>The planning paradigm envisaged by this specification does not try to directly address the problem of concretely creating and managing bookings for appointments, which, while conceptually simple, in real life unavoidably entails the complexity of ad hoc communication, cancellations, rebooking and so on. Instead it assumes that the existing systems designed to help perform this mostly administrative work will manage to get patients to intended appointments.</p>
</div>
<div class="paragraph">
<p>However, since the timing of visits is usually clinically determined, it would be reasonable for a task within a plan to <em>request an appointment</em> be created for a visit at some nominal time for some purpose, e.g. week 22 ante-natal review, in next 8 days. Another part of the same plan may have a wait state whose trigger event is the patient turning up for the nominated purpose. However, all of the administrative activity that occurs in order to ensure the patient appears is assumed to be external to the task planning system.</p>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_clinical_decision_support_cds"><a class="anchor" href="#_clinical_decision_support_cds"></a>2.4. Clinical Decision Support (CDS)</h3>
<div class="paragraph">
<p>While this specification covers the computable representation of decisions in a work plan, it is not intended to replace CDS systems that perform complex pure decision analysis, typically via access to specialist knowledge bases. Instead, it is assumed that the plans running in the task planning system will make requests of various CDS systems to provide specific answers, e.g. to check medications interactions for a proposed prescription, or propose a type of treatment for a hypertensive patient.</p>
</div>
</div>
<div class="sect2">
<h3 id="_relationship_to_workflow_formalisms_and_systems"><a class="anchor" href="#_relationship_to_workflow_formalisms_and_systems"></a>2.5. Relationship to Workflow Formalisms and Systems</h3>
<div class="paragraph">
<p>This specification describes a model for a task plan concept that incudes support for work distribution across multiple performers, nested task plans, conditional branching, timing and various other facilities. Many of these are conceptually close to the features found in standard workflow languages such as <a href="http://www.bpmn.org/" target="_blank" rel="noopener">OMG BPMN (Business Process Modelling Notation)</a> and <a href="http://yawlfoundation.org/" target="_blank" rel="noopener">YAWL (Yet another Workflow Language)</a> (<a href="#Hofstede_van_der_Aalst2009">Hofstede&#44; van der Aalst&#44; Adams&#44; &amp; Russell&#44; 2010</a>), as well as emerging case-based standards such as <a href="https://www.omg.org/spec/CMMN/1.0/" target="_blank" rel="noopener">OMG CMMN (Case Management Modelling Notation)</a> and <a href="https://www.omg.org/spec/DMN/" target="_blank" rel="noopener">OMG DMN (Decision Model and Notation)</a>. Of these, YAWL is the most comprehensive in its design and the most useful source of concepts for the current specification.</p>
</div>
<div class="paragraph">
<p>While the model described here takes ideas from these languages, there are some key differences as well. The primary conceptual difference is that the subject (i.e. 'case') here is assumed to be a) an intentional agent (generally a human patient) that makes choices, and b) an active biological organism, which reacts to drugs and other interventions. In other words, an entity that cannot be considered a passive object (such as a package or blood sample), as is the case for most logistic workflows, for which languages such as BPMN are designed. (Note that even the patient can be a passive object in some circumstances, such as radiology.) Other departures include the use of a declarative rather than prescriptive means of defining the plan graph structure, and the formalisation of all elements of a plan and its execution.</p>
</div>
<div class="paragraph">
<p>The main consequence of this is that the design of a task plan is not taken to be a highly deterministic description whose exceptions are generally knowable in advance as they would be for a logistic system whose subjects are passive objects. Instead, tasks and groups of tightly-coupled tasks are specified in a more self-standing way, using preconditions rather than logical join and split operators.</p>
</div>
</div>
<div class="sect2">
<h3 id="_limitations_of_the_openehr_standard_entry_model"><a class="anchor" href="#_limitations_of_the_openehr_standard_entry_model"></a>2.6. Limitations of the openEHR standard Entry Model</h3>
<div class="paragraph">
<p>The Entry model described in the <a href="https://specifications.openehr.org/releases/RM/latest/ehr.html">openEHR EHR IM</a> defines a way to record clinical statements representing real observations, decisions, orders and actions that have occurred, in the EHR. In this scheme, Instructions represent orders for certain kinds of Actions to be performed. Actions and Observations represent events that have subsequently occurred in the real world - a real drug administration or an actual blood sugar measurement.</p>
</div>
<div class="paragraph">
<p>There is however a common additional need to concretely plan individual Actions and sometimes Observations ahead of time, as a set of 'tasks', often known as a 'task list'. Here we will use the more general term <em>task plan</em> to mean a specification of a set of actions to be performed by actors (usually human, but potentially machine as well) providing care.</p>
</div>
<div class="paragraph">
<p>A set of planned tasks need not all relate to a single order, or indeed any order. The general picture is that a task plan corresponds to some self-standing healthcare job to be done, which may include tasks designed to fulfill multiple orders, and also tasks not defined by orders.</p>
</div>
<div class="paragraph">
<p>To meet this need, a further kind of content can be recorded in the EHR, representing task plans containing tasks. Here we understand the word 'task' to mean 'definition of a planned task', i.e. a description of something to be performed in the future.</p>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_technical_requirements"><a class="anchor" href="#_technical_requirements"></a>3. Technical Requirements</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The discussion above provides a guide as to what should potentially be modelled in a plan. Rather than necessarily 'everything' (i.e. every possible step as per the medical textbook), it is:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>long term <em>clinical timing plans</em>;</p>
</li>
<li>
<p>reminders / checklist items for basic <em>actions that are often missed</em> or forgotten due to busy workplace and fatigue;</p>
</li>
<li>
<p>complex sets of actions defined by <em>clinical pathways</em>;</p>
</li>
<li>
<p>decision points that determine which path from alternatives to follow;</p>
</li>
<li>
<p><em>actions requiring sign-off</em> in some way;</p>
</li>
<li>
<p>actions that result in <em>recording</em> something in the EHR;</p>
</li>
<li>
<p>actions of varying levels of granularity that are needed in a <em>training</em> mode.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Task planning is accordingly applicable to numerous clinical scenarios, exemplified by the following:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>routine simple medication administration, e.g. for post-operative pain - tasks extend across worker shifts;</p>
</li>
<li>
<p>complex drug administration e.g. multi-drug chemotherapy over multiple days;</p>
</li>
<li>
<p>physiotherapy rehabilitation sessions - recurrent therapeutic procedure, with defined end-point;</p>
</li>
<li>
<p>dialysis - recurrent therapeutic procedure;</p>
</li>
<li>
<p>diet + physical activity plan for overweight treatment - recurrent tasks, patient as a performer;</p>
</li>
<li>
<p>surgery planning - one time event;</p>
</li>
<li>
<p>acute stroke management - multiple sets of tasks coordinated across multiple performers.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Within these and many other similar clinical procedures, a number of commonly occurring technical requirements appear, as described below.</p>
</div>
<div class="sect2">
<h3 id="_flexible_allocation_of_workers"><a class="anchor" href="#_flexible_allocation_of_workers"></a>3.1. Flexible Allocation of Workers</h3>
<div class="paragraph">
<p>As described earlier, the varying availability of workers for a given plan needs to be accommodated within the planning architecture. It should be possible for the specific worker performing a task to leave and be replaced by another, whether during an active period of work, or between tasks within the plan.</p>
</div>
</div>
<div class="sect2">
<h3 id="_coordinated_teamwork"><a class="anchor" href="#_coordinated_teamwork"></a>3.2. Coordinated Teamwork</h3>
<div class="paragraph">
<p>In many cases, a plan is intended for execution by a team of specialised performers, with each performer doing their part of the work, and at various points, passing control to another team member. Management of acute stroke is an example of this. In other cases, team members are working more or less in parallel, or by communicating in real time to each other. In both situations, if the workers are not physically in the same room at the same time, notifications are needed to alert each person when to start working on the subject; similarly, callback notifications are needed to alert original workers when other work has been completed, for example, an MRI image taken and report written.</p>
</div>
</div>
<div class="sect2">
<h3 id="_planned_tasks_for_an_order"><a class="anchor" href="#_planned_tasks_for_an_order"></a>3.3. Planned Tasks for an Order</h3>
<div class="paragraph">
<p>The simplest need is to be able to post a full plan of all actions to be performed for an order, in advance of the order commencing. This would result in a series of Tasks for each planned openEHR <code>ACTION</code> at execution time.</p>
</div>
<div class="paragraph">
<p>In openEHR, an order is represented by an <code>INSTRUCTION</code> instance, which contains a directive to do something such as preform radiography or administer medication. The form of representation in the Instruction is normally <em>interpretable</em> by an agent who will convert it to separate tasks. For example, a drug order for Amoxicillin 500mg oral tablet 3 times/day x 7 days is converted by a human agent to 21 separate tasks, each consisting of taking one tablet at a certain time or day. These tasks can be represented in a plan, each task of which which can then be performed and signed off by a staff member, e.g. a shift nurse. The structure of such a granular plan can act as a record of what has been done (or not), and what is left to do.</p>
</div>
<div class="paragraph">
<p>One difficulty with posting a full plan is that in some cases, the work is effectively open-ended, i.e. it has no currently known completion date. This might be because the patient condition being treated is chronic, e.g. insulin or Salbutamol (Ventolin) treatment; or it might be that although the condition is assumed to be limited in time, no current assumption can be made about when, e.g. pain medication of a trauma patient.</p>
</div>
</div>
<div class="sect2">
<h3 id="_tracking_orders_from_plans"><a class="anchor" href="#_tracking_orders_from_plans"></a>3.4. Tracking Orders from Plans</h3>
<div class="paragraph">
<p>A standard activity within any clinic context is to raise orders, e.g. for lab tests, radiology etc, and to await the results. This may commonly be done within the context of a plan representing a standard protocol, such as for an annual schedule of health checks for various categories of patient (child, adult, elderly, diabetic etc). In an openEHR context, orders are represented using Instruction EHR entries, with subsequent actions being recorded as Action entries in the EHR. Where a plan is defined to create orders, it should be possible to define tasks in the plan to create, execute (i.e. send) orders, and wait on results, for multiple simultaneous orders in the same plan.</p>
</div>
</div>
<div class="sect2">
<h3 id="_order_sets_and_protocols"><a class="anchor" href="#_order_sets_and_protocols"></a>3.5. Order Sets and Protocols</h3>
<div class="paragraph">
<p>A plan for a clinical intervention will typically need to encompass more than one order, in situations where drugs and other therapies are used according to a protocol or regime. For example, in multi-drug chemotherapy based on protocols like CHOP (non-Hodgkin&#8217;s lymphoma), COPP or Stanford V (Hodgkin&#8217;s lymphoma) etc, a single drug such as Cyclophosphamide is just a component. A plan for administering chemotherapy according to a R-CHOP protocol would implicate orders for the drugs  (R)ituximab, (C)yclophosphamide, (H)ydroxydaunorubicin, (O)ncovin, and (P)rednisolone or Prednisone, and would accordingly include planned tasks for each of these drugs as they are administered according to the protocol.</p>
</div>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 28.5714%;">
<col style="width: 28.5714%;">
<col style="width: 14.2857%;">
<col style="width: 14.2857%;">
<col style="width: 14.2858%;">
</colgroup>
<thead>
<tr>
<th class="tableblock halign-left valign-top">Drug</th>
<th class="tableblock halign-left valign-top">Standard [R]-CHOP-14 or<br>
 [R]-CHOP-21</th>
<th class="tableblock halign-left valign-top">[R]-Maxi-CHOP</th>
<th class="tableblock halign-left valign-top">Mode</th>
<th class="tableblock halign-left valign-top">Days</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">(R)ituximab</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">375 mg/m²</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">375 mg/m²</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">IV infusion</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Day 1</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">(C)yclophosphamide</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">750 mg/m²</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">1200 mg/m²</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">IV infusion</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Day 1</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">(H)ydroxydaunorubicin</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">50 mg/m²</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">75 mg/m²</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">IV bolus</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Day 1</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">(O)ncovin</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">1.4 mg/m² (max. 2 mg)</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">2 mg</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">IV bolus</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Day 1</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">(P)rednisone or (P)rednisolone</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">40 mg/m²</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">100 mg</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">PO qd</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Days 1-5</p></td>
</tr>
</tbody>
</table>
<div class="paragraph">
<p>(Extract from <a href="https://en.wikipedia.org/wiki/CHOP">Wikipedia</a>.)</p>
</div>
<div class="paragraph">
<p>A more general notion is of a protocol or guideline, which is a full set of actions to be performed to achieve a goal. Some of the actions will have corresponding orders, but others, such as making intermediate observations, may not. Examples can be found at sites such as the <a href="https://pathways.nice.org.uk/" target="_blank" rel="noopener">UK National Institute for Care and Excellence (NICE)</a>.</p>
</div>
</div>
<div class="sect2">
<h3 id="_lookahead_plan"><a class="anchor" href="#_lookahead_plan"></a>3.6. Lookahead Plan</h3>
<div class="paragraph">
<p>A more flexible version of a plan is 'lookahead' planning, i.e. posting a plan of tasks for a moving window in time, e.g. one day, a few days, a few nursing rotations etc. The idea is not to try to plan out the entire plan execution, since it can easily change or be stopped, e.g. due to change in patient or other unexpected events. In a lookahead approach, some planned tasks are executed, and more planned tasks are added. The planned timing of each set of tasks may change due to the current situation, with the effect that the overall set of tasks that unfolds in time may well be different from an attempt to plan all tasks before any are executed.</p>
</div>
<div class="paragraph">
<p>For the open-ended cases mentioned above, the only option is a lookahead plan that extends as far ahead in time as the treating physicians are prepared to go.</p>
</div>
</div>
<div class="sect2">
<h3 id="_recurring_repeatable_tasks"><a class="anchor" href="#_recurring_repeatable_tasks"></a>3.7. Recurring / Repeatable Tasks</h3>
<div class="paragraph">
<p>Many clinical plans involve repetition over time. For example, the 14-day version of the CHOP protocol (CHOP-14) involves execution of the 5 day treatment every 14 days, for 3 iterations. Other clinical plans are essentially permanently recurring for the life of the patient, e.g asthma therapy.</p>
</div>
</div>
<div class="sect2">
<h3 id="_checklist_sign_off"><a class="anchor" href="#_checklist_sign_off"></a>3.8. Checklist &amp; Sign-off</h3>
<div class="paragraph">
<p>If a plan is created, the constituent tasks can be viewed by workers as a checklist, and subsequently signed off as having been either performed or not done over time. The utility of this is that the correspondence between the tasks actually performed (represented by <code>ACTION</code>, <code>OBSERVATION</code> etc Entries) and the planned tasks is established. If a planned Action A1 is posted with execution time T, it might actually be performed at time T', but users still want to know that it was planned Action A1 that was intentionally performed, and not some other Action in the plan. Over the course of the order execution, a picture will emerge of planned Actions being performed and signed off, possibly with some being missed as not needed, or not done for some other reason. Additional Actions not originally posted in the plan might also be done if they are allowed by the general specification of the relevant archetypes.</p>
</div>
</div>
<div class="sect2">
<h3 id="_sub_plans"><a class="anchor" href="#_sub_plans"></a>3.9. Sub-plans</h3>
<div class="paragraph">
<p>Plans can be described at varying levels of detail, depending on how workers are intended to relate to them. One institution may describe an action such as cannulation atomically, relying on professional training and situational specifics to generate the correct concrete outcome, whereas another may require nurses to follow a guideline such as the <a href="http://emedicine.medscape.com/article/1998177-overview">Medscape Intravenous Cannulation</a> guideline. In cases where a self-standing clinical task is itself fully described in terms of steps, it is possible to represent the latter as its own plan, and to be able to <em>refer</em> to it from another plan. The general case is that any task that could be represented by a single item in a plan could also be represented by a reference to a separate detailed plan.</p>
</div>
</div>
<div class="sect2">
<h3 id="_task_grouping_optionality_and_execution_basis"><a class="anchor" href="#_task_grouping_optionality_and_execution_basis"></a>3.10. Task Grouping, Optionality and Execution Basis</h3>
<div class="paragraph">
<p>A set of tasks intended to achieve a defined goal could be performed sequentially or in parallel, and may include sub-groups of tasks that can performed together. A common situation is to have a plan intended for sequential (i.e. ordered) execution by the agent, one of whose steps is actually a sub-group of tasks which can be executed in parallel (i.e. in any order).</p>
</div>
<div class="paragraph">
<p>It can also be assumed that some tasks in a plan may be designated as optional, to be executed 'if needed' or on some other condition being true.</p>
</div>
<div class="paragraph">
<p>The general structure and execution semantics of a plan therefore includes the notion of sequential or parallel execution of groups of tasks, and also optional execution of some tasks. We can consider the plan itself as a outer group of tasks for which either sequential or parallel execution can be specified.</p>
</div>
</div>
<div class="sect2">
<h3 id="_decision_pathways"><a class="anchor" href="#_decision_pathways"></a>3.11. Decision Pathways</h3>
<div class="paragraph">
<p>Task plans derived from semi-formal care pathways or guidelines (and potentially ad hoc designed plans) may contain 'decision points', which are of the following logical form:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><strong>decision point</strong>: a step containing a variable assignment of the form <code>$v := expression</code>;</p>
</li>
<li>
<p><strong>subordinate decision paths</strong>: groups of tasks each group of which has attached a variable test of the form <code>$v rel_op value</code>, where <code>rel_op</code> is one of <code>=</code>, <code>/=</code>, <code>&lt;</code>, <code>&gt;</code>, <code>&lt;=</code> or <code>&gt;=</code>.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>An example of decision points is shown below, in an extract from the <a href="https://intermountainhealthcare.org/ext/Dcmnt?ncid=520500199" target="_blank" rel="noopener">Intermountain Healthcare Care Process Module (CPM) for Ischemic Stroke Management</a>:</p>
</div>
<div id="decision_pathway_example" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/IHC_stroke_decision_path.png" alt="IHC stroke decision path" width="80%">
</div>
<div class="title">Figure 4. Decision pathway example (Intermountain Healthcare Acute Stroke CPM)</div>
</div>
<div class="paragraph">
<p>In this example, the node containing the text "Further CLASSIFY &#8230;&#8203;" corresponds to a decision point that can be represented as <code>$symptom_onset_time := t</code>, where <code>t</code> is a time entered by a user. The subsequent nodes in the chart can be understood as paths based respectively on the tests <code>$symptom_onset_time &lt; 4.5h</code> and <code>4.5h &lt; $symptom_onset_time &lt; 6h</code>.</p>
</div>
<div class="paragraph">
<p>The ability to include decision pathways enables conditional sections of care pathways to be directly represented within a plan.</p>
</div>
</div>
<div class="sect2">
<h3 id="_different_types_of_cancellation"><a class="anchor" href="#_different_types_of_cancellation"></a>3.12. Different types of Cancellation</h3>
<div class="paragraph">
<p>Tasks in a plan can be cancelled before being attempted for two types of reasons. One case is when the performer or the system realises the task can&#8217;t be performed (perhaps for lack of resources), and it is cancelled from the plan ahead of time. The other case is when the performer or system realises that the task isn&#8217;t needed, and can be cancelled as unnecessary, or already done by an external agent (e.g. an examination done at a night clinic).</p>
</div>
<div class="paragraph">
<p>In the first, case, the cancellation can be understood as a 'failed' task, whereas in the second, it is equivalent to a successful task. These two flavours of cancellation should be understood by the system so that plan success or failure can be reliably determined.</p>
</div>
</div>
<div class="sect2">
<h3 id="_changes_and_abandonment"><a class="anchor" href="#_changes_and_abandonment"></a>3.13. Changes and Abandonment</h3>
<div class="paragraph">
<p>Inevitably, some plans will have to be changed or abandoned partway through due to unexpected changes in the patient situation. The question here is: what should be done with the remaining planned tasks that will not be performed? Should they be marked as 'won&#8217;t do' (with some reason) and committed to the EHR, or should they be deleted prior to being committed to the EHR?</p>
</div>
<div class="paragraph">
<p>It is assumed that the answer will differ according to circumstance and local preference, in other words, that planned tasks that are created are not necessarily written into the EHR, but may initially exist in a separate 'planned tasks' buffer, and are only committed when each task is either performed or explicitly marked as not done, or else included in a list of not-done Actions to be committed to the EHR at a point of plan abandonment.</p>
</div>
<div class="paragraph">
<p>The following kinds of abandonment of tasks should be supported:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>cancellation of an entire plan that has been posted to the EHR or a 'planning buffer' if one exists;</p>
</li>
<li>
<p>cancellation of a particular task on a list ahead of time, with a reason;</p>
</li>
<li>
<p>marking a task as 'did not perform' after the planned time has passed, with a reason.</p>
</li>
</ul>
</div>
</div>
<div class="sect2">
<h3 id="_rationalising_unrelated_work_plans"><a class="anchor" href="#_rationalising_unrelated_work_plans"></a>3.14. Rationalising Unrelated Work Plans</h3>
<div class="paragraph">
<p>It is assumed that at any moment there could be multiple plans extant for <em>different problems and timelines</em> for the same subject of care, e.g. chemotherapy, hypertension, ante-natal care. If naively created, these could clash in time and potentially in terms of other resources. There should therefore be support for being able to efficiently locate all existing plans and scan their times, states and resources. This aids avoiding clashes and also finding opportunities for rationalising and bundling tasks e.g. grouping multiple tasks into a single visit, taking bloods require by two protocols at the same sitting etc.</p>
</div>
<div class="paragraph">
<p>It should be possible to process multiple plans as part of interfacing with or constructing a 'patient diary', i.e. rationalised list of all work to be done involving the patient.</p>
</div>
</div>
<div class="sect2">
<h3 id="_support_process_analytics"><a class="anchor" href="#_support_process_analytics"></a>3.15. Support Process Analytics</h3>
<div class="paragraph">
<p>As tasks are performed and signed off on the list of posted planned tasks, there will generally be differences between Actions actually performed and the tasks on the list. Differences may include:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>time of execution - this will almost always be different, even if only by seconds;</p>
</li>
<li>
<p>performer - a task intended to be performed by a specific type of actor (say a nurse) might be performed by another (say the consultant);</p>
</li>
<li>
<p>any other modifiable detail of the order, e.g. medication dose in bedside care situations.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>These differences are obtainable from the EHR since both planned tasks and performed Actions will appear, providing a data resource for analysing business process, order compliance, reasons for deviation and so on.</p>
</div>
</div>
<div class="sect2">
<h3 id="_support_for_costing_and_billing_information"><a class="anchor" href="#_support_for_costing_and_billing_information"></a>3.16. Support for Costing and Billing Information</h3>
<div class="paragraph">
<p>It should be possible to record internal costing data against plans as a whole, and also individual tasks. Additionally, it should be possible to attach external billing information to tasks and plans. Costing information might be attached to each task, such as consumption of inventory items, time and other resources. Billing information is typically more coarse-grained and reported using nationally agreed code systems, e.g. ICD10 or similar.</p>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_design_principles"><a class="anchor" href="#_design_principles"></a>4. Design Principles</h2>
<div class="sectionbody">
<div class="paragraph">
<p>The following sections describe the design key ideas used in the Task Planning model defined in this specification.</p>
</div>
<div class="sect2">
<h3 id="_computational_basis"><a class="anchor" href="#_computational_basis"></a>4.1. Computational Basis</h3>
<div class="paragraph">
<p>A basic choice in the architecture presented here is that it is <em>executable</em> in the sense of all elements used in creating Plan definitions have an objective computational meaning and can be executed according to defined semantics. The intention is that developing task plans is a kind of high level programming, performed using dedicated tools, and whose resulting artefacts are executable. This does not of course mean that the resulting system performs the work (although it may contain software agents that perform some particular Tasks). Instead, it means that the resulting executable artefacts and application(s) when executed in a real world socio-technical environment that includes human and other actors, will convert disparate workers with weak communication and coordination into an efficient, integrated, team.</p>
</div>
<div class="paragraph">
<p>This follows the YAWL approach (<a href="#Hofstede_van_der_Aalst2009">Hofstede&#44; van der Aalst&#44; Adams&#44; &amp; Russell&#44; 2010</a>), such that no Plan defined according to this specification has ambiguous meaning.</p>
</div>
</div>
<div class="sect2">
<h3 id="_computation_context"><a class="anchor" href="#_computation_context"></a>4.2. Computation Context</h3>
<div class="paragraph">
<p>This specification describes the models and semantics for task plans and their execution by a notional openEHR Task Planning execution engine ('TP engine'). This is assumed to operate in a server computing environment in which other systems exist with which the TP engine communicates. A key system is the openEHR EHR system, via which openEHR EHRs are accessible to the TP Engine.</p>
</div>
<div class="paragraph">
<p>Outside of the environment exist other organisations with which TP engine communicates by generic means (ultimately, email, phone calls, etc), mediated by an appropriate communications / notification system within the environment.</p>
</div>
<div class="paragraph">
<p>Users who act as performers of tasks are connected to the engine via applications that communicate to the TP engine via the API of the TP Engine. These applications may be dedicated to Task Planning or a combined openEHR application context containing Task Planning components or forms. Users who act as plan designers are connected to a task planning designer system via a dedicated designer application.</p>
</div>
<div class="paragraph">
<p>The computational environment is shown below.</p>
</div>
<div id="computational_environment" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/computational_environment.svg" alt="computational environment" width="80%">
</div>
<div class="title">Figure 5. Computational Environment</div>
</div>
<div class="paragraph">
<p>One of the major differences between the openEHR Task Planning architecture compared to other workflow architectures is that it can rely on shared access to persistent patient EHRs as the location in which context data can be read (e.g. patient variables) and in which records of performed tasks are ultimately stored, in the form of openEHR Compositions containing Entries, in the usual way.</p>
</div>
<div class="sect3">
<h4 id="_separation_of_definition_and_execution"><a class="anchor" href="#_separation_of_definition_and_execution"></a>4.2.1. Separation of Definition and Execution</h4>
<div class="paragraph">
<p>One of the most basic tenets of workflow processing is assumed here, namely the clear separation of Plan definition and Plan execution. This specification distinguishes more than the usual two levels of representation, as follows:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Plan <em>template</em>, representing re-usable Plans and Plan components, from which Plan 'definitions' can be generated;</p>
</li>
<li>
<p>Plan <em>definition</em>, the concrete representation of a particular Plan that may be directly executed;</p>
</li>
<li>
<p>Plan <em>execution</em>, the execution of the plan, which may be long-lived, e.g. days, months, years;</p>
</li>
<li>
<p>Task execution, the runtime execution of part(s) of a Plan during user sessions, via use of applications etc.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The first level is implemented by Archetyping of the definition-level model defined in this specification.</p>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_conceptual_elements"><a class="anchor" href="#_conceptual_elements"></a>4.3. Conceptual Elements</h3>
<div class="sect3">
<h4 id="_work_plan"><a class="anchor" href="#_work_plan"></a>4.3.1. Work Plan</h4>
<div class="paragraph">
<p>The top-level formal concept defined is the <em>Work Plan</em>, which consists of one or more <em>Task Plans</em>. The Work Plan is a definition of work to be performed by one or more workers in order to achieve a defined goal with respect to a <em>single subject of care</em>. A different subject requires a different instance of a Work Plan. Goals are often defined by published guidelines or care pathways, and the overall structure of work defined within a Work Plan and its constituent Task Plans may well be structured according to such publications.</p>
</div>
<div class="paragraph">
<p>Within a Work Plan, each included Task Plan is a definition of work to be performed in a single work <em>context</em>, by a 'principal performer' and possibly other participants. Multiple Task Plans occur for two reasons:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>distinct performers working in different contexts, across which managed <em>hand-offs</em> are required;</p>
</li>
<li>
<p><em>sub-plans</em> subordinate to a parent Task Plan, to be performed by the same worker.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Sub-plans occur to allow re-use of Plans for smaller pieces of work and also to provide a means of controlling the detail level of work differently for performers of different experience levels.</p>
</div>
<div class="paragraph">
<p>The entirety of the Work Plan definition is assumed to be <em>executable within a single computational context</em> (i.e. a 'Task Planning engine'), in which methods of notification and worker communication are available, enabling the state of progress of the work defined in the Plan to be fully represented. A Work Plan will often be limited to a single enterprise, but this need not be the case, as long as all of its Task Plans communicate within the same Plan execution context.</p>
</div>
<div class="paragraph">
<p>More typically, some jobs required by a Work Plan are performed in another organisational context entirely, and from the point of view of the original Work Plan, the second organisation is seen as a 'black box' to which a request can be made and a result might be returned. A common example is a hospital clinical workflow that at some point requires a laboratory result, which is processed by an external organisation. These situations are handled by an 'external request' Task type.</p>
</div>
</div>
<div class="sect3">
<h4 id="_task_plan"><a class="anchor" href="#_task_plan"></a>4.3.2. Task Plan</h4>
<div class="paragraph">
<p>The actual definition of work to be done in one work context with a principal performer consists of Tasks stated within a Task Plan. The most basic structuring notion required is that of a sequential list of Tasks, enabling the representation of the set of steps in a typical linear workflow such as making tea or cleaning a wound.</p>
</div>
<div class="paragraph">
<p>However, in the real world, almost every job can be sub-divided into smaller pieces of work in a fractal nature. This simple fact requires that the general structure of Tasks is actually a hierarchy, within which sequential Task lists occur commonly (and will be the top-level structure in simple cases). The formal construct provided for this is the Task Group, which may contain Tasks and more Task Groups.</p>
</div>
<div class="paragraph">
<p>The Task concept defined in this specification is relatively straightforward in the abstract: it corresponds to a separately performable <em>item of work</em> for a <em>performer</em> to execute. A Task within a Plan has a lifecycle whose states indicate whether it is planned, available, complete etc.</p>
</div>
<div class="paragraph">
<p>In business terms, a Task typically corresponds to:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>an explicit level of clinical responsibility, e.g. nurse administration of a drug, single observation of patient vital sign etc;</p>
</li>
<li>
<p>an explicit level of re-imbursement / billing;</p>
</li>
<li>
<p>granularity of check-list and protocol single items, designed to be signed off as performed;</p>
</li>
<li>
<p>a particular planned time of execution.</p>
</li>
</ul>
</div>
<div class="sect4">
<h5 id="_parallel_and_sequential_execution"><a class="anchor" href="#_parallel_and_sequential_execution"></a>4.3.2.1. Parallel and Sequential Execution</h5>
<div class="paragraph">
<p>With hierarchy and sequential execution semantics, a great many types of work can be represented. However, some sets of Tasks can be performed without regard to order - i.e. in parallel. The model defined here therefore includes an execution type indicator at the Task Group level, so that manner of performing the work items within a Task Group - with or without regard to order - can be indicated. In purely sequential Task Plans, there is only one <em>execution path</em>. Parallel execution enables the possibility of multiple execution paths during a Plan execution.</p>
</div>
</div>
<div class="sect4">
<h5 id="_conditional_structures"><a class="anchor" href="#_conditional_structures"></a>4.3.2.2. Conditional Structures</h5>
<div class="paragraph">
<p>The power of the Task Group / Task structure can be significantly augmented in another dimension with the addition of conditions, to create <em>conditional structures</em>. These can be used to represent a variety of logical choice structures, equivalent to the following programming concepts:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><strong>if/elseif/else</strong>: a multi-branch logic chain with any condition on each branch, evaluated in order;</p>
</li>
<li>
<p><strong>switch</strong>: a multi-way logic structure based on a single condition and branches for multiple value sub-ranges;</p>
</li>
<li>
<p><strong>rule-set</strong>: a chained event-driven rule structure whereby each branch is defined to fire on reception of a specific kind of event.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>In a purely deterministic view of workflow, the above types of conditional structures correspond to the situation where the conditions are fully defined in the Plan, and execution unequivocally follows the paths according to the evaluation results of each condition. However, in a realistic system this is only one possible mode of execution, because the condition expressions might not always correctly represent reality, due to being approximate or simply deficient. In such cases, the user may need to <em>override</em> the ordinary execution path. This can easily happen in a clinical scenario, where the condition structure is defined as an attempt to represent <em>recommendations</em> that may be overridden by better knowledge on the part of the runtime user (e.g. an oncologist).</p>
</div>
<div class="paragraph">
<p>A third possibility exists as well: conditional pathways whose conditions are not encoded at all in the Plan definition, i.e. are only known by runtime users. Such 'ad hoc' conditional structures occur where no clear or simple algorithm can be stated for choosing each path. A typical example in a clinical situation is a physician determining the complex trade-off between efficacy and side-effects for which drug regime to use for a complex condition such as cancer.</p>
</div>
<div class="paragraph">
<p>There are thus three levels of human/system interaction with respect to conditional processing:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>fully automated</em>: formal conditions fully express the criteria for altenate paths;</p>
</li>
<li>
<p><em>decision support</em>: formal conditions are an attempt to provide support to users, but may be overridden;</p>
</li>
<li>
<p><em>ad hoc</em>: alternate pathways are defined, but the criteria for entry are provided by the user at execution time.</p>
</li>
</ul>
</div>
</div>
<div class="sect4">
<h5 id="_summary"><a class="anchor" href="#_summary"></a>4.3.2.3. Summary</h5>
<div class="paragraph">
<p>The leaf level constituents of a Task Plan are Tasks of various kinds, including inline-defined Tasks; requests to other contexts within the same Work Plan; requests to external contexts and requests to IT systems and services.</p>
</div>
<div class="paragraph">
<p>We can summarise the above-described structure in reverse:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><strong>Task</strong>: a separately performable unit of planned work at any level of granularity; may be defined inline or via sub-plan;</p>
</li>
<li>
<p><strong>Task Group</strong>: a group of Tasks and/or more Task Groups within a Task Plan that are to be executed on the same basis, e.g. sequential, parallel.</p>
</li>
<li>
<p><strong>conditional Group types</strong>: special kinds of Task Group that enable conditional logic structures to be represented in a Plan.</p>
</li>
<li>
<p><strong>Task Plan</strong>: a logical set of Tasks for a single performer context to achieve a defined result within a larger plan.</p>
</li>
<li>
<p><strong>Work Plan</strong>: top-level structure containing related Task Plans needed to implement an intended outcome for a subject of care.</p>
</li>
</ul>
</div>
</div>
</div>
<div class="sect3">
<h4 id="_graph_structure"><a class="anchor" href="#_graph_structure"></a>4.3.3. Graph Structure</h4>
<div class="paragraph">
<p>The Task Group construct replaces the node references found in traditional workflow formalisms such as BPMN, and defines the static graph structure of the 'normal flow' of a Task Plan <em>by implication</em>. Only exceptions to the normal flow are represented with explicit node references.</p>
</div>
<div class="paragraph">
<p>This provides significantly more power than an explicit graph structure for the normal flow, since Task Groups can have <em>rules</em> attached to them indicating which members should be executed and when, rather than relying on explicit links. The sequential / parallel indicator is one such simple rule. Additional rules could be added, such as:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>at least N members must complete for group to complete</p>
</li>
<li>
<p>exit group on first succeeding task</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>These more sophisticated rules are represented in a generic way, with the Task Plan engine assumed to implement the underlying mechanics.</p>
</div>
</div>
<div class="sect3">
<h4 id="_work_context"><a class="anchor" href="#_work_context"></a>4.3.4. Work Context</h4>
<div class="paragraph">
<p>A fundamental concept in this specification is <em>work context</em>, which is the factor that distinguishes one Task Plan from another, i.e. one Task Plan (and any sub-Task Plans) corresponds to Tasks to be performed in a single work context. Work context is defined as a single, <em>contiguous cognitive flow</em> in the real world (i.e. not in the computational representation, which must always be considered an approximation updated in snapshot fashion) in which work can be performed <em>seamlessly</em> by one or more performers on a single subject. Concretely, this means that the flow of cognitive activity is unbroken during the work. This may extend over time and even distinct physical spaces, such as in the case of tele-consultations. Normally a single cognitive flow corresponds to a single actor, usually a person, but this is not always the case. More than one person may be involved in performing work on the same subject, but essentially working as one, and relying on real-time verbal or other communication to achieve the effect of a <em>single mind</em>.</p>
</div>
<div class="paragraph">
<p>Continuous knowledge of the work, and continuous real-time communication with oneself ('train of thought') or directly among multiple performers is what characterises a given context. A different context is one with different cognitive actors, and within which communications are performed by notifications at certain time checkpoints, typically just the beginning and end.</p>
</div>
<div class="paragraph">
<p>Since parallelism is possible within a single Plan, a performer may be working on more than one thing at once, within the same context, for the subject. In other words, a work context (and a Task Plan in execution) may contain multiple execution paths at a point in time.</p>
</div>
</div>
<div class="sect3">
<h4 id="_context_switch_and_fork"><a class="anchor" href="#_context_switch_and_fork"></a>4.3.5. Context Switch and Fork</h4>
<div class="paragraph">
<p>If work has to be stopped within one context and passed to a different work context, a <em>context switch</em> is required, and the first worker or team will wait for a response. If the context switch is within the same Work Plan, it is termed a <em>hand-off</em>, which entails switching Task Plans. A context change is also required to request work from an environment external to the current Work Plan.</p>
</div>
<div class="paragraph">
<p>A second kind of change of control is a <em>context fork</em>, whereby the current performer signals to another context to start doing some work, but continues doing his own work.</p>
</div>
<div class="paragraph">
<p>A context switch is commonly known as 'block and wait' or <em>synchronous processing</em>, while a context fork is known as <em>asynchronous</em> or <em>parallel processing</em>.</p>
</div>
<div class="paragraph">
<p>The following diagram shows a taxonomy of task types that result from the above considerations.</p>
</div>
<div id="task_taxonomy" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/task_taxonomy.svg" alt="task taxonomy" width="50%">
</div>
<div class="title">Figure 6. Task Taxonomy</div>
</div>
<div class="paragraph">
<p>How does a hand-off actually work? There are two distinct scenarios. Consider a hand-off situation in which one worker is a radiographer taking images of the patient, and who once finished, will hand over to a radiologist, who will assess the images. In this case, the inputs required by the radiologist - the images - are immediately available online, so she can begin her work immediately. The hand-off can therefore be effected by means of notification to the radiologist. In terms of control flow, the radiologist (at least in situations like Emergency Department, acute stroke case) is driven by events: as soon as new images are ready, she works on them. Accordingly, in terms of Task Plans, when the radiographer has completed his Task Plan (doing the imaging), the radiologist is notified, and her acceptance of the work will cause the relevant Task Plan to be activated.</p>
</div>
<div class="paragraph">
<p>A second common scenario is typified by the first worker being a reception staff-member who receives a patient in a (non-emergency) clinic. When he has completed the usual appointment and administrative record check, he tells the patient to wait in the waiting area for the doctor. The hand-off to the doctor in this case entails the patient (i.e. the 'subject') being physically available when the doctor is ready, and the doctor having the patient visible on a list. The control flow in this case is: the second worker processes his patients from the queue, and will see a particular patient when they get to the head of the queue. Consequently, there is no point in notifying the doctor as such; instead, the latest patient is added to the queue, and seen by the doctor in his turn.</p>
</div>
<div class="paragraph">
<p>We can state the general question as being when the second worked in a hand-off should commence his work. It could be:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>immediately - this will be the case of a radiologist reviewing an MRI for an acute stroke;</p>
</li>
<li>
<p>when the worker is ready - e.g. the case where it&#8217;s a GP working through a list of patients in a waiting room;</p>
</li>
<li>
<p>when the patient arrives - e.g. when a patient is sent for a transfusion, the transfusion unit should start on the patient as soon as he/she appears in that part of the hospital.</p>
</li>
</ul>
</div>
</div>
<div class="sect3">
<h4 id="_context_continuity_over_worker_shifts"><a class="anchor" href="#_context_continuity_over_worker_shifts"></a>4.3.6. Context Continuity over Worker Shifts</h4>
<div class="paragraph">
<p>Work context is maintained during a <em>work session</em> during which the work is done by one or more performers. But if the work extends over hours or days (e.g. chemotherapy), worker shifts will end and the work will be taken up by the same or new workers on the next day. The Task Planning model does not consider this kind of worker replacement to be a context switch, since it is assumed that the Task Planning runtime system maintains all relevant context information, available for use by new workers. All that is required to maintain the context is for de-allocation and re-allocation of the work to the new (i.e. replacement) performers.</p>
</div>
</div>
<div class="sect3">
<h4 id="_principal_performer"><a class="anchor" href="#_principal_performer"></a>4.3.7. Principal Performer</h4>
<div class="paragraph">
<p>Following the notion of work context described above, a Task Plan is defined to have a <em>principle performer</em>, that is to say, a single logical executing actor. This is often a single person (or a device or possibly a software service), but might equally be a group of personnel, e.g. ward nurses, who execute the steps of a Task Plan during and across shift boundaries (wound dressing, turning patients, IV maintenance etc). In these cases the separate individuals constitute a 'single mind' as described above, with respect to the subject of care and the work, and their communication is not directly represented within the Task Plan.</p>
</div>
<div class="paragraph">
<p>In addition to the principal performer, other <em>participations</em> can be specified for any contained Task in a Plan. This allows the Plan to indicate where specific members working in a single cognitive work context should be responsible for specific individual Tasks. However it is assumed that the principal performer is <em>responsible</em> for all actions, and is also the notifier of action completions and cancellations.</p>
</div>
<div class="paragraph">
<p>The principal performer and other participants are specified in the Plan in terms of professional roles, and optionally a specific agent. This might in some cases be the patient.</p>
</div>
<div class="paragraph">
<p>Where an overall work plan requires separate actors who do not operate within the same work context, e.g. the various specialists and other professionals who perform different tasks with respect to an acute stroke patient, separate Task Plans each with their own principal performers are required. In this situation, coordination between the various actors is achieved by context switching and notification.</p>
</div>
<div class="paragraph">
<p>During the execution of a Task Plan, at any given time, a particular physical actor must be <em>assigned</em> as the principal performer, in order for the Plan to proceed. This assignment will change over time for long-running Plans, due to shift changes, out of hours contacts, worker vacations and so on. In this model, worker changes are handled by runtime <em>allocation</em> and are not treated as context switches. The allocation concept is described in more detail below.</p>
</div>
</div>
<div class="sect3">
<h4 id="_time_and_wait_states"><a class="anchor" href="#_time_and_wait_states"></a>4.3.8. Time and Wait States</h4>
<div class="paragraph">
<p>Many tasks in the real world can only be performed when certain events occur or conditions become true. This model treats such conditions as wait states, based on events or time.</p>
</div>
<div class="paragraph">
<p>Time is understood in three possible ways:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>as a <em>relative offset</em> from the start of the Plan timeline, when it is activated;</p>
</li>
<li>
<p>as an <em>absolute time</em> as marked on a calendar;</p>
</li>
<li>
<p>as the <em>moment at which an event occurs</em>.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The first two are converted to artificial events by the execution system internal clock reaching markers on the Work Plan timeline or calendar. For real event-based times, the kinds of events recognised include the following:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>timer event</em>: an event caused by a timer that expires;</p>
</li>
<li>
<p><em>state trigger</em>: a condition based on one or more watched variables available from the computation environment, including subject variables (sex, vital signs, etc) and variables relating to clinical processes, e.g. 'time since emergency admission'.</p>
</li>
<li>
<p><em>task transition</em>: an event generated by the state transition of a Task during execution so far, e.g. the previous Task completing;</p>
</li>
<li>
<p><em>callback notification</em>: an event generated by a notification received on completion of a Task dispatched to a different Plan or an external system;</p>
</li>
<li>
<p><em>system notification</em>: an external event is notified to the system by a user, e.g. receipt of a phone call.</p>
</li>
<li>
<p><em>manual notification</em>: an external event is signalled manually to the system by a user, e.g. receipt of a phone call.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Tasks can be defined to wait on either one or more events.</p>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_levels_of_definition_and_representation"><a class="anchor" href="#_levels_of_definition_and_representation"></a>4.4. Levels of Definition and Representation</h3>
<div class="paragraph">
<p>Task Plans are defined, refined and used in various phases in time. A number of related technical representations are used, each appropriate to its phase.</p>
</div>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 18.1818%;">
<col style="width: 27.2727%;">
<col style="width: 54.5455%;">
</colgroup>
<thead>
<tr>
<th class="tableblock halign-left valign-top">Phase</th>
<th class="tableblock halign-left valign-top">Representation</th>
<th class="tableblock halign-left valign-top">Purpose</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">Design time</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Definition model</strong><br>
                          (archetypes and templates<br>
                          of definition classes)</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">At the <em>model</em> level, a Work Plan and its constituent Task Plans are represented in the form of
                                                      openEHR templated archetype(s) based on the Task Planning definition model of this specification.</p>
<p class="tableblock">                                                      Multiple layers of modelling may be used to represent a range of Plan Templates from the more
                                                      general to the specific, and then templated to define a <em>near subject-specific Plan</em>. For example
                                                      a general model may be built to represent a chemotherapy Plan; a specalised form of this may
                                                      represent R-CHOP protocols; an even more specialised one may represent a particular institution&#8217;s
                                                      form of this protocol.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">Clinical time -<br>
 planning</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Instantiated definition</strong><br>
                         (= one subject)<br>
                         (instances of definition<br>
                          classes)</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">When a Work Plan model is <em>used</em> for a subject (i.e. patient), it is <em>instantiated</em> from its templated                                     archetypes, creating an instance of the Work Plan definition (i.e. in the class/instance sense).</p>
<p class="tableblock">                                                      At instantiation time, Task Plans re-used by reference within a Work Plan at the archetype level are instantiated as <em>distinct instances</em> for each such reference.</p>
<p class="tableblock">                                                      After Work Plan instantiation, the planner may adjust it in any way that maintains conformance with its archetypes and template, e.g. to provide values for particular parts of the model such as medication dosages, that correspond to the particular subject.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">Clinical time -<br>
 plan execution</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Materialised definition</strong><br>
                         (= one run)<br>
                         (instances of<br>
                         definition<br>
                         materialised classes,<br>
                         persisted over sessions)</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Close to Plan execution time, a Work Plan definition will be <em>materialised</em>, i.e. instantiated
                                                      for execution. At the point of materialisation, the definition model must be published and persisted, guaranteeing the its availability as the reference model for its materialised expressions. It may be materialised any number of times, corresponding to the distinct number of instances of use required.</p>
<p class="tableblock">                                                      In the materialised form, repeatable sections of the definition are 'unfolded' into literal sections,
                                                      for as many repetitions as required by the relevant performer(s). Accordingly, parts of the materialised expression of a Plan may have an N:1 relationship with the original definition form.</p>
<p class="tableblock">                                                      Unreachable decision paths may be removed, and where possible decision nodes, simplifying the materialised form compared to the definition form.</p>
<p class="tableblock">                                                      The materialised form has its own class model containing additional data items to enable run-time tracking
                                                      of the Plan as it is performed. During execution time, various kinds of deletions and modifications to the materialised representation are possible, corresponding to changes in plan that respond to unexpected events.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">Clinical time -<br>
 task execution</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>Runtime instantiation</strong><br>
                        (instances of<br>
                         materialised classes,<br>
                         during session)</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Since a Plan execution may run over many hours, days or longer, the materialised expression will in
                                                     general correspond to something larger than the literal in-memory instantiation of (parts of) the Plan required during any given user-application session during which some or all of the Task Plan might be performed. The part of the plan currently being displayed, performed, tracked etc, is known here as the 'run-time instantiation', and consists of a subset of the total materialised form instances.</p></td>
</tr>
</tbody>
</table>
<div class="sect3">
<h4 id="_phases_of_work"><a class="anchor" href="#_phases_of_work"></a>4.4.1. Phases of Work</h4>
<div class="paragraph">
<p>In this scheme, archetype- and template-based modelling is used as much as possible during the design phase, in order to create a hierarchy of re-usable models that are progressively more specialised, until close-to-patient models are achieved, typically as templates. This enables the power of the archetype modelling formalism, including specialisation and composition to be used freely, in a similar manner to an object-oriented programming environment.</p>
</div>
<div class="paragraph">
<p>When the design phase is complete, a Work Plan template may be instantiated by a clinical planner in the <em>planning</em> phase, to create definitions instances that are stored in a Composition in the patient EHR. During this phase, adjustments to the definition. Multiple workers may undertake such modifications, which may be performed over some time. At any given time, a particular patient EHR may contain multiple Work Plan definitions.</p>
</div>
<div class="paragraph">
<p>When a Work Plan is ready, the execution phase can begin, done by materialising the Plan definition from the EHR into the TP Engine, where it can be executed. It is the materialised expression of a Plan that is used to record all Plan-related actions by Task performers.</p>
</div>
<div class="paragraph">
<p>A Plan 'execution' may be long-lived, and extend beyond worker sessions in individual application invocations. The execution state will therefore be persisted for such Plans. During the execution phase, multiple <em>runtime executions</em> will occur, during which some part of the Plan will actually execute with the relevant users (i.e. performers) and applications.</p>
</div>
<div class="paragraph">
<p>As the work is performed in the execution phase, the results are documented with openEHR Entries, such as Actions and Observations.</p>
</div>
<div class="paragraph">
<p>The following figure illustrates these phases of work and the series of representations of Work Plans as they progress from archetyped models to runtime executions.</p>
</div>
<div id="tp_modelling_wf" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/tp_modelling_wf.svg" alt="tp modelling wf">
</div>
<div class="title">Figure 7. TP Modelling Workflow</div>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_execution_concepts"><a class="anchor" href="#_execution_concepts"></a>4.5. Execution Concepts</h3>
<div class="sect3">
<h4 id="_plan_execution_lifecycle"><a class="anchor" href="#_plan_execution_lifecycle"></a>4.5.1. Plan Execution Lifecycle</h4>
<div class="paragraph">
<p>A Work Plan definition can be executed by being materialised. The model recognises three states in the execution phase, as follows.</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code>materialised</code> state: after creation of the materialised Plan, the Plan may be modified by its user(s), and pre-allocations done of performers.</p>
</li>
<li>
<p><code>activated</code> state: the materialised Plan is <em>activated</em> when the users want to proceed. Connections must be established between the Plan execution context and various channels or APIs via which performer allocation and communication can be achieved. Activation establishes the zero point of the execution clock, and will cause performer allocations and generate various kinds of notifications as time moves forward. During the work, Tasks become <em>available</em> as earlier Tasks are completed or cancelled. When a Task is available to be done, the performer has various options, including doing the work, cancelling the Task as not needed, completing the Task, aborting it, and abandoning the current Task Plan.</p>
</li>
<li>
<p><code>terminated</code> state: A Work Plan terminates when a path taken through the materialised Task graph terminates, either due to finishing, or due to abandonment at an intermediate Task. The Work Plan as a whole returns a termination status of success or fail, which may be used to control behaviour if it is part of a chain in which a context switch follows termination.</p>
</li>
</ul>
</div>
</div>
<div class="sect3">
<h4 id="_allocation"><a class="anchor" href="#_allocation"></a>4.5.2. Allocation</h4>
<div class="paragraph">
<p>Since a Task in a Task Plan being executed at runtime represents the Plan execution system&#8217;s knowledge of some work being performed in the real world, a way to connect the Plan as it is in the system (e.g. as shown on a UI application, or via notifications such as instant messaging) to the real-world actors performing it is needed. Following YAWL, the architecture described here treats <em>allocation</em> of work to a performer as a formal activity during Plan execution.</p>
</div>
<div class="paragraph">
<p>Conceptually, worker allocation is understood in the following way. Firstly, it is assumed that Tasks can be allocated to two types of worker resource:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>individuals, specified in the Plan definition in terms of role and/or function within <em>principal performer</em> and <em>other participations</em> e.g. 'cardiologist';</p>
</li>
<li>
<p>a worker <em>pool</em>, i.e. group of equivalent workers, e.g. nurses on a particular ward; here, any one of the workers can perform a given Task, and the workers may swap over time.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Secondly, at runtime, the actual worker will be resolved at execution time as follows:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>the Plan or Task is <em>assigned</em> to a real individual or worker pool;</p>
</li>
<li>
<p>an appropriate worker <em>claims</em> a Plan (if Plans are posted somewhere, awaiting workers) or <em>accepts</em> the Task (if Plan invitations are sent to individuals).</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>It remains the business of the organisation and also the Task Planning engine to resolve how these choices are made.</p>
</div>
<div class="paragraph">
<p>As per YAWL, more sophisticated implementations of Task Planning may offer numerous allocation strategies, such as first-available, quickest-to-complete, least-frequently-used and so on.</p>
</div>
</div>
<div class="sect3">
<h4 id="_task_lifecycle"><a class="anchor" href="#_task_lifecycle"></a>4.5.3. Task Lifecycle</h4>
<div class="paragraph">
<p>Every Task in a Plan has a lifecycle described by a state machine. The states represent the state of a real world item of work, <em>as known by the Plan execution system</em>; setting them is entirely reliant on the system receiving input from performers. The successful execution path is through the states <code>planned</code> &#8658; <code>available</code> &#8658; <code>completed</code>, with other terminal states <code>cancelled</code> and <code>aborted</code> available for cases where a Task is cancelled and aborted respectively. Here, <code>cancelled</code> means 'not needed', i.e. the principal performer determined Task could be cancelled before or during execution, without compromising the Plan. Conversely, the <code>aborted</code> state indicates that the performer cannot do or complete the Task, or the rest of the Plan. Thus, <code>aborted</code> for a Task means abandonment of the current Task Plan.</p>
</div>
<div class="paragraph">
<p>From the viewpoint of Plan execution, the final state of a Task execution determines whether the Plan remaints in the <code>active</code> state, or whether it enters the <code>terminated</code> state. If the Task terminates with <code>completed</code> or <code>cancelled</code> state, it is considered to have <em>succeeded</em>, and the Plan remains <code>active</code>. If the Task is <code>aborted</code>, it is considered as <em>failed</em>, and the Plan terminates with a failure status.</p>
</div>
<div class="paragraph">
<p>A special transition <code><em>override</em></code> is used to force a Task to into the <code>available</code> state; this represents a performer explicitly overriding preconditions or subject preconditions.</p>
</div>
</div>
<div class="sect3">
<h4 id="_availability"><a class="anchor" href="#_availability"></a>4.5.4. Availability</h4>
<div class="paragraph">
<p>A Task becomes <em>available</em> to perform when three kinds of condition are met:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Execution control flow reaches the Task;</p>
</li>
<li>
<p>Any waited-on external event occurs;</p>
</li>
<li>
<p>Subject preconditions if any, are met.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Control flow reaches a Task in a Plan when either preceding Tasks have been performed (local control flow) or a previously dispatched external Task completes, whose restart location in the current Plan is the current Task.</p>
</div>
<div class="paragraph">
<p>External preconditions (described above) are met when a point in clock time is reached or an event notification is received.</p>
</div>
<div class="paragraph">
<p>If the control flow and external preconditions are met, a Task will still not be available until any subject-related preconditions are satisfied. These are conditions that may be specified to ensure the Task is only performed if it is clinically appropriate and safe to do so, such as 'systolic blood pressure &lt; 160 mmHg'.</p>
</div>
<div class="paragraph">
<p>Since the Task Plan cannot presume to have perfect knowledge of the real world situation, the performer is always allowed to override the external and subject pre-conditions, due to better knowledge. In such cases, the control flow requirement still holds - since this can already be 'overridden' by the performing cancelling preceding Tasks where appropriate.</p>
</div>
<div class="paragraph">
<p>When a Task does become available for execution, nothing will happen until a performer is allocated to do it. When an available worker is allocated, the Task may be commenced, and further life-cycle states can be reached, i.e. <code>completed</code>, <code>aborted</code> etc.</p>
</div>
<div class="paragraph">
<p>The following diagram illustrates these concepts.</p>
</div>
<div id="task_availability" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/task_availability.svg" alt="task availability" width="55%">
</div>
<div class="title">Figure 8. Task Availability</div>
</div>
</div>
<div class="sect3">
<h4 id="_adaptive_modification_and_exception_handling"><a class="anchor" href="#_adaptive_modification_and_exception_handling"></a>4.5.5. Adaptive Modification and Exception-handling</h4>
<div class="paragraph">
<p>One of the major challenges for any workflow system is that of being able to handle unplanned exceptions at runtime and adapt. The Task Planning model makes a key assumption that simplifies deviations at runtime, which is that the human (or other) performer always knows best. This means that Tasks posted to be done by the system are always advisory, and their details (such as time) are advisory. Accordingly, the model provides the following support for execution-time adaption:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>logical deletion</em>: Tasks can be skipped by two types of cancellation in the lifecycle: <code>cancelled</code> (not needed) and <code>aborted</code> (abandon current Task Plan); if <code>cancelled</code> is used, this has the benign effect of skipping past a Task;</p>
</li>
<li>
<p><em>logical addition</em>: work items that are not represented as Tasks in a Task Plan can always be done, such as making extra patient observations or performing unplanned patient actions (e.g. refit a catheter, change a dressing); in openEHR they will always be recorded in the normal manner via Observation and Action Entries;</p>
</li>
<li>
<p><em>overrides</em>: various aspects of a Plan definition can be overridden at runtime, such as Task execution time and subject preconditions (such as BP &lt; 160 mm[Hg]). Override is represented in the system as an alternative lifecycle transition that puts a Task into the <code>available</code> state even if not all conditions have been met for availability.</p>
</li>
</ul>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_relationship_of_tasks_with_existing_openehr_entry_types"><a class="anchor" href="#_relationship_of_tasks_with_existing_openehr_entry_types"></a>4.6. Relationship of Tasks with existing openEHR Entry Types</h3>
<div class="paragraph">
<p>Within the phases of clinical planning and execution time described above, the Task Plan is not the only information artefact that may be created. The existing openEHR model <code>ENTRY</code> types provide the standard way to represent orders, via <code>INSTRUCTION</code>, and order-related performed activities, via <code>ACTION</code>. In addition, the usual <code>OBSERVATION</code>, <code>EVALUATION</code> and <code>ADMIN_ENTRY</code> types are used to record observations, diagnoses, and administrative events as they occur in clinical time. In abstract terms, Instructions may be understood as formal statements of 'what is to be done', and the other types, as records of 'what was done'. However, Instructions are most suited to concise representations of orderable actions, particularly medication administration, but not for general purpose detailed plans of events. The addition of Task Plans provides a way to specify such plans more flexibly, and in a step-by-step manner.</p>
</div>
<div class="paragraph">
<p>Both Instructions and Plans may be fully or partially defined by care pathways and/or guidelines, equally, they may be ad hoc developed in the 'old school medicine' sense. The following figure illustrates the relationships among care pathways, the existing openEHR Entry types and Task Plans.</p>
</div>
<div id="planning_artefact_relationships" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/planning_artefacts.svg" alt="planning artefacts" width="50%">
</div>
<div class="title">Figure 9. openEHR Planning Artefact Relationships</div>
</div>
<div class="paragraph">
<p>In simple cases, a Task Plan may just be the list of Tasks to fulfill one order, i.e. a single <code>INSTRUCTION</code> prescribing a course of antibiotics. The general case however is that the Work Plan corresponds to a clinical goal which implicates multiple orders, such as the CHOP chemotherapy mentioned above.</p>
</div>
<div class="paragraph">
<p>Consequently, <em>not every Task in a Work Plan is associated with an order</em>, illustrated by the yellow Task objects in the above figure. While a typical case is that a Task corresponds to an openEHR <code>ACTION</code> that has not yet been recorded (and which normally has a driving <code>INSTRUCTION</code>), it may also correspond to an <code>ACTION</code> that has no <code>INSTRUCTION</code> or indeed an <code>OBSERVATION</code> or possibly an <code>EVALUATION</code> (perhaps some kind of check during a procedure). Indeed, there is also no reason why a Task Plan cannot consist of Tasks that define administrative work and would be documented with openEHR <code>ADMIN_ENTRYs</code>.</p>
</div>
<div class="paragraph">
<p>We can infer from the above that the main driver of a Task Plan isn&#8217;t in general an order, but a care plan or guideline that usually includes orders, or else plain old ad hoc planning.</p>
</div>
<div class="paragraph">
<p>A high-level view of how clinical work generates openEHR information can be visualised conceptually with a modified version of the <a href="https://specifications.openehr.org/releases/RM/latest/ehr.html#_information_ontology">Clinical Investigator process diagram</a> as follows:</p>
</div>
<div id="clinical_process_planning" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/clinical_process_planning.svg" alt="clinical process planning" width="70%">
</div>
<div class="title">Figure 10. Clinical Investigator Process with Planning</div>
</div>
<div class="paragraph">
<p>According to this scheme, <code>WORK_PLAN</code>, <code>TASK_PLAN</code> and <code>TASK</code> are new types of information that can be committed to the EHR.</p>
</div>
</div>
<div class="sect2">
<h3 id="_order_semantics_versus_plan_semantics"><a class="anchor" href="#_order_semantics_versus_plan_semantics"></a>4.7. Order Semantics versus Plan Semantics</h3>
<div class="paragraph">
<p>Despite the above explanation, the difference between Instructions (as defined in openEHR) and Task Plans may not be completely clear. However, there is a key difference, which is the semantic level at which the two are expressed. A typical order, represented in an openEHR <code>INSTRUCTION</code> has an <em>algorithmic</em> form, such as  "Amoxicillin 3 times a day, orally, for 7 days". Although healthcare professionals do not typically think about it, this expression is in fact a small program that is mentally <em>interpreted</em> to produce resultant actions such as giving one tablet at 9:15 am, one at lunch and so on.</p>
</div>
<div class="paragraph">
<p>We can think of a Task Plan for ordered actions as the interpreted form of the original order statement(s), that is to say, a completely 'unfolded' list of single Tasks in time such as 'give 1 Amoxycillin oral tab at lunch'. This is a form suitable for displaying on work lists, checking off and ensuring no mistakes are made. When a Task is performed, it will still give rise to the appropriate openEHR Entry recording the details, such as 'gave 1 Amoxycillin tab at 13:37'.</p>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_task_planning_model_overview"><a class="anchor" href="#_task_planning_model_overview"></a>5. Task Planning Model Overview</h2>
<div class="sectionbody">
<div class="paragraph">
<p>This section and the following one describe the Task Planning model in technical detail. Most of the emphasis is on the 'definition' level of expression, with most details of the 'materialised' and 'runtime' expressions left to implementers. Throughout these sections, a version of the <a href="https://specifications.openehr.org/releases/PROC/Release-1.5.0/tp_vml.html" target="_blank" rel="noopener">Task Planning Visual Modelling Language (TP-VML)</a> is used to illustrate instance structures. This visual language is designed to be formally aligned to the semantics of the model.</p>
</div>
<div class="paragraph">
<p>The following UML diagram shows the <code>rm.task_planning</code> package in overview form, showing the constituent packages, <code>definition</code>, <code>materialised</code>, and <code>history</code>. The first of these packages contains the class model for the <em>definition model</em> expression of a Work Plan, i.e. the workflow structure intentionally designed to achive a goal.</p>
</div>
<div class="paragraph">
<p>The <code>materialised</code> package contains the class model of the materialised form of the definition, which is created prior to its use in execution. The materialised model is presented in outline only, as a way of indicating some of the general features of the materialised form, and is not intended to be normative. (At some point in the future, a skeleton materialised model may be declared normative, based on implementation experience).</p>
</div>
<div class="paragraph">
<p>The <code>history</code> package contains the model of audit events that have occurred to each Task Plan in a Work Plan during execution.</p>
</div>
<div id="proc_task_planning_overview" class="imageblock text-center text-center">
<div class="content">
<img src="UML/diagrams/PROC-task_planning-overview.svg" alt="PROC task planning overview">
</div>
<div class="title">Figure 11. rm.task_planning package overview</div>
</div>
<div class="paragraph">
<p>The following instance diagram illustrates the relationships among these models for one Task Plan. On the left is a Task Plan definition, consisting of a Task Group and various Defined Actions. Each of these Tasks may have a prototype Entry attached, which represents the intended data of an Action, Observation or other Entry that the Task defines.</p>
</div>
<div class="paragraph">
<p>In the centre is a materialised Task Plan, which is an execution-time structure used to maintain state for an executing Plan. This structure allows the representation of all state to do with Plan execution, including instances of variables, timing information and so on. The materialised structure is not owned by the definition structure, but rather is created at run time, and points back to its definition via various references. The right hand side of the diagram shows a part of the materialised structure that is currently instantiated within a user-application session.</p>
</div>
<div class="paragraph">
<p>At the lower right is a Task Plan Execution History, which is a record of all events that were made during the execution of the original Task Plan.</p>
</div>
<div id="task_planning_overview" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/task_planning_overview.svg" alt="task planning overview" width="65%">
</div>
<div class="title">Figure 12. Task planning overview</div>
</div>
<div class="sect2">
<h3 id="_identification_and_referencing"><a class="anchor" href="#_identification_and_referencing"></a>5.1. Identification and Referencing</h3>
<div class="paragraph">
<p>With a Task Plan, various elements need to be referenceable at runtime. Tasks and Task Groups are identified via the <code><em>uid</em></code> attribute inherited from <code>LOCATABLE</code> via <code>PLAN_ITEM</code>, and which is populated with a Guid. References to a Task or Task Group are thus achieved with <code>UID_BASED_ID</code> instances carrying a Guid.</p>
</div>
</div>
<div class="sect2">
<h3 id="_plan_data_context"><a class="anchor" href="#_plan_data_context"></a>5.2. Plan Data Context</h3>
<div class="paragraph tbd">
<p>TBD: this section needs to be upgraded to latest EL and BMM model. The type <code>EXPR_TYPE_DEF</code> will be replaced by a BMM equivalent.</p>
</div>
<div class="paragraph">
<p>A Task Plan may contain logical <em>symbolic values</em> of various kinds, including <em>constants</em>, <em>variable references</em> and <em>expressions</em>, which are used in within the Plan structure. These are globally collated and tracked at runtime at the Work Plan level, i.e. in common to all Task Plans. Each context value has a symbolic name (<code>CONTEXT_VALUE.<em>name</em></code>), a type from within the openEHR type system (<code>EXPR_TYPE_DEF</code>).
The following UML diagram illustrates.</p>
</div>
<div id="proc_task_planning_context" class="imageblock text-center text-center">
<div class="content">
<img src="UML/diagrams/PROC-task_planning.definition-context.svg" alt="PROC task planning.definition context">
</div>
<div class="title">Figure 13. Task planning - context values</div>
</div>
<div class="paragraph">
<p>An instance of <code>PLAN_DATA_CONTEXT</code> represents the full set of tracked variables and expressions used in a Work Plan, which are either  atomic <em>variables</em> or <em>constants</em>, or else <em>expressions</em> that reference such variables, respectively represented by the classes <code>CONTEXT_VARIABLE&lt;T&gt;</code>, <code>CONTEXT_CONSTANT&lt;T&gt;</code> and <code>CONTEXT_EXPRESSION&lt;T&gt;</code>. These classes and the abstract parent are generic, with the parameter being the formal type of variable or expression.</p>
</div>
<div class="paragraph">
<p>Context variables are typically related to subject state, such as patient vital signs, key demographic characteristics and so on, or the clinical care process, such as the 'time since stroke event', while expressions are used to represent logical expressions such as <code>$bp_systolic - $bp_diastolic</code>, where <code>$bp_systolic</code> and <code>$bp_diastolic</code> are defined as single variables. The syntax of expressions is defined by the <a href="https://specifications.openehr.org/releases/LANG/latest/expression_language.html">openEHR Expression language</a>.</p>
</div>
<div class="paragraph">
<p>Two types of context variable are distinguished: external and local, represented by <code>EXTERNAL_VARIABLE&lt;t&gt;</code> and <code>LOCAL_VARIABLE&lt;T&gt;</code>. The former represent values of entities outside the task planning environment, and are written to via a <code><em>populating_request</em></code> which uses some method (such as EHR querying, API calls) to obtain the relevant external value. They are accordingly not writable from within the Work Plan.</p>
</div>
<div class="paragraph">
<p>There are two types of external variables - 'event' and 'state', which distinguish the update basis. An Event variable is 'watched' by some technical means, and its value is updated whenever it changes. The <code>CONTINUOUS_EVENT_VARIABLE</code> specialised type can be used for managing updates of continuous valued variables (i.e. real values) such that changes below a certain threshold, say 2% do not register.</p>
</div>
<div class="paragraph">
<p>Local variables are internal to the Work Plan, and can be read and written to by expressions used within Tasks in the Plan.</p>
</div>
<div class="sect3">
<h4 id="_class_descriptions"><a class="anchor" href="#_class_descriptions"></a>5.2.1. Class Descriptions</h4>
<div class="sect4">
<h5 id="_plan_data_context_class"><a class="anchor" href="#_plan_data_context_class"></a>5.2.1.1. PLAN_DATA_CONTEXT Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>PLAN_DATA_CONTEXT</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Container for all variable definitions used in the Task Plan.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>variables</strong>: <code>List&lt;CONTEXT_VARIABLE&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>List of all variables tracked by this Plan.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>expressions</strong>: <code>List&lt;CONTEXT_EXPRESSION&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>List of all expressions used in the Plan, based on tracked variables.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>constants</strong>: <code>List&lt;CONTEXT_CONSTANT&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>List of all constants used in the Plan.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_context_valuet_class"><a class="anchor" href="#_context_valuet_class"></a>5.2.1.2. CONTEXT_VALUE&lt;T&gt; Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong><em>CONTEXT_VALUE&lt;T&gt; (abstract)</em></strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Any kind of value used in the Plan definition. Typed by the formal type of the value, i.e. Boolean, Integer etc. The types are represented by <code>EXPR_TYPE_DEF</code> descendants.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>name</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Name of variable, as used in precondition and decision expressions.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>type</strong>: <code>T</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Type of this variable.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_context_constanttt_class"><a class="anchor" href="#_context_constanttt_class"></a>5.2.1.3. CONTEXT_CONSTANT&lt;TT&gt; Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>CONTEXT_CONSTANT&lt;TT&gt;</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Definition of a symbolic constant value that can be used in Context Expressions.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>CONTEXT_VALUE</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>value</strong>: <code>Any</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Value of the constant.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_context_variablett_class"><a class="anchor" href="#_context_variablett_class"></a>5.2.1.4. CONTEXT_VARIABLE&lt;TT&gt; Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong><em>CONTEXT_VARIABLE&lt;TT&gt; (abstract)</em></strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Any kind of symbolic variable that can be used within Expressions in the Task Plan, including in pre-conditions and decision pathways.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>CONTEXT_VALUE</code></p></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_external_variablett_class"><a class="anchor" href="#_external_variablett_class"></a>5.2.1.5. EXTERNAL_VARIABLE&lt;TT&gt; Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong><em>EXTERNAL_VARIABLE&lt;TT&gt; (abstract)</em></strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>A variable that carries a value from the external environment, including patient variables, and has a method of being populated. Cannot be written to from within the TP environment.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>CONTEXT_VARIABLE</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>populating_request</strong>: <code>SYSTEM_CALL</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional specification of a system request that would populate a context variable.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_local_variablett_class"><a class="anchor" href="#_local_variablett_class"></a>5.2.1.6. LOCAL_VARIABLE&lt;TT&gt; Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>LOCAL_VARIABLE&lt;TT&gt;</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Variable that is used locally within the Work Plan, and can be used to transmit information to sub-plans.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>CONTEXT_VARIABLE</code></p></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_event_variablett_class"><a class="anchor" href="#_event_variablett_class"></a>5.2.1.7. EVENT_VARIABLE&lt;TT&gt; Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>EVENT_VARIABLE&lt;TT&gt;</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Variable whose value is required to be the latest; ideally, updating would be implemented by listener model.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>EXTERNAL_VARIABLE</code></p></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_continuous_event_variablett_class"><a class="anchor" href="#_continuous_event_variablett_class"></a>5.2.1.8. CONTINUOUS_EVENT_VARIABLE&lt;TT&gt; Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>CONTINUOUS_EVENT_VARIABLE&lt;TT&gt;</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Dynamically updated variable of any continuous type whose value may change by arbitrarily small amounts. The <code><em>update_variation</em></code> attribute may be used to control updating frequency.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>EVENT_VARIABLE</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>update_variation</strong>: <code>Real</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Minimum percentage variation from current value to be considered a change that should cause an update.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_state_variablett_class"><a class="anchor" href="#_state_variablett_class"></a>5.2.1.9. STATE_VARIABLE&lt;TT&gt; Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>STATE_VARIABLE&lt;TT&gt;</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Variable that is updated by polling, and is regarded as correct as long as the last update occurred at or more recently than the required currency.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>EXTERNAL_VARIABLE</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>required_currency</strong>: <code>Iso8601_duration</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Required currency of data in target system (e.g. EHR) to be considered valid in the context of this Task.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_context_expressiontt_class"><a class="anchor" href="#_context_expressiontt_class"></a>5.2.1.10. CONTEXT_EXPRESSION&lt;TT&gt; Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>CONTEXT_EXPRESSION&lt;TT&gt;</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>An expression that references one or more context variables. At run time, Context Expressions are updated when changes to their dependent variables are detected.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>CONTEXT_VALUE</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>expression</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Expression, in openEHR Expression syntax.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_boolean_context_expression_class"><a class="anchor" href="#_boolean_context_expression_class"></a>5.2.1.11. BOOLEAN_CONTEXT_EXPRESSION Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>BOOLEAN_CONTEXT_EXPRESSION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Boolean-valued form of <code>CONTEXT_EXPRESSION</code>.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>CONTEXT_EXPRESSION</code></p></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_system_calls"><a class="anchor" href="#_system_calls"></a>5.3. System Calls</h3>
<div class="paragraph">
<p>The <code>SYSTEM_CALL</code> class and its descendants provide a way to represent a call to any service or interface available within the computing environment. The class attributes are designed to carry sufficient meta-data such that a call invocation module or plug-in in the Task Planning execution environment can convert the call to a concrete form (e.g. a REST or RPC call) and then execute it.</p>
</div>
<div class="sect3">
<h4 id="_generic_api_calls"><a class="anchor" href="#_generic_api_calls"></a>5.3.1. Generic API calls</h4>
<div class="paragraph">
<p>The representation of a generic API call is via the <code>API_CALL</code> class, while the <code>QUERY_CALL</code> class provides a way to represent a call to a query service.</p>
</div>
<div class="paragraph">
<p>For generic API calls, the assumed model of calling is as follows: when the call is invoked, all required parameters are passed; these are obtained from two sources:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>context values</em>: context values, Work Plan built-in variables (see below);</p>
</li>
<li>
<p><em>fixed parameters</em>: parameters whose value is fixed from the point of view of the Plan definition.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The first is specified via the <code><em>parameter_map</em></code> attribute, which defines the mapping between the external call parameter names and the names of variables that will be used to populate them at invocation. For example, assume there is an API call in a clinical decision support service with the following signature, which is to be used in a Task Plan:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="ts"><span></span>    <span class="tok-nx">cds_calc_risk</span> <span class="tok-p">(</span>
        <span class="tok-nx">riskType</span>:    <span class="tok-kt">String</span><span class="tok-p">;</span>
        <span class="tok-nx">sex</span>:         <span class="tok-kt">CodedText</span><span class="tok-p">;</span>
        <span class="tok-nx">dateOfBirth</span>: <span class="tok-kt">Iso8601Date</span><span class="tok-p">;</span>
        <span class="tok-nx">isSmoker</span>:    <span class="tok-kt">Boolean</span><span class="tok-p">;</span>
    <span class="tok-p">)</span><span class="tok-o">:</span> <span class="tok-nx">Real</span></code></pre>
</div>
</div>
<div class="paragraph">
<p>The <code><em>parameter_map</em></code> attribute of the <code>SYSTEM_CALL</code> instance will contain the following, where the left hand item in each case is the name of a Work Plan context value (i.e. variable, expression or constant):</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="json"><span></span>    <span class="tok-p">{</span>
        <span class="tok-nt">&quot;parameter_map&quot;</span><span class="tok-p">:</span> <span class="tok-p">[</span>
            <span class="tok-p">{</span><span class="tok-nt">&quot;context_name&quot;</span><span class="tok-p">:</span> <span class="tok-s2">&quot;subject_sex&quot;</span><span class="tok-p">,</span>        <span class="tok-nt">&quot;name&quot;</span><span class="tok-p">:</span> <span class="tok-s2">&quot;sex&quot;</span><span class="tok-p">},</span>
            <span class="tok-p">{</span><span class="tok-nt">&quot;context_name&quot;</span><span class="tok-p">:</span> <span class="tok-s2">&quot;subject_dob&quot;</span><span class="tok-p">,</span>        <span class="tok-nt">&quot;name&quot;</span><span class="tok-p">:</span> <span class="tok-s2">&quot;dateOfBirth&quot;</span><span class="tok-p">},</span>
            <span class="tok-p">{</span><span class="tok-nt">&quot;context_name&quot;</span><span class="tok-p">:</span> <span class="tok-s2">&quot;tobacco_use_status&quot;</span><span class="tok-p">,</span> <span class="tok-nt">&quot;name&quot;</span><span class="tok-p">:</span> <span class="tok-s2">&quot;isSmoker&quot;</span><span class="tok-p">}</span>
        <span class="tok-p">]</span>
    <span class="tok-p">}</span></code></pre>
</div>
</div>
<div class="paragraph">
<p>This tells the Task Plan execution system to inject the current value of the context variable <code>subject_sex</code> into the location where the <code>sex</code> parameter is expected and so on.</p>
</div>
<div class="paragraph tbd">
<p>TBD: we may need to allow functions, so that data type/structure conversions can be managed.</p>
</div>
<div class="paragraph">
<p>The second type of parameter is a fixed value, which enables the System call to represent the external call in a preferred way. An example of this is a general API call such as <code>cds_check (type: String, other_args, &#8230;&#8203;)</code> might be used from within the Task Plan with the first argument fixed in each case, to form specific invocations, e.g. <code>cds_check ("hypertension risk", other_args, &#8230;&#8203;)</code>, <code>cds_check ("diabetes type 2 risk", other_args, &#8230;&#8203;)</code> etc. Fixed parameters are represented in the <code><em>bound_parameters</em></code> attribute of a <code>SYSTEM_CALL</code> instance.</p>
</div>
<div class="paragraph">
<p>The total set of parameters for any System call is provided by the combination of the contents of the <code><em>parameter_map</em></code> and <code><em>bound_parameters</em></code> attributes, where either may be empty.</p>
</div>
</div>
<div class="sect3">
<h4 id="_query_calls"><a class="anchor" href="#_query_calls"></a>5.3.2. Query Calls</h4>
<div class="paragraph">
<p>The above provides for API calls whose signature definition may be more or less anything. For the case of query invocation, some simplifying assumptions can be made, and in the interests of clarity, the <code>QUERY_CALL</code> class is defined for this purpose. A <code>QUERY_CALL</code> instance represents a query invocation which is assumed to take the  form of either an ad hoc query or a stored query, with substitutable parameters. accordingly, the external API calls are therefore assumed to take one of the two forms:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="typescript"><span></span>    <span class="tok-c1">// ad hoc query call</span>
    <span class="tok-nx">execute_ad_hoc_query</span> <span class="tok-p">(</span>
        <span class="tok-nx">query_text</span>: <span class="tok-kt">String</span><span class="tok-p">;</span>
        <span class="tok-nx">parameters</span>: <span class="tok-kt">Hash</span><span class="tok-o">&lt;</span><span class="tok-nb">String</span><span class="tok-p">,</span> <span class="tok-nb">String</span><span class="tok-o">&gt;</span><span class="tok-p">;</span>
    <span class="tok-p">)</span><span class="tok-o">:</span> <span class="tok-nx">Result</span>

    <span class="tok-c1">// stored query call</span>
    <span class="tok-nx">execute_stored_query</span> <span class="tok-p">(</span>
        <span class="tok-nx">query_id</span>: <span class="tok-kt">String</span><span class="tok-p">;</span>
        <span class="tok-nx">parameters</span>: <span class="tok-kt">Hash</span><span class="tok-o">&lt;</span><span class="tok-nb">String</span><span class="tok-p">,</span> <span class="tok-nb">String</span><span class="tok-o">&gt;</span><span class="tok-p">;</span>
    <span class="tok-p">)</span><span class="tok-o">:</span> <span class="tok-nx">Result</span></code></pre>
</div>
</div>
<div class="paragraph">
<p>In the first case, a query string is supplied; in the second, the registered identifier of a stored query is supplied. In both cases, the substitutable parameters are supplied though the <code>args</code> attribute, which is a keyed list of <code>String</code> values that can be substituted into the replaceable parameters found in the query.</p>
</div>
<div class="paragraph">
<p>In order to represent an invocation of either of these calls, the <code><em>parameter_map</em></code> attribute is used to represent the map between the names of <em>the substitutable parameters in the query</em> and variables from the Work Plan context. Since these are often likely to be the same (almost certainly the case for ad hoc queries), mappings are only required for substitutable variables whose names differ in the query and in the Plan context variable set.</p>
</div>
<div class="paragraph">
<p>The <code><em>bound_parameters</em></code> may be used in a similar fashion, to represent fixed-value substitutable parameters.</p>
</div>
<div class="paragraph">
<p>As a consequence of this scheme, the total set of replaceable query parameters is specified by the combination of the <code><em>parameter_map</em></code>, the <code><em>bound_parameters</em></code> and the context variables. In many cases, only the latter may be used.</p>
</div>
</div>
<div class="sect3">
<h4 id="_class_descriptions_2"><a class="anchor" href="#_class_descriptions_2"></a>5.3.3. Class Descriptions</h4>
<div class="sect4">
<h5 id="_system_call_class"><a class="anchor" href="#_system_call_class"></a>5.3.3.1. SYSTEM_CALL Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong><em>SYSTEM_CALL (abstract)</em></strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Abstract definition of a request to make to a system (i.e. information system or device) via its API, that reads or writes information specific to the Task to which it is attached in an actual Plan.</p>
</div>
<div class="paragraph">
<p>This could include OS calls, e.g. to launch an application for a certain user.</p>
</div>
<div class="paragraph">
<p>The formal signature of the call may be referenced via the <code>definition</code> attribute.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>system_id</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identifier of target system, typically a domain name.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>call_name</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Name of call in API.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>definition</strong>:</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Signature definition of call.</p>
</div>
<div class="paragraph">
<p>TODO: to be defined.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>parameter_map</strong>: <code>List&lt;PARAMETER_MAPPING&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Map of parameter names from system call definition (i.e. argument names) to Work Plan context variable names. This may be partial if there are bound parameters.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>bound_parameters</strong>: <code>List&lt;PARAMETER_DEF&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Parameter values fixed for any invocation of the call. For example, a general call such as <code><em>cds_check (type: String, other_args, &#8230;&#8203;)</em></code> might be used from within the Task Plan in the form <code><em>cds_check ("hypertension risk", other_args, &#8230;&#8203;)</em></code>, i.e. the first argument is always fixed.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_parameter_def_class"><a class="anchor" href="#_parameter_def_class"></a>5.3.3.2. PARAMETER_DEF Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>PARAMETER_DEF</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Specifies a parameter with a name and type from an external API, and a value to be passed for this parameter on call invocation.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>name</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Name of parameter in external API call.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>type</strong>: <code>EL_TYPE_DEF</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Type of parameter in external API call.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>value</strong>: <code>Any</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Fixed value to pass on call invocation.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_parameter_mapping_class"><a class="anchor" href="#_parameter_mapping_class"></a>5.3.3.3. PARAMETER_MAPPING Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>PARAMETER_MAPPING</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Mapping of an internal context value name to an external API call parameter name.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>name</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Name of parameter in external API call definition.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>context_name</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Name of context value definition (i.e. variable, expression, constant, including built-ins) whose value should be passed through as the named parameter on call invocation.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_api_call_class"><a class="anchor" href="#_api_call_class"></a>5.3.3.4. API_CALL Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>API_CALL</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Type of System call targetted to a general API, which may by via any concrete technology or protocol. The parameters list will normally consist of heterogeneous types.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>SYSTEM_CALL</code></p></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_query_call_class"><a class="anchor" href="#_query_call_class"></a>5.3.3.5. QUERY_CALL Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>QUERY_CALL</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Type of System Call that is to a query service, where calls are available for executing ad hoc queries and stored queries. For the ad hoc case, the parameters are of the form:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code><em>query_text</em>: String</code></p>
</li>
<li>
<p><code><em>query_parameters</em>: Hash&lt;String, String&gt;</code></p>
</li>
</ul>
</div>
<div class="paragraph">
<p>while for the stored query case, a <code><em>query_id</em></code> would be supplied instead of the <code><em>query_text</em>: String</code>.</p>
</div>
<div class="paragraph">
<p>In the context of a Work Plan / Task Plan, query parameters  supplied from three places:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>for substitutable parameters having the same name as context variables, by implicit substitution;</p>
</li>
<li>
<p>for parameters with different names, <code><em>parameter_map</em></code> defines the mapping;</p>
</li>
<li>
<p>for fixed parameters, <code><em>bound_parameters</em></code> contains the values.</p>
</li>
</ul>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>SYSTEM_CALL</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>query_id</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identifier of a stored query.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>query_text</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Ad hoc query text.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_variable_referencing"><a class="anchor" href="#_variable_referencing"></a>5.4. Variable Referencing</h3>
<div class="paragraph">
<p>Within the expressions and System calls used in Task definitions, various variables may be used. These include the context variables described above and built-in variables defined for any Work Plan context, enabling the current Plan, current Task etc to be referred to, for example in a System call. The 'camel-case' and 'snake-case' variants of a variable name are treated as equivalents, i.e. <code>$var_name</code> and <code>$varName</code> refer to the same thing. Among the context variables, some standard defaults are recommended in order to maximise reusability of Task Plan definitions.</p>
</div>
<div class="paragraph">
<p>Within expressions, defined variables are referenced using the '$' syntax, i.e. <code>$var_name</code> or <code>$varName</code>. Within System calls there are two places where variable references may appear:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>within the <code><em>parameters</em></code> list, to indicate the mapping of a call parameter to a variable defined in the Work Plan context;</p>
</li>
<li>
<p>as lexical inline replaceable parameters within a call parameter that represents an ad hoc query string or similar.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>For the first case, the '$' name form is used. In the second case, variables usually appear within query strings in a lexical form that depends on the particular kind of query syntax, i.e. forms such as:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code>$var_name</code> - openEHR AQL;</p>
</li>
<li>
<p><code>@varName</code> - SQL Server, Oracle, PostGres 9 or later;</p>
</li>
<li>
<p><code>$[varName]</code> - some SQL implementations.</p>
</li>
</ul>
</div>
<div class="paragraph tbd">
<p>TBD: do we need another property to record the type of query syntax, e.g. <code>'aql'</code>, <code>'oracle-sql'</code>, or variable syntax, since it is not a SQL standard?</p>
</div>
<div class="paragraph">
<p>The following table describes the variables available within a typical Work Plan.</p>
</div>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 16.6666%;">
<col style="width: 16.6666%;">
<col style="width: 16.6666%;">
<col style="width: 50.0002%;">
</colgroup>
<thead>
<tr>
<th class="tableblock halign-left valign-top">Name</th>
<th class="tableblock halign-left valign-top">Type</th>
<th class="tableblock halign-left valign-top">Status</th>
<th class="tableblock halign-left valign-top">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top" colspan="4"><p class="tableblock"><em>Work plan-defined variables</em></p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>$work_plan_id</code> / <code>$workPlanId</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>String</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Standard</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Variable referring to current <code>WORK_PLAN.<em>uid</em></code></p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>$task_plan_id</code> / <code>$taskPlanId</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>String</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Standard</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Variable referring to current <code>TASK_PLAN.<em>uid</em></code></p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>$task_group_id</code> / <code>$taskGroupId</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>String</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Standard</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Variable referring to current <code>TASK_GROUP.<em>uid</em></code></p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>$task_id</code> / <code>$taskId</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>String</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Standard</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Variable referring to current <code>TASK.<em>uid</em></code></p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>$subject_id</code> / <code>$subjectId</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>String</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Standard</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Variable referring to current <code>WORK_PLAN.<em>subject.external_ref.id.value</em></code></p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top" colspan="4"><p class="tableblock"><em>Context variables and expressions</em></p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>$var_name</code> / <code>$varName</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>Any</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Standard</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Any variable or expression, e.g. <code>$heart_rate</code>;</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>$ehr_id</code> / <code>$ehrId</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>String</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Preferred</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Variable referring to EHR id of EHR of the subject of the Task Plan</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>$bp_systolic</code> / <code>$bpSystolic</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>Real</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Preferred</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Variable referring to subject current systolic arterial blood pressure</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>$bp_diastolic</code> / <code>$bpDiastolic</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>Real</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Preferred</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Variable referring to subject current diastolic arterial blood pressure</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>$heart_rate</code> / <code>$heartRate</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>Real</code></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Preferred</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Variable referring to subject current heart rate</p></td>
</tr>
</tbody>
</table>
</div>
<div class="sect2">
<h3 id="_specifying_time"><a class="anchor" href="#_specifying_time"></a>5.5. Specifying Time</h3>
<div class="paragraph">
<p>Generic classes for specifying time formally and in customary form such as 'afternoon' are provided for use in the main model. These are shown bottom right of the above UML diagram: <code>TIME_SPECIFIER</code> and descendants.</p>
</div>
<div class="sect3">
<h4 id="_class_descriptions_3"><a class="anchor" href="#_class_descriptions_3"></a>5.5.1. Class Descriptions</h4>
<div class="sect4">
<h5 id="_time_specifier_class"><a class="anchor" href="#_time_specifier_class"></a>5.5.1.1. TIME_SPECIFIER Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong><em>TIME_SPECIFIER (abstract)</em></strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Abstract parent of types used to specify a point in time during a day.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_clock_time_class"><a class="anchor" href="#_clock_time_class"></a>5.5.1.2. CLOCK_TIME Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>CLOCK_TIME</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>A point in time within a day.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>TIME_SPECIFIER</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>time</strong>: <code>Iso8601_time</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Time expressed as a clock time within a day.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_customary_time_class"><a class="anchor" href="#_customary_time_class"></a>5.5.1.3. CUSTOMARY_TIME Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>CUSTOMARY_TIME</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Time specified in some customary way, such as 'morning', 'afternoon', etc, that must be interpreted to determine an equivalent format time.</p>
</div>
<div class="paragraph">
<p>Resolution to computable times is assumed to be done via call to a service or resource available within the operational environment.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>TIME_SPECIFIER</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>time</strong>: <code>DV_CODED_TEXT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>A coded term expressing a customary time in natural language.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_enumerated_types"><a class="anchor" href="#_enumerated_types"></a>5.6. Enumerated Types</h3>
<div class="paragraph">
<p>Various enumerated types are defined in the <code>definitions</code> package, for use by the definition, materialised and runtime models.</p>
</div>
<div class="sect3">
<h4 id="_class_descriptions_4"><a class="anchor" href="#_class_descriptions_4"></a>5.6.1. Class Descriptions</h4>
<div class="sect4">
<h5 id="_task_lifecycle_enumeration"><a class="anchor" href="#_task_lifecycle_enumeration"></a>5.6.1.1. TASK_LIFECYCLE Enumeration</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Enumeration</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>TASK_LIFECYCLE</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Enumeration representing possible lifecycle states for a Task lifecycle transition, for example, "not needed".</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">planned</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Task is planned for the future.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">available</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Task is available for execution by performer.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">cancelled</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Task was cancelled without commencing.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">abandoned</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Task was aborted after commencement, i.e. ended prematurely without meeting normal conditions of completion.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">completed</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Task was completed in the intended way.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">suspended</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Task is waiting for completion of a handoff or external request.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">underway</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Task has been commenced.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">resumed</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Task has been resumed from <code>suspend</code> state.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_resume_type_enumeration"><a class="anchor" href="#_resume_type_enumeration"></a>5.6.1.2. RESUME_TYPE Enumeration</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Enumeration</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>RESUME_TYPE</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Enumeration of types of resume behaviour after a callback.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">resume_specified</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Resume at a specified Task in the same thread of control.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">retry_current_group</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Retry Tasks starting at the top of the current Group.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">new_thread</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Recommence as a new thread of execution at <code><em>restart_location</em></code>.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_temporal_relation_enumeration"><a class="anchor" href="#_temporal_relation_enumeration"></a>5.6.1.3. TEMPORAL_RELATION Enumeration</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Enumeration</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>TEMPORAL_RELATION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Enumeration of relative temporal relations.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">before</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Before a reference event.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">with</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>At the same time as a reference event.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">after</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>After a reference event.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_execution_type_enumeration"><a class="anchor" href="#_execution_type_enumeration"></a>5.6.1.4. EXECUTION_TYPE Enumeration</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Enumeration</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>EXECUTION_TYPE</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Enumeration specifying types of execution for a set of Tasks.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">sequential</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Items execute in order, one after the other.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">parallel</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Items may be executed in parallel, with no regard to order in the representation.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_plan_time_origin_enumeration"><a class="anchor" href="#_plan_time_origin_enumeration"></a>5.6.1.5. PLAN_TIME_ORIGIN Enumeration</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Enumeration</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>PLAN_TIME_ORIGIN</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Enumeration of types of origin for time offsets within a Work Plan.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">current_task_plan</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Time offset is relative to the moment of activation of the Task Plan within which the offset occurs.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">current_work_plan</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Time offset is relative to the moment of activation of the Work Plan within which the offset occurs.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">inner_repeat_section</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Time offset is relative to the moment of activation of the innermost Repeat Section (Task Group or Task with a <code>REPEAT_SPEC</code>) within which the offset occurs.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">outer_repeat_section</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Time offset is relative to the moment of activation of the outermost Repeat Section (Task Group or Task with a <code>REPEAT_SPEC</code>) within which the offset occurs.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_definition_model"><a class="anchor" href="#_definition_model"></a>6. Definition Model</h2>
<div class="sectionbody">
<div class="sect2">
<h3 id="_overview"><a class="anchor" href="#_overview"></a>6.1. Overview</h3>
<div class="paragraph">
<p>This section describes the formal model of Work Plan and Task Plan, which is presented in UML form, as well as in TP-VML definition instance form. The following figure shows the main classes in the <code>proc.task_planning.definition</code> package.</p>
</div>
<div id="proc_definition_structure" class="imageblock text-center text-center">
<div class="content">
<img src="UML/diagrams/PROC-task_planning.definition-structure.svg" alt="PROC task planning.definition structure">
</div>
<div class="title">Figure 14. proc.task_planning.definition model overview</div>
</div>
<div class="paragraph">
<p>The remaining classes are shown in various specialised views below.</p>
</div>
</div>
<div class="sect2">
<h3 id="_plan_structure"><a class="anchor" href="#_plan_structure"></a>6.2. Plan Structure</h3>
<div class="paragraph">
<p>The top-level structure for defining plans is a <code>WORK_PLAN</code>, which includes one or more related <code>TASK_PLANs</code> making up a logical goal-oriented plan. Within a Work Plan, two distinct lists of Task Plans are maintained:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code><em>plans</em></code>: references all Task Plans;</p>
</li>
<li>
<p><code><em>top_level_plans</em></code>: 'entry point' Task Plans that will be <em>unconditionally active at Work Plan activation</em> (often limited to only one).</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Non-top-level plans are those used as sub-plans within the hierarchy of a top-level Plan. A typical Work Plan / Task Plan structure is shown below in TP-VML form.</p>
</div>
<div id="work_task_plans" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/work_task_plans.svg" alt="work task plans" width="50%">
</div>
<div class="title">Figure 15. Work Plan top level structure</div>
</div>
<div class="paragraph">
<p><code>WORK_PLAN</code> has a number of attributes relating to formal Plan representation, as follows:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code><em>context</em></code>: a data context for the Plan as a whole, which enables external variables (such as patient data items) to be tracked and updated;</p>
</li>
<li>
<p><code><em>calendar</em></code>: a global calendar containing entries that relate to this Work Plan, e.g. appointments, holidays etc;</p>
</li>
<li>
<p><code><em>timeline</em></code>: the global timeline for the Plan (and hence the subject) into which planned Tasks are fixed, with times specified as offsets from the zero point;</p>
</li>
<li>
<p><code><em>event_wait_states</em></code>: a reference list of all Event wait instances defined in the Plan;</p>
</li>
<li>
<p><code><em>order_list</em></code>: a table of references to orders being tracked in the Plan (described in <a href="#_order_tracking">Section 6.8</a> below).</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Additionally, there are the following meta-data attributes:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code><em>indications</em></code>: record clinical indications (including codes for diagnoses) for which the Work Plan can be / should be used;</p>
</li>
<li>
<p><code><em>classification</em></code>: record one or more classifications of the Work Plan as a whole, e.g. business category, administrative category etc. The most common structure is likely to be a logical list (i.e. <code>ITEM_TREE</code> instance of linear list form), such that the <code><em>archetype_node_id</em></code> attribute (inherited from <code>LOCATABLE</code>) acts as the name of the category (e.g. 'org unit'), and an <code>ELEMENT</code> containing a <code>DV_TEXT</code> providing the actual category value (e.g. 'inventory management').</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Both <code>WORK_PLAN</code> and <code>TASK_PLAN</code> are descendants of <code>CONTENT_ITEM</code>, which makes them a type of content that may occur in an openEHR <code>COMPOSITION</code>. Compositions used for this purpose have their <code><em>category</em></code> attribute set to the openEHR coded term <code>|Work Plan|</code>. This enables Work Plans to be committed to the openEHR EHR.</p>
</div>
<div class="paragraph">
<p>Plan internal structure is specified by the <code><em>definition</em></code> attribute of a <code>TASK_PLAN</code> is a <code>TASK_GROUP</code>, which has as its <code><em>members</em></code> any number of <code>PLAN_ITEMs</code>, which resolve either to more <code>TASK_GROUPs</code> (and some specialisations described below), or <code>TASK</code> entities.</p>
</div>
<div class="sect3">
<h4 id="_the_plan_calendar"><a class="anchor" href="#_the_plan_calendar"></a>6.2.1. The Plan Calendar</h4>
<div class="paragraph">
<p>The Work Plan <code><em>calendar</em></code> consists of Plan-related entries fixed in time, as per the usual notion of a person&#8217;s or organisational calendar. These will normally be a small subset of entries from a/the work management calendar of the organisation in whose IT system the Work Plans are used. A Plan calendar event can be used as the basis for a wait state (<code>TASK_WAIT.<em>events</em></code>) for Tasks in the Plan, either to indicate that something should be done on the date/time of the calendar event, or with a certain delay. Calendar events may include organisational events, national holidays and patient appointments. Wait states of the form '2 weeks after Easter Sunday' and '24 week ante-natal review (10 Feb 2019)' can therefore be defined in a Plan.</p>
</div>
</div>
<div class="sect3">
<h4 id="_plan_items"><a class="anchor" href="#_plan_items"></a>6.2.2. Plan Items</h4>
<div class="paragraph">
<p>The <code>PLAN_ITEM</code> class is the parent of all fine-grained elements of a Task Plan, which are either <code>TASKs</code> or <code>TASK_GROUPs</code>. It has a mandatory <code><em>description</em></code> attribute, which represents a natural language specification of the work of the Task.</p>
</div>
<div class="sect4">
<h5 id="_wait_states"><a class="anchor" href="#_wait_states"></a>6.2.2.1. Wait States</h5>
<div class="paragraph">
<p><code>PLAN_ITEM</code> also has two optional attributes that control the timing behaviour of Task Plan elements: <code><em>wait_spec</em></code> and <code><em>repeat_spec</em></code>. The first enables a wait state (described above under <a href="#_time_and_wait_states">Section 4.3.8</a>) to be applied to a Task or Group, which is triggered by time-related Events (clock time, reaching a point in a calendar) or other kinds of Events (external notifications etc). This allows the timing of a Task to be specified.</p>
</div>
</div>
<div class="sect4">
<h5 id="_repetition"><a class="anchor" href="#_repetition"></a>6.2.2.2. Repetition</h5>
<div class="paragraph">
<p>The second attribute, <code><em>repeat_spec</em></code> of type <code>TASK_REPEAT</code> enables a Task or Group to be marked as repeating. This is not intended to replace the use of individual Task instances over time, such as repeated medication administrations, but rather to be used to indicate if larger sections (i.e. Task Groups) of planned Tasks are repeatable. Where repeats are specified, they will be unrolled into literal copies in the materialised expression of the Plan.</p>
</div>
<div class="paragraph">
<p>Repeat behaviour is specified in terms of the attributes <code><em>repeats</em></code>, <code><em>terminate_condition</em></code> and <code><em>period</em></code>. The first indicates the minimum and maximum number of repeats that may occur. Repetition occurs until the minimum number of repeats (i.e. <code><em>repeats.lower</em></code>) is reached. Following that, if <code><em>terminate_condition</em></code> is set, it is evaluated <em>prior</em> to each further potential iteration. Repetition will cease when <code><em>terminate_condition</em></code> becomes True or else when <code><em>repeats.upper</em></code> is reached (assuming no plan abandonment or other exceptions).</p>
</div>
<div class="paragraph">
<p>The optional <code><em>period</em></code> attribute defines the period of repetition. If the latter is not defined, each repetition commences according to the application of Task availability rules already defined on the individual Tasks and/or Groups; this will typically lead to each repeat executing as soon as the preceding one has completed. If set, the <code><em>period</em></code> will have the effect of spacing iterations out over time. Its value should be greater than the duration of a single iteration, since at execution time, a new iteration can only begin after completion of the previous one.</p>
</div>
</div>
<div class="sect4">
<h5 id="_other_attributes"><a class="anchor" href="#_other_attributes"></a>6.2.2.3. Other Attributes</h5>
<div class="paragraph">
<p>Two archetypable structure attributes are defined on <code>PLAN_ITEM</code>. The first, <code><em>classification</em></code>, is designed to allow any Task Group or Task to be tagged with one or more classifications, and has the same structural definition at <code>WORK_PLAN.<em>classification</em></code>.</p>
</div>
<div class="paragraph">
<p>The second, <code>other_details</code> is provided to support extensions, in the same manner as elsewhere in openEHR information models.</p>
</div>
</div>
</div>
<div class="sect3">
<h4 id="_lifecycle_state"><a class="anchor" href="#_lifecycle_state"></a>6.2.3. Lifecycle State</h4>
<div class="paragraph">
<p>At execution time, every Plan Item (i.e. Task and Group) notionally has a <em>lifecycle state</em>, represented by a state machine, containing states and transitions reflecting possible actions by the performer. The lifecycle state of a Task is set by the TP engine and affected directly by performer actions and other logic, while the lifecycle state of a Group is aggregated from the state values of its member Tasks and Groups.</p>
</div>
<div class="paragraph">
<p>The lifecycle state does not appear directly as a data attribute on the <code>PLAN_ITEM</code> or <code>TASK</code> classes since it is a runtime variable for a Task. Accordingly, it appears in the materialised model, <a href="#_materialised_model">described below</a>. It is however useful to decribe the lifecycle state here, since it represents a key part of Task Plan semantics, and influences whether Tasks (and thus Groups) fail or complete, and potentially whether the Plan continues in execution.</p>
</div>
<div class="paragraph">
<p>The lifecycle states are as follows (terminal states are marked with '(T)'):</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code>initial</code>: initial pseudo-state, not used in operation;</p>
</li>
<li>
<p><code>planned</code>: defined, but not yet available for execution;</p>
</li>
<li>
<p><code>available</code>: available for execution, due to previous Tasks having been performed, preconditions being met, and if there is a time specification on the Task, the current time being at or later than the stated time;</p>
</li>
<li>
<p><code>cancelled</code> (T): cancelled prior or during execution as not needed for success of the Plan;</p>
</li>
<li>
<p><code>completed</code> (T): performed to completion;</p>
</li>
<li>
<p><code>abandoned</code> (T): execution of current Task Plan was stopped before or after commencement due to completion being impossible;</p>
</li>
<li>
<p><code>underway</code>: indicates that a Task execution has been commenced;</p>
</li>
<li>
<p><code>suspended</code>: indicates that a Task execution has been suspended.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The state machine is shown below.</p>
</div>
<div id="task_state_machine" class="imageblock text-center text-center">
<div class="content">
<img src="UML/diagrams/PROC-TaskStateMachine.svg" alt="PROC TaskStateMachine" width="80%">
</div>
<div class="title">Figure 16. Task lifecycle state machine</div>
</div>
<div class="paragraph">
<p>The state machine is designed to represent both stateless and stateful views of the actual execution state of a Task in the real world. The standard pathway is <code>available</code> &#8658; <code>completed</code> or <code>abandoned</code> or <code>cancelled</code>, which enables a user to indicate the outcome of executing a Task, without having to report interim states during execution in the real world. The pathways through the states <code>underway</code> and <code>suspended</code> are provided to represent in-execution states, which are needed for two cases:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>longer-running atomic Tasks;</p>
</li>
<li>
<p>dispatchable Tasks that are blocked waiting on another performer.</p>
</li>
</ul>
</div>
<div class="admonitionblock note">
<table>
<tr>
<td class="icon">
<div class="title">Note</div>
</td>
<td class="content">
Task lifecycle only accounts for the states of a Task itself; states of an order (e.g. prescription, lab request) with which the Task may be associated will be visible in the documentation for those objects, e.g. openEHR <code>ACTION</code> or other Entry objects.
</td>
</tr>
</table>
</div>
<div class="sect4">
<h5 id="_task_availability"><a class="anchor" href="#_task_availability"></a>6.2.3.1. Task Availability</h5>
<div class="paragraph">
<p>Each Task in a new Plan execution starts in the <code>initial</code> state. Following the design principle <a href="#_allocation">described earlier</a>, the execution engine executing a Task Plan can determine the <em>availability</em> i.e., when the transition <code>planned</code> &#8658; <code>available</code> may occur for any Task as follows:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>control-flow</em>: preceding Tasks / Groups within the owning Task Group are in the <code>completed</code> or <code>cancelled</code> state;</p>
</li>
<li>
<p><em>wait state</em>: any Task or Group wait state has been exited due to the arrival of the relevant events (including time-related);</p>
</li>
<li>
<p><em>subject preconditions</em>: subject preconditions attached to the current Task Action are satisfied.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>A Task is considered <code>available</code> according to this logic even if performer and/or resources have not been allocated. Availability in this sense is the equivalent of the 'enabled' state of a task within a Workflow Net, described in <a href="#Hofstede_van_der_Aalst2009">Hofstede van der Aalst Adams &amp; Russell (2010)</a>, section 2.3.2.</p>
</div>
<div class="paragraph">
<p>The workflow application may provide an override capability so that a Task can be performed before it is determined to be available. This would enable a user to perform the Task anyway, forcing the lifecycle transition <code><em>override</em></code> from <code>planned</code> to <code>available</code>. A corresponding <code>TASK_EVENT_RECORD</code> is created recording the use of the override.</p>
</div>
</div>
<div class="sect4">
<h5 id="_aggregate_process_state"><a class="anchor" href="#_aggregate_process_state"></a>6.2.3.2. Aggregate Process State</h5>
<div class="paragraph">
<p>The effective state of a Task Group, Task Plan and Work Plan can be inferred from the lifecycle states of the Tasks, according to logic described in <a href="#_aggregate_lifecycle_state">Section 7.3</a>. This includes availability of Task Groups containing parallel paths with associated OR logic, i.e. the equivalent of the OR-join in YAWL (<a href="#Hofstede_van_der_Aalst2009">Hofstede van der Aalst Adams &amp; Russell (2010)</a>, section 3.2).</p>
</div>
</div>
</div>
<div class="sect3">
<h4 id="_references_to_clinical_quality_artefacts"><a class="anchor" href="#_references_to_clinical_quality_artefacts"></a>6.2.4. References to Clinical Quality Artefacts</h4>
<div class="paragraph">
<p>The classes <code>WORK_PLAN</code> and <code>TASK_PLAN</code> may contain various references to externally defined clinical quality artefacts that they are based on or relate to, as follows:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>In <code>WORK_PLAN</code>:</p>
<div class="ulist">
<ul>
<li>
<p><code><em>care_pathway</em></code>: a reference to a published care pathway from which this Work Plan was derived, if any;</p>
</li>
<li>
<p><code><em>care_plan</em></code>: a machine reference to an underpinning Care Plan from elsewhere in the EHR, if any exists;</p>
</li>
</ul>
</div>
</li>
<li>
<p>In <code>TASK_PLAN</code>:</p>
<div class="ulist">
<ul>
<li>
<p><code><em>guideline</em></code>: reference to a published guideline (used by <code>WORK_PLAN.<em>care_pathway</em></code>, if set) from which this particular Task Plan was derived, if any;</p>
</li>
<li>
<p><code><em>best_practice_ref</em></code>: reference to an institutional document that defines the best practice on which this Task Plan is based, if any;</p>
</li>
</ul>
</div>
</li>
<li>
<p>In <code>PLAN_ITEM</code>:</p>
<div class="ulist">
<ul>
<li>
<p><code><em>guideline_step</em></code>: reference to a step within the <code><em>guideline</em></code> referenced by the current Task Plan or the <code><em>care_pathway</em></code> of the Work Plan, which is the basis of this Plan Item, i.e. single Task or Task Group.</p>
</li>
</ul>
</div>
</li>
</ul>
</div>
<div class="paragraph">
<p>In addition, where a Task Plan is driven by an order set, two attributes are provided to record the details:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>In <code>TASK_PLAN</code>:</p>
<div class="ulist">
<ul>
<li>
<p><code><em>order_set_type</em></code>: the identifier of a type of Order Set which this Task Plan uses, if any;</p>
</li>
<li>
<p><code><em>order_set_id</em></code>: the identifier of a specific Order Set which this Task Plan uses, if any.</p>
</li>
</ul>
</div>
</li>
</ul>
</div>
<div class="paragraph">
<p>Lastly, the <code><em>workflow_id</em></code> attribute defined in <code>ENTRY</code> may be set within <code>INSTRUCTION</code> and <code>ACTION</code> to refer to the Order Set instance used in this Task Plan, if set.</p>
</div>
</div>
<div class="sect3">
<h4 id="_class_definitions"><a class="anchor" href="#_class_definitions"></a>6.2.5. Class Definitions</h4>
<div class="sect4">
<h5 id="_work_plan_class"><a class="anchor" href="#_work_plan_class"></a>6.2.5.1. WORK_PLAN Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>WORK_PLAN</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Top-level object of any logical work plan. References one or more <code>TASK_PLANs</code> that described the work, typically of each performer, although a single <code>TASK_PLAN</code> may also have multiple performers.</p>
</div>
<div class="paragraph">
<p>The attribute <code><em>care_pathway</em></code> and `<em>care_plan</em>`provide a way of associating a Work Plan with a published care pathway, and an operational care plan from within the EHR, if available.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>AUTHORED_RESOURCE</code>, <code>CONTENT_ITEM</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>care_pathway</strong>: <code>ITEM_STRUCTURE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identifier of care pathway etc, on which this Work Plan is based, if such exists. A 'care pathway' is understood here as a published standard for performing care for a major condition or presenting complaint, e.g. sepsis, heart attack etc.</p>
</div>
<div class="paragraph">
<p>The <code>ITEM_STRUCTURE</code> type is used to allow population at runtime with an archetype based on e.g. BibTex publication reference fields, such as the following:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code>title = "NICE Sepsis care pathway"</code>;</p>
</li>
<li>
<p><code>publisher = "National Institute of Health and Care Excellence (UK)"</code>;</p>
</li>
<li>
<p><code>year = 2016</code>;</p>
</li>
<li>
<p><code>url = "https://pathways.nice.org.uk/pathways/sepsis"</code>.</p>
</li>
</ul>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>plans</strong>: <code>List&lt;UID_BASED_ID&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>References to all Task Plans use in this Work Plan. In general, only some of these are top-level Plans.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>care_plan</strong>: <code>LOCATABLE_REF</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Care plan in EHR from which this Work Plan is derived, if any.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>calendar</strong>: <code>PLAN_CALENDAR</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Global calendar object, containing events fixed in time relevant to the Plan&#8217;s Tasks, for example appointments.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>timeline</strong>: <code>PLAN_TIMELINE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Global timeline of Work Plan, on which Tasks with planned times can be listed.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>context</strong>: <code>PLAN_DATA_CONTEXT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Global Work Plan data context.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>event_wait_states</strong>: <code>List&lt;EVENT_WAIT&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Reference list of all defined Event Listeners.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>top_level_plans</strong>: <code>List&lt;TASK_PLAN&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>The set of Task Plans that are active at Work Plan activation. Does not include Task Plans referred to from <code>HAND_OFF</code> or <code>SUB_PLAN</code>.</p>
</div>
<div class="paragraph">
<p>TODO: change to computed?</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>indications</strong>: <code>List&lt;DV_TEXT&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Clinical applicability of this Work Plan to subject of work, e.g. 'acute ischaemic stroke' etc. May be derived from a governing guideline.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>order_list</strong>: <code>Hash&lt;String,ORDER_REF&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Orders tracked by Tasks in this Work Plan.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>classification</strong>: <code>ITEM_STRUCTURE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Archetypable structure for recording classification of Work Plans, e.g. business process category, administrative category etc.</p>
</div>
<div class="paragraph">
<p>Note that the same kind of classifications can be applied to Tasks and Groups via <code>PLAN_ITEM.<em>classification</em></code>.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_plan_calendar_class"><a class="anchor" href="#_plan_calendar_class"></a>6.2.5.2. PLAN_CALENDAR Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>PLAN_CALENDAR</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Work Plan global calendar in which all absolute-time Calendar Events are recorded.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>entries</strong>: <code>List&lt;CALENDAR_ENTRY&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Entries in calendar.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_plan_timeline_class"><a class="anchor" href="#_plan_timeline_class"></a>6.2.5.3. PLAN_TIMELINE Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>PLAN_TIMELINE</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>List of Plan Items that have a <code><em>wait_condition</em></code> containing a <code>TIMELINE_MOMENT</code> event.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>planned_items</strong>: <code>List&lt;PLAN_ITEM&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>List of Plan Items that have a wait_condition containing a <code>TIMELINE_MOMENT</code>.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>timers</strong>: <code>List&lt;TIMER_WAIT&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Reference list of all defined Timers.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_calendar_entry_class"><a class="anchor" href="#_calendar_entry_class"></a>6.2.5.4. CALENDAR_ENTRY Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>CALENDAR_ENTRY</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>A single calendar entry.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_task_plan_class"><a class="anchor" href="#_task_plan_class"></a>6.2.5.5. TASK_PLAN Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>TASK_PLAN</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Logical list of Tasks in a structure defining order and conditions of execution of items of work intended to achieve a goal. A Task Plan consists of a top-level <code>TASK_GROUP</code> containing <code>PLAN_ITEMs</code>, which are either atomic TASKs, more <code>TASK_GROUPs</code> or conditional Groups.</p>
</div>
<div class="paragraph">
<p>A Task Plan specifies a <code><em>principal_performer</em></code>, representing a kind of actor who can perform the Tasks, and bounding <code><em>start_time</em></code> and <code><em>completion_time</em></code> information.</p>
</div>
<div class="paragraph">
<p>It has an associated <code><em>execution_history</em></code> that can be used to record work events in time.</p>
</div>
<div class="paragraph">
<p>The <code><em>guideline</em></code> attribute provides a way of associating a Task Plan with a published guideline on which the Task Plan may be based; this may be used by <code>WORK_PLAN.<em>care_pathway</em></code> if set.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>CONTENT_ITEM</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>description</strong>: <code>DV_TEXT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Human-understandable description of the Task Plan, which may be specific to the work items and patient.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>subject</strong>: <code>PARTY_PROXY</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional indicator of subject of Task Plan, which is normally the subject of the EHR. If this is not the case, this attribute states with respect to whom the Plan is to be performed.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>guideline</strong>: <code>ITEM_STRUCTURE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identifier of guideline on which this Task Plan is based, if such exists. A 'guideline' is understood here as a published standard for performing a detailed Task.</p>
</div>
<div class="paragraph">
<p>Identifier of care pathway etc, on which this Work Plan is based, if such exists. A 'care pathway' is understood here as a published standard for performing care for a major condition or presenting complaint, e.g. sepsis, heart attack etc.</p>
</div>
<div class="paragraph">
<p>The <code>ITEM_STRUCTURE</code> type is used to allow population at runtime with an archetype based on e.g. BibTex publication reference fields, such as the following:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code>title = "NHS guideline for Atrial fibrillation: management"</code>;</p>
</li>
<li>
<p><code>publisher = "National Institute of Health and Care Excellence (UK)"</code>;</p>
</li>
<li>
<p><code>year = 2016</code>;</p>
</li>
<li>
<p><code>url = "https://www.nice.org.uk/guidance/cg180"</code>.</p>
</li>
</ul>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>definition</strong>: <code>TASK_GROUP</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>The Tasks for the main part of this Task Plan; this section of the plan may be repeatable.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>execution_history</strong>: <code>TASK_PLAN_EXECUTION_HISTORY</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>History of execution events for an execution of this Task Plan.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>best_practice_ref</strong>: <code>DV_URI</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>A URI (typically a local URL) that points to the document form of any governing guideline or other best practice publication in use in the current institution. This link provides a way for a clinician to cross-check the Task Plan design and functioning against the definitive document that acts as the source of its semantics.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>expiry_time</strong>: <code>Iso8601_duration</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Maximal date/time by which this Task Plan should be considered obsolete. If not set, the Task Plan would normally be inferred to be obsolete after a discharge from acute care, but in primary or social care situations, no value may be assumed to indicate that the Tasks are still to be performed, depending on the times specified in the <code><em>execution_time</em></code> attribute of <code>TASKs</code> in the Plan.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>due_time</strong>: <code>Iso8601_duration</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Due date/time expressed as an offset, to be converted to a real date/time at activation.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>order_set_type</strong>: <code>DV_IDENTIFIER</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional identifier for an order set, which is understood as a <em>type</em> of order set, e.g. 'R-CHOP-14'.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>order_set_id</strong>: <code>DV_IDENTIFIER</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identifier of instance of an order set on which this Task Plan is based, if there is one.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>indications</strong>: <code>List&lt;DV_TEXT&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Clinical applicability of this Task Plan to subject of work, e.g. 'pregnancy', 'lymphoma' etc. May be derived from a governing guideline. May be displayed as a safety precaution to human performer.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>principal_performer</strong>: <code>TASK_PARTICIPATION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Specification of principle performer of this Task Plan as a Participation, in terms of role and optionally function, mode and specific performer as appropriate.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_task_participation_class"><a class="anchor" href="#_task_participation_class"></a>6.2.5.6. TASK_PARTICIPATION Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>TASK_PARTICIPATION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Class defining a participation in Task(s), minimally in terms of function. Optionally, the role and mode may also be specified. The performer attribute enables a specific actor to be specified.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>function</strong>: <code>DV_TEXT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>The function of the Party in this participation (note that a given party might participate in more than one way in a particular activity). This attribute should be coded.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>role</strong>: <code>List&lt;DV_TEXT&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Organisational role, i.e. the professional type of participant in the activity. Preferably coded.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>mode</strong>: <code>DV_CODED_TEXT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional field for recording the 'mode' of the performer / activity interaction, e.g. present, by telephone, by email etc.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>performer</strong>: <code>PARTY_PROXY</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>The id and possibly demographic system link of the party participating in the activity.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>optionality</strong>: <code>VALIDITY_KIND</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Condition for participation in the Plan item.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_plan_item_class"><a class="anchor" href="#_plan_item_class"></a>6.2.5.7. PLAN_ITEM Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong><em>PLAN_ITEM (abstract)</em></strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Parent type of structural Task types that may appear within a Task Plan structure.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>LOCATABLE</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>description</strong>: <code>DV_TEXT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Human-readable form of the task directive.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>repeat_spec</strong>: <code>TASK_REPEAT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional specification of repetitions.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>classification</strong>: <code>ITEM_STRUCTURE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Archetypable structure for recording classification of Task Groups or Tasks, e.g. business process category, administrative category etc.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>wait_spec</strong>: <code>TASK_WAIT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional wait specification for Plan Item (Task or Group) initiation. If not set, the Plan Item is immediately <code>available</code> once execution reaches it. If set, it becomes <code>available</code> when any Event in <code><em>events</em></code> occurs.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>review_dataset</strong>: <code>List&lt;REVIEW_DATASET_SPEC&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional data-set to review prior to / as part of performing the Plan element.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>guideline_step</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional reference to a step within the <code><em>guideline</em></code> referenced by the current Task Plan (if set) or else the <code><em>care_pathway</em></code> of the Work Plan, which is the basis of this Plan Item, i.e. single Task or Task Group.</p>
</div>
<div class="paragraph">
<p>The reference may take the form of a plain text section or item name within the referenced guideline, e.g. '"Check heart rate"' or be a URI or path reference, if the guideline has an online machine-representation.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>other_details</strong>: <code>ITEM_STRUCTURE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Archetypable structure for recording non hard-modelled information.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>reminders</strong>: <code>List&lt;REMINDER&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional wait state(s) that may be used to remind the Task performer to do something based on a Timer or other Event. Will be cancelled by the Task transitioning to any new state from the <code>available</code> state, due to performer activity.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_task_repeat_class"><a class="anchor" href="#_task_repeat_class"></a>6.2.5.8. TASK_REPEAT Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>TASK_REPEAT</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Definition of repetition for a Plan Item. The <code><em>repeats</em></code> attribute states the number of repeats. Here, 'repeats' means additional executions, i.e. not counting the original execution. If not set, any number of repeats is allowed. The minimum number of repeats is set by the lower bound of <code><em>repeats</em></code>.</p>
</div>
<div class="paragraph">
<p>If set, the <code><em>terminate_condition</em></code> attribute defines when repetition should cease, once the minimum number of repeats has occurred according to <code><em>repeats</em></code>. It is expressed in terms of a condition, typically a subject-related variable. It is tested after prior to each new potential execution following the minimum number.</p>
</div>
<div class="paragraph">
<p>If <code><em>period</em></code> is set, this defines the duration between the start of each iteration at execution time. It has the effect at runtime of adding a <code><em>wait_spec</em></code> with a <code>TIMELINE_MOMENT</code> event to each <code>PLAN_ITEM</code> copy in the materialised form, i.e. creating the same structure as would have been created if the repetitions had been manually specified.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>repeats</strong>: <code>Interval&lt;Integer&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Range of repetitions. If the lower limit is greater than zero, at least one repeat is required. A range such as 0..3 means up to 3 repeats possible, but not required.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>terminate_condition</strong>: <code>PLAN_EVENT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>States a condition for when repetition should stop. If set, tested prior to each further potential repetition once the minimum number have been executed.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>period</strong>: <code>Iso8601_duration</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional period of repetition, i.e. duration between the commencement of each <code>PLAN_ITEM</code> clone in the materialised form.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_task_group_structure"><a class="anchor" href="#_task_group_structure"></a>6.3. Task Group Structure</h3>
<div class="paragraph">
<p>The set of Tasks in a Task Plan is represented within a containment structure created using instances of the <code>TASK_GROUP</code> class, which has three key attributes. Execution of a Group is primarily controlled by the <code><em>execution_type</em></code> and <code><em>concurrency_mode</em></code> attributes, which respectively indicate sequential or parallel processing, and for the latter case, various modes of <code>and</code> and <code>or</code> parallel processing logic (described in the next section), common to workflow formalisms. For more exotic situations, the <code><em>execution_rules</em></code> attribute can be used.</p>
</div>
<div class="paragraph">
<p><code>TASK_GROUP</code> also has a <code><em>training_level</em></code> attribute which enables different visibility of Sub-Plans to users with different experience levels. This is described more fully <a href="#_training_level">below</a>.</p>
</div>
<div class="paragraph">
<p>The Task Group construct enables two important ways to relate Tasks together:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>as a <em>module</em> of work consisting of a series of Tasks, achieved by a Task Group with <code><em>execution_type</em> = sequential</code>;</p>
</li>
<li>
<p>as a set of possible or mandatory <em>concurrent threads of work</em>, achieved by a Task Group with <code><em>execution_type</em> = parallel</code>.</p>
</li>
</ul>
</div>
<div class="sect3">
<h4 id="_sequential_task_groups"><a class="anchor" href="#_sequential_task_groups"></a>6.3.1. Sequential Task Groups</h4>
<div class="paragraph">
<p>A sequential Task Group corresponds to a single thread of processing at execution time, in which each of the Tasks becomes available to the worker (i.e. Task Plan&#8217;s <code><em>principal_performer</em></code>) <em>in order</em>, and according to the specific conditions associated with each Task. The following illustrates a sequential Task Group in TP-VML. Note that although there is visually an end-group icon (right hand end), there is no separate class or instance in the model - both the start-group and end-group icons visually represent the <code>TASK_GROUP</code> as a logical container.</p>
</div>
<div id="task_group_sequential" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/task_group_sequential.svg" alt="task group sequential" width="45%">
</div>
<div class="title">Figure 17. Sequential Task Group</div>
</div>
</div>
<div class="sect3">
<h4 id="_parallel_task_groups_and_concurrency"><a class="anchor" href="#_parallel_task_groups_and_concurrency"></a>6.3.2. Parallel Task Groups and Concurrency</h4>
<div class="paragraph">
<p>The parallel Task Group represents a different degree of complexity, since it enables concurrent threads of work at execution time. In terms of YAWL and Petri net workflow theory, a parallel Task Group corresponds to paired <em>split</em> and <em>join</em> points. The following illustrates a parallel Task Group in TP-VML. The multi-point shape of the exit and entry elements is intended to convey the idea of multiple possible branches (the limitation of 3 points is purely visual, semantically, any number of branches is supported).</p>
</div>
<div id="task_group_parallel" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/task_group_parallel.svg" alt="task group parallel" width="25%">
</div>
<div class="title">Figure 18. Parallel Task Group</div>
</div>
<div class="paragraph">
<p>The first difference between a parallel Group and a sequential one is that when a parallel Group is arrived at in the control flow, once any wait state is satisfied, the first Task in <em>all of the outgoing branches</em> is made <code>available</code>. Subsequent execution behaviour depends on the type of split and join logic (i.e. AND, OR, XOR, or other) which is represented by the attribute <code>TASK_GROUP.<em>concurrency_mode</em></code>, whose possible values indicate to the execution engine three things:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>how many branches may be commenced;</p>
</li>
<li>
<p>how commencing a branches affects other branches;</p>
</li>
<li>
<p>under what conditions to consider the group has completed.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Here, the notion of 'completion' corresponds to the <code>completed</code> state in the Task lifecycle state machine described earlier, inferred from the completion states of the items in the branches. The detail of how Task Group lifecycle state is aggregated from contained items is described in detail in <a href="#_aggregate_lifecycle_state">Section 7.3</a>. Here we describe only the logic determining the <code>completed</code> state, for the sake of simplicity.</p>
</div>
<div class="paragraph">
<p>The AND case is the simplest, since there is no conditional processing - all paths must be followed. An AND Group essentially represents work that should be performed, but for which the ordering is more relaxed than for a strict sequential Group.</p>
</div>
<div class="paragraph">
<p>The XOR case represents a 1/N choice, and is understood in this specification as representing the <em>intent</em> that only one path can sensibly be followed, usually because the branches are mutually exclusive alternatives in reality. Consequently, in execution, an XOR Group is processed such that as soon as one branch is chosen by a performer transitioning a Task from the <code>available</code> state, <em>the first Task in all remaining branches is transitioned to</em> <code>cancelled</code>, effectively cancelling the non-chosen branches. In this case completion is also trivial to determine.</p>
</div>
<div class="paragraph">
<p>However the OR case is more complicated. A minimal interpretation of 'OR' logic is that as soon as one branch in the Group completes, the Group is considered <code>completed</code>, and no more Tasks from other branches are available to perform. A maximal interpretation is that Group completion is achieved only when every path commenced completes. The model represents these two cases explicitly, via the values <code>or_first_completed</code> and <code>or_all_started</code> respectively of <code>TASK_GROUP.<em>concurrency_mode</em></code>.</p>
</div>
<div class="paragraph">
<p>The following table summarises the semantics of the four concurrency modes.</p>
</div>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 20%;">
<col style="width: 10%;">
<col style="width: 10%;">
<col style="width: 30%;">
<col style="width: 30%;">
</colgroup>
<thead>
<tr>
<th class="tableblock halign-left valign-top">Concurrency mode</th>
<th class="tableblock halign-left valign-top">TP-VML</th>
<th class="tableblock halign-left valign-top">Logic</th>
<th class="tableblock halign-left valign-top">Split<br>
                                     behaviour</th>
<th class="tableblock halign-left valign-top">Join<br>
                                                behaviour</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>and_all_paths</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="task_group_parallel_and" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/task_group_parallel_and.svg" alt="task group parallel and">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">AND</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">All branches are followed.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Group completes when all branches complete.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>xor_one_path</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="task_group_parallel_xor" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/task_group_parallel_xor.svg" alt="task group parallel xor">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">XOR</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Only one branch can be started; once a branch is commenced, the first Task in remaining branches is transitioned to <code>cancelled</code>.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Group completes when the started branch completes; equivalent to a sequential Group, once a branch is chosen.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>or_all_started</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="task_group_parallel_or_all" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/task_group_parallel_or_all.svg" alt="task group parallel or all">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">partial AND</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">One or more branches may be commence.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">The Group is complete when all branches commenced have completed; equivalent to an AND consisting of all commenced branches.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>or_first_completed</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="task_group_parallel_or_first" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/task_group_parallel_or_first.svg" alt="task group parallel or first">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">OR</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">One or more branches may be commenced.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">The Group is complete when one branch completes.</p></td>
</tr>
</tbody>
</table>
<div class="paragraph">
<p>The parallel / concurrent semantics attached to the Task Group do not indicate anything about decisional processing, i.e. the conditions that might be used to choose outgoing paths from the split point represented by a Task Group in the XOR and OR logic cases. Consequently, the choice of path(s) to follow in the parallel case is determined <em>by the performer, not the system</em>. In order to specify conditions on paths, the conditional subtypes <a href="#_decision_structures">described below</a> are used.</p>
</div>
</div>
<div class="sect3">
<h4 id="_hierarchical_nesting"><a class="anchor" href="#_hierarchical_nesting"></a>6.3.3. Hierarchical Nesting</h4>
<div class="paragraph">
<p>Task Groups of sequential and parallel types may be mixed in a hierarchical fashion. One structure is such that the overall work of a Task Plan is defined as a sequential Group in which some members are a parallel Group, as shown below.</p>
</div>
<div id="task_grouping" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/task_grouping.svg" alt="task grouping" width="75%">
</div>
<div class="title">Figure 19. Nested Task grouping - sequential structure</div>
</div>
<div class="paragraph">
<p>Similarly, the outermost Group may be parallel, with the work being defined as sections of sequential work situated within a parallel Task Group, as shown below.</p>
</div>
<div id="task_grouping2" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/task_grouping2.svg" alt="task grouping2" width="75%">
</div>
<div class="title">Figure 20. Nested Task grouping - parallel chains</div>
</div>
</div>
<div class="sect3">
<h4 id="_generic_execution_time_semantics"><a class="anchor" href="#_generic_execution_time_semantics"></a>6.3.4. Generic Execution-time Semantics</h4>
<div class="paragraph">
<p>The combination of the Task Group / Task hierachical pattern, which implicitly defines the graph structure of the 'normal flow' of a Task Plan, and the generic control attributes defined on <code>TASK</code> and its descendant types enable a significant amount of execution-time Plan processing to be implemented independently of any specific Task semantics.</p>
</div>
</div>
<div class="sect3">
<h4 id="_well_formedness"><a class="anchor" href="#_well_formedness"></a>6.3.5. Well-formedness</h4>
<div class="paragraph">
<p>A significant consequence of the Task Group construct in the TP model is that each Task Group forms a sub-network within its container, where a <em>network</em> is understood in the graph theory sense of a directed graph with a start <code>s</code> and terminal node <code>t</code>, containing paths from <code>s</code> to <code>t</code> n which all member elements are found. This holds for descendant types of <code>TASK_GROUP</code>, including the <a href="#_decision_structures">Decision Structures</a> described below. This is a more limited form of connectivity than allowed in YAWL or BPMN, which do not require matched split and join points.</p>
</div>
</div>
<div class="sect3">
<h4 id="_training_level"><a class="anchor" href="#_training_level"></a>6.3.6. Training Level</h4>
<div class="paragraph">
<p>One challenge with creating Task Plan definitions is the level of detail to use, with respect to the variable level of skill of different performers. For a senior nurse, a briefer version of the Plan would be preferable with actions such as 'set up IV with catheter' being a single atom, whereas a trainee may need to see a more detailed set of sub-tasks.</p>
</div>
<div class="paragraph">
<p>To enable a single Plan to be used in both ways, the concept of 'training level' is included in the model, on the <code>TASK_GROUP</code> class. This enables any Group of Tasks to be marked as having a specific training level, where a higher number corresponds to less experience. At execution time, the training level of the allocated performer can be obtained, and then used in comparison to the training level indicated on each Group (including the top-level Group of the whole Plan). If the user training level is higher, then the Group may be shown only as a single step (using its <code><em>description</em></code>, inherited from <code>PLAN_ITEM</code>); otherwise it may be shown as the set of sub-steps. This provides a simple way for the same Plan to be presented in different forms matching different performer experience levels.</p>
</div>
<div class="paragraph">
<p>The default value of <code><em>training_level</em></code> is 0.</p>
</div>
</div>
<div class="sect3">
<h4 id="_class_definitions_2"><a class="anchor" href="#_class_definitions_2"></a>6.3.7. Class Definitions</h4>
<div class="sect4">
<h5 id="_task_group_class"><a class="anchor" href="#_task_group_class"></a>6.3.7.1. TASK_GROUP Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>TASK_GROUP</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Grouping structure that defines the graph structure of a Task Plan, replacing node-to-node references.</p>
</div>
<div class="paragraph">
<p>This allows Task Group to define the execution basis for a collection of Tasks, which may include more Task groups.</p>
</div>
<div class="paragraph">
<p>The <code><em>execution_type</em></code> attribute defines the mode of execution. If not set, sequential execution is assumed.</p>
</div>
<div class="paragraph">
<p>If set to <code>parallel</code>, the Task Group represents a split/join pair with respect to all contained Tasks and Groups. In this case, <code><em>concurrency_mode</em></code> may be set to control the processing. If it is not set, 'AND' logic is assumed (i.e. <code>and_all_paths</code>).</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>PLAN_ITEM</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>members</strong>: <code>List&lt;PLAN_ITEM&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Set of Tasks to perform. Execution order is defined by the <code><em>execution_type</em></code> setting, either sequential or parallel (no order).</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>execution_type</strong>: <code>EXECUTION_TYPE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Basis for executing the Task items contained in this Task Group.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>concurrency_mode</strong>: <code>CONCURRENCY_MODE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Mode in which to execute if execution type is parallel.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>execution_rules</strong>: <code>List&lt;EXECUTION_RULE&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Other rules that may control execution over and above the basic sequential / parallel scheme, e.g.</p>
</div>
<div class="ulist">
<ul>
<li>
<p>at least N members must complete for group to complete;</p>
</li>
<li>
<p>exit group on first succeeding task.</p>
</li>
</ul>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>training_level</strong>: <code>Integer</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>An integer value representing the training level for which this Task Plan is designed. A high value corresponds to a lower level of expertise. The default value is zero.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_execution_type_enumeration_2"><a class="anchor" href="#_execution_type_enumeration_2"></a>6.3.7.2. EXECUTION_TYPE Enumeration</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Enumeration</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>EXECUTION_TYPE</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Enumeration specifying types of execution for a set of Tasks.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">sequential</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Items execute in order, one after the other.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">parallel</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Items may be executed in parallel, with no regard to order in the representation.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_concurrency_mode_enumeration"><a class="anchor" href="#_concurrency_mode_enumeration"></a>6.3.7.3. CONCURRENCY_MODE Enumeration</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Enumeration</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>CONCURRENCY_MODE</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Mode in which concurrent processing should proceed.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">xor_one_path</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Only one parallel path is followed.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">and_all_paths</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>All paths are followed, and Group completes only when all complete.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">or_first_completed</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Group completes when any one path completes.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">or_all_started</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Group is complete when all paths commenced complete.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_execution_rule_class"><a class="anchor" href="#_execution_rule_class"></a>6.3.7.4. EXECUTION_RULE Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>EXECUTION_RULE</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Rule controlling execution in addition to basic sequential / parallel setting.</p>
</div>
<div class="paragraph">
<p>TODO: define detail.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_general_task_semantics"><a class="anchor" href="#_general_task_semantics"></a>6.4. General Task Semantics</h3>
<div class="sect3">
<h4 id="_dispatchable_and_performable_tasks"><a class="anchor" href="#_dispatchable_and_performable_tasks"></a>6.4.1. Dispatchable and Performable Tasks</h4>
<div class="paragraph">
<p>Tasks are represented by the <code>TASK</code> class whose two concrete sub-types distinguish the two basic flavours of Task, namely <em>dispatchable</em> and <em>performable</em>. <code>TASK</code> is a generic (i.e. templated) class, whose generic parameter is constrained to the type <code>TASK_ACTION</code>, the latter of whose subtypes defined the particular kinds of Tasks available.</p>
</div>
<div class="paragraph">
<p>The <code>DISPATCHABLE_TASK&lt;T&gt;</code> class has two attributes to do with managing context change and callback. The <code><em>wait</em></code> flag indicates whether the current Task waits (i.e. blocks) while the dispatched work is performed, or whether it continues on asynchronously. The first constitutes a context switch, the second a context fork. The <code><em>callback</em></code> attribute attaches a special kind of Event wait state that is triggered on receipt of a callback. How callbacks function in detail is <a href="#_callbacks">described below</a>.</p>
</div>
<div class="paragraph">
<p>There are some key differences between the two kinds of Task as shown in the following table.</p>
</div>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 14.2857%;">
<col style="width: 42.8571%;">
<col style="width: 42.8572%;">
</colgroup>
<thead>
<tr>
<th class="tableblock halign-left valign-top">Task Type</th>
<th class="tableblock halign-left valign-top">Description</th>
<th class="tableblock halign-left valign-top">Lifecycle state</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><em>Performable</em></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Task performed by the current performer.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Advanced by actions of performer (real world actor)</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><em>Dispatchable</em></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">A Task whose work is dispatched for execution to another performer or system.</p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock"><em>wait</em> = <code>True</code>: Advanced by receipt of callback notification<br>
                                                                                                <em>wait</em> = <code>False</code>: Automatically advanced to <code>completed</code></p></td>
</tr>
</tbody>
</table>
</div>
<div class="sect3">
<h4 id="_class_definitions_3"><a class="anchor" href="#_class_definitions_3"></a>6.4.2. Class Definitions</h4>
<div class="sect4">
<h5 id="_taskta_class"><a class="anchor" href="#_taskta_class"></a>6.4.2.1. TASK&lt;TA&gt; Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong><em>TASK&lt;TA&gt; (abstract)</em></strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Atomic Task that is typed according to the kind of <code>TASK_ACTION</code> it includes. A <code>TASK</code> has a lifecycle that can be progressed in the plan execution, i.e. in the Materialised form.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>PLAN_ITEM</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>action</strong>: <code>TA</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Task Action definition.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>order_tags</strong>: <code>List&lt;String&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>References to order(s) being created and / or tracked by this Task. The value(s) must match <code>ORDER_REF.<em>order_tag</em></code> values from the list <code>WORK_PLAN.<em>order_list</em></code> and be unique within the list.</p>
</div>
<div class="paragraph">
<p>Multiple tags are only required if the same Task causes creation of, or tracks, more than one order.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Invariants</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p><em>Inv_order_tags</em>: <code>order_tags /= Void implies not order_tags.is_empy</code></p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_dispatchable_taskta_class"><a class="anchor" href="#_dispatchable_taskta_class"></a>6.4.2.2. DISPATCHABLE_TASK&lt;TA&gt; Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>DISPATCHABLE_TASK&lt;TA&gt;</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Type of Task representing work to be performed by another actor. Such Tasks are 'dispatchable' in the sense that they consist of notifying a request for specific work to be done by another principal performer, or an external system or service. The details of the target  are defined in <code><em>action</em></code>.</p>
</div>
<div class="paragraph">
<p>If <code><em>wait</em></code> is True, the Task blocks until the target work thread returns. If <code><em>callback</em></code> is set, specific processing can be performed on the return, before execution progresses. If it is not set, the Task completes normally on target completion, and execution continues to the next Task. In this case (<code><em>wait</em> = True</code>, no <code><em>callback</em></code>), a global timer will be created for the Task to deal with the situation where the dispatch target never returns.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>TASK</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>wait</strong>: <code>Boolean</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Flag indicating whether to wait or continue in the current Plan after the dispatch notification has been achieved. <code><em>wait</em> = True</code> corresponds to a context switch (block and wait) while <code><em>wait</em> = False</code> indicates a context fork.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>callback</strong>: <code>CALLBACK_WAIT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional callback notification handler.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_performable_taskta_class"><a class="anchor" href="#_performable_taskta_class"></a>6.4.2.3. PERFORMABLE_TASK&lt;TA&gt; Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>PERFORMABLE_TASK&lt;TA&gt;</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Represents a Task that can be performed by the principal performer during the Plan execution.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>TASK</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>capture_dataset</strong>: <code>List&lt;CAPTURE_DATASET_SPEC&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Associated data-set template and/or form via which data to be captured during this Task will actually be entered.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_task_actions"><a class="anchor" href="#_task_actions"></a>6.5. Task Actions</h3>
<div class="paragraph">
<p>The specific definition of the work of Tasks is provided by <code>TASK.<em>action</em></code>, of type <code>TASK_ACTION</code> and its subtypes. Two abstract sub-types <code>DISPATCHABLE_ACTION</code> and <code>PERFORMABLE_ACTION</code> distinguish the <em>dispatchable</em> and <em>performable</em> flavours of Task Action, corresponding to the two <code>TASK</code> subtypes. The following UML diagram shows <code>TASK_ACTION</code> and its subtypes in detail.</p>
</div>
<div id="rm_definition_actions" class="imageblock text-center text-center">
<div class="content">
<img src="UML/diagrams/PROC-task_planning.definition-actions.svg" alt="PROC task planning.definition actions">
</div>
<div class="title">Figure 21. proc.task_planning.definition model - Task Actions</div>
</div>
<div class="paragraph">
<p><code>TASK_ACTION</code> includes two attributes that apply to all subtypes. The first is <code><em>subject_preconditions</em></code>, which enables subject-related preconditions to be expressed, i.e. conditions referencing variables relating to the subject such as vital signs. These preconditions can be understood as conditions for safe processing, and should either be satisfied before proceeding, or else overridden by a competent performer who understands the implications.</p>
</div>
<div class="paragraph">
<p>A subject precondition is formally represented as a <code>BOOLEAN_CONTEXT_EXPRESSION</code>, whose <code><em>expression</em></code> value is a string in <a href="https://specifications.openehr.org/releases/LANG/latest/expression_language.html" target="_blank" rel="noopener">openEHR Expression Language</a> syntax.</p>
</div>
<div class="paragraph">
<p>Pre-conditions are evaluated at the point at which the Task to which they are attached becomes available during execution. If any pre-condition evaluates to False, the Task is in theory unable to be performed. A clinical professional may override at execution time, since it may always be the case that particular circumstances obviate the need for a particular pre-condition that normally applies.</p>
</div>
<div class="paragraph">
<p>The second generally applicable attribute is <code><em>costing_data</em></code>, since cost information may clearly be relevant to any Plan item. Costing is dealt with in detail below.</p>
</div>
<div class="paragraph">
<p>Performable Actions have two attributes. The <code><em>other_participations</em></code> and <code><em>resources</em></code> attributes allow other performers and passive resources to be defined for an Action. Both are subject to an allocation process at execution time, similar to that of the <code><em>principal_performer</em></code>.</p>
</div>
<div class="paragraph">
<p>The subtypes of <code>TASK_ACTION</code> consist of the following:</p>
</div>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 14.2857%;">
<col style="width: 14.2857%;">
<col style="width: 71.4286%;">
</colgroup>
<thead>
<tr>
<th class="tableblock halign-left valign-top">Type</th>
<th class="tableblock halign-left valign-top">TP-VML</th>
<th class="tableblock halign-left valign-top">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>DEFINED_ACTION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="task_defined_task" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/task-defined_task.svg" alt="task defined task">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">An inline-defined Task to be performed by the principal performer of the Group (see below for details);</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>SUB_PLAN</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="task_sub_plan" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/task-sub_plan.svg" alt="task sub plan">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">A kind of Task that stands for another Task Plan (identified by the inherited <code>LINKED_PLAN.<em>target</em></code> attribute) to be performed by the current performer - usually a fine-grained set of steps designed to achieve the result of this Task.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>SYSTEM_REQUEST</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="task_system_request" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/task-system_request.svg" alt="task system request">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">A kind of Task that consists of a request to a computational system, such as a data retrieval or procedure call, on behalf of the current performer;</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>HAND_OFF</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="task_hand_off" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/task-hand_off.svg" alt="task hand off">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">A kind of Task that hands off to another Task Plan in the same Work Plan, having a different performer (identified via the <code><em>target</em></code> attribute inherited from <code>LINKED_PLAN</code>);</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>EXTERNAL_REQUEST</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="task_external_request" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/task-external_request.svg" alt="task external request">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">A Task type that consists of a request to an external organisational entity that is outside the current Work Plan and its execution environment, on behalf of the current performer;</p></td>
</tr>
</tbody>
</table>
<div class="paragraph">
<p>The following sections provide more detail on some of these model features.</p>
</div>
<div class="sect3">
<h4 id="_performable_actions"><a class="anchor" href="#_performable_actions"></a>6.5.1. Performable Actions</h4>
<div class="sect4">
<h5 id="_sub_plans_and_re_use"><a class="anchor" href="#_sub_plans_and_re_use"></a>6.5.1.1. Sub-plans and Re-use</h5>
<div class="paragraph">
<p>As described above, multiple Task Plans may be used to define a single logical plan of work. This occurs for two main reasons:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>re-use</em>: Task Plans that can be used on their own, e.g. 'set up IV drip', are combined within a larger plan;</p>
</li>
<li>
<p><em>level of granularity</em>: a Task Plan can contain Tasks that can be represented as finer-grained Task Plans, which may potentially be used or passed over depending on the level of experience, known here as <em>training level</em> of the performer.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The following instance diagram illustrates.</p>
</div>
<div id="task_linking" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/task_linking.svg" alt="task linking">
</div>
<div class="title">Figure 22. Task Plan linking</div>
</div>
<div class="paragraph">
<p>This shows a Plan for dialysis with a single performer, 'dialysis nurse', and several sub-plans, each referred to by an instance of the <code>SUB_PLAN</code> class. Since a Sub-plan is a kind of Task, it has a <em>description</em> and could be performed and signed off as if it were a normal inline <code>DEFINED_ACTION</code> by an experienced performer (training level high), or it might be entered into by a performer such as a trainee nurse. The <code>TASK_GROUP.<em>training_level</em></code> attribute can be used to set the experience level of sub-plans if required; implementing this behaviour at execution time would rely in the Plan execution engine using this setting.</p>
</div>
</div>
<div class="sect4">
<h5 id="_inline_defined_actions"><a class="anchor" href="#_inline_defined_actions"></a>6.5.1.2. Inline Defined Actions</h5>
<div class="paragraph">
<p>Tasks whose definitions are stated within a Task Plan are modelled using the <code>DEFINED_ACTION</code> type. A detailed specification of the work to be done in a Defined Action  may be stated via optional atttribute <code><em>prototype</em></code> of type <code>ENTRY</code>, which enables the details of a Task to be specified in terms of a descendant of the <code>ENTRY</code> class. This is typically an <code>ACTION</code> instance but could be an <code>OBSERVATION</code>, <code>ADMIN_ENTRY</code> or other descendant. The following view of the UML illustrates.</p>
</div>
<div id="proc_task_planning_definition_defined_task" class="imageblock text-center text-center">
<div class="content">
<img src="UML/diagrams/PROC-task_planning.definition-defined_task.svg" alt="PROC task planning.definition defined task" width="50%">
</div>
<div class="title">Figure 23. proc.task_planning.definition - Definition Task</div>
</div>
<div class="paragraph">
<p>The attribute is called 'prototype' because the target Entry instance is understood as a partially populated, prototype 'planning time' partial copy of an Entry that will be created when the Task is actually performed. For example, a Task Plan for administering medication at 8 hourly intervals over a number of days could consist of a number of <code>DEFINED_ACTIONs</code>, each having a protoype of an <code>ACTION</code> instance based on the <code>openEHR-EHR-ACTION.medication.v1</code> archetype or a templated version thereof. Each such instance would contain the structured description of the medication administration and time, and when the administration was actually performed, an <code>ACTION</code> instance would be created from the prototype, modified to reflect any divergence from the planned form of the Task, and committed to the EHR in the normal way.</p>
</div>
<div class="paragraph">
<p>The following illustrates Task definitions using prototypes.</p>
</div>
<div id="task_definition" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/task_definition.svg" alt="task definition" width="55%">
</div>
<div class="title">Figure 24. Task definition</div>
</div>
<div class="paragraph">
<p>Assuming that the Task Plan is archetyped in the same way as Entries and other elements of the EHR, this scheme supports various modes of design-time specification. The <code><em>prototype</em></code> attribute in a <code>TASK_PLAN</code> archetype will usually be represented by an archetype slot or external reference, which specifies identifiers of permitted archetypes (or templates) of the target type, i.e. <code>ACTION</code> or other Entry. This can be used in various ways, as follows:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><a href="https://specifications.openehr.org/releases/AM/latest/ADL2.html#_external_references">external reference</a>: specifies a fixed archetype identifier which will be substituted in the templated form of the Task Plan. This has the effect of creating <code>ACTION</code> or other prototype instances in the <code>TASK_PLAN</code> structure;</p>
</li>
<li>
<p><a href="https://specifications.openehr.org/releases/AM/latest/ADL2.html#_archetype_slots">archetype slot</a>: specified using a slot constraint that is satisfied by one or more archetypes that may be specified by a template, or left open until runtime.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>In the latter case, the slot may be filled in the Task Plan template with an <code>ACTION</code> or other Entry archetype, allowing the Tasks to be fully specified inline as in the external reference case. Alternatively, it may be left unresolved, which would allow the workflow application to choose the exact Task definition archetype at runtime.</p>
</div>
<div class="paragraph">
<p>One reason to allow a Task to contain a <code><em>prototype</em></code> reference that remains unresolved until runtime is if the Task represents the act of making an observation, for example, taking a blood pressure. In such cases, no prototype at all may be needed, and the Task <code><em>description</em></code> attribute (inherited from <code>PLAN_ITEM</code>) may be sufficient information for the performer. On the other hand, a prototype <code>OBSERVATION</code> could be specified in the <code>TASK_PLAN</code> template, which defines a particular form of the observation, e.g. a blood pressure which only records mean arterial pressure and cuff size.</p>
</div>
<div class="paragraph">
<p>To allow further flexibility, The multiplicity of the <code><em>prototype</em></code> attribute is unlimited, to allow for the possibility of one Task being prototyped by more than one Entry instance, e.g. an <code>ACTION</code> and an <code>OBSERVATION</code>, two <code>ADMIN_ENTRY</code> instances and so on.</p>
</div>
</div>
</div>
<div class="sect3">
<h4 id="_dispatchable_actions"><a class="anchor" href="#_dispatchable_actions"></a>6.5.2. Dispatchable Actions</h4>
<div class="paragraph">
<p>The type <code>DISPATCHABLE_ACTION</code> is the abstract parent of various Action subtypes that represent work requested to be done by some other agent, i.e. external to the current Task Plan. The three sub-types correspond to 3 different types of other performer, i.e.:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code>HAND_OFF</code>: another principle performer in the same Work Plan;</p>
</li>
<li>
<p><code>EXTERNAL_REQUEST</code>: a performer outside the current Work Plan computational environment.</p>
</li>
<li>
<p><code>SYSTEM_REQUEST</code>: a computation to be performed by a system call;</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The general execution scheme for such Actions is as follows:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>dispatch</em> the work request to a target actor or service;</p>
</li>
<li>
<p><em>block or continue</em>, according to the <code><em>wait</em></code> flag, which determines switch or fork behaviour; and</p>
</li>
<li>
<p>process any <em>callback notification</em>, specified via the <code><em>callback</em></code> attribute.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The following sub-sections described the various subtypes of <code>DISPATCHABLE_ACTION</code>, while callbacks are described in detail further down.</p>
</div>
<div class="sect4">
<h5 id="_hand_offs_and_coordinated_teamwork"><a class="anchor" href="#_hand_offs_and_coordinated_teamwork"></a>6.5.2.1. Hand-offs and Coordinated Teamwork</h5>
<div class="paragraph">
<p>Work Plans may be designed to contain multiple Task Plans, each corresponding to a team worker. In the execution of such a Work Plan, the performer of any Task Plan may at some point need to hand off to another performer, i.e. one of the other Task Plans in the same Work Plan. As described above, the original worker may wait or continue, and in both cases, receipt of a callback notification from the other Task Plan may cause a change in the execution path of the first Plan.</p>
</div>
<div class="paragraph">
<p>The following illustrates, using the example of an acute stroke management care process.</p>
</div>
<div id="task_coordination" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/task_coordination.svg" alt="task coordination">
</div>
<div class="title">Figure 25. Task coordination</div>
</div>
<div class="paragraph">
<p>In this Work Plan, three Task Plans are used to perform (parts of) the clinical work coordinated for managing an acute stroke, as per a Care Pathway. There are two Hand-offs, the first synchronous (<code><em>wait</em></code> = <code>True</code>; callback wait resumes at the next Task) and the second an asynchronous fork (<code><em>wait</em></code> = <code>False</code>).</p>
</div>
</div>
<div class="sect4">
<h5 id="_external_request"><a class="anchor" href="#_external_request"></a>6.5.2.2. External Request</h5>
<div class="paragraph">
<p>The Task sub-type <code>EXTERNAL_REQUEST</code> represents a request by the current performer to an external entity completely outside of the current Work Plan computational context, to request some work on behalf of the performer. This is typically an organisation of which routine requests can be made (e.g. pathology laboratory). The request has to be defined generically, in terms of an organisation identifier, a request identifier (i.e. a name or type of job) and a list of other details, represented by the standard archetypable <code>ITEM_STRUCTURE</code>.</p>
</div>
</div>
<div class="sect4">
<h5 id="_system_request"><a class="anchor" href="#_system_request"></a>6.5.2.3. System Request</h5>
<div class="paragraph">
<p>The Task sub-type <code>SYSTEM_REQUEST</code> represents a request to a <em>system</em> with a computational interface on behalf of the performer, such as a logging facility or a decision support system. The request is defined in terms of a <code>SYSTEM_CALL</code> instance.</p>
</div>
</div>
</div>
<div class="sect3">
<h4 id="_class_definitions_4"><a class="anchor" href="#_class_definitions_4"></a>6.5.3. Class Definitions</h4>
<div class="sect4">
<h5 id="_task_action_class"><a class="anchor" href="#_task_action_class"></a>6.5.3.1. TASK_ACTION Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong><em>TASK_ACTION (abstract)</em></strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Abstract parent of Task Action types, which define the specifics of the work of a Task. All Task Actions may have subject preconditions (i.e. preconditions on the state of the subject) that must be met or overridden before proceeding; costing information; and one or more review data sets to display in the application environment.</p>
</div>
<div class="paragraph">
<p>Performable Actions have further properties.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>LOCATABLE</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>instruction_activity</strong>: <code>LOCATABLE_REF</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional reference back to the <code>ACTIVITY</code> of an <code>INSTRUCTION</code> that generated this <code>TASK</code>.</p>
</div>
<div class="paragraph">
<p>TODO: may be movable to <code>PERFORMABLE_ACTION</code>.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>subject_preconditions</strong>: <code>List&lt;SUBJECT_PRECONDITION&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Condition which must be met for the Task Action to be available to perform in a runtime execution context.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>costing_data</strong>: <code>TASK_COSTING</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Costing data related to this Task item.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_subject_precondition_class"><a class="anchor" href="#_subject_precondition_class"></a>6.5.3.2. SUBJECT_PRECONDITION Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>SUBJECT_PRECONDITION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Clinical preconditions expressing when the Task is safely executable with respect to the principal performer and subject.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>description</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Textual representation of preconditions for this Task to be performed, according to governing protocol. May be displayed as a safety check for human performer, e.g. 'patient no allergic to penicillin'.</p>
</div>
<div class="paragraph">
<p>Evaluated when encountered.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>expression</strong>: <code>BOOLEAN_CONTEXT_EXPRESSION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>An optional formal Boolean expression that can be machine-evaluated at runtime to determine availability, if the relevant variables exist.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_performable_action_class"><a class="anchor" href="#_performable_action_class"></a>6.5.3.3. PERFORMABLE_ACTION Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong><em>PERFORMABLE_ACTION (abstract)</em></strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Represents an Action that can be performed by the principal performer during the Plan execution. This is either inline defined or via reference to a sub-plan.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>TASK_ACTION</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>resources</strong>: <code>List&lt;RESOURCE_PARTICIPATION&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Descriptions of resources required for the Task, if required to be processed at runtime as pre-conditions to Task execution.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>other_participations</strong>: <code>List&lt;TASK_PARTICIPATION&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>List of participations for task item.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_resource_participation_class"><a class="anchor" href="#_resource_participation_class"></a>6.5.3.4. RESOURCE_PARTICIPATION Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>RESOURCE_PARTICIPATION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Description of a resource with optional external system reference.</p>
</div>
<div class="paragraph">
<p>TODO: explain <code><em>external_ref</em></code>.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>resource_type</strong>: <code>DV_TEXT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Text or coded description of resource.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>external_ref</strong>: <code>OBJECT_REF</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Reference to resource, e.g. in scheduling or other system.</p>
</div>
<div class="paragraph">
<p>TODO: may need to be a more powerful reference like a <code>SYSTEM_CALL</code>.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_defined_action_class"><a class="anchor" href="#_defined_action_class"></a>6.5.3.5. DEFINED_ACTION Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>DEFINED_ACTION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Task sub-type that represents concretely defined work items. The definition of the work of the Task is expressed in terms of archetype of an <code>ENTRY</code> (usually an <code>ACTION</code>) that will be used to record the Task&#8217;s execution.</p>
</div>
<div class="paragraph">
<p>The <code><em>entry_instance</em></code> attribute can be used to record a forward reference to an <code>ACTION</code> or other <code>ENTRY</code> when it has been recorded.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>PERFORMABLE_ACTION</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>prototype</strong>: <code>List&lt;ENTRY&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Prototype instance of one or more openEHR EHR Entries that express the specific work of the Task. Normally one Entry would be used, typically an <code>ACTION</code>, but more than one may sometimes make sense, e.g. an <code>ACTION</code> and an <code>OBSERVATION</code>.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>optionality</strong>: <code>VALIDITY_KIND</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Informal indication of whether Task is considered optional or not from the point of view of any guideline. If not set, the Task is treated as mandatory.</p>
</div>
<div class="paragraph">
<p>This attribute is not used computationally.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_sub_plan_class"><a class="anchor" href="#_sub_plan_class"></a>6.5.3.6. SUB_PLAN Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>SUB_PLAN</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>A Task referencing another Plan within the same Work Plan, to be executed by the current performer. Execution continues on from the previous Task.</p>
</div>
<div class="paragraph">
<p>For an experienced performer, the referenced Plan, which is usually more detailed may not be needed.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>LINKED_PLAN</code>, <code>PERFORMABLE_ACTION</code></p></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_dispatchable_action_class"><a class="anchor" href="#_dispatchable_action_class"></a>6.5.3.7. DISPATCHABLE_ACTION Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong><em>DISPATCHABLE_ACTION (abstract)</em></strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Type of Task Action that is performed by another performer, system or organisation.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>TASK_ACTION</code></p></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_hand_off_class"><a class="anchor" href="#_hand_off_class"></a>6.5.3.8. HAND_OFF Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>HAND_OFF</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>A kind of Task representing a hand-off to a different performer in the current Work Plan.</p>
</div>
<div class="paragraph">
<p>Tasks of the linked Plan become available to that performer, who is also alerted to start work.</p>
</div>
<div class="paragraph">
<p>A hand-off usually involves waiting with later notification (callback), or continuation. Waiting would typically mean the Plan execution engine places this Plan on a wait list, enabling the performer to proceed with work on other subjects.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>LINKED_PLAN</code>, <code>DISPATCHABLE_ACTION</code></p></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_external_request_class"><a class="anchor" href="#_external_request_class"></a>6.5.3.9. EXTERNAL_REQUEST Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>EXTERNAL_REQUEST</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Task type for representing a request to an external organisational service or actor not within the current Work Plan.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>DISPATCHABLE_ACTION</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>organisation</strong>: <code>PARTY_PROXY</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identifier of organisation to which the request or order is addressed.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>request_id</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Request identifier for this type request. May be used in callback notification. Other runtime instance-level identifiers may be needed as well.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>other_details</strong>: <code>ITEM_STRUCTURE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Request details.</p>
</div>
<div class="paragraph">
<p>TODO: more details needed.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_system_request_class"><a class="anchor" href="#_system_request_class"></a>6.5.3.10. SYSTEM_REQUEST Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>SYSTEM_REQUEST</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Request to an external computational system or service.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>DISPATCHABLE_ACTION</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>system_call</strong>: <code>SYSTEM_CALL</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Definition of call to make.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_linked_plan_class"><a class="anchor" href="#_linked_plan_class"></a>6.5.3.11. LINKED_PLAN Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong><em>LINKED_PLAN (abstract)</em></strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Task type that represents a dispatch to another Task Plan to be executed by another performer in a Plan Group.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>target</strong>: <code>TASK_PLAN</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Reference to target <code>TASK_PLAN</code> object.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_data_sets_and_application_interaction"><a class="anchor" href="#_data_sets_and_application_interaction"></a>6.6. Data-sets and Application Interaction</h3>
<div class="paragraph">
<p>In order for performers to execute Task Groups and individual Tasks with a Plan, specific data must often be reviewed to enable the performer to know how to proceed. This is generally the case for Tasks that involve administering drugs to a patient, where the dose depends on one or more variables relating to the patient state, such as ECG data, INR, heart rate etc.</p>
</div>
<div class="paragraph">
<p>To achieve this, the Task Planning model formalises the relationship between a 'data set' and a Task that may use it. A 'data-set' in openEHR is a template, normally displayed as a form within an application. In the Task Planning context, a data set may also be a sub-section of a template or form, specified by a path, to allow more than one Task to be used to construct each section of a form. The following UML diagram shows the data-set related classes in detail.</p>
</div>
<div id="proc_definition_dataset" class="imageblock text-center text-center">
<div class="content">
<img src="UML/diagrams/PROC-task_planning.definition-dataset.svg" alt="PROC task planning.definition dataset">
</div>
<div class="title">Figure 26. proc.task_planning.definition model overview</div>
</div>
<div class="paragraph">
<p>Two variants of data-set are defined, as follows:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>data display</em>: a <code>REVIEW_DATASET_SPEC</code> represents a template or part thereof that is to be displayed in order for the Task performer to do the work of the Task;</p>
</li>
<li>
<p><em>data capture</em>: a <code>CAPTURE_DATASET-SPEC</code> represents a template or part thereof that is to be populated by the work of the Task.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Either a template or form identifier (or both) maybe be used to specify a data-set. The <code><em>populating_call</em></code> attribute may be used to define a system call that will pre-populate either kind of data-set. The <code><em>form_section_path</em></code> attribute is populated if a data-set section (i.e. part of a form) needs to be specified.</p>
</div>
<div class="paragraph">
<p>A review data-set may be specified on any Plan Item (i.e. Task Group of Task, of any kind) via the attribute <code>PLAN_ITEM.<em>review_dataset</em></code>, in order to signal to the runtime system to request the display of data at the start of that part of the Plan.</p>
</div>
<div class="paragraph">
<p>A capture data-set may be specified for a <code>PERFORMABLE_TASK</code> only (since the work of the Task in this case is what achieves the desired data capture), via the <code><em>capture_dataset</em></code> attribute.</p>
</div>
<div class="paragraph">
<p>For reference, any review data-set may have any number of capture data-sets used to capture the data associated with it, via the <code>REVIEW_DATASET_SPEC.<em>capture_datasets</em></code> attribute. This enables the relationship between potentially numerous (typically small) forms/dialogs used to obtain data from users and the commonly larger forms used to display such data.</p>
</div>
<div class="paragraph">
<p>Both kinds of data sets described here may be the same as or related to templates and/or forms used in the generation of Task EHR data, mentioned in <code>PERFORMABLE_ACTION.<em>prototype</em></code> .</p>
</div>
<div class="sect3">
<h4 id="_class_definitions_5"><a class="anchor" href="#_class_definitions_5"></a>6.6.1. Class Definitions</h4>
<div class="sect4">
<h5 id="_dataset_spec_class"><a class="anchor" href="#_dataset_spec_class"></a>6.6.1.1. DATASET_SPEC Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong><em>DATASET_SPEC (abstract)</em></strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Specification of a related data-set and/or form to use with a Task, usually by means of display and/or data entry screens in an application being used by the principal performer.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>LOCATABLE</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>form_id</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Form identifier.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>template_id</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Template identifier in String form of an <code>ARCHETYPE_HRID</code>. If used with no <code><em>form_id</em></code>, the Execution engine needs to determine how to find a form based on the template identifier.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>other_details</strong>: <code>ITEM_STRUCTURE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Other data-set related details.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>populating_call</strong>: <code>SYSTEM_CALL</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional system call that will populate this data-set.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>form_section_path</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional path to a sub-section of the form identified by <code><em>form_id</em></code>. The format of the path is the same as a template or AQL path.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Invariants</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p><em>Inv_validity</em>: <code>form_id /= Void or template_id /= Void</code></p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_capture_dataset_spec_class"><a class="anchor" href="#_capture_dataset_spec_class"></a>6.6.1.2. CAPTURE_DATASET_SPEC Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>CAPTURE_DATASET_SPEC</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Specification of a related data capture data-set and/or form to use with a Task, usually by means data entry screens in an application being used by the principal performer.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>DATASET_SPEC</code></p></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_review_dataset_spec_class"><a class="anchor" href="#_review_dataset_spec_class"></a>6.6.1.3. REVIEW_DATASET_SPEC Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>REVIEW_DATASET_SPEC</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Specification of a related data display data-set and/or form to use with a Task, usually by means display screens in an application being used by the principal performer.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>DATASET_SPEC</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>capture_datasets</strong>: <code>List&lt;CAPTURE_DATASET_SPEC&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Capture data-sets (forms etc) used to obtain the data displayed in this Review data-set.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_decision_structures"><a class="anchor" href="#_decision_structures"></a>6.7. Decision Structures</h3>
<div class="sect3">
<h4 id="_overview_2"><a class="anchor" href="#_overview_2"></a>6.7.1. Overview</h4>
<div class="paragraph">
<p>More advanced applications of Task Plans include decision structures, in which one of multiple branches may be taken depending on specific conditions. There are four varieties of such structure, which are defined as specific descendants of the <code>TASK_GROUP</code> class, as shown in the following UML model.</p>
</div>
<div id="proc_task_planning_definition_decision" class="imageblock text-center text-center">
<div class="content">
<img src="UML/diagrams/PROC-task_planning.definition-decision.svg" alt="PROC task planning.definition decision">
</div>
<div class="title">Figure 27. proc.task_planning.choice package - decision structures</div>
</div>
<div class="paragraph">
<p>The <code>CHOICE_GROUP</code> class defines the essential semantics for all conditional structure types, which is that they conform to a parallel, XOR-logic (i.e. single path) concurrency model, as indicated by the class invariants. In traditional workflow processing, any instance of a <code>CHOICE_GROUP</code> is thus an 'XOR gate'.</p>
</div>
<div class="paragraph">
<p>The specific sub-types are based on the design principles <a href="#_conditional_structures">described earlier</a>, which distinguished both different conditional structural types, and three different levels of system support, i.e. 'automated', 'decision support' and 'ad hoc'. The combination of structural types and levels of system/user interaction levels is realised in terms of variations on the <code>CHOICE_GROUP</code> and <code>CHOICE_BRANCH</code> classes shown above, which define a generic notion of a decision point from which multiple branches emanate. The variations in system support manifest as follows.</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>fully automated</em>: three kinds of fully defined decision structures, namely the <code>CONDITION_XX</code>, <code>DECISION_XX</code> and <code>EVENT_XX</code> classes shown in the UML diagram;</p>
</li>
<li>
<p><em>decision support</em>: where instances of the above structures should be considered recommendations only, the <code><em>override_type</em></code> attribute defined on <code>CHOICE_GROUP</code> may be used on any <code>XX_GROUP</code> to indicate that user override is allowed;</p>
</li>
<li>
<p><em>ad hoc</em>: a dedicated variation <code>ADHOC_GROUP</code> and <code>ADHOC_BRANCH</code> are used to represent multiple branches where no criteria are defined in the Plan definition, but instead provided by an execution-time user.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>In the override and adhoc cases, a justification may be provided at execution-time for having overridden or made a particular adhoc choice. This is represented in the materialised model, and therefore does not appear in the definition model.</p>
</div>
<div class="paragraph">
<p>The three fully defined decision patterns are described below.</p>
</div>
</div>
<div class="sect3">
<h4 id="_condition_group_ifelseifelse"><a class="anchor" href="#_condition_group_ifelseifelse"></a>6.7.2. Condition Group (if/elseif/else)</h4>
<div class="paragraph">
<p>The first is a structure in which a set of Task Groups are treated as separate branches from a common point in the Plan. Each branch is entered conditionally according to the Boolean expression included on the branch. The classes <code>CONDITION_GROUP</code> and <code>CONDITION_BRANCH</code> provide this structure, which is  equivalent to an if/then/else structure in a programming language. Semantically, the branches are evaluated in order, in the matter of an if/then/else structure, and the final member may be a catch-all branch that matches if nothing else does. Accordingly, the <code><em>execution_type</em></code> is constrained to <code>sequential</code>.</p>
</div>
<div class="paragraph">
<p>The following diagram shows a typical condition structure.</p>
</div>
<div id="condition_structure" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/condition_structure.svg" alt="condition structure">
</div>
<div class="title">Figure 28. Condition structure</div>
</div>
</div>
<div class="sect3">
<h4 id="_decision_group_switch"><a class="anchor" href="#_decision_group_switch"></a>6.7.3. Decision Group (switch)</h4>
<div class="paragraph">
<p>The second pattern corresponds to a decision point in a workflow at which some expression is evaluated, and each outgoing branch corresponds to a sub-set of the expression&#8217;s value range (<code><em>value_constraint</em></code> attribute). The classes <code>DECISION_GROUP</code> and <code>DECISION_BRANCH</code> provide this structure, which is  equivalent to a switch statement in a programming language. The branch sub-ranges should ideally be individually mutually exclusive, and collectively they should cover the entire value range of the expression. However, as with the Condition Group, the branches are processed in order stated in the definition (<code><em>execution_type</em></code> is constrained to <code>sequential</code>), which enables overlapping value constraints on the branches, and also a final catch-all 'else' branch, if needed. The latter would have an open value constraint of the correct type.</p>
</div>
<div class="paragraph">
<p>The following diagram shows a typical decision structure.</p>
</div>
<div id="decision_structure" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/decision_structure.svg" alt="decision structure">
</div>
<div class="title">Figure 29. Decision structure</div>
</div>
</div>
<div class="sect3">
<h4 id="_event_group"><a class="anchor" href="#_event_group"></a>6.7.4. Event Group</h4>
<div class="paragraph">
<p>The final structure is a wait state at which multiple branches correspond to the receipt of different events. Taken together, the events constitute a set of logical alternatives at the relevant point in the Plan. This structure is modelled using the classes <code>EVENT_GROUP</code> and <code>EVENT_BRANCH</code>, and is equivalent to a when / then / else  rules structure in a rule-based programming environment.</p>
</div>
<div id="event_structure" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/event_structure.svg" alt="event structure">
</div>
<div class="title">Figure 30. Event structure</div>
</div>
</div>
<div class="sect3">
<h4 id="_class_definitions_6"><a class="anchor" href="#_class_definitions_6"></a>6.7.5. Class Definitions</h4>
<div class="sect4">
<h5 id="_choice_group_class"><a class="anchor" href="#_choice_group_class"></a>6.7.5.1. CHOICE_GROUP Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong><em>CHOICE_GROUP (abstract)</em></strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Abstract precursor of root node of any decision structure. All such structures are instances of a Task Group in parallel mode, with XOR (single path) concurrency logic.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>TASK_GROUP</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>override_type</strong>: <code>OVERRIDE_TYPE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Indicates kind of user override that would be accepted at runtime. If set to a value other than <code>prohibited</code>, user interaction is assumed, and runtime processing must enter a</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>timeout</strong>: <code>TIMER_WAIT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Timeout handler to use if <code>CHOICE_GROUP</code> blocks unexpectedly, e.g. due to absent user, unavailable external data item.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1<br>
(redefined)</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>members</strong>: <code>List&lt;CHOICE_BRANCH&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Set of Tasks to perform. Execution order is defined by the <code><em>execution_type</em></code> setting, either sequential or parallel (no order).</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Invariants</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p><em>Inv_parallel</em>: <code>execution_type = EXECUTION_TYPE.parallel</code></p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p><em>Inv_xor_concurrency</em>: <code>concurrency_mode = CONCURRENCY_MODE.xor_one_path</code></p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_override_type_enumeration"><a class="anchor" href="#_override_type_enumeration"></a>6.7.5.2. OVERRIDE_TYPE Enumeration</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Enumeration</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>OVERRIDE_TYPE</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Enumeration expressing kinds of override that can be stated for a Plan definition decision structure.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">allowed</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Override by user is allowed.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">allowed_with_reason</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>User override allowed with provided reason.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock">prohibited</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Override by user is prohibited.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_choice_branch_class"><a class="anchor" href="#_choice_branch_class"></a>6.7.5.3. CHOICE_BRANCH Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong><em>CHOICE_BRANCH (abstract)</em></strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Abstract precursor of any subordinate branch in a decision structure.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>TASK_GROUP</code></p></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_condition_group_class"><a class="anchor" href="#_condition_group_class"></a>6.7.5.4. CONDITION_GROUP Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>CONDITION_GROUP</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Special kind of Task Group whose members are all <code>CONDITION_BRANCH</code> instances, each of which represents a conditional expression based on context variables. Member branches are evaluated in order, which enables overlapping conditions as well as a final 'match-any' branch with a test expression of <code>True</code> to be used if needed.</p>
</div>
<div class="paragraph">
<p>This structure is the equivalent of a programming if/then/else statement.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>CHOICE_GROUP</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1<br>
(redefined)</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>members</strong>: <code>List&lt;CONDITION_BRANCH&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Set of branches in this condition group.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_condition_branch_class"><a class="anchor" href="#_condition_branch_class"></a>6.7.5.5. CONDITION_BRANCH Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>CONDITION_BRANCH</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>A specialised kind of <code>TASK_GROUP</code> representing a branch in a Condition Group.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>CHOICE_BRANCH</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>test</strong>: <code>BOOLEAN_CONTEXT_EXPRESSION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Boolean-valued test expression which if True indicates that this Branch is to be followed during execution.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Invariants</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p><em>Inv_no_wait_condition</em>: <code>wait_spec = Void</code></p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_decision_group_class"><a class="anchor" href="#_decision_group_class"></a>6.7.5.6. DECISION_GROUP Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>DECISION_GROUP</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Special kind of Task Group whose members are all <code>DECISION_BRANCH</code> instances, each of which represents a distinct value sub-range, and which represent together the total possible range of values of the test expression.</p>
</div>
<div class="paragraph">
<p>This structure is the equivalent of a programming switch statement. It is processed in order, and for situations that need it, the last branch may represent an 'any value', corresponding to a final 'else' at the end of the switch.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>CHOICE_GROUP</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>test</strong>: <code>CONTEXT_EXPRESSION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Test expression that generates a value of any type whose sub-ranges may be assigned to the various output branches, in the manner of a switch statement.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1<br>
(redefined)</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>members</strong>: <code>List&lt;DECISION_BRANCH&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Set of branches in this Decision Group.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_decision_branch_class"><a class="anchor" href="#_decision_branch_class"></a>6.7.5.7. DECISION_BRANCH Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>DECISION_BRANCH</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>A specialised kind of <code>TASK_GROUP</code> representing a branch in a Decision Group.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>CHOICE_BRANCH</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>value_constraint</strong>: <code>BOOLEAN_CONTEXT_EXPRESSION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Constraint on result value of the owning Decision Group <code><em>test</em></code> expression, for this branch.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Invariants</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p><em>Inv_no_wait_condition</em>: <code>wait_spec = Void</code></p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_adhoc_group_class"><a class="anchor" href="#_adhoc_group_class"></a>6.7.5.8. ADHOC_GROUP Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>ADHOC_GROUP</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Special kind of Task Group whose members are all <code>ADHOC_BRANCH</code> instances, each of which represents an outgoing branch. No conditions or rules are supplied in the model, and it is assumed that the user has a way of choosing based on the branches, and the decision context.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>CHOICE_GROUP</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1<br>
(redefined)</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>members</strong>: <code>List&lt;ADHOC_BRANCH&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Branches of this choice group.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_adhoc_branch_class"><a class="anchor" href="#_adhoc_branch_class"></a>6.7.5.9. ADHOC_BRANCH Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>ADHOC_BRANCH</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>A specialised kind of <code>TASK_GROUP</code> representing a branch in an Ad Hoc Group.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>CHOICE_BRANCH</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Invariants</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p><em>Inv_no_wait_condition</em>: <code>wait_spec = Void</code></p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_event_group_class"><a class="anchor" href="#_event_group_class"></a>6.7.5.10. EVENT_GROUP Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>EVENT_GROUP</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Special kind of Task Group whose members are <code>EVENT_BRANCH</code> instances each representing a mutually exclusive Event Wait, the first of which occurs determines the execution path.</p>
</div>
<div class="admonitionblock note">
<table>
<tr>
<td class="icon">
<div class="title">Note</div>
</td>
<td class="content">
at least one of the branches should have a timeout set, i.e. <code><em>wait_spec.timeout</em> /= Void</code> to ensure the Event group does not block indefinitely. If no such timeout is set, the Plan global timeout will eventually fire.
</td>
</tr>
</table>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>CHOICE_GROUP</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1<br>
(redefined)</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>members</strong>: <code>List&lt;EVENT_BRANCH&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Set of branches in this Event Group.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_event_branch_class"><a class="anchor" href="#_event_branch_class"></a>6.7.5.11. EVENT_BRANCH Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>EVENT_BRANCH</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>A specialised kind of <code>TASK_GROUP</code> representing a branch in an Event Group.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>CHOICE_BRANCH</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Invariants</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p><em>Wait_spec_not_void</em>: <code>wait_spec /= Void</code></p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_order_tracking"><a class="anchor" href="#_order_tracking"></a>6.8. Order Tracking</h3>
<div class="paragraph">
<p>A small number of features in the model are designed to support the tracking of orders from a Work Plan. The following UML view shows the relevant classes and properties.</p>
</div>
<div id="proc_definition_order_tracking" class="imageblock text-center text-center">
<div class="content">
<img src="UML/diagrams/PROC-task_planning.definition-order_tracking.svg" alt="PROC task planning.definition order tracking">
</div>
<div class="title">Figure 31. Order tracking</div>
</div>
<div class="paragraph">
<p>The facilities consist of the following:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>the <code>ORDER_REF</code> class, representing an 'order reference';</p>
</li>
<li>
<p><code>WORK_PLAN.<em>order_list</em></code> is a table of Order Refs being tracked by the current Plan;</p>
</li>
<li>
<p><code>TASK.<em>order_tags</em></code> allows any Task to reference one or more <code>ORDER_REF</code> instances in the Work Plan <code><em>order_list</em></code>.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>These features enable the creation and/or tracking of orders in an EHR system, according to various scenarios described below. Orders as described here are usually represented as openEHR Instructions and Actions committed to an openEHR EHR (within Compositions), but may in fact be any object(s) that can be referred to by a <code>LOCATABLE_REF</code>(which contains a URI). The following sub-sections assume openEHR Instructions and Actions for simplicity of explanation.</p>
</div>
<div class="paragraph">
<p>Two key attributes are used to connect Tasks in a Work Plan to Instructions in the EHR. The first is the <code>ORDER_REF.<em>order_ref</em></code> attribute, which represents a reference to the Instruction in the EHR. Subsequent Actions that are committed for a given Instruction contain references to the Instruction, which can be matched to the <code><em>order_ref</em></code> value.</p>
</div>
<div class="paragraph">
<p>The second attribute is <code>ORDER_REF.<em>order_tag</em></code>, used to logically identify an order tracking reference (i.e. an <code>ORDER_REF</code>) within a Work Plan. Any <code>TASK</code> that wants to refer to one or more orders records these same references in its <code>TASK.<em>order_tags</em></code> attribute. An order tag may take any String value not containing white space characters. The recommended approach is to use strings meaningful and unique within the Plan context, such that every order is distinguished, including distinct instances. For example, the value <code>"hypertension_medication"</code> may be sufficient within one Plan to identify and track an order for such medication, but if the Plan potentially may track two or more such medications, more unique values will be required, e.g. <code>"beta_blocker_medication"</code>, <code>"ACE_inhibitor_medication"</code> etc. Similarly, orders for different types of insulin (typical for diabetics) would need to be distinguished.</p>
</div>
<div class="paragraph">
<p>Multiple order tags may be used in a <code>TASK</code> for the case where a single Task causes creation of multiple orders, or a single Task waits on events (Action commits) from multiple orders.</p>
</div>
<div class="paragraph">
<p>For Plans in which repetition occurs (<code>PLAN_ITEM.<em>repeat_spec</em></code>), order tags may be constructed using the format <code>"xxxx@n"</code>, e.g. <code>"doxorubicin@1"</code>, <code>"doxorubicin_admin@2"</code> to refer to the orders for Doxorubicin in two distinct cycles of chemtherapy mentioned in the same Work Plan.</p>
</div>
<div class="sect3">
<h4 id="_tracking_an_existing_order"><a class="anchor" href="#_tracking_an_existing_order"></a>6.8.1. Tracking an Existing Order</h4>
<div class="paragraph">
<p>In this scenario, at Work Plan design time, an order <em>already exists</em> in the form of an Instruction committed to a patient EHR. This might be a standing order, e.g. for insulin. The Plan might be used to track patient or healthcare professional administrations of such a medication.</p>
</div>
<div class="paragraph">
<p>Since it is possible to construct a <code>LOCATABLE_REF</code> to the <code>INSTRUCTION</code> (and indeed, to a contained <code>ACTIVITY</code>), it may be referenced from a Work Plan using an <code>ORDER_REF</code> instance, via the <code><em>order_ref</em></code> property. The corresponding Instruction archetype identifier may also be recorded, enabling direct lookup by the TP engine, for use within the Plan modelling environment. The <code><em>order_tag</em></code> field will be set to a value that refers to the order in a sufficiently precise way as to be unique within the Work Plan.</p>
</div>
<div class="paragraph">
<p>This scheme allows Tasks to be defined within the Plan that have a Task Wait (<code>PLAN_ITEM.<em>wait_spec</em></code>) that wait on an event (e.g. <code>SYSTEM_NOTIFICATION</code> or <code>MANUAL_NOTIFICATION</code>) that is generated due to a subsequent commit to the EHR of <code>ACTIONs</code> for the original order (e.g. drug administration events, cancellation or suspension of medication by the doctor etc).</p>
</div>
<div class="paragraph tbd">
<p>TBD: could also use Dispatchable Task approach as per below, to wait on an existing order.</p>
</div>
</div>
<div class="sect3">
<h4 id="_creating_and_tracking_an_order"><a class="anchor" href="#_creating_and_tracking_an_order"></a>6.8.2. Creating and Tracking an Order</h4>
<div class="paragraph">
<p>In this scenario, the Work Plan is the creator of the order(s) of interest. At Work Plan <em>design time</em>, there is no order (i.e. <code>INSTRUCTION</code>) in the EHR (this will only occur at Plan execution time), so  <code>ORDER_REF.<em>order_ref</em></code> cannot initially be populated. An <code>ORDER_REF</code> can nevertheless be created for the order at Plan design time, with the <code><em>order_tag</em></code> being used to refer to the order from within the Work Plan. A typical Plan structure in this case might contain the following, for each order:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>a <code>PERFORMABLE_TASK&lt;DEFINED_ACTION&gt;</code> with associated <code><em>capture_dataset</em></code>, representing the entry of routine data and creation of the order, resulting in a commit to the EHR system of a Composition containing an Instruction for the order;</p>
</li>
<li>
<p>a subsequent <code>DISPATCHABLE_TASK&lt;SYSTEM_REQUEST&gt;</code> (or <code>DISPATCHABLE_TASK&lt;EXTERNAL_REQUEST&gt;</code>) that causes the appropriate API call or message to be generated and sent to the filler of the order (e.g. pharmacy, laboratory etc); this Task may include a callback wait state (<code>DISPATCHABLE_TASK.<em>callback</em></code>) so that it blocks and waits for a result within a certain time-frame.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Both the Performable and Dispatchable Tasks use <code>TASK.<em>order_tags</em></code> to logically refer to the same order. Any number of pairs of Performable and Dispatchable Tasks may be defined to create and react to different orders being processed within the same Work Plan.</p>
</div>
<div class="paragraph">
<p>A concrete callback event can be arranged to occur when an <code>ACTION</code> for the order of interest is committed to the EHR. This relies on the population of the relevant Work Plan <code>CONTEXT_REF.<em>order_ref</em></code> attribute within the TP engine execution environment, at the moment the order is created in the EHR system. This then allows commits of <code>ACTIONs</code> for that order (among others, generally) to be matched with the Dispatchable Task(s) waiting on them. The callback processing for the Dispatchable Task follows the <code>order tracking</code> callback model described in <a href="#_callback_processing_for_blocking_tasks">Section 6.9.5.1</a> below.</p>
</div>
<div class="paragraph">
<p>The Dispatchable Task might be located in a repeating section of the Plan, if the intention is to await multiple Actions for the same Instruction.</p>
</div>
<div class="paragraph">
<p>An example of a Work Plan representing this scenario is available in the <a href="https://specifications.openehr.org/releases/PROC/Release-1.5.0/tp_examples.html#_order_coordination" target="_blank" rel="noopener">Task Planning Examples</a> document.</p>
</div>
</div>
<div class="sect3">
<h4 id="_class_definitions_7"><a class="anchor" href="#_class_definitions_7"></a>6.8.3. Class Definitions</h4>
<div class="sect4">
<h5 id="_order_ref_class"><a class="anchor" href="#_order_ref_class"></a>6.8.3.1. ORDER_REF Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>ORDER_REF</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>An instance of this class represents a logical tracking reference to one 'order' in the real world. In an openEHR system, this will be represented by an <code>INSTRUCTION</code> committed to the EHR, normally followed by <code>ACTIONs</code> each representing the execution of an Activity or change of state of the order.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>LOCATABLE</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>order_tag</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Tag that refers to this order within a Work Plan. May include an instance-level modifier such as '@1', '@2' etc, to distinguish repeats within a Plan.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>instruction_archetype_id</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identifier of openEHR Instruction archetype that contains the order.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>action_archetype_id</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identifier of openEHR Action archetype that defines the actions that may occur with respect to the Instruction activities used in this order.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>order_ref</strong>: <code>LOCATABLE_REF</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>EHR system order reference. When referencing an openEHR order, this will be a reference to the initial Instruction defining the order.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_events"><a class="anchor" href="#_events"></a>6.9. Events</h3>
<div class="sect3">
<h4 id="_overview_3"><a class="anchor" href="#_overview_3"></a>6.9.1. Overview</h4>
<div class="paragraph">
<p>Work plans interact with events in the external world, as well being driven by time. In this model, moments in time are modelled in terms of Events that represent the <em>reaching</em> of certain points in time or an entry in a calendar, as time passes. Consequently, specifying a time for a Task to be performed and waiting for certain Events before it can be performed are both specified in terms of 'events'. The relevant part of the model, shown below, consists of various types of Events, and additionally, various types of <em>wait states</em> that may be used to intercept them.</p>
</div>
<div id="proc_task_planning_definition_event" class="imageblock text-center text-center">
<div class="content">
<img src="UML/diagrams/PROC-task_planning.definition-event.svg" alt="PROC task planning.definition event">
</div>
<div class="title">Figure 32. proc.task_planning model - Events</div>
</div>
<div class="paragraph">
<p>Two general classes of Events are distinguished:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>deterministic</em>: Events guaranteed to occur at a knowable point in time (shown on the lower left in light pink);</p>
</li>
<li>
<p><em>non-deterministic</em>: Events that might never occur (shown on the lower right in magenta).</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>For non-deterministic events, a timeout handler is generally needed.</p>
</div>
</div>
<div class="sect3">
<h4 id="_event_types"><a class="anchor" href="#_event_types"></a>6.9.2. Event Types</h4>
<div class="paragraph">
<p>The various Event types are shown below, with their TP-VML representations.</p>
</div>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 14.2857%;">
<col style="width: 28.5714%;">
<col style="width: 57.1429%;">
</colgroup>
<thead>
<tr>
<th class="tableblock halign-left valign-top">Type</th>
<th class="tableblock halign-left valign-top">TP-VML</th>
<th class="tableblock halign-left valign-top">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top" colspan="3"><p class="tableblock"><strong>Deterministic Events</strong></p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>TIMER_EVENT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="event_timer" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/event_timer.svg" alt="event timer">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Event generated by the expiry of a Timer that was launched at some earlier time; if attached to a Task wait state, the timer is launched at the moment execution reaches the Task.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>TIMELINE_MOMENT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="event_timeline_moment" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/event_timeline_moment.svg" alt="event timeline moment">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Event generated by system clock reaching a fixed time-point on the Work Plan timeline, specified by an offset from the Work Plan origin (overridable) plus an optional fixed time in the day. The latter enables fixed points in time such as a particular hour of day or customary time such as 'afternoon' to be specified. A combination of the two such as <code>P2D</code>, <code>13:30:00</code> can thus be used to state a time like '13:30 on day 2 of the plan'.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>CALENDAR_EVENT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="event_calendar_event" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/event_calendar_event.svg" alt="event calendar event">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Event generated by system clock reaching an event in the global Plan calendar, which is specified in absolute time, independent of the Work Plan timeline. The value of the <code><em>time</em></code> attribute is obtained from the calendar.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top" colspan="3"><p class="tableblock"><strong>Non-deterministic Events</strong></p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>TASK_TRANSITION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="event_task_transition" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/event_task_transition.svg" alt="event task transition">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Event generated by the lifecycle transition of another Task, such as transition to <code>cancelled</code> or <code>done</code>.<br>
 NOTE: not needed for transition of the preceding Task to a terminal state, since in this case, execution automatically proceeds to the current Task.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>STATE_TRIGGER</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="event_state_trigger" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/event_state_trigger.svg" alt="event state trigger">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">An event generated by a change in a tracked variable, or a Boolean expression based on tracked variables, e.g. a value reaching a threshold.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>MANUAL_NOTIFICATION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="event_manual_notification" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/event_manual_notification.svg" alt="event manual notification">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">An event that is manually notified to the Plan execution engine by a user.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>SYSTEM_NOTIFICATION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="event_system_notification" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/event_system_notification.svg" alt="event system notification">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">An event that is notified to the Plan execution engine by a system.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>CALLBACK_NOTIFICATION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="event_callback" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/event_callback.svg" alt="event callback">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">A callback notification connected to a dispatch for a Dispatchable Task (Hand-off, External Request, System Request).</p></td>
</tr>
</tbody>
</table>
<div class="paragraph">
<p>Instances of all of these types on their own only identify the type and source of an event - a wait state is required to catch an event. There are three types of wait state used in a TP definition: Task Wait, Timer Wait and Callback Wait. These are described below.</p>
</div>
<div class="paragraph">
<p>The following Event types require further explanation.</p>
</div>
<div class="sect4">
<h5 id="_timeline_moment"><a class="anchor" href="#_timeline_moment"></a>6.9.2.1. TIMELINE_MOMENT</h5>
<div class="paragraph">
<p>The <code>TIMELINE_MOMENT</code> event type represents an event generated by the system when a point in time on the execution clock is reached. The time point is specified by two attributes, <code><em>timeline_offset</em></code> and <code><em>fixed_time</em></code>, with the time origin (default: Work Plan activation) being optionally specified by <code><em>timeline_origin</em></code>. At least one of the first two attributes must be set.</p>
</div>
<div class="paragraph">
<p>If <code><em>fixed_time</em></code> is set using an instance of <code>CLOCK_TIME</code>, it refers to the first moment at which the time occurs during the day, <em>after any offset has elapsed</em>. The following diagram shows how this works for two instances of <code>TIMELINE_MOMENT</code>, both having a <code><em>fixed_time</em></code> of <code>07:30</code> and a <code><em>timeline_offset</em></code> of <code>P1d</code> (one day), when the timeline origin is different (i.e. the Work Plan was started at different times).</p>
</div>
<div id="timeline_moment_semantics" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/timeline_moment_semantics.svg" alt="timeline moment semantics">
</div>
<div class="title">Figure 33. <code>TIMELINE_MOMENT</code> semantics</div>
</div>
<div class="paragraph">
<p>The <code><em>fixed_time</em></code> attribute may also be set using an instance of <code>CUSTOMARY_TIME</code>, to allow the time to be specified using coded terms like <code>morning</code>, <code>afternoon</code>, <code>evening</code> and so on. Such terms are assumed to define time ranges such as <code>07:00:00 - 11:30:00</code> etc, which are typically culturally specific, and/or specific to hospital or other institutional norms. Consequently, such terms have to be resolved to computable intervals by some means (e.g. a locale service API call), left up to the TP execution system. Where such an interval is used to define a time, the event is generated at the earliest time of the interval (e.g. <code>07:00:00</code> for 'morning')</p>
</div>
<div class="paragraph">
<p>If <code><em>fixed_time</em></code> is not set, it refers to the first moment in time directly after the offset, if any, has elapsed (i.e. a Void <code><em>fixed_time</em></code> is intepreted as "don&#8217;t care"). If <code><em>timeline_offset</em></code> is not set, <code><em>fixed_time</em></code> is resolved to the first occurrence of the specified time directly from the time origin.</p>
</div>
<div class="paragraph">
<p>A <code>TIMELINE_MOMENT</code> with neithre of <code><em>timeline_offset</em></code> or <code><em>fixed_time</em></code> set is not considered meaningful, since it is equivalent to no <code>TIMELINE_MOMENT</code> event at all.</p>
</div>
<div class="paragraph">
<p>The timeline origin defaults to the moment of Work Plan activiation, but may be overridden via the <code><em>timeline_origin</em></code> attribute to be the moment of activation of the current Task Plan, or the entry into a repeating section (a Task Group or Task with <code><em>repeat_spec</em></code> set).</p>
</div>
</div>
</div>
<div class="sect3">
<h4 id="_general_facilities"><a class="anchor" href="#_general_facilities"></a>6.9.3. General Facilities</h4>
<div class="sect4">
<h5 id="_event_wait_state"><a class="anchor" href="#_event_wait_state"></a>6.9.3.1. Event Wait State</h5>
<div class="paragraph">
<p>The class <code>EVENT_WAIT&lt;T&gt;</code> defines a generic model of a general-purpose event wait state that may be specialised for particular purposes. Its attributes are as follows:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code><em>success_action</em></code> of type <code>EVENT_ACTION</code>, which defines possible actions to occur on receipt of an event;</p>
</li>
<li>
<p><code><em>timeout</em></code> of type <code>TIMER_WAIT</code>, whose <code><em>success_action</em></code> defines possible actions when no event is received.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The <code>EVENT_ACTION</code> type defines a number of things the system can do on a triggering event:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>make a system call, if the <code><em>system_call</em></code> attribute is set, e.g. to cause a notification to be sent or write to a system logger;</p>
</li>
<li>
<p>displaying a message to the user, specified in the <code><em>message</em></code> attribute;</p>
</li>
<li>
<p>optionally indicate a specific lifecycle state for the Plan Item (a Task or Task Group) receiving the event, specified by <code><em>receiver_thread_next_state</em></code>;</p>
</li>
<li>
<p>optionally indicate where execution should resume in the plan, for example at an earlier Task, via the <code><em>resume_action</em></code> attribute, whose value is an instance of <code>RESUME_ACTION</code>, defining the <code><em>resume_type</em></code> and <code><em>resume_location</em></code> attributes.</p>
</li>
</ul>
</div>
</div>
<div class="sect4">
<h5 id="_timers"><a class="anchor" href="#_timers"></a>6.9.3.2. Timers</h5>
<div class="paragraph">
<p>A generic timer can be specified using <code>TIMER_WAIT</code>, a specialisation of <code>EVENT_WAIT&lt;TIMER_EVENT&gt;</code> based on the Event type <code>TIMER_EVENT</code>. This provides a way to specify a Timer (the <code>TIMER_EVENT</code>) and listen for it (the <code>TIMER_WAIT</code>).  A <code>TIMER_WAIT</code> creates a separate Event wait state that listens for a Timer event launched some duration after Task activation, and may result in specific actions, specified via the inherited <code>EVENT_WAIT.<em>success_action</em></code> attribute.</p>
</div>
<div class="paragraph">
<p>The timer represented by a <code>TIMER_EVENT</code> is started when the wait state to which it is attached is reached in the execution.</p>
</div>
</div>
<div class="sect4">
<h5 id="_reminder"><a class="anchor" href="#_reminder"></a>6.9.3.3. Reminder</h5>
<div class="paragraph">
<p>A reminder can be specified using <code>REMINDER</code>, a specialisation of <code>EVENT_WAIT&lt;PLAN_EVENT&gt;</code>. Conceptually, a reminder is a wait state that is activated if a secondary event (represented by the <code><em>event</em></code> attribute inherited from <code>EVENT_WAIT&lt;T&gt;</code>) occurs in the absence of waited-on primary event(s), i.e. expected lifecycle transitions of the owning Task. Usually the secondary event is a <code>TIMER_EVENT</code>, but it could be anything else. If any of the primary events occurs, the reminder is cancelled.</p>
</div>
</div>
</div>
<div class="sect3">
<h4 id="_task_wait_state"><a class="anchor" href="#_task_wait_state"></a>6.9.4. Task Wait State</h4>
<div class="paragraph">
<p>The principal way to wait for events is via the <code>TASK_WAIT</code> attachable to any <code>PLAN_ITEM</code> via the <code><em>wait_spec</em></code> attribute. The <code>TASK_WAIT</code> class represents a wait state that defines when a Task should enter the <code>available</code> state from the <code>planned</code> state in terms of Events of the types described above. Its <code><em>events</em></code> attribute enables multiple Events to be used as triggers, with an assumed logical OR relation among them. This enables the specification of triggers such as 'at 8pm on day 1, OR when oxygen saturation drops below 90% (whichever comes first)'. The optional <code><em>event_relation</em></code> attribute allows the Task to be specified as commencing <code>before</code>, <code>with</code> or <code>after</code> the trigger event (such as a meal).</p>
</div>
<div class="paragraph">
<p>The following figure illustrates typical uses of <code>TASK_WAIT</code>.</p>
</div>
<div id="task_wait_state" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/task_wait_state.svg" alt="task wait state">
</div>
<div class="title">Figure 34. Task wait state</div>
</div>
<div class="sect4">
<h5 id="_time_outs"><a class="anchor" href="#_time_outs"></a>6.9.4.1. Time-outs</h5>
<div class="paragraph">
<p>A timeout can be set on a Task Wait state by setting <code>TASK_WAIT.<em>timeout</em></code> with a <code>TIMER_WAIT</code> instance, which is activated when the Task Wait state is reached in the execution. This is useful in cases where Event receipt is not certain. The <code>TIMER_WAIT</code> generates a timer event if no other event is received; conversely, receipt of any other event cancels the timeout timer. The <code>TIMER_EVENT</code> attached to <code>TIMER_WAIT.<em>event</em></code> indicates the duration of the timer. The <code><em>success_action</em></code> of the <code>TIMER_WAIT</code> indicates actions to execute if the timer fires. The following Plan fragment illustrates.</p>
</div>
<div id="timing_patterns_1" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/uc_task_timing_1.svg" alt="uc task timing 1">
</div>
<div class="title">Figure 35. Timing patterns</div>
</div>
</div>
<div class="sect4">
<h5 id="_reminder_2"><a class="anchor" href="#_reminder_2"></a>6.9.4.2. Reminder</h5>
<div class="paragraph">
<p>When an event specified in <code>TASK_WAIT.<em>events</em></code> fires, it puts the Task into the <code>available</code> lifecycle state. In typical real world situations, the performer may not realise, or may be busy on something else. To enable the performer to be reminded, the <code>PLAN_ITEM.<em>reminders</em></code> attribute may be used to specify one or more <code>REMINDER</code> wait states. Each of these will have a <code>TIMER_EVENT</code> (or other event) as its firing <code><em>event</em></code>.</p>
</div>
<div class="paragraph tbd">
<p>TBD: what about transition to <code>underway</code>?</p>
</div>
<div class="paragraph">
<p>If a Reminder is activated, it will generate a notification, specified via the inherited <code><em>success_action</em></code> attribute. If still no activity occurs for some time, additional reminders may fire (due to Timer events with longer times), and generate new notifications. As soon as the performer progresses the Task to a new state, any reminder for which such a transition is cancelling, will be cancelled. An example is illustrated below.</p>
</div>
<div id="task_wait_state_reminder" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/task_wait_state_reminder.svg" alt="task wait state reminder">
</div>
<div class="title">Figure 36. Task wait state with reminder</div>
</div>
</div>
<div class="sect4">
<h5 id="_lifecycle_transition_override"><a class="anchor" href="#_lifecycle_transition_override"></a>6.9.4.3. Lifecycle Transition Override</h5>
<div class="paragraph">
<p>In some cases, it may be necessary to progress a Task to a state other than <code>available</code>. This may be achieved by specifying <code>TASK_WAIT.<em>next_state</em></code>.</p>
</div>
</div>
</div>
<div class="sect3">
<h4 id="_callbacks"><a class="anchor" href="#_callbacks"></a>6.9.5. Callbacks</h4>
<div class="paragraph">
<p>A callback is the mechanism to state what happens when control returns to a Dispatchable Task (such as a Hand-off or External Request) from its target. It is defined in the model by <code>CALLBACK_WAIT</code>, a specialisation of <code>EVENT_WAIT&lt;CALLBACK_NOTIFICATION&gt;</code>, which represents a wait state to receive notifications of Dispatch completion, as well as timeout if no response is received. The callback event is formally represented by the <code>CALLBACK_NOTIFICATION</code> class. These classes are shown in the following view of the UML model.</p>
</div>
<div id="proc_definition_callback_wait" class="imageblock text-center text-center">
<div class="content">
<img src="UML/diagrams/PROC-task_planning.definition-callback_wait.svg" alt="PROC task planning.definition callback wait">
</div>
<div class="title">Figure 37. Callback Wait</div>
</div>
<div class="paragraph">
<p>In order to define the processing on receipt of a callback event, <code>CALLBACK_WAIT</code> adds two attributes to <code>EVENT_WAIT&lt;T&gt;</code>:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code><em>fail_action</em></code>: enables a different <code>EVENT_ACTION</code> to be specified on receipt of a callback with a 'fail' status;</p>
</li>
<li>
<p><code><em>custom_actions</em></code>: enables a custom set of <code>EVENT_ACTIONs</code> to be specified, in the form of a Hash table, with a specific Event Action for each key; the keys are assumed to represent specific return statuses of the remote Task.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>A Callback Wait thus has three standard Event responders: <code><em>success_action</em></code>, <code><em>fail_action</em></code> and <code><em>timeout</em></code>, and additionally any number of custom responders definable via <code><em>custom_actions</em></code>, described below.</p>
</div>
<div class="paragraph">
<p>Task lifecycle state processing for a Dispatchable Task occurs both at the point of dispatch and return and/or timeout. The general model is as follows:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>the Task starts in the <code>planned</code> state, as for any Task in a Plan;</p>
</li>
<li>
<p>when the execution point reaches the Task, and any Task Wait state has been exited, the Task becomes <code>available</code> (refer above to <a href="#_task_availability">Section 6.2.3.1</a>);</p>
</li>
<li>
<p>the Task dispatch operation is performed either automatically, or in the case of an External Request, manually;</p>
</li>
<li>
<p>if <code>DISPATCHABLE_TASK.<em>wait</em></code> is <code>False</code>:</p>
<div class="ulist">
<ul>
<li>
<p>the Task transitions to the <code>completed</code> state.</p>
</li>
</ul>
</div>
</li>
<li>
<p>if <code>DISPATCHABLE_TASK.<em>wait</em></code> is <code>True</code>:</p>
<div class="ulist">
<ul>
<li>
<p>the Task enters the <code>underway</code> state until a callback (or timeout) occurs, at which point the next state will depend on the details of the callback (see below);</p>
</li>
</ul>
</div>
</li>
</ul>
</div>
<div class="sect4">
<h5 id="_callback_processing_for_blocking_tasks"><a class="anchor" href="#_callback_processing_for_blocking_tasks"></a>6.9.5.1. Callback Processing for Blocking Tasks</h5>
<div class="paragraph">
<p>For a <code>DISPATCHABLE_TASK</code> that blocks and waits in the <code>underway</code> state, there are three callback processing models:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code>standard</code>: generic <code>success | fail | timeout</code> model;</p>
</li>
<li>
<p><code>order tracking</code>: used if <code>DISPATCHABLE_TASK.<em>order_tags</em></code> is set;</p>
</li>
<li>
<p><code>custom</code>: used if <code>DISPATCHABLE_TASK.<em>callback.custom_actions</em></code> is set.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Each model corresponds to a different set of possible callback statuses returned by the TP engine with the callback notification to represent the state of the remote Task execution. In the <code>standard</code> model it is a generic <code>success | fail | timeout</code> approach. Under the <code>order tracking</code> model (<a href="#_order_tracking">Section 6.8</a>, above), the return statuses are states from the <a href="https://specifications.openehr.org/releases/RM/latest/ehr.html#_the_standard_instruction_state_machine_ism">openEHR Instruction State Machine</a>. Under the <code>custom</code> model, they are specific to the context.</p>
</div>
<div class="paragraph">
<p>Under each model, the next lifecycle state of the Dispatchable Task is determined by the callback status in a specific way. For each possible status under each model, a specific callback handler may be set, defined in terms of the <code>CALLBACK</code> properties <code><em>success_action</em></code>, <code><em>fail_action</em></code>, <code><em>timeout.success_action</em></code>. Any of these (see class <code>EVENT_ACTION</code>) if set may override the default next state, and also may generate a system call and/or a message for the performer.</p>
</div>
<div class="paragraph tbd">
<p>TBD: It would be reasonable to design an implementation with a default message of the form <code>"Task $task_name[id=$task_id] completed with $state"</code>, and a global flag <code><em>default_messages_on</em></code> to obviate the need to always set basic messages in <code>EVENT_ACTION</code>.</p>
</div>
<div class="paragraph">
<p>In special cases, it may also cause execution to resume in another place (see <a href="#_resume_semantics">Section 7.2.4</a>).</p>
</div>
<div class="paragraph">
<p>A common approach to timeout processing applies to all models. If no callback occurs, and <code>CALLBACK.<em>timeout.success_action</em></code> is set, its timer will be used to generate the timeout, and also to determine the next state, message etc. If it is not set, the Work Plan global timeout will be triggered to unblock the Task and transition it to the <code>abandoned</code> state.</p>
</div>
<div class="paragraph tbd">
<p>TBD: need to define Plan level timeout.</p>
</div>
<div class="paragraph">
<p>The following table describes the details of callback processing under the various models.</p>
</div>
<table class="tableblock frame-all grid-all stripes-none stretch">
<colgroup>
<col style="width: 15.3846%;">
<col style="width: 15.3846%;">
<col style="width: 23.0769%;">
<col style="width: 23.0769%;">
<col style="width: 23.077%;">
</colgroup>
<thead>
<tr>
<th class="tableblock halign-left valign-top">Callback<br>
 model</th>
<th class="tableblock halign-left valign-top">Callback<br>
              statuses</th>
<th class="tableblock halign-left valign-top">Dispatchable Task<br>
                        settings</th>
<th class="tableblock halign-left valign-top">Response processing</th>
<th class="tableblock halign-left valign-top">Notes</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top" rowspan="2"><div class="content"><div class="paragraph">
<p><strong>Standard</strong></p>
</div></div></td>
<td class="tableblock halign-left valign-top" rowspan="2"><p class="tableblock"><em>success</em><br>
 | <em>fail</em><br>
 | <em>timeout</em></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">no callback handlers</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="ulist">
<ul>
<li>
<p><em>success</em> &#8594; <code>completed</code><br></p>
</li>
<li>
<p><em>fail</em> &#8594; <code>abandoned</code><br></p>
</li>
<li>
<p><em>timeout</em> &#8594; <code>abandoned</code></p>
</li>
</ul>
</div></div></td>
<td class="tableblock halign-left valign-top"></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">callback handlers (<code><em>success_action</em></code>, <code><em>fail_action</em></code>, <code><em>timeout.success_action</em></code>)</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>As specified in <code>EVENT_ACTION.</code><br>
 <code><em>receiver_thread_next_state</em></code>,<br>
 or else as above.</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Use to e.g. convert <em>fail</em> to <code>cancelled</code>.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top" rowspan="2"><div class="content"><div class="paragraph">
<p><strong>Order<br>
 tracking</strong></p>
</div></div></td>
<td class="tableblock halign-left valign-top" rowspan="2"><p class="tableblock">Action ISM state<br>
 | <em>timeout</em></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">no callback handlers<br>
 (except optionally <code><em>timeout.success_action</em></code>)</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="ulist">
<ul>
<li>
<p><code>planned</code> &#8594; <code>underway</code><br></p>
</li>
<li>
<p><code>cancelled</code> &#8594; <code>cancelled</code><br></p>
</li>
<li>
<p><code>postponed</code> &#8594; <code>suspended</code><br></p>
</li>
<li>
<p><code>scheduled</code> &#8594; <code>underway</code><br></p>
</li>
<li>
<p><code>active</code> &#8594; <code>underway</code><br></p>
</li>
<li>
<p><code>suspended</code> &#8594; <code>suspended</code><br></p>
</li>
<li>
<p><code>aborted</code> &#8594; <code>cancelled</code><br></p>
</li>
<li>
<p><code>completed</code> &#8594; <code>completed</code><br></p>
</li>
<li>
<p><em>timeout</em> &#8594; <code>abandoned</code></p>
</li>
</ul>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">May catch multiple callbacks via use of <code>underway</code> target state.<br>
<br>
 Only target states reachable from <code>underway</code> can be used.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock">callback handlers (<code><em>custom_actions</em></code>, <code><em>timeout.success_action</em></code>)</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>As specified in <code><em>custom_actions[n].<br>
 receiver_thread_next_state</em></code>,<br>
 or else as above</p>
</div></div></td>
<td class="tableblock halign-left valign-top"></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p><strong>Custom</strong></p>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Custom statuses<br>
 | <em>timeout</em></p></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">callback handlers (<code><em>custom_actions</em></code>, <code><em>timeout.success_action</em></code>)</p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="ulist">
<ul>
<li>
<p><code>xxx</code> &#8594; <code>underway</code><br></p>
</li>
<li>
<p><code>yyy</code> &#8594; <code>cancelled</code><br></p>
</li>
<li>
<p><code>zzz</code> &#8594; <code>suspended</code><br></p>
</li>
<li>
<p>etc</p>
</li>
<li>
<p><em>timeout</em> &#8594; <code>abandoned</code></p>
</li>
</ul>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">May catch multiple callbacks via use of <code>underway</code> target state.<br>
<br>
 Only target states reachable from <code>underway</code> can be used.</p></td>
</tr>
</tbody>
</table>
<div class="paragraph">
<p>The following diagram shows the TP-VML definition for a dispatchable Task with a standard callback.</p>
</div>
<div id="timing_callback_pattern_1" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/uc_task_callback_1.svg" alt="uc task callback 1">
</div>
<div class="title">Figure 38. Standard callback example</div>
</div>
<div class="paragraph">
<p>The following TP-VML definition illustrates a custom callback.</p>
</div>
<div id="timing_callback_pattern_2" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/uc_task_callback_2.svg" alt="uc task callback 2">
</div>
<div class="title">Figure 39. Custom callback example</div>
</div>
</div>
<div class="sect4">
<h5 id="_callback_processing_for_non_blocking_tasks"><a class="anchor" href="#_callback_processing_for_non_blocking_tasks"></a>6.9.5.2. Callback Processing for Non-blocking Tasks</h5>
<div class="paragraph">
<p>In the case of a context fork, the source Task has performed its work as soon as the dispatch has occurred, and its state is set to <code>completed</code>. The next Task(s) become <code>available</code> in the normal way, and processing continues. At some later point in time, a status notification of timeout may be received from the remote Task. This will be processed similarly to the above, with the exception that the next state processing, <em>if explicit next states are set</em>, is  <em>with respect to the enclosing Task Group</em>, which may be the top-level Group of the Task Plan. This allows the possibility of the callback processing to cause the local execution pathway to stop with abandonment, or cancellation. The default next-state processing is 'no change', i.e. the current execution path doesn&#8217;t care what happens to the remote thread. However, if <code>EVENT_ACTION.<em>receiver_thread_next_state</em></code> is set for an execution status of the remote Task, the execution of the Task Group containing the source Task may be ended (<code>cancel</code>) or the whole Plan abandoned (<code>abandon</code>). Such a transition might even be set on <code>success</code>, which provides a way to model 'first one wins' logic.</p>
</div>
<div class="paragraph">
<p>The following illustrates a non-blocking callback in TP-VML.</p>
</div>
<div id="dispatchable_no_wait_callback" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/dispatchable_no_wait_callback.svg" alt="dispatchable no wait callback">
</div>
<div class="title">Figure 40. Non-blocking callback example</div>
</div>
</div>
<div class="sect4">
<h5 id="_callback_with_custom_resume_behaviour"><a class="anchor" href="#_callback_with_custom_resume_behaviour"></a>6.9.5.3. Callback with Custom Resume Behaviour</h5>
<div class="paragraph">
<p>The attribute <code>EVENT_ACTION.<em>resume_action</em></code> of type <code>RESUME_ACTION</code>, and its attribute <code><em>resume_location</em></code> enable custom post-callback behaviour to be stated. The default is to process the <code>EVENT_ACTION</code> (e.g. post a message, make a system call etc), and then to complete the current Task and progress to the next in the normal way. A custom resume action alows a different resumption location to be specified, as defined by the enumeration <code>RESUME_TYPE</code>. This kind of resumption is described below in the section on <a href="#_resume_semantics">Section 7.2.4</a>.</p>
</div>
</div>
<div class="sect4">
<h5 id="_manually_notified_pseudo_callback"><a class="anchor" href="#_manually_notified_pseudo_callback"></a>6.9.5.4. Manually-notified Pseudo-callback</h5>
<div class="paragraph">
<p>A callback at execution time is achieved via notification within the TP system. However, in some cases, the effect of a callback is required where the means of notification is the subject (i.e. the patient, in a clinical system) being sent to another department or room, and the current performer&#8217;s execution blocking for that subject until he/she returns. This effect can be achieved by the task pattern shown below, consisting of a Hand-off followed by a normal Task that waits on a Manual notification event. This pattern is not a true callback.</p>
</div>
<div id="manual_callback" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/manual_callback.svg" alt="manual callback">
</div>
<div class="title">Figure 41. Pattern to achieve effect of 'manual callback'</div>
</div>
</div>
</div>
<div class="sect3">
<h4 id="_class_definitions_8"><a class="anchor" href="#_class_definitions_8"></a>6.9.6. Class Definitions</h4>
<div class="sect4">
<h5 id="_task_wait_class"><a class="anchor" href="#_task_wait_class"></a>6.9.6.1. TASK_WAIT Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>TASK_WAIT</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Object representing time of a Task to be performed in terms of a related event. The <code><em>start_window</em></code> is used to add an 'acceptable delay' time within which the Task should be started with respect to the intended start time. The <code><em>timeout</em></code> attribute can be used for non-deterministic Events.</p>
</div>
<div class="ulist">
<ul>
<li>
<p>clock time: event = <code>TIMELINE_MOMENT</code>, <code>CALENDAR_EVENT</code>;</p>
</li>
<li>
<p>notification-based: event = <code>MANUAL_NOTIFICATION</code>, <code>CALLBACK_NOTIFICATION</code> or <code>SYSTEM_NOTIFICATION</code>;</p>
</li>
<li>
<p>task-linked: event = <code>TASK_TRANSITION</code>, e.g. 1hr after previous Task done;</p>
</li>
<li>
<p>state-linked: event = <code>STATE_TRIGGER</code>, e.g. 'when systolic BP &gt; 165'.</p>
</li>
</ul>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>events</strong>: <code>List&lt;PLAN_EVENT&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>One or more events that define the intended point in time. If there are more than one, the implied logical relation is OR, i.e. any event occurring causes the wait state to complete.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>event_relation</strong>: <code>TEMPORAL_RELATION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Temporal relation to the event of the point or period in time being defined by this Timing Spec.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>timeout</strong>: <code>TIMER_WAIT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Timeout handler to use if no other Event is received within a certain time.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>next_state</strong>: <code>TASK_LIFECYCLE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Override for next state to enter on receipt of any Event in <code><em>events</em></code>. Default processing is to enter the <code>available</code> state.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_event_waitp_class"><a class="anchor" href="#_event_waitp_class"></a>6.9.6.2. EVENT_WAIT&lt;P&gt; Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>EVENT_WAIT&lt;P&gt;</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Wait state for any kind of Event, with a success Action and an optional separate timeout Event Wait state.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>event</strong>: <code>P</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Descriptor for event on which this wait state is based.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>success_action</strong>: <code>EVENT_ACTION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Action to perform if any listened-for event returns a success result.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>timeout</strong>: <code>TIMER_WAIT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Timeout handler to use if no other Event is received within a certain time.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_timer_wait_class"><a class="anchor" href="#_timer_wait_class"></a>6.9.6.3. TIMER_WAIT Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>TIMER_WAIT</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Event listener for a Timer event.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>EVENT_WAIT</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1<br>
(redefined)</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>event</strong>: <code>TIMER_EVENT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Redefined from <code>EVENT_WAIT</code>.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Invariants</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p><em>Inv_no_timeout</em>: <code>timeout = Void</code></p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p><em>Inv_has_action</em>: <code>success_action /= Void</code></p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_reminder_class"><a class="anchor" href="#_reminder_class"></a>6.9.6.4. REMINDER Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>REMINDER</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Specialised Event wait state activated when its <code><em>event</em></code> fires. This is often a <code>TIMER_EVENT</code>, but may be any other kind of event. Will be cancelled when/if its owning Task enters a terminal state (i.e. completes or is cancelled or the Plan abandoned).</p>
</div>
<div class="paragraph">
<p>If the reminder is activated, its <code><em>success_action</em></code> should be configured to generate a reminder or alert to performer or other user.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>EVENT_WAIT</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1<br>
(redefined)</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>event</strong>: <code>PLAN_EVENT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>The event that will generate the reminder. This could be a timer, or it may be a timeline moment, calendar time, or a non-deterministic event, e.g. state trigger.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Invariants</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p><em>Inv_no_timeout</em>: <code>timeout = Void</code></p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p><em>Inv_has_action</em>: <code>success_action /= Void</code></p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_callback_wait_class"><a class="anchor" href="#_callback_wait_class"></a>6.9.6.5. CALLBACK_WAIT Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>CALLBACK_WAIT</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Specialised descendant of <code>EVENT_WAIT &lt;CALL_BACK_NOTIFICATION&gt;</code> that adds a fail action. Used for representing post-callback actions.</p>
</div>
<div class="paragraph">
<p>Default processing if <code>EVENT_ACTION.<em>receiver_thread_next_state</em></code> is not set:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>on <code><em>success_action</em></code>: the owning Task <code><em>lifecycle_state</em></code> is progressed to the <code>completed</code> state.</p>
</li>
<li>
<p>on <code><em>fail_action</em></code>: the owning Task <code><em>lifecycle_state</em></code> is progressed to the <code>abandoned</code> state.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p><code>EVENT_ACTION.<em>receiver_thread_next_state</em></code> must be set on all</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>EVENT_WAIT</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>fail_action</strong>: <code>EVENT_ACTION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Action to perform if any listened-for event returns a fail result.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>custom_actions</strong>: <code>Hash&lt;String,EVENT_ACTION&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>A keyed list of specific actions to perform based on custom key values, which are understood as types of remote event more specific than just 'success' or 'fail'.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1<br>
(redefined)</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>event</strong>: <code>CALLBACK_NOTIFICATION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Callback notification on which this Callback wait state is based.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_event_action_class"><a class="anchor" href="#_event_action_class"></a>6.9.6.6. EVENT_ACTION Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>EVENT_ACTION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Action(s) to perform on receipt of an event with a particular status. Four possible things can be specified:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>a message;</p>
</li>
<li>
<p>a system call;</p>
</li>
<li>
<p>the next state of the Task or other resume location (<code><em>receiver_thread_next_state</em></code>);</p>
</li>
<li>
<p>a specific resume action indicating to resume in a specific location in the Plan.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>If <code><em>resume_action</em></code> is set, it dictates where execution resumes; if not, the default is to resume at the next Task in normal execution flow.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>system_call</strong>: <code>List&lt;SYSTEM_CALL&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>System call to perform on receipt of event</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>message</strong>: <code>DV_TEXT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional message to display to original Task context (i.e. application, form etc) if timer expires.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>resume_action</strong>: <code>RESUME_ACTION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional resume action, used when the intention is to resume in a different location than the default (i.e. next available Task).</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>receiver_thread_next_state</strong>: <code>TASK_LIFECYCLE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Next state of the receiver thread of control. In the blocking case, this is the original Task of this callback notification; in the non-blocking (context fork) case, it will be the <em>enclosing  Task Group</em> of the original dispatching Task.</p>
</div>
<div class="paragraph">
<p>If not set, default processing will be performed, which for a Task is to enter the <code>available</code> state.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Invariants</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p><em>Inv_custom_actions_next_state</em>: <code>custom_actions.for_all ((ev:EVENT_ACTION) {ev.receiver_thread_next_state /= Void})</code></p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_resume_action_class"><a class="anchor" href="#_resume_action_class"></a>6.9.6.7. RESUME_ACTION Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>RESUME_ACTION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Type representing an execution jump to a new location in the current Plan.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>resume_type</strong>: <code>RESUME_TYPE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Procedure to execute when completion notification received, for example, to display a form, notify performer etc.</p>
</div>
<div class="paragraph">
<p>TODO: determine details.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>resume_location</strong>: <code>UID_BASED_ID</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Reference to a resume Task in the current Plan, at which to restart when the request / handoff has completed.</p>
</div>
<div class="paragraph">
<p>If not set, the following Task is assumed. It set, is typically an earlier Task, in situations where the current Task(s) are no longer needed once the external action has been completed.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_plan_event_class"><a class="anchor" href="#_plan_event_class"></a>6.9.6.8. PLAN_EVENT&lt;&gt; Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong><em>PLAN_EVENT&lt;&gt; (abstract)</em></strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Entity representing an Event generated during system execution. Descendants define details of each kind of Event known in the system.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>LOCATABLE</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>other_details</strong>: <code>ITEM_STRUCTURE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>delay</strong>: <code>Iso8601_duration</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional delay to event generation.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_timer_event_class"><a class="anchor" href="#_timer_event_class"></a>6.9.6.9. TIMER_EVENT Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>TIMER_EVENT</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Timer expiry event generated by Task Plan engine, after the <code><em>duration</em></code> period has elapsed from the moment of execution reaching the Task to which this Event is attached.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>PLAN_EVENT</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>duration</strong>: <code>Iso8601_duration</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Delay from activation time to receive the event notification.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>purpose</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional explanatory purpose of Timer.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_calendar_event_class"><a class="anchor" href="#_calendar_event_class"></a>6.9.6.10. CALENDAR_EVENT Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>CALENDAR_EVENT</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Specifies an event generated during execution when the Plan clock reaches a corresponding entry in the global calendar.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>PLAN_EVENT</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>entry_id</strong>: <code>UID_BASED_ID</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identifier of entry within global Plan calendar.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>time</strong>: <code>Iso8601_date_time</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Time of entry in calendar.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_timeline_moment_class"><a class="anchor" href="#_timeline_moment_class"></a>6.9.6.11. TIMELINE_MOMENT Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>TIMELINE_MOMENT</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Specifies a time event generated during execution when the Plan clock reaches a specific point defined in the global Plan Timeline. The time of this timeline moment is calculated as the <code><em>fixed_time</em></code> in the day, e.g. <code>14:30:00</code>, no matter when the Plan is activated.</p>
</div>
<div class="paragraph">
<p>The <code><em>timeline_offset</em></code> attribute can be used to specify a particular offset with respect to a time origin, by default, the origin of the Work Plan. The <code><em>fixed_time</em></code> then corresponds to the first occurrence of that time on the clock <em>after</em> the <code><em>timeline_offset</em></code> is passed.</p>
</div>
<div class="paragraph">
<p>This can be used to specify particular times on particular days, e.g.: <code>07:30:00 on day 3</code>, <code>14:00:00 on day 5</code> and so on by setting <code><em>timeline_offset</em></code> to numbers of days, e.g. <code>P3D</code>, <code>P5D</code> etc. Note that a value of <code>P1D</code> means the first 24h period after Plan activation, whereas if <code><em>timeline_offset</em></code> is not set, the <code><em>fixed_time</em></code> is understood to specify the first moment after Plan activation that this time is reached on the Plan clock.</p>
</div>
<div class="paragraph">
<p>The <code><em>timeline_origin</em></code> can be set to specify another time origin, such as the start of execution of the Task Plan, or of a repeat section.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>PLAN_EVENT</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>timeline_offset</strong>: <code>Iso8601_duration</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Variable part of time specification, expressed as an offset from the zero time point of the Task Plan. Converted to absolute time at activation.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>fixed_time</strong>: <code>TIME_SPECIFIER</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Fixed time specifier, used to expressed a fixed moment in the day.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>timeline_origin</strong>: <code>PLAN_TIME_ORIGIN</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Relative origin for <code><em>timeline_offset</em></code>. If not set, Work Plan activation is assumed as the time origin.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Invariants</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p><em>Inv_validity</em>: <code>timeline_offset /= Void or fixed_time /= Void</code></p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_task_transition_class"><a class="anchor" href="#_task_transition_class"></a>6.9.6.12. TASK_TRANSITION Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>TASK_TRANSITION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Event type for Task transitions, specified in terms of target state reached by the associated Task.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>PLAN_EVENT</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>task_id</strong>: <code>UID_BASED_ID</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identifier of Task with which this event is associated.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>transitions</strong>: <code>List&lt;TASK_LIFECYCLE&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>One or more Task lifecycle transition(s) that defines this event; if more than one, the logical relation is 'OR'.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_manual_notification_class"><a class="anchor" href="#_manual_notification_class"></a>6.9.6.13. MANUAL_NOTIFICATION Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>MANUAL_NOTIFICATION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Event type representing the manual notification of a real-world event to the system, such as arrival of a test result, manually taken vital sign value over a threshold.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>PLAN_EVENT</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>description</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Natural language or processable description of the event. Needs to be sufficiently detailed to distinguish it from other similar events.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_system_notification_class"><a class="anchor" href="#_system_notification_class"></a>6.9.6.14. SYSTEM_NOTIFICATION Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>SYSTEM_NOTIFICATION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Event type representing a notification from a system of some event, represented by notification type and reference identifier.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>PLAN_EVENT</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>system_id</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identifier of system that will generate notification.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>notification_type</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Type of notification, i.e. among types generated by the source system.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>reference_id</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Reference identifier, typically a request identifier from a previous request.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_callback_notification_class"><a class="anchor" href="#_callback_notification_class"></a>6.9.6.15. CALLBACK_NOTIFICATION Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>CALLBACK_NOTIFICATION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Event generated on receipt of notification of completion of the work of the target of a Dispatchable Task.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>PLAN_EVENT</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>task_id</strong>: <code>UID_BASED_ID</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identifier of originating Task.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>request_id</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identifier of original request, may be matchable with <code>EXTERNAL_REQUEST.<em>request_id</em></code>.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>subject_id</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identifier of subject to which callback relates.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect4">
<h5 id="_state_trigger_class"><a class="anchor" href="#_state_trigger_class"></a>6.9.6.16. STATE_TRIGGER Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>STATE_TRIGGER</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Type of event representing an expression referring to one or more tracked variables, reaching a value or passing a threshold value.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>PLAN_EVENT</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>expression</strong>: <code>BOOLEAN_CONTEXT_EXPRESSION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Boolean-returning expression that mentions one or more tracked variables, e.g. <code>heart_rate &gt; 120 bpm</code>. Evaluation controlled by Plan variable context.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_cost_tracking"><a class="anchor" href="#_cost_tracking"></a>6.10. Cost Tracking</h3>
<div class="paragraph tbd">
<p>TBD: describe cost tracking.</p>
</div>
<div class="sect3">
<h4 id="_class_definitions_9"><a class="anchor" href="#_class_definitions_9"></a>6.10.1. Class Definitions</h4>
<div class="sect4">
<h5 id="_task_costing_class"><a class="anchor" href="#_task_costing_class"></a>6.10.1.1. TASK_COSTING Class</h5>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>TASK_COSTING</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Costing information for a Task.</p>
</div>
<div class="paragraph tbd">
<p>TODO: to be developed.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_global_semantics"><a class="anchor" href="#_global_semantics"></a>7. Global Semantics</h2>
<div class="sectionbody">
<div class="paragraph">
<p>This section describes the global semantics of the model in execution, taking into account all elements described above.</p>
</div>
<div class="sect2">
<h3 id="_control_flow"><a class="anchor" href="#_control_flow"></a>7.1. Control Flow</h3>
<div class="sect3">
<h4 id="_graph_structure_2"><a class="anchor" href="#_graph_structure_2"></a>7.1.1. Graph Structure</h4>
<div class="paragraph">
<p>The execution graph structure of a Work Plan consists of its top-level Task Plan(s) (<code>WORK_PLAN.<em>top_level_plans</em></code>) and subordinate Task Plans linked from Hand-offs and sub-plans (i.e. <code>DISPATCHABLE_TASK&lt;HAND_OFF&gt;</code> and <code>DISPATCHABLE_TASK&lt;SUB_PLAN&gt;</code>) Task types. Top-level Task Plans are those that do not have prior executable Tasks, and are thus active at activation time. The following illustrates a typical structure.</p>
</div>
<div id="wp_tp_hierarchy" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/wp_tp_hierarchy.svg" alt="wp tp hierarchy" width="55%">
</div>
<div class="title">Figure 42. Work Plan control path graph structure</div>
</div>
</div>
<div class="sect3">
<h4 id="_general_scheme"><a class="anchor" href="#_general_scheme"></a>7.1.2. General Scheme</h4>
<div class="paragraph">
<p>When a materialised Work Plan is activated (<a href="#_activation">see below</a>), its top-level Task Plans are active, meaning that their initial Task(s) are in the <code>available</code> lifecycle state, as <a href="#_task_lifecycle">described above</a>.</p>
</div>
<div class="paragraph">
<p>In a Task Plan, the <em>execution path</em> follows the chain of Tasks defined in the <code><em>definition</em></code> of the Plan, which is a <code>TASK_GROUP</code>. It descends into and exits any other <code>TASK_GROUPs</code> encountered within the Plan as Tasks are executed and completed or cancelled by their workers. A Task becomes <code>available</code> based on a combination of completion (or skipping) of previous Tasks and other conditions, according to the Task lifecycle logic <a href="#_task_lifecycle_2">described above</a>.</p>
</div>
<div class="paragraph">
<p>The currently <code>available</code> Task in a Task Plan corresponds to the <em>current execution point</em> of the Plan. For parallel execution Task Groups, more than one Task can be available simultaneously, meaning there is more than one thread of execution. As Tasks complete, and timing and other events occur, making new Tasks available, each thread of execution advances through the Task Plan graph.</p>
</div>
<div class="paragraph">
<p>On the way, the execution path is modified by conditional nodes and also by Dispatchable Tasks, as follows.</p>
</div>
</div>
<div class="sect3">
<h4 id="_conditional_nodes"><a class="anchor" href="#_conditional_nodes"></a>7.1.3. Conditional Nodes</h4>
<div class="paragraph">
<p>The various kinds of conditional nodes represent different ways of controlling execution of a Task Plan.</p>
</div>
<div class="paragraph">
<p>A <code>CONDITION_GROUP / CONDITION_BRANCH</code> structure is processed in the same way as an if-then/elseif-then/else statement in a programming language, i.e. in-order processing, with the first matching path followed. In the temporal Plan execution environment, the processing proceeds instantaneously, i.e. there is no wait state involved.</p>
</div>
<div class="paragraph">
<p>A <code>DECISION_GROUP / DECISION_BRANCH</code> structure is processed like a case (aka switch) statement in a programming language, i.e. evaluate the <code>DECISION_GROUP.<em>test</em></code>, find the first branch whose <code><em>value_constraint</em></code> (a value range) contains the value, and follow it. This is also instantaneously processed.</p>
</div>
<div class="paragraph">
<p>The other two types of Choice Group are blocking.</p>
</div>
<div class="paragraph">
<p>An <code>ADHOC_GROUP / ADHOC_BRANCH</code> structure is processed using an implicit wait state, since it requires user input. It will thus block until input is supplied. The inherited <code>CHOICE_GROUP.<em>timeout</em></code> attribute can be used to defined actions if no user input supplied. When this is not defined, a global timeout is triggered, breaking the wait state.</p>
</div>
<div class="paragraph">
<p>Finally the <code>EVENT_GROUP / EVENT_BRANCH</code> structure is blocking due to <code>TASK_WAIT</code> states set on each branch. It is processed by waiting for one of the events on the branches to occur, or else for the <code><em>timeout</em></code> on the group to fire. As for the Ad hoc case, a timeout may be set in order to force processing if none of the specified events occurs, and if not set, a global timeout will break the wait state if nothing else happens.</p>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_task_dispatching"><a class="anchor" href="#_task_dispatching"></a>7.2. Task Dispatching</h3>
<div class="sect3">
<h4 id="_hand_offs"><a class="anchor" href="#_hand_offs"></a>7.2.1. Hand-offs</h4>
<div class="paragraph tbd">
<p>TBD:</p>
</div>
</div>
<div class="sect3">
<h4 id="_external_requests"><a class="anchor" href="#_external_requests"></a>7.2.2. External Requests</h4>
<div class="paragraph tbd">
<p>TBD:</p>
</div>
</div>
<div class="sect3">
<h4 id="_system_requests"><a class="anchor" href="#_system_requests"></a>7.2.3. System Requests</h4>
<div class="paragraph tbd">
<p>TBD:</p>
</div>
</div>
<div class="sect3">
<h4 id="_resume_semantics"><a class="anchor" href="#_resume_semantics"></a>7.2.4. Resume Semantics</h4>
<div class="paragraph">
<p>The <code><em>resume_type</em></code> and <code><em>resume_location</em></code> attributes of the <code>RESUME_ACTION</code> class constitute the possibility of an uncontrolled jump or 'goto' within the Task execution structure. If allowed without limitation, it is likely to lead to undecidable situations in Plan execution, and unreliable execution histories. For example, if the execution history shows that some Task Y was performed, then it would normally be assumed that the preceding Task X had also been performed (even if cancelled), and by extension that any wait state such as an Event Branch had been satisifed by the relevant event being received. If however, a jump to Task Y from some Task A on a completely separate path were allowed, no such inference can be made, without appropriate processing rules regarding such jumps.</p>
</div>
<div class="paragraph">
<p>To create workable rules, the notion of the <em>execution path</em> described above has to be used, i.e. the path traversed so far throught the Group / Task graph to the current point. Because the graph has no cycles, a <em>most recent common location</em> for the execution path actually taken and the designated resume location can always be found. This location may be somewhere back in the current path, including at the start (no real common point), or the current Task (resume location is ahead, not behind).</p>
</div>
<div class="paragraph">
<p>Making the execution valid according to the Plan while allowing an arbitrary resumption point requires finding a <em>valid path</em> from the most recent common location to the resume location. This can be done if the intermediate steps from the most recent common point and the resume point can be shown to be traversable. There are three situations that can occur at each node along this path:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>normal Tasks with no <code><em>wait_spec</em></code> (i.e. planned or event-based timing): these may be automatically cancelled, meaning 'not done, not needed';</p>
</li>
<li>
<p>normal Tasks with a <code><em>wait_spec</em></code>: these can be traversed if the relevant time-related or other events are known to have already been received;</p>
</li>
<li>
<p>conditional Group structures: these can be traversed if the relevant conditions and/or events are known to be true, or to have already been received, respectively.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Whether the intermediate logical conditions or event wait states (including timeline events) up to the resume location are satisfiable can in general only be known at execution time. This means that at design time, no general rule can be used to limit the choice of a resume location. However, the intermediate wait states and conditions can be determined easily enough and shown in a tool to the designer, enabling at least a guess as to viability.</p>
</div>
<div class="paragraph">
<p>What actually happens at execution time depends on where the resume location is, as follows:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><strong>forward resume</strong>: the resume location is ahead of the current point on the execution path; getting there just requires the above algorithm of cancellation with condition and event checks;</p>
</li>
<li>
<p><strong>alternate path</strong>: the resume location is on an alternate branch with respect to the current execution path; this may be treated as for the forward resume case;</p>
</li>
<li>
<p><strong>current path</strong>: the resume location is earlier on the current path.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The last possibility implies the need to <em>retry</em> Tasks already performed, which must be in either the <code>cancelled</code> or <code>completed</code> state. Assuming that the intention of the resume location is to perform (again) the Task or Group at that location, the latter must be put back into the <code>available</code> state. This is enabled by the special transitions <code><em>retry</em></code> from <code>cancelled</code> to <code>available</code> and <code><em>redo</em></code> from or <code>completed</code> to <code>available</code>.</p>
</div>
<div class="paragraph">
<p>This doesn&#8217;t address what should happen at execution time when conditions or wait states at intermediate nodes from the most recent common point to the resume point cannot be met. The simplest approach is that they are manually overridden, as may already be done in normal path processing. This has the effect that such overrides are  at least recorded in the execution history.</p>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_aggregate_lifecycle_state"><a class="anchor" href="#_aggregate_lifecycle_state"></a>7.3. Aggregate Lifecycle State</h3>
<div class="paragraph">
<p>During a Work Plan execution, the lifecycle state described above on each Task is recursively aggregated up to owning Task Groups (including Choice Groups, described below in <a href="#_decision_structures">Section 6.7</a>), to the top Task Group (i.e. <code>TASK_PLAN.<em>definition</em></code>). Consequently, the aggregate lifecycle state of a Task Plan as a whole is just the lifecycle state of its <code><em>definition</em></code>.</p>
</div>
<div class="sect3">
<h4 id="_sequential_groups"><a class="anchor" href="#_sequential_groups"></a>7.3.1. Sequential Groups</h4>
<div class="paragraph">
<p>The following algorithm is used to compute the runtime lifecycle state of a Task Group for which <code><em>execution_type</em></code> is <code>sequential</code> from the set of states of its members.</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="java"><span></span><span class="tok-c1">//</span>
<span class="tok-c1">// Aggregate lifecycle state algorithm.</span>
<span class="tok-c1">// Infer the state of a collection whose members&#39; states are in source_states.</span>
<span class="tok-c1">// The order of if/else evaluation determines the correct result.</span>
<span class="tok-c1">//</span>
<span class="tok-n">Task_lifecycle</span> <span class="tok-nf">aggregate_state</span> <span class="tok-o">(</span><span class="tok-n">Set</span><span class="tok-o">&lt;</span><span class="tok-n">Task_lifecycle</span><span class="tok-o">&gt;</span> <span class="tok-n">source_states</span><span class="tok-o">)</span> <span class="tok-o">{</span>

    <span class="tok-k">if</span> <span class="tok-o">(</span><span class="tok-n">source_states</span><span class="tok-o">.</span><span class="tok-na">contains</span><span class="tok-o">(</span><span class="tok-n">Abandoned</span><span class="tok-o">))</span>
        <span class="tok-k">return</span> <span class="tok-n">Abandoned</span><span class="tok-o">;</span>
    <span class="tok-k">else</span> <span class="tok-k">if</span> <span class="tok-o">(</span><span class="tok-n">source_states</span><span class="tok-o">.</span><span class="tok-na">contains</span><span class="tok-o">(</span><span class="tok-n">Available</span><span class="tok-o">))</span>
        <span class="tok-k">return</span> <span class="tok-n">Available</span><span class="tok-o">;</span>
    <span class="tok-k">else</span> <span class="tok-k">if</span> <span class="tok-o">(</span><span class="tok-n">source_states</span><span class="tok-o">.</span><span class="tok-na">contains</span><span class="tok-o">(</span><span class="tok-n">Planned</span><span class="tok-o">))</span>
        <span class="tok-k">return</span> <span class="tok-n">Planned</span><span class="tok-o">;</span>
    <span class="tok-k">else</span> <span class="tok-k">if</span> <span class="tok-o">(</span><span class="tok-n">source_states</span><span class="tok-o">.</span><span class="tok-na">contains</span><span class="tok-o">(</span><span class="tok-n">Suspended</span><span class="tok-o">))</span>
        <span class="tok-k">return</span> <span class="tok-n">Suspended</span><span class="tok-o">;</span>
    <span class="tok-k">else</span> <span class="tok-k">if</span> <span class="tok-o">(</span><span class="tok-n">source_states</span><span class="tok-o">.</span><span class="tok-na">contains</span><span class="tok-o">(</span><span class="tok-n">Underway</span><span class="tok-o">))</span>
        <span class="tok-k">return</span> <span class="tok-n">Underway</span><span class="tok-o">;</span>
    <span class="tok-k">else</span> <span class="tok-k">if</span> <span class="tok-o">(</span><span class="tok-n">source_states</span><span class="tok-o">.</span><span class="tok-na">contains</span><span class="tok-o">(</span><span class="tok-n">Completed</span><span class="tok-o">))</span>
        <span class="tok-k">return</span> <span class="tok-n">Completed</span><span class="tok-o">;</span>
    <span class="tok-k">else</span> <span class="tok-k">if</span> <span class="tok-o">(</span><span class="tok-n">source_states</span><span class="tok-o">.</span><span class="tok-na">contains</span><span class="tok-o">(</span><span class="tok-n">Cancelled</span><span class="tok-o">))</span>
        <span class="tok-k">return</span> <span class="tok-n">Cancelled</span><span class="tok-o">;</span>
    <span class="tok-k">else</span>
        <span class="tok-k">return</span> <span class="tok-n">Initial</span><span class="tok-o">;</span>
<span class="tok-o">}</span></code></pre>
</div>
</div>
<div class="paragraph">
<p>Consequences of the above algorithm include:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>a Task Group at runtime is in a terminal state only if all recursively contained Tasks and/or other Task Groups are in terminal states;</p>
</li>
<li>
<p>completing a Task Group will ripple back up the Task Group hierarchy to a point where the completing Group is not the last remaining uncompleted Task or Group in the parent;</p>
</li>
<li>
<p>if the <code>abandoned</code> state is entered for a Task, the effect is to cause the current run of the enclosing Task Plan to be <code>abandoned</code>.</p>
</li>
</ul>
</div>
</div>
<div class="sect3">
<h4 id="_parallel_groups"><a class="anchor" href="#_parallel_groups"></a>7.3.2. Parallel Groups</h4>
<div class="paragraph">
<p>If <code>TASK_GROUP.<em>execution_type</em></code> is <code>parallel</code>, then the value of <code><em>concurrency_mode</em></code> will also affect computation of Task Group lifecycle state, since in some modes, some Tasks will be ignored. The following table indicates the computation for Task Group state at any time during and after execution of its branches. Note that all decision structures, i.e. <code>CHOICE_GROUPs</code>, are equivalent to <code>xor_one_path</code> Task Groups, and are thus solved by the second entry in the table below.</p>
</div>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 23.0769%;">
<col style="width: 15.3846%;">
<col style="width: 61.5385%;">
</colgroup>
<thead>
<tr>
<th class="tableblock halign-left valign-top">Concurrency mode</th>
<th class="tableblock halign-left valign-top">TP-VML</th>
<th class="tableblock halign-left valign-top">Lifecycle state rule</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>and_all_paths</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="lifecycle_and" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/task_group_parallel_and.svg" alt="task group parallel and">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Apply the algorithm to each branch; re-apply the algorithm using all branch results as the input set.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>xor_one_path</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="lifecycle_xor" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/task_group_parallel_xor.svg" alt="task group parallel xor">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Apply the algorithm to the chosen branch.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>or_all_started</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="lifecycle_or_all" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/task_group_parallel_or_all.svg" alt="task group parallel or all">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Apply the algorithm to each commenced branch; re-apply the algorithm using these branch results as the input set.</p></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><p class="tableblock"><code>or_first_completed</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div id="lifecycle_or_first" class="imageblock">
<div class="content">
<img src="task_planning/diagrams/task_group_parallel_or_first.svg" alt="task group parallel or first">
</div>
</div></div></td>
<td class="tableblock halign-left valign-top"><p class="tableblock">Apply the algorithm to each commenced branch; apply the OR-join algorithm below to this set.</p></td>
</tr>
</tbody>
</table>
<div class="listingblock">
<div class="content">
<pre class="pygments highlight"><code data-lang="java"><span></span><span class="tok-c1">//</span>
<span class="tok-c1">// OR-join algorithm: apply to Aggregate lifcycle algorithm results</span>
<span class="tok-c1">// obtained from all commenced branches.</span>
<span class="tok-c1">//</span>
<span class="tok-n">Task_lifecycle</span> <span class="tok-nf">or_join_state</span> <span class="tok-o">(</span><span class="tok-n">Set</span><span class="tok-o">&lt;</span><span class="tok-n">Task_lifecycle</span><span class="tok-o">&gt;</span> <span class="tok-n">branch_states</span><span class="tok-o">)</span> <span class="tok-o">{</span>

    <span class="tok-k">if</span> <span class="tok-o">(</span><span class="tok-n">branch_states</span><span class="tok-o">.</span><span class="tok-na">contains</span><span class="tok-o">(</span><span class="tok-n">Abandoned</span><span class="tok-o">))</span>
        <span class="tok-k">return</span> <span class="tok-n">Abandoned</span><span class="tok-o">;</span>
    <span class="tok-k">else</span> <span class="tok-k">if</span> <span class="tok-o">(</span><span class="tok-n">branch_states</span><span class="tok-o">.</span><span class="tok-na">contains</span><span class="tok-o">(</span><span class="tok-n">Completed</span><span class="tok-o">))</span>
        <span class="tok-k">return</span> <span class="tok-n">Completed</span><span class="tok-o">;</span>
    <span class="tok-k">else</span> <span class="tok-k">if</span> <span class="tok-o">(</span><span class="tok-n">branch_states</span><span class="tok-o">.</span><span class="tok-na">contains</span><span class="tok-o">(</span><span class="tok-n">Underway</span><span class="tok-o">))</span>
        <span class="tok-k">return</span> <span class="tok-n">Underway</span><span class="tok-o">;</span>
    <span class="tok-k">else</span> <span class="tok-k">if</span> <span class="tok-o">(</span><span class="tok-n">branch_states</span><span class="tok-o">.</span><span class="tok-na">contains</span><span class="tok-o">(</span><span class="tok-n">Suspended</span><span class="tok-o">))</span>
        <span class="tok-k">return</span> <span class="tok-n">Suspended</span><span class="tok-o">;</span>
    <span class="tok-k">else</span> <span class="tok-k">if</span> <span class="tok-o">(</span><span class="tok-n">branch_states</span><span class="tok-o">.</span><span class="tok-na">contains</span><span class="tok-o">(</span><span class="tok-n">Available</span><span class="tok-o">))</span>
        <span class="tok-k">return</span> <span class="tok-n">Available</span><span class="tok-o">;</span>
    <span class="tok-k">else</span> <span class="tok-k">if</span> <span class="tok-o">(</span><span class="tok-n">branch_states</span><span class="tok-o">.</span><span class="tok-na">contains</span><span class="tok-o">(</span><span class="tok-n">Planned</span><span class="tok-o">))</span>
        <span class="tok-k">return</span> <span class="tok-n">Planned</span><span class="tok-o">;</span>
    <span class="tok-k">else</span> <span class="tok-k">if</span> <span class="tok-o">(</span><span class="tok-n">branch_states</span><span class="tok-o">.</span><span class="tok-na">contains</span><span class="tok-o">(</span><span class="tok-n">Cancelled</span><span class="tok-o">))</span>
        <span class="tok-k">return</span> <span class="tok-n">Cancelled</span><span class="tok-o">;</span>
    <span class="tok-k">else</span>
        <span class="tok-k">return</span> <span class="tok-n">Initial</span><span class="tok-o">;</span>
<span class="tok-o">}</span></code></pre>
</div>
</div>
<div class="paragraph">
<p>The logic of the OR-join algorithm is to treat <em>any</em> finishing branch (<code>abandoned</code> or <code>completed</code>) as finishing the group, and otherwise to report the progress of the most advanced branch (i.e. <code>underway</code>, then <code>suspended</code> etc) as the progress of the Group.</p>
</div>
<div class="paragraph">
<p>If the Task Group has more complex execution rules (<code>TASK_GROUP.<em>execution_rules</em></code>), then its lifecycle state will also be affected according to these rules.</p>
</div>
</div>
<div class="sect3">
<h4 id="_work_plan_2"><a class="anchor" href="#_work_plan_2"></a>7.3.3. Work Plan</h4>
<div class="paragraph">
<p>The lifecycle state of a Work Plan is determined from the states of its top-level Task Plans in the same way as for a parallel AND Task Group, i.e. by re-applying the algorithm to all the Task Plans.</p>
</div>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_execution"><a class="anchor" href="#_execution"></a>8. Execution</h2>
<div class="sectionbody">
<div class="paragraph">
<p>This section describes the execution time semantics that correspond to the materialised and runtime forms of the Task Planning model.</p>
</div>
<div class="sect2">
<h3 id="_phases_of_processing"><a class="anchor" href="#_phases_of_processing"></a>8.1. Phases of Processing</h3>
<div class="paragraph">
<p>As described in the earlier section <a href="#_execution_concepts">Section 4.5</a>, Work Plan execution traverses three states: <code>materialised</code>, <code>activated</code> and <code>terminated</code>. These are described in the following sub-sections.</p>
</div>
<div class="sect3">
<h4 id="_materialisation"><a class="anchor" href="#_materialisation"></a>8.1.1. Materialisation</h4>
<div class="paragraph">
<p>When a Work Plan is to be made available for use, it will be <em>materialised</em>, which concretely means instantiating and usually persisting it (this might be avoided for very short run Plans). Some user input may be required, e.g. number of repetitions of repeatable sections. Conditional branches whose conditions or events will never be met can also be removed during materialisation.</p>
</div>
<div class="paragraph">
<p>The materialised representation consists of:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>A copy of the definition form of the Plan;</p>
</li>
<li>
<p>An instance of the Plan using Materialised model instances, i.e. the <code>M_XXX</code> classes shown below, representing the concrete executable Tasks, each with a reference back to a definition Task.</p>
</li>
<li>
<p>For Plans with repeatable sections, the Materialised model contains these sections 'unrolled' into as many instances as required by the Plan activator. In terms of the materialised model described below, some <code>M_TASK_GROUP</code> instances will have their <code><em>members</em></code> containing additional <code>M_XX</code> instances. Thus, more than one <code>M_TASK</code> may point to the same generating <code>TASK</code> from the definition.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The structure created will thus mirror the structure of the original definition, with extra copies for repeatable sections and potentially 'dead branches' removed.</p>
</div>
<div class="paragraph">
<p>At materialisation time, an instance of <code>EXECUTION_HISTORY</code> is also created, proving a root point to accumulate Plan execution event records.</p>
</div>
<div class="paragraph">
<p>Advance allocations of Tasks to concrete participants may be made in this phase.</p>
</div>
</div>
<div class="sect3">
<h4 id="_activation"><a class="anchor" href="#_activation"></a>8.1.2. Activation</h4>
<div class="paragraph">
<p>A materialised Work Plan is <em>activated</em> when it is ready to be used. Activation starts the timeline clock for the Work Plan; accordingly, execution times in the constituent Task Plans are converted to absolute clock times, or a form that can be related to clock time, e.g. via the use of the materialised Work Plan timeline and calendar.</p>
</div>
<div class="paragraph">
<p>As part of activation, the <em>runtime window</em> must be determined. This is a moving window corresponding to the section of a materialised Plan that will be actively executing at any moment. The size of the window should be at least a working shift (e.g. 8-12 hours), but might be longer, e.g. the number of days used in the organisation for lookahead planning. The parts of Task Plans within a Work Plan that are inside the runtime window are in active execution, while other parts (both prior and after the window) are not currently executing but should be available for visualisation.</p>
</div>
<div class="paragraph">
<p>When the runtime window is known, allocations for the window can be managed, as <a href="#_allocation">described below</a>. To enable allocation to take place, a communication channel must be established with each potential worker or worker pool. This may consist of any technical means, including email, instant messager, a ward screen application and so on. Allocations may be filled in a 'just in time' fashion where the technical means exists to enable it (e.g. push communications from the server).</p>
</div>
<div class="paragraph">
<p>Execution starts by putting the Work Plan&#8217;s top-level Task Plans into an initial wait state, waiting on allocation of principal performer, and availability of the Task Plan subject (patient, related person, image, tissue sample etc).</p>
</div>
<div class="paragraph">
<p>For each Task Plan, execution of the Plan section within the runtime window consists of:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Tasks within the runtime window being displayed within a separate or shared application for each performer, along with lifecycle state of each Task;</p>
</li>
<li>
<p>Tasks become <em>available</em> as earlier Tasks are completed or cancelled. When a Task is available to be done, the performer has various options, including doing the work, cancelling the Task as not needed, completing the Task, or aborting it, which abandons the entire Plan;</p>
</li>
<li>
<p>performers interact with the visual representation to transition the lifecycle state of each Task;</p>
</li>
<li>
<p>as the work proceeds, event records are generated and added to the execution history.</p>
</li>
<li>
<p>the Plan remains in the <code>active</code> state until abandoned or completed.</p>
</li>
</ul>
</div>
</div>
<div class="sect3">
<h4 id="_termination"><a class="anchor" href="#_termination"></a>8.1.3. Termination</h4>
<div class="paragraph">
<p>A Task Plan <em>terminates</em> when the execution path taken through the materialised Group/Task graph completes, either due to finishing, or due to abandonment at an intermediate Task.</p>
</div>
<div class="paragraph">
<p>The Task Plan as a whole returns a termination status of <code>success</code> or <code>fail</code>, which may be used to control behaviour if it is part of a hand-off chain in which a context switch follows termination of one Task Plan.</p>
</div>
<div class="paragraph">
<p>A Work Plan terminates when all member Task Plans have terminated in the above fashion.</p>
</div>
<div class="paragraph">
<p>An event record is added to the execution history for each Task Plan termination, and for the final Work Plan termination.</p>
</div>
</div>
<div class="sect3">
<h4 id="_allowed_plan_modifications"><a class="anchor" href="#_allowed_plan_modifications"></a>8.1.4. Allowed Plan Modifications</h4>
<div class="paragraph">
<p>After materialisation but prior to activation, changes may be made to any part of the materialised plan, corresponding to adjusting repeated sections and removing or adding back in condition branches according to relevancy with respect to newly evaluated subject variables (e.g. discovering that the patient is pregnant may require certain Decision Branches to be added back in).</p>
</div>
<div class="paragraph">
<p>Once activation has occurred, changes of the same type may still occur, but only <em>ahead of the runtime window</em>, since the parts of the Plan within the window, or already executed can&#8217;t safely or sensibly be altered.</p>
</div>
<div class="paragraph">
<p>If other kinds of changes are needed, this is generally a sign that the Plan design contains issues, and that the current version if already in use will be abandoned in favour of a newer version.</p>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_execution_processing"><a class="anchor" href="#_execution_processing"></a>8.2. Execution Processing</h3>
<div class="sect3">
<h4 id="_worker_allocation"><a class="anchor" href="#_worker_allocation"></a>8.2.1. Worker Allocation</h4>
<div class="paragraph">
<p>Before a materialised Work Plan can be executed, at least the <code><em>principal_performer</em></code> must be allocated for Task Plans containing Tasks within the current runtime window (<a href="#_activation">see above</a>). Some actors designated <code>PERFORMABLE_ACTION.<em>other_participations</em></code> of affected Tasks may need to be allocated as well. Not all performers are needed at any time, only those implicated in the part of the Plan to be executed, e.g. for the current day within a multi-day Plan.</p>
</div>
<div class="paragraph">
<p>The allocation process consists of:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>assignment</em> of a Plan or Task to a real actor or worker pool;</p>
</li>
<li>
<p>receipt by the TP engine of a <em>claim</em> by an individual to accept the request.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Assigning communicates a request to potential worker(s) (e.g. via application screens, personal messages, scheduling systems etc), one of which accepts the request and thereby becomes the allocated worker. This is done by user(s) authenticating to the Plan execution engine via an application and accepting the request. This operation is likely to be done nearly invisibly to the user, who may simply open an application window or click on a notification.</p>
</div>
<div class="paragraph">
<p>The principal performer is considered to have been allocated when the work is claimed by the worker, and a <em>live communication channel</em> has been established between the TP engine and the worker.</p>
</div>
</div>
<div class="sect3">
<h4 id="_worker_de_allocation"><a class="anchor" href="#_worker_de_allocation"></a>8.2.2. Worker De-allocation</h4>
<div class="paragraph">
<p>At various moments during the execution of a Plan, a worker may leave e.g. due to worker shift changeover, being called away, or just finishing for the day. When a worker <em>disconnects from the communication channel</em>, either actively (e.g. by closing an application) or by an inactivity time-out, the TP engine registers a de-allocation of the worker. For the remaining Task(s) in the Plan to be performed, the necessary worker allocations have to be repeated by the TP engine.</p>
</div>
</div>
<div class="sect3">
<h4 id="_resource_allocation"><a class="anchor" href="#_resource_allocation"></a>8.2.3. Resource Allocation</h4>
<div class="paragraph tbd">
<p>TBD</p>
</div>
</div>
</div>
<div class="sect2">
<h3 id="_persistence"><a class="anchor" href="#_persistence"></a>8.3. Persistence</h3>
<div class="paragraph">
<p>The run-time instance structure may need to be persisted to enable a partial execution of a long-running Task Plan to be recorded and picked up when later tasks become ready. In theory, this could be within the EHR, but it is recommended that either a specific EHR area be used for this, or that run-time state persistence be implemented outside the EHR proper.</p>
</div>
<div class="paragraph tbd">
<p>issue-runtime-persistence: if within the EHR, we could create a new 'pointer' on the EHR object that points to 'task runtime state' data or similar. Is this a useful thing to do?</p>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_materialised_model"><a class="anchor" href="#_materialised_model"></a>9. Materialised Model</h2>
<div class="sectionbody">
<div class="sect2">
<h3 id="_overview_4"><a class="anchor" href="#_overview_4"></a>9.1. Overview</h3>
<div class="paragraph">
<p>The <a href="#proc_task_planning_overview">Model overview figure</a> shows a package <code>proc.task_planning.materialised</code>. This is a partial specification of classes that could be instantiated at Task Plan execution time to track Plan execution, and is provided as a guide to implementing a materialised form for runtime use. A minimal materialised model is described here, as a means of indicating some of the general issues that will be encountered in representation of the runtime form of a Plan definition. <strong>It should not be considered either normative or complete</strong>. The model is shown below.</p>
</div>
<div id="proc_task_planning_materialised" class="imageblock text-center text-center">
<div class="content">
<img src="UML/diagrams/PROC-task_planning.materialised.svg" alt="PROC task planning.materialised">
</div>
<div class="title">Figure 43. proc.task_planning.materialised package</div>
</div>
</div>
<div class="sect2">
<h3 id="_class_descriptions_5"><a class="anchor" href="#_class_descriptions_5"></a>9.2. Class Descriptions</h3>
<div class="sect3">
<h4 id="_m_work_plan_class"><a class="anchor" href="#_m_work_plan_class"></a>9.2.1. M_WORK_PLAN Class</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>M_WORK_PLAN</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Materialised form of <code>WORK_PLAN</code>.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>plans</strong>: <code>List&lt;M_TASK_PLAN&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Member Plans.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>owner</strong>: <code>WORK_PLAN</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Owning Work Plan definition.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>timeline</strong>: <code>M_TIMELINE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Materialised global timeline.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>calendar</strong>: <code>M_CALENDAR</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Materialised global calendar.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>context</strong>: <code>M_PLAN_DATA_CONTEXT</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Materialised global context.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect3">
<h4 id="_m_task_plan_class"><a class="anchor" href="#_m_task_plan_class"></a>9.2.2. M_TASK_PLAN Class</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>M_TASK_PLAN</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Root object of a materialised Task Plan structure, used in execution.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>start_time</strong>: <code>Iso8601_date_time</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Nominal start time for the Task Plan as a whole. The timings of individual Tasks may be specified as offsets from this time, via <code>PLANNED_TIME.<em>relative_offset</em></code>.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>definition</strong>: <code>M_TASK_GROUP</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Root of run-time Task Plan Task structure.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>owner</strong>: <code>TASK_PLAN</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Owning Task Plan definition.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>pending_callbacks</strong>: <code>List&lt;M_CALLBACK&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Reference list of all wait conditions in the Task Plan, and current status.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>principal_performer</strong>: <code>M_PERFORMER_ALLOCATION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Run-time principal performer - a person or other agent.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Functions</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>lifecycle_state</strong> (): <code>TASK_LIFECYCLE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Lifecycle state of Task Plan, derived as a copy of the <code><em>lifecycle_state()</em></code> of the definition <code>TASK_GROUP</code>.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect3">
<h4 id="_m_performer_allocation_class"><a class="anchor" href="#_m_performer_allocation_class"></a>9.2.3. M_PERFORMER_ALLOCATION Class</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>M_PERFORMER_ALLOCATION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Tracking information for a current performer allocation.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>performer</strong>: <code>PARTY_IDENTIFIED</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identity of allocated performer.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>connection</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>URI used to connect to performer (e.g. application, messaging channel) for notifications.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>other_details</strong>: <code>Hash&lt;String, String&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Archetypable details.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect3">
<h4 id="_m_plan_item_class"><a class="anchor" href="#_m_plan_item_class"></a>9.2.4. M_PLAN_ITEM Class</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong><em>M_PLAN_ITEM (abstract)</em></strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Abstract parent of materialised run-time types that correspond to design time <code>PLAN_ITEM</code> instances.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>definition</strong>: <code>PLAN_ITEM</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Corresponding item from Task Plan definition. Redefined in descendants to the definition type corresponding to each runtime (RT_XXX) type.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect3">
<h4 id="_m_task_group_class"><a class="anchor" href="#_m_task_group_class"></a>9.2.5. M_TASK_GROUP Class</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>M_TASK_GROUP</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Materialised form of <code>TASK_GROUP</code> from a Task Plan definition.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>M_PLAN_ITEM</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>members</strong>: <code>List&lt;M_PLAN_ITEM&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Member run-time items in group, mimicking structure of the corresponding definition group instance.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1<br>
(redefined)</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>definition</strong>: <code>TASK_GROUP</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Reference to corresponding TASK_GROUP instance in Task Plan definition.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Functions</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>lifecycle_state</strong> (): <code>TASK_LIFECYCLE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Effective lifecycle state, computed from the states of members of the group.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect3">
<h4 id="_m_task_class"><a class="anchor" href="#_m_task_class"></a>9.2.6. M_TASK Class</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>M_TASK</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Materialised form of <code>TASK</code> type and its descendants from a Task Plan definition.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>M_PLAN_ITEM</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>lifecycle_state</strong>: <code>TASK_LIFECYCLE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Current lifecycle state of this Task at run-time.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>events</strong>: <code>List&lt;TASK_EVENT_RECORD&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>List of references to run-time events that have occurred on this Task.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>preconditions</strong>: <code>List&lt;EL_ASSERTION&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Run-time form of preconditions on corresponding TASK in Task Plan definition.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1<br>
(redefined)</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>definition</strong>: <code>TASK</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Reference to corresponding TASK instance in Task Plan definition.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect3">
<h4 id="_m_task_action_class"><a class="anchor" href="#_m_task_action_class"></a>9.2.7. M_TASK_ACTION Class</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>M_TASK_ACTION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Materialised form of <code>TASK_ACTION</code> type.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>definition</strong>: <code>TASK_ACTION</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect3">
<h4 id="_m_dispatchable_action_class"><a class="anchor" href="#_m_dispatchable_action_class"></a>9.2.8. M_DISPATCHABLE_ACTION Class</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>M_DISPATCHABLE_ACTION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Materialised form of <code>DISPATCHABLE_ACTION</code>.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>M_TASK_ACTION</code></p></td>
</tr>
</tbody>
</table>
</div>
<div class="sect3">
<h4 id="_m_performable_action_class"><a class="anchor" href="#_m_performable_action_class"></a>9.2.9. M_PERFORMABLE_ACTION Class</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>M_PERFORMABLE_ACTION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Materialised form of <code>PERFORMABLE_ACTION</code>.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>M_TASK_ACTION</code></p></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_plan_execution_history"><a class="anchor" href="#_plan_execution_history"></a>10. Plan Execution History</h2>
<div class="sectionbody">
<div class="sect2">
<h3 id="_overview_5"><a class="anchor" href="#_overview_5"></a>10.1. Overview</h3>
<div class="paragraph">
<p>The history of execution events from a Work Plan execution is represented in the runtime instances of classes defined in the <code>proc.task_planning.history</code> package, of which <code>EXECUTION_HISTORY</code> is the root.</p>
</div>
<div id="proc_task_planning_history" class="imageblock text-center text-center">
<div class="content">
<img src="UML/diagrams/PROC-task_planning.history.svg" alt="PROC task planning.history">
</div>
<div class="title">Figure 44. proc.task_planning.history package</div>
</div>
<div class="paragraph">
<p>As shown above, two types of execution event are defined:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><code>TASK_EVENT_RECORD</code>: type representing a change to one consitutent Task. Thus, if the performer cancels a particular Task within the list, a <code>TASK_EVENT_RECORD</code> will be added to the history, including Task id, time, and reason; notifications can also be recorded on such events;</p>
</li>
<li>
<p><code>TASK_PLAN_EVENT_RECORD_</code>: type representing any kind of execution event not linked to a specific Task, for example 'plan abandonment', 'new principal performer'.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The first type may also include forward references to EHR Entries that were committed as a result of a Task being performed. This facilitates logical indexing of planned and performed work items.</p>
</div>
<div class="paragraph tbd">
<p>ISSUE-fwd-refs: entry_instance is a forward reference - which requires updating the Task Plan after the Tasks have beed performed and relevant Entries committed. Is this complication worth the benefit obtained, i.e. directly followable links rather than querying, to find Entries from the Task Plan items? Is being able to determine the resulting Entries starting from the Task Plan even useful?</p>
</div>
<div class="paragraph">
<p>The Execution history for a Plan execution will grow and might become quite long for some Task Plan executions. How it may be persisted in various ways. The following possibilities are all compatible with both the model, and typical EHR requirements:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>In the Task Plan application persistence:</p>
<div class="ulist">
<ul>
<li>
<p>persist the full history, delete or archive once the Task Plan is fully completed;</p>
</li>
</ul>
</div>
</li>
<li>
<p>In the EHR:</p>
<div class="ulist">
<ul>
<li>
<p>persist the full history in some or all cases, if useful in the EHR environment (e.g. for teaching);</p>
</li>
<li>
<p>persist a partial / filtered version of the history, e.g. retain only <em>cancel</em> and <em>abort</em> events, on the basis that completed Tasks will show up as <code>ACTIONs</code> elsewhere in the EHR;</p>
</li>
<li>
<p>don&#8217;t persist any of the history - rely on the workflow application persistence for it during execution, and forget afterward.</p>
</li>
</ul>
</div>
</li>
</ul>
</div>
<div class="paragraph">
<p>This approach cleanly separates the definitional representation of a Task Plan, which should only change if changes to the plan are made, and the execution state, which is built during the work performance.</p>
</div>
</div>
<div class="sect2">
<h3 id="_class_descriptions_6"><a class="anchor" href="#_class_descriptions_6"></a>10.2. Class Descriptions</h3>
<div class="sect3">
<h4 id="_task_plan_execution_history_class"><a class="anchor" href="#_task_plan_execution_history_class"></a>10.2.1. TASK_PLAN_EXECUTION_HISTORY Class</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>TASK_PLAN_EXECUTION_HISTORY</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>History of Task Plan execution events and notifications. May be used by a workflow application to record all events during execution.</p>
</div>
<div class="paragraph">
<p>May be persisted in the EHR in partial or complete form, or not at all.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>task_events</strong>: <code>List&lt;TASK_EVENT_RECORD&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Task-level execution time events.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>plan_events</strong>: <code>List&lt;TASK_PLAN_EVENT_RECORD&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Execution time events that occurred at the Task Plan level, i.e. not to a particular task. These include events such as Task Plan abandonment.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect3">
<h4 id="_event_record_class"><a class="anchor" href="#_event_record_class"></a>10.2.2. EVENT_RECORD Class</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong><em>EVENT_RECORD (abstract)</em></strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Abstract parent of types representing execution time events on a Task Plan.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>time</strong>: <code>Iso8601_date_time</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Time the event occurred.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>description</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional description associated with the event. Would typically be populated for Cancel and Abort events.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect3">
<h4 id="_task_plan_event_record_class"><a class="anchor" href="#_task_plan_event_record_class"></a>10.2.3. TASK_PLAN_EVENT_RECORD Class</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>TASK_PLAN_EVENT_RECORD</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Record of an runtime event to a Task Plan, including abandonment, performer allocation and re-allocation and so on.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>EVENT_RECORD</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>details</strong>: <code>Hash&lt;String, String&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Other details as a name/value list.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect3">
<h4 id="_task_event_record_class"><a class="anchor" href="#_task_event_record_class"></a>10.2.4. TASK_EVENT_RECORD Class</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>TASK_EVENT_RECORD</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Record of an event for a single Task. Records task identifier, time, resulting lifecycle state and optional reason.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Inherit</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><p class="tableblock"><code>EVENT_RECORD</code></p></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>task_id</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identification of Task in the Task Plan structre using a path of the form <code>/task_group_id/task_group_id</code>.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>lifecycle_state</strong>: <code>TASK_LIFECYCLE</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>The lifecycle state that was reached due to this event.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>notifications_sent</strong>: <code>List&lt;TASK_NOTIFICATION_RECORD&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Notifications that were performed as part of this Task Event.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>entry_instances</strong>: <code>List&lt;LOCATABLE_REF&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Forward references to Entry (e.g. <code>ACTION</code>, <code>OBSERVATION</code> etc) that was recorded as a result of this Task being performed. If this is set, it indicates that the planned Task is 'done' i.e. checked off the plan.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>preconditions_satisfied</strong>: <code>Boolean</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Set to True if all preconditions defined on the corresponding Task were satisfied at runtime. If set to False, and there were preconditions, this means that preconditions were overridden by the user at runtime.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>wait_conditions_satisfied</strong>: <code>Boolean</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Set to True if all wait_conditions for the corresponding Task were satisfied when it was performed. If False, and there were wait_conditions, wait_conditions were overridden by the user at runtime.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>0..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>lifecycle_transition_reason</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Optional reason for lifecycle transition.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect3">
<h4 id="_task_notification_record_class"><a class="anchor" href="#_task_notification_record_class"></a>10.2.5. TASK_NOTIFICATION_RECORD Class</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Class</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>TASK_NOTIFICATION_RECORD</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Record of a notification to another party (i.e. performer).</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Attributes</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>reciever</strong>: <code>PARTY_PROXY</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identification of the receiver party</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>receiver_task_plan</strong>: <code>String</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Identifier of receiving Task Plan.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>1..1</strong></p></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>details</strong>: <code>Hash&lt;String, String&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Other details as a name/value list.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_transactional_service_model"><a class="anchor" href="#_transactional_service_model"></a>11. Transactional Service Model</h2>
<div class="sectionbody">
<div class="sect2">
<h3 id="_overview_6"><a class="anchor" href="#_overview_6"></a>11.1. Overview</h3>
<div class="paragraph">
<p>The information structures required to represent planned Tasks and references at design and runtime are non-trivial. For this reason, an abstract service is defined, with a transactional interface that converts calls into correct underlying information structures. The following UML diagram illustrates the services.</p>
</div>
<div id="proc_task_planning_service" class="imageblock text-center text-center">
<div class="content">
<img src="UML/diagrams/PROC-task_planning.service.svg" alt="PROC task planning.service">
</div>
<div class="title">Figure 45. proc.task_planning.service package</div>
</div>
</div>
<div class="sect2">
<h3 id="_definition_interface"><a class="anchor" href="#_definition_interface"></a>11.2. Definition Interface</h3>
<div class="paragraph tbd">
<p>TBC:</p>
</div>
</div>
<div class="sect2">
<h3 id="_execution_time_interface"><a class="anchor" href="#_execution_time_interface"></a>11.3. Execution-time Interface</h3>
<div class="paragraph tbd">
<p>TBC:</p>
</div>
</div>
<div class="sect2">
<h3 id="_class_descriptions_7"><a class="anchor" href="#_class_descriptions_7"></a>11.4. Class Descriptions</h3>
<div class="sect3">
<h4 id="_i_work_plan_definition_interface"><a class="anchor" href="#_i_work_plan_definition_interface"></a>11.4.1. I_WORK_PLAN_DEFINITION Interface</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Interface</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>I_WORK_PLAN_DEFINITION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Task planning API that converts transactional calls to correct Task Planning information structures at Work Plan level.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Functions</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>plans</strong> (): <code>List&lt;UID_BASED_ID&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>List of Task Plan ids for this Work Plan.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>plan</strong> (<br>
a_task_plan_id: <code>UID_BASED_ID[1]</code><br>
): <code>List&lt;I_TASK_PLAN_DEFINITION&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Obtain a Task Plan definition API interface.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect3">
<h4 id="_i_task_plan_materialised_interface"><a class="anchor" href="#_i_task_plan_materialised_interface"></a>11.4.2. I_TASK_PLAN_MATERIALISED Interface</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Interface</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>I_TASK_PLAN_MATERIALISED</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Task planning API for materialised Task Plan level.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Functions</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>materialise</strong></p></td>
<td class="tableblock halign-left valign-top"><div class="content"></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>activate</strong></p></td>
<td class="tableblock halign-left valign-top"><div class="content"></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>terminate</strong></p></td>
<td class="tableblock halign-left valign-top"><div class="content"></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect3">
<h4 id="_i_work_plan_definition_interface_2"><a class="anchor" href="#_i_work_plan_definition_interface_2"></a>11.4.3. I_WORK_PLAN_DEFINITION Interface</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Interface</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>I_WORK_PLAN_DEFINITION</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Task planning API that converts transactional calls to correct Task Planning information structures at Work Plan level.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Functions</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>plans</strong> (): <code>List&lt;UID_BASED_ID&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>List of Task Plan ids for this Work Plan.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>plan</strong> (<br>
a_task_plan_id: <code>UID_BASED_ID[1]</code><br>
): <code>List&lt;I_TASK_PLAN_DEFINITION&gt;</code></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Obtain a Task Plan definition API interface.</p>
</div></div></td>
</tr>
</tbody>
</table>
</div>
<div class="sect3">
<h4 id="_i_task_plan_materialised_interface_2"><a class="anchor" href="#_i_task_plan_materialised_interface_2"></a>11.4.4. I_TASK_PLAN_MATERIALISED Interface</h4>
<table class="tableblock frame-all grid-all stretch">
<colgroup>
<col style="width: 11.1111%;">
<col style="width: 33.3333%;">
<col style="width: 55.5556%;">
</colgroup>
<tbody>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Interface</strong></p></th>
<th class="tableblock halign-center valign-top" colspan="2"><p class="tableblock"><strong>I_TASK_PLAN_MATERIALISED</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Description</strong></p></th>
<td class="tableblock halign-left valign-top" colspan="2"><div class="content"><div class="paragraph">
<p>Task planning API for materialised Task Plan level.</p>
</div></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Functions</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Signature</strong></p></th>
<th class="tableblock halign-center valign-top"><p class="tableblock"><strong>Meaning</strong></p></th>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>materialise</strong></p></td>
<td class="tableblock halign-left valign-top"><div class="content"></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>activate</strong></p></td>
<td class="tableblock halign-left valign-top"><div class="content"></div></td>
</tr>
<tr>
<th class="tableblock halign-center valign-top"></th>
<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>terminate</strong></p></td>
<td class="tableblock halign-left valign-top"><div class="content"></div></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_relationship_with_other_openehr_ehr_artefacts"><a class="anchor" href="#_relationship_with_other_openehr_ehr_artefacts"></a>12. Relationship with other openEHR EHR Artefacts</h2>
<div class="sectionbody">
<div class="sect2">
<h3 id="_overview_7"><a class="anchor" href="#_overview_7"></a>12.1. Overview</h3>
<div class="paragraph">
<p>One of the side-effects of distinct state machines for <code>INSTRUCTIONs</code> and Task Plans is that not all careflow steps and states in the former need to be represented as Tasks in a Task Plan. For example, a significant number of careflow steps defined in <code>ACTION</code> archetypes are for non-Active states, e.g. Planning, Postponement, Suspension etc. These steps do not need to have Tasks defined for them, since by definition they are nearly all unplanned.</p>
</div>
<div class="paragraph">
<p>As a consequence, most Tasks in a Task Plan correspond only to Active-state careflow steps of constituent order <code>INSTRUCTIONs</code>.</p>
</div>
</div>
<div class="sect2">
<h3 id="_execution_time_ehr_structures"><a class="anchor" href="#_execution_time_ehr_structures"></a>12.2. Execution-time EHR Structures</h3>
<div class="paragraph">
<p>The model described here provides significant power when used with openEHR Instructions, Actions and Observations to represent clinical work driven by guidelines and order sets. This section describes the relationship of information instances that correspond to the various phases of work described earlier, as follows:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><em>ordering</em>: creation of <code>INSTRUCTIONs</code>;</p>
</li>
<li>
<p><em>task planning</em>: creation of <code>TASK_PLAN(s)</code> representing a plan of individual tasks that achieve the order intention;</p>
</li>
<li>
<p><em>execution</em>: creation of <code>ACTION</code> and other Entry types that document the Tasks as they were performed.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>The model supports logical linking between these items to support workflow traceability. The following figure illustrates both aspects, which are further described below.</p>
</div>
<div id="runtime_planning_structures" class="imageblock text-center text-center">
<div class="content">
<img src="task_planning/diagrams/planning_runtime_structures.svg" alt="planning runtime structures" width="80%">
</div>
<div class="title">Figure 46. Runtime planning structures</div>
</div>
<div class="paragraph">
<p>Various links can be recorded at execution time, as follows:</p>
</div>
<div class="ulist">
<ul>
<li>
<p><strong>planned Task to Order reference</strong>: the <code>TASK_EVENT_RECORD.entry_instances</code> attribute is used to record reverse reference(s) from a <code>TASK</code> to an <code>ACTIVITY</code> within an <code>INSTRUCTION</code> that records a corresponding order, if one exists (shown on the diagram as a logical link from <code>DEFINED_ACTION</code> to <code>ACTIVITY</code> instances);</p>
</li>
<li>
<p><strong>planned Task to performed Task reference</strong>: the <code>TASK_EVENT_RECORD.entry_instances</code> attribute is used to record a forward reference to the Entry instance that was created when this Task was performed, i.e. some <code>ACTION</code>, <code>OBSERVATION</code> etc (shown on the diagram as a logical link from <code>DEFINED_ACTION</code> to <code>ACTION</code> instances);</p>
</li>
<li>
<p><strong>performed Task to planned Task reference</strong>: the <code>ENTRY.<em>workflow_id</em></code> attribute may be used to record a reverse reference from an <code>ACTION</code>, <code>OBSERVATION</code> etc to a causing <code>TASK</code> instance.</p>
</li>
</ul>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_references"><a class="anchor" href="#_references"></a>References</h2>
<div class="sectionbody">
<div class="paragraph">
<p><a id="Hofstede_van_der_Aalst2009"></a>Hofstede, A. H. M. T., Aalst, W. M. P. van der, Adams, M., &amp; Russell, N. (2010). <em>Modern Business Process Automation: YAWL and its Support Environment</em>. Springer-Verlag.</p>
</div>
<div class="paragraph">
<p><a id="Schrijvers_et_al2012"></a>Schrijvers, G., Hoorn, A. van, &amp; Huiskes, N. (2012). The care pathway: concepts and theories: an introduction. In <em>International journal of integrated care</em>.</p>
</div>
</div>
</div>
</div>
<div id="footer">
<div id="footer-text">
Last updated 2020-05-27 16:01:23 +0100
</div>
</div>
<link rel="stylesheet" href="https://specifications.openehr.org/styles/pygments-default.css">
</body>
</html>