DICOM Attribute

Accession Number (0008,0050)

Keyword
AccessionNumber
VR
SH
VM
1

Definition

A departmental Information System generated number that identifies the Imaging Service Request.

From NEMA PS3.3 §C.7.2.1.

Attribute Metadata

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

Used in 2 Modules

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

  • OBR-18 Placer Field 1 (Accession Number)
    ORMORU

    Most common mapping per IHE RAD-TF — Accession Number is conveyed in OBR-18 (Placer Field 1) for radiology orders. Some sites use OBR-3 (Filler Order Number) or a Z-segment instead. Always confirm with facility convention.

    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 Queryable
  • Azure DICOM Queryable
  • Google Cloud Healthcare Queryable

Accession Number is a Study-level QIDO-RS matching key on all three platforms. AWS HealthImaging promotes it to top-level ImageSet metadata.

Per-vendor source URLs and verification date in src/content/dicom/cloud-support.json#_meta. Status taxonomy: required (mandated on Store), queryable (QIDO-RS matching key), preserved (stored as-is), promoted (AWS top-level metadata), unsupported (stripped/rejected).

Real-World Sample Values

  • 03028041970546 waveform_ecg.dcm

Extracted from pydicom test fixtures (MIT, de-identified).

Mirth Connect Example

Route DICOM by Accession Number — IHE OBR-18 mapping — Per IHE RAD-TF, Accession Number lives in OBR-18 (Placer Field 1) for radiology

Per IHE RAD-TF, Accession Number lives in OBR-18 (Placer Field 1) for radiology orders. Some sites use OBR-3 or a Z-segment instead.

// (0008,0050) Accession Number — primary identifier for radiology orders
var accNum = String(msg.dataset.attr.(@tag == '00080050').value).trim();
if (!accNum) {
  // Reject incoming DICOM without an Accession Number — common WL/MWL workflow assumption
  destinationSet.removeAll();
  return;
}
tmp['OBR'][18] = accNum;
channelMap.put('accession', accNum); // also expose for downstream filters

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

  • high Accession Number truncation at 16 chars (SH limit)

    Diagnosis: Some EHRs (notably Epic legacy, some custom HIS) generate accession numbers >16 chars. DICOM's SH VR caps at 16 chars; the modality's Worklist SCU silently truncates, then the resulting study lands with a different (short) AccessionNumber than the order, breaking reconciliation.

    Fix: Either (a) constrain the source HIS to ≤16 chars, or (b) hash the long accession (e.g., MD5 first 16 chars) and maintain a mapping table for back-lookup. Long-term: pursue the SH-cap removal in IHE RAD profiles.

  • medium Accession Number used inconsistently across systems

    Diagnosis: Order entry uses ORC-2 (Placer Order Number) for a unique identifier, but the modality's AccessionNumber comes from OBR-18 (Placer Field 1) populated with a different value. DICOM's AccessionNumber doesn't match HIS's order.

    Fix: Per IHE RAD-TF Vol 2, AccessionNumber should be OBR-18. Audit your worklist SCP's mapping. Some sites use a Z-segment (ZDS-1) — confirm with your conformance statement.

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 AccessionNumber or the broader (0008,0050) context: