Template  OSD - Order sequence definition

This data type specifies a fully coded version for forming a relationship between an order and one or more other orders. The relationship may be sequential or a cyclical pattern.

Usage of the OSD is restricted to the TQ data type (especially as it is applied to the ORC-7?). Retained for backward compatibility only as of v 2.5. The reader is advised to consider the TQ1 and TQ2 segments rather than this data type if sequencing levels or cyclical patterns need to be transmitted.

Note: Replaces the CM data type used in the TQ data type, component 10, as of v 2.5.

There are many situations, such as the creation of an order for a group of intravenous (IV) solutions, where the sequence of the individual intravenous solutions (each a service in itself) needs to be specified, e.g., hyperalimentation with multi-vitamins in every third bottle.

There are other situations where part of the order’s instructions contains a results condition of some type, such as "PRN pain". There is currently a free text "condition" component of ORC-7-quantity/timing that allows any condition to be specified.

The sequencing conditions are based on the completion of a predecessor service.

Usage notes:

Suppose the following:

The predecessor order is defined by the OE1000&OrdEnt as the placer order number, in subcomponents 2 and 3 of component 10 of ORC-7-quantity/timing.

The successor order, this order, has the placer order number OE1001^OrdEnt in the ORC segment.

The following sequence condition values have the following meanings:

Use Case 1: Cyclic placer order groups

For the special case where there is a cycle of orders that must be repeated, the first order to be executed will have a "sequence condition value" whose first character must be an asterisk (*). The last order to be executed may have a "sequence condition value" whose first character must be a pound sign (#).

Example:

Translates to: execute this order the first time without evaluating the condition specified in the 10th component; but repeat only its execution when the specified external order’s start or finish date/time has met this condition. This specification generates a repetition of the order for each iteration of the cycle.

Note: This requires that the ordering application be able to specify the placer order number of the last order in the cycle in the first order’s quantity/timing specification.

To implement a cyclic group of four IV orders using the parent/child paradigm, the parent specifies a custom group of IVs, and the following occurs:

ORC-7-quantity/timing of the second child order specifies that it follows the first child order.

ORC-7-quantity/timing of the third child order specifies that it follows the second child order.

ORC-7-quantity/timing of the fourth child order specifies that it follows the third order.

To repeat the group of four child orders in a cyclic manner, the following occurs:

ORC-7-quantity/timing of the first child order specifies that it is to be executed once without any dependence on the completion of other orders.

Its second execution follows the completion of the fourth order. See example in Chapter 4 RXO segment examples. This scheme allows the following to be tracked:

The status of the whole group of orders to be reported back at the level of the parent order.

The status for each individual IV order by following the status of the corresponding child order.

Separate Orders example:

The same group of orders can be sent as a group of four orders (without a common parent), linked only by the data in their quantity/timing fields. In this case, there is no convenient HL7 method of transmitting the order status of the group as a whole without transmitting the status of each of the four separate orders.

Use Case 2: Inheritance of order status

Cancellation/discontinuation/hold order control events:

This logic implies the normal execution of the referenced predecessor order. Thus a cancel (or discontinuation or hold) of a predecessor order implies the cancellation (or discontinuation or hold) of all subsequent orders in the chain.

If the referenced order has been canceled (or discontinued or held), the current order inherits that same status.

In the case of hold, the removal of the hold of the predecessor implies a removal of the hold for the given order (which can then be executed according to the specification in the 10th component).