DICOM Attribute

Patient's Name (0010,0010)

Keyword
PatientName
VR
PN
VM
1

Definition

Patient's full name.

From NEMA PS3.3 §C.7.1.1.

Attribute Metadata

Tag
(0010,0010)
Keyword
PatientName
Name
Patient's Name
Value Representation (VR)
PN
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 PN with multiplicity 1.

Used in 2 Modules

This attribute uses the PN 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-5 Patient Name
    ADTORMORUSIUDFT

    Direct mapping. PID-5 uses XPN (Extended Person Name) which decomposes the same 5 components as DICOM PN VR (family/given/middle/prefix/suffix).

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

Patient Name is a QIDO-RS Study-level matching key supported by all three vendors. Fuzzy matching support varies — AWS HealthImaging exact-match only; Azure supports fuzzy via PatientNameFuzzy parameter.

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

  • CompressedSamples^CT1 CT_small.dcm
  • CompressedSamples^MR1 MR_small.dcm
  • Anonymized ExplVR_BigEnd.dcm

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

Mirth Connect Example

Map DICOM Patient Name to HL7 v2 PID-5 — DICOM-to-HL7v2 channel

DICOM-to-HL7v2 channel. Inbound DICOM parsed to E4X XML by Mirth's DICOM Reader. Outbound HL7 v2 ADT or ORM message.

// (0010,0010) Patient's Name uses 5-component PN format: family^given^middle^prefix^suffix
var pn = String(msg.dataset.attr.(@tag == '00100010').value);
var parts = pn.split('^');
tmp['PID'][5][1] = parts[0] || ''; // family name complex
tmp['PID'][5][2] = parts[1] || ''; // given name complex
tmp['PID'][5][3] = parts[2] || ''; // middle name
tmp['PID'][5][4] = parts[3] || ''; // prefix
tmp['PID'][5][5] = parts[4] || ''; // suffix

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 Empty PatientName rejected by downstream PACS

    Diagnosis: Some PACS / VNA implementations mandate a non-empty (0010,0010). When the source DICOM has PatientName = '' or contains only delimiters ('^^^^'), the SCP returns Status 0xA900 (Identifier Does Not Match SOP Class) on STORE, or QIDO-RS returns 400.

    Fix: Default to '^^^^^^' (5 carets for empty 5-component PN) on the perimeter channel before forwarding. Alternatively, drop the message and notify upstream — never silently insert a fake name.

  • medium Multi-byte character encoding mismatch garbles non-ASCII names

    Diagnosis: Modality emits PatientName in ISO-IR 100 (Latin-1) but receiver expects UTF-8 (ISO-IR 192). The (0008,0005) Specific Character Set tag is set incorrectly or absent. Names with é, ü, ñ, or CJK characters render as mojibake (e.g., 'José' instead of 'José').

    Fix: Set (0008,0005) = 'ISO_IR 192' and re-encode the name as UTF-8 in your transformer. Mirth's `new java.lang.String(bytes, 'ISO-8859-1')` then `.getBytes('UTF-8')` is the canonical conversion.

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