Definition Model

Enumeration representing possible lifecycle states for a Task lifecycle transition.

Integer-based values.

Task is defined, but not yet available for execution.

Value = 0.

Task is available for execution by the performer, 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.

Value = 1.

Task was cancelled prior to or during execution as not needed for success of the Plan. This is a terminal state.

Value = 2.

Task was aborted due to completion being impossible, i.e. ended prematurely without meeting normal conditions of completion. This is a terminal state.

Value = 4.

Task has been commenced or resumed from 'suspend' state.

Value = 5.

Task is put on hold, i.e. not actively being performed while in this state.

Value = 6.

Task was completed in the intended way. This is a terminal state.

Value = 8.

Top-level object of any logical work plan. References one or more TASK_PLANs that described the work, typically of each performer, although a single TASK_PLAN may also have multiple performers.

The attribute care_pathway and `care_plan`provide a way of associating a Work Plan with a published care pathway, and an operational care plan from within the EHR, if available.

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.

The ITEM_STRUCTURE type is used to allow population at runtime with an archetype based on e.g. BibTex publication reference fields, such as the following:

References to all Task Plans use in this Work Plan. In general, only some of these are top-level Plans.

Care plan in EHR from which this Work Plan is derived, if any.

Global calendar object, containing events fixed in time relevant to the Plan’s Tasks, for example appointments.

Global timeline of Work Plan, on which Tasks with planned times can be listed.

Global Work Plan data context.

Reference list of all defined Event Listeners.

The set of Task Plans that are active at Work Plan activation. Does not include Task Plans referred to from HAND_OFF or SUB_PLAN.

TODO: change to computed?

Clinical applicability of this Work Plan to subject of work, e.g. 'acute ischaemic stroke' etc. May be derived from a governing guideline.

Orders tracked by Tasks in this Work Plan.

Archetypable structure for recording classification of Work Plans, e.g. business process category, administrative category etc.

Note that the same kind of classifications can be applied to Tasks and Groups via PLAN_ITEM.classification.

Work Plan global calendar in which all absolute-time Calendar Events are recorded.

Entries in calendar.

List of Plan Items that have a wait_condition containing a TIMELINE_MOMENT event.

List of Plan Items that have a wait_condition containing a TIMELINE_MOMENT.

Reference list of all defined Timers.

A single calendar entry.

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 TASK_GROUP containing PLAN_ITEMs, which are either atomic TASKs, more TASK_GROUPs or conditional Groups.

A Task Plan specifies a principal_performer, representing a kind of actor who can perform the Tasks, and bounding start_time and completion_time information.

It has an associated execution_history that can be used to record work events in time.

The guideline 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 WORK_PLAN.care_pathway if set.

Human-understandable description of the Task Plan, which may be specific to the work items and patient.

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.

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.

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.

The ITEM_STRUCTURE type is used to allow population at runtime with an archetype based on e.g. BibTex publication reference fields, such as the following:

The Tasks for the main part of this Task Plan; this section of the plan may be repeatable.

History of execution events for an execution of this Task Plan.

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.

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 execution_time attribute of TASKs in the Plan.

Due date/time expressed as an offset, to be converted to a real date/time at activation.

Optional identifier for an order set, which is understood as a type of order set, e.g. 'R-CHOP-14'.

Identifier of instance of an order set on which this Task Plan is based, if there is one.

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.

Specification of principle performer of this Task Plan as a Participation, in terms of role and optionally function, mode and specific performer as appropriate.

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.

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.

Organisational role, i.e. the professional type of participant in the activity. Preferably coded.

Optional field for recording the 'mode' of the performer / activity interaction, e.g. present, by telephone, by email etc.

The id and possibly demographic system link of the party participating in the activity.

Condition for participation in the Plan item.

Parent type of structural Task types that may appear within a Task Plan structure.

Human-readable form of the task directive.

Optional specification of repetitions.

Archetypable structure for recording classification of Task Groups or Tasks, e.g. business process category, administrative category etc.

Optional wait specification for Plan Item (Task or Group) initiation. If not set, the Plan Item is immediately available once execution reaches it. If set, it becomes available when any Event in events occurs.

Optional data-set to review prior to / as part of performing the Plan element.

Optional reference to a step within the guideline referenced by the current Task Plan (if set) or else the care_pathway of the Work Plan, which is the basis of this Plan Item, i.e. single Task or Task Group.

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.

Archetypable structure for recording non hard-modelled information.

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 available state, due to performer activity.

Definition of repetition for a Plan Item. The repeats 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 repeats.

If set, the terminate_condition attribute defines when repetition should cease, once the minimum number of repeats has occurred according to repeats. 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.

If period is set, this defines the duration between the start of each iteration at execution time. It has the effect at runtime of adding a wait_spec with a TIMELINE_MOMENT event to each PLAN_ITEM copy in the materialised form, i.e. creating the same structure as would have been created if the repetitions had been manually specified.

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.

States a condition for when repetition should stop. If set, tested prior to each further potential repetition once the minimum number have been executed.

Optional period of repetition, i.e. duration between the commencement of each PLAN_ITEM clone in the materialised form.

Grouping structure that defines the graph structure of a Task Plan, replacing node-to-node references.

This allows Task Group to define the execution basis for a collection of Tasks, which may include more Task groups.

The execution_type attribute defines the mode of execution. If not set, sequential execution is assumed.

If set to parallel, the Task Group represents a split/join pair with respect to all contained Tasks and Groups. In this case, concurrency_mode may be set to control the processing. If it is not set, 'AND' logic is assumed (i.e. and_all_paths).

Set of Tasks to perform. Execution order is defined by the execution_type setting, either sequential or parallel (no order).

Basis for executing the Task items contained in this Task Group.

Mode in which to execute if execution type is parallel.

Other rules that may control execution over and above the basic sequential / parallel scheme, e.g.

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.

Enumeration specifying types of execution for a set of Tasks.

Items execute in order, one after the other.

Items may be executed in parallel, with no regard to order in the representation.

Mode in which concurrent processing should proceed.

Only one parallel path is followed.

All paths are followed, and Group completes only when all complete.

Group completes when any one path completes.

Group is complete when all paths commenced complete.

Rule controlling execution in addition to basic sequential / parallel setting.

TODO: define detail.

Atomic Task that is typed according to the kind of TASK_ACTION it includes. A TASK has a lifecycle that can be progressed in the plan execution, i.e. in the Materialised form.

Task Action definition.

References to order(s) being created and / or tracked by this Task. The value(s) must match ORDER_REF.order_tag values from the list WORK_PLAN.order_list and be unique within the list.

Multiple tags are only required if the same Task causes creation of, or tracks, more than one order.

Inv_order_tags: order_tags /= Void implies not order_tags.is_empy

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 action.

If wait is True, the Task blocks until the target work thread returns. If callback 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 (wait = True, no callback), a global timer will be created for the Task to deal with the situation where the dispatch target never returns.

Flag indicating whether to wait or continue in the current Plan after the dispatch notification has been achieved. wait = True corresponds to a context switch (block and wait) while wait = False indicates a context fork.

Optional callback notification handler.

Represents a Task that can be performed by the principal performer during the Plan execution.

Associated data-set template and/or form via which data to be captured during this Task will actually be entered.

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.

Performable Actions have further properties.

Optional reference back to the ACTIVITY of an INSTRUCTION that generated this TASK.

TODO: may be movable to PERFORMABLE_ACTION.

Condition which must be met for the Task Action to be available to perform in a runtime execution context.

Costing data related to this Task item.

Clinical preconditions expressing when the Task is safely executable with respect to the principal performer and subject.

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'.

Evaluated when encountered.

An optional formal Boolean expression that can be machine-evaluated at runtime to determine availability, if the relevant variables exist.

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.

Descriptions of resources required for the Task, if required to be processed at runtime as pre-conditions to Task execution.

List of participations for task item.

Description of a resource with optional external system reference.

TODO: explain external_ref.

Text or coded description of resource.

Reference to resource, e.g. in scheduling or other system.

TODO: may need to be a more powerful reference like a SYSTEM_CALL.

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 ENTRY (usually an ACTION) that will be used to record the Task’s execution.

The entry_instance attribute can be used to record a forward reference to an ACTION or other ENTRY when it has been recorded.

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 ACTION, but more than one may sometimes make sense, e.g. an ACTION and an OBSERVATION.

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.

This attribute is not used computationally.

A Task referencing another Plan within the same Work Plan, to be executed by the current performer. Execution continues on from the previous Task.

For an experienced performer, the referenced Plan, which is usually more detailed may not be needed.

Type of Task Action that is performed by another performer, system or organisation.

A kind of Task representing a hand-off to a different performer in the current Work Plan.

Tasks of the linked Plan become available to that performer, who is also alerted to start work.

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.

Task type for representing a request to an external organisational service or actor not within the current Work Plan.

Identifier of organisation to which the request or order is addressed.

