HL7 ORC Common Order
HL7 field reference ORC fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| ORC.1 | Order Control | Yes | No | ID | 0119 |
| ORC.2 | Placer Order Number | No | No | EI | |
| ORC.3 | Filler Order Number | No | No | EI | |
| ORC.4 | Placer Group Number | No | No | EI | |
| ORC.5 | Order Status | No | No | ID | 0038 |
| ORC.6 | Response Flag | No | No | ID | 0121 |
| ORC.7 | Quantity/Timing | No | Yes | TQ | |
| ORC.8 | Parent | No | No | EIP | |
| ORC.9 | Date/Time of Transaction | No | No | TS | |
| ORC.10 | Entered By | No | Yes | XCN | |
| ORC.11 | Verified By | No | Yes | XCN | |
| ORC.12 | Ordering Provider | No | Yes | XCN | |
| ORC.13 | Enterer's Location | No | No | PL | |
| ORC.14 | Call Back Phone Number | No | Yes | XTN | |
| ORC.15 | Order Effective Date/Time | No | No | TS | |
| ORC.16 | Order Control Code Reason | No | No | CE | |
| ORC.17 | Entering Organization | No | No | CE | |
| ORC.18 | Entering Device | No | No | CE | |
| ORC.19 | Action By | No | Yes | XCN | |
| ORC.20 | Advanced Beneficiary Notice Code | No | No | CE | 0339 |
| ORC.21 | Ordering Facility Name | No | Yes | XON | |
| ORC.22 | Ordering Facility Address | No | Yes | XAD | |
| ORC.23 | Ordering Facility Phone Number | No | Yes | XTN | |
| ORC.24 | Ordering Provider Address | No | Yes | XAD | |
| ORC.25 | Order Status Modifier | No | No | CWE | |
| ORC.26 | Advanced Beneficiary Notice Override Reason | No | No | CWE | 0552 |
| ORC.27 | Filler's Expected Availability Date/Time | No | No | TS | |
| ORC.28 | Confidentiality Code | No | No | CWE | 0177 |
| ORC.29 | Order Type | No | No | CWE | 0482 |
| ORC.30 | Enterer Authorization Mode | No | No | CNE | 0483 |
| ORC.31 | Parent Universal Service Identifier | No | No | CWE |
If PID tells us who the patient is and PV1 tells us which visit we are talking about, ORC tells us what is happening to an order. It is the common order segment, which means it carries the order control information that applies across lab, radiology, pharmacy, diet, procedure, and other order workflows.
The ORC segment is about order lifecycle. New order, cancel request, accepted, unable to accept, status changed, discontinued, on hold, released, replaced: those ideas live here. The order detail segment that follows, such as OBR for an observation request, tells you what is being ordered or resulted. ORC tells you how that order is being controlled. In Integration Soup, I like order-control routing to be very visible, because a cancel request and a status update should not quietly travel the same path just because both are ORC messages.
A lot of trouble comes from treating ORC and OBR as duplicates. They do overlap. ORC-2 and OBR-2 are both placer order numbers. ORC-3 and OBR-3 are both filler order numbers. ORC-12 and OBR-16 can both carry the ordering provider. The practical rule is simple: if both segments carry the same logical field, the values should match, or your interface specification should explain exactly why they do not.
As with all HL7, optional does not mean unimportant. In many real order interfaces the essential ORC fields are ORC-1, ORC-2, ORC-3, ORC-5, ORC-9, ORC-12, ORC-15, and ORC-16. Get those right and the receiving system can usually understand the order lifecycle. Get those wrong and everything downstream starts inventing meaning from nearby fields, which is rarely a proud moment.
So let's go through each of the ORC fields and talk about how they tend to behave in real interfaces.
This is the action field: the verb for the order message. NW means a new order or service. CA is a cancel request. OK says the order was accepted. CR says it was cancelled as requested. SC says the status changed. UA means the receiver was unable to accept the order. It is one of the most important fields in all order messaging.
The order control codes fall into different personalities. Some are requests, such as "please cancel this order". Some are acknowledgments, such as "yes, cancelled as requested". Some are notifications, such as "this order has been cancelled". That distinction matters. A placer system should not send a filler-only acknowledgment code just because it likes the wording. If you receive CA, CR, and OC as if they are the same thing, your order state machine is going to have a long and emotional life.
I like to design order interfaces so ORC-1 drives the action, while ORC-5 describes the current status. Do not use ORC-5 to decide whether the message is asking you to do something. ORC-1 is the command or notification. ORC-5 is the status being reported.
The two order numbers tell you who minted which identifier. The placer number comes from the system that placed or requested the order. The filler number comes from the system that fills, performs, dispenses, or results it. In a lab workflow, the EHR or order entry system is usually the placer, and the LIS is usually the filler. In radiology, the ordering system may be the placer and the RIS or imaging workflow system may be the filler.
These identifiers are the backbone of order matching. Use the EI data type properly. PON-12345^^^EHR and FON-998877^^^LAB are much more useful than two bare numbers. The namespace or assigning system stops the receiving application from guessing which system minted the value.
In messages that also have OBR, the same logical identifiers may appear in OBR-2 and OBR-3. If both ORC and OBR are present and both carry the order numbers, they should match. If your sender puts different values in ORC-2 and OBR-2, do not casually pick one and hope. Decide which segment is authoritative for your local feed, document it, and log mismatches. Order number mismatches are not cute formatting problems; they are how results attach to the wrong request.
Related orders sometimes need a shared handle from the placer side. This is useful when one requisition or clinical request generates several individual orders. For example, a panel, a set of imaging studies, or several lab tests may each have their own order number but share a placer group number.
Do not use ORC-4 as the order number. It is a grouping identifier. In some feeds it is the thing that helps you show "these orders belong together", while ORC-2 and ORC-3 identify the individual order. If you turn the group number into your primary key, the first multi-order request will teach you why that was optimistic.
The status here is the current state of the order as known by the sending application. Common values include in process, completed, cancelled, discontinued, on hold, scheduled, replaced, error order not found, and partial results available. It is especially useful in status update messages, result messages, and workflows where the filler keeps the placer informed.
The status value should normally come from the filler when the filler owns the status. A placer can request a cancellation with ORC-1, but the filler confirms the outcome with a control code and status. Do not let a receiver mark an order completed just because it saw a final result somewhere else unless that is the agreed rule. ORC-5 is the order status, while OBR-25 is the result status for an observation request. Related, yes. Identical, no.
Sometimes the sender wants to be specific about what should come back. This field can request only an MSA segment, exceptions only, replacement and parent-child detail, or confirmations with associated segments depending on the code. In many modern interfaces, it is left empty because the acknowledgment behavior is handled by the interface agreement rather than per-order flags.
If you do use it, be precise. A response flag can change what the receiver is expected to send back. Do not populate it from a default value unless the sender and receiver both understand the operational consequence.
Timing on older order feeds often lands here using the TQ data type. It can describe when the ordered service should happen, frequency, priority, duration, and related timing ideas. You will still see it in v2.5.1 feeds, especially older order interfaces.
In later HL7 thinking, TQ1 and TQ2 are the cleaner home for timing detail. If your message has both ORC-7 and TQ1/TQ2, agree which one wins. For a one-off lab order, ORC-7 may be empty. For a recurring treatment, medication, or service, timing becomes much more important.
Parent-child order relationships need more than a shared group number. This field links the order to a parent order using placer and filler assigned identifiers, which is useful for child orders, replacement orders, reflex testing, add-ons, or workflows where one original order creates one or more dependent orders.
Use this when there is a real parent-child order relationship. Do not put the placer group number here just because both fields sound relational. A group says orders belong together. A parent says this order is derived from or subordinate to another order.
Use this timestamp for when the action in ORC-1 actually happened. It is not the same as MSH-7, which is the message timestamp. If someone cancelled an order at 10:00 but the interface sent the message at 10:03, the 10:00 action time belongs here.
This field is very useful for audit trails and ordering timelines. If messages arrive late or out of sequence, ORC-9 may be more meaningful than receive time. Still, be careful with clock drift and time zones. A beautiful order timeline built from badly synchronized systems is still fiction, just with timestamps.
The person who keyed in the order is not always the person who ordered it. It may be a clinician, clerk, nurse, system user, or automated process depending on the workflow. Treat it as an audit and workflow field, not automatically as the ordering provider.
Verification is the older companion idea. Later HL7 versions moved away from relying on this field for detailed participation, but v2.5.1 feeds still use it. Use proper XCN identifiers if you populate either field. A display name alone is not enough for a serious audit trail.
The ordering provider is often the clinician responsible for ordering the test, medication, procedure, or service. It may be repeated, but if you have multiple provider roles, make sure the receiver knows what those repeats mean.
This field overlaps with OBR-16 in observation orders. In a clean order message, the ORC ordering provider and the OBR ordering provider normally match unless there is a documented reason. If they differ, do not assume the OBR is wrong or the ORC is wrong. Work out whether the order has a common provider at the ORC level and a detail-specific provider at the OBR level.
Order-entry provenance can include both where the order was entered and who to call about it. The location might be a ward, nurse station, clinic, floor, or facility, and it uses PL, so structure it if you can. The callback number is the practical phone contact for clarifying the order.
These fields are practical support fields. They are not the patient's location and they are not necessarily the performing location. If a lab has a question about the order, ORC-14 may be the number they call. If the order came from a ward workstation, ORC-13 may tell you where that happened.
Effective time answers when the order information should take effect. This can be especially important for continuing orders. A cancellation message might be sent today but not take effect until a future date.
The reason then explains the order control code. If ORC-1 says cancel, this can explain why. If ORC-1 says hold, it can explain the hold reason. Put coded values here when possible. Free text is nice for a human reading one message, but coded reasons are what make reports, routing, and automation possible later.
Audit trails get much clearer when these three ideas stay separate: the organisation that entered the order, the device used to enter it, and the person who took the action represented by ORC-1. They are useful when you need to separate the ordering provider from the user, organisation, or device that actually performed the transaction.
The distinction matters in real systems. A doctor may be the ordering provider, a nurse may enter the order, a ward may be the entering location, and an interface engine or EHR workstation may be the entering device. If you collapse those into one "ordered by" concept, you lose useful audit information.
These ABN fields mostly belong to US billing and medical-necessity workflows, where a patient may need to be informed that a service might not be covered. The code carries the Advanced Beneficiary Notice value, and the later override field can explain why it was overridden.
If your workflow does not use ABN concepts, leave these fields alone. If it does, be exact. These values can have billing and consent consequences. They are not general-purpose insurance notes.
Contact details live here: the ordering facility name, address, and phone number, plus the ordering provider address. These are useful when the receiving system needs to contact the ordering organisation or send reports back outside the immediate electronic workflow.
Do not use these as substitutes for identifiers. The facility name and address are contact details. The actual placer and filler order numbers still identify the order, and provider identifiers still identify the clinician. Contact fields help humans follow up when the data is not enough.
A modifier adds local detail to the broader order status. If ORC-5 says the order is in process, this field might explain the particular in-process state, such as sent to an external lab, waiting for specimen, label printed, or another local workflow status.
Only use this field when ORC-5 is valued. A status modifier without a status is like an adjective wandering around without a noun. Also expect local codes here. ORC-5 is constrained by an HL7-defined table; ORC-25 is where organisations can add detail that their workflow actually needs.
This is the filler-side estimate for when the ordered thing will be available. In lab or radiology, that might mean when results are expected. In pharmacy, it might mean when the prescription is expected to be ready. It is not the order creation time.
This field can be very helpful for status displays, but it should be treated as an estimate unless the workflow says otherwise. If the expected time changes, send a status update rather than letting old times linger in downstream systems.
Confidentiality flags are order-level handling instructions. Examples include usual control, restricted, very restricted, employee, psychiatric, HIV, substance treatment, VIP, and similar categories depending on the code set and local policy.
Confidentiality is not decoration. If you send it, the receiver must know whether it affects display, access control, auditing, routing, or all of those. If the receiver cannot enforce the meaning, be careful about sending sensitive flags that create a false sense of protection.
These two fields round out the order provenance story. The order type says whether the order is inpatient or outpatient in the order-type sense; it is not a replacement for PV1-2 patient class, though the two may often line up. The authorization mode says how the enterer was authorized, such as electronic, paper, phone, verbal, fax, reflexive automated system, or in person.
These fields are most useful in workflows where authorization and order provenance matter. If a verbal order needs later signature, or a reflex order is generated automatically, ORC-30 can help explain how the order came into being.
Parent service identifiers help when a child order was generated from a larger ordered service, replacement, reflex action, or broader service request. In that sort of parent-child order workflow, this field can preserve the service that sits above the current order.
As with all parent fields, use it only when the relationship is real and agreed. If you need to connect a result battery to the service that caused it, this can be helpful. If you are just trying to stash another code somewhere, it will confuse the next interface that tries to make sense of the order tree.