A set of related requests that can be used to capture intended activities that have inter-dependencies such as "give this medication after that one".

Allows a service to provide a unique, business identifier for the request.

Allows identification of the request as it is known by various participating systems and in a way that remains consistent across servers.

A canonical URL referencing a FHIR-defined protocol, guideline, orderset or other definition that is adhered to in whole or in part by this request.

A URL referencing an externally defined protocol, guideline, orderset or other definition that is adhered to in whole or in part by this request.

A plan, proposal or order that is fulfilled in whole or in part by this request.

Allows tracing of authorization for the request and tracking whether proposals/recommendations were acted upon.

Completed or terminated request(s) whose function is taken by this new request.

Allows tracing the continuation of a therapy or administrative process instantiated through multiple requests.

The replacement could be because the initial request was immediately rejected (due to an issue) or because the previous request was completed, but the need for the action described by the request remains ongoing.

A shared identifier common to multiple independent 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.

Some business processes need to know if multiple items were ordered as part of the same "prescription" or "requisition" for billing or other purposes.

Requests are linked either by a "basedOn" relationship (i.e. one request is fulfilling another) or by having a common requisition. Requests that are part of the same requisition are generally treated independently from the perspective of changing their state or maintaining them after initial creation.

The current state of the request. For request orchestrations, the status reflects the status of all the requests in the orchestration.

Indicates the level of authority/intentionality associated with the request and where the request fits into the workflow chain.

Proposals/recommendations, plans and orders all use the same structure and can exist in the same fulfillment chain.

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

A code that identifies what the overall request orchestration is.

This element can be used to provide a code that captures the meaning of the request orchestration as a whole, as opposed to the code of the action element, which captures the meaning of the individual actions within the request orchestration.

The subject for which the request orchestration was created.

Describes the context of the request orchestration, if any.

Indicates when the request orchestration was created.

Provides a reference to the author of the request orchestration.

Describes the reason for the request orchestration in coded or textual form.

Goals that are intended to be achieved by following the requests in this RequestOrchestration.

Provides a mechanism to communicate additional information about the response.

The actions, if any, produced by the evaluation of the artifact.

The linkId of the action from the PlanDefinition that corresponds to this action in the RequestOrchestration resource.

A user-visible prefix for the action. For example a section or item numbering such as 1. or A.

The title of the action displayed to a user.

A short description of the action used to provide a summary to display to the user.

A text equivalent of the action to be performed. This provides a human-interpretable description of the action when the definition is consumed by a system that might not be capable of interpreting it dynamically.

Indicates how quickly the action should be addressed with respect to other actions.

A code that provides meaning for the action or action group. For example, a section may have a LOINC code for a section of a documentation template.

Didactic or other informational resources associated with the action that can be provided to the CDS recipient. Information resources can include inline text commentary and links to web resources.

Goals that are intended to be achieved by following the requests in this action.

An expression that describes applicability criteria, or start/stop conditions for the action.

When multiple conditions of the same kind are present, the effects are combined using AND semantics, so the overall condition is true only if all of the conditions are true.

The kind of condition.

Applicability criteria are used to determine immediate applicability when a plan definition is applied to a given context. Start and stop criteria are carried through application and used to describe enter/exit criteria for an action.

An expression that returns true or false, indicating whether or not the condition is satisfied.

The expression may be inlined, or may be a reference to a named expression within a logic library referenced by the library element.

Defines input data requirements for the action.

A human-readable label for the data requirement used to label data flows in BPMN or similar diagrams. Also provides a human readable label when rendering the data requirement that conveys its purpose to human readers.

Defines the data that is to be provided as input to the action.

Points to an existing input or output element that provides data to this input.

The relatedData element allows indicating that an input to a parent action is an input to specific child actions. It also allows the output of one action to be identified as the input to a different action

Defines the outputs of the action, if any.

A human-readable label for the data requirement used to label data flows in BPMN or similar diagrams. Also provides a human readable label when rendering the data requirement that conveys its purpose to human readers.