Request identifier for this type request. May be used in callback notification. Other runtime instance-level identifiers may be needed as well.

Request details.

TODO: more details needed.

Request to an external computational system or service.

Definition of call to make.

Task type that represents a dispatch to another Task Plan to be executed by another performer in a Plan Group.

Reference to target TASK_PLAN object.

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.

Form identifier.

Template identifier in String form of an ARCHETYPE_HRID. If used with no form_id, the Execution engine needs to determine how to find a form based on the template identifier.

Other data-set related details.

Optional system call that will populate this data-set.

Optional path to a sub-section of the form identified by form_id. The format of the path is the same as a template or AQL path.

Inv_validity: form_id /= Void or template_id /= Void

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.

Optional information for multi-step form fill and commit interaction with the EHR.

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.

Capture data-sets (forms etc) used to obtain the data displayed in this Review data-set.

Specification of a 'commit group', i.e. a complete data set (usually a multi-part form) that is progressively built and committed in the incomplete lifecycle state, with a final complete state commit.

Unique identifier of this commit group within scope of a single Task Plan.

If True, the Task to which this Dataset Spec is attached is the one that puts it into the complete lifecycle state.

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.

Indicates kind of user override that would be accepted at runtime. If set to a value other than prohibited, user interaction is assumed, and runtime processing must enter a wait state.

Timeout handler to use if CHOICE_GROUP blocks unexpectedly, e.g. due to absent user, unavailable external data item.

Set of branches in this Choice Group.

Inv_parallel: execution_type = EXECUTION_TYPE.parallel

Inv_xor_concurrency: concurrency_mode = CONCURRENCY_MODE.xor_one_path

Enumeration expressing kinds of override that can be stated for a Plan definition decision structure.

Override by user is allowed.

User override allowed with provided reason.

Override by user is prohibited.

Abstract precursor of any subordinate branch in a decision structure.

Special kind of Task Group whose members are all CONDITION_BRANCH instances, each of which represents a conditional expression based on context variables. Member branches are evaluated in order, which enables overlapping conditions. The final branch may be used as a logical else (i.e. 'match-any') branch with a condition of True.

This structure is the equivalent of a programming if/then/else statement.

Set of branches in this Condition Group.

A specialised kind of TASK_GROUP representing a branch in a Condition Group.

Boolean-valued test expression which if True indicates that this Branch is to be followed during execution.

Inv_no_wait_condition: wait_spec = Void

Special kind of Task Group whose members are all DECISION_BRANCH instances, each of which represents a distinct value sub-range, and which represent together the total possible range of values of the test expression.

This structure is the equivalent of a programming 'case' statement. It is processed in order, and for situations that need it, the last branch may use a value_constraint representing 'any value', to represent a catch-all 'else' branch.

Reference to an Expression Language terminal that may be a function call or property reference. The Result value is compared to value_constraint sub-ranges in each of the various output branches, in the manner of a case statement.

Set of branches in this Decision Group.

A specialised kind of TASK_GROUP representing a branch in a Decision Group.

Constraint on result value of the owning Decision Group value, for this branch.

Inv_no_wait_condition: wait_spec = Void

Special kind of Task Group whose members are all ADHOC_BRANCH 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.

Set of branches in this Adhoc Group.

A specialised kind of TASK_GROUP representing a branch in an Ad Hoc Group.

Inv_no_wait_condition: wait_spec = Void

Special kind of Task Group whose members are EVENT_BRANCH instances each representing a mutually exclusive Event Wait, the first of which occurs determines the execution path.

Set of branches in this Event Group.

A specialised kind of TASK_GROUP representing a branch in an Event Group.

Wait_spec_not_void: wait_spec /= Void

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 INSTRUCTION committed to the EHR, normally followed by ACTIONs each representing the execution of an Activity or change of state of the order.

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.

Identifier of openEHR Instruction archetype that contains the order.

Identifier of openEHR Action archetype that defines the actions that may occur with respect to the Instruction activities used in this order.

EHR system order reference. When referencing an openEHR order, this will be a reference to the initial Instruction defining the order.

Object representing time of a Task to be performed in terms of a related event. The start_window is used to add an 'acceptable delay' time within which the Task should be started with respect to the intended start time. The timeout attribute can be used for non-deterministic Events.

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.

Temporal relation to the event of the point or period in time being defined by this Timing Spec.

Timeout handler to use if no other Event is received within a certain time.

Override for next state to enter on receipt of any Event in events. Default processing is to enter the available state.

Wait state for any kind of Event, with a success Action and an optional separate timeout Event Wait state.

