DICOM Attribute

Patient's Sex (0010,0040)

Keyword
PatientSex
VR
CS
VM
1

Definition

Sex of the named Patient. See Note 2 and Note 3. Enumerated Values: M male F female O other

From NEMA PS3.3 §C.7.1.1.

Attribute Metadata

Tag
(0010,0040)
Keyword
PatientSex
Name
Patient's Sex
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 2 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

  • PID-8 Administrative Sex
    ADTORMORU

    Same code values: M, F, O, U (and DICOM-only A for Ambiguous when absent in HL7 v2).

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

Patient Sex is preserved but not exposed as a QIDO-RS matching key by any vendor.

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

  • O CT_small.dcm
  • F MR_small.dcm

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

Mirth Connect Example

Validate DICOM Patient Sex against HL7 v2 PID-8 enum — Both standards use M/F/O/U code values

Both standards use M/F/O/U code values. Some legacy modalities emit non-standard codes; normalize before transmission.

// (0010,0040) Patient's Sex — normalize to HL7 v2 administrative-sex codes
var sexRaw = String(msg.dataset.attr.(@tag == '00100040').value).toUpperCase().trim();
var valid = { 'M': 'M', 'F': 'F', 'O': 'O', 'U': 'U', 'A': 'A' };
tmp['PID'][8] = valid[sexRaw] || 'U'; // U = Unknown when source is non-standard

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 Patient Sex non-standard codes from legacy modalities

    Diagnosis: Older modalities emit non-standard sex codes ('1', '2', 'MALE', 'FEMALE'). DICOM CS expects M/F/O/U; downstream EHRs reject anything else.

    Fix: Normalize on perimeter. Mirth lookup table: `{'M':'M','F':'F','O':'O','U':'U','1':'M','2':'F','MALE':'M','FEMALE':'F'}`. Default to 'U' on unknown.

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