DICOM Attribute

Referring Physician's Name (0008,0090)

Keyword
ReferringPhysicianName
VR
PN
VM
1

Definition

Name of the Patient's referring physician.

From NEMA PS3.3 §C.7.2.1.

Attribute Metadata

Tag
(0008,0090)
Keyword
ReferringPhysicianName
Name
Referring Physician'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

  • ImagingStudy.referrer (0008,0090)+(0008,0096)

Source: HL7 FHIR R5 ImagingStudy (CC0).

HL7 v2 Equivalent

  • PV1-8 Referring Doctor
    ADTORMORU

    Also frequently appears in OBR-16 (Ordering Provider) for orders. Both PID PV1-8 and OBR-16 are XCN.

    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

Referring Physician Name is a Study-level QIDO-RS matching key on all three platforms.

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

  • 2721 waveform_ecg.dcm
  • Last Name^First Name reportsi.dcm

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

Mirth Connect Example

Map DICOM Referring Physician Name to HL7 v2 OBR-16 — PN format on both sides

PN format on both sides. ReferringPhysicianName mainly populates ORM/ORU OBR-16 (Ordering Provider) for radiology results.

// (0008,0090) Referring Physician's Name — XCN target on the HL7 v2 side
var pn = String(msg.dataset.attr.(@tag == '00080090').value).split('^');
tmp['OBR'][16][1] = ''; // ID Number — usually empty unless there's a separate identifier
tmp['OBR'][16][2] = pn[0] || ''; // family
tmp['OBR'][16][3] = pn[1] || ''; // given
tmp['OBR'][16][4] = pn[2] || ''; // middle

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

  • low Referring Physician name format inconsistency between RIS and modality

    Diagnosis: RIS sends ReferringPhysicianName as 'DR. JANE SMITH' (single component, all caps); DICOM PN expects family^given format. Modality may forward unchanged, causing downstream FHIR Practitioner.name parsing to fail.

    Fix: Normalize on perimeter: split on space/comma, identify family vs given via heuristic (last token = family for English-language names), strip honorifics ('DR.', 'M.D.'). Edge cases: hyphenated families, multi-token givens. Test against a representative sample.

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 ReferringPhysicianName or the broader (0008,0090) context: