This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions
Orders and Observations Work Group | Maturity Level: 3 | Trial Use | Security Category: Not Classified | Compartments: Patient |
Detailed Descriptions for the elements in the Task resource.
Task | |||||||||||||
Element Id | Task | ||||||||||||
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 data (i.e. inputs, outputs, status). Please refer to Fulfillment/Execution. | ||||||||||||
Short Display | A task to be performed | ||||||||||||
Cardinality | 0..* | ||||||||||||
Type | DomainResource | ||||||||||||
Summary | false | ||||||||||||
Invariants |
| ||||||||||||
Task.identifier | |||||||||||||
Element Id | Task.identifier | ||||||||||||
Definition | The business identifier for this task. | ||||||||||||
Short Display | Task Instance Identifier | ||||||||||||
Note | This is a business identifier, not a resource identifier (see discussion) | ||||||||||||
Cardinality | 0..* | ||||||||||||
Type | Identifier | ||||||||||||
Summary | false | ||||||||||||
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. | ||||||||||||
Short Display | Formal definition of task | ||||||||||||
Cardinality | 0..1 | ||||||||||||
Type | canonical(ActivityDefinition) | ||||||||||||
Requirements | Enables a formal definition of how the 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. | ||||||||||||
Short Display | Formal definition of task | ||||||||||||
Cardinality | 0..1 | ||||||||||||
Type | uri | ||||||||||||
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. | ||||||||||||
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, 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 Display | Request fulfilled by this task | ||||||||||||
Cardinality | 0..* | ||||||||||||
Type | Reference(Any) | ||||||||||||
Summary | true | ||||||||||||
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 | ||||||||||||
Task.groupIdentifier | |||||||||||||
Element Id | Task.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 Display | Requisition or grouper id | ||||||||||||
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. | ||||||||||||
Short Display | Composite task | ||||||||||||
Cardinality | 0..* | ||||||||||||
Type | Reference(Task) | ||||||||||||
Hierarchy | This 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). | ||||||||||||
Summary | true | ||||||||||||
Comments | This should usually be 0..1. | ||||||||||||
Task.status | |||||||||||||
Element Id | Task.status | ||||||||||||
Definition | The current status of the task. | ||||||||||||
Short Display | draft | requested | received | accepted | + | ||||||||||||
Cardinality | 1..1 | ||||||||||||
Terminology Binding | Task Status (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. | ||||||||||||
Short Display | Reason for current status | ||||||||||||
Cardinality | 0..1 | ||||||||||||
Terminology Binding | Task Status Reason (Example) | ||||||||||||
Type | CodeableReference | ||||||||||||
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. | ||||||||||||
Short Display | E.g. "Specimen collected", "IV prepped" | ||||||||||||
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. this a proposed task, a planned task, an actionable task, etc. | ||||||||||||
Short Display | unknown | proposal | plan | order | original-order | reflex-order | filler-order | instance-order | option | ||||||||||||
Cardinality | 1..1 | ||||||||||||
Terminology Binding | Task Intent (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. | ||||||||||||
Short Display | routine | urgent | asap | stat | ||||||||||||
Cardinality | 0..1 | ||||||||||||
Terminology Binding | RequestPriority (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. | ||||||||||||
Summary | false | ||||||||||||
Task.doNotPerform | |||||||||||||
Element Id | Task.doNotPerform | ||||||||||||
Definition | If true indicates that the Task is asking for the specified action to not occur. | ||||||||||||
Short Display | True if Task is prohibiting action | ||||||||||||
Cardinality | 0..1 | ||||||||||||
Type | boolean | ||||||||||||
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.) | ||||||||||||
Summary | true | ||||||||||||
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 Id | Task.code | ||||||||||||
Definition | A name or code (or both) briefly describing what the task involves. | ||||||||||||
Short Display | Task Type | ||||||||||||
Cardinality | 0..1 | ||||||||||||
Terminology Binding | Task Codes (Example) | ||||||||||||
Type | CodeableConcept | ||||||||||||
Summary | true | ||||||||||||
Invariants |
| ||||||||||||
Task.description | |||||||||||||
Element Id | Task.description | ||||||||||||
Definition | A free-text description of what is to be performed. | ||||||||||||
Short Display | Human-readable explanation of task | ||||||||||||
Cardinality | 0..1 | ||||||||||||
Type | markdown | ||||||||||||
Summary | true | ||||||||||||
Task.focus | |||||||||||||
Element Id | Task.focus | ||||||||||||
Definition | The request being fulfilled or the resource being manipulated (changed, suspended, etc.) by this task. | ||||||||||||
Short Display | What task is acting on | ||||||||||||
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.). | ||||||||||||
Invariants |
| ||||||||||||
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). | ||||||||||||
Short Display | Beneficiary of the Task | ||||||||||||
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. | ||||||||||||
Short Display | Healthcare event during which this task originated | ||||||||||||
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.requestedPeriod | |||||||||||||
Element Id | Task.requestedPeriod | ||||||||||||
Definition | Indicates the start and/or end of the period of time when completion of the task is desired to take place. | ||||||||||||
Short Display | When the task should be performed | ||||||||||||
Cardinality | 0..1 | ||||||||||||
Type | Period | ||||||||||||
Summary | true | ||||||||||||
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 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). | ||||||||||||
Short Display | Start and end time of execution | ||||||||||||
Cardinality | 0..1 | ||||||||||||
Type | Period | ||||||||||||
Summary | true | ||||||||||||
Task.authoredOn | |||||||||||||
Element Id | Task.authoredOn | ||||||||||||
Definition | The date and time this task was created. | ||||||||||||
Short Display | Task Creation Date | ||||||||||||
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 | ||||||||||||
Summary | false | ||||||||||||
Invariants |
| ||||||||||||
Task.lastModified | |||||||||||||
Element Id | Task.lastModified | ||||||||||||
Definition | The date and time of last modification to this task. | ||||||||||||
Short Display | Task Last Modified Date | ||||||||||||
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 |
| ||||||||||||
Task.requester | |||||||||||||
Element Id | Task.requester | ||||||||||||
Definition | The creator of the task. | ||||||||||||
Short Display | Who is asking for task to be done | ||||||||||||
Cardinality | 0..1 | ||||||||||||
Type | Reference(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). | ||||||||||||
Summary | true | ||||||||||||
Task.requestedPerformer | |||||||||||||
Element Id | Task.requestedPerformer | ||||||||||||
Definition | The kind of participant or specific participant that should perform the task. | ||||||||||||
Short Display | Who should perform the Task | ||||||||||||
Cardinality | 0..* | ||||||||||||
Terminology Binding | Procedure Performer Role Codes (Preferred) | ||||||||||||
Type | CodeableReference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson) | ||||||||||||
Requirements | Use to distinguish tasks on different activity queues. | ||||||||||||
Summary | false | ||||||||||||
Task.owner | |||||||||||||
Element Id | Task.owner | ||||||||||||
Definition | Party responsible for managing task execution. | ||||||||||||
Short Display | Responsible individual | ||||||||||||
Cardinality | 0..1 | ||||||||||||
Type | Reference(Practitioner | PractitionerRole | Organization | CareTeam | Patient | RelatedPerson) | ||||||||||||
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.performer | |||||||||||||
Element Id | Task.performer | ||||||||||||
Definition | The entity who performed the requested task. | ||||||||||||
Short Display | Who or what performed the task | ||||||||||||
Cardinality | 0..* | ||||||||||||
Summary | true | ||||||||||||
Task.performer.function | |||||||||||||
Element Id | Task.performer.function | ||||||||||||
Definition | A code or description of the performer of the task. | ||||||||||||
Short Display | Type of performance | ||||||||||||
Cardinality | 0..1 | ||||||||||||
Terminology Binding | TaskPerformerFunctionCode: | ||||||||||||
Type | CodeableConcept | ||||||||||||
Summary | true | ||||||||||||
Task.performer.actor | |||||||||||||
Element Id | Task.performer.actor | ||||||||||||
Definition | The actor or entity who performed the task. | ||||||||||||
Short Display | Who performed the task | ||||||||||||
Cardinality | 1..1 | ||||||||||||
Type | Reference(Practitioner | PractitionerRole | Organization | CareTeam | Patient | RelatedPerson) | ||||||||||||
Summary | true | ||||||||||||
Task.location | |||||||||||||
Element Id | Task.location | ||||||||||||
Definition | Principal physical location where this task is performed. | ||||||||||||
Short Display | Where task occurs | ||||||||||||
Cardinality | 0..1 | ||||||||||||
Type | Reference(Location) | ||||||||||||
Requirements | Provides context around the event occurrence (e.g. if it occurred inside or outside a dedicated healthcare setting). | ||||||||||||
Summary | true | ||||||||||||
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 Id | Task.reason | ||||||||||||
Definition | A description, code, or reference indicating why this task needs to be performed. | ||||||||||||
Short Display | Why task is needed | ||||||||||||
Cardinality | 0..* | ||||||||||||
Terminology Binding | TaskReason: | ||||||||||||
Type | CodeableReference(Any) | ||||||||||||
Summary | false | ||||||||||||
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 Id | Task.insurance | ||||||||||||
Definition | Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be relevant to the Task. | ||||||||||||
Short Display | Associated insurance coverage | ||||||||||||
Cardinality | 0..* | ||||||||||||
Type | Reference(Coverage | ClaimResponse) | ||||||||||||
Summary | false | ||||||||||||
Task.note | |||||||||||||
Element Id | Task.note | ||||||||||||
Definition | Free-text information about the task during its lifecycle. | ||||||||||||
Short Display | Comments made about the task | ||||||||||||
Cardinality | 0..* | ||||||||||||
Type | Annotation | ||||||||||||
Summary | false | ||||||||||||
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. | ||||||||||||
Short Display | Key events in history of the Task | ||||||||||||
Cardinality | 0..* | ||||||||||||
Type | Reference(Provenance) | ||||||||||||
Alternate Names | Status History | ||||||||||||
Summary | false | ||||||||||||
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. | ||||||||||||
Short Display | Constraints on fulfillment tasks | ||||||||||||
Cardinality | 0..1 | ||||||||||||
Requirements | Sometimes when fulfillment is sought, you don't want full fulfillment. | ||||||||||||
Summary | false | ||||||||||||
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 |
| ||||||||||||
Task.restriction.repetitions | |||||||||||||
Element Id | Task.restriction.repetitions | ||||||||||||
Definition | Indicates the number of times the requested action should occur. | ||||||||||||
Short Display | How many times to repeat | ||||||||||||
Cardinality | 0..1 | ||||||||||||
Type | positiveInt | ||||||||||||
Requirements | E.g. order that requests monthly lab tests, fulfillment is sought for 1. | ||||||||||||
Summary | false | ||||||||||||
Task.restriction.period | |||||||||||||
Element Id | Task.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 Display | When fulfillment is sought | ||||||||||||
Cardinality | 0..1 | ||||||||||||
Type | Period | ||||||||||||
Requirements | E.g. order that authorizes 1 year's services. Fulfillment is sought for next 3 months. | ||||||||||||
Summary | false | ||||||||||||
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 Id | Task.restriction.recipient | ||||||||||||
Definition | For requests that are targeted to more than one potential recipient/target, to identify who is fulfillment is sought for. | ||||||||||||
Short Display | For whom is fulfillment sought? | ||||||||||||
Cardinality | 0..* | ||||||||||||
Type | Reference(Patient | Practitioner | PractitionerRole | RelatedPerson | Group | Organization) | ||||||||||||
Summary | false | ||||||||||||
Task.input | |||||||||||||
Element Id | Task.input | ||||||||||||
Definition | Additional information that may be needed in the execution of the task. | ||||||||||||
Short Display | Information used to perform 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 | ||||||||||||
Summary | false | ||||||||||||
Task.input.type | |||||||||||||
Element Id | Task.input.type | ||||||||||||
Definition | A code or description to distinguish between inputs. | ||||||||||||
Short Display | Label for the input | ||||||||||||
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 | ||||||||||||
Summary | false | ||||||||||||
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. | ||||||||||||
Task.input.value[x] | |||||||||||||
Element Id | Task.input.value[x] | ||||||||||||
Definition | The value of the input parameter as a basic type. | ||||||||||||
Short Display | Content to use in performing the task | ||||||||||||
Cardinality | 1..1 | ||||||||||||
Type | * | ||||||||||||
[x] Note | See Choice of Datatypes for further information about how to use [x] | ||||||||||||
Summary | false | ||||||||||||
Task.output | |||||||||||||
Element Id | Task.output | ||||||||||||
Definition | Outputs produced by the Task. | ||||||||||||
Short Display | Information produced as part of 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. | ||||||||||||
Summary | false | ||||||||||||
Task.output.type | |||||||||||||
Element Id | Task.output.type | ||||||||||||
Definition | A code or description to distinguish between outputs. | ||||||||||||
Short Display | Label for output | ||||||||||||
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 | ||||||||||||
Summary | false | ||||||||||||
Task.output.value[x] | |||||||||||||
Element Id | Task.output.value[x] | ||||||||||||
Definition | The value of the Output parameter as a basic type. | ||||||||||||
Short Display | Result of output | ||||||||||||
Cardinality | 1..1 | ||||||||||||
Type | * | ||||||||||||
[x] Note | See Choice of Datatypes for further information about how to use [x] | ||||||||||||
Requirements | Task outputs can take any form. | ||||||||||||
Summary | false |