A task to be performed.

The business identifier for this task.

Identifies a plan, proposal or order that this task has been created in fulfillment of.

An identifier that links together multiple tasks and other requests that were created in the same context.

Billing and/or reporting can be linked to whether multiple requests were created as a single unit.

Task that this particular task is part of.

Allows tasks to be broken down into sub-steps (and this division can occur independent of the original task).

This should usually be 0..1.

The current status of the task.

These states enable coordination of task status with off-the-shelf workflow solutions that support automation of tasks.

An explanation as to why this task is held, failed, was refused, etc.

This applies to the current status. Look at the history of the task to see reasons for past statuses.

Contains business-specific nuances of the business state.

There's often a need to track substates of a task - this is often variable by specific workflow implementation.

Indicates the "level" of actionability associated with the Task. I.e. Is this a proposed task, a planned task, an actionable task, etc.

This element is immutable. Proposed tasks, planned tasks, etc. must be distinct instances.

A name or code (or both) briefly describing what the task involves.

The priority of the task among other tasks of the same type.

Used to identify the service level expected while performing a task.

A free-text description of what is to be performed.

The request being actioned or the resource being manipulated by this task.

Used to identify the thing to be done.

If multiple resources need to be manipulated, use sub-tasks. (This ensures that status can be tracked independently for each referenced resource.).

The entity who benefits from the performance of the service specified in the task (e.g., the patient).

Used to track tasks outstanding for a beneficiary. Do not use to track the task owner or creator (see owner and creator respectively). This can also affect access control.

The healthcare event (e.g. a patient and healthcare provider interaction) during which this task was created.

For some tasks it may be important to know the link between the task or episode of care the task originated within.

The date and time this task was created.

Most often used along with lastUpdated to track duration of task to supporting monitoring and management.

The date and time of last modification to this task.

Used along with history to track task activity and time in a particular task state. This enables monitoring and management.

The creator of the task.

Identifies who created this task. May be used by access control mechanisms (e.g., to ensure that only the creator can cancel a task).

The owner of this task. The participant who can execute this task.

Identifies who is expected to perform this task.

Tasks may be created with an owner not yet identified.

The type of participant that can execute the task.

Use to distinguish tasks on different activity queues.

A description or code indicating why this task needs to be performed.

This should only be included if there is no focus or if it differs from the reason indicated on the focus.

Free-text information captured about the task as it progresses.

Identifies any limitations on what part of a referenced task subject request should be actioned.

Sometimes when fulfillment is sought, you don't want full fulfillment.

Indicates the number of times the requested action should occur.

E.g. order that requests monthly lab tests, fulfillment is sought for 1.

Over what time-period is fulfillment sought.

E.g. order that authorizes 1 year's services. Fulfillment is sought for next 3 months.

For requests that are targeted to more than on potential recipient/target, for whom is fulfillment sought?

A reference to a formal or informal definition of the task. For example, a protocol, a step within a defined workflow definition, etc.

Enables a formal definition of how he task is to be performed (e.g. using BPMN, BPEL, XPDL or other formal notation) to be associated with a task, enabling automation.

Additional information that may be needed in the execution of the task.

Resources and data used to perform the task. This data is used in the business logic of task execution, and is stored separately because it varies between workflows.

A code or description indicating how the input is intended to be used as part of the task execution.

Inputs are named to enable task automation to bind data and pass it from one task to the next.

If referencing a BPMN workflow or Protocol, the "system" is the URL for the workflow definition and the code is the "name" of the required input.

The value of the input parameter as a basic type.

Outputs produced by the Task.

Resources and data produced during the execution the task. This data is generated by the business logic of task execution, and is stored separately because it varies between workflows.

The name of the Output parameter.

Outputs are named to enable task automation to bind data and pass it from one task to the next.

The value of the Output parameter as a basic type.

Task outputs can take any form.