FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

12.1 Resource Task - Content

Orders and Observations icon Work GroupMaturity Level: 4 Trial UseSecurity Category: Not Classified Compartments: Group, Patient

A task to be 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.

12.1.1 Scope and Usage

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.

12.1.2 Background and Context

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

Note to Implementers: 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.

Feedback here icon.

12.1.3 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 may or must be present in order for a task to complete. Outputs represent intermediate or final results produced by a task. For example, in a task supporting reading of radiology image, 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.

12.1.4 References to this Resource

12.1.5 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Task TU DomainResource A task to be performed
+ Rule: Last modified date must be greater than or equal to authored-on date.
+ Rule: Task.restriction is only allowed if the Task is seeking fulfillment and a focus is specified.

Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier 0..* Identifier Task Instance Identifier

... instantiatesCanonical Σ 0..1 canonical(ActivityDefinition) Formal definition of task
... instantiatesUri Σ 0..1 uri Formal definition of task
... basedOn Σ 0..* Reference(Any) Request fulfilled by this task

... groupIdentifier Σ 0..1 Identifier Requisition or grouper id
... partOf Σ 0..* Reference(Task) Composite task

... status ?!Σ 1..1 code draft | requested | received | accepted | +
Binding: Task Status (Required)
... statusReason Σ 0..1 CodeableReference() Reason for current status
Binding: Task Status Reason (Example)
... businessStatus Σ 0..1 CodeableConcept E.g. "Specimen collected", "IV prepped"
Binding: Task Business Status (Example)
... intent Σ 1..1 code unknown | proposal | plan | order | original-order | reflex-order | filler-order | instance-order | option
Binding: Task Intent (Required)
... priority 0..1 code routine | urgent | asap | stat
Binding: RequestPriority (Required)
... doNotPerform ?!Σ 0..1 boolean True if Task is prohibiting action
... code ΣC 0..1 CodeableConcept Task Type
Binding: Task Codes (Extensible)
... description Σ 0..1 markdown Human-readable explanation of task
... focus ΣC 0..1 Reference(Any) What task is acting on
... for Σ 0..1 Reference(Any) Beneficiary of the Task
... encounter Σ 0..1 Reference(Encounter) Healthcare event during which this task originated
... requestedPeriod Σ 0..1 Period When the task should be performed
... executionPeriod Σ 0..1 Period Start and end time of execution
... authoredOn 0..1 dateTime Task Creation Date
... lastModified Σ 0..1 dateTime Task Last Modified Date
... requester Σ 0..1 Reference(Device | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson) Who is asking for task to be done
... requestedPerformer 0..* CodeableReference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson) Who should perform the Task
Binding: Procedure Performer Role Codes (Preferred)

... owner Σ 0..1 Reference(Practitioner | PractitionerRole | Organization | CareTeam | Patient | RelatedPerson) Responsible individual
... performer Σ 0..* BackboneElement Who or what performed the task

.... function Σ 0..1 CodeableConcept Type of performance
Binding: Task Performer Function Code (Example)
.... actor Σ 1..1 Reference(Practitioner | Device | Organization | PractitionerRole | Organization | CareTeam | Patient | RelatedPerson) Who performed the task
... location Σ 0..1 Reference(Location) Where task occurs
... reason 0..* CodeableReference(Any) Why task is needed
Binding: Task Reason (Example)

... insurance 0..* Reference(Coverage | ClaimResponse) Associated insurance coverage

... note 0..* Annotation Comments made about the task

... relevantHistory 0..* Reference(Provenance) Key events in history of the Task

... restriction C 0..1 BackboneElement Constraints on fulfillment tasks
.... repetitions 0..1 positiveInt How many times to repeat
.... period 0..1 Period When fulfillment is sought
.... recipient 0..* Reference(Patient | Practitioner | PractitionerRole | RelatedPerson | Group | Organization) For whom is fulfillment sought?

... input 0..* BackboneElement Information used to perform task

.... type 1..1 CodeableConcept Label for the input
Binding: Task Input/Output Parameter Type (Example)
.... value[x] 1..1 * Content to use in performing the task
... output 0..* BackboneElement Information produced as part of task

.... type 1..1 CodeableConcept Label for output
Binding: Task Input/Output Parameter Type (Example)
.... value[x] 1..1 * Result of output

doco Documentation for this format icon

See the Extensions for this resource

 

Additional definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions, the spreadsheet version & the dependency analysis

12.1.5.1 Terminology Bindings

Path ValueSet Type Documentation
Task.status TaskStatus Required

The current status of the task.
Task.statusReason TaskStatusReason Example

The current status reason of the task.
Task.businessStatus TaskBusinessStatus Example

The business-specific nuances of the state of the task.
Task.intent TaskIntent Required

Distinguishes whether the task is a proposal, plan or full order.
Task.priority RequestPriority Required

Identifies the level of importance to be assigned to actioning the request.
Task.code TaskCode (a valid code from Task Codes) Extensible

Codes indicating the type of action that is expected to be performed
Task.requestedPerformer ProcedurePerformerRoleCodes Preferred

This example value set defines the set of codes that can be used to indicate a role of a procedure performer.
Task.performer.function TaskPerformerFunctionCode Example

The performer of the task.
Task.reason TaskReason Example

The reason for the task being performed.
Task.input.type TaskInputOutputParameterType (a valid code from Task Input/Output Parameter Type) Example

The input and output types for the task.
Task.output.type TaskInputOutputParameterType (a valid code from Task Input/Output Parameter Type) Example

The input and output types for the task.

12.1.5.2 Constraints

UniqueKeyLevelLocationDescriptionExpression
img tsk-0Rule (base)Last modified date must be greater than or equal to authored-on date.lastModified.exists().not() or authoredOn.exists().not() or lastModified >= authoredOn
img tsk-1Rule (base)Task.restriction is only allowed if the Task is seeking fulfillment and a focus is specified.restriction.exists() implies code.coding.where(code='fulfill' and system='http://hl7.org/fhir/CodeSystem/task-code').exists() and focus.exists()

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

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

12.1.8 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

Note to Implementers: 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.

Feedback here icon.

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

12.1.10 Search Parameters

Search parameters for this resource. See also the full list of search parameters for this resource, and check the Extensions registry for search parameters on extensions related to this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

Name Type Description Expression In Common
actor reference Search by specific performer. Task.performer.actor
(Practitioner, Organization, CareTeam, Device, Patient, PractitionerRole, RelatedPerson)
authored-on date Search by creation date Task.authoredOn
based-on reference Search by requests this task is based on Task.basedOn
(Any)
business-status token Search by business status Task.businessStatus
code token Search by task code Task.code 21 Resources
encounter reference Search by encounter Task.encounter
(Encounter)		 29 Resources
focus reference Search by task focus Task.focus
(Any)
group-identifier token Search by group identifier Task.groupIdentifier
identifier token Search for a task instance by its business identifier Task.identifier 65 Resources
input reference Search by task input Task.input.value.ofType(Reference)
intent token Search by task intent Task.intent
modified date Search by last modification date Task.lastModified
output reference Search by task output Task.output.value.ofType(Reference)
owner reference Search by task owner Task.owner
(Practitioner, Organization, CareTeam, Patient, PractitionerRole, RelatedPerson)
part-of reference Search by task this task is part of Task.partOf
(Task)
patient reference Search by patient Task.for.where(resolve() is Patient)
(Patient)		 65 Resources
performer token Search by recommended type of performer (e.g., Requester, Performer, Scheduler). Task.requestedPerformer.concept
period date Search by period Task is/was underway Task.executionPeriod
priority token Search by task priority Task.priority
requestedperformer-reference reference Search by specific requested performer. Task.requestedPerformer.reference
requester reference Search by task requester Task.requester
(Practitioner, Organization, Device, Patient, PractitionerRole, RelatedPerson)
status token Search by task status Task.status
subject reference Search by subject Task.for
(Any)