HL7 TX Data Type: Text Data

The TX (Text Data) data type has existed since HL7 v2.1 and sits between ST and FT on the v2 spectrum of textual primitives. It carries free-text content — sentences, paragraphs, descriptive notes — that does not need the typographic command vocabulary of FT but is too long or too prose-shaped to belong in ST. Its most visible appearance is in OBX-5 whenever OBX-2 is TX: a textual observation result with no formatting requirements.

Purpose

TX exists for prose. Where ST is meant for atomic strings (a surname, a catalog number) and FT layers on formatting commands, TX is the unadorned middle ground: human-readable text containing words, sentences, punctuation, and whitespace, but no .br-style directives. A receiver that renders TX simply displays it; there is no presentation contract beyond "show the characters".

Format and constraints

TX is a primitive with no components or 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.
Whitespace, including multiple consecutive spaces, is significant and must be preserved.
Length: historically 1..65536 in early versions. v2.7 deprecated fixed maximum lengths in favour of conformance-profile constraints; HAPI v2.8.1 imposes no length cap at the type level.
Delimiter escapes are identical to ST and FT:
- F — field separator (|)
- S — component separator (^)
- T — subcomponent separator (&)
- R — repetition separator (~)
- E — escape character (``)
Formatting commands (.br, .ce, H, etc.) are not part of TX. Sending them is technically legal as opaque text but receivers should not interpret them.
Empty content "" is the HL7 delete sentinel, just as with ST.

Where it's used

OBX-5 Observation Value when OBX-2 = TX — the canonical use; carries prose results such as a transcribed impression or a free-text comment.
NTE-3 Comment in legacy profiles that predate the FT switchover (rare in modern messages).
ERR-7 Diagnostic Information in v2.5+ when an implementer chose TX over FT for the error narrative.
DSC-1 Continuation Pointer secondary descriptor text in some site profiles.
BUI-13 Container Comment in vendor-specific blood-bank flows.
Z-segment narrative slots where an implementer wants prose without formatting.
Order-entry "special instructions" fields in legacy OBR variants.
Result narrative in lab interfaces where the LIS cannot emit FT.

Version differences

TX has been stable since v2.1. The escape rules have not changed. The only material evolution is the v2.7 deprecation of fixed maximum lengths in favour of conformance-profile constraints. HAPI v2.8.1 imposes no length cap at the type level. Across v2.7.1, v2.8, v2.8.1, and v2.8.2 there are no changes to the type.

Common mistakes

Embedding .br or other FT formatting commands inside TX. Conformant receivers treat them as literal text, producing visible .br markers in the rendered narrative.
Sending un-escaped & or ^ inside a sentence — receivers split the value on those characters because they are delimiters at higher levels of the encoded message.
Stripping consecutive spaces. A clinician's intentional double space or tabular alignment in a narrative is lost.
Confusing TX with ST in OBX. If OBX-2 says ST, downstream graders may flag a multi-line TX-shaped value as a conformance violation.
Sending "" (two literal double quotes) to mean "the user typed an empty string" — in HL7 v2 that token is the delete sentinel.

Examples

Minimal:

Patient tolerated the procedure well.

Sentence with escaped delimiters (a literal Smith & Jones | Lab would be):

Smith T Jones F Lab

Longer prose with internal punctuation:

The patient reports intermittent chest discomfort, worse on exertion, relieved by rest. No syncope. No dyspnea at rest.

In context — OBX with TX value type:

OBX|1|TX|IMP^Impression^L||No acute cardiopulmonary process. Recommend clinical correlation.||||||F

In context — TX carrying a free-text comment within a legacy NTE:

NTE|1|L|Specimen received room temperature, processed within thirty minutes.

Common pitfall:

WRONG:  OBX|1|TX|IMP^Impression^L||Findings: A&B noted on chest film||||||F
        The literal `&` is the subcomponent delimiter; the receiver splits "A" and "B" into separate subcomponents.
RIGHT:  OBX|1|TX|IMP^Impression^L||Findings: ATB noted on chest film||||||F

FHIR mapping

TX maps cleanly to the FHIR string primitive in most contexts, and to Markdown-typed elements such as Annotation.text when the surrounding container expects narrative. There is no per-datatype ConceptMap published in the v2-to-FHIR IG for TX specifically — the mapping is dictated by the target FHIR element, exactly as for ST.

OBX-5 (TX) typically maps to Observation.valueString when no coded observation is appropriate.
TX appearing in error or comment slots maps to OperationOutcome.issue.diagnostics or Annotation.text.
TX never carries codes, so it does not map to CodeableConcept directly.

Engine considerations

Preserve whitespace exactly. Many laboratory narratives align sub-results with spaces; trimming or collapsing whitespace destroys the layout.
Escape and unescape exactly once. The F S T R E substitution is identical to ST and FT — share one routine across all three types.
Do not interpret FT formatting commands found inside a TX field. Pass them through as literal characters and let conformance tooling flag the producer.
Per-profile length caps should be enforced at the boundary; HAPI v2.8.1 does not truncate TX automatically.
TX content frequently arrives with embedded Unicode line separators from rich-text sources. Decide on a normalization policy (drop, replace with space, convert to .br and change type to FT) and apply it consistently.
The "" delete sentinel applies to TX exactly as it does to ST.

How Vorro parses and produces TX

Vorro treats TX identically to ST at the byte level — unescape exactly once on ingress, retain the original encoded form alongside the decoded value, surface "" as a typed Deleted marker. The only difference is the policy layer: Vorro flags TX values that contain .br or other FT commands as a soft conformance warning, because such content almost always belongs in an FT-typed field.

On outbound we re-apply the five canonical delimiter escapes and preserve all internal whitespace. Vorro never silently rewrites a TX value to FT (or vice versa); type changes are explicit, logged, and visible in replay diffs.

Sources

← Back to HL7 v2 Guide