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

  • Patient.identifier PatientID ↔ Patient.identifier where system identifies the issuing assigning authority (commonly a local hospital MRN namespace). Use a coded type like MR (Medical Record Number) per HL7v2-0203.

Source: HL7 FHIR R5 ImagingStudy (CC0).

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

  • MRN0012345 common US hospital MRN

    Local MRN — typically 6-10 digits, sometimes with prefix

  • 1234567890 common pattern

    Pure-numeric MRN (Cerner/Oracle Health default style)

  • JH-12345-EHR compound MRN pattern

    Hyphenated — facility-prefix + ID + system-suffix

  • ANON-2026-001 research dataset pattern

    Pseudonymized for research (TCIA/IDC convention)

Curated illustrative samples — no real PHI. Each value teaches a real-world pattern (PN VR component delimiters, multi-script encoding, MRN format, RadLex order text). Maintained at scripts/dicom/data/manual-samples.source.json.

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: