Release 5 Preview #1

This page is part of the FHIR Specification (v4.2.0: R5 Preview #1). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R4 R3

V2-0119.vs.xml

Vocabulary Work GroupMaturity Level: N/AStandards Status: Informative

Raw XML (canonical form + also see XML Format Specification)

FHIR Value set/code system definition for HL7 v2 table 0119 ( ORDER CONTROL)

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

<ValueSet xmlns="http://hl7.org/fhir">
  <id value="v2-0119"/> 
  <meta> 
    <profile value="http://hl7.org/fhir/StructureDefinition/shareablevalueset"/> 
  </meta> 
  <language value="en"/> 
  <text> 
    <status value="additional"/> 
    <div xmlns="http://www.w3.org/1999/xhtml">
      <p> Order Control Codes</p> 

      <table class="grid">
        <tr> 
          <td> 
            <b> Code</b> 
          </td> 
          <td> 
            <b> Description</b> 
          </td> 
          <td> 
            <b> Comment</b> 
          </td> 
          <td> 
            <b> Version</b> 
          </td> 
        </tr> 
        <tr> 
          <td> AF
            <a name="AF"> </a> 
          </td> 
          <td> Order/service refill request approval</td> 
          <td> Placer Applications.
AF is a response to RF where the placer authorizing a refill or quantity of refills.</td> 
          <td> added v2.3</td> 
        </tr> 
        <tr> 
          <td> CA
            <a name="CA"> </a> 
          </td> 
          <td> Cancel order/service request</td> 
          <td> Placer or Filler Applications.
A cancellation is a request by the placer for the filler, or the filler to the placer,
               not to do a previously ordered service. Confirmation of the cancellation request is provided
               by the filler or placer, e.g., a message with an ORC-1-order control value of CR.
Typical responses include, but are not limited to, CR – Cancelled as requested, UC – Unable
               to Cancel.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> CH
            <a name="CH"> </a> 
          </td> 
          <td> Child order/service</td> 
          <td> Placer or Filler Applications.
Used in conjunction with the PA - Parent order control code. Refer to PA order control
               code for discussion.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> CN
            <a name="CN"> </a> 
          </td> 
          <td> Combined result</td> 
          <td> Filler Applications.
The combined result code provides a mechanism to transmit results that are associated
               with two or more orders. This situation occurs commonly in radiology reports when the
               radiologist dictates a single report for two or more exams represented as two or more
               orders. For example, knee and hand films for a rheumatoid arthritis patient might generate
               a single dictation on the part of the radiologist.
When such results are reported the CN code replaces the RE code in all but the last ORC,
               and the results follow the last ORC and its OBR. An example follows of a single report
               following three ORCs:
MSH|...&lt;cr&gt;
PID|...&lt;cr&gt;
ORC|CN|...&lt;cr&gt;
OBR|1|A4461XA^HIS|81641^RAD|73666^Bilateral Feet|...&lt;cr&gt;
ORC|CN|...&lt;cr&gt;
OBR|2|A4461XB^HIS|81642^RAD|73642^Bilateral Hand PA|...&lt;cr&gt;
ORC|RE|...&lt;cr&gt;
OBR|3|A4461XC^HIS|81643^RAD|73916^Bilateral Knees|...&lt;cr&gt;
OBX|1|CE|73916&amp;IMP|1|Radiologist’s Impression|...&lt;cr&gt;
OBX|2|CE|73642&amp;IMP|1|Radiologist’s Impression|...&lt;cr&gt;
OBX|3|FT|73642&amp;GDT|1|Description|...&lt;cr&gt;</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> CP
            <a name="CP"> </a> 
          </td> 
          <td> Cancel process step</td> 
          <td> Filler Applications.
The control code CP – Cancel process step should be used in the ORC-1 for communication
               Filler-to-Filler, e.g., LIS-to-Analyzer, to differentiate from code CA (Placer-to-Filler).
The Filler should response with an acceptance of the cancellation using ORC-1 = CR and
               ORC-5 = CA.</td> 
          <td> added v2.8</td> 
        </tr> 
        <tr> 
          <td> CR
            <a name="CR"> </a> 
          </td> 
          <td> Canceled as requested</td> 
          <td> Filler or Placer Applications.
A response by the filler or placer application that a request to cancel (CA by the placer
               application) was performed successfully.</td> 
          <td> added v2.2</td> 
        </tr> 
        <tr> 
          <td> DC
            <a name="DC"> </a> 
          </td> 
          <td> Discontinue order/service request</td> 
          <td> Placer or Filler Applications.
A request by the placer for the filler, or the filler to the placer,  to discontinue a
               previously requested service. The differentiation between discontinue and cancel is that
               discontinue effects the order/service and all future occurrences, cancel refers to just
               the present action. 
Typical responses include, but are not limited to, CR – Cancelled as requested, UC – Unable
               to Cancel.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> DE
            <a name="DE"> </a> 
          </td> 
          <td> Data errors</td> 
          <td> Placer or Filler Applications.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> DF
            <a name="DF"> </a> 
          </td> 
          <td> Order/service refill request denied</td> 
          <td> Placer Applications.
In response to a Filler application requesting refill authorization (RF), DF indicates
               that the placer does not authorize refills for the order. ORC-16 Order Control Code reason
               may be used to indicate the reason for the request denial. Some suggested values include:
AA  Patient unknown to the provider
AB  Patient never under provider care
AC  Patient no longer under provider care
AD  Patient has requested refill too soon
AE  Medication never prescribed for the patient
AF  Patient should contact provider first
AG  Refill not appropriate
Note that these values originate from the NCPDP SCRIPT Response Segment Code List Qualifiers.
               Materials Reproduced with the consent of ©National Council for Prescription Drug Programs,
               Inc. 1988, 1992, 2002 NCPDP.</td> 
          <td> added v2.3</td> 
        </tr> 
        <tr> 
          <td> DR
            <a name="DR"> </a> 
          </td> 
          <td> Discontinued as requested</td> 
          <td> Filler or Placer Applications.
The filler or placer, in response to a request to discontinue (DC from the placer or filler
               application), has discontinued the order/service.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> FU
            <a name="FU"> </a> 
          </td> 
          <td> Order/service refilled, unsolicited</td> 
          <td> Filler Applications.
FU notifies the placer that the filler issued a refill for the order at the patient's
               request.</td> 
          <td> added v2.3</td> 
        </tr> 
        <tr> 
          <td> HD
            <a name="HD"> </a> 
          </td> 
          <td> Hold order request</td> 
          <td> Placer Applications.
Typical responses include, but are not limited to, CR - Cancelled as requested, UC - Unable
               to Cancel.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> HR
            <a name="HR"> </a> 
          </td> 
          <td> On hold as requested</td> 
          <td> Filler Applications.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> LI
            <a name="LI"> </a> 
          </td> 
          <td> Link order/service to patient care problem or goal</td> 
          <td> Placer or Filler Applications.
Refer to Chapter 12 Patient Care for complete discussion.</td> 
          <td> added v2.3.1</td> 
        </tr> 
        <tr> 
          <td> MC
            <a name="MC"> </a> 
          </td> 
          <td> Miscellaneous Charge - not associated with an order</td> 
          <td> applies to DFT^P03^DFT_P03 and DFT^P11^DFT_P11</td> 
          <td> added v2.6</td> 
        </tr> 
        <tr> 
          <td> NA
            <a name="NA"> </a> 
          </td> 
          <td> Number assigned</td> 
          <td> Placer Applications.
There are three circumstances that involve requesting an order number (ORC-2-placer order
               number or ORC-3-filler order number): 

(1) When the filler application needs to request an ORC-3-filler order number from a centralized
               application (e.g., HIS).
SN – The send order number code provides a mechanism for the filler to request an ORC-3-filler
               order number from some centralized application (called “other� in the table below), such
               as a central HIS, by sending an ORM message containing an ORC-1-order control value of
               SN. This ORC has a null ORC-3-filler order number and an ORC-2-placer order number created
               by the filler application when the filler originates the order.

The order (SN type) message can be acknowledged by either one of two methods:
a) By an order application acknowledgement message containing an ORC-1-order control value
               of OK. Then an unsolicited order message can be sent at a future time, containing an ORC
               with ORC-1-order control value of NA to provide the actual number assigned.

b) By an order acknowledgement message containing an ORC-1-order control value of NA as
               described below.

NA – The number assigned code allows the “other� application to notify the filler application
               of the newly-assigned filler order number. ORC-1-order control contains value of NA, ORC-2-placer
               order number (from the ORC with the SN value), and the newly-assigned filler order number.
               
Code  From  ORC-2-Placer Order Number  ORC-3-Filler Order Number
SN  filler application  placer order number^filler application ID  Null
NA  other application  placer order number^filler application ID  filler order number^filler
               application ID
Note: Both the placer order number and the filler order number have the filler’s application
               ID

(2) When the filler application needs to request an ORC-2-placer order number from some
               other application (e.g., Order Entry).

SN – The send order number code provides a mechanism for the filler application to request
               an ORC-2-placer order number from another application (called “other� in the table below)
               by sending an order message containing an ORC-1-order control value of SN. This ORC has
               a null ORC-2-placer order number and an ORC-3-filler order number created by the filler
               application when the filler originates the order. 

The order (SN type) message can be acknowledged by two methods:
a) By an order application acknowledgement message containing an ORC-1-order control value
               of OK. Then an unsolicited order message can be sent at a future time, containing an ORC-1-order
               control value of NA to provide the actual number assigned.
 
b) By an order acknowledgement message containing an ORC-1-order control value of NA as
               described below.
NA – The number assigned code allows the “other� application to notify the filler application
               of the newly-assigned ORC-2-placer order number. The ORC contains an ORC-1-order control
               value of NA, the newly-assigned ORC-2-placer order number, and the ORC-3-filler order
               number (from the ORC with the SN value).
Code  From  ORC-2-Placer Order Number  ORC-3-Filler Order Number
SN  filler application  null  filler order number^filler application ID
NA  other application  placer order number^placer application ID  filler order number^filler
               application ID
Note: The new ORC-2-placer order number has the placer’s application ID

(3) When an application (not the filler application) wants to assign an ORC-3-filler order
               number for a new order.
NW – When the application creating an order (not the filler application) wants to assign
               a filler order number for a new order.
or 
RO – (RO following an RP). In this case, the “other� application completes ORC-3-filler
               order number, using the filler application ID as the second component of the filler order
               number.
Code  From  ORC-2-Placer Order Number  ORC-3-Filler Order Number
NW or RO  Other application to filler application  placer order number^placer application
               ID  filler order number^filler application ID</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> NR
            <a name="NR"> </a> 
          </td> 
          <td> Notification Received</td> 
          <td/>  
          <td> added v2.9</td> 
        </tr> 
        <tr> 
          <td> NW
            <a name="NW"> </a> 
          </td> 
          <td> New order/service</td> 
          <td> Placer Applications.
See comments for NA - Number Assigned.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> OC
            <a name="OC"> </a> 
          </td> 
          <td> Order/service canceled</td> 
          <td> Filler Applications.</td> 
          <td> added v2.2</td> 
        </tr> 
        <tr> 
          <td> OD
            <a name="OD"> </a> 
          </td> 
          <td> Order/service discontinued</td> 
          <td> Filler Applications.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> OE
            <a name="OE"> </a> 
          </td> 
          <td> Order/service released</td> 
          <td> Filler Applications.</td> 
          <td> added v2.3</td> 
        </tr> 
        <tr> 
          <td> OF
            <a name="OF"> </a> 
          </td> 
          <td> Order/service refilled as requested</td> 
          <td> Filler Applications.
