Release 4B

This page is part of the FHIR Specification (v4.3.0: R4B - STU). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3

Orders and Observations Work GroupMaturity Level: 2 Trial UseSecurity Category: Not Classified Compartments: Not linked to any defined compartments

Detailed Descriptions for the elements in the Task resource.

Task
Element IdTask
Definition

A task to be performed.

Cardinality0..*
TypeDomainResource
Summaryfalse
Invariants
Defined on 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.identifier
Element IdTask.identifier
Definition

The business identifier for this task.

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.

Cardinality0..1
Typecanonical(ActivityDefinition)
Requirements

Enables a formal definition of how he 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.

Cardinality0..1
Typeuri
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.

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

Cardinality0..*
TypeReference(Any)
Summarytrue
Task.groupIdentifier
Element IdTask.groupIdentifier
Definition

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

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.

Cardinality0..*
TypeReference(Task)
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.

Cardinality1..1
Terminology BindingTaskStatus (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.

Cardinality0..1
Terminology BindingTaskStatusReason:
TypeCodeableConcept
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.

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.

Cardinality1..1
Terminology BindingTaskIntent (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.

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.code
Element IdTask.code
Definition

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

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

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

Task.description
Element IdTask.description
Definition

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

Cardinality0..1
Typestring
Summarytrue
Task.focus
Element IdTask.focus
Definition

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

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

Task.for
Element IdTask.for
Definition

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

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.

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

Cardinality0..1
TypePeriod
Summarytrue
Task.authoredOn
Element IdTask.authoredOn
Definition

The date and time this task was created.

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.

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.

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.performerType
Element IdTask.performerType
Definition

The kind of participant that should perform the task.

Cardinality0..*
Terminology BindingProcedure Performer Role Codes (Preferred)
TypeCodeableConcept
Requirements

Use to distinguish tasks on different activity queues.

Summaryfalse
Task.owner
Element IdTask.owner
Definition

Individual organization or Device currently responsible for task execution.

Cardinality0..1
TypeReference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | 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.location
Element IdTask.location
Definition

Principal physical location where the this task is performed.

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
Task.reasonCode
Element IdTask.reasonCode
Definition

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

Cardinality0..1
Terminology BindingTaskReason:
TypeCodeableConcept
Summaryfalse
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 IdTask.reasonReference
Definition

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

Cardinality0..1
TypeReference(Any)
Summaryfalse
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 IdTask.insurance
Definition

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

Cardinality0..*
TypeReference(Coverage | ClaimResponse)
Summaryfalse
Task.note
Element IdTask.note
Definition

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

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.

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.

Cardinality0..1
Requirements

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

Summaryfalse
Task.restriction.repetitions
Element IdTask.restriction.repetitions
Definition

Indicates the number of times the requested action should occur.

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

Over what time-period is fulfillment sought.

Cardinality0..1
TypePeriod
Requirements

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

Summaryfalse
Comments

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 on potential recipient/target, for 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.

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.

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.

Cardinality1..1
Typebase64Binary|boolean|canonical|code|date|dateTime|decimal|id|instant|integer|markdown|oid|positiveInt|string|time|unsignedInt|uri|url|uuid|Address|Age|Annotation|Attachment|CodeableConcept|Coding|ContactPoint|Count|Distance|Duration|HumanName|Identifier|Money|Period|Quantity|Range|Ratio|Reference|SampledData|Signature|Timing|ContactDetail|Contributor|DataRequirement|Expression|ParameterDefinition|RelatedArtifact|TriggerDefinition|UsageContext|Dosage|Meta
[x] NoteSee Choice of Data Types for further information about how to use [x]
Summaryfalse
Task.output
Element IdTask.output
Definition

Outputs produced by the 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.

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.

Cardinality1..1
Typebase64Binary|boolean|canonical|code|date|dateTime|decimal|id|instant|integer|markdown|oid|positiveInt|string|time|unsignedInt|uri|url|uuid|Address|Age|Annotation|Attachment|CodeableConcept|Coding|ContactPoint|Count|Distance|Duration|HumanName|Identifier|Money|Period|Quantity|Range|Ratio|Reference|SampledData|Signature|Timing|ContactDetail|Contributor|DataRequirement|Expression|ParameterDefinition|RelatedArtifact|TriggerDefinition|UsageContext|Dosage|Meta
[x] NoteSee Choice of Data Types for further information about how to use [x]
Requirements

Task outputs can take any form.

Summaryfalse