HL7 Table HL70038: Order Status

HL70038 is the HL7-defined code table that describes the lifecycle state of an order as seen by the filler. It lives in ORC-5 Order Status on every ORM, OMG, OML, and ORU message that carries a Common Order segment, and it is the single most-inspected field when an integration engine has to decide whether a downstream system should display, hide, or replace an existing order. The table is present from HL7 v2.2 onward.

Purpose

HL70038 answers one question: where is this order right now in its filler-side lifecycle. It is set and maintained by the filler application (lab, radiology, pharmacy), not by the placer; the placer expresses intent through ORC-1 (Order Control) and ORC-25 (Order Status Modifier is reserved for v2.8+ extensions). A receiver reading ORC-5 should treat the value as the filler's authoritative statement of where the order sits — completed, in process, cancelled, on hold, or in error.

Because the table is HL7-defined, every conformant v2 receiver is expected to recognize the nine codes below without local extension. Sites that need finer-grained sub-states (e.g., "awaiting collection" vs "awaiting analysis") layer that detail in ORC-9 or in a status modifier rather than coining new HL70038 codes.

Where it's used

• ORC-5 Order Status — the canonical home of HL70038, populated on every ORM/OMG/OML/ORU that carries an order.
• OBR is sometimes mistakenly assumed to carry HL70038; OBR-25 Result Status uses a different table (HL70123). Keep the two separate.
• Some pharmacy profiles echo ORC-5 into RXO and RXE segments by reference; the canonical field remains ORC-5.

Code list

Code system OID

• OID: 2.16.840.1.113883.18.13
• Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0038

The OID resolves on the HL7 Terminology server and is the value Vorro emits in CWE.14 when a downstream profile demands OID-bound coded values for ORC-5.

HL7-defined vs user-defined

HL70038 is HL7-defined. The table number falls inside the HL7-reserved range (HL70001–HL70999), and the code set is normative — receivers must accept all nine values, and senders must not invent additional codes inside this table. Sites that need sub-statuses use a separate user-defined field (often ORC-29 Order Status Modifier or a local Z-segment) rather than extending HL70038.

Version differences

• v2.2 — Table introduced with eight values; SC (scheduled) added at the same time to accommodate radiology workflows.
• v2.3 – v2.3.1 — RP (replaced) clarified to require a populated ORC-8 (Parent) pointing at the replacement.
• v2.4 — ER (error, order not found) added so fillers could explicitly signal that the placer's order number did not resolve.
• v2.5 – v2.7 — Set frozen at nine codes.
• v2.8 – v2.8.1 — No additions, but the standard introduces ORC-29 Order Status Modifier for vendors who need richer sub-states without polluting HL70038.

Common mistakes

• Sending the display word in ORC-5 — Completed instead of CM. ORC-5 is an ID field and the code value is the two-character symbol.
• Using CA after partial results have posted. Once any work has happened the correct code is DC (discontinued); CA is reserved for cancellations before any activity.
• Treating CM as terminal in all cases. A CM order can still be amended by a subsequent ORC^XO (Replace Order) or ORC^CR (Cancel after Completion); receivers must not garbage-collect CM orders too aggressively.
• Defaulting unknown status to IP. IP is a positive statement that work is happening; if the filler does not actually know, the message should not be sent.
• Extending HL70038 locally with codes like PEND, RECV, or QUEUED. HL70038 is HL7-defined; locally extended codes break conformance and FHIR mapping. Use ORC-29 for sub-states instead.

Examples

A common ORC carrying an in-process scheduled order:

ORC|NW|PLC0001^LAB|FLR0001^LAB||SC|||||||1234^SMITH^JOHN^^^^MD

An order discontinued mid-run after partial results:

ORC|XO|PLC0001^LAB|FLR0001^LAB||DC|||||||1234^SMITH^JOHN^^^^MD

Same CM value translated to a FHIR ServiceRequest.status snippet:

{
  "resourceType": "ServiceRequest",
  "id": "FLR0001",
  "status": "completed",
  "intent": "order"
}

A CWE-typed ORC-5 (v2.7+ profile) carrying OID metadata produces a fuller FHIR Coding on the originating extension:

{
  "status": "active",
  "_status": {
    "extension": [{
      "url": "http://hl7.org/fhir/StructureDefinition/originalText",
      "valueString": "SC"
    }]
  }
}

Mapping failure example — unknown vendor code:

ORC|NW|PLC0001^LAB|FLR0001^LAB||PEND

PEND is not in HL70038. A conformant engine should route the message to a curation queue, preserve the original PEND in the audit log, and emit FHIR status: unknown rather than silently coercing it to active.

FHIR mapping

The v2-to-FHIR IG does not publish a ConceptMap for this table; the mapping below follows the obvious correspondence, collapsing the nine HL7 codes onto the seven-value FHIR request-status ValueSet:

ServiceRequest.status and MedicationRequest.status are both bound to http://hl7.org/fhir/ValueSet/request-status. Because four v2 codes (A, IP, SC) collapse to FHIR active and three (CA, DC, RP) collapse to revoked, the original HL70038 code must be preserved as an extension if the receiver needs to round-trip back to HL7 v2.

Engine considerations

• Two-character validation — ORC-5 is 1–2 characters; engines should reject longer payloads rather than truncate, since truncation of DC to D is ambiguous.
• Case sensitivity — HL70038 codes are case-sensitive uppercase; cm is not a valid code. Normalize on ingest.
• State-machine enforcement — Engines should not accept arbitrary transitions. CM → SC is almost always a sender bug; flag it rather than forward.
• CWE upgrade path — In v2.7+ profiles ORC-5 may be transmitted as CWE rather than ID, allowing OID metadata in CWE.14 (2.16.840.1.113883.18.13). Engines must handle both shapes.
• Round-trip preservation — When mapping to FHIR request-status, store the original HL70038 code as an extension so the v2 outbound channel can restore the CA/DC/RP distinction.

How Vorro handles HL70038

Vorro validates ORC-5 against the nine HL70038 codes on ingest. Values that match are forwarded to all downstream channels untouched. Values that fail validation — including lowercase variants, vendor extensions like PEND, and accidental display strings — are routed to the terminology curation queue, where they either resolve to one of the nine canonical codes (and a remap rule is created) or pass through with a soft warning so downstream systems are not silently fed bad order states.

On outbound, Vorro emits HL70038 as ID for v2.5 and earlier profiles and as CWE with CWE.14 populated for v2.7+ destinations that advertise OID-bound coded values. The original HL70038 code is always preserved when round-tripping through FHIR ServiceRequest.status.

Related pages

• ORC segment — Common Order
• HL70119 code table — Order Control Codes
• HL70217 code table — Order Priority

Sources

• HL7 Terminology — CodeSystem v2-0038 Order Status
• HL7 v2 product brief