HL7 CF Data Type: Coded Element with Formatted Values

The CF (Coded Element with Formatted Values) data type was introduced in HL7 v2.3 as a sibling of CE. Structurally it replaces CE's plain-text "Text" component with a FT (Formatted Text) component, so the displayed value can carry embedded HL7 formatting escape sequences — .br for line break, H…N for highlight, .sp N for vertical space, .in N for indent. CF is rare in production traffic; it exists for the small set of fields where the receiving system must render the display string with HL7-defined visual formatting rather than as a plain string.

Purpose

CF answers a narrow but real need: occasionally a coded value's display text is not a single line of plain text but a small formatted block — a multi-line label, a highlighted abbreviation, an indented qualifier — and the sender wants the receiver to render the formatting deterministically. CE cannot do this (its Text component is ST) and CWE deliberately did not pick it up either. CF therefore occupies a niche between CE and the modern CWE: same six-component shape as CE, but with FT in the display slots.

The "Formatted Values" in the name refers strictly to the display text. The codes themselves (CF.1, CF.4) are plain ST as in every other coded composite — they are not formatted.

Component reference

Source: HAPI HL7v2 v2.8.1 javadocs — CF. CF has 6 components separated by ^. Length is not published in the javadocs (—).

Seq	Name	Data Type	Length	Req	Description
CF.1	Identifier	st	—	C	Primary code value. At least one of CF.1 / CF.4 must be present.
CF.2	Formatted Text	ft	—	O	Display text for CF.1, with HL7 formatting escape sequences permitted.
CF.3	Name of Coding System	id	—	C	Coding system for CF.1 — drawn from HL7 table [HL70396]. Required when CF.1 is present.
CF.4	Alternate Identifier	st	—	C	Equivalent code from a second coding system.
CF.5	Alternate Formatted Text	ft	—	O	Display text for CF.4, with HL7 formatting escape sequences permitted.
CF.6	Name of Alternate Coding System	id	—	C	Coding system for CF.4 — drawn from HL7 table [HL70396].

The shape is identical to CE: a primary triplet (1–3) and an alternate triplet (4–6). The only structural difference is the FT type on CF.2 and CF.5.

Most-used components

CF.1 Identifier — the code; the value every consumer reads first.
CF.2 Formatted Text — the formatted display string; the entire reason CF exists. Common escape sequences: .br (line break), H…N (start/end highlight), .sp N (vertical space), .in N (indent), .ti N (temporary indent), .fi / .nf (fill / no-fill).
CF.3 Name of Coding System — disambiguates CF.1. Drawn from [HL70396], the same coding-system name table used by CE / CWE / CNE.
CF.4 / CF.5 / CF.6 — the alternate triplet, used when the receiver may know the alternate vocabulary but not the primary one.

Where it's used

CF appears in a handful of legacy fields whose specifications expected formatted display text. Representative fields (profile-dependent — many sites substitute CWE in modern installations):

OBX-3 Observation Identifier — in v2.3 profiles where the observation identifier carried formatted display text.
OBX-5 Observation Value — when the result is itself a coded element with formatted display.
DG1-3 Diagnosis Code — in older profiles before CWE supplanted it.
PR1-4 Procedure Code — in older profiles before CWE supplanted it.
MFE-4 Primary Key Value — in some master-file profiles.
Various Z-segment fields in vendor specifications that elected CF for label rendering.

Most v2.5+ profiles have migrated these fields to CWE. CF tends to be seen today only in legacy lab / pathology interfaces and in narrative coded results where the formatted text genuinely matters.

Version differences

v2.3 — CF introduced with 6 components (Identifier / Formatted Text / Name of Coding System / Alternate Identifier / Alternate Formatted Text / Name of Alternate Coding System).
v2.3.1 / v2.4 / v2.5 / v2.5.1 / v2.6 / v2.7 — structurally stable. No second alternate triplet was ever added (unlike CWE, which gained CWE.10–CWE.13 in v2.6).
v2.7.1 / v2.8 / v2.8.1 / v2.8.2 — structurally stable per the HAPI v2.8.1 javadoc. Same six components.

CF has not been deprecated, but the standard's center of gravity for coded values shifted to CWE in v2.5+, and most new fields use CWE rather than CF.

Common mistakes

Embedding raw newlines (r, n) inside CF.2 instead of .br. The HL7 segment terminator is r — a literal newline truncates the message.
Sending unescaped ^ or ~ inside CF.2. Even though CF.2 is Formatted Text, the field/component delimiters still apply; pipe characters and carets must be escaped with F and S.
Using HTML / RTF / Markdown formatting in CF.2. The standard defines a specific set of escape sequences (Chapter 2, "Formatted Text"); engines do not interpret HTML tags.
Treating CF as a drop-in replacement for CWE. CF has no Original Text component, no coding system version, no OID metadata — round-tripping a CWE through CF loses CWE.7–CWE.22.
Populating CF.2 with plain text that happens to contain `` — the receiver tries to interpret it as a formatting escape and either errors or renders garbage. Escape every backslash as E when the text is not actually formatted.
Down-casting CF to CE without stripping formatting commands. CE's Text component is ST, and engines that receive HBOLDN in a ST field will render the escape sequence literally.

