HL7 Table HL70217: Order Priority

HL70217 is the legacy HL7-defined code table for order priority. It carries how urgently the filler should perform an order, using single-letter codes drawn from a pre-2.5 era when timing was crammed into a single TQ field. The table lives in the priority sub-component of the legacy Timing/Quantity field — TQ.6, plus the embedded TQ in ORC-7.6 and OBR-27.6 — and it remains in active use whenever a sender's profile predates the v2.5 Extended Priority Codes (HL70485) split. The table has been present since HL7 v2.2.

Purpose

HL70217 answers one narrow question: how soon does the filler need to act. It is a coarse priority signal — seven codes, no quantitative timing — designed for routing decisions like "drop this on the STAT queue" or "schedule for the next preop slot." Anything more precise (start time, repeat pattern, duration) belongs in the other components of the TQ field, not in TQ.6.

Because the table is HL7-defined, every conformant v2.2–v2.8.1 receiver is expected to recognize the seven codes below without local extension. v2.5 introduced a parallel richer table — HL70485 Extended Priority Codes — for new fields like TQ1-9 (TQ1 segment Priority), but HL70217 itself stayed put for backward compatibility with TQ, ORC-7, and OBR-27.

Where it's used

• TQ.6 Priority — the canonical home of HL70217 inside the legacy Timing/Quantity data type.
• ORC-7.6 Quantity/Timing — Priority subcomponent — same code set embedded in ORC.
• OBR-27.6 Quantity/Timing — Priority subcomponent — same code set embedded in OBR.
• HL70217 is not used in TQ1-9 (the v2.5+ replacement); that field is bound to HL70485 instead.

Code list

Code system OID

• OID: 2.16.840.1.113883.18.91
• Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0217

The OID resolves on the HL7 Terminology server and is the value Vorro emits in CWE.14 when a downstream profile demands OID-bound coded values for the TQ.6 priority subcomponent.

HL7-defined vs user-defined

HL70217 is HL7-defined. The table number falls inside the HL7-reserved range (HL70001–HL70999), and the seven-code set is normative — receivers must accept all seven values, and senders must not invent additional codes inside this table. Sites that need richer priority semantics (e.g., contrast-with-prep, post-op day 1) use HL70485 Extended Priority Codes in v2.5+ profiles rather than extending HL70217.

Version differences

• v2.2 — Table introduced with the seven values listed above.
• v2.3 – v2.4 — Unchanged; TQ remains the primary carrier.
• v2.5 — HL70485 Extended Priority Codes introduced for the new TQ1 segment. HL70217 stayed bound to the legacy TQ, ORC-7, and OBR-27 priority subcomponents for backward compatibility.
• v2.6 — The TQ data type is officially deprecated; new implementations should use TQ1 with HL70485. HL70217 remains valid for messages that still carry TQ.
• v2.7 – v2.8.1 — HL70217 set frozen; the standard nudges implementers toward HL70485 but does not remove HL70217.

Common mistakes

• Sending the display word in TQ.6 — STAT instead of S. TQ.6 is ID and the code value is the symbol (and STAT and S are not the same code).
• Using HL70217 codes in TQ1-9. TQ1-9 is bound to HL70485, where the STAT code is the spelled-out STAT, not S. Mixing the two tables silently corrupts priority routing.
• Defaulting unknown priority to S (STAT) to make sure the filler "doesn't miss it." This floods STAT queues and devalues genuine STAT signals; the correct default when priority is unknown is R (Routine).
• Treating A (ASAP) and S (STAT) as interchangeable. STAT carries operational and contractual meaning (e.g., 15-minute turnaround in many labs); ASAP does not.
• Extending HL70217 locally with codes like URGENT, EXP (expedite), or vendor-specific values. HL70217 is HL7-defined; use HL70485 in v2.5+ for richer priorities instead.

Examples

An ORC carrying a STAT laboratory order on a v2.4 profile:

