Release 4 5 Preview #2
This page is part of the FHIR Specification (v4.0.1: R4 - Mixed Normative and STU ). This is the current published version in it's permanent home (it will always be available at this URL). 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

Detailed Descriptions for the elements in the Task resource.

Task
Element Id Task
Definition

A task to be performed.

Cardinality 0..*
Type DomainResource
Invariants
Defined on this element
inv-1 Rule 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 Id Task.identifier
Definition

The business identifier for this task.

Note This is a business identifier, not a resource identifier (see discussion )
Cardinality 0..*
Type Identifier
Task.instantiatesCanonical
Element Id Task.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.

Cardinality 0..1
Type canonical ( ActivityDefinition )
Requirements

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

Summary true
Task.instantiatesUri
Element Id Task.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.

Cardinality 0..1
Type uri
Requirements

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

Summary true
Task.basedOn
Element Id Task.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, ServiceRequest, CarePlan, etc. which is distinct from the "request" resource the task is seeking to fulfill. This latter resource is referenced by FocusOn. For example, based on a ServiceRequest (= BasedOn), a task is created to fulfill a procedureRequest ( = FocusOn ) to collect a specimen from a patient.

Cardinality 0..*
Type Reference ( Any )
Summary true
Task.groupIdentifier
Element Id Task.groupIdentifier
Definition

An identifier that links together multiple tasks and other requests that were created in the same context.

Cardinality 0..1
Type Identifier
Requirements

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

Summary true
Task.partOf
Element Id Task.partOf
Definition

Task that this particular task is part of.

Cardinality 0..*
Type Reference ( Task )
Requirements

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

Summary true
Comments

This should usually be 0..1.

Task.status
Element Id Task.status
Definition

The current status of the task.

Cardinality 1..1
Terminology Binding TaskStatus ( Required )
Type code
Is Modifier true (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.

Summary true
Task.statusReason
Element Id Task.statusReason
Definition

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

Cardinality 0..1
Terminology Binding TaskStatusReason :
Type CodeableConcept
Summary true
Comments

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

Task.businessStatus
Element Id Task.businessStatus
Definition

Contains business-specific nuances of the business state.

Cardinality 0..1
Terminology Binding TaskBusinessStatus :
Type CodeableConcept
Requirements

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

Summary true
Task.intent
Element Id Task.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.

Cardinality 1..1
Terminology Binding TaskIntent ( Required )
Type code
Summary true
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 Id Task.priority
Definition

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

Cardinality 0..1
Terminology Binding Request priority ( Required )
Type code
Meaning if Missing If missing, this task should be performed with normal priority
Requirements

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

Task.code
Element Id Task.code
Definition

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

Cardinality 0..1
Terminology Binding Task Codes ( Example )
Type CodeableConcept
Summary true
Comments

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

Task.description
Element Id Task.description
Definition

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

Cardinality 0..1
Type string
Summary true
Task.focus
Element Id Task.focus
Definition

The request being actioned or the resource being manipulated by this task.

Cardinality 0..1
Type Reference ( Any )
Requirements

Used to identify the thing to be done.

Summary true
Comments

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

Task.for
Element Id Task.for
Definition

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

Cardinality 0..1
Type Reference ( 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 Names Patient
Summary true
Task.encounter
Element Id Task.encounter
Definition

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

Cardinality 0..1
Type Reference ( Encounter )
Requirements

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

Summary true
Task.executionPeriod
Element Id Task.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).

Cardinality 0..1
Type Period
Summary true
Task.authoredOn
Element Id Task.authoredOn
Definition

The date and time this task was created.

Cardinality 0..1
Type dateTime
Requirements

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

Alternate Names Created Date
Invariants
Affect this element
inv-1 Rule 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 Id Task.lastModified
Definition

The date and time of last modification to this task.

Cardinality 0..1
Type dateTime
Requirements

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

Alternate Names Update Date
Summary true
Invariants
Affect this element
inv-1 Rule 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 Id Task.requester
Definition

The creator of the task.

Cardinality 0..1
Type Reference ( Device | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson )
Patterns Reference(Device,Organization,Patient,Practitioner,PractitionerRole,RelatedPerson): Common patterns = Participant
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).

Summary true
Task.performerType
Element Id Task.performerType
Definition

The kind of participant that should perform the task.

Cardinality 0..*
Terminology Binding Procedure Performer Role Codes ( Preferred )
Type CodeableConcept
Requirements

Use to distinguish tasks on different activity queues.

Task.owner
Element Id Task.owner
Definition

Individual organization or Device currently responsible for task execution.

Cardinality 0..1
Type Reference ( Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson )
Patterns Reference(Practitioner,PractitionerRole,Organization,CareTeam,HealthcareService,Patient,Device,RelatedPerson): Common patterns = Participant
Requirements

Identifies who is expected to perform this task.

Alternate Names Performer; Executer
Summary true
Comments

Tasks may be created with an owner not yet identified.

Task.location
Element Id Task.location
Definition

Principal physical location where the this task is performed.

Cardinality 0..1
Type Reference ( 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).

Summary true
Task.reasonCode
Element Id Task.reasonCode
Definition

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

Cardinality 0..1
Terminology Binding TaskReason :
Type CodeableConcept
Comments

This should only be included if there is no focus or if it differs from the reason indicated on the focus.

Task.reasonReference
Element Id Task.reasonReference
Definition

A resource reference indicating why this task needs to be performed.

Cardinality 0..1
Type Reference ( Any )
Comments

Tasks might be justified based on an Observation, a Condition, a past or planned procedure, etc. This should only be included if there is no focus or if it differs from the reason indicated on the focus. Use the CodeableConcept text element in Task.reasonCode if the data is free (uncoded) text.

Task.insurance
Element Id Task.insurance
Definition

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

Cardinality 0..*
Type Reference ( Coverage | ClaimResponse )
Patterns Reference(Coverage,ClaimResponse): Common patterns = Event
Task.note
Element Id Task.note
Definition

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

Cardinality 0..*
Type Annotation
Task.relevantHistory
Element Id Task.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.

Cardinality 0..*
Type Reference ( Provenance )
Alternate Names Status History
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 Id Task.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.

Cardinality 0..1
Requirements

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

Task.restriction.repetitions
Element Id Task.restriction.repetitions
Definition

Indicates the number of times the requested action should occur.

Cardinality 0..1
Type positiveInt
Requirements

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

Task.restriction.period
Element Id Task.restriction.period
Definition

Over what time-period is fulfillment sought.

Cardinality 0..1
Type Period
Requirements

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

Comments

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

Task.restriction.recipient
Element Id Task.restriction.recipient
Definition

For requests that are targeted to more than on potential recipient/target, for whom is fulfillment sought?

Cardinality 0..*
Type Reference ( Patient | Practitioner | PractitionerRole | RelatedPerson | Group | Organization )
Patterns Reference(Patient,Practitioner,PractitionerRole,RelatedPerson,Group,Organization): Common patterns = Participant
Task.input
Element Id Task.input
Definition

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

Cardinality 0..*
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 Names Supporting Information
Task.input.type
Element Id Task.input.type
Definition

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

Cardinality 1..1
Terminology Binding TaskInputParameterType :
Type CodeableConcept
Requirements

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

Alternate Names Name
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 Id Task.input.value[x]
Definition

The value of the input parameter as a basic type.

Cardinality 1..1
Type *
[x] Note See Choice of Data Types for further information about how to use [x]
Task.output
Element Id Task.output
Definition

Outputs produced by the Task.

Cardinality 0..*
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.

Task.output.type
Element Id Task.output.type
Definition

The name of the Output parameter.

Cardinality 1..1
Terminology Binding TaskOutputParameterType :
Type CodeableConcept
Requirements

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

Alternate Names Name
Task.output.value[x]
Element Id Task.output.value[x]
Definition

The value of the Output parameter as a basic type.

Cardinality 1..1
Type *
[x] Note See Choice of Data Types for further information about how to use [x]
Requirements

Task outputs can take any form.