View raw Markdown
type: resourceresource: Task

Task

Introduction

Scope and Usage

Note to Balloters: To ensure this resource is ready for Normative status, we are seeking ballot comment on the substantive content. The key changes made since R5 include:

A Task resource describes an activity that can be performed and tracks the state of completion of that activity. It is a representation that an activity should be or has been initiated, and eventually, represents the successful or unsuccessful completion of that activity.

Concretely the Task resource could be used in FHIR to serve different purposes like:

Note that there are a variety of processes associated with making and processing orders. Some orders may be handled immediately by automated systems but most require real-world actions by one or more humans. Some orders can only be processed when other real-world actions happen, such as a patient presenting themselves so that the action to be performed can actually be performed. Often these real-world dependencies are only implicit in the order details.

If a Task is seeking to instantiate or modify something, the entity to be instantiated or modified SHALL be pointed to by the Task.focus.

[%stu-note dstu%] Task.instantiatesCanonical and Task.instantiatesURI have been removed from the core elements. Instead, use the following workflow extensions:

[%end-note%]

Background and Context

Using Tasks in a RESTful context

In a RESTful context, a server functions as a repository of tasks. The server itself, or other agents are expected to monitor task activity and initiate appropriate actions to ensure task completion, updating the status of the task as it proceeds through its various stages of completion. These agents can be coordinated, following well choreographed business logic to ensure that tasks are completed. Task management may also be centrally controlled using some form of a workflow engine, in which case, the workflow engine itself may update and maintain the Task resources in the server, and through its orchestration activities ensure that tasks are completed. The Task resource enables either model of task management yet provides a consistent view of the status of tasks being executed in support of healthcare workflows.

The assignment of tasks into categories by type of task, type of performer and task status enable the server to function as a queue of work items. This queue can be polled or subscribed to by various agents, enabling automation of workflows in FHIR using existing search and subscription mechanisms. Owners, requesters, other agents (e.g. workflow managers) can thus be ready to initiate the next steps in a complex workflow.

[%stu-note dstu%] Currently, task pre-requisites can be represented using Task's `description` element or the RequestOrchestration resource. We are seeking input from the implementer community in evaluating whether there is need for adding another mechanism to this resource for this purpose. [%end-note%]

Boundaries and Relationships

Task spans both intent and event and tracks the execution through to completion. A Task is a workflow step such as cancelling an order, fulfilling an order, signing an order, merging a set of records, admitting a patient. In contrast, Procedures are actions that are intended to result in a physical or mental change to or for the subject (for example, surgery, physiotherapy, training, counseling). A Task resource often exists in parallel with clinical resources. For example, a Task could request fulfillment of a ServiceRequest ordering a procedure that would result in a Procedure, Observation, DiagnosticReport, ImagingStudy or similar resource. Another example would be a Task that requests fulfillment of a CommunicationRequest to be performed between various actors. The task resource tracks the state of a task, enabling systems to ensure that tasks are completed. This information is kept separate from the operational details necessary to complete the task, as those details vary across and even within workflows. That detail is expected to be carried in the referenced .focus of the task.

The Task resource can represent an authorization for a service to be provided or the fulfillment of an authorization (by another Task or resource type that implements the Request pattern). For further information about the separation of responsibilities, refer to the Fulfillment/Execution section of the Request pattern. Information about the details of the fulfillment of an authorization may be handled by additional Task resource instances.

Tasks may have named inputs and outputs. Inputs represent information that is provided in order for a task to be completed. Outputs represent intermediate or final results produced while performing a task. For example, in a task supporting reading of radiology images, the inputs might include both the imaging study to be read, as well as relevant prior images. Outputs could represent radiology measurements as well as the Radiologist's diagnostic report.

Inputs and outputs are tracked by the task because workflow management activity may automate the transfer of outputs from one task to inputs to a subsequent task.

To facilitate the integration of off the shelf workflow applications with FHIR, the Task resource may reference a definition. This definition can represent a description of the workflow activity to be performed, using a standard workflow description language such as BPEL, BPMN, or XPDL, a workflow definition such as those defined in IHE profiles, or even simple written instructions explaining a process to be performed.

Notes

Tasks vs. other Requests

While Task can be used to seek fulfillment of other authorizations such as ServiceRequests, MedicationRequests, etc., Task can also be used on its own to solicit action without any prior authorization. However, such requests for action should be tightly time-bound and be satisfied with a single 'event'. I.e. they should ask as a task-list checkbox that can easily be marked as complete. Any action that requires ongoing repeated performance should be captured using a different type of resource, not Task.

Task Titles

Tasks often have titles (eg "My Tasks", "Outstanding Tasks for Patient X") which can be presented in a list. The task title should go into the Task.code as a coded concept and/or text.

