DICOM Attribute
Study Instance UID (0020,000D)
- Keyword
StudyInstanceUID- VR
UI- VM
1
Definition
Unique identifier for the Study.
From NEMA PS3.3 §C.7.2.1.
Attribute Metadata
This attribute is part of the current DICOM Standard. Its value representation is UI with multiplicity 1.
Used in 7 Modules
Value Representation
This attribute uses the UI
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
-
ImagingStudy.identifierStudyInstanceUID (0020,000D) | study ID (0020,0010)
Source: HL7 FHIR R5 ImagingStudy (CC0).
HL7 v2 Equivalent
-
ZDS-1 / OBR-3Study Instance UID (custom Z-segment) or Filler Order NumberORMORUIHE RAD-TF defines ZDS-1 (a Z-segment) as the formal carrier for Study Instance UID. Many facilities instead overload OBR-3 (Filler Order Number) or include the UID as a comment NTE. 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 Required
- Azure DICOM Required
- Google Cloud Healthcare Required
Study Instance UID is required on Store and is a Study-level QIDO-RS matching key. AWS HealthImaging uses it as the primary key for ImageSet retrieval.
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
-
1.3.6.1.4.1.5962.1.2.1.20040119072730.12322CT_small.dcm -
1.3.6.1.4.1.5962.1.2.4.20040826185059.5457MR_small.dcm -
1.2.840.113619.2.21.848.246800003.0.1952805748.3ExplVR_BigEnd.dcm
Extracted from pydicom test fixtures (MIT, de-identified).
Mirth Connect Example
Use Study Instance UID for de-duplication — Idempotent ingestion pattern
Idempotent ingestion pattern. Hashed UIDs land in the global channel map as a TTL-style cache.
// (0020,000D) Study Instance UID — globally unique per study
var studyUID = String(msg.dataset.attr.(@tag == '0020000D').value).trim();
var seen = $gc('seen_studies') || new java.util.HashMap();
var now = Date.now();
// Expire entries older than 7 days
var iter = seen.entrySet().iterator();
while (iter.hasNext()) { if (now - iter.next().getValue() > 7 * 86400 * 1000) iter.remove(); }
if (seen.containsKey(studyUID)) {
logger.info('Duplicate study, skipping: ' + studyUID);
destinationSet.removeAll();
return;
}
seen.put(studyUID, now);
$gc('seen_studies', seen); 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 Same Study Instance UID re-used by mistake
Diagnosis: Modality firmware bug or operator error generates the same (0020,000D) for two different studies. Second study overwrites the first in the PACS or fails QIDO-RS lookup with ambiguous result.
Fix: Add a Mirth de-duplication filter: maintain `seen_studies` map in `globalChannelMap` keyed by StudyInstanceUID. On collision, route to a quarantine channel and notify the modality biomed team.
-
high UID exceeds 64-character cap
Diagnosis: DICOM UI VR caps at 64 chars. Some modalities concatenate vendor-specific suffixes that exceed the cap. PACS rejects with Status 0xC000.
Fix: Validate UID length before forward in your DICOM Reader transformer: `if (uid.length > 64) { reject }`. Notify modality vendor — UID generators must respect the cap.
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 StudyInstanceUID or the broader (0020,000D) 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