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 this request group.

Provides a mechanism to communicate additional information about the response.

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

A user-visible prefix for the action.

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.

A code that provides meaning for the action or action group. For example, a section may have a LOINC code for a the 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.

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.

A brief, natural language description of the condition that effectively communicates the intended semantics.

The media type of the language for the expression.

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 related to.

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.

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

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 the requiredness behavior for the action.

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.