Defines the data that results as output from the action.

Points to an existing input or output element that is results as output from the action.

The relatedData element allows indicating that the output of child action is also the output of a parent action. It also allows the input of one action to be identified as the output of a different action

A relationship to another action such as "before" or "30-60 minutes after start of".

The element id of the target related action.

The relationship of this action to the related action.

The relationship of the end of this action to the related action.

A duration or range of durations to apply to the relationship. For example, 30-60 minutes before.

An optional value describing when the action should be performed.

Allows prompting for activities and detection of missed planned activities.

The intent of the timing element is to provide timing for when the action should be performed. The timing may be absolute (specified as a dateTime or Period) or relative (specified as an Age, Duration, or Range), or it may be a more complex, potentially repeating timing specified using Timing.

Identifies the facility where the action will occur; e.g. home, hospital, specific clinic, etc.

Helps in planning of activity.

May reference a specific clinical location or may just identify a type of location.

The participant that should perform or be responsible for this action.

Because request orchestrations represent potential options for performing activities, some specific participants may still be unknown, so this element allows for both definitional participants (in the same way they are specified in ActivityDefinition and PlanDefinition resources) as well as identifying specific participants when they are known.

The type of participant in the action.

The type of participant in the action.

The type of participant in the action.

When this element is a reference, it SHOULD be a reference to a definitional resource (for example, a location type, rather than a specific location).

The role the participant should play in performing the described action.

Indicates how the actor will be involved in the action - author, reviewer, witness, etc.

A reference to the actual participant.

The type of action to perform (create, update, remove).

Defines the grouping behavior for the action and its children.

Defines the selection behavior for the action and its children.

Defines expectations around whether an action is required.

Defines whether the action should usually be preselected.

Defines whether the action can be selected multiple times.

The resource that is the target of the action (e.g. CommunicationRequest).

The target resource SHALL be a Request resource with a Request.intent set to "option".

A reference to an ActivityDefinition that describes the action to be taken in detail, a PlanDefinition that describes a series of actions to be taken, a Questionnaire that should be filled out, a SpecimenDefinition describing a specimen to be collected, or an ObservationDefinition that specifies what observation should be captured.

Note that the definition is optional, and if no definition is specified, a dynamicValue with a root ($this) path can be used to define the entire resource dynamically.

A reference to a StructureMap resource that defines a transform that can be executed to produce the intent resource using the ActivityDefinition instance as the input.

Note that when a referenced ActivityDefinition also defines a transform, the transform specified here generally takes precedence. In addition, if both a transform and dynamic values are specific, the dynamic values are applied to the result of the transform.

Customizations that should be applied to the statically defined resource. For example, if the dosage of a medication must be computed based on the patient's weight, a customization would be used to specify an expression that calculated the weight, and the path on the resource that would contain the result.

Dynamic values are applied in the order in which they are defined in the RequestOrchestration resource. Note that when dynamic values are also specified by a referenced ActivityDefinition, the dynamicValues from the ActivityDefinition are applied first, followed by the dynamicValues specified here. In addition, if both a transform and dynamic values are specific, the dynamic values are applied to the result of the transform.

The path to the element to be customized. This is the path on the resource that will hold the result of the calculation defined by the expression. The specified path SHALL be a FHIRPath resolvable on the specified target type of the ActivityDefinition, and SHALL consist only of identifiers, constant indexers, and a restricted subset of functions. The path is allowed to contain qualifiers (.) to traverse sub-elements, as well as indexers ([x]) to traverse multiple-cardinality sub-elements (see the Simple FHIRPath Profile for full details).

To specify the path to the current action being realized, the %action environment variable is available in this path. For example, to specify the description element of the target action, the path would be %action.description. The path attribute contains a Simple FHIRPath Subset that allows path traversal, but not calculation.

An expression specifying the value of the customized element.

The expression may be inlined or may be a reference to a named expression within a logic library referenced by the library element.

Sub actions.