BTS closes an HL7 v2 batch. A batch file wraps a series of messages between a Batch Header (BHS) at the top and a Batch Trailer (BTS) at the bottom: BHS ... [messages] ... BTS. BTS exists so the receiver can confirm it got every message the sender intended to send. It carries a count of the messages in the batch and, optionally, a free-text comment and a set of batch totals. BTS is part of the HL7 batch protocol envelope; it is not a clinical-content segment and never appears inside an individual message.
Purpose
BTS lets a receiver reconcile a batch. The sender states how many messages the batch contained (BTS-1) so the receiver can compare that against the number of messages it actually parsed between the BHS and the BTS. If the counts disagree, the batch was truncated or corrupted in transit. BTS-3 can carry application-defined running totals (for example, a sum of monetary amounts in a billing batch) for a second reconciliation check.
Used in
BTS is used only in HL7 v2 batch files — the file-transfer / store-and-forward exchange style, as opposed to real-time MLLP message-at-a-time exchange. It always pairs with a BHS at the top of the same batch. A file may also be wrapped at the outermost level by a File Header (FHS) and File Trailer (FTS) when multiple batches share one file. BTS does not appear inside a message; it sits at the batch level, after the last message's final segment.
Field-by-field reference
Source: HL7 v2.5.1 standard definition of the BTS segment (Chapter 2, Control). There is no v2-to-FHIR IG ConceptMap for BTS. R = required (cardinality min ≥ 1); O = optional. Repeat = field may repeat. Length and table numbers are left as — where no well-established authoritative value applies.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| BTS-1 | Batch Message Count | ST | — | O | — | — | The number of messages contained in the batch, as a string. The receiver compares this against the messages actually found between BHS and BTS. |
| BTS-2 | Batch Comment | ST | — | O | — | — | Free-text comment about the batch. Informational only. |
| BTS-3 | Batch Totals | NM | — | O | Y | — | One or more application-defined numeric totals for the batch (for example, a sum of charges). Repeats; each repetition is one total. |
Most-used fields
BTS-1 Batch Message Count is the field that matters. It is the primary reconciliation control: the receiver counts the messages it parsed and compares. A mismatch means the batch is incomplete and should be rejected or flagged, not silently processed.
BTS-3 Batch Totals is used by applications that want a content-level checksum — most commonly financial batches that sum monetary amounts so the receiver can confirm nothing was dropped or doubled. It repeats, so a batch can carry several independent totals.
BTS-2 Batch Comment is informational and rarely drives logic.
Version differences (2.3 to 2.8.2)
- The BTS segment and the surrounding batch protocol (FHS/BHS/BTS/FTS) have been stable since early v2 releases; the three fields BTS-1, BTS-2, BTS-3 are unchanged across 2.3 through 2.8.2.
- The batch protocol itself is increasingly legacy: most modern interfaces use real-time MLLP single-message exchange rather than batch files, so BTS appears far less often in newer deployments even though the definition is unchanged.
- No fields were added to BTS in later versions; receivers that ignore BTS-2 and BTS-3 interoperate cleanly with senders that populate them.
Common mistakes
- Counting the BHS, FHS, FTS, or the BTS itself toward the BTS-1 message count. BTS-1 counts messages in the batch, not envelope segments.
- Ignoring a BTS-1 mismatch and processing a truncated batch anyway.
- Treating BTS-1 as a typed integer field; it is an ST (string) in the standard, so parse defensively.
- Emitting BTS without a matching BHS, or nesting messages without the BHS/BTS pair, which breaks batch-aware receivers.
- Assuming BTS has a FHIR mapping; it does not (see FHIR mapping below).
Examples
Minimal valid BTS (count only):
BTS|2
Fully-populated BTS (count, comment, and two batch totals):
BTS|2|End of nightly ADT batch|1495.00~3
Annotated breakdown of the fully-populated example:
BTS ← segment ID
| ← field separator
2 ← BTS-1 Batch Message Count (2 messages in this batch)
End of nightly ADT batch ← BTS-2 Batch Comment (free text)
1495.00~3 ← BTS-3 Batch Totals, repeating (~): total 1 = 1495.00, total 2 = 3
In-context inside a BHS...BTS batch wrapper (two ADT messages):
BHS|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609000000||ADT BATCH|BATCH-0001
MSH|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609000001||ADT^A01^ADT_A01|MSG00001|P|2.5.1
EVN|A01|20260609000001
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
PV1|1|I|ICU^101^A|||||||MED
MSH|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609000002||ADT^A03^ADT_A03|MSG00002|P|2.5.1
EVN|A03|20260609000002
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
PV1|1|I|ICU^101^A|||||||MED
BTS|2|Nightly ADT batch
In-context inside a BHS...BTS batch wrapper (financial batch with batch totals):
BHS|^~&|BILLING|HOSP_A|RECV|HOSP_B|20260609010000||DFT BATCH|BATCH-0002
MSH|^~&|BILLING|HOSP_A|RECV|HOSP_B|20260609010001||DFT^P03^DFT_P03|FIN00001|P|2.5.1
EVN|P03|20260609010001
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
FT1|1|||20260609|20260609|CG|99213^Office Visit^L|||1|||||||||||745.00
MSH|^~&|BILLING|HOSP_A|RECV|HOSP_B|20260609010002||DFT^P03^DFT_P03|FIN00002|P|2.5.1
EVN|P03|20260609010002
PID|1||654321^^^HOSP^MR||ROE^JANE^B||19750202|F
FT1|1|||20260609|20260609|CG|99214^Office Visit^L|||1|||||||||||750.00
BTS|2|Daily charge batch|1495.00
FHIR mapping
BTS is not mapped at the segment level. No segment-level ConceptMap is published in the v2-to-FHIR IG for BTS. BTS is a batch-protocol envelope segment that carries transport reconciliation data (message count, comment, totals) rather than clinical or administrative content, so it has no FHIR resource target.
When a v2 batch is converted to FHIR, each message inside the batch is mapped to its own FHIR Bundle (or resources), and the batch envelope itself — BHS and BTS — is consumed by the integration layer for reconciliation and then discarded. The BTS-1 message count maps conceptually to verifying that the expected number of converted Bundles was produced, but this is engine-level reconciliation, not a published field-to-element mapping.
Engine considerations
- Reconcile, do not trust: after parsing a batch, compare the engine's own count of messages against BTS-1. Reject or quarantine the batch on mismatch rather than processing partial data.
- BTS-1 is an ST; parse it as a string and convert defensively. A non-numeric or empty BTS-1 should be treated as a malformed trailer.
- BTS-3 repeats; do not assume a single total. Match each total positionally to whatever application convention the sender and receiver agreed on, since the standard does not define what each total means.
- Require the pair: a BTS without a matching BHS (or a BHS with no BTS) is a structurally invalid batch. Enforce the envelope.
- Batch protocol is legacy in many shops. If an interface is real-time MLLP, BTS should never appear; seeing it may indicate a misconfigured file feed.
How Vorro parses and produces BTS
On the inbound side, Vorro recognizes the BHS/BTS envelope, splits the batch into individual messages, and uses BTS-1 to reconcile the parsed message count before any message is released downstream; a count mismatch raises a batch-level error so a truncated file never passes silently. On the produce side, when Vorro emits a batch it stamps BTS-1 with the exact number of messages written between the BHS and BTS, optionally adds a BTS-2 comment from channel config, and computes BTS-3 totals when a channel defines a summation rule (for example, summing FT1 amounts for a financial batch).
Related pages
- BHS — the Batch Header that opens the batch BTS closes; the two always pair.
- FTS — the File Trailer that closes a file-level wrapper around one or more batches.
- MSH — the Message Header that opens each message inside the batch.
Sources
- HL7 Version 2.5.1 product brief
- HL7 v2-to-FHIR IG — segment maps index (no BTS entry listed)
