type: resource-definitionsresource: Task

Task Definitions

Task

A task to be performed

Definition: A task to be performed as a part of a workflow and the related informations like inputs, outputs and execution progress. While very simple workflows can be implemented with [[[Request]]] alone, most workflows would require a Task (explicit or contained) as a means to track the execution progress (i.e. inputs, outputs, status). Please refer to Fulfillment/Execution.

Cardinality: 0..*

Constraints: tsk-0 | error | Last modified date must be greater than or equal to authored-on date. | lastModified.exists().not() or authoredOn.exists().not() or lastModified >= authoredOn; tsk-1 | error | 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() and focus.value.ofType(Reference).exists())

Mappings: workflow=Request, Event; rim=ControlAct[moodCode=INT]; w5=workflow.order

Task.identifier

Task Instance Identifier

Definition: The business identifier for this task.

Cardinality: 0..*

Type: Identifier

Mappings: workflow=Request.identifier, Event.identifier; w5=FiveWs.identifier; rim=.id

Task.basedOn

Request fulfilled by this task

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.

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

Cardinality: 0..*

Type: Reference(Resource)

Summary: true

Mappings: workflow=Request.basedOn, Event.basedOn; rim=.outboundRelationship[typeCode=FLFS].target[moodCode=INT]

Task.groupIdentifier

Requisition or grouper id

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.

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

Cardinality: 0..1

Type: Identifier

Summary: true

Mappings: workflow=Request.groupIdentifier; rim=.inboundRelationship[typeCode=COMP].source[moodCode=INT].id

Task.partOf

Composite task

Definition: Task that this particular task is part of.

Comments: This should usually be 0..1.

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

Cardinality: 0..*

Type: Reference(Task)

Summary: true

Mappings: workflow=Event.partOf; rim=.inboundRelationship[typeCode=COMP].source[moodCode=INT]

Task.status

draft | requested | received | accepted | +

Definition: The current status of the task.

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

Cardinality: 1..1

Type: code

Binding: required:task-status

Summary: true

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)

Mappings: workflow=Request.status, Event.status; w5=FiveWs.status; rim=.statusCode

Task.statusReason

Reason for current status

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

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

Cardinality: 0..*

Type: CodeableReference

Binding: example:task-status-reason

Summary: true

Mappings: rim=.inboundRelationship[typeCode=SUBJ].source[classCode=CACT, moodCode=EVN, code="status change"].reasonCode; workflow=Request.statusReason, Event.statusReason

Task.businessStatus

E.g. "Specimen collected", "IV prepped"

Definition: Contains business-specific nuances of the business state.

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

Cardinality: 0..1

Type: CodeableConcept

Binding: example:task-business-status

Summary: true

Mappings: rim=.inboundRelationship[typeCode=SUBJ].source[classCode=OBS, moodCode=EVN, code="business status"]

Task.intent

Definition: Indicates the "level" of actionability associated with the Task, i.e. this a proposed task, a planned task, an actionable task, etc.

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

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

Cardinality: 1..1

Type: code

Binding: required:task-intent

Summary: true

Mappings: workflow=Request.intent; w5=FiveWs.class; rim=.moodCode

Task.priority

routine | urgent | asap | stat

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

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

Meaning if Missing: If missing, this task should be performed with normal priority

Cardinality: 0..1

Type: code

Binding: required:request-priority

Mappings: workflow=Request.priority; w5=FiveWs.grade; rim=.priorityCode

Task.doNotPerform

True if Task is prohibiting action

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

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 resuscitate). If this happens, doNotPerform SHALL NOT be set to true. I.e. The resource SHALL NOT have double negation. (E.g. 'Do not DNR').

When Task.focus refers to a Request Resource, it is that Request's doNotPerform Flag that indicates that the action should not be performed. A Task can be used to request that authorized action is not performed by having task.focus point to that request resource and use Task.code as the do not perform indicator.

Note that the use of doNotPerform and negation in Task.code can cause ambiguity and the impact of this should be considered not only for task but also for all related resources.

Cardinality: 0..1

Type: boolean

Summary: true

Is Modifier: true (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.)

Mappings: workflow=Request.doNotPerform, Event.doNotPerform; w5=FiveWs.what[x]; rim=.code

Task.code

Task Type

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

Conditions: tsk-1

Cardinality: 0..1

Type: CodeableConcept

Binding: extensible:task-code

Summary: true

Mappings: workflow=Request.code, Event.code; w5=FiveWs.what[x]; rim=.code

Task.description

Human-readable explanation of task

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

Cardinality: 0..1