OF directly responds to the placer system's request for a refill.</td> 
          <td> added v2.3</td> 
        </tr> 
        <tr> 
          <td> OH
            <a name="OH"> </a> 
          </td> 
          <td> Order/service held</td> 
          <td> Filler Applications.</td> 
          <td> added v2.2</td> 
        </tr> 
        <tr> 
          <td> OK
            <a name="OK"> </a> 
          </td> 
          <td> Order/service accepted &amp; OK</td> 
          <td> Filler Applications.
See comments for NA - Number Assigned.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> OP
            <a name="OP"> </a> 
          </td> 
          <td> Notification of order for outside dispense</td> 
          <td> Placer Applications.
These order control codes are used to communicate an order between systems where the order
               is intended for informational purposes. For example, an order that will be performed by
               a vendor outside the enterprise of communicating systems. The communicating systems may
               need to maintain information relative to the order for clinical continuity, but no actions
               to perform the ordered service are intended.
OP represents an informational version of NW, PY represents the informational-only version
               of RO. NW and RO table notes also apply to OP and PY, respectively.</td> 
          <td> added v2.5</td> 
        </tr> 
        <tr> 
          <td> OR
            <a name="OR"> </a> 
          </td> 
          <td> Released as requested</td> 
          <td> Filler Applications.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> PA
            <a name="PA"> </a> 
          </td> 
          <td> Parent order/service</td> 
          <td> Filler Applications.
The parent (PA) and child (CH) order control codes allow the spawning of “child� orders
               from a “parent� order without changing the parent (original order). One or more ORC segments
               with an ORC-1-order control value of PA are followed by one or more ORC segments with
               an ORC-1-order control value of CH. Whether OBR segments must be present is determined
               by the value of ORC-6-response flag. 

For example, suppose that a microbiology culture produced two organisms and corresponding
               susceptibility reports. Then the sequence of segments would be as follows: (see figure
               4-4)

The assignment of placer order numbers in the parent-child paradigm depends on whether
               the placer or filler creates the child order and in the latter case, on whether the placer
               supports the SN/NA transaction. If the placer creates the child orders it will assign
               their placer order numbers according to its usual procedures. If the filler creates the
               child orders there are two possibilities: each child will inherit the placer order number
               of its parent, or the filler will use the SN/NA transaction to request that the placer
               assign a placer order number. In either case, the filler application creates the filler
               order numbers of the children according to its usual procedures.

Whenever a child order is transmitted in a message the ORC segment’s ORC-8-parent is valued
               with the parent’s filler order number (if originating from the filler) and with the parent’s
               placer order number (if originating from the filler or if originating from the placer).
               

The parent child mechanism can be used to “expand� a parent order (e.g., an order for
               three EKGs on successive mornings).</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> PR
            <a name="PR"> </a> 
          </td> 
          <td> Previous Results with new order/service</td> 
          <td> Placer Applications.
PR indicates that this ORC is part of an ORU structure containing previous observation,
               which is embedded in the order.

At least two main use cases require that the complete results of the previous observations
               be transmitted with the order. 

•  Diagnostic laboratories referring tests to another lab for either confirmation of results
               (HIV, etc.) or due to not being equipped to do the tests (genetic testing, etc.). 

•  Diagnostic laboratories sending test results to Knowledge Bases for the automated generation
               of diagnostic comments for inclusion into the lab report.</td> 
          <td> added v2.4</td> 
        </tr> 
        <tr> 
          <td> PY
            <a name="PY"> </a> 
          </td> 
          <td> Notification of replacement order for outside dispense</td> 
          <td> Placer Applications.
See comments for OP - Notification of order for outside dispense.</td> 
          <td> added v2.5</td> 
        </tr> 
        <tr> 
          <td> RA
            <a name="RA"> </a> 
          </td> 
          <td> Recommendation Accepted</td> 
          <td/>  
          <td> added v2.9</td> 
        </tr> 
        <tr> 
          <td> RC
            <a name="RC"> </a> 
          </td> 
          <td> Recommended Change</td> 
          <td/>  
          <td> added v2.9</td> 
        </tr> 
        <tr> 
          <td> RD
            <a name="RD"> </a> 
          </td> 
          <td> Recommendation Declined</td> 
          <td/>  
          <td> added v2.9</td> 
        </tr> 
        <tr> 
          <td> RE
            <a name="RE"> </a> 
          </td> 
          <td> Observations/Performed Service to follow</td> 
          <td> Placer or Filler Applications.
The observations-to-follow code is used to transmit patient-specific information with
               an order. An order detail segment (e.g., OBR) can be followed by one or more observation
               segments (OBX). Any observation that can be transmitted in an ORU message can be transmitted
               with this mechanism. When results are transmitted with an order, the results should immediately
               follow the order or orders that they support.

The following example shows the sequence of segments for three Pharmacy orders. It illustrates
               the use of the RE code:
Segment  Order Control  Comment
MSH    
PID    
ORC  NW  First new order
RXO    First order segment
    
ORC  NW  2nd new order
RXO    2nd order segment
[ORC  RE  Patient-specific observation, optional in V 2.2
 OBR]    Observation OBR, optional in V 2.2
OBX    An observation segment
OBX    Another observation segment
OBX    Another observation segment
OBX    Another observation segment
    
ORC  NW  3rd order
RXO    3rd order segment

In this version of HL7, results can be transmitted with an order as one or more OBX segments
               without the necessity of including the ORC and OBR segments.

Observations can be transmitted in an ORU message without using an ORC. There are times
               when it is necessary to transmit information not included in the OBR segments of the ORU
               message. In this case, it is recommended that the ORC be included in the ORU message.

The order control value of RE is required only in ORM messages to indicate that an order
               is followed by observation results (OBX). The RE code is not necessary in the ORU message
               because it is expected that the OBR segments can be followed by observation results (OBX).</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> RF
            <a name="RF"> </a> 
          </td> 
          <td> Refill order/service request</td> 
          <td> Placer or Filler Applications.
RF accommodates requests by either the filler or the placer. The filler may be requesting
               refill authorization from the placer. A placer system may be requesting a refill to be
               done by the filler system.

Typical responses include, but are not limited to: For a Filler request AF – Order/service
               refill request approval, DF – Order/service refill request denied; for a Placer request
               RE – Observations/Performed Service to follow, UF – Unable to refill.</td> 
          <td> added v2.3</td> 
        </tr> 
        <tr> 
          <td> RL
            <a name="RL"> </a> 
          </td> 
          <td> Release previous hold</td> 
          <td> Placer Applications.</td> 
          <td> added v2.2</td> 
        </tr> 
        <tr> 
          <td> RO
            <a name="RO"> </a> 
          </td> 
          <td> Replacement order</td> 
          <td> Placer or Filler Applications.
A replacement is the substitution of one or more orders for one or more previously ordered
               services.

The replaced orders are treated as though they were canceled. If and when an ordered service
               can be replaced are local site-specific determinations.

Use the parent/child order control codes if the site specifies that the original order
               must remain intact. Do not use the replacement codes under this circumstance. 

For each order to be replaced, use an ORC-1-order control value of RP (request for a replacement
               going to a filler) or RU (an unsolicited replacement created by the filler) used by the
               filler to notify the placer and/or other systems). By local agreement, the ORC segment
               (with RP or RU) may be followed by its original order detail segment. The ORC segments
               (with RP or RU) must be followed by an ORC segment with an ORC-1-order control value of
               RO (indicating the replacement order). By local agreement, the ORC with the RO value may
               be followed by an order detail segment. 

For example, suppose that an ancillary application were replacing two OBR orders with
               three different orders. The sequence of segments would be as follows:

Seg  Order Control  Comment
ORC  RU  1st replaced ORC
OBR    1st replaced order’s detail segment
    
ORC  RU  2nd replaced ORC
OBR    2nd replaced order’s detail segment
    
ORC  RO  1st replacement ORC
OBR    1st replacement order’s detail segment
    
ORC  RO  2nd replacement ORC
OBR    2nd replacement order’s detail segment
    
ORC  RO  3rd replacement ORC
OBR    3rd replacement order’s detail segment

Whether the OBR segments must be present is determined by the value of ORC-6-response
               flag.

The described replacement method will handle all possible cases of replacement: one into
               one, many into one, one into many, and many into many. If the placer sent this request
               to the filler with two RPs, and this was a response back from the filler to the placer,
               the two RUs (replaced unsolicited) would be two RQs (replaced as requested). (see figure
               4-3)

Seg  Order Control  Comment
ORC  RQ  1st replaced ORC
OBR    1st replaced order’s detail segment
    
ORC  RQ  2nd replaced ORC
OBR    2nd replaced order’s detail segment
    
ORC  RO  1st replacement ORC
OBR    1st replacement order’s detail segment
    
ORC  RO  2nd replacement ORC
OBR    2nd replacement order’s detail segment
    
ORC  RO  3rd replacement ORC
OBR    3rd replacement order’s detail segment

The replacement order code is sent by the filler application to another application indicating
               the exact replacement ordered service. It is used with the RP and RU order control codes
               as described above.

The rules for the order numbers in ORC segments with an order control value of RO are
               determined by the replacement type (RP or RU).

In the case of the RU type (i.e., unsolicited replacement by the filler), the filler order
               number is generated as usual by the filler application. The placer order number is identical
               to the placer order number of the first transmitted ORC with an order control value of
               RU.

In the case of the RP type (i.e., a replacement request from another application to the
               filler), the placer order number is generated by the placer application using the procedure
               for new orders. The filler order number is generated by the filler application using the
               procedure identical for new orders.

If a replacement sequence is used in an ORU message (i.e., during results reporting),
               the following are the recommended segments to be used for the replacement orders:

ORC with an order control value of RO.

Any OBR segments (can be replaced by any order detail segments).

Optionally followed by observation result segments (OBX)
NTE segments can appear after the OBR (or any order detail segment) or after an OBX segment
               as in a regular ORU message.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> RP
            <a name="RP"> </a> 
          </td> 
          <td> Order/service replace request</td> 
          <td> Placer Applications.
A replacement is the substitution of one or more orders for one or more previously ordered
               services. See comment 1 on RO – Replacement Order for further discussion.

The order replace request code permits the order filler to replace one or more new orders
               with one or more new orders, at the request of the placer application.

The rules for the order numbers in ORC segments with an order control value of RO are
               determined by the replacement type (RP or RU).

In the case of the RU type (i.e., unsolicited replacement by the filler), the filler order
               number is generated as usual by the filler application. The placer order number is identical
               to the placer order number of the first transmitted ORC with an order control value of
               RU.

In the case of the RP type (i.e., a replacement request from another application to the
               filler), the placer order number is generated by the placer application using the procedure
               for new orders. The filler order number is generated by the filler application using the
               procedure identical for new orders.

If a replacement sequence is used in an ORU message (i.e., during results reporting),
               the following are the recommended segments to be used for the replacement orders:

a) ORC with an order control value of RO

b) Any OBR segments (can be replaced by any order detail segments)

c) Optionally followed by observation result segments (OBX)

d) NTE segments can appear after the OBR (or any order detail segment) or after an OBX
               segment as in a regular ORU message</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> RQ
            <a name="RQ"> </a> 
          </td> 
          <td> Replaced as requested</td> 
          <td> Filler Applications.
A replacement is the substitution of one or more orders for one or more previously ordered
               services. See comment 1 on RO – Replacement Order for further discussion.

The order replace request code permits the order filler to replace one or more new orders
               with one or more new orders, at the request of the placer application.

The replacement order code is sent by the filler application to another application indicating
               the exact replacement ordered service. It is used with the RP and RU order control codes
               as described above.

The rules for the order numbers in ORC segments with an order control value of RO are
               determined by the replacement type (RP or RU).

In the case of the RU type (i.e., unsolicited replacement by the filler), the filler order
               number is generated as usual by the filler application. The placer order number is identical
               to the placer order number of the first transmitted ORC with an order control value of
               RU.

