NEWFree ROI Calculators — quantify what prior auth and siloed data are costing your organization.Prior Auth ROI Siloed Data ROI
HL7 v2Code Table6 min read

HL7 Table HL70001: Administrative Sex

HL70001 is one of the oldest HL7-defined code tables, present since HL7 v2.1, and it carries the administrative (not clinical, not genetic) sex of a person. It sits behind PID-8 Administrative Sex on every patient demographic message, and is also referenced from STF-5 (Staff Identification) and NK1-15 (Next of Kin Administrative Sex). The values are intentionally short single-character codes drawn from the IS data type — six total in v2.8.1.

Purpose

HL70001 records the sex used for administrative, billing, and registration purposes. It is not a statement about gender identity, sex assigned at birth, chromosomal sex, or any clinical observation of sex characteristics; those are carried by separate fields in modern profiles (PID-35 and PID-36 from v2.9 onward, and the OMG-Ob segment in clinical genomics profiles). HL70001 answers a single narrow question: which value should the EHR display in the "Sex" box on the registration screen.

Because the table is HL7-defined, every conformant v2 receiver is expected to recognize the six codes below without local extension. Senders that need a richer concept (non-binary, gender identity, preferred pronouns) should populate the v2.9 gender identity fields rather than overloading PID-8.

Where it's used

  • PID-8 Administrative Sex — the canonical home of HL70001, populated on every ADT, ORM, ORU, and SIU message that carries a patient.
  • STF-5 Staff Administrative Sex — same code set applied to clinicians and staff in master-file messages.
  • NK1-15 Administrative Sex — next-of-kin sex on the NK1 segment.

Code list

CodeDisplayComment/Description
AAmbiguousSex cannot be determined from physical examination; commonly used for newborns pending workup.
FFemaleAdministrative female.
MMaleAdministrative male.
NNot applicableUsed for non-person subjects (devices, pooled specimens, environmental samples).
OOtherA value that does not fit M, F, A, N, or U — typically a non-binary administrative designation.
UUnknownSex is not known or has not been recorded.

Code system OID

  • OID: 2.16.840.1.113883.18.2
  • Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0001

The OID resolves on the HL7 Terminology server and is the value Vorro emits in CWE.14 when a downstream profile demands OID-bound coded values.

HL7-defined vs user-defined

HL70001 is HL7-defined. The table number falls inside the HL7-reserved range (HL70001–HL70999), and the code set is normative — receivers must accept all six values without local extension, and senders must not invent additional codes inside this table. Sites that need richer sex/gender semantics either use the v2.9 gender identity fields (PID-35) or carry the extra concept on a CWE field bound to a different value set; they do not extend HL70001 with local codes.

Version differences

  • v2.1 – v2.3 — Three values: M, F, U. Sufficient for early registration systems.
  • v2.3.1O (Other) added to accommodate non-binary administrative designations.
  • v2.4A (Ambiguous) added for newborn workflows where biological sex is genuinely indeterminate at registration.
  • v2.5N (Not applicable) added so the same field could carry sex for non-person subjects (devices, pooled specimens).
  • v2.6 – v2.8.1 — Set frozen at six codes; no further additions.
  • v2.9 — HL70001 itself is unchanged, but PID-35 Sex Parameter for Clinical Use was added alongside PID-8 to separate administrative sex from clinical sex.

Common mistakes

  • Sending the display word in PID-8 — Female instead of F. PID-8 is IS (or CWE in modern profiles), and the code value is the single-character symbol.
  • Treating PID-8 as a clinical sex field. M and F here say nothing about chromosomes, hormones, or anatomy; clinical sex belongs in PID-35 (v2.9+) or in a dedicated observation.
  • Defaulting unknown sex to M because the EHR demands a non-null value. U exists for exactly this case and must be used instead.
  • Extending HL70001 locally with T, X, NB, or vendor-specific values. HL70001 is HL7-defined; locally extended codes break conformance and FHIR mapping.
  • Confusing O (Other) with A (Ambiguous). O is a deliberate administrative designation chosen by the person; A describes physical indeterminacy.

Examples

A minimal PID with administrative sex F:

PID|1||10456^^^MRN^MR||DOE^JANE^A||19850412|F|||123 MAIN ST^^BOSTON^MA^02118||(617)555-1212|||S||10456|123-45-6789

Ambiguous newborn:

PID|1||N99821^^^MRN^MR||DOE^BABY^^^^^L||20260601|A|||456 OAK ST^^BOSTON^MA^02118

Same F value translated to a FHIR Patient.gender snippet:

{
  "resourceType": "Patient",
  "id": "10456",
  "gender": "female"
}

When the source carries OID metadata in a CWE-typed PID-8 (v2.7+ profile), FHIR consumers see a richer Coding:

{
  "gender": "female",
  "_gender": {
    "extension": [{
      "url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
      "valueCode": "unknown"
    }]
  }
}

Mapping failure example — unknown vendor code:

PID|1||10456^^^MRN^MR||DOE^JANE||19850412|X

X is not in HL70001. A conformant engine should route the message to a curation queue, preserve the original X in the audit log, and emit FHIR gender: unknown with a data-absent-reason extension rather than silently dropping the value.

FHIR mapping

The HL7 v2-to-FHIR Implementation Guide publishes ConceptMap-table-hl70001-to-administrative-gender, which collapses the six HL7 codes onto the four-value FHIR administrative-gender ValueSet:

HL7 v2 (HL70001)FHIR (administrative-gender)
Ffemale
Mmale
Aother
Oother
Nother
Uunknown

Patient.gender is a code element bound to http://hl7.org/fhir/ValueSet/administrative-gender. Because three v2 codes (A, O, N) all map to FHIR other, the original v2 code must be preserved as an extension if the receiver needs to round-trip back to HL7 v2.

Engine considerations

  • Single-character validation — PID-8 is one character; engines should reject multi-character payloads outright rather than truncate.
  • Case sensitivity — HL70001 codes are case-sensitive uppercase; f is not a valid code. Normalize on ingest.
  • CWE upgrade path — In v2.7+ profiles PID-8 may be transmitted as CWE rather than IS, allowing OID metadata in CWE.14 (2.16.840.1.113883.18.2). Engines must handle both shapes.
  • Round-trip preservation — When mapping to FHIR administrative-gender, store the original HL70001 code as an extension so the v2 outbound channel can restore A/O/N distinction.

How Vorro handles HL70001

Vorro validates PID-8 against the six HL70001 codes on ingest. Values that match are forwarded to all downstream channels untouched. Values that fail validation — including lowercase variants, vendor extensions, and accidental display strings — are routed to the terminology curation queue, where they either resolve to one of the six canonical codes (and a remap rule is created) or pass through with a soft warning so downstream systems are not silently fed bad data.

On outbound, Vorro emits HL70001 as IS for v2.5 and earlier profiles and as CWE with CWE.14 populated for v2.7+ destinations that advertise OID-bound coded values. The original HL70001 code is always preserved when round-tripping through FHIR Patient.gender.

Sources

← Back to HL7 v2 Guide

Ready to Integrate This Into Your Workflow?

Talk to a Vorro expert about implementing HL7 v2 in your specific environment.

Browse HL7 v2 Guides