HL7 CQ Data Type: Composite Quantity with Units

The CQ (Composite Quantity with Units) data type was introduced in HL7 v2.3 and pairs a numeric quantity with a coded unit of measure into a single field. It is the workhorse for any HL7 v2 field that needs to say "how much" without losing the unit semantics — including OBX-7 reference-range bounds, TQ1 quantity components, and dosage fields across the pharmacy/treatment segments (RXO, RXE, RXD, RXG, RXA).

Purpose

CQ exists because quantity values are useless without their units. Sending 5 in a dose field is meaningless; sending 5^mg^UCUM is a structured, machine-actionable value. CQ binds the two so that downstream systems can perform unit-aware arithmetic, conversion, and comparison without parsing free text. In v2.5 and later, the units component was upgraded from CE to CWE so that an alternate identifier (UCUM in addition to ANSI+/ISO+ legacy codes) can travel with the same value.

Component table

Source: HAPI HL7v2 v2.8.1 javadocs (CQ). Length is shown as — because v2.7+ deprecated fixed maximum lengths in favour of conformance-profile constraints.

Comp	Name	Sub-type	Length	Required	Description
CQ.1	Quantity	nm	—	R	Numeric magnitude of the measurement. May be integer or decimal; sign is permitted where the field semantics allow it.
CQ.2	Units	cwe	—	C	Coded unit of measure. Conditional: required whenever CQ.1 is populated. CWE allows a primary code (typically UCUM) and an alternate code (legacy ISO+ / ANSI+).

Most-used components

CQ.1 Quantity — the numeric value itself; this is the field downstream calculations read first.
CQ.2 Units — the coded unit; without it CQ.1 cannot be interpreted. UCUM is the strongly preferred code system in v2.7+.

Where it's used

OBX-7 Reference Range — uses CQ-style numerator/denominator structure for bounds on numeric observations.
TQ1-2 Quantity — total quantity to administer or perform across a timing schedule.
OBR-27.2 Quantity Timing components — legacy quantity-and-timing composite carries CQ pieces.
RXO-2 Requested Give Amount – Minimum / RXO-3 Maximum — minimum and maximum dose magnitude in pharmacy orders (paired with RXO-4 Units; many sites still send the composite shape).
RXE-3 / RXE-4 Give Amount – Minimum / Maximum — encoded order dosing (CQ semantics with separate fields in modern profiles).
RXD-4 Actual Dispense Amount — quantity actually dispensed.
RXG-6 Give Amount – Minimum — quantity to give per administration.
RXA-6 Administered Amount — amount actually administered in a vaccination or therapeutic message.
PRT-23 Quantity — quantity associated with a participation (e.g. supplies used).
SPM-12 Specimen Quantity — amount of specimen collected.

Version differences

HL7 v2.3 — CQ introduced with two components: Quantity (NM) and Units (CE).
HL7 v2.5 — CQ.2 promoted from CE to CWE so alternate identifiers (notably UCUM alongside legacy ISO+/ANSI+) can travel together.
HL7 v2.6 / v2.7 — no structural changes; UCUM becomes the strongly recommended primary code system for CQ.2.
HL7 v2.7.1 / v2.8 / v2.8.1 / v2.8.2 — structure stable; fixed maximum lengths deprecated in favour of conformance-profile constraints. HAPI v2.8.1 javadoc shows the two-component layout above.

Common mistakes

Sending units as plain text in CQ.2 instead of a coded CWE/CE value — downstream systems cannot perform unit conversion against the string "mg".
Omitting CQ.2 when CQ.1 is populated — the units component is conditionally required and a bare number is not interpretable.
Sending negative quantities in fields whose semantics require a positive magnitude (e.g. RXA-6 administered amount), causing receivers to reject the order.
Using non-UCUM codes without an explicit code-system component — mg alone is ambiguous; mg^milligram^UCUM is unambiguous.
Embedding the unit into CQ.1 ("5 mg") as a single string — CQ is a composite, and the ^ separator between magnitude and unit is mandatory.

