FTS is the last segment of an HL7 v2 file. It is one half of the file envelope: a file opens with FHS (File Header) and closes with FTS (File Trailer), with one or more batches nested in between. FTS carries no clinical content. Its only job is to mark the end of the file and, optionally, to declare how many batches the file contained so the receiver can confirm it read everything. If FHS opens the wrapper, FTS is what tells the receiver the wrapper is now closed and complete.
Purpose
FTS signals the end of an HL7 file and lets the receiver reconcile what it received against what the sender claims to have sent. FTS-1 (File Batch Count) states how many BHS...BTS batches the file contained, so the receiver can detect a truncated or partially-transmitted file. FTS-2 (File Trailer Comment) is free text. FTS holds nothing about patients, orders, or results — it is pure file framing.
Used in
FTS appears only in HL7 file exchange (the file-batch protocol), not in real-time message streams. It is always paired with FHS: a file is FHS ... [ one or more batches ] ... FTS. A batch inside the file is itself wrapped by BHS/BTS, and each message inside a batch still begins with MSH. FTS is optional in many implementations — plenty of file feeds carry batches and messages without a file wrapper at all — but when FHS is present, FTS should close it.
Field-by-field reference
Source: the HL7 v2.5.1 standard definition of the FTS segment. No segment-level ConceptMap is published in the v2-to-FHIR IG for FTS, so the field list below comes from the base standard rather than an IG map. R = required (cardinality min ≥ 1). Repeat = field may repeat. Both FTS fields are optional in the standard. Length is shown as — pending authoritative v2.5.1 length data; Table # is — because neither field is bound to an HL7 table.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| FTS-1 | File Batch Count | NM | — | O | — | — | The number of batches (BHS...BTS) contained in this file. Lets the receiver verify it read every batch. |
| FTS-2 | File Trailer Comment | ST | — | O | — | — | Free-text comment. No defined semantics; site-specific. |
Most-used fields
FTS-1 File Batch Count is the field that matters. A receiver that counted the BHS segments it parsed can compare that count to FTS-1 and reject a file that is short — the classic signal of a truncated transfer. In practice many senders leave FTS-1 empty and rely on transport-level integrity (file size, checksums) instead, so receivers should treat a populated FTS-1 as a useful cross-check rather than a guaranteed control total.
FTS-2 File Trailer Comment is rarely populated and carries no defined meaning. Do not put reconciliation logic on it.
Version differences (2.3 to 2.8.2)
- The FTS segment and its two fields (FTS-1 File Batch Count, FTS-2 File Trailer Comment) have been stable since the file-batch protocol was introduced.
- 2.3 through 2.5.1: FTS definition is essentially unchanged — two optional fields, no table bindings.
- 2.6 / 2.7 / 2.8.x: FTS remains a two-field envelope segment. The broader file/batch protocol picked up clarifying notes over the versions, but FTS itself did not gain or lose fields.
- Practical takeaway: an FTS written for 2.3 parses identically under 2.8.2. Version drift is not a real concern for this segment.
Common mistakes
- Omitting FTS while still sending FHS, leaving the file wrapper open. If you open with FHS, close with FTS.
- Putting a message or batch count in the wrong place — FTS-1 counts batches (BHS), not individual messages (MSH). Message counts belong in BTS-1 at the batch level.
- Treating FTS-1 as mandatory and rejecting files that legitimately leave it empty.
- Trying to map FTS to a FHIR resource. It is transport framing, not content.
Examples
Minimal valid FTS (no fields populated):
FTS
Fully-populated FTS (batch count and comment):
FTS|1|End of file 20260609-NIGHTLY
Annotated breakdown of the fully-populated example:
FTS ← segment ID
| ← FTS-1 / FTS-2 field separator
1 ← FTS-1 File Batch Count (one batch in this file)
End of file 20260609-NIGHTLY ← FTS-2 File Trailer Comment (free text)
In-context inside a single-batch file (FHS ... FTS wrapper):
FHS|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609020000||NIGHTLY-ADT|FILE0001
BHS|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609020000||ADT-BATCH|BATCH0001
MSH|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609020000||ADT^A01^ADT_A01|MSG00001|P|2.5.1
EVN|A01|20260609020000
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
BTS|1|End of batch
FTS|1|End of file
In-context inside a multi-batch file (two batches, FTS-1 = 2):
FHS|^~&|LAB|HOSP_B|EHR|HOSP_A|20260609030000||NIGHTLY-ORU|FILE0002
BHS|^~&|LAB|HOSP_B|EHR|HOSP_A|20260609030000||ORU-BATCH|BATCH0001
MSH|^~&|LAB|HOSP_B|EHR|HOSP_A|20260609030000||ORU^R01^ORU_R01|CTRL-9001|P|2.5.1
OBR|1||ORD123|CBC^Complete Blood Count^L
BTS|1
BHS|^~&|LAB|HOSP_B|EHR|HOSP_A|20260609031500||ORU-BATCH|BATCH0002
MSH|^~&|LAB|HOSP_B|EHR|HOSP_A|20260609031500||ORU^R01^ORU_R01|CTRL-9002|P|2.5.1
OBR|1||ORD124|BMP^Basic Metabolic Panel^L
BTS|1
FTS|2|Nightly results file, 2 batches
FHIR mapping
Target: Not mapped at the segment level. No segment-level ConceptMap is published in the v2-to-FHIR IG for FTS. The IG segment maps index lists content-bearing segments (MSH, PID, OBR, IN1, and so on) but not the file-protocol envelope segments. This is expected: FHS, FTS, BHS, and BTS describe how a file is framed and transmitted, which is a transport concern with no place in a FHIR clinical resource. When a file is converted to FHIR, the messages inside it map to resources and Bundles; the file wrapper itself is consumed and discarded by the parser.
Engine considerations
- FTS terminates the file. After reading FTS, an engine should consider the file complete and stop expecting more segments.
- Reconciliation: if FTS-1 is present, compare it to the number of BHS segments actually parsed and raise an error on a mismatch — this catches truncated transfers. If FTS-1 is empty, fall back to transport-level integrity checks.
- An FHS with no matching FTS is a malformed (or still-open) file; decide explicitly whether to hold, reject, or accept-with-warning.
- Do not let FTS leak into message routing. Strip the file wrapper before per-message processing so that downstream rules only ever see MSH-led messages.
How Vorro parses and produces FTS
On the inbound side, Vorro recognizes the FHS...FTS wrapper, unwraps it, and routes the contained batches and messages independently; if FTS-1 is populated it reconciles the declared batch count against the batches actually read and flags a short file. On the outbound side, when a channel is configured to emit a file wrapper, Vorro pairs every FHS it writes with a closing FTS and sets FTS-1 to the true batch count so the receiver can verify completeness.
Related pages
- FHS — the File Header that opens the wrapper FTS closes.
- BTS — the Batch Trailer that closes each batch inside the file.
- MSH — the Message Header that begins every message nested inside the batches.
Sources
- HL7 v2-to-FHIR IG — segment maps index (no FTS segment ConceptMap listed)
- HL7 Version 2.5.1 product brief