Task state machine

Tasks start in a Draft state. Once they have been assigned to an owner they transition to the Ready state, indicating that they are ready to be performed. Once the owner initiates activity on the task, the task transitions to the In Progress state, indicating that work is being performed. Upon normal completion, the task enters the Completed state. If there is a failure during the task execution that prevents the task from being completed, it can also enter a Failed state, indicating an abnormal termination of the task. A task in any non-terminal state may also be Cancelled, representing an abnormal termination of the task due to external forces, rather than an error condition.

Tasks in any non-terminal state (Draft, Ready, In Progress) can be suspended and resumed. When a task is suspended, it is typically resumed in the state it was in when it was originally suspended. Suspending a task suspends all of its children as well. Resuming a task resumes all of its children.

An In-progress task can also be stopped, returning it to a Ready state. This may be in preparation for delegation or reassignment (e.g., because it cannot be completed by the current owner), to restart a task due to a temporary failure (e.g., to reattempt completion of the activity), or in preparation to allow others to claim the task.

The task history allows applications monitoring the state of a workflow to identify tasks that are long running, perhaps stuck in some queue, to enable management activities that could ensure completion. It also enables tracking of task statistics such as wait time, or time in progress, or time to completion, enabling capture of important task metrics in support of optimization and quality improvement.

The following diagram reflects the "typical" state machine for Task. Note that not all states will be supported by all workflows and that some workflows may support additional transitions, including transitions from terminal states (e.g. back to "in-progress" from "failed" or "completed").

Diagram showing typical state machine for the Task resource

The Cancelled state

While the intention of a "cancelled" task is that all work authorized by the task should cease, this might not always be possible practice. It is possible that the originally requested action could still be completed and still attached to the Task but this would not change the status of the task. If the placer cancels a task, it signals they no longer care about the outcome of the task.

StructureDefinition

Elements (Simplified)

Mappings

Implementation Guide

implementationguide-Task-core.xml

<?xml version="1.0" encoding="UTF-8"?>

<ImplementationGuide xmlns="http://hl7.org/fhir">
  <id value="Task-core"/>
  <version value="0.1"/>
  <name value="TaskHL7Extensions"/>
  <title value="Task  H L7  Extensions"/>
  <status value="draft"/>
  <date value="2017-02-16T00:00:00.000"/>
  <publisher value="Health Level Seven, Inc. - FHIR I WG"/>
  <description value="Defines common extensions used with or related to the Task resource"/>
</ImplementationGuide>

Resource Packs

list-Task-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir">
  <id value="Task-packs"/>
  <status value="current"/>
  <mode value="working"/>
  <entry>
    <item>
      <reference value="ImplementationGuide/Task-core"/>
    </item>
  </entry>
</List>

Search Parameters

Full Search Parameters

Examples

Full Examples

Mapping Exceptions

task-event-mapping-exceptions.xml

Divergent Elements

Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is.

The recorded date is NOT intended to be the same as a database.createdTimestamp - that would be captured as part of resource.meta or possibly Provenance.

It is possible for the same event to be disclosed to different systems at different times. E.g. a patient might tell two different clinicians about a historical event at different visits. If the disclosure is from the patient rather than record transfer from clinician A to B, the recorded date would be the date each respective clinician put the data in their record. If the data flowed from clinician A to B, the recorded date would remain the recorded date as initially set in clinician A's system.

Unmapped Elements

task-fivews-mapping-exceptions.xml

Divergent Elements

Unmapped Elements

task-request-mapping-exceptions.xml

Divergent Elements

Note: This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number.

A status of completed for a "doNotPerform" request indicates that the period of non-performance is now satisfied and the request no longer holds.

One exception to this is that the granularity of Request.intent is allowed to change. For example, a Request identified as an "order" might later be clarified to be a "filler-order". Or, in rarer cases (to meet recipient constraints), the reverse might also occur.

When resources map to this element, they are free to define as many codes as necessary to cover their space and will map to "proposal, plan or order". Can have multiple codes that map to one of these. E.g. "original order", "encoded order", "reflex order" would all map to "order". Expectation is that the set of codes is mutually exclusive or a strict all-encompassing hierarchy. | resource=This element is immutable. Proposed tasks, planned tasks, etc. must be distinct instances.

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

In some cases, the Request.code may pre-coordinate prohibition into the requested action. E.g. "NPO" (nothing by mouth), "DNR" (do not recussitate). If this happens, doNotPerform SHALL NOT be set to true. I.e. The resource shall not have double negation. (E.g. "Do not DNR"). | resource=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.

See additional guidance here. | resource=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.

Unmapped Elements