5.33 Resource Task - Content

5.33.1 Scope and Usage

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

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

5.33.2 Background and Context

5.33.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 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 and 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, creators, other agents (e.g. workflow managers) can thus be ready to initiate the next steps in a complex workflow.

5.33.2.2 Tasks State Machine

Tasks start in a Created 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 (Created, Reading, 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.

5.33.2.3 Using Tasks with operations

The Task resource defines several operations to enable rich control over the task execution environment. A server managing task resources may allow unfettered read access to all tasks that it maintains, but restrict write access to the task resources to itself in order to exert control over the task state machine. Instead, it might offer operations on tasks that enable strictly controlled write operations following commonly accepted business rules for task management. For example, only tasks that are in the "In Process" state might be allowed to be "Completed" or "Failed". Use or support of these operations is not essential in simple workflow environments where task activity needs little management.

There is no distinct operation for creating a new task because the FHIR RESTful API already distinguishes between the create and update operations.

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.

5.33.3 Boundaries and Relationships

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 as the subject of the task.

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 transer 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 actitivity 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.

• Structure
• UML
• XML
• JSON
• All

Structure

Name	Flags	Card.	Type	Description & Constraints
Task	I		DomainResource	A task to be performed A Failure reason may be present only when a task has failed. Last modified date must be greater than or equal to created date.
identifier		0..1	Identifier	Task Instance Identifier
type	Σ	0..1	CodeableConcept	Task Type
description	Σ	0..1	string	Task Description
performerType		0..*	Coding	requester | dispatcher | scheduler | performer | monitor | manager | acquirer | reviewer TaskPerformerType (Preferred)
priority		0..1	code	low | normal | high TaskPriority (Required)
status	Σ I	1..1	code	draft | requested | received | accepted | + TaskStatus (Required)
failureReason	Σ I	0..1	CodeableConcept	Task Failure Reason
subject		0..1	Reference(Any)	Task Subject
for	Σ	0..1	Reference(Any)	Beneficiary of the Task
definition	Σ	0..1	uri	Task Definition
created	I	1..1	dateTime	Task Creation Date
lastModified	Σ I	1..1	dateTime	Task Last Modified Date
creator		1..1	Reference(Device | Organization | Patient | Practitioner | RelatedPerson)	Task Creator
owner		0..1	Reference(Device | Organization | Patient | Practitioner | RelatedPerson)	Task Owner
parent		0..1	Reference(Task)	Composite task
input		0..*	BackboneElement	Task Input
name		1..1	string	Input Name
value[x]		1..1	*	Input Value
output		0..*	BackboneElement	Task Output
name		1..1	string	Output Name
value[x]		1..1	*	Output Value
Documentation for this format

<Task xmlns="http://hl7.org/fhir"> 
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..1 Identifier Task Instance Identifier --></identifier>
 <type><!-- 0..1 CodeableConcept Task Type --></type>
 <description value="[string]"/><!-- 0..1 Task Description -->
 <performerType><!-- 0..* Coding requester | dispatcher | scheduler | performer | monitor | manager | acquirer | reviewer --></performerType>
 <priority value="[code]"/><!-- 0..1 low | normal | high -->
 <status value="[code]"/><!--  1..1 draft | requested | received | accepted | + -->
 <failureReason><!--  0..1 CodeableConcept Task Failure Reason --></failureReason>
 <subject><!-- 0..1 Reference(Any) Task Subject --></subject>
 <for><!-- 0..1 Reference(Any) Beneficiary of the Task --></for>
 <definition value="[uri]"/><!-- 0..1 Task Definition -->
 <created value="[dateTime]"/><!--  1..1 Task Creation Date -->
 <lastModified value="[dateTime]"/><!--  1..1 Task Last Modified Date -->
 <creator><!-- 1..1 Reference(Device|Organization|Patient|Practitioner|
   RelatedPerson) Task Creator --></creator>
 <owner><!-- 0..1 Reference(Device|Organization|Patient|Practitioner|
   RelatedPerson) Task Owner --></owner>
 <parent><!-- 0..1 Reference(Task) Composite task --></parent>
 <input>  <!-- 0..* Task Input -->
  <name value="[string]"/><!-- 1..1 Input Name -->
  <value[x]><!-- 1..1 * Input Value --></value[x]>
 </input>
 <output>  <!-- 0..* Task Output -->
  <name value="[string]"/><!-- 1..1 Output Name -->
  <value[x]><!-- 1..1 * Output Value --></value[x]>
 </output>
</Task>

{
  "resourceType" : "Task",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : { Identifier }, // Task Instance Identifier
  "type" : { CodeableConcept }, // Task Type
  "description" : "<string>", // Task Description
  "performerType" : [{ Coding }], // requester | dispatcher | scheduler | performer | monitor | manager | acquirer | reviewer
  "priority" : "<code>", // low | normal | high
  "status" : "<code>", // C? R!  draft | requested | received | accepted | +
  "failureReason" : { CodeableConcept }, // C? Task Failure Reason
  "subject" : { Reference(Any) }, // Task Subject
  "for" : { Reference(Any) }, // Beneficiary of the Task
  "definition" : "<uri>", // Task Definition
  "created" : "<dateTime>", // C? R!  Task Creation Date
  "lastModified" : "<dateTime>", // C? R!  Task Last Modified Date
  "creator" : { Reference(Device|Organization|Patient|Practitioner|
   RelatedPerson) }, // R!  Task Creator
  "owner" : { Reference(Device|Organization|Patient|Practitioner|
   RelatedPerson) }, // Task Owner
  "parent" : { Reference(Task) }, // Composite task
  "input" : [{ // Task Input
    "name" : "<string>", // R!  Input Name
    // value[x]: Input Value. One of these 23:
    "valueInteger" : <integer>
    "valueDecimal" : <decimal>
    "valueDateTime" : "<dateTime>"
    "valueDate" : "<date>"
    "valueInstant" : "<instant>"
    "valueString" : "<string>"
    "valueUri" : "<uri>"
    "valueBoolean" : <boolean>
    "valueCode" : "<code>"
    "valueBase64Binary" : "<base64Binary>"
    "valueCoding" : { Coding }
    "valueCodeableConcept" : { CodeableConcept }
    "valueAttachment" : { Attachment }
    "valueIdentifier" : { Identifier }
    "valueQuantity" : { Quantity }
    "valueRange" : { Range }
    "valuePeriod" : { Period }
    "valueRatio" : { Ratio }
    "valueHumanName" : { HumanName }
    "valueAddress" : { Address }
    "valueContactPoint" : { ContactPoint }
    "valueSchedule" : { Schedule }
    "valueReference" : { Reference }
  }],
  "output" : [{ // Task Output
    "name" : "<string>", // R!  Output Name
    // value[x]: Output Value. One of these 23:
    "valueInteger" : <integer>
    "valueDecimal" : <decimal>
    "valueDateTime" : "<dateTime>"
    "valueDate" : "<date>"
    "valueInstant" : "<instant>"
    "valueString" : "<string>"
    "valueUri" : "<uri>"
    "valueBoolean" : <boolean>
    "valueCode" : "<code>"
    "valueBase64Binary" : "<base64Binary>"
    "valueCoding" : { Coding }
    "valueCodeableConcept" : { CodeableConcept }
    "valueAttachment" : { Attachment }
    "valueIdentifier" : { Identifier }
    "valueQuantity" : { Quantity }
    "valueRange" : { Range }
    "valuePeriod" : { Period }
    "valueRatio" : { Ratio }
    "valueHumanName" : { HumanName }
    "valueAddress" : { Address }
    "valueContactPoint" : { ContactPoint }
    "valueSchedule" : { Schedule }
    "valueReference" : { Reference }
  }]
}

Structure

Name	Flags	Card.	Type	Description & Constraints
Task	I		DomainResource	A task to be performed A Failure reason may be present only when a task has failed. Last modified date must be greater than or equal to created date.
identifier		0..1	Identifier	Task Instance Identifier
type	Σ	0..1	CodeableConcept	Task Type
description	Σ	0..1	string	Task Description
performerType		0..*	Coding	requester | dispatcher | scheduler | performer | monitor | manager | acquirer | reviewer TaskPerformerType (Preferred)
priority		0..1	code	low | normal | high TaskPriority (Required)
status	Σ I	1..1	code	draft | requested | received | accepted | + TaskStatus (Required)
failureReason	Σ I	0..1	CodeableConcept	Task Failure Reason
subject		0..1	Reference(Any)	Task Subject
for	Σ	0..1	Reference(Any)	Beneficiary of the Task
definition	Σ	0..1	uri	Task Definition
created	I	1..1	dateTime	Task Creation Date
lastModified	Σ I	1..1	dateTime	Task Last Modified Date
creator		1..1	Reference(Device | Organization | Patient | Practitioner | RelatedPerson)	Task Creator
owner		0..1	Reference(Device | Organization | Patient | Practitioner | RelatedPerson)	Task Owner
parent		0..1	Reference(Task)	Composite task
input		0..*	BackboneElement	Task Input
name		1..1	string	Input Name
value[x]		1..1	*	Input Value
output		0..*	BackboneElement	Task Output
name		1..1	string	Output Name
value[x]		1..1	*	Output Value
Documentation for this format

UML Diagram

XML Template

<Task xmlns="http://hl7.org/fhir"> 
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..1 Identifier Task Instance Identifier --></identifier>
 <type><!-- 0..1 CodeableConcept Task Type --></type>
 <description value="[string]"/><!-- 0..1 Task Description -->
 <performerType><!-- 0..* Coding requester | dispatcher | scheduler | performer | monitor | manager | acquirer | reviewer --></performerType>
 <priority value="[code]"/><!-- 0..1 low | normal | high -->
 <status value="[code]"/><!--  1..1 draft | requested | received | accepted | + -->
 <failureReason><!--  0..1 CodeableConcept Task Failure Reason --></failureReason>
 <subject><!-- 0..1 Reference(Any) Task Subject --></subject>
 <for><!-- 0..1 Reference(Any) Beneficiary of the Task --></for>
 <definition value="[uri]"/><!-- 0..1 Task Definition -->
 <created value="[dateTime]"/><!--  1..1 Task Creation Date -->
 <lastModified value="[dateTime]"/><!--  1..1 Task Last Modified Date -->
 <creator><!-- 1..1 Reference(Device|Organization|Patient|Practitioner|
   RelatedPerson) Task Creator --></creator>
 <owner><!-- 0..1 Reference(Device|Organization|Patient|Practitioner|
   RelatedPerson) Task Owner --></owner>
 <parent><!-- 0..1 Reference(Task) Composite task --></parent>
 <input>  <!-- 0..* Task Input -->
  <name value="[string]"/><!-- 1..1 Input Name -->
  <value[x]><!-- 1..1 * Input Value --></value[x]>
 </input>
 <output>  <!-- 0..* Task Output -->
  <name value="[string]"/><!-- 1..1 Output Name -->
  <value[x]><!-- 1..1 * Output Value --></value[x]>
 </output>
</Task>

JSON Template

{
  "resourceType" : "Task",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : { Identifier }, // Task Instance Identifier
  "type" : { CodeableConcept }, // Task Type
  "description" : "<string>", // Task Description
  "performerType" : [{ Coding }], // requester | dispatcher | scheduler | performer | monitor | manager | acquirer | reviewer
  "priority" : "<code>", // low | normal | high
  "status" : "<code>", // C? R!  draft | requested | received | accepted | +
  "failureReason" : { CodeableConcept }, // C? Task Failure Reason
  "subject" : { Reference(Any) }, // Task Subject
  "for" : { Reference(Any) }, // Beneficiary of the Task
  "definition" : "<uri>", // Task Definition
  "created" : "<dateTime>", // C? R!  Task Creation Date
  "lastModified" : "<dateTime>", // C? R!  Task Last Modified Date
  "creator" : { Reference(Device|Organization|Patient|Practitioner|
   RelatedPerson) }, // R!  Task Creator
  "owner" : { Reference(Device|Organization|Patient|Practitioner|
   RelatedPerson) }, // Task Owner
  "parent" : { Reference(Task) }, // Composite task
  "input" : [{ // Task Input
    "name" : "<string>", // R!  Input Name
    // value[x]: Input Value. One of these 23:
    "valueInteger" : <integer>
    "valueDecimal" : <decimal>
    "valueDateTime" : "<dateTime>"
    "valueDate" : "<date>"
    "valueInstant" : "<instant>"
    "valueString" : "<string>"
    "valueUri" : "<uri>"
    "valueBoolean" : <boolean>
    "valueCode" : "<code>"
    "valueBase64Binary" : "<base64Binary>"
    "valueCoding" : { Coding }
    "valueCodeableConcept" : { CodeableConcept }
    "valueAttachment" : { Attachment }
    "valueIdentifier" : { Identifier }
    "valueQuantity" : { Quantity }
    "valueRange" : { Range }
    "valuePeriod" : { Period }
    "valueRatio" : { Ratio }
    "valueHumanName" : { HumanName }
    "valueAddress" : { Address }
    "valueContactPoint" : { ContactPoint }
    "valueSchedule" : { Schedule }
    "valueReference" : { Reference }
  }],
  "output" : [{ // Task Output
    "name" : "<string>", // R!  Output Name
    // value[x]: Output Value. One of these 23:
    "valueInteger" : <integer>
    "valueDecimal" : <decimal>
    "valueDateTime" : "<dateTime>"
    "valueDate" : "<date>"
    "valueInstant" : "<instant>"
    "valueString" : "<string>"
    "valueUri" : "<uri>"
    "valueBoolean" : <boolean>
    "valueCode" : "<code>"
    "valueBase64Binary" : "<base64Binary>"
    "valueCoding" : { Coding }
    "valueCodeableConcept" : { CodeableConcept }
    "valueAttachment" : { Attachment }
    "valueIdentifier" : { Identifier }
    "valueQuantity" : { Quantity }
    "valueRange" : { Range }
    "valuePeriod" : { Period }
    "valueRatio" : { Ratio }
    "valueHumanName" : { HumanName }
    "valueAddress" : { Address }
    "valueContactPoint" : { ContactPoint }
    "valueSchedule" : { Schedule }
    "valueReference" : { Reference }
  }]
}

5.33.5 Processing Tasks

TBD