HL7 Table HL70485: Extended Priority Codes

HL70485 was introduced in HL7 v2.5 as the successor to the legacy HL70217 priority vocabulary. It carries the urgency and timing semantics for orders in modern v2 profiles — bound to TQ1-9 Priority, ORC-27, and OBR-27. Where HL70217 had only the original single-letter codes from v2.2, HL70485 adds explicit values for callback (CR), preop (P), use-as-directed (UD), and timing-critical (T) workflows that pre-v2.5 profiles could only express with comments.

Purpose

HL70485 answers two questions at once: how urgently the order should be performed, and any standing-timing modifier that affects how the result should be reported. S (STAT) means do it now; R (Routine) means do it on the normal schedule; T (Timing critical) means the time window matters and missing it invalidates the result; PRN means perform on patient request, not on a schedule.

Because TQ1 (Timing/Quantity) was introduced in v2.5 alongside HL70485, the new table reflects the broader timing model that supersedes the older Quantity/Timing (TQ) component approach. Profiles that still use the OBR-27 component-coded priority on v2.4 and earlier should map to HL70217; v2.5+ profiles use HL70485 exclusively.

Where it's used

• TQ1-9 Priority — primary home in v2.5+ profiles.
• ORC-27 Order Priority — replaces the legacy priority component of ORC-7.
• OBR-27 Quantity/Timing — priority component in v2.5+ profiles that retain the OBR-27 path.

Code list

Code system OID

• OID: 2.16.840.1.113883.18.378
• Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0485

The OID is emitted in CWE.14 on v2.7+ profiles that carry priority as CWE; earlier profiles encode the value as ID with no OID slot.

HL7-defined vs user-defined

HL70485 is HL7-defined. Local extension is not permitted; if a site needs a custom priority concept it should be expressed in a CWE field bound to a different value set, not as a fabricated HL70485 code. The set is intentionally small (12 entries) and stable since v2.5.

Version differences

• v2.5 — Table introduced alongside TQ1 segment as the modern priority vocabulary. Initial set: A, CR, EL, EM, P, PRN, R, RR, S, T, UD, UR.
• v2.6 – v2.8.1 — Set frozen; no additions or removals.
• v2.9 — HL70485 unchanged; FHIR mapping refined to use request-priority.

The earlier HL70217 (Creation Role of Priority) lingers in v2.4-and-earlier profiles. Vorro maps HL70217 values to HL70485 equivalents on ingest so that downstream channels see a consistent vocabulary.

Common mistakes

• Using STAT as a free-text value in TQ1-9. The field is a coded value; the correct code is S.
• Confusing EM (Emergency) and S (STAT). Emergency implies a clinical emergency context; STAT is a workflow priority. Many trauma systems require both — S in TQ1-9 and a separate Emergency flag in PV2.
• Using R (Routine) when no priority is intended. Routine is a real value; leaving the field empty if the receiver requires it will fail conformance.
• Sending T (Timing critical) without populating the time window in TQ1-7/TQ1-8. The code is only meaningful when accompanied by start/end times.
• Mixing HL70217 codes (e.g. C for Callback) with HL70485 codes (CR). The two tables overlap but are not identical; pick one based on the profile version.

Examples

A routine basic metabolic panel:

TQ1|1|||||||||R^Routine^HL70485

STAT troponin:

TQ1|1|||||||||S^STAT^HL70485

Timing-critical post-feeding glucose (with explicit time window):

TQ1|1|||20260610080000|20260610083000|||||T^Timing critical^HL70485

Preop CBC scheduled the morning of surgery:

TQ1|1|||20260612060000||||||P^Preop^HL70485

Same S value translated to FHIR ServiceRequest.priority:

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

Mapping failure example — legacy code on a v2.5+ profile:

TQ1|1|||||||||C^Callback^HL70217

C is from HL70217; the v2.5+ equivalent is CR^Callback^HL70485. A conformant engine should remap, log the upgrade, and route the message to the next channel.

FHIR mapping

The v2-to-FHIR IG publishes ConceptMap-table-hl70485-to-request-priority, which collapses HL70485 onto the four-value FHIR request-priority set:

Round-trip from FHIR back to v2 is lossy for the timing-modifier codes (CR, P, PRN, T, UD), which must be reconstructed from Timing or a code extension; engines that need lossless v2 round-trip should preserve the original HL70485 code as an extension on ServiceRequest.priority.

Engine considerations

• Profile detection — HL70217 vs HL70485 selection depends on the negotiated v2 version. Default to HL70485 on v2.5+ and HL70217 on v2.4 and earlier.
• Multi-field consistency — TQ1-9, ORC-27, and OBR-27 may all be populated on a single order; receivers should prefer TQ1-9 and warn on disagreement.
• Timing modifiers — T, P, PRN, CR, and UD require accompanying timing data in TQ1; engines should validate the pairing.
• Case sensitivity — Codes are case-sensitive uppercase; stat is not valid.

How Vorro handles HL70485

Vorro validates TQ1-9, ORC-27, and OBR-27 against HL70485 on ingest for v2.5+ profiles and against HL70217 on earlier profiles, with an automatic remap from HL70217 to HL70485 on outbound when the destination profile is v2.5+. Unknown codes — including lowercase variants and HL70217 codes on v2.5+ ingress — are routed to the terminology curation queue.

On outbound FHIR, Vorro emits the collapsed ServiceRequest.priority value and preserves the original HL70485 code as an extension so timing-modifier semantics survive the round trip.

Related pages

• TQ1 segment — Timing/Quantity
• ORC segment — Common Order
• HL70217 code table — Creation Role of Priority

Sources

• HL7 Terminology — CodeSystem v2-0485 Extended Priority Codes
• HL7 v2 product brief
• HL7 v2-to-FHIR IG — ConceptMap HL70485 to request-priority