Examples

Minimal value (quantity with simple unit triplet):

85^mg^UCUM

Three-component value with decimal magnitude:

85.5^mg^UCUM

Fully populated CWE units (primary UCUM + alternate legacy code):

85.5^mg&milligram&UCUM&mg&milligram&ISO+

In context — OBX-7 reference range on a numeric lab observation (note the low-high formed from two CQ-style components):

MSH|^~&|LAB|MERCY^2.16.840.1.113883.19.5^ISO|EHR|MERCY|20260610094500||ORU^R01^ORU_R01|MSG0091|P|2.8.1
PID|1||MR884412^^^MERCY^MR||TESTPATIENT^ALEX^Q||19720508|F
OBR|1|ORD-1234^MERCY|FIL-9988^MERCY|2951-2^Sodium^LN|||20260610093000
OBX|1|NM|2951-2^Sodium^LN||139|mmol/L^millimole per liter^UCUM|135-145|N|||F

In context — RXE-3 / RXE-4 dosing using CQ semantics in a pharmacy encoded order:

RXE||1605^Furosemide^RXNORM|40^mg^UCUM|80^mg^UCUM|mg^milligram^UCUM|TAB^Tablet^HL70162|PO^Oral^HL70162

Common pitfall — bare numeric without units:

OBX|1|NM|2951-2^Sodium^LN||139||135-145|N|||F

The receiver has no way to know whether 139 is mmol/L, mg/dL, or mEq/L; the observation is effectively unusable for decision support.

FHIR mapping

The v2-to-FHIR IG publishes a CQ ConceptMap at ConceptMap-datatype-cq-to-quantity. CQ maps directly to the FHIR Quantity data type:

CQ component	FHIR element	Notes
CQ.1 Quantity	`Quantity.value`	Decimal; sign preserved where semantically valid.
CQ.2.1 Identifier (UCUM code)	`Quantity.code`	UCUM code expected.
CQ.2.2 Text	`Quantity.unit`	Human-readable unit name.
CQ.2.3 Name of Coding System	`Quantity.system`	Resolved to a URI (e.g. `http://unitsofmeasure.org` for UCUM).

For ratios (e.g. mg/kg/day), downstream profiles commonly map to FHIR Ratio or Dosage.doseAndRate. Comparator semantics (<, >=) are not part of CQ — those live in fields like OBX-7 reference ranges or use TS comparator prefixes.

Engine considerations

UCUM normalization: many engines accept ISO+/ANSI+ legacy unit codes on inbound but should emit UCUM on outbound to keep FHIR mapping clean. Maintain a curated translation table; do not rely on free-text matching.
Composite vs. paired-field forms: older messages sometimes carry quantity and units in adjacent fields (RXO-2 + RXO-4) rather than a single CQ composite. Engines must recognize both shapes and not double-count units.
Decimal locale: CQ.1 is NM, which mandates . as the decimal separator. European systems that emit 1,5 will fail strict validation.
CWE in CQ.2: the units component is a full CWE — sub-components are separated by &. Engines that treat CQ.2 as a flat string lose the code-system and alternate-code metadata.

How Vorro parses and produces CQ

Vorro treats CQ as a first-class measurement object. On inbound, CQ.1 is parsed as a typed decimal and CQ.2 is normalized against an internal UCUM dictionary; non-UCUM inputs are preserved verbatim in an alternate-code slot and a soft warning is emitted so the source system can be coached toward UCUM. Conversion (e.g. mg/dL ↔ mmol/L for glucose) happens at the mapping layer, never silently inside the parser.

On outbound, Vorro always emits CQ with both components populated and a UCUM-primary CWE in CQ.2. Where the source carried only a numeric field with an implicit unit (legacy lab feeds), Vorro fills CQ.2 from the field's profile-defined default unit and tags the message with provenance so downstream readers know the unit was inferred rather than asserted by the source.

Sources

← Back to HL7 v2 Guide