DICOM Attribute

Patient Position (0018,5100)

Keyword
PatientPosition
VR
CS
VM
1

Definition

Patient position descriptor relative to the equipment. Required for images where Patient Orientation Code Sequence (0054,0410) is not present and whose SOP Class UID (0008,0016) is one of the following: "1.2.840.10008.5.1.4.1.1.2" (CT Image Storage), "1.2.840.10008.5.1.4.1.1.4" (MR Image Storage), "1.2.840.10008.5.1.4.1.1.2.1" (Enhanced CT Image Storage), "1.2.840.10008.5.1.4.1.1.4.1" (Enhanced MR Image Storage), "1.2.840.10008.5.1.4.1.1.4.3" (Enhanced Color MR Image Storage), "1.2.840.10008.5.1.4.1.1.4.2" (MR Spectroscopy Storage SOP Class). May be present for other SOP Classes if Patient Orientation Code Sequence (0054,0410) is not present. See for Defined Terms and further explanation.

From NEMA PS3.3 §C.7.3.1.

Attribute Metadata

Tag
(0018,5100)
Keyword
PatientPosition
Name
Patient Position
Value Representation (VR)
CS
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 CS with multiplicity 1.

Used in 4 Modules

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

No standard HL7 v2 equivalent published for this attribute. Imaging-only attributes (Image Pixel data, technical acquisition parameters, modality-specific values) typically have no HL7 v2 carrier.

Cloud DICOM Support

AWS HealthImaging, Azure DICOM, and GCP Healthcare DICOM coverage rolls out by attribute. The QIDO-RS matching keys + Patient/Study/Series core (~50 attributes) are documented; lower-traffic attributes will be added as Saga teams encounter them in production.

Real-World Sample Values

  • FFS CT_small.dcm
  • HFS MR_small.dcm

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

Mirth Connect Example

Patient Position parse — HFS / FFP / LFS for worklist display — PatientPosition is a DICOM defined term (HFS=Head First Supine, FFS=Feet First S

PatientPosition is a DICOM defined term (HFS=Head First Supine, FFS=Feet First Supine, etc.). RIS worklist tickets often want the expanded form.

// (0018,5100) Patient Position — CS defined term
var pp = String(msg.dataset.attr.(@tag == '00185100').value).trim().toUpperCase();
var positions = {
  'HFS': 'Head First - Supine',
  'HFP': 'Head First - Prone',
  'HFDR': 'Head First - Decubitus Right',
  'HFDL': 'Head First - Decubitus Left',
  'FFS': 'Feet First - Supine',
  'FFP': 'Feet First - Prone',
  'FFDR': 'Feet First - Decubitus Right',
  'FFDL': 'Feet First - Decubitus Left'
};
channelMap.put('patient_position_code', pp);
channelMap.put('patient_position_text', positions[pp] || pp);

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 PatientPosition HFS/FFS swap causes z-axis flip in 3D reconstruction

    Diagnosis: Patient scanned feet-first but technologist left modality set to default HFS. 3D MPR/MIP reconstructions render the patient inverted. Clinicians may miss pathology on the wrong side.

    Fix: Cross-check PatientPosition against ImageOrientationPatient at reconstruction time. Flag studies where the two are inconsistent for review. Some viewers auto-correct silently; explicit alerts prevent downstream confusion.

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 PatientPosition or the broader (0018,5100) context: