DICOM Attribute

Patient ID (0010,0020)

Keyword
PatientID
VR
LO
VM
1

Definition

Primary identifier for the Patient. In the case of imaging a group of small animals simultaneously, the single Value of this identifier corresponds to the identification of the entire group. See also .

From NEMA PS3.3 §C.7.1.1.

Attribute Metadata

Tag
(0010,0020)
Keyword
PatientID
Name
Patient ID
Value Representation (VR)
LO
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 LO with multiplicity 1.

Used in 4 Modules

This attribute uses the LO 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

  • PID-3 Patient Identifier List
    ADTORMORUSIUDFT

    PID-3 is a repeating CX field; DICOM PatientID typically maps to the MRN entry (PID-3.1 with PID-3.5 = 'MR').

    Source: IHE RAD-TF Vol 2 §4.1

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

Patient ID is required on Store across all three vendors and is a Study-level QIDO-RS matching key. 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

  • 1CT1 CT_small.dcm
  • 4MR1 MR_small.dcm
  • id00001 rtplan.dcm

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

Mirth Connect Example

Map DICOM Patient ID to HL7 v2 PID-3 with identifier type — DICOM-to-HL7v2 channel

DICOM-to-HL7v2 channel. PID-3 is repeating CX; the MRN entry needs PID-3.5='MR' to be parseable by EHRs.

// (0010,0020) Patient ID — most facilities expect MRN form in PID-3.1 with MR as type
var mrn = String(msg.dataset.attr.(@tag == '00100020').value);
tmp['PID'][3][1][1] = mrn;            // ID Number
tmp['PID'][3][1][4][1] = 'MyHospital'; // Assigning Authority Namespace ID
tmp['PID'][3][1][5] = 'MR';            // Identifier Type Code

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 Patient ID conflicts between EHR MRN and DICOM PatientID

    Diagnosis: EHR is the source of truth for MRN but the modality's worklist query returned a different PatientID (e.g., the visit number). DICOM lands with the wrong PatientID and breaks patient reconciliation downstream.

    Fix: Apply Mirth-side reconciliation: query the EHR (via FHIR Patient resource or HL7 v2 QBP) using the DICOM AccessionNumber, fetch the canonical MRN, and rewrite (0010,0020) before forwarding to the long-term archive.

  • medium Leading-zero stripping breaks lookups

    Diagnosis: PatientID '00012345' arrives correctly but the Mirth transformer reads it as integer (12345) and emits the integer form downstream. EHR lookups on '12345' fail to match the canonical zero-padded MRN.

    Fix: Always read PatientID as String — never `parseInt`. In Mirth: `String(msg.dataset.attr.(@tag == '00100020').value)` not `parseInt(...)`.

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 PatientID or the broader (0010,0020) context: