FHIR CI-Build

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

Orders and Observations icon Work GroupMaturity Level: 3 Trial UseSecurity Category: Not Classified Compartments: Patient

Detailed Descriptions for the elements in the Task resource.

Task
Element IdTask
Definition

A task to be performed.

Short DisplayA task to be performed
Cardinality0..*
TypeDomainResource
Summaryfalse
Invariants
Defined on this element
tsk-1Rule 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()
inv-1Rule Last modified date must be greater than or equal to authored-on date.lastModified.exists().not() or authoredOn.exists().not() or lastModified >= authoredOn
Task.identifier
Element IdTask.identifier
Definition

The business identifier for this task.

Short DisplayTask Instance Identifier
NoteThis is a business identifier, not a resource identifier (see discussion)
Cardinality0..*
TypeIdentifier
Summaryfalse
Task.instantiatesCanonical
Element IdTask.instantiatesCanonical
Definition

The URL pointing to a FHIR-defined protocol, guideline, orderset or other definition that is adhered to in whole or in part by this Task.

Short DisplayFormal definition of task
Cardinality0..1
Typecanonical(ActivityDefinition)
Requirements

Enables a formal definition of how the task is to be performed, enabling automation.

Summarytrue
Task.instantiatesUri
Element IdTask.instantiatesUri
Definition

The URL pointing to an externally maintained protocol, guideline, orderset or other definition that is adhered to in whole or in part by this Task.

Short DisplayFormal definition of task
Cardinality0..1
Typeuri
Requirements

Enables a formal definition of how the task is to be performed (e.g. using BPMN, BPEL, XPDL or other formal notation to be associated with a task), enabling automation.

Summarytrue
Task.basedOn
Element IdTask.basedOn
Definition

BasedOn refers to a higher-level authorization that triggered the creation of the task. It references a "request" resource such as a ServiceRequest, MedicationRequest, CarePlan, etc. which is distinct from the "request" resource the task is seeking to fulfill. This latter resource is referenced by focus. For example, based on a CarePlan (= basedOn), a task is created to fulfill a ServiceRequest ( = focus ) to collect a specimen from a patient.

Short DisplayRequest fulfilled by this task
Cardinality0..*
TypeReference(Any)
Summarytrue
Comments

Task.basedOn is never the same as Task.focus. Task.basedOn will typically not be present for 'please fulfill' Tasks as a distinct authorization is rarely needed to request fulfillment. If the Task is seeking fulfillment of an order, the order to be fulfilled is always communicated using focus, never basedOn. However, authorization may be needed to perform other types of Task actions. As an example of when both would be present, a Task seeking suspension of a prescription might have a Task.basedOn pointing to the ServiceRequest ordering surgery (which is the driver for suspending the MedicationRequest - which would be the Task.focus).

Task.groupIdentifier
Element IdTask.groupIdentifier
Definition

A shared identifier common to multiple independent Task and Request instances that were activated/authorized more or less simultaneously by a single author. The presence of the same identifier on each request ties those requests together and may have business ramifications in terms of reporting of results, billing, etc. E.g. a requisition number shared by a set of lab tests ordered together, or a prescription number shared by all meds ordered at one time.

Short DisplayRequisition or grouper id
Cardinality0..1
TypeIdentifier
Requirements

Billing and/or reporting can be linked to whether multiple requests were created as a single unit.

Summarytrue
Task.partOf
Element IdTask.partOf
Definition

Task that this particular task is part of.

Short DisplayComposite task
Cardinality0..*
TypeReference(Task)
HierarchyThis reference is part of a strict Hierarchy
Requirements

Allows tasks to be broken down into sub-steps (and this division can occur independent of the original task).

Summarytrue
Comments

This should usually be 0..1.

Task.status
Element IdTask.status
Definition

The current status of the task.

Short Displaydraft | requested | received | accepted | +
Cardinality1..1
Terminology BindingTask Status (Required)
Typecode
Is Modifiertrue (Reason: This element is labeled as a modifier because it is a status element that contains status entered-in-error which means that the resource should not be treated as valid)
Requirements

These states enable coordination of task status with off-the-shelf workflow solutions that support automation of tasks.

Summarytrue
Task.statusReason
Element IdTask.statusReason
Definition

An explanation as to why this task is held, failed, was refused, etc.

Short DisplayReason for current status
Cardinality0..1
Terminology BindingTask Status Reason (Example)
TypeCodeableReference
Summarytrue
Comments

This applies to the current status. Look at the history of the task to see reasons for past statuses.

Task.businessStatus
Element IdTask.businessStatus
Definition

Contains business-specific nuances of the business state.

Short DisplayE.g. "Specimen collected", "IV prepped"
Cardinality0..1
Terminology BindingTaskBusinessStatus:
TypeCodeableConcept
Requirements

There's often a need to track substates of a task - this is often variable by specific workflow implementation.

Summarytrue
Task.intent
Element IdTask.intent
Definition

Indicates the "level" of actionability associated with the Task, i.e. i+R[9]Cs this a proposed task, a planned task, an actionable task, etc.

Short Displayunknown | proposal | plan | order | original-order | reflex-order | filler-order | instance-order | option
Cardinality1..1
Terminology BindingTask Intent (Required)
Typecode
Summarytrue
Comments

This element is immutable. Proposed tasks, planned tasks, etc. must be distinct instances.

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

Task.priority
Element IdTask.priority
Definition

Indicates how quickly the Task should be addressed with respect to other requests.

Short Displayroutine | urgent | asap | stat
Cardinality0..1
Terminology BindingRequestPriority (Required)
Typecode
Meaning if MissingIf missing, this task should be performed with normal priority
Requirements

Used to identify the service level expected while performing a task.

Summaryfalse
Task.doNotPerform
Element IdTask.doNotPerform
Definition

If true indicates that the Task is asking for the specified action to not occur.

Short DisplayTrue if Task is prohibiting action
Cardinality0..1
Typeboolean
Is Modifiertrue (Reason: If true, this element negates the Task. For example, instead of a request to perform a task, it is a request _not_ to perform a task.)
Summarytrue
Comments

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 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').

doNotPerform should ONLY be used with Tasks that are tightly bounded in time or process phase. E.g. 'Do not fulfill the midnight dose of medication X tonight due to the early morning scheduled procedure, where the nurse could reasonably check off 'Med X not given at midnight as instructed'. Similarly, a decision support proposal that a patient should not be given a standard intake questionnaire (because the patient is cognitively impaired) would be marked as 'complete' or 'rejected' when the clinician preps the CarePlan or order set after reviewing the decision support results. If there is a need to create a standing order to not do something that can't be satisfied by a single 'non-action', but rather an ongoing refusal to perform the function, MedicationRequest, ServiceRequest or some other form of authorization should be used.

Task.code
Element IdTask.code
Definition

A name or code (or both) briefly describing what the task involves.

Short DisplayTask Type
Cardinality0..1
Terminology BindingTask Codes (Example)
TypeCodeableConcept
Summarytrue
Comments

The title (eg "My Tasks", "Outstanding Tasks for Patient X") should go into the code.

Invariants
Affect this element
tsk-1Rule 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()
Task.description
Element IdTask.description
Definition

A free-text description of what is to be performed.

Short DisplayHuman-readable explanation of task
Cardinality0..1
Typestring
Summarytrue
Task.focus
Element IdTask.focus
Definition

The request being fulfilled or the resource being manipulated (changed, suspended, etc.) by this task.

Short DisplayWhat task is acting on
Cardinality0..1
TypeReference(Any)
Requirements

Used to identify the thing to be done.

Summarytrue
Comments

If multiple resources need to be manipulated, use sub-tasks. (This ensures that status can be tracked independently for each referenced resource.).

Invariants
Affect this element
tsk-1Rule 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()
Task.for
Element IdTask.for
Definition

The entity who benefits from the performance of the service specified in the task (e.g., the patient).

Short DisplayBeneficiary of the Task
Cardinality0..1
TypeReference(Any)
Requirements

Used to track tasks outstanding for a beneficiary. Do not use to track the task owner or creator (see owner and creator respectively). This can also affect access control.

Alternate NamesPatient
Summarytrue
Task.encounter
Element IdTask.encounter
Definition

The healthcare event (e.g. a patient and healthcare provider interaction) during which this task was created.

Short DisplayHealthcare event during which this task originated
Cardinality0..1
TypeReference(Encounter)
Requirements

For some tasks it may be important to know the link between the encounter the task originated within.

Summarytrue
Task.requestedPeriod
Element IdTask.requestedPeriod
Definition

Indicates the start and/or end of the period of time when completion of the task is desired to take place.

Short DisplayWhen the task should be performed
Cardinality0..1
TypePeriod
Summarytrue
Comments

This is typically used when the Task is not seeking fulfillment of a focus Request, as in that case the period would be specified on the Request and/or in the Task.restriction.period. Instead, it is used for stand-alone tasks.

Task.executionPeriod
Element IdTask.executionPeriod
Definition

Identifies the time action was first taken against the task (start) and/or the time final action was taken against the task prior to marking it as completed (end).

Short DisplayStart and end time of execution
Cardinality0..1
TypePeriod
Summarytrue
Task.authoredOn
Element IdTask.authoredOn
Definition

The date and time this task was created.

Short DisplayTask Creation Date
Cardinality0..1
TypedateTime
Requirements

Most often used along with lastUpdated to track duration of task to supporting monitoring and management.

Alternate NamesCreated Date
Summaryfalse
Invariants
Affect this element
inv-1Rule Last modified date must be greater than or equal to authored-on date.lastModified.exists().not() or authoredOn.exists().not() or lastModified >= authoredOn
Task.lastModified
Element IdTask.lastModified
Definition

The date and time of last modification to this task.

Short DisplayTask Last Modified Date
Cardinality0..1
TypedateTime
Requirements

Used along with history to track task activity and time in a particular task state. This enables monitoring and management.

Alternate NamesUpdate Date
Summarytrue
Invariants
Affect this element
inv-1Rule Last modified date must be greater than or equal to authored-on date.lastModified.exists().not() or authoredOn.exists().not() or lastModified >= authoredOn
Task.requester
Element IdTask.requester
Definition

The creator of the task.

Short DisplayWho is asking for task to be done
Cardinality0..1
TypeReference(Device | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson)
Requirements

Identifies who created this task. May be used by access control mechanisms (e.g., to ensure that only the creator can cancel a task).

Summarytrue
Task.requestedPerformer
Element IdTask.requestedPerformer
Definition

The kind of participant or specific participant that should perform the task.

Short DisplayWho should perform Task
Cardinality0..*
Terminology BindingProcedure Performer Role Codes (Preferred)
TypeCodeableReference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson)
Requirements

Use to distinguish tasks on different activity queues.

Summaryfalse
Task.owner
Element IdTask.owner
Definition

Party responsible for managing task execution.

Short DisplayResponsible individual
Cardinality0..1
TypeReference(Practitioner | PractitionerRole | Organization | CareTeam | Patient | RelatedPerson)
Requirements

Identifies who is expected to perform this task.

Alternate NamesPerformer; Executer
Summarytrue
Comments

Tasks may be created with an owner not yet identified.

Task.performer
Element IdTask.performer
Definition

The entity who performed the requested task.

Short DisplayWho or what performed the task
Cardinality0..*
Summarytrue
Task.performer.function
Element IdTask.performer.function
Definition

A code or description of the performer of the task.

Short DisplayType of performance
Cardinality0..1
Terminology BindingTaskPerformerFunctionCode:
TypeCodeableConcept
Summarytrue
Task.performer.actor
Element IdTask.performer.actor
Definition

The actor or entity who performed the task.

Short DisplayWho performed the task
Cardinality1..1
TypeReference(Practitioner | PractitionerRole | Organization | CareTeam | Patient | RelatedPerson)
Summarytrue
Task.location
Element IdTask.location
Definition

Principal physical location where this task is performed.

Short DisplayWhere task occurs
Cardinality0..1
TypeReference(Location)
Requirements

Ties the event to where the records are likely kept and provides context around the event occurrence (e.g. if it occurred inside or outside a dedicated healthcare setting).

Summarytrue
Comments

This should only be specified when the Task to be/being performed happens or is expected to happen primarily within the bounds of a single Location. Other locations (e.g. source, destination, etc.) would either be reflected on the 'basedOn' Request or be conveyed as distinct Task.input values.

Task.reason
Element IdTask.reason
Definition

A description, code, or reference indicating why this task needs to be performed.

Short DisplayWhy task is needed
Cardinality0..*
Terminology BindingTaskReason:
TypeCodeableReference
Summaryfalse
Comments

This will typically not be present for Tasks with a code of 'please fulfill' as, for those, the reason for action is conveyed on the Request pointed to by Task.focus. Some types of tasks will not need a 'reason'. E.g. a request to discharge a patient can be inferred to be 'because the patient is ready' and this would not need a reason to be stated on the Task.

Task.insurance
Element IdTask.insurance
Definition

Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be relevant to the Task.

Short DisplayAssociated insurance coverage
Cardinality0..*
TypeReference(Coverage | ClaimResponse)
Summaryfalse
Task.note
Element IdTask.note
Definition

Free-text information captured about the task as it progresses.

Short DisplayComments made about the task
Cardinality0..*
TypeAnnotation
Summaryfalse
Task.relevantHistory
Element IdTask.relevantHistory
Definition

Links to Provenance records for past versions of this Task that identify key state transitions or updates that are likely to be relevant to a user looking at the current version of the task.

