A group 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 all requests that were authorized more or less simultaneously by a single author, representing the identifier of the requisition, prescription or similar form.

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 groups, the status reflects the status of all the requests in the group.

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 group is.

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

The subject for which the request group was created.

Describes the context of the request group, if any.

Indicates when the request group was created.

Provides a reference to the author of the request group.

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

Indicates another resource whose existence justifies Goals that are intended to be achieved by following the requests in this request group. RequestGroup.

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

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

The element id of the action this is target related to. action.

The relationship 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 groups 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.

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

Sub actions.