Testing HL7 v2 ORC-2: What Placer Order Number Actually Needs to Handle
ORC-2 and OBR-2 are supposed to carry the same value, and when a test data generator produces them independently instead of propagating one from the other, it hides the exact bug that shows up in production when a filler system fails to echo the placer number correctly.
ORC-2 is the second field of the HL7 v2 ORC segment — the ordering system's own identifier for the order, generated at the moment the order is placed. Where a message includes both ORC and OBR segments for the same order, ORC-2 is treated as the segment of record and OBR-2 is expected to carry an identical value.
What this field contains
Example
ORD44219^SYNTHIB in the second field is the placer order number, assigned by the ordering system. Synthetic order number — not from a real facility.
Where this trips people up
The specific bug worth testing for isn't a malformed ORC-2 value, it's a disagreement between ORC-2 and its counterpart in the corresponding OBR segment. When those two identifiers diverge — because an interface engine transforms one but not the other, or a filler system regenerates its own copy of the number — a receiving system can end up filing a result against a different order than the one the placer is tracking. Build test cases that assert ORC-2 and OBR-2 match on every message, and add a case where they deliberately don't, so you know your own system actually flags the mismatch instead of silently accepting whichever value it reads first.