HL7 FN Data Type: Family Name

The FN (Family Name) data type was introduced in HL7 v2.5 to structure compound surnames — Spanish names with particles ("de la Cruz"), Dutch and German names with tussenvoegsels ("van der Berg"), Portuguese double-barreled surnames — so that downstream systems can sort, search, and display them correctly. Before v2.5 the entire surname was a single ST inside XPN.1, which meant "de la Cruz" sorted under "d" instead of "C" and "van der Berg" fell apart when a system tried to extract the "real" surname.

FN is rarely used as a top-level field type. It appears as the sub-type of XPN.1 (Family Name on the extended person name composite) and XCN.2 (Family Name on the extended composite ID+name for persons). Whenever you see a surname inside a v2.5+ name composite, FN is the structure underneath it.

Purpose

FN exists to separate the culturally significant pieces of a surname so the receiver can render and sort them appropriately:

• The own surname (the part inherited from the person's own family).
• The own-surname prefix (a particle attached to the own surname, like "de la" or "van der").
• The partner/spouse surname and its prefix (used in cultures where a partner's name is appended rather than replacing the maiden name, or where double-barreled surnames mix both lineages).

A simple Anglo surname populates only FN.1 (Surname) and leaves FN.2–FN.5 empty. A Spanish "Maria de la Cruz" populates FN.1 with the full surname for display but additionally populates FN.2 = "de la" and FN.3 = "Cruz" so a search index can file her under "C".

Components

Source: HAPI HL7v2 v2.8.1 javadoc (FN). Length is not published in the v2.8.1 javadocs (—).

Most-used components

• FN.1 Surname — usually the only component populated. For Anglo names this is the whole story.
• FN.2 Own Surname Prefix + FN.3 Own Surname — populated together for compound own surnames ("de la" + "Cruz", "van der" + "Berg").
• FN.4 Surname Prefix from Partner/Spouse + FN.5 Surname from Partner/Spouse — populated when a partner-derived surname is exchanged structurally (less common in clinical exchange; more common in registries and vital records).

Where it's used

FN is rarely a top-level field type. It appears as the sub-type of two name composites, both of which surface in many segments:

• XPN.1 Family Name — used on every patient name field: PID-5 Patient Name, PID-6 Mother's Maiden Name, PID-9 Patient Alias, NK1-2 Name, IN1-16 Insured's Name, GT1-3 Guarantor Name.
• XCN.2 Family Name — used on every practitioner name field: PV1-7 Attending Doctor, PV1-8 Referring Doctor, ORC-12 Ordering Provider, OBR-16 Ordering Provider, OBR-32 Principal Result Interpreter, NK1-30 Contact Person Identifier.

Because FN is nested inside XPN.1 or XCN.2, its components are sub-sub-components on the wire. In a flat PID-5 like de la Cruz^Maria^Elena^^^^L, the surname de la Cruz populates XPN.1, and inside XPN.1 the FN sub-components are delimited by &: de la Cruz&de la&Cruz^Maria^Elena^^^^L.

Version differences

• v2.4 and earlier — No FN type. Surnames were a single ST inside XPN.1. Compound surnames had no structured representation.
• v2.5 — FN introduced with all five components shown above. XPN.1 and XCN.2 retyped from ST to FN.
• v2.6 / v2.7 / v2.8 / v2.8.1 — no structural changes; HAPI v2.8.1 javadoc shows the identical five-component structure.
• v2.8.2 — FN unchanged.

Common mistakes

• Putting a compound surname only into FN.1 and leaving FN.2/FN.3 empty. The display works, but downstream sort/search by "real" surname fails. "de la Cruz" sorts under "d" instead of "C".
• Sending FN.2 ("de la") without FN.3 ("Cruz"). FN.2 alone is meaningless — it is a particle that requires the own surname to attach to.
• Stuffing the partner surname into FN.1 with a hyphen ("Smith-Garcia") instead of splitting it across FN.3 (own = "Smith") and FN.5 (partner = "Garcia"). Hyphenated forms display correctly but cannot be programmatically separated.
• Treating FN as a top-level field type. FN almost never appears at the field level; it is the sub-type of XPN.1 and XCN.2 and lives one level down on the wire. Engines that look for FN at the field position miss it.
• Using ^ to delimit FN components inside XPN.1. Because FN is nested inside a composite, its component delimiter on the wire is & (sub-component), not ^. Senders that emit de la Cruz^de la^Cruz^Maria flatten the FN into XPN siblings and corrupt the given-name slot.

Examples

Minimal value

Smith

Just the surname; FN.2–FN.5 empty. Covers most Anglo names.

Multi-component value — Spanish compound surname

de la Cruz^de la^Cruz

FN.1 carries the full display surname, FN.2 the prefix, FN.3 the bare own surname. A sort index keyed on FN.3 files this person under "C".

Fully populated — Dutch compound with partner surname

van der Berg-de Vries^van der^Berg^de^Vries

• FN.1 = van der Berg-de Vries (full display)
• FN.2 = van der (own-surname prefix)
• FN.3 = Berg (own surname)
• FN.4 = de (partner-surname prefix)
• FN.5 = Vries (partner surname)

A receiver can render the legal form, search by either lineage, and produce localized variations.

Annotated breakdown

van der Berg-de Vries        FN.1  Surname (full display)
^van der                     FN.2  Own Surname Prefix
^Berg                        FN.3  Own Surname
^de                          FN.4  Surname Prefix from Partner/Spouse
^Vries                       FN.5  Surname from Partner/Spouse

In-context excerpt — FN inside XPN.1 inside PID-5

Because FN nests inside XPN.1, its delimiter on the wire is &, not ^:

PID|1||MRN-554122^^^MERCY^MR||de la Cruz&de la&Cruz^Maria^Elena^^^^L||19780214|F

• PID-5.1 (XPN.1) is the FN composite de la Cruz&de la&Cruz:
  • FN.1 = de la Cruz
  • FN.2 = de la
  • FN.3 = Cruz
• PID-5.2 (XPN.2) = Maria (given name)
• PID-5.3 (XPN.3) = Elena (middle)
• PID-5.7 (XPN.7) = L (legal)

In-context excerpt — FN inside XCN.2 inside OBR-16

OBR|1|ORD-7742|ACC-9921|11218-5^Microbiology studies^LN||20260610090000|||||||||99834^de la Cruz&de la&Cruz^Maria^Elena^^DR^^^MERCY&2.16.840.1.113883.19.5&ISO^L^^^NPI^^^^^^^^MD

XCN.2 carries the FN composite de la Cruz&de la&Cruz. Note the same & delimiter — both XCN.2's FN sub-components and XCN.9's HD sub-components share it because both are nested one level deeper than the surrounding XCN.

Common pitfall snippet

PID|1||MRN-554122^^^MERCY^MR||de la Cruz^Maria^Elena^^^^L

The sender placed "de la Cruz" in FN.1 only and left FN.2 / FN.3 empty. The patient displays correctly but every sort and search treats "de" as the first letter of the surname. Downstream MPI systems often re-key her as "Cruz, Maria de la" with reversed casing, fragmenting her record.

FHIR mapping

The v2-to-FHIR IG publishes a single ConceptMap for FN:

• FN → HumanName

FHIR's HumanName.family is a single string, but the ISO 21090 extensions (http://hl7.org/fhir/StructureDefinition/humanname-own-prefix, humanname-own-name, humanname-partner-prefix, humanname-partner-name) preserve the structured pieces that FN carries. Receivers that ignore the extensions still get a readable surname; receivers that consume them get sortable own-surname semantics.

Engine considerations

• Delimiter level: FN lives inside XPN.1 or XCN.2, so its component delimiter on the wire is & (sub-component), not ^ (component). Engines that re-tokenize XPN.1 with ^ to "split the surname" destroy adjacent XPN components.
• Preserving compound-surname semantics on normalization: When normalizing FN to FHIR HumanName.family, do not collapse FN.2/FN.3/FN.4/FN.5 into FN.1 silently. Emit the ISO 21090 extensions so the structure round-trips.
• MPI matching: Patient-matching algorithms keyed on surname must compare FN.3 (the bare own surname) rather than FN.1 when comparing across cultures. Comparing FN.1 cross-culture treats "de la Cruz" and "Cruz" as different people.
• HAPI typing: HAPI v2.8.1 strongly types XPN.1 as FN; engines that downcast to ST to call .getValue() get only FN.1 back and lose FN.2–FN.5.
• Backward compatibility with v2.4 receivers: When sending to a pre-v2.5 receiver, collapse FN.2–FN.5 into FN.1 and emit only FN.1. Sending sub-components to a v2.4 receiver yields a parse error or a corrupted surname.

How Vorro parses and produces FN

On inbound, Vorro parses XPN.1 and XCN.2 as the FN composite they are: FN.1 becomes the display surname, FN.2 + FN.3 (when populated) become structured own-surname-prefix and own-surname slots, and FN.4 + FN.5 the partner equivalents. The internal Name model carries all five, and Vorro's MPI matcher keys on FN.3 when present and FN.1 when not, with a configurable particle list (de, de la, van, van der, von, du, da, dos) that lets the matcher derive FN.3 heuristically from FN.1 for legacy senders.

On outbound, Vorro emits FN.1 always, and FN.2/FN.3 when the internal record carries a recognized particle. Partner-derived components are emitted only for destinations advertising v2.5+ support; pre-v2.5 destinations get a collapsed FN.1 with a soft warning logged so the downgrade is auditable. The FHIR exporter emits the ISO 21090 extensions on HumanName.family whenever FN.2–FN.5 are present.

Related pages

• XPN data type — Extended Person Name
• XCN data type — Extended Composite ID Number and Name for Persons
• PID segment — Patient Identification

Sources

• HAPI HL7v2 v2.8.1 javadoc — FN
• HAPI HL7v2 v2.8.1 apidocs index
• HL7 v2 product brief
• v2-to-FHIR ConceptMap — FN to HumanName