The RQ1 (Requisition Detail-1) segment supplements RQD by carrying the commercial attributes of a non-stock requisition line: anticipated price, manufacturer identifier and catalog reference, vendor identifier and catalog reference, taxability flag, and substitution allowance. Where RQD describes what and how much is being requested, RQ1 describes from whom, at what price, and under what substitution rules.
Purpose
RQ1 exists so that a non-stock requisition can travel with the supplier-facing detail that materials management and finance systems need without polluting the clinical detail in RQD. Common uses:
- Communicating the anticipated unit or extended price of a special-order item so that purchase-order generation can proceed without manual lookup.
- Identifying both the manufacturer and the distributor (vendor), each with their own catalog code, so the receiver can validate against both supply chains.
- Flagging whether the line is taxable, which drives downstream financial postings.
- Declaring whether substitutions are allowed, so the vendor knows whether it may ship an equivalent product.
Used in
RQ1 appears inside the order detail group of non-stock supply-requisition order messages, immediately after the RQD it qualifies:
- General order (ORM^O01) — order detail group when requisitioning a non-stock item.
- General clinical order (OMG^O19) — order detail group when the order is a non-stock item rather than a service.
- Order response messages that echo the original requisition detail (ORR^O02, ORG^O20).
RQ1 is never used in isolation; it is the supplementary sibling of an RQD.
Field-by-field reference
The table below lists every RQ1 field defined in HL7 v2.5.1, as published in the HAPI v2.5.1 javadoc. Data types link to their dedicated reference pages. Required (Req) values reflect HL7's optionality (R = required, O = optional). Repeat is Y where the javadoc shows the field as repeating, otherwise "—". Table # is shown only where a well-established HL7 user-defined or HL7-defined table applies.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| RQ1-1 | Anticipated Price | st | — | R | — | — | Expected unit or extended price for the line |
| RQ1-2 | Manufacturer Identifier | ce | — | O | — | — | Coded identifier of the manufacturer |
| RQ1-3 | Manufacturer's Catalog | st | — | O | — | — | Manufacturer's catalog number for the item |
| RQ1-4 | Vendor ID | ce | — | O | — | — | Coded identifier of the supplying vendor |
| RQ1-5 | Vendor Catalog | st | — | O | — | — | Vendor's catalog number for the item |
| RQ1-6 | Taxable | id | — | O | — | — | Indicates whether the line is taxable (Y/N) |
| RQ1-7 | Substitute Allowed | id | — | O | — | — | Indicates whether substitution is permitted (Y/N) |
Most-used fields
- RQ1-1 Anticipated Price — the only required field; downstream finance systems use it to validate purchase-order totals before they are released.
- RQ1-2 Manufacturer Identifier and RQ1-3 Manufacturer's Catalog — together they unambiguously identify the product at its source, regardless of which distributor fulfills it.
- RQ1-4 Vendor ID and RQ1-5 Vendor Catalog — together they identify the distributor and the line item in their catalog, driving routing of the purchase order.
- RQ1-7 Substitute Allowed — a critical clinical-safety flag; some items must not be substituted even when an equivalent is cheaper or in stock.
Version differences (2.3 to 2.8.2)
- HL7 v2.3 / v2.3.1 — RQ1 is defined with the same seven fields. Anticipated Price is ST, which is unusual for a price and reflects v2.3's lighter typing.
- HL7 v2.4 — field set unchanged; documentation clarifies the RQD/RQ1 pairing inside the order detail group.
- HL7 v2.5 / v2.5.1 — the version documented here. ST is retained for RQ1-1 for backward compatibility.
- HL7 v2.6 — some implementations migrate the coded fields (RQ1-2, RQ1-4) from CE to CWE, but the base standard retains CE.
- HL7 v2.7 / v2.7.1 — coded fields commonly profile to CWE; RQ1-6 and RQ1-7 continue to use HL7 table 0136 (Yes/No Indicator) semantics.
- HL7 v2.8 / v2.8.1 / v2.8.2 — field set is stable; the long-standing oddity of RQ1-1 being ST rather than a money/numeric type persists.
Common mistakes
- Sending RQ1 without a preceding RQD. RQ1 is supplementary detail; it must follow the RQD it qualifies.
- Populating RQ1-1 (Anticipated Price) with a currency-prefixed string ("$12.50") that downstream systems cannot parse. The field is ST, but receivers typically expect a bare decimal.
- Using RQ1-6 / RQ1-7 with values other than Y or N (for example "Yes", "TRUE", or "1"). Both fields are ID values bound to HL7 table 0136.
- Sending the same identifier in RQ1-2 and RQ1-4 because the manufacturer and the vendor happen to be the same organisation, then failing to populate both catalog numbers.
- Confusing RQ1 with RQD: RQ1 carries commercial detail, not clinical/quantity detail.
- Treating RQ1-1 as the extended (line total) price in one direction of an interface and the unit price in the other, leading to silent financial drift.
Examples
Minimal RQ1
RQ1|12.50
Fully populated RQ1
RQ1|12.50|MFG-MEDLINE^Medline Industries^L|MED-7F-IV|VENDORX^VendorX Distribution^L|VX-IV-7F-100|N|Y
Annotated breakdown
RQ1 Segment ID — Requisition Detail-1
|12.50 RQ1-1 Anticipated Price (ST) — unit price 12.50
|MFG-MEDLINE^... RQ1-2 Manufacturer Identifier (CE)
|MED-7F-IV RQ1-3 Manufacturer's Catalog (ST)
|VENDORX^... RQ1-4 Vendor ID (CE)
|VX-IV-7F-100 RQ1-5 Vendor Catalog (ST)
|N RQ1-6 Taxable (ID, table 0136) — not taxable
|Y RQ1-7 Substitute Allowed (ID, table 0136) — yes
In-context excerpt — OMG^O19 non-stock requisition
MSH|^~&|ERP|HOSP|MM|VENDORX|20260610114500||OMG^O19^OMG_O19|MSG000781|P|2.5.1
PID|1||MRN0091^^^HOSP^MR||Doe^Jane^M||19710204|F
ORC|NW|REQ-2026-0781|||SC||||20260610114500|||DRBROWN^Brown^Eleanor^^^^MD
RQD|1|IV-TUBING-7F^IV Tubing 7F^L||HOSP-9911^IV Tubing 7Fr^HOSP|10|EA^Each^UCUM|CC4490^ICU-Supply^L|6022^Med-Surg Supplies^L|ICU-N04^ICU North Stockroom^L|20260618
RQ1|12.50|MFG-MEDLINE^Medline Industries^L|MED-7F-IV|VENDORX^VendorX Distribution^L|VX-IV-7F-100|N|Y
In-context excerpt — multi-line ORM^O01 requisition
MSH|^~&|ERP|HOSP|MM|VENDORX|20260610115300||ORM^O01^ORM_O01|MSG000782|P|2.5.1
PID|1||MRN0091^^^HOSP^MR||Doe^Jane^M||19710204|F
ORC|NW|REQ-2026-0782|||SC||||20260610115300|||DRBROWN^Brown^Eleanor^^^^MD
RQD|1|GLOVES-NIT-M^Nitrile Gloves M^L|||5|BX^Box^UCUM|CC4490^ICU-Supply^L|6022^Med-Surg Supplies^L|ICU-N04^ICU North Stockroom^L|20260615
RQ1|8.75|MFG-CARDINAL^Cardinal Health^L|CH-NIT-M-100|VENDORX^VendorX Distribution^L|VX-NIT-M|N|Y
RQD|2|GOWN-ISO-L^Isolation Gown L^L|||25|EA^Each^UCUM|CC4490^ICU-Supply^L|6022^Med-Surg Supplies^L|ICU-N04^ICU North Stockroom^L|20260615
RQ1|1.20|MFG-HALYARD^Halyard Health^L|HAL-GOWN-L|VENDORX^VendorX Distribution^L|VX-GOWN-L|N|N
FHIR mapping
There is no segment-level ConceptMap published in the HL7 v2-to-FHIR Implementation Guide for RQ1. Conceptually, RQ1 lines map to extensions or qualifying attributes on a FHIR SupplyRequest line that is also derived from the paired RQD:
- RQ1-1 → an
extensioncarrying the anticipated price (FHIRMoney). - RQ1-2 / RQ1-3 → manufacturer reference and catalog code.
- RQ1-4 / RQ1-5 →
SupplyRequest.supplier(or an order-level supplier reference) and the supplier's catalog code. - RQ1-6 → a taxability extension on the line.
- RQ1-7 →
SupplyRequest.parameteror a substitution-allowed extension.
These mappings are conceptual; bridges typically need profile-specific extensions because FHIR's SupplyRequest does not natively carry per-line commercial detail in the same shape v2 does.
Engine considerations
- Pairing with RQD — engines should validate that every RQ1 has an immediately preceding RQD in the same order group and refuse to forward orphan RQ1 segments.
- Price formatting — RQ1-1 is ST. Engines should validate it parses as a decimal and normalize formatting (no currency symbols, no thousand separators) before persistence.
- Yes/No coding — RQ1-6 and RQ1-7 must be coerced to HL7 table 0136 ("Y" / "N"). Engines should reject or normalize variants such as "Yes", "1", or "true".
- Manufacturer vs vendor — engines should not collapse RQ1-2 into RQ1-4 when both happen to reference the same organisation. The distinction is semantically meaningful even when the values match.
- Substitution policy — RQ1-7 should be propagated downstream as a first-class flag rather than buried in free-text notes; missing values should default conservatively to "N" rather than "Y".
How Vorro parses and produces RQ1
Vorro's HL7 v2 engine treats RQ1 as the commercial twin of RQD:
- On inbound parsing, RQ1 is bound to the immediately preceding RQD; orphan RQ1 segments are quarantined with a clear validation message rather than silently dropped.
- RQ1-1 is parsed as a decimal with strict locale-independent rules and emitted into the canonical line model as a typed
Moneyvalue with a configurable currency. - RQ1-2 and RQ1-4 are validated against the configured manufacturer and vendor registries; unknown codes produce structured warnings without blocking the line.
- RQ1-6 and RQ1-7 are normalized to canonical booleans on the way in and serialized back to "Y"/"N" on the way out, with a configurable default for RQ1-7 (factory default: "N").
- On outbound generation, Vorro guarantees that RQ1 is always emitted directly after its parent RQD, even when downstream systems request reordering, to preserve standards conformance.
