This page is part of the Clinical Order Workflows (v1.0.0-ballot: STU 1 Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. No current official version has been published yet. For a full list of available versions, see the Directory of published versions
Page standards status: Informative |
The Task resource is a FHIR resource dedicated to the management of workflows; Except in very simple workflows, it is expectable that the Task resource will be used in most data exchanges when there are workflow needs. Designers and implementers of systems implementing workflows using FHIR resources are highly recommended to review the Task resource pages.
This ImplementationGuide introduces two specific types of Task that are important for the execution of workflows:
Some of the elements that support the key purposes of the Task resource:
Task.status
The Task status represents the status of the activity that is being performed. To support system interoperability, the status
is limited to a set of values.
Task.businessStatus
One of the core aspects in FHIR workflow is that FHIR distinguishes status of authorization and status of execution. While it is common to consider concepts like "status of the order", in FHIR the status of the order is simply whether an authorization is draft, active, not active, and completed.
The Task resource and specifically Task.businessStatus
is used to track the actual execution, assigning a code for the status.
Task.focus
Tasks can be used for tracking and coordinating the execution of requests. Task.focus
indicates which request is being acted upon by the Task and its derivatives, inputs and outputs.
Task.input
is used to get the relevant Data for the performer to execute the Request. Examples:
Specimen
ResourceQuestionnaireResponse
Resource (for example ask at Order Entry Questions)Task.output
is used to get - if and when available - the output of the Request from the Filler to the Placer. Examples of resources that are typical outputs are:
DiagnosticReport
Questionaires
ImageStudy
The Task resource can be used to coordinate several requests, when they are grouped but not orchestrated (i.e. they are part of the same group, but are not interdependent).
In future releases of FHIR, Task.focus
is planned to expand to 0..* in support of the cases where there is a need to coordinate several requests. For supporting this in R4 and R5, implementers can use a built-in extension mechanism that "imports" an element as an extension. In this case, the task.focus element is imported as an additional extension on Task, thus allowing task.focus to effectively point to several requests.
Profile: GroupCoordinationTask
Parent: Task
* extension contains http://hl7.org/fhir/4.0/StructureDefinition/extension-Task.focus named focus 0..* MS
See the example of grouped dispense.
Implementers are invited to provide feedback on the use of Task.focus, and point to input on the coordination of several requests.
Note to balloters: Throughout this implementation guide there are references to a "performer of a Task". In FHIR R4, the Task resource only has an owner
element, however FHIR R5 has also added a performer
element. HL7 invites balloters to provide input on whether the owner
element is sufficient to represent the performer concept, or if they may be different in some use cases.