HL7 ST Data Type: String

The ST (String) data type has existed since HL7 v2.1 and is the simplest non-numeric primitive in v2 messaging. It carries a single run of printable characters with no internal structure. ST is the underlying type for an enormous portion of the standard — every component-level free-text field eventually bottoms out at ST. PID-5.1 Family Name (an XPN whose FN.1 component is ST), ORC-3 Filler Order Number (an EI whose first component is ST), and OBX-5 when OBX-2 is ST are three of the most visible examples.

Purpose

ST represents short, unstructured character data. Where FT (formatted text) and TX (text data) allow embedded formatting and multi-line content, ST is meant for atomic strings: a surname, a catalog number, an identifier component, a short label. It carries no semantics of its own — meaning comes entirely from the field that holds it.

Format and constraints

ST is a primitive: it has no components and no sub-components.

Character set: any printable character from the message's declared character set (MSH-18 / MSH-20), excluding the five HL7 delimiters in their literal form.
Length: historically 1..199 in v2.5 and earlier. v2.7 deprecated fixed maximum lengths in favour of conformance-profile constraints; HAPI v2.8.1 imposes no length cap at the type level.
Delimiters inside an ST value must be escaped using the HL7 escape sequences declared in MSH-2 (default ``):
- F — field separator (|)
- S — component separator (^)
- T — subcomponent separator (&)
- R — repetition separator (~)
- E — escape character itself (``)
Additional sequences X.. (hex), Zxx (locally defined), and Cxxxx / Mxxxxxx (character-set switching) are permitted but rarely used.
Leading and trailing whitespace is significant; receivers should not trim unless a profile says so.
Empty content ("") explicitly means "delete on update"; a truly absent field is left blank with no quotes.

Where it's used

ST sits beneath many composite types. Common appearances:

PID-5.1 Family Name (XPN → FN → ST) — the patient's surname.
PID-5.2 Given Name (XPN → ST) — first name.
PID-3.1 ID Number (CX → ST) — the literal MRN string.
ORC-3.1 Entity Identifier (EI → ST) — order filler identifier.
MSH-10 Message Control ID (ST directly) — message identity.
OBX-5 Observation Value when OBX-2 = ST — a textual result.
BUI-8 Container Catalog Number (ST directly) — see BUI.
BUI-9 Container Lot Number (ST directly).
DON-25 Apheresis Type Machine (ST directly) — see DON.
IAR-4 Management (ST directly) — see IAR.

Version differences

v2.1 through v2.6: ST defined with a recommended 1..199 length.
v2.7: fixed maximum length deprecated; length now governed by conformance profile.
v2.7.1, v2.8, v2.8.1, v2.8.2: no changes to the type. Escape rules unchanged since v2.3.

Common mistakes

Sending a literal |, ^, ~, &, or `` inside an ST without escaping — receivers parse the character as a delimiter and split the value.
Double-escaping on round-trip — applying F substitution twice produces FF and corrupts the value.
Stripping leading/trailing spaces. A name like " McDonald" (with a leading space) is rare but legal; silent trimming changes the data.
Sending "" (two double quotes) to mean "empty string" when the sender actually means "null" — in HL7 v2 those quotes are the delete sentinel.
Sending multi-line content in ST. Use FT or TX for anything with newlines.

Examples

Minimal:

SMITH

Value containing escaped delimiters (the literal name Smith^Jones & Co|Ltd would be written as):

SmithSJones T CoFLtd

Value containing an escaped backslash (e.g. a Windows path stored as a catalog reference):

C:ECatalogEREF-4R5400

In context — PID-5 carrying ST components for family and given name:

PID|1||MR884412^^^MERCY^MR||OTBrien^Patrick^J^^Mr.||19720508|M

In context — OBX-5 with ST value type and an escaped delimiter inside a textual result:

OBX|1|ST|GEN-NOTE^Generic Note^L||Specimen lipemicS result reviewed by pathologist||||||F

Common pitfalls:

WRONG:  PID|1||MR1^^^MERCY^MR||AT&T^Inc.||...
        The literal `&` is the subcomponent delimiter; receivers will split "AT" and "T".
RIGHT:  PID|1||MR1^^^MERCY^MR||ATTT^Inc.||...

FHIR mapping

A primitive's FHIR target is dictated by the containing element, not the type itself. The v2-to-FHIR IG publishes several ConceptMaps that show the legal targets:

ST → string — the default mapping when the containing element is a FHIR string-typed property (e.g. HumanName.family).
ST → CodeableConcept — used when the containing v2 field is a coded textual value with no separate code component.
ST → Identifier — used when the ST is the literal value portion of an identifier element (typical for the value inside an EI or CX).

Choose the target by following the parent field's mapping; ST itself never picks.

Engine considerations

Escape-sequence round-tripping is the single biggest correctness risk. Engines must escape on serialize and unescape on parse exactly once; double-escaping or skipping a layer is a common source of corrupted names.
Per-profile maximum length should be enforced at the boundary rather than at the type. HAPI v2.8.1 does not truncate ST automatically.
Character-set switching via Cxxxx / Mxxxxxx is rarely encountered; engines that strip unknown escape sequences will silently lose those bytes.
Preserve significant whitespace; do not call .trim() on raw ST values unless the conformance profile mandates it.
"" (two literal double quotes) is the HL7 "delete" sentinel, distinct from a blank field — represent both states explicitly in your model.

How Vorro parses and produces ST

Vorro's parser unescapes ST exactly once during ingress and stores the canonical Unicode string. The original encoded form is retained alongside the decoded value so that any downstream replay can be re-emitted byte-identical to the source — useful for audit, and required for some legacy gateways that hash the raw segment. We surface the HL7 delete sentinel ("") as a typed Deleted marker rather than coercing it to an empty string.

On outbound, Vorro re-applies the five canonical escape sequences (F S T R E) against the message's declared encoding characters from MSH-2. We never emit X.. hex escapes for ordinary text; profile-specific length caps are enforced at the egress boundary so truncations are explicit rather than silent.

Sources

← Back to HL7 v2 Guide