View raw Markdown
type: resourceresource: RequestOrchestration

RequestOrchestration

Introduction

Scope and Usage

This resource is a request resource from a FHIR workflow perspective - see Workflow, specifically Request.

The RequestOrchestration resource is used to represent a set of optional and related activities that may be performed for a specific patient or context. This resource is often, but not always, the result of applying a specific PlanDefinition to a particular patient. Other than differences that tie the RequestOrchestration to a particular subject and setting, the actionDefinition element of PlanDefinition is identical to the action element of the RequestOrchestration, allowing the same features and functionality to be used in both places to describe optionality of and relationships between activities in a workflow.

RequestOrchestrations can contain hierarchical groups of actions, where each specific action references the action to be performed (in terms of a Request resource), and each group describes additional behavior, relationships, and applicable conditions between the actions in the overall group.

Boundaries and Relationships

Explains how this resource relates to others. Particularly important is to differentiate between appropriate usages for related resources when an implementer might be confused about what to reference when.

Background and Context

Provides additional detail on exactly how the resource is to be used

Notes

Usage

The RequestOrchestration resource is used when there are temporal, co-occurrence or other dependencies between one or more steps of an overall workflow. For example, "do procedure A or procedure B, but not both" or "do procedure A after procedure B" or "Act on this ServiceRequest, then use the value of that observation in the calculation of the dose of this subsequent MedicationRequest". RequestOrchestrations that define actions (i.e. that are more than just narrative representations) will always reference other Request resources with an intent of "option".

Each "option" request can only be interpreted in the context of a RequestOrchestration that references it. This is because the RequestOrchestration defines the context in which the option request may/should/must occur, including any triggers, timing constraints, choices, sequencing requirements, etc. Typically such "option" requests will be contained resources due to this dependency. However, in some cases "option" requests may be stand-alone if they are immutable or tightly tied to a ActivityDefinition such that the option resources can safely be referenced without a risk of their content/intent changing

Elements in the "option" requests may include extensions for timing or other elements that allow calculation based on information found in the RequestOrchestration or other referenced "option" resources, as well as to expose elements within the "option" resource for referencing in other "option" resources. These extensions are:

The RequestOrchestration and all of its referenced "option" Requests are treated as a single integrated Request whose status is the status of the RequestOrchestration. If there is a need to manage statuses of the different parts, separately, refer to the guidance here.

Documenting Choices

A RequestOrchestration can be used to document (wholly or in part) options that are to be chosen by the order filler when actually delivering care. There is no expectation for systems that fulfill a RequestOrchestration to specifically document which choices were made among the options defined. However, if this is needed, it could be accomplished with a 'filler-order' RequestOrchestration basedOn the 'original-order' RequestOrchestration that narrows the order to reflect the filling clinician's choices.

NOTE: The 'intent' of the requests referenced by a RequestOrchestration are never changed from Option to Order or some other value to convey 'selection'.

Completion

A RequestOrchestration is deemed to be complete when the requirements of the request options needed to satisfy at least one path through the overall request have been met or when the author of the RequestOrchestration deems it to be sufficiently complete.

StructureDefinition

Elements (Simplified)

Mappings

Resource Packs

list-RequestOrchestration-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir">
  <id value="RequestOrchestration-packs"/>
  <status value="current"/>
  <mode value="working"/>
</List>

Search Parameters

Full Search Parameters

Examples

Full Examples

Mapping Exceptions

requestorchestration-fivews-mapping-exceptions.xml

Divergent Elements

Unmapped Elements

requestorchestration-request-mapping-exceptions.xml

Divergent Elements

Note: This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number.

A status of completed for a "doNotPerform" request indicates that the period of non-performance is now satisfied and the request no longer holds.

One exception to this is that the granularity of Request.intent is allowed to change. For example, a Request identified as an "order" might later be clarified to be a "filler-order". Or, in rarer cases (to meet recipient constraints), the reverse might also occur.

When resources map to this element, they are free to define as many codes as necessary to cover their space and will map to "proposal, plan or order". Can have multiple codes that map to one of these. E.g. "original order", "encoded order", "reflex order" would all map to "order". Expectation is that the set of codes is mutually exclusive or a strict all-encompassing hierarchy.

Unmapped Elements