The ORC segment, short for Common Order, carries the information that applies to any order in an HL7 v2 message, regardless of whether it is a lab test, imaging study or medication. It tells the receiving system what to do with the order, who placed it and how to identify it. Errors in ORC are behind many rejected orders and unmatched results. This reference covers every ORC field, the most important order control codes and practical implementation tips. For the wider picture of message types, see our HL7 message types and event types guide. Need help debugging an order interface? Request a free HL7 interface review.
What the ORC Segment Does
ORC appears in order-related messages such as ORM, OML, ORU, RDE and others. It sits before order-specific segments like OBR or RXO, and holds details shared by all order types. Understanding its role helps teams design interfaces that keep orders and results synchronized between systems.
Where ORC appears in messages
ORC usually follows patient and visit segments and precedes the detail segment for each order. A message containing several orders typically repeats ORC once per order. Each ORC therefore groups one order’s common information with its detail segments, such as OBR for observations.
The job of order control
The first field, ORC-1 Order Control, tells the receiver what action to take, such as creating, cancelling or changing an order. It is the only required ORC field in the base standard, and receivers rely on it to decide how every following segment should be processed.
Linking orders across systems
ORC carries placer and filler order numbers, which link an order in the ordering system to the same order in the performing system. Consistent use of these identifiers is essential, because results and status updates depend on them to find the correct original order.
ORC versus OBR
ORC holds information common to all order types, while OBR holds observation-specific details such as the test ordered and specimen information. Some fields overlap, including order numbers and ordering provider. Implementation guides usually specify which segment is authoritative when values appear in both.
ORC Field Reference (HL7 v2.5.1)
The table below lists ORC fields as defined in HL7 v2.5.1. Optionality uses standard codes: R for required, O for optional, C for conditional and B for retained for backward compatibility. Specific implementation guides and trading partners may tighten these rules, so always check partner specifications.
| Seq | Field name | Data type | Opt | Notes |
| ORC-1 | Order Control | ID | R | Action requested, e.g. NW, CA, XO |
| ORC-2 | Placer Order Number | EI | C | Order ID from the ordering system |
| ORC-3 | Filler Order Number | EI | C | Order ID from the performing system |
| ORC-4 | Placer Group Number | EI | O | Groups related orders together |
| ORC-5 | Order Status | ID | O | Current status, e.g. IP, CM, CA |
| ORC-6 | Response Flag | ID | O | Level of response requested |
| ORC-7 | Quantity/Timing | TQ | B | Superseded by the TQ1/TQ2 segments |
| ORC-8 | Parent | EIP | O | Links child orders to a parent order |
| ORC-9 | Date/Time of Transaction | TS | O | When the order event occurred |
| ORC-10 | Entered By | XCN | O | Person who entered the order |
| ORC-11 | Verified By | XCN | O | Person who verified the order |
| ORC-12 | Ordering Provider | XCN | O | Provider responsible for the order |
| ORC-13 | Enterer’s Location | PL | O | Location where the order was entered |
| ORC-14 | Call Back Phone Number | XTN | O | Contact number for questions |
| ORC-15 | Order Effective Date/Time | TS | O | When the order action takes effect |
| ORC-16 | Order Control Code Reason | CE | O | Reason for the order control action |
| ORC-17 | Entering Organization | CE | O | Organization of the person entering |
| ORC-18 | Entering Device | CE | O | Device used to enter the order |
| ORC-19 | Action By | XCN | O | Person who initiated the action |
| ORC-20 | Advanced Beneficiary Notice Code | CE | O | ABN status for billing |
| ORC-21 | Ordering Facility Name | XON | O | Facility placing the order |
| ORC-22 | Ordering Facility Address | XAD | O | Address of the ordering facility |
| ORC-23 | Ordering Facility Phone Number | XTN | O | Phone of the ordering facility |
| ORC-24 | Ordering Provider Address | XAD | O | Address of the ordering provider |
| ORC-25 | Order Status Modifier | CWE | O | Refines ORC-5 status |
| ORC-26 | ABN Override Reason | CWE | C | Reason for overriding ABN rules |
| ORC-27 | Filler’s Expected Availability Date/Time | TS | O | When results are expected |
| ORC-28 | Confidentiality Code | CWE | O | Confidentiality of the order |
| ORC-29 | Order Type | CWE | O | Inpatient or outpatient order |
| ORC-30 | Enterer Authorization Mode | CNE | O | How the order was authorized |
| ORC-31 | Parent Universal Service Identifier | CWE | O | Service ID of the parent order |
Order Control Codes You Will See Most
ORC-1 uses codes from HL7 table 0119. Dozens exist, but a small set covers most real-world interfaces. Knowing what each code means, and which direction it usually travels, prevents misinterpreted messages and orders stuck in the wrong status.
New orders: NW and OK
NW requests a new order, typically sent from the ordering system to the performing system. OK confirms the order was accepted, often returned with the filler order number. Together they establish the order and the identifiers both systems will use for future updates.
Cancellations: CA, CR and OC
CA requests cancellation of an order. CR confirms the order was canceled as requested. OC indicates the order was canceled by the performing system, often without a request. Handle each differently, because they reflect who initiated the cancellation and whether a request was honored.
Changes and discontinuations: XO and DC
XO requests a change to an existing order, while DC requests discontinuation, common for ongoing orders such as medications. Receiving systems must locate the original order using identifiers before applying changes, so accurate placer and filler numbers are critical here.
Status and results: SC and RE
SC signals a status change, often paired with an updated ORC-5 value. RE indicates observations follow, commonly used in result messages. Receivers use these codes to update order status and file results against the correct original order. Test both codes with every partner.
Example ORC Segment
Real examples help teams validate parsing and mapping. The sample below shows a new order with placer and group numbers, a transaction time, the person entering the order and the ordering provider. Values are fictional and shown in standard pipe-delimited format.
ORC|NW|ORD12345^HOSP_EHR||GRP7788^HOSP_EHR|||||20261016083000|JDOE^Doe^Jane||1234567890^Smith^John^A^^^MD
Reading the example
ORC-1 is NW, a new order. ORC-2 holds placer order number ORD12345 from HOSP_EHR. ORC-3 is empty because the filler has not assigned a number yet. ORC-4 holds the group number, ORC-9 the transaction time and ORC-10 the entering user.
The ordering provider field
ORC-12 holds the ordering provider using the XCN data type, here with an identifier followed by family name, given name, middle initial and degree. Many partners require a national provider identifier in this field, with its assigning authority specified in later components.
Empty fields and delimiters
Empty fields are represented by consecutive pipe characters, which keep later fields in the correct position. Counting delimiters is the most reliable way to confirm which field holds which value, especially when debugging messages from unfamiliar systems. Interface engines can automate this check.
Implementation Tips and Common Errors
Most ORC problems come from inconsistent identifiers, misunderstood control codes and partner-specific rules. These tips reflect issues we see repeatedly when building and troubleshooting order interfaces for hospitals, labs and digital health companies.
Keep order numbers consistent
Placer and filler order numbers must remain stable for the life of an order. Reformatting, truncating or regenerating them breaks the link between orders and results. Document identifier formats with every partner and validate them in automated tests before go-live.
Agree on supported control codes
Partners rarely support every order control code. Confirm which codes each partner sends and accepts, and how unsupported codes should be handled. A short agreed list prevents silent failures when an unexpected code arrives in production traffic. Document the agreed list in each specification.
Watch ORC and OBR duplication
When the same value appears in ORC and OBR, such as ordering provider or order numbers, mismatches cause confusion. Follow the implementation guide’s rules for which segment wins, and validate that both contain consistent values in every outbound message. Automated checks catch most issues.
Validate against partner specifications
Base HL7 optionality is a starting point, not a contract. Partners often make optional fields required. Build validation rules from each partner’s specification, and reject or flag messages that violate them before they reach production systems. Keep validation rules version-controlled per partner.
How Taction Helps With HL7 Order Interfaces
Taction has delivered 200+ healthcare projects, including HL7 interfaces for labs, imaging, pharmacy and EHR integrations. We help organizations design, build and troubleshoot order interfaces so orders reach the right system and results return to the right patient.
Free HL7 interface review
Share sample messages and partner specifications. We review ORC and OBR usage, identifier handling and control codes, then flag mapping risks and fixes. You get clear, actionable recommendations. Request your free review. We also flag quick fixes you can apply immediately to reduce rejected orders.
Order and result interface development
We build ORM, OML and ORU interfaces through engines such as Mirth Connect, with validation, acknowledgments and monitoring. Explore our HL7 integration services for how we deliver reliable order workflows. Every interface includes alerting, so rejected or stuck orders are caught before they affect patient care.
Lab integration expertise
Lab orders depend on accurate ORC and OBR mapping. Our lab integration HL7 services cover reference labs, outreach clients and LIS connections, including compendium mapping and certification support. We also help labs onboard new clients faster with reusable interface templates and documented mapping standards for every partner.
HL7 engineers on demand
Need experienced interface engineers? Hire HL7 integration engineers who understand order workflows, segment mapping and engine development. They join your team quickly and document every interface thoroughly. Engagements scale with your roadmap, from a single order interface to support across many partners, labs and connected clinical systems.
Frequently Asked Questions
These answers cover common questions about the HL7 ORC segment. Because implementation guides and partners often add rules beyond the base standard, always confirm requirements with the specifications for your specific interface.
What does ORC stand for in HL7?
ORC stands for Common Order. It carries information common to all order types, such as order control, order numbers, ordering provider and transaction time. It appears in order-related messages before order-specific segments such as OBR or RXO. Most order interfaces use it.
Which ORC field is required?
In the HL7 v2.5.1 base standard, ORC-1 Order Control is the only required field. Placer and filler order numbers are conditional. Many implementation guides and partners require additional fields, so check each partner specification carefully. Validate those rules before go-live.
What is the difference between ORC-2 and ORC-3?
ORC-2 is the placer order number, assigned by the system that placed the order. ORC-3 is the filler order number, assigned by the system performing the order. Both identifiers link orders, status updates and results across systems. Keep both stable over time.
What does order control code NW mean?
NW means new order. The ordering system sends it to request that the performing system create an order. The receiver often responds with OK, confirming acceptance and providing a filler order number for future communication. Partners may use different response codes.
Is ORC-7 Quantity/Timing still used?
ORC-7 is retained for backward compatibility in HL7 v2.5.1, with timing information moved to the TQ1 and TQ2 segments. Older interfaces may still populate ORC-7, so confirm which approach each partner expects before building mappings. Document the agreed approach clearly.