Type: markdown

Summary: true

Mappings: rim=.text

Task.focus

What task is acting on

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

Comments: If multiple resources need to be manipulated, use sub-tasks. (This ensures that status can be tracked independently for each referenced resource.). Typically a Task should only have one focus. If multiple focuses are provided, then action must be taken on the complete set as a whole (i.e,. all must be accepted, rejected, cancelled, held, completed, etc. as a whole). If there is a possibility to have different statuses for different focuses, then there SHALL be a separate Task instance for each focus.

Requirements: Used to identify the thing to be done.

Conditions: tsk-1

Cardinality: 0..*

Type: BackboneElement

Summary: true

Mappings: w5=FiveWs.what[x]; rim=.outboundRelationship[typeCode=SUBJ].target; workflow=Request.product, Event.product

Task.focus.value[x]

What task is acting on

Definition: What task is acting on.

Cardinality: 1..1

Type: Reference(Resource), canonical

Summary: true

Task.for

Beneficiary of the Task

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

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.

Aliases: Patient

Cardinality: 0..1

Type: Reference(Resource)

Summary: true

Mappings: workflow=Request.subject, Event.subject; w5=FiveWs.subject; rim=.participation[typeCode=RCT].role

Task.encounter

Healthcare event during which this task originated

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

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

Cardinality: 0..1

Type: Reference(Encounter)

Summary: true

Mappings: workflow=Request.encounter, Event.encounter; w5=FiveWs.context; rim=.inboundRelationship[typeCode=COMP].source[classCode=PCPR, moodCode=EVN]

Task.requestedPeriod

When the task should be performed

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

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.

Cardinality: 0..1

Type: Period

Summary: true

Mappings: workflow=Request.occurrence[x]; rim=.effectiveTime

Task.executionPeriod

Start and end time of execution

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

Mappings: workflow=Event.occurrence[x]; w5=FiveWs.done[x]; rim=.effectiveTime

Task.authoredOn

Task Creation Date

Definition: The date and time this task was created.

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

Aliases: Created Date

Cardinality: 0..1

Type: dateTime

Mappings: workflow=Request.authoredOn, Event.recorded; w5=FiveWs.recorded; rim=.participation[typeCode=AUT].time

Task.lastModified

Task Last Modified Date

Definition: The date and time of last modification to this task.

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

Aliases: Update Date

Cardinality: 0..1

Type: dateTime

Summary: true

Mappings: rim=.inboundRelationship[typeCode=SUBJ, ].source[classCode=CACT, moodCode=EVN].effectiveTime

Task.requester

Who is asking for task to be done

Definition: The creator of the task.

Comments: Group is only allowed in the circumstance where the group represents a family or a household, and should not represent groups of Practitioners where other more specific resources can be used instead.

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

Cardinality: 0..1

Type: Reference(Device, Group, Organization, Patient, Practitioner, PractitionerRole, RelatedPerson)

Summary: true

Mappings: workflow=Request.requester; w5=FiveWs.author; rim=.participation[typeCode=AUT].role

Task.requestedPerformer

Who should perform the Task

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

Requirements: Use to distinguish tasks on different activity queues.

Cardinality: 0..*

Type: CodeableReference

Binding: preferred:performer-role

Mappings: workflow=Event.performer.function, Request.performerType; w5=FiveWs.actor; rim=.participation[typeCode=PRF].role.code

Task.owner

Responsible individual

Definition: Party responsible for managing task execution.

Comments: Tasks may be created with an owner not yet identified. Group is only allowed in the circumstance where the group represents a family or a household, and should not represent groups of Practitioners where other more specific resources can be used instead.

Requirements: Identifies who is expected to perform this task.

Aliases: Performer, Executer

Cardinality: 0..1

Type: Reference(Practitioner, PractitionerRole, Organization, CareTeam, Patient, RelatedPerson, Group)

Summary: true

Mappings: workflow=Event.performer.actor, Request.performer; w5=FiveWs.actor; rim=.participation[typeCode=PRF].role

Task.performer

Who or what performed the task

Definition: The entity who performed the requested task.

Cardinality: 0..*

Type: BackboneElement

Summary: true

Task.performer.function

Type of performance

Definition: A code or description of the performer of the task.

Cardinality: 0..1

Type: CodeableConcept

Binding: example:task-performer-function-code

Summary: true

Task.performer.actor

Who performed the task

Definition: The actor or entity who performed the task.

Cardinality: 1..1

Type: Reference(Practitioner, Device, Organization, PractitionerRole, CareTeam, Patient, RelatedPerson, Group)

Summary: true

Task.location

Where task occurs

Definition: Principal physical location where this task is performed.

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.

Requirements: Provides context around the event occurrence (e.g. if it occurred inside or outside a dedicated healthcare setting).

Cardinality: 0..1

Type: Reference(Location)

Summary: true

Mappings: w5=FiveWs.where[x]; rim=.participation[typeCode=LOC].role; workflow=Event.location

Task.reason

Why task is needed

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

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.

Cardinality: 0..*

Type: CodeableReference

Binding: example:task-reason

Mappings: workflow=Event.reason, Request.reason; w5=FiveWs.why[x]; v2=EVN-7; rim=.reasonCode

Task.insurance

Associated insurance coverage

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

Cardinality: 0..*

Type: Reference(Coverage, ClaimResponse)

Mappings: workflow=Request.insurance; v2=IN1/IN2; rim=.outboundRelationship[typeCode=COVBY].target

Task.note

Comments made about the task

Definition: Free-text information about the task during its lifecycle.

Cardinality: 0..*

Type: Annotation

Mappings: workflow=Request.note, Event.note; rim=.inboundRelationship[typeCode=SUBJ, ].source[classCode=OBS, moodCode=EVN, code="annotation"].value(string)

Task.relevantHistory

Key events in history of the Task

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.

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.

Aliases: Status History

Cardinality: 0..*

Type: Reference(Provenance)

Mappings: workflow=Request.relevantHistory; rim=.inboundRelationship(typeCode=SUBJ].source[classCode=CACT, moodCode=EVN]

Task.restriction

Constraints on fulfillment tasks

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.

Comments: This element should only be used when the Task is seeking fulfillment of a request resource that authorizes a broader set of subjects, repetitions and/or time-period than the Task itself is seeking execution against. It is not used otherwise.

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

Conditions: tsk-1

Cardinality: 0..1

Type: BackboneElement

Mappings: rim=Instead of pointing to request, would point to component of request, having these characteristics

Task.restriction.repetitions

How many times to repeat

Definition: Indicates the number of times the requested action should occur.

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

Cardinality: 0..1

Type: positiveInt

Mappings: rim=.repeatNumber

Task.restriction.period

When fulfillment is sought

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

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.

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

Cardinality: 0..1

Type: Period

Mappings: rim=.effectiveTime(IVL<TS>)

Task.restriction.recipient

Individual or entity from whom fulfillment is being sought

Definition: For requests directed at multiple potential recipients or targets, this is used to specify the individual or entity from whom fulfillment is being sought.

Comments: If seeking fulfillment of a ServiceRequest where the ServiceRequest.subject was a Group of devices, but the Task was only seeking execution against a single device. If just creating a Task that is to manipulate a device in the absence of a broader order, there's no need for restriction.recipient. The Device to be manipulated would be the Task.focus (and potentially the Task.for - if the action wasn't for the benefit of a Patient or some other record).

Cardinality: 0..*

Type: Reference(Patient, Practitioner, PractitionerRole, RelatedPerson, Group, Organization, Device)

Mappings: rim=.participation[typeCode=SBJ].role

Task.input

Information used to perform task

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

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.

Aliases: Supporting Information

Cardinality: 0..*

Type: BackboneElement

Mappings: rim=???

Task.input.type

Label for the input

Definition: A code or description to distinguish between inputs.

Comments: The type of the input may affect how it is used in the task. 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.

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

Aliases: Name

Cardinality: 1..1

Type: CodeableConcept

Binding: example:task-inputoutput-parameter-type

Mappings: rim=???

Task.input.value[x]

Content to use in performing the task

Definition: The value of the input parameter as a basic type.

Cardinality: 1..1

Type: base64Binary, boolean, canonical, code, date, dateTime, decimal, id, instant, integer, integer64, 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, DataRequirement, Expression, ParameterDefinition, RelatedArtifact, TriggerDefinition, UsageContext, Dosage, CodeableReference, Meta

Mappings: rim=???; workflow=Request.supportingInfo

Task.output

Information produced as part of task

Definition: Outputs produced by the Task.

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.

Cardinality: 0..*

Type: BackboneElement

Mappings: rim=???

Task.output.type

Label for output

Definition: A code or description to distinguish between outputs.

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

Aliases: Name

Cardinality: 1..1

Type: CodeableConcept

Binding: example:task-inputoutput-parameter-type

Mappings: rim=???

Task.output.value[x]

Result of output

Definition: The value of the Output parameter as a basic type.

Requirements: Task outputs can take any form.

Cardinality: 1..1

Mappings: rim=???