DICOM Attribute

Requested Procedure Priority (0040,1003)

Keyword
RequestedProcedurePriority
VR
SH
VM
1

Attribute Metadata

Tag
(0040,1003)
Keyword
RequestedProcedurePriority
Name
Requested Procedure Priority
Value Representation (VR)
SH
Value Multiplicity (VM)
1
Status
Active
Source
NEMA PS3.6 (table_6-1)

This attribute is part of the current DICOM Standard. Its value representation is SH with multiplicity 1.

This attribute uses the SH Value Representation. Multiplicity 1 governs how many values may be encoded.

Integration Notes

Real-world integration guidance for engineers implementing this attribute in Mirth Connect, FHIR gateways, HL7 v2 bridges, and cloud DICOM services. Authoritative source data where available; reference examples and operational notes where they add value.

FHIR Mapping

No direct FHIR ImagingStudy mapping published for this attribute. Some tags map indirectly via the Patient, Endpoint, or ImagingSelection resources — Phase 2b will expand coverage to those.

HL7 v2 Equivalent

  • TQ1-9 / OBR-27.6 Priority
    ORM

    TQ1-9 in HL7 v2.5+ (or OBR-27.6 in older versions). Code values: STAT, ASAP, ROUTINE, etc. — often mapped one-to-one to DICOM RequestedProcedurePriority.

    Source: IHE RAD-TF Vol 2 §4.7

Verify against IHE Radiology TF Vol 2 and your facility's interface specification before production use.

Cloud DICOM Support

AWS HealthImaging, Azure DICOM, and GCP Healthcare DICOM coverage rolls out by attribute. The QIDO-RS matching keys + Patient/Study/Series core (~50 attributes) are documented; lower-traffic attributes will be added as Saga teams encounter them in production.

Real-World Sample Values

No representative sample value available — this attribute isn't present in the de-identified pydicom fixture set. Add a fixture covering this attribute to expand coverage.

Mirth Connect Example

Map HL7 v2 Order Priority (TQ1-9) to DICOM RequestedProcedurePriority — HL7 v2

HL7 v2.5+ uses TQ1-9; older messages use OBR-27.6. DICOM uses STAT/HIGH/ROUTINE/MEDIUM/LOW.

// (0040,1003) Requested Procedure Priority — map HL7 v2 priority codes
var tq19 = String(msg['TQ1'] && msg['TQ1'][9] && msg['TQ1'][9][1] || '').trim().toUpperCase();
var obr276 = String(msg['OBR'] && msg['OBR'][27] && msg['OBR'][27][6] || '').trim().toUpperCase();
var hl7Prio = tq19 || obr276;
var map = { 'S': 'STAT', 'A': 'HIGH', 'P': 'HIGH', 'R': 'ROUTINE', 'T': 'MEDIUM', 'C': 'LOW' };
var dicomPrio = map[hl7Prio] || 'ROUTINE';
channelMap.put('dicom_request_priority', dicomPrio);

Reference only — validate before production. Snippets are starting points, not turnkey solutions. Always test against your channel's specific message structure and your facility's interface specification. See Mirth Connect User Guide + NEMA PS3.6 + your vendor conformance statement for authoritative specification.

Common Operational Errors

  • medium Priority code value drift between v2.4 and v2.5+

    Diagnosis: HL7 v2.4 uses OBR-27.6 for priority; v2.5+ moved it to TQ1-9. Mirth channel reads OBR-27.6 only; v2.5+ source omits it; DICOM RequestedProcedurePriority defaults to 'ROUTINE' when message was actually 'STAT'.

    Fix: Read TQ1-9 first, fall back to OBR-27.6: `var prio = msg['TQ1'][9][1] || msg['OBR'][27][6];`. Test against both v2.4 and v2.5+ source samples.

Reference only — validate before applying a fix. Scenarios are drawn from common DICOM/HL7 v2 integration patterns; reproduce against your environment before acting on any diagnosis. See NEMA PS3.6 + your vendor conformance statement for authoritative specification. Severity levels: high (data-loss / patient-safety), medium (workflow disruption), low (cosmetic).

DICOM Integration Services

Saga IT builds production DICOM integrations across Mirth Connect, FHIR gateways, and cloud imaging platforms. If you're working with RequestedProcedurePriority or the broader (0040,1003) context: