HL7 Table HL70119: Order Control Code

HL70119 is the verb of every HL7 v2 order message. Carried in ORC-1 Order Control, it tells the receiver what the sender intends to do — submit a new order (NW), cancel an existing one (CA), discontinue (DC), hold (HD), refill (RF), replace (RP), or report on prior activity (SC, OK, UA). Without ORC-1 there is no order; without a valid HL70119 code, the receiver has no way to know whether the rest of the segment is a request, a confirmation, an unsolicited update, or an error. The table is HL7-defined, normative across v2.3 through v2.8.1, and one of the most consequential vocabularies in the entire v2 stack.

Purpose

HL70119 codes a lifecycle event, not a status. NW means "I am placing a new order"; OK means "I accepted the order you sent"; OC means "I have canceled the order"; RR means "I received your request, response to follow." A given order will pass through many ORC-1 values during its lifetime — a typical lab order goes NW → OK → SC → SC → CN or NW → CA → OC if canceled.

The table interacts closely with HL70038 Order Status (which is a state, not an event) and with the placer/filler order-number pairs in ORC-2 and ORC-3. A correct order-lifecycle implementation requires all three working together — HL70119 says what just happened, HL70038 says what the order looks like now, and the order numbers identify which order it happened to.

Where it's used

• ORC-1 Order Control — the canonical home of HL70119, populated on every ORM, OML, ORL, OMG, and ORU message.
• Indirectly referenced by acknowledgment segments and audit trails that record the most recent ORC-1 value seen for a given placer/filler number.

Code list

Code system OID

• OID: 2.16.840.1.113883.18.39
• Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0119

The OID is emitted in CWE.14 on profiles that demand OID-bound coded values. Most v2 implementations carry ORC-1 as ID, which has no OID slot — the OID matters only when the field is upgraded to CWE or when mapping to FHIR.

HL7-defined vs user-defined

HL70119 is HL7-defined. Sites must not invent local order-control codes; the lifecycle vocabulary is normative across all v2 versions and conformance-tested by HL7-defined ack rules. A new order-lifecycle concept that cannot be expressed by an existing HL70119 code is a signal that the use case belongs in a different message structure entirely (a referral, a problem-list update, a scheduling event), not a local extension of HL70119.

Version differences

• v2.2 — Initial table covering the placer/filler core: NW, OK, CA, OC, DC, OD, HD, OH, RL, OE, SC.
• v2.3 — Refill family added (RF, OF, AF, DF, UF, FU); replacement family added (RP, RO, PY, RU, UM).
• v2.3.1 — Parent/child linkage codes added (PA, CH, CN) for reflex testing and panel decomposition.
• v2.4 — Problem-list linkage (LI, UN) and status-request family (SS, SR, SN, NA) added.
• v2.5 – v2.8.1 — Set frozen; no breaking changes, only clarifications in the description column.

Common mistakes

• Sending NW for a refill. A refill request is RF, not a new order. Sending NW causes the filler to allocate a brand new order number and the prescription history breaks.
• Using CA and DC interchangeably. CA cancels an order that has not yet started; DC discontinues one already in progress. Many lab systems reject CA once a specimen has been collected and expect DC.
• Treating OK as a status. OK is an event ("I accepted this order"); the resulting status is HL70038 A (Some, but not all, results available) or IP (In process). Engines that store ORC-1 as the order's current state will get the lifecycle wrong.
• Ignoring RR. RR (Request received) is an interim ack — engines that treat it as a terminal response will hang waiting for a state that already arrived.
• Sending RP without populating ORC-8 with the prior order reference. The replacement request requires the receiver to know which order is being replaced.

Examples

A new lab order placed by the EHR:

ORC|NW|10456^EHR||GRP-2026-0610-001|||^^^20260610093000^^R||20260610093000|jsmith^Smith^Jane|^Adams^John^A
OBR|1|10456^EHR||80048^Basic Metabolic Panel^L|||20260610093000

The lab acknowledges:

ORC|OK|10456^EHR|LIS-22910^LIS|GRP-2026-0610-001||IP

The placer requests cancellation:

ORC|CA|10456^EHR|LIS-22910^LIS

The filler confirms:

ORC|CR|10456^EHR|LIS-22910^LIS||CA

Replacement order using RP:

ORC|RP|10456^EHR|LIS-22910^LIS|GRP-2026-0610-001|||^^^20260610100000^^R

Same NW event translated to FHIR ServiceRequest:

{
  "resourceType": "ServiceRequest",
  "id": "10456",
  "status": "active",
  "intent": "order",
  "code": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "24323-8",
      "display": "Basic metabolic panel"
    }]
  }
}

Mapping failure example — invented vendor code:

ORC|MOD|10456^EHR|LIS-22910^LIS

MOD (intended as "modify order") is not in HL70119; the correct verb depends on intent. A pure header change is XO only in legacy v2.2 sites; modern profiles express modifications as RP (replace request) with the new content following.

FHIR mapping

The v2-to-FHIR IG publishes ConceptMap-table-hl70119-to-request-status. The mapping is multi-target — HL70119 codes a lifecycle event, while FHIR splits the concept across ServiceRequest.status, .intent, and the replaces/basedOn references. Selected mappings:

Round-trip from FHIR back to v2 is lossy because FHIR collapses both the placer and filler verbs into one status; engines must inspect the message direction and the prior state to reconstruct the correct HL70119 code on outbound.

Engine considerations

• State machine — A conformant order-management engine implements HL70119 as a state machine, not a free lookup. Many transitions are illegal (e.g. CA after OC is already final).
• Placer vs filler perspective — Codes split cleanly into placer verbs (NW, CA, DC, HD, RL, RF, RP, RO, SS) and filler responses (OK, OC, OD, OH, OR, OF, RR, SC, UA, UC, UD, UH, UR). Engines should validate that the right party is sending each code.
• Unsolicited updates — OC, OD, OH, OE, FU, RU may arrive without a preceding request; downstream systems must accept them.
• Replacement chain — RP/RO/PY/RU build a chain via ORC-8; preserve the chain when mapping to FHIR ServiceRequest.replaces.

How Vorro handles HL70119

Vorro maintains a per-order state machine keyed on the placer/filler order-number pair. ORC-1 values are validated against HL70119 on ingest and against the current state machine position — illegal transitions (e.g. CA on an order already in OC) are routed to a curation queue with a synthetic NAK so the upstream system can investigate. Legal transitions update internal state and forward the message untouched.

On outbound FHIR, Vorro converts ORC-1 to the appropriate combination of ServiceRequest.status, .intent, and .replaces/.basedOn references, preserving the original HL70119 code in a Coding extension so the v2 outbound channel can reconstruct the correct verb for downstream subscribers.

Related pages

• ORC segment — Common Order
• OBR segment — Observation Request
• HL70038 code table — Order Status

Sources

• HL7 Terminology — CodeSystem v2-0119 Order Control Code
• HL7 v2 product brief
• HL7 v2-to-FHIR IG — ConceptMap HL70119 to request-status