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
Value Representation
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-18Placer Field 1 (Accession Number)ORMORUMost 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
-
03028041970546waveform_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:
- Medical Imaging & DICOM Integration — end-to-end PACS, VNA, and cloud imaging deployments
- Mirth Connect Services — production-grade Mirth channel development
- Healthcare AI Integration — DICOM pipelines for AI/ML inference