ORC|NW|PLC0042^LAB|FLR0042^LAB||SC|^^^20260601120000^^S|||20260601115530|||1234^SMITH^J^^^^MD

A routine outpatient order:

ORC|NW|PLC0099^LAB|FLR0099^LAB||SC|^^^20260615^^R|||20260601090000|||1234^SMITH^J^^^^MD

Same S value translated to a FHIR ServiceRequest.priority snippet via the v3-ActPriority bridge:

{
  "resourceType": "ServiceRequest",
  "id": "FLR0042",
  "status": "active",
  "intent": "order",
  "priority": "stat"
}

A CWE-typed TQ.6 (v2.7+ profile) carrying OID metadata produces a fuller Coding:

{
  "priority": "stat",
  "_priority": {
    "extension": [{
      "url": "http://hl7.org/fhir/StructureDefinition/originalText",
      "valueString": "S"
    }]
  }
}

Mapping failure example — unknown vendor code:

ORC|NW|PLC0042^LAB|FLR0042^LAB||SC|^^^20260601120000^^URGENT

URGENT is not in HL70217 (it is also not in HL70485, which uses UR). A conformant engine should route the message to a curation queue, preserve the original URGENT in the audit log, and emit FHIR priority: routine with a data-absent-reason extension rather than silently coercing to STAT.

FHIR mapping

The HL7 v2-to-FHIR Implementation Guide publishes ConceptMap-table-hl70217-to-v3-actpriority, which projects the seven HL7 codes onto the v3 ActPriority code system that FHIR uses as a bridge:

ServiceRequest.priority and MedicationRequest.priority are bound to http://hl7.org/fhir/ValueSet/request-priority (a four-value set: routine, urgent, asap, stat). Because HL70217 is richer than the FHIR set, the v3-ActPriority intermediate carries the additional distinction (callback, preop, PRN) and must be preserved as a Coding on the extension if round-trip back to HL7 v2 is required.

Engine considerations

• Length validation — TQ.6 is 1–5 characters (PRN is the longest); engines should reject longer payloads rather than truncate.
• Case sensitivity — HL70217 codes are case-sensitive uppercase; s is not a valid code. Normalize on ingest.
• Table-confusion guard — Engines that handle both HL70217 (TQ.6) and HL70485 (TQ1-9) must route each field to its own value set. Accepting STAT in TQ.6 because it "looks right" silently corrupts data; that code belongs only in HL70485.
• CWE upgrade path — In v2.7+ profiles TQ.6 may be transmitted as CWE rather than ID, allowing OID metadata in CWE.14 (2.16.840.1.113883.18.91). Engines must handle both shapes.
• Round-trip preservation — When mapping to FHIR ServiceRequest.priority, store the original HL70217 code as an extension so the v2 outbound channel can restore C/P/PRN distinctions that collapse to FHIR routine.

How Vorro handles HL70217

Vorro validates TQ.6, ORC-7.6, and OBR-27.6 against the seven HL70217 codes on ingest. Values that match are forwarded to all downstream channels untouched. Values that fail validation — including lowercase variants, vendor extensions like URGENT, and HL70485 codes that wandered into the wrong field — are routed to the terminology curation queue, where they either resolve to one of the seven canonical codes (and a remap rule is created) or pass through with a soft warning so downstream systems are not silently fed bad priority signals.

On outbound, Vorro emits HL70217 as ID for v2.5 and earlier profiles and as CWE with CWE.14 populated for v2.7+ destinations that advertise OID-bound coded values. The original HL70217 code is always preserved when round-tripping through FHIR ServiceRequest.priority, and Vorro never up-converts a legacy S to HL70485 STAT unless the destination profile specifically requires TQ1.

Related pages

• ORC segment — Common Order
• HL70485 code table — Extended Priority Codes
• HL70038 code table — Order Status

Sources

• HL7 Terminology — CodeSystem v2-0217 Order Priority
• HL7 v2 product brief
• HL7 v2-to-FHIR IG — ConceptMap HL70217 to act-priority