A task to be performed. performed as a part of a workflow and the related informations like inputs, outputs and execution progress. While very simple workflows can be implemented with Request alone, most workflows would require a Task (explicit or contained) as a means to track the execution progress (i.e. inputs, outputs, status). Please refer to Fulfillment/Execution .

The URL pointing to a FHIR -defined protocol, guideline, orderset or other definition that is adhered to in whole or in part by business identifier for this Task. task.

BasedOn refers to a higher-level authorization that triggered the creation of the task. It references a "request" resource such as a ServiceRequest, MedicationRequest, ServiceRequest, CarePlan, etc. which is distinct from the "request" resource the task is seeking to fulfill. This latter resource is referenced by FocusOn. focus. For example, based on a ServiceRequest CarePlan (= BasedOn), basedOn), a task is created to fulfill a procedureRequest ServiceRequest ( = FocusOn focus ) to collect a specimen from a patient.

Task.basedOn is never the same as Task.focus. Task.basedOn will typically not be present for 'please fulfill' Tasks as a distinct authorization is rarely needed to request fulfillment. If the Task is seeking fulfillment of an order, the order to be fulfilled is always communicated using focus , never basedOn. However, authorization may be needed to perform other types of Task actions. As an example of when both would be present, a Task seeking suspension of a prescription might have a Task.basedOn pointing to the ServiceRequest ordering surgery (which is the driver for suspending the MedicationRequest - which would be the Task.focus).

An A shared identifier that links together common to multiple tasks independent Task and other requests Request instances that were created in activated/authorized more or less simultaneously by a single author. The presence of the same context. identifier on each request ties those requests together and may have business ramifications in terms of reporting of results, billing, etc. E.g. a requisition number shared by a set of lab tests ordered together, or a prescription number shared by all meds ordered at one time.

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. i+R[9]Cs this a proposed task, a planned task, an actionable task, etc.

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

In most cases, Tasks will have an intent of "order".

Indicates how quickly the Task should be addressed with respect to other requests.

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

If true indicates that the Task is asking for the specified action to not occur.

The attributes provided with the Task qualify what is not to be done. For example, if a requestedPeriod is provided, the 'do not' request only applies within the specified time. If a requestedPerformer is specified then the 'do not' request only applies to performers of that type. Qualifiers include: code, subject, occurrence, requestedPerformer and performer.

In some cases, the Request.code may pre-coordinate prohibition into the requested action. E.g. 'NPO' (nothing by mouth), 'DNR' (do not resuscitate). If this happens, doNotPerform SHALL NOT be set to true. I.e. The resource SHALL NOT have double negation. (E.g. 'Do not DNR').

When Task.focus refers to a Request Resource, it is that Request's doNotPerform Flag that indicates that the action should not be performed. A Task can be used to request that authorized action is not performed by having task.focus point to that request resource and use Task.code as the do not perform indicator.

Note that the use of doNotPerform and negation in Task.code can cause ambiguity and the impact of this should be considered not only for task but also for all related resources.

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

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

The request being actioned fulfilled or the resource being manipulated (changed, suspended, etc.) 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.). Typically a Task should only have one focus. If multiple focuses are provided, then action must be taken on the complete set as a whole (i.e,. all must be accepted, rejected, cancelled, held, completed, etc. as a whole). If there is a possibility to have different statuses for different focuses, then there SHALL be a separate Task instance for each focus.

What task is acting on.

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 encounter the task originated within.

Indicates the start and/or end of the period of time when completion of the task is desired to take place.

This is typically used when the Task is not seeking fulfillment of a focus Request, as in that case the period would be specified on the Request and/or in the Task.restriction.period. Instead, it is used for stand-alone tasks.

Identifies the time action was first taken against the task (start) and/or the time final action was taken against the task prior to marking it as completed (end).

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

Group is only allowed in the circumstance where the group represents a family or a household, and should not represent groups of Practitioners where other more specific resources can be used instead.

The kind of participant or specific participant that should perform the task.

Use to distinguish tasks on different activity queues.

Group is only allowed in the circumstance where the group represents a family or a household, and should not represent groups of Practitioners where other more specific resources can be used instead.

Individual organization or Device currently Party responsible for managing task execution.

Identifies who is expected to perform this task.

Tasks may be created with an owner not yet identified. Group is only allowed in the circumstance where the group represents a family or a household, and should not represent groups of Practitioners where other more specific resources can be used instead.

Principal physical location where The entity who performed the this task is performed. requested task.

A code or description of the performer of the task.

Ties the event to where the records are likely kept and provides context around the event occurrence (e.g. if it occurred inside The actor or outside a dedicated healthcare setting). entity who performed the task.

Group is only allowed in the circumstance where the group represents a family or a household, and should not represent groups of Practitioners where other more specific resources can be used instead.

A description or code indicating why Principal physical location where this task needs to be is performed.

Provides context around the event occurrence (e.g. if it occurred inside or outside a dedicated healthcare setting).

This should only be included if there is no focus specified when the Task to be/being performed happens or if it differs from is expected to happen primarily within the reason indicated bounds of a single Location. Other locations (e.g. source, destination, etc.) would either be reflected on the focus. 'basedOn' Request or be conveyed as distinct Task.input values.

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

Tasks might This will typically not be justified based present for Tasks with a code of 'please fulfill' as, for those, the reason for action is conveyed on an Observation, the Request pointed to by Task.focus. Some types of tasks will not need a Condition, 'reason'. E.g. a past or planned procedure, etc. This should only request to discharge a patient can be included if there is no focus or if it differs from inferred to be 'because the patient is ready' and this would not need a reason indicated to be stated on the focus. Use the CodeableConcept text element in Task.reasonCode if the data is free (uncoded) text. Task.

Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be relevant to the Task.

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

Links to Provenance records for past versions of this Task that identify key state transitions or updates that are likely to be relevant to a user looking at the current version of the task.

This element does not point to the Provenance associated with the current version of the resource - as it would be created after this version existed. The Provenance for the current version can be retrieved with a _revinclude.

If the Task.focus is a request resource and the task is seeking fulfillment (i.e. is asking for the request to be actioned), this element identifies any limitations on what parts of the referenced request should be actioned.

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

This element should only be used when the Task is seeking fulfillment of a request resource that authorizes a broader set of subjects, repetitions and/or time-period than the Task itself is seeking execution against. It is not used otherwise.

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 The time-period is for which fulfillment is sought. This must fall within the overall time period authorized in the referenced request. E.g. ServiceRequest.occurance[x].

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

This is distinct from Task.executionPeriod. ExecutionPeriod indicates when the task needs to be initiated, while Task.restriction.period specifies the subset of the overall authorization that this period covers. For example, a MedicationRequest with an overall effective period of 1 year might have a Task whose restriction.period is 2 months (i.e. satisfy 2 months of medication therapy), while the execution period might be 'between now and 5 days from now' - i.e. If you say yes to this, then you're agreeing to supply medication for that 2 month period within the next 5 days.

Note that period.high is the due date representing the time by which the task should be completed.

For requests that are targeted to more than on directed at multiple potential recipient/target, for whom recipients or targets, this is used to specify the individual or entity from whom fulfillment sought? is being sought.

If seeking fulfillment of a ServiceRequest where the ServiceRequest.subject was a Group of devices, but the Task was only seeking execution against a single device. If just creating a Task that is to manipulate a device in the absence of a broader order, there's no need for restriction.recipient. The Device to be manipulated would be the Task.focus (and potentially the Task.for - if the action wasn't for the benefit of a Patient or some other record).

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. distinguish between inputs.

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

The type of the input may affect how it is used in the task. 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. A code or description to distinguish between outputs.

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.