HL7 TCC Segment: Test Code Configuration

The TCC (Test Code Configuration) segment carries the default configuration values that a laboratory analyzer or middleware uses when running a given test code. It binds a Universal Service Identifier to a set of operating defaults — dilution factors, inventory warning levels, and flags that control whether the instrument may automatically rerun, repeat, or reflex a result. TCC is a master-file style segment exchanged between a laboratory automation system and the analyzers it manages.

Purpose

TCC communicates the configuration baseline for a test code as it should be applied on automated laboratory equipment. Where an order tells an instrument what to run, TCC tells the instrument how that test code is set up by default: the dilution and pre-dilution factors to apply, the endogenous content of the pre-dilution diluent, the inventory level at which to warn, the reportable dynamic range, the units of measure, and whether automatic rerun, repeat, and reflex behaviors are permitted.

Because these are configuration defaults rather than per-specimen instructions, TCC typically flows during master-file synchronization or test-code definition exchange between the automation manager and the analyzer, not on every patient order.

Used in

TCC appears in laboratory automation and test-code definition messages, where it conveys analyzer configuration defaults for a service identifier. See the OUL unsolicited laboratory observation message for the message context in which test-code configuration and detail segments are exchanged. TCC is closely related to the per-run TCD segment, which overrides these defaults for a specific run, and to the observation-definition OM1 segment.

Field-by-field reference

Source: HAPI HL7v2 v2.5.1 javadocs (TCC javadoc) for sequence, name, data type, and repetition. Length is not published in the javadocs (—); Required and Table # are filled from the HL7 v2.5.1 standard where well-established.

Seq	Name	Data Type	Length	Req	Repeat	Table #	Description
TCC-1	Universal Service Identifier	ce	—	R	—	—	Test code this configuration applies to
TCC-2	Test Application Identifier	ei	—	O	—	—	Identifier for the test application instance
TCC-3	Specimen Source	sps	—	O	—	—	Default specimen source for the test
TCC-4	Auto-Dilution Factor Default	sn	—	O	—	—	Default automatic dilution factor applied
TCC-5	Rerun Dilution Factor Default	sn	—	O	—	—	Default dilution factor used on rerun
TCC-6	Pre-Dilution Factor Default	sn	—	O	—	—	Default pre-dilution factor applied to specimen
TCC-7	Endogenous Content of Pre-Dilution Diluent	sn	—	O	—	—	Analyte content of the pre-dilution diluent
TCC-8	Inventory Limits Warning Level	nm	—	O	—	—	Reagent level that triggers an inventory warning
TCC-9	Automatic Rerun Allowed	id	—	O	—	HL70136	Whether automatic rerun is permitted
TCC-10	Automatic Repeat Allowed	id	—	O	—	HL70136	Whether automatic repeat is permitted
TCC-11	Automatic Reflex Allowed	id	—	O	—	HL70136	Whether automatic reflex testing is permitted
TCC-12	Equipment Dynamic Range	sn	—	O	—	—	Reportable measurement range of the equipment
TCC-13	Units	ce	—	O	—	—	Units of measure for the result
TCC-14	Processing Type	ce	—	O	—	HL70388	Processing type, such as evaluation or production

Most-used fields

In practice the fields that carry the configuration intent are:

TCC-1 Universal Service Identifier — the only required field; it anchors the entire configuration to a specific test code.
TCC-4, TCC-5, TCC-6 Dilution factors — the default auto, rerun, and pre-dilution factors that govern how the analyzer prepares the specimen.
TCC-9, TCC-10, TCC-11 Automatic flags — the rerun, repeat, and reflex permissions, which determine how much autonomy the instrument has when a result falls outside expectations.
TCC-13 Units — the units of measure the configuration expects results to be reported in.

Version differences (2.3 to 2.8.2)

The TCC segment was introduced for laboratory automation in HL7 v2.4 and the field roster has been stable through v2.5.1, v2.6, v2.7, and into v2.8.x. There is no TCC in v2.3, which predates the laboratory automation chapter. From v2.4 onward the 14-field structure described here is consistent, with later versions clarifying table bindings and length guidance rather than adding or removing fields. Engines that still receive v2.3 traffic will never see a TCC; conversion to a v2.4-or-later flavor is required before configuration defaults can be expressed.

Common mistakes

Treating TCC as a per-specimen instruction. TCC carries defaults for a test code; the per-run override belongs in TCD. Sending TCC on every patient order is a misuse.
Omitting TCC-1. The Universal Service Identifier is required; without it the configuration cannot be associated with any test code and the segment is meaningless.
Confusing the dilution factor fields. TCC-4 (auto), TCC-5 (rerun), and TCC-6 (pre-dilution) are distinct; populating the wrong one changes how the analyzer prepares the specimen.
Misreading the automatic flags. TCC-9, TCC-10, and TCC-11 are ID-typed yes/no permissions, not free text; sending arbitrary strings will fail validation on strict engines.
Assuming units are inferred. TCC-13 should be sent explicitly; relying on the analyzer's built-in default can produce mismatched units between configuration and reported results.

Examples

Minimal TCC with only the required service identifier:

TCC|1554-5^Glucose^LN

Fully-populated TCC with dilution defaults, automatic flags, and units:

TCC|1554-5^Glucose^LN|APP4471^Roche^L|SER^Serum^HL70070|2^1^:^1|5^1^:^1|2^1^:^1|0^0^:^1|25|Y|Y|N|1^600^-^mg/dL|mg/dL^milligrams per deciliter^UCUM|P^Production^HL70388

Annotated breakdown:

TCC|1554-5^Glucose^LN|APP4471^Roche^L|SER^Serum^HL70070|2^1^:^1|...
    |                |                |                |
    |                |                |                +-> TCC-4 Auto-Dilution Factor Default
    |                |                +------------------> TCC-3 Specimen Source (Serum)
    |                +-----------------------------------> TCC-2 Test Application Identifier
    +----------------------------------------------------> TCC-1 Universal Service Identifier (LOINC 1554-5)

In-context excerpt 1 — TCC paired with TCD inside a test-code configuration exchange:

MSH|^~&|LABAUTO|MAINLAB|ANALYZER|CHEM1|20260610093000||OUL^R22^OUL_R22|MSG00231|P|2.5.1
TCC|1554-5^Glucose^LN|APP4471^Roche^L|SER^Serum^HL70070|2^1^:^1|5^1^:^1|2^1^:^1|0^0^:^1|25|Y|Y|N|1^600^-^mg/dL|mg/dL^milligrams per deciliter^UCUM|P^Production^HL70388
TCD|1554-5^Glucose^LN|4^1^:^1|5^1^:^1|2^1^:^1|0^0^:^1|Y|N|N^No repeat needed^HL70389

In-context excerpt 2 — TCC for a second analyte in the same configuration batch:

MSH|^~&|LABAUTO|MAINLAB|ANALYZER|CHEM1|20260610093005||OUL^R22^OUL_R22|MSG00232|P|2.5.1
TCC|2160-0^Creatinine^LN|APP4472^Roche^L|SER^Serum^HL70070|1^1^:^1|3^1^:^1|1^1^:^1|0^0^:^1|15|Y|N|N|1^20^-^mg/dL|mg/dL^milligrams per deciliter^UCUM|P^Production^HL70388

FHIR mapping

No segment-level ConceptMap is published in the HL7 v2-to-FHIR Implementation Guide for TCC. Conceptually, TCC maps to FHIR ObservationDefinition and DeviceDefinition: the test-code identity and units align with ObservationDefinition, while the analyzer-specific dilution and automation defaults align with DeviceDefinition. Because TCC expresses configuration defaults rather than a single discrete clinical event, no normalized one-to-one resource mapping is defined; integrators should treat it as configuration metadata.

Engine considerations

Most interface engines model TCC as an optional segment within laboratory automation message structures; confirm the engine's schema includes it before routing OUL-family traffic that carries configuration.
The dilution factor fields are SN (structured numeric), which encode a comparator, numerator, separator, and denominator. Engines that flatten SN to a plain number will lose the ratio semantics.
The automatic flags (TCC-9 to TCC-11) are ID-typed against a yes/no table; strict validators reject values outside the bound table.
Length is not published in the javadocs, so engines should not enforce hard field-length limits derived from the javadoc alone; rely on the underlying HL7 v2.5.1 standard instead.
Because TCC is configuration data, treat it idempotently — reprocessing the same configuration should not create duplicate clinical records.

How Vorro parses and produces TCC

When Vorro ingests a TCC segment it normalizes TCC-1 into a primary test-code reference, preserving the original coding system so downstream consumers can trace the identifier back to its source. The SN-typed dilution fields are parsed into structured ratio objects rather than scalars, keeping the comparator and denominator intact. The ID-typed automatic flags are validated against the yes/no table and surfaced as boolean configuration attributes.

When producing TCC, Vorro emits TCC-1 from the normalized test-code reference and reconstructs each SN field from its structured ratio representation, ensuring the comparator and separator components round-trip without loss. Units in TCC-13 are emitted using the configured units coding system, and the automatic flags are rendered as the normalized table values. Empty optional fields are left unpopulated rather than filled with placeholder values, so the produced segment carries only the configuration that was actually set.

Sources

← Back to HL7 v2 Guide