ORM^O01 — Order Message

The historical HL7 v2 prescription message: lab orders, imaging, treatments, medications. Present in virtually every EHR ↔ LIS feed deployed before 2010.

Purpose

ORM^O01 carries a clinical order: a lab test request, an imaging order, a drug prescription, a nursing request. The message is multi-object: one envelope may bear several orders (repeated ORC + OBR groups), each with its own observations (OBX), notes (NTE), diagnoses (DG1), specimens (SPM).

The order control code in ORC-1 qualifies the intent: NW (New Order), CA (Cancel), DC (Discontinue), RP (Replace), HD (Hold), RL (Release). That code drives the business semantics on the receiving side.

Segment structure

The abstract structure ORM_O01 defined in chapter 4 of v2.5.1:

ORM_O01
  MSH                       Message Header (mandatory)
  [ { NTE } ]               Notes and Comments (optional)
  [
    PATIENT
      PID                   Patient Identification (mandatory)
      [ PD1 ]               Patient Additional Demographics
      [ { NTE } ]
      [ { NK1 } ]           Next of Kin
      [
        PATIENT_VISIT
          PV1               Patient Visit
          [ PV2 ]           Patient Visit - Additional Info
      ]
      [ { INSURANCE
          IN1               Insurance
          [ IN2 ]
          [ IN3 ]
      } ]
      [ GT1 ]               Guarantor
      [ { AL1 } ]           Patient Allergy
  ]
  {
    ORDER                   Order (repeating)
      ORC                   Common Order (mandatory)
      [
        ORDER_DETAIL
          OBR | RQD | RQ1 | RXO | ODS | ODT
          [ { NTE } ]
          [ { DG1 } ]       Diagnosis
          [ { OBX } ]       Observation / Result
          [ { FT1 } ]       Financial Transaction
          [ { CTI } ]       Clinical Trial Identification
          [
            BLG             Billing
          ]
      ]
  }

MSH — Message Header

• MSH-9: ORM^O01^ORM_O01.
• MSH-10: sender-side unique message identifier (idempotency key).
• MSH-12: 2.5.1.
• MSH-15 / MSH-16: AL + AL is common for ORM (the EHR expects an application ORR with the placer/filler ID allocated by the LIS).

PID — Patient Identification

PID is identical to that of an ADT^A01 (see the ADT^A01 page) — the consistency of PID-3 identifiers between the two flows is critical for downstream correlation (ORU results attached to the right patient and the right encounter).

ORC — Common Order

ORC is the skeleton common to all orders: control code, Placer / Filler identifiers, operator, order date, etc. Critical fields:

• ORC-1: Order Control (NW, CA, DC, RP, HD, RL…). Drives business semantics.
• ORC-2: Placer Order Number — identifier allocated by the ordering system (EHR). Stable across the order lifecycle.
• ORC-3: Filler Order Number — identifier allocated by the executing system (LIS). Returned in the ORR.
• ORC-5: Order Status (IP=In Process, CM=Completed, SC=Scheduled, A=Some results available…).
• ORC-7: Quantity / Timing — repetition frequency (for recurring prescriptions).
• ORC-9: desired effective date.
• ORC-10 / ORC-12: Entered By / Ordering Provider (ordering clinician, XCN).
• ORC-17: Entering Organization — entry facility.

OBR — Observation Request

OBR carries the detail of the test request. Critical fields:

• OBR-2: Placer Order Number (must match ORC-2).
• OBR-3: Filler Order Number (matches ORC-3, empty on creation).
• OBR-4: Universal Service Identifier (CWE) — code of the requested test (CBC, BMP, TSH…). Ideally coded in LOINC.
• OBR-7: Observation Date/Time — specimen collection / exam timestamp.
• OBR-16: Ordering Provider (XCN).
• OBR-22: Results Report / Status Change — Date/Time (empty on creation).
• OBR-24: Diagnostic Serv Sect ID (LAB, RAD, CHE…).
• OBR-25: Result Status (O=Order received, I=In progress, P=Preliminary, F=Final).

OBX — Observation / Result

OBX carries a discrete observation: at order time (clinical context, weight, pregnancy status), or at result time (used in the ORU^R01 response). Critical fields for the ORM context (order-time observations):

• OBX-2: value type (NM=Numeric, ST=String, CWE=Coded with Exceptions, TX=Text…).
• OBX-3: Observation Identifier — observation code (LOINC).
• OBX-5: Observation Value.
• OBX-6: Units (UCUM).
• OBX-7: Reference Range (normal interval).
• OBX-8: Abnormal Flags (H=High, L=Low, HH=Critical High…).
• OBX-11: Observation Result Status.

Real-world example

A Complete Blood Count (CBC) request for patient John Doe, following suspicion of bacterial pneumonia:

MSH|^~\&|EHR|CLINIC02|LIS|HOSP01|20260514110000||ORM^O01^ORM_O01|ORM00000001|P|2.5.1|||AL|NE
PID|1||MRN567890^^^HOSP^MR||DOE^JOHN^A^^MR.||19720515|M|||100 MAIN ST^^ANYTOWN^CA^90210^USA||(555)555-1234|||S||ACCT123456
PV1|1|I|ICU^101^A^HOSP01||||DRSMITH^Smith^James^A^^DR.||||||1||||||||||||||||||||||HOSP01
ORC|NW|ORD789012|||IP||^^^20260514110000^^R||20260514110000|DRSMITH^Smith^James^A^^DR.||DRSMITH^Smith^James^A^^DR.|HOSP01
OBR|1|ORD789012||CBC^Complete Blood Count^L|||20260514110000|||||||||DRSMITH^Smith^James^A^^DR.||||||20260514110000||LAB|F
NTE|1||Hematocrit if possible
DG1|1|I10|J18.9^Bacterial pneumonia^I10|||A

• MSH: the clinic EHR sends to the hospital LIS, version 2.5.1.
• PID + PV1: patient and visit (consistent with the admission A01).
• ORC+NW: New Order, Placer ORD789012, ordering provider DRSMITH.
• OBR+1+ORD789012: requested test = CBC^Complete Blood Count^L (local code), desired collection time 14 May 11:00, sector LAB, status F (Final — the order is validated).
• NTE: free clinical note ("Hematocrit if possible").
• DG1: admission diagnosis justifying the request: bacterial pneumonia (ICD-10 J18.9), code A = Admitting.

Response (ORR^O02)

The LIS responds by allocating a Filler Order Number and confirming acceptance:

MSH|^~\&|LIS|HOSP01|EHR|CLINIC02|20260514110005||ORR^O02^ORR_O02|ORR00000001|P|2.5.1
MSA|AA|ORM00000001
PID|1||MRN567890^^^HOSP^MR||DOE^JOHN^A^^MR.||19720515|M
ORC|OK|ORD789012|LIS456789||IP||||20260514110005

• MSA-1: AA (Application Accept).
• MSA-2: identifier of the acknowledged ORM message.
• ORC-1: OK = Acknowledge — order accepted.
• ORC-3: LIS456789 — the LIS-allocated Filler ID.

The final result will arrive later, in a separate message: ORU^R01 (Observation Result Unsolicited), correlated through the Placer / Filler pair.

Common errors

• Non-unique Placer Order Number on the EHR side: if the EHR reuses a Placer ID for a new order, the LIS cannot tell update from new request. Always stratify by encounter + timestamp.
• OBR-4 without standard coding: using only a local label (CBC^Complete Blood Count^L) without a LOINC component forces the LIS to maintain a mapping table. Enrich at least to CBC^...^L~58410-2^...^LN.
• ORC-1 = NW on an existing order: the EHR must send RP (Replace) or XO (Change order) for modifications. NW always creates a new order.
• No ORR response: some batch-mode LIS systems do not return ORR; the EHR must then correlate ORU results by Placer ID (OBR-2) rather than Filler ID.
• Mixed multi-orders: an ORM may carry N ORC+OBR groups. Each must be self-sufficient (its own Placer ID, its own OBR-4 code).

Evolution: ORM → OML / OMI / OMP / OMD / OMG

Starting with v2.5, HL7 split ORM into several domain-specific messages to reduce semantic ambiguity. The table below summarises the equivalence:

Whatever the chosen domain message, the mechanics stay the same: an ORR response (ORI^O23 for OMI, ORL^O22 for OML, etc.) acknowledges the order, then a result message ORU^R01 or its equivalent returns the observations.

See also: ADT^A01 for patient admission, and FHIR Bundle which carries multi-resource operations in FHIR R5 — the functional equivalent of a multi-ORC ORM.