Examples

Minimal value — just the identifier (legal but defeats the purpose of CF):

PA

Three-component value — code with plain display text and coding system (no formatting used):

PA^Posterior-Anterior^HL70260

With a line break in the formatted text:

PA^Posterior-Anterior.br(standing)^HL70260

With highlighted abbreviation:

PA^HPAN Posterior-Anterior view^HL70260

Six-component value with alternate triplet:

PA^HPAN Posterior-Anterior view^HL70260^XR-PA^HXR-PAN Chest, PA projection^MERCYRAD

In context — OBX-3 Observation Identifier in a radiology result that wants formatted display:

OBX|1|CF|PA^HPAN Posterior-Anterior view.br(standing)^HL70260||F^Final^HL70078|||||F

Common pitfall — raw newline in CF.2:

OBX|1|CF|PA^Posterior-Anterior
(standing)^HL70260

The literal newline terminates the OBX segment early; the receiver sees (standing)^HL70260 as the start of the next segment and fails parse.

Common pitfall — HTML in CF.2:

PA^<b>PA</b> Posterior-Anterior^HL70260

The receiver renders the literal <b> and </b> characters; HL7 v2.8.1 does not define HTML interpretation of FT.

FHIR mapping

The HL7 v2-to-FHIR Implementation Guide does not publish a dedicated ConceptMap for CF — the datatype maps index lists ConceptMaps for CWE, CNE, CE, CX, EI and others, but not for CF. This reflects CF's narrow real-world footprint.

Conceptually, the practical FHIR target is CodeableConcept, by analogy with CWE / CE:

HL7 v2	FHIR target	Notes
CF.1 Identifier	`CodeableConcept.coding[0].code`
CF.2 Formatted Text	`CodeableConcept.coding[0].display` or `CodeableConcept.text`	Strip HL7 escape sequences; if formatting must be preserved, carry the original FT in an `Annotation` extension on the surrounding resource.
CF.3 Name of Coding System	`CodeableConcept.coding[0].system`	HL70396 short name → URI.
CF.4 Alternate Identifier	`CodeableConcept.coding[1].code`
CF.5 Alternate Formatted Text	`CodeableConcept.coding[1].display`	Same stripping rule as CF.2.
CF.6 Name of Alternate Coding System	`CodeableConcept.coding[1].system`

Because FHIR display strings are plain strings, the formatting commands that distinguish CF from CE are typically discarded on the way to FHIR. Senders that need formatting to survive the FHIR boundary must shadow the value in an Annotation whose text carries the original FT.

Engine considerations

Escape-sequence handling — engines must parse the HL7 formatting commands inside CF.2 and CF.5 distinctly from the field/component/repetition delimiters. A correct parser tokenizes the FT after splitting on ^, not before.
Round-trip with non-CF receivers — when forwarding to a system that expects CE or CWE in the same field, the engine should either strip the escape sequences and emit plain text, or preserve them in a shadow field (the receiver's site-specific notes field) — never pass through unchanged with the type silently re-labeled.
HL70396 validation — CF.3 and CF.6 share the [HL70396] coding-system name table with CWE / CNE / CE. The same lookup logic applies.
No coding system version — CF carries no analogue to CWE.7; if the receiver needs a version, the surrounding profile must pin it.
No Original Text — there is no CF analogue to CWE.9. The Formatted Text in CF.2 is both the display and the closest thing to a human-readable fallback; engines should not synthesize Original Text from a stripped CF.2.
HAPI typing — ca.uhn.hl7v2.model.v281.datatype.CF exposes typed accessors getCf1_Identifier() through getCf6_NameOfAlternateCodingSystem(). CF.2 and CF.5 return FT instances, not ST.

How Vorro parses and produces CF

On inbound, Vorro detects CF fields by schema (not by content) and parses CF.2 / CF.5 through the FT tokenizer rather than the ST path. The structured FT — line breaks, highlights, indents — is preserved in the internal model so that downstream HL7 v2 destinations can re-emit it byte-for-byte. When the destination is FHIR, the FT is rendered to plain text for CodeableConcept.coding[].display and the original FT string is preserved on an Annotation so it can be reconstructed on a return trip.

On outbound, Vorro emits CF only when the destination profile explicitly calls for it; by default we promote CF semantics to CWE for v2.5+ destinations so that the coding-system version and Original Text are not lost. We never emit unescaped delimiters inside CF.2, and never substitute HTML for HL7 escape sequences.

Sources

HAPI HL7v2 v2.8.1 javadoc — CF datatype
HAPI HL7v2 v2.8.1 apidocs index
HL7 v2 product brief
HL7 v2-to-FHIR IG — Datatype Maps index (CF intentionally not listed)

← Back to HL7 v2 Guide