HL7 FT Data Type: Formatted Text

The FT (Formatted Text) data type has existed since HL7 v2.1 and is the v2 standard's way of carrying free-text content that needs light typographic structure — paragraph breaks, indentation, centering, and emphasis — without resorting to a full markup language. It is the underlying type for NTE-3 Comment, DSP-3 Display Data, and OBX-5 whenever OBX-2 is FT. Wherever a report narrative, clinical note, or human-readable annotation rides through a v2 interface, FT is almost always the type doing the work.

Purpose

FT extends ST with a small set of embedded formatting escape sequences. The intent is to let an information system convey simple presentation hints — "start a new line here", "center this title", "indent four spaces" — that survive transport across heterogeneous EHRs without negotiating fonts or stylesheets. FT is not HTML, RTF, or Markdown; it is a tightly scoped, vendor-neutral set of commands that have been stable since the early v2.x releases.

Format and constraints

FT is a primitive with no components or sub-components. Content is plain text plus inline escape sequences delimited by the message's escape character (default ``).

Formatting commands recognized by the standard:
- .br — begin a new line.
- .ce — end the current line and center the next.
- .sp N — emit N blank lines (defaults to 1 if N omitted).
- .fi — begin word-wrap (fill) mode.
- .nf — begin no-wrap (no-fill) mode; honor explicit line breaks only.
- .in N — set left indent to N spaces for subsequent lines.
- .ti N — temporary indent of N spaces for the next line only.
- H — turn highlighting on.
- N — return to normal (turn highlighting off).
Standard delimiter escapes apply just like ST: F, S, T, R, E.
Character set follows MSH-18; length governed by conformance profile (historic 1..65536 ceiling is deprecated in v2.7+).
The literal sequence .br is the only legal way to encode a hard newline; raw r or n bytes inside a field are illegal.

Where it's used

NTE-3 Comment — the canonical FT field; carries clinical, order, and result narratives.
OBX-5 Observation Value when OBX-2 = FT — formatted result narratives (radiology, pathology, transcribed reports).
DSP-3 Display Data — pre-formatted text intended for terminal display.
FT1-19 Diagnosis Code — Patient (historic usage in early v2 financial messages).
ERR-8 Diagnostic Information (FT in some profiles) — extended error narrative.
CSP-2 Study Phase Identifier text (legacy clinical study messages).
IN1-37 Verification Date/Time secondary text in some site-defined profiles.
Vendor-extended Z-segment narrative slots that mirror NTE-3's contract.

Version differences

FT has been remarkably stable. The escape command set above was finalized by v2.3 and has not been extended in v2.4 through v2.8.1. The only material change across versions 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.

Common mistakes

Embedding raw r or n bytes instead of .br — most parsers reject the segment outright because the carriage return is the segment terminator.
Forgetting to balance H with N. An unterminated highlight bleeds into following fields on rendering systems that honor it.
Sending HTML or RTF inside FT in the hope a receiver will render it. Conformant receivers treat the markup as literal characters.
Double-escaping on round-trip — re-applying F substitution to an already-encoded value produces FF and corrupts the narrative.
Using .sp without a number on engines that require an explicit count; some receivers silently drop the command.

Examples

Minimal:

Specimen received in good condition.

Multi-line with explicit break and indent:

IMPRESSION:.br\.in 41. No acute findings..br2. Recommend follow-up in 6 months.

Centered heading followed by body text:

.ceFINAL REPORT.br\.brPatient tolerated procedure well.

In context — NTE segment carrying a formatted comment:

NTE|1|L|HCRITICALN\.brPotassium 6.8 mmol/L confirmed on repeat draw..brProvider notified at 14:32.

In context — OBX with FT value type:

OBX|1|FT|RAD-CHEST^Chest X-Ray Report^L||.ceCHEST PA AND LATERAL.br\.brNo focal consolidation. Heart size normal.||||||F

Common pitfall:

WRONG:  NTE|1|L|Line one
        Line two
        A raw CR inside the field breaks the segment; the receiver sees "Line two" as a new (invalid) segment.
RIGHT:  NTE|1|L|Line one.brLine two

FHIR mapping

FT maps cleanly to FHIR Annotation, whose text element is Markdown. The published v2-to-FHIR IG includes a ConceptMap specifically for FT comment fields. HL7 formatting commands are either stripped or rewritten to Markdown equivalents: .br becomes a newline, H...N becomes **...**, .in N becomes leading spaces, and .ce is dropped (Markdown has no center directive).

See v2-to-FHIR IG ConceptMap — FT comment to Annotation.
When FT appears in an OBX whose target is Observation.valueString, the formatting commands are typically dropped rather than converted.
When FT carries a structured report, prefer DiagnosticReport.presentedForm with a text/plain rendering if downstream consumers cannot render Markdown.

Engine considerations

Decide once, project-wide, whether you preserve formatting commands verbatim or normalize them on ingress. Mixing strategies across pipelines guarantees diff noise on replay.
.br is the only safe paragraph delimiter — never inject rn from a Windows-origin source without translating it first.
Maintain an explicit allow-list of recognized formatting commands; treat unknown .... sequences as opaque so a future v2.9 extension does not corrupt round-trips.
Conformance profiles often cap NTE-3 length even though the type is unbounded; enforce caps at the egress boundary, not silently mid-pipeline.
Some EHRs reject FT containing X.. hex escapes — surface the rejection rather than retrying blindly.
Be defensive about non-breaking spaces and Unicode line separators (U+2028, U+2029) that some transcription systems emit; convert them to .br on ingest.

How Vorro parses and produces FT

Vorro parses FT in two passes. The first pass unescapes the delimiter sequences (F S T R E) exactly once, yielding canonical Unicode text. The second pass tokenizes the formatting commands into a small structured tree (paragraph, indent, highlight) that downstream FHIR mappers can rewrite to Markdown or strip wholesale — controlled by a per-route policy.

On outbound we re-emit the formatting tree as canonical FT, normalizing whitespace and ordering so two semantically identical narratives serialize byte-for-byte the same. We never inject raw CRLF inside an FT field, and we surface unknown .... commands as opaque tokens rather than dropping them, so round-trips through Vorro never silently lose vendor-specific extensions.

Sources

← Back to HL7 v2 Guide