Short DisplayKey events in history of the Task
Cardinality0..*
TypeReference(Provenance)
Alternate NamesStatus History
Summaryfalse
Comments

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.

Task.restriction
Element IdTask.restriction
Definition

If the Task.focus is a request resource and the task is seeking fulfillment (i.e. is asking for the request to be actioned), this element identifies any limitations on what parts of the referenced request should be actioned.

Short DisplayConstraints on fulfillment tasks
Cardinality0..1
Requirements

Sometimes when fulfillment is sought, you don't want full fulfillment.

Summaryfalse
Comments

Task.restriction can only be present if the Task is seeking fulfillment of another Request resource, and the restriction identifies what subset of the authorization conveyed by the request is supposed to be fulfilled by this Task. A possible example could be a standing order (the request) covering a significant time period and/or individuals, while the Task seeks fulfillment for only a subset of that time-period and a single individual.

Invariants
Affect this element
tsk-1Rule 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()
Task.restriction.repetitions
Element IdTask.restriction.repetitions
Definition

Indicates the number of times the requested action should occur.

Short DisplayHow many times to repeat
Cardinality0..1
TypepositiveInt
Requirements

E.g. order that requests monthly lab tests, fulfillment is sought for 1.

Summaryfalse
Task.restriction.period
Element IdTask.restriction.period
Definition

The time-period for which fulfillment is sought. This must fall within the overall time period authorized in the referenced request. E.g. ServiceRequest.occurance[x].

Short DisplayWhen fulfillment is sought
Cardinality0..1
TypePeriod
Requirements

E.g. order that authorizes 1 year's services. Fulfillment is sought for next 3 months.

Summaryfalse
Comments

This is distinct from Task.executionPeriod. ExecutionPeriod indicates when the task needs to be initiated, while Task.restriction.period specifies the subset of the overall authorization that this period covers. For example, a MedicationRequest with an overall effective period of 1 year might have a Task whose restriction.period is 2 months (i.e. satisfy 2 months of medication therapy), while the execution period might be 'between now and 5 days from now' - i.e. If you say yes to this, then you're agreeing to supply medication for that 2 month period within the next 5 days.

Note that period.high is the due date representing the time by which the task should be completed.

Task.restriction.recipient
Element IdTask.restriction.recipient
Definition

For requests that are targeted to more than one potential recipient/target, to identify who is fulfillment is sought for.

Short DisplayFor whom is fulfillment sought?
Cardinality0..*
TypeReference(Patient | Practitioner | PractitionerRole | RelatedPerson | Group | Organization)
Summaryfalse
Task.input
Element IdTask.input
Definition

Additional information that may be needed in the execution of the task.

Short DisplayInformation used to perform task
Cardinality0..*
Requirements

Resources and data used to perform the task. This data is used in the business logic of task execution, and is stored separately because it varies between workflows.

Alternate NamesSupporting Information
Summaryfalse
Task.input.type
Element IdTask.input.type
Definition

A code or description indicating how the input is intended to be used as part of the task execution.

Short DisplayLabel for the input
Cardinality1..1
Terminology BindingTaskInputParameterType:
TypeCodeableConcept
Requirements

Inputs are named to enable task automation to bind data and pass it from one task to the next.

Alternate NamesName
Summaryfalse
Comments

If referencing a BPMN workflow or Protocol, the "system" is the URL for the workflow definition and the code is the "name" of the required input.

Task.input.value[x]
Element IdTask.input.value[x]
Definition

The value of the input parameter as a basic type.

Short DisplayContent to use in performing the task
Cardinality1..1
Type*
[x] NoteSee Choice of Datatypes for further information about how to use [x]
Summaryfalse
Task.output
Element IdTask.output
Definition

Outputs produced by the Task.

Short DisplayInformation produced as part of task
Cardinality0..*
Requirements

Resources and data produced during the execution the task. This data is generated by the business logic of task execution, and is stored separately because it varies between workflows.

Summaryfalse
Task.output.type
Element IdTask.output.type
Definition

The name of the Output parameter.

Short DisplayLabel for output
Cardinality1..1
Terminology BindingTaskOutputParameterType:
TypeCodeableConcept
Requirements

Outputs are named to enable task automation to bind data and pass it from one task to the next.

Alternate NamesName
Summaryfalse
Task.output.value[x]
Element IdTask.output.value[x]
Definition

The value of the Output parameter as a basic type.

Short DisplayResult of output
Cardinality1..1
Type*
[x] NoteSee Choice of Datatypes for further information about how to use [x]
Requirements

Task outputs can take any form.

Summaryfalse