How to Test HL7 v2 ORC: A Field-by-Field Breakdown
ORC sits in front of OBR in nearly every order message, and when the two segments disagree about the placer or filler order number, the order and its result stop being the same order as far as most downstream systems are concerned.
ORC is the HL7 v2 segment that carries the transaction-level details of an order — what kind of action is being communicated (new, cancel, status update), the order's identifiers, its current status, and who is responsible for it. It typically appears once per order, immediately before the OBR or other detail segment it governs.
The fields that actually matter in practice
Example
A synthetic ORC segment for a new order (NW) that is now in process (IP), with placer and filler order numbers and an ordering provider. Every value here is invented.
Where this trips people up
ORC and OBR both carry placer and filler order numbers, and interface teams often assume they're redundant copies that can be generated independently in test data. In production HL7 v2 messaging, ORC is generally treated as the authoritative source for these identifiers when a message carries both segments, with OBR expected to echo the same values. When a test suite generates ORC-2/ORC-3 and OBR-2/OBR-3 from two different code paths, it's easy to end up with a passing test that would never occur in a real feed — and easy to miss the real-world bug where a filler system updates its own OBR-3 without propagating the change back to ORC-3, leaving the two segments quietly disagreeing about which filler order this even is.