In the case of the RP type (i.e., a replacement request from another application to the
               filler), the placer order number is generated by the placer application using the procedure
               for new orders. The filler order number is generated by the filler application using the
               procedure identical for new orders.

If a replacement sequence is used in an ORU message (i.e., during results reporting),
               the following are the recommended segments to be used for the replacement orders:

a) ORC with an order control value of RO

b) Any OBR segments (can be replaced by any order detail segments)

c) Optionally followed by observation result segments (OBX)

d) NTE segments can appear after the OBR (or any order detail segment) or after an OBX
               segment as in a regular ORU message</td> 
          <td> added v2.2</td> 
        </tr> 
        <tr> 
          <td> RR
            <a name="RR"> </a> 
          </td> 
          <td> Request received</td> 
          <td> Placer or Filler Applications.
Left in for backward compatibility. In the current version it is equivalent to an accept
               acknowledgment. The request-received code indicates that an order message has been received
               and will be processed later. The order has not yet undergone the processing that would
               permit a more exact response.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> RU
            <a name="RU"> </a> 
          </td> 
          <td> Replaced unsolicited</td> 
          <td> Filler Applications.
A replacement is the substitution of one or more orders for one or more previously ordered
               services. See comment 1 on RO – Replacement Order for further discussion.

The unsolicited replacement code permits the filler application to notify another application
               without being requested from the placer application.

The rules for the order numbers in ORC segments with an order control value of RO are
               determined by the replacement type (RP or RU).

In the case of the RU type (i.e., unsolicited replacement by the filler), the filler order
               number is generated as usual by the filler application. The placer order number is identical
               to the placer order number of the first transmitted ORC with an order control value of
               RU.

In the case of the RP type (i.e., a replacement request from another application to the
               filler), the placer order number is generated by the placer application using the procedure
               for new orders. The filler order number is generated by the filler application using the
               procedure identical for new orders.

If a replacement sequence is used in an ORU message (i.e., during results reporting),
               the following are the recommended segments to be used for the replacement orders:

a) ORC with an order control value of RO

b) Any OBR segments (can be replaced by any order detail segments)

c) Optionally followed by observation result segments (OBX)

d) NTE segments can appear after the OBR (or any order detail segment) or after an OBX
               segment as in a regular ORU message</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> SC
            <a name="SC"> </a> 
          </td> 
          <td> Status changed</td> 
          <td> Placer or Filler Applications.</td> 
          <td> added v2.2</td> 
        </tr> 
        <tr> 
          <td> SN
            <a name="SN"> </a> 
          </td> 
          <td> Send order/service number</td> 
          <td> Placer Applications.
See comments for NA - Number Assigned.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> SQ
            <a name="SQ"> </a> 
          </td> 
          <td> Supplemented as requested</td> 
          <td/>  
          <td> added v2.9</td> 
        </tr> 
        <tr> 
          <td> SR
            <a name="SR"> </a> 
          </td> 
          <td> Response to send order/service status request</td> 
          <td> Filler Applications.</td> 
          <td> added v2.2</td> 
        </tr> 
        <tr> 
          <td> SS
            <a name="SS"> </a> 
          </td> 
          <td> Send order/service status request</td> 
          <td> Placer Applications.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> SU
            <a name="SU"> </a> 
          </td> 
          <td> Supplement this order</td> 
          <td/>  
          <td> added v2.9</td> 
        </tr> 
        <tr> 
          <td> UA
            <a name="UA"> </a> 
          </td> 
          <td> Unable to accept order/service</td> 
          <td> Filler Applications.
An unable to accept code is used when a new order cannot be accepted by the filler. Possible
               reasons include requesting a prescription for a drug which the patient is allergic to
               or for an order which requires certain equipment resources which are not available such
               that the order cannot be filled. Note that this is different from the communication level
               acceptance as defined within the MSA segment.</td> 
          <td> added v2.3</td> 
        </tr> 
        <tr> 
          <td> UC
            <a name="UC"> </a> 
          </td> 
          <td> Unable to cancel</td> 
          <td> Filler or Placer Applications.
An unable-to-cancel code is used when the ordered service is at a point that it cannot
               be canceled by the placer or filler or when local rules prevent cancellation by the filler.
               The use of this code is dependent on the value of ORC-6-response flag.
If the filler initiated the request to cancel and the placer is unable to cancel while
               the filler cannot proceed with the fulfillment of that order, then the necessary communication
               to resolve the conflict is outside the scope of these messages.</td> 
          <td> added v2.2</td> 
        </tr> 
        <tr> 
          <td> UD
            <a name="UD"> </a> 
          </td> 
          <td> Unable to discontinue</td> 
          <td> Filler or Placer Applications.
An unable-to-discontinue code is used when the ordered service is at a point that it cannot
               be discontinued by the placer or filler or when local rules prevent discontinuance by
               the filler. The use of this code is dependent on the value of ORC-6-response flag.
If the filler initiated the request to discontinue and the placer is unable to discontinue
               while the filler cannot proceed with the fulfillment of that order, then the necessary
               communication to resolve the conflict is outside the scope of these messages.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> UF
            <a name="UF"> </a> 
          </td> 
          <td> Unable to refill</td> 
          <td> Filler Applications.
Negative response to RF Refill order/service request, indicating that the receiving application
               was not able to complete the refill request.</td> 
          <td> added v2.3</td> 
        </tr> 
        <tr> 
          <td> UH
            <a name="UH"> </a> 
          </td> 
          <td> Unable to put on hold</td> 
          <td> Filler Applications.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> UM
            <a name="UM"> </a> 
          </td> 
          <td> Unable to replace</td> 
          <td> Filler Applications.</td> 
          <td> added v2.2</td> 
        </tr> 
        <tr> 
          <td> UN
            <a name="UN"> </a> 
          </td> 
          <td> Unlink order/service from patient care problem or goal</td> 
          <td> Placer or Filler Applications.
Refer to Chapter 12 Patient Care for complete discussion.</td> 
          <td> added v2.3.1</td> 
        </tr> 
        <tr> 
          <td> UR
            <a name="UR"> </a> 
          </td> 
          <td> Unable to release</td> 
          <td> Filler Applications.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> UX
            <a name="UX"> </a> 
          </td> 
          <td> Unable to change</td> 
          <td> Filler Applications.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> XO
            <a name="XO"> </a> 
          </td> 
          <td> Change order/service request</td> 
          <td> Placer Applications.</td> 
          <td> added v2.2</td> 
        </tr> 
        <tr> 
          <td> XR
            <a name="XR"> </a> 
          </td> 
          <td> Changed as requested</td> 
          <td> Filler Applications.</td> 
          <td> from v2.1</td> 
        </tr> 
        <tr> 
          <td> XX
            <a name="XX"> </a> 
          </td> 
          <td> Order/service changed, unsol.</td> 
          <td> Filler Applications.</td> 
          <td> from v2.1</td> 
        </tr> 
      </table> 

    </div> 
  </text> 
  <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status">
    <valueCode value="external"/> 
  </extension> 
  <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm">
    <valueInteger value="0"/> 
  </extension> 
  <url value="http://terminology.hl7.org/ValueSet/v2-0119"/> 
  <version value="2.9"/> 
  <name value="v2.0119"/> 
  <title value="v2 ORDER CONTROL"/> 
  <status value="active"/> 
  <experimental value="false"/> 
  <publisher value="HL7, Inc"/> 
  <contact> 
    <telecom> 
      <system value="url"/> 
      <value value="http://hl7.org"/> 
    </telecom> 
  </contact> 
  <description value="FHIR Value set/code system definition for HL7 v2 table 0119 ( ORDER CONTROL)"/> 
  <immutable value="true"/> 
  <compose> 
    <include> 
      <system value="http://terminology.hl7.org/CodeSystem/v2-0119"/> 
    </include> 
  </compose> 
</ValueSet>

Usage note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of the specification.