HL7 Table HL70121: Response Flag

HL70121 controls how verbose the receiver's acknowledgment of an order should be. It is a small five-value HL7-defined code table that has been part of v2 since v2.2, sitting on the ORC-6 Response Flag field of every order message. The codes form a rough ladder from "say almost nothing" (N) up to "send everything you have plus replacements and parent-child relationships" (R), letting senders trade bandwidth and ack latency against the richness of what they get back.

Purpose

ORC-6 answers a single question: when you acknowledge this order, how much should you include? A pharmacy that only needs to know whether the order was accepted can request N (only the MSA segment). A revenue cycle system that wants the full echo of the order plus any replacement orders the receiver generated can request R. The flag does not change the semantics of the order itself; it only shapes the response.

Because the table is HL7-defined, every conformant receiver is expected to honor the requested verbosity. In practice many implementations ignore ORC-6 and always send the same shape of acknowledgment, which is a frequent source of integration friction.

Where it's used

ORC-6 Response Flag — the canonical and only home of HL70121, carried on every ORC segment from v2.2 onward.

Code list

Code	Display	Comment/Description
D	Also other associated segments	Acknowledgment includes the MSA segment plus other associated segments (NTE, OBR, etc.) relevant to the order.
E	Report exceptions only	Acknowledgment is sent only when an exception or error occurs; successful orders are silently accepted.
F	Same as D plus confirmations as positive notifications	Full echo including positive confirmation notifications for each component of the order.
N	Only the MSA segment is returned	Minimal acknowledgment — just MSA. The least chatty option.
R	Same as E plus replacement and parent-child	Exceptions plus any replacement orders the receiver generated and parent-child relationships between orders.

Code system OID

OID: 2.16.840.1.113883.18.40
Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0121

The OID resolves on the HL7 Terminology server and is the value Vorro emits in CWE.14 when ORC-6 is transmitted as CWE in v2.7+ profiles.

HL7-defined vs user-defined

HL70121 is HL7-defined. The table number falls inside the HL7-reserved range (HL70001–HL70999), and the code set is normative — receivers must accept all five values without local extension, and senders must not invent additional codes inside this table. Sites occasionally try to add Q (quiet) or V (verbose); these are not conformant and should be normalized onto N and F respectively.

Version differences

v2.1 — Table did not exist. Acknowledgment shape was implicit.
v2.2 — HL70121 introduced with the current five values (D, E, F, N, R).
v2.3 – v2.8.1 — Set frozen at five codes; no further additions.
v2.9 — HL70121 itself unchanged; ORC-6 may be transmitted as CWE with OID-bound metadata for profiles that adopt the CWE upgrade.

Common mistakes

Leaving ORC-6 blank and expecting the receiver to use a sensible default. There is no defined default; behavior varies wildly between vendors, so explicit N, E, D, F, or R is always safer.
Sending Y or 1 to mean "yes, acknowledge." HL70121 has no Y value; the closest concept is D or F. Vendors that pre-date HL7 conformance sometimes emit Boolean-style flags here.
Requesting F (full echo) on high-volume interfaces. Full echo on every order can multiply ack volume by an order of magnitude; E (exceptions only) is almost always the right choice for production order traffic.
Treating ORC-6 as case-insensitive. HL70121 codes are case-sensitive uppercase; n is not a valid code.
Assuming receivers honor the flag. Many production systems hardcode their ack shape and ignore ORC-6 entirely; senders should not depend on the flag for correctness, only for bandwidth tuning.

Examples

A minimal ORC requesting exceptions-only acknowledgment:

ORC|NW|ORD12345^EHR|FILL98765^PHARM|GRP777|CM|E|||20260612083000|NUR123^JONES^ANNE||PHYS456^WELBY^MARCUS

A full-echo request on a low-volume reference lab interface:

ORC|NW|ORD22222^EHR|FILL55555^LAB|GRP888|CM|F|||20260612110000|NUR789^SMITH^JOHN||PHYS456^WELBY^MARCUS

Because HL70121 has no direct FHIR equivalent, a FHIR consumer typically preserves the value as an extension on the target ServiceRequest:

{
  "resourceType": "ServiceRequest",
  "id": "ord-12345",
  "status": "active",
  "intent": "order",
  "extension": [{
    "url": "http://terminology.hl7.org/CodeSystem/v2-0121",
    "valueCoding": {
      "system": "http://terminology.hl7.org/CodeSystem/v2-0121",
      "code": "E",
      "display": "Report exceptions only"
    }
  }]
}

The acknowledgment verbosity itself maps onto FHIR's Prefer: return=minimal (analogous to N) or Prefer: return=representation (analogous to F) HTTP headers on Bundle submissions, but that is a transport-layer concept rather than a payload code.

Mapping failure example — vendor code in ORC-6:

ORC|NW|ORD99999^EHR|FILL11111^PHARM||CM|Q|||20260612

Q is not in HL70121. A conformant engine should route the message to the curation queue, preserve the original Q in the audit log, and either remap to N (the closest HL7-defined value for "quiet") or pass through with a soft warning so downstream order receivers are not silently fed an unrecognized verbosity flag.

FHIR mapping

There is no direct FHIR ValueSet for HL70121. FHIR controls response verbosity at the transport layer rather than in the payload:

HL7 v2 (HL70121)	FHIR equivalent
N	`Prefer: return=minimal` HTTP header on the submission
D	`Prefer: return=representation` on the submission
F	`Prefer: return=representation` + OperationOutcome with informational issues
E	`Prefer: return=OperationOutcome` (errors-only)
R	No direct equivalent; replacement and parent-child relationships are expressed via `basedOn` and `replaces` on the resulting `ServiceRequest` resources

Because the mapping crosses from a payload code to a transport header (and partially has no equivalent), the original HL70121 code must be preserved as an extension on the FHIR resource if the receiver needs to round-trip back to HL7 v2.

Engine considerations

Single-character validation — ORC-6 is one character; engines should reject multi-character payloads outright rather than truncate.
Case sensitivity — HL70121 codes are case-sensitive uppercase; normalize on ingest.
Receiver behavior — Many production systems ignore ORC-6 and always send the same ack shape. Engines should not block messages because the requested verbosity was not honored; they should log the discrepancy and pass through.
CWE upgrade path — In v2.7+ profiles ORC-6 may be transmitted as CWE rather than ID, allowing OID metadata in CWE.14 (2.16.840.1.113883.18.40). Engines must handle both shapes.
Round-trip preservation — When mapping to FHIR, store the original HL70121 code as an extension; the FHIR target uses a transport header that is not visible on the resource itself.

How Vorro handles HL70121

Vorro validates ORC-6 against the five HL70121 codes on ingest. Values that match are forwarded to downstream channels untouched. Values that fail validation — including lowercase variants, vendor extensions like Q or V, Boolean-style Y/1, and accidental display strings — are routed to the terminology curation queue, where a remap rule resolves them to one of the five canonical codes while preserving the original in the audit log.

On outbound, Vorro emits HL70121 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. When translating to FHIR, the original HL70121 code is preserved as an extension on the target ServiceRequest, and the engine optionally sets the corresponding Prefer header on outbound FHIR submissions so the verbosity intent survives the format change.

Sources

← Back to HL7 v2 Guide