Descriptor for event on which this wait state is based.

Action to perform if any listened-for event returns a success result.

Timeout handler to use if no other Event is received within a certain time.

Event listener for a Timer event.

Redefined from EVENT_WAIT.

Inv_no_timeout: timeout = Void

Inv_has_action: success_action /= Void

Specialised Event wait state activated when its event fires. This is often a TIMER_EVENT, 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).

If the reminder is activated, its success_action should be configured to generate a reminder or alert to performer or other user.

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.

Inv_no_timeout: timeout = Void

Inv_has_action: success_action /= Void

Specialised descendant of EVENT_WAIT <CALL_BACK_NOTIFICATION> that adds a fail action. Used for representing post-callback actions.

Default processing if EVENT_ACTION.receiver_thread_next_state is not set:

EVENT_ACTION.receiver_thread_next_state must be set on all

Action to perform if any listened-for event returns a fail result.

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'.

Callback notification on which this Callback wait state is based.

Action(s) to perform on receipt of an event with a particular status. Four possible things can be specified:

If resume_action is set, it dictates where execution resumes; if not, the default is to resume at the next Task in normal execution flow.

System call to perform on receipt of event

Optional message to display to original Task context (i.e. application, form etc) if timer expires.

Optional resume action, used when the intention is to resume in a different location than the default (i.e. next available Task).

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 enclosing Task Group of the original dispatching Task.

If not set, default processing will be performed, which for a Task is to enter the available state.

Inv_custom_actions_next_state: custom_actions.for_all ((ev:EVENT_ACTION) {ev.receiver_thread_next_state /= Void})

Type representing an execution jump to a new location in the current Plan.

Procedure to execute when completion notification received, for example, to display a form, notify performer etc.

TODO: determine details.

Reference to a resume Task in the current Plan, at which to restart when the request / handoff has completed.

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.

Entity representing an Event generated during system execution. Descendants define details of each kind of Event known in the system.

Any kind of Event defined as part of a Plan definition.

Optional delay to event generation.

Archetype-configurable extra meta-data for any event.

Timer expiry event generated by Task Plan engine, after the duration period has elapsed from the moment of execution reaching the Task to which this Event is attached.

Delay from activation time to receive the event notification.

Optional explanatory purpose of Timer.

Specifies an event generated during execution when the Plan clock reaches a corresponding entry in the global calendar.

Identifier of entry within global Plan calendar.

Time of entry in calendar.

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 fixed_time in the day, e.g. 14:30:00, no matter when the Plan is activated.

The timeline_offset attribute can be used to specify a particular offset with respect to a time origin, by default, the origin of the Work Plan. The fixed_time then corresponds to the first occurrence of that time on the clock after the timeline_offset is passed.

This can be used to specify particular times on particular days, e.g.: 07:30:00 on day 3, 14:00:00 on day 5 and so on by setting timeline_offset to numbers of days, e.g. P3D, P5D etc. Note that a value of P1D means the first 24h period after Plan activation, whereas if timeline_offset is not set, the fixed_time is understood to specify the first moment after Plan activation that this time is reached on the Plan clock.

The timeline_origin can be set to specify another time origin, such as the start of execution of the Task Plan, or of a repeat section.

Variable part of time specification, expressed as an offset from the zero time point of the Task Plan. Converted to absolute time at activation.

Fixed time specifier, used to expressed a fixed moment in the day.

Relative origin for timeline_offset. If not set, Work Plan activation is assumed as the time origin.

Inv_validity: timeline_offset /= Void or fixed_time /= Void

Event type for Task transitions, specified in terms of target state reached by the associated Task.

Identifier of Task with which this event is associated.

One or more Task lifecycle transition(s) that defines this event; if more than one, the logical relation is 'OR'.

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.

Natural language or processable description of the event. Needs to be sufficiently detailed to distinguish it from other similar events.

Event type representing a notification from a system of some event, represented by notification type and reference identifier.

Identifier of system that will generate notification.

Type of notification, i.e. among types generated by the source system.

Reference identifier, typically a request identifier from a previous request.

Type of event representing an expression referring to one or more tracked variables, reaching a value or passing a threshold value.

Boolean-returning expression that mentions one or more tracked variables, e.g. heart_rate > 120 bpm. Evaluation controlled by Plan variable context.

System-generated Event created on receipt of notification of completion of the work of the target of a Dispatchable Task.

Identifier of originating Task.

Identifier of original request, may be matchable with EXTERNAL_REQUEST.request_id.

Identifier of subject to which callback relates.

Costing information for a Task.