Release 4B
WorkflowThis page is part of the FHIR Specification (v4.3.0: R4B - STU). This is a downloaded version of the specification. For a full list of available versions, see the Directory of published versions 
| Orders and Observations Work Group | Maturity Level: 2 | Trial Use | Security Category: Not Classified | Compartments: Not linked to any defined compartments |
A task to be performed.
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.
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.
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.
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, 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.
Note: Currently, task pre-requisites can be represented using Task's `description` element or the RequestGroup 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
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.
As stated above, 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.
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.
This resource is referenced by CarePlan, ImagingStudy, PaymentReconciliation and itself.
This resource does not implement any patterns.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
  Task | TU | DomainResource | A task to be performed + Rule: Last modified date must be greater than or equal to authored-on date. 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 | + TaskStatus (Required) |
| statusReason | Σ | 0..1 | CodeableConcept | Reason for current status TaskStatusReason (Example) |
| businessStatus | Σ | 0..1 | CodeableConcept | E.g. "Specimen collected", "IV prepped" TaskBusinessStatus (Example) |
| intent | Σ | 1..1 | code | unknown | proposal | plan | order | original-order | reflex-order | filler-order | instance-order | option TaskIntent (Required) |
| priority | 0..1 | code | routine | urgent | asap | stat RequestPriority (Required) | |
| code | Σ | 0..1 | CodeableConcept | Task Type Task Codes (Example) |
| description | Σ | 0..1 | string | Human-readable explanation of task |
| focus | Σ | 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 |
| executionPeriod | Σ | 0..1 | Period | Start and end time of execution |
| authoredOn | I | 0..1 | dateTime | Task Creation Date |
| lastModified | ΣI | 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 |
| performerType | 0..* | CodeableConcept | Requested performer Procedure Performer Role Codes (Preferred) | |
| owner | Σ | 0..1 | Reference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson) | Responsible individual |
| location | Σ | 0..1 | Reference(Location) | Where task occurs |
| reasonCode | 0..1 | CodeableConcept | Why task is needed TaskReason (Example) | |
| reasonReference | 0..1 | Reference(Any) | Why task is needed | |
| 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 | 0..1 | BackboneElement | Constraints on fulfillment tasks | |
 repetitions | 0..1 | positiveInt | How many times to repeat | |
| period | 0..1 | Period | When fulfillment 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 TaskInputParameterType (Example) | |
  value[x] | 1..1 | Content to use in performing the task | ||
 valueBase64Binary | base64Binary | |||
| valueBoolean | boolean | |||
| valueCanonical | canonical() | |||
| valueCode | code | |||
| valueDate | date | |||
| valueDateTime | dateTime | |||
| valueDecimal | decimal | |||
| valueId | id | |||
| valueInstant | instant | |||
| valueInteger | integer | |||
| valueMarkdown | markdown | |||
| valueOid | oid | |||
| valuePositiveInt | positiveInt | |||
| valueString | string | |||
| valueTime | time | |||
| valueUnsignedInt | unsignedInt | |||
| valueUri | uri | |||
| valueUrl | url | |||
| valueUuid | uuid | |||
| valueAddress | Address | |||
| valueAge | Age | |||
| valueAnnotation | Annotation | |||
| valueAttachment | Attachment | |||
| valueCodeableConcept | CodeableConcept | |||
| valueCoding | Coding | |||
| valueContactPoint | ContactPoint | |||
| valueCount | Count | |||
| valueDistance | Distance | |||
| valueDuration | Duration | |||
| valueHumanName | HumanName | |||
| valueIdentifier | Identifier | |||
| valueMoney | Money | |||
| valuePeriod | Period | |||
| valueQuantity | Quantity | |||
| valueRange | Range | |||
| valueRatio | Ratio | |||
| valueReference | Reference() | |||
| valueSampledData | SampledData | |||
| valueSignature | Signature | |||
| valueTiming | Timing | |||
| valueContactDetail | ContactDetail | |||
| valueContributor | Contributor | |||
| valueDataRequirement | DataRequirement | |||
| valueExpression | Expression | |||
| valueParameterDefinition | ParameterDefinition | |||
| valueRelatedArtifact | RelatedArtifact | |||
| valueTriggerDefinition | TriggerDefinition | |||
| valueUsageContext | UsageContext | |||
| valueDosage | Dosage | |||
| valueMeta | Meta | |||
| output | 0..* | BackboneElement | Information produced as part of task | |
| type | 1..1 | CodeableConcept | Label for output TaskOutputParameterType (Example) | |
| value[x] | 1..1 | Result of output | ||
| valueBase64Binary | base64Binary | |||
| valueBoolean | boolean | |||
| valueCanonical | canonical() | |||
| valueCode | code | |||
| valueDate | date | |||
| valueDateTime | dateTime | |||
| valueDecimal | decimal | |||
| valueId | id | |||
| valueInstant | instant | |||
| valueInteger | integer | |||
| valueMarkdown | markdown | |||
| valueOid | oid | |||
| valuePositiveInt | positiveInt | |||
| valueString | string | |||
| valueTime | time | |||
| valueUnsignedInt | unsignedInt | |||
| valueUri | uri | |||
| valueUrl | url | |||
| valueUuid | uuid | |||
| valueAddress | Address | |||
| valueAge | Age | |||
| valueAnnotation | Annotation | |||
| valueAttachment | Attachment | |||
| valueCodeableConcept | CodeableConcept | |||
| valueCoding | Coding | |||
| valueContactPoint | ContactPoint | |||
| valueCount | Count | |||
| valueDistance | Distance | |||
| valueDuration | Duration | |||
| valueHumanName | HumanName | |||
| valueIdentifier | Identifier | |||
| valueMoney | Money | |||
| valuePeriod | Period | |||
| valueQuantity | Quantity | |||
| valueRange | Range | |||
| valueRatio | Ratio | |||
| valueReference | Reference() | |||
| valueSampledData | SampledData | |||
| valueSignature | Signature | |||
| valueTiming | Timing | |||
| valueContactDetail | ContactDetail | |||
| valueContributor | Contributor | |||
| valueDataRequirement | DataRequirement | |||
| valueExpression | Expression | |||
| valueParameterDefinition | ParameterDefinition | |||
| valueRelatedArtifact | RelatedArtifact | |||
| valueTriggerDefinition | TriggerDefinition | |||
| valueUsageContext | UsageContext | |||
| valueDosage | Dosage | |||
| valueMeta | Meta | |||
| Documentation for this format | ||||
See the Profiles & Extensions and the alternate definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions & the dependency analysis
| Path | Definition | Type | Reference |
|---|---|---|---|
| Task.status | Required | TaskStatus | |
| Task.statusReason | Example | ?? | |
| Task.businessStatus | Example | ?? | |
| Task.intent | Required | TaskIntent | |
| Task.priority | Required | RequestPriority | |
| Task.code | Example | TaskCode | |
| Task.performerType | Preferred | ProcedurePerformerRoleCodes | |
| Task.reasonCode | Example | ?? | |
| Task.input.type | Example | ?? | |
| Task.output.type | Example | ?? |
| id | Level | Location | Description | Expression |
| inv-1 | Rule | (base) | Last modified date must be greater than or equal to authored-on date. | lastModified.exists().not() or authoredOn.exists().not() or lastModified >= authoredOn |
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.
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").
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.
Search parameters for 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 |
| 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 | |
| encounter | reference | Search by encounter | Task.encounter (Encounter) | |
| 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 | |
| intent | token | Search by task intent | Task.intent | |
| modified | date | Search by last modification date | Task.lastModified | |
| owner | reference | Search by task owner | Task.owner (Practitioner, Organization, CareTeam, Device, Patient, HealthcareService, 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) | |
| performer | token | Search by recommended type of performer (e.g., Requester, Performer, Scheduler). | Task.performerType | |
| period | date | Search by period Task is/was underway | Task.executionPeriod | |
| priority | token | Search by task priority | Task.priority | |
| 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) |
FHIR ®© HL7.org 2011+. FHIR Release 4B (v4.3.0) hl7.fhir.r4b.core#4.3.0 generated on Sat, May 28, 2022 12:57+1000.
Links: Search |
Version History |
Table of Contents |
QA Page |
Compare to R4 |
|
Propose a change
0..1