BHS opens an HL7 batch. When several HL7 v2 messages are shipped together as a single file or stream, the batch protocol wraps them: a BHS line at the top, the messages in the middle, and a BTS line at the bottom that closes the batch and counts what was inside. BHS is pure transport envelope — it carries no clinical or patient data. Like MSH, it is structurally special: BHS-1 defines the batch field separator and BHS-2 defines the batch encoding characters, so a reader learns the delimiters from the BHS line before parsing the rest of the batch. BHS always pairs with a closing BTS, and an outer file may further wrap one or more batches with FHS / FTS.
Purpose
BHS marks the start of a batch and describes the batch as a whole: who sent it, who it is for, when it was created, and an optional batch control id used to correlate the batch with its trailer. It does not describe any single message — each contained message still carries its own MSH. BHS exists only so that a batch of messages can be moved as one unit over file or stream transport.
Used in
BHS is used in HL7 batch files and batch streams. A batch can contain messages of any type — ADT, ORU, ORM, DFT, SIU, MDM, and so on, mixed or uniform. BHS is not part of any individual message; it belongs to the batching/transport layer. Every batch that opens with BHS must close with a matching BTS. When multiple batches are grouped into one file, an outer FHS header and FTS trailer wrap the batches. See the messages index at /academy/hl7/messages for the message types that ride inside a batch.
Field-by-field reference
Source: HL7 v2.5.1 standard definition of the BHS segment. There is no v2-to-FHIR IG ConceptMap for BHS (see FHIR mapping below). R = required (cardinality min ≥ 1). Repeat = field may repeat. Lengths are shown as —; treat exact lengths and table numbers as site-/version-dependent unless well established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| BHS-1 | Batch Field Separator | ST | — | R | — | — | The character (almost always ` |
| BHS-2 | Batch Encoding Characters | ST | — | R | — | — | Component, repetition, escape, and sub-component characters — almost always ^~&. |
| BHS-3 | Batch Sending Application | HD | — | O | — | — | The application that created the batch. |
| BHS-4 | Batch Sending Facility | HD | — | O | — | — | The facility or organization that sent the batch. |
| BHS-5 | Batch Receiving Application | HD | — | O | — | — | Intended receiving application for the batch. |
| BHS-6 | Batch Receiving Facility | HD | — | O | — | — | Intended receiving facility for the batch. |
| BHS-7 | Batch Creation Date/Time | DTM | — | O | — | — | When the batch was created (YYYYMMDDHHMMSS[.S+][+/-ZZZZ]). |
| BHS-8 | Batch Security | ST | — | O | — | — | Rarely used; site-defined security info for the batch. |
| BHS-9 | Batch Name/ID/Type | ST | — | O | — | — | A name, id, or type describing the batch contents (site-defined). |
| BHS-10 | Batch Comment | ST | — | O | — | — | Free-text comment about the batch. |
| BHS-11 | Batch Control ID | ST | — | O | — | — | Unique id for this batch; echoed by BTS-3 (Batch Control ID) to correlate trailer to header. |
| BHS-12 | Reference Batch Control ID | ST | — | O | — | — | The Batch Control ID of an earlier batch this one refers to (e.g. a re-send or response batch). |
Most-used fields
BHS-1 Batch Field Separator and BHS-2 Batch Encoding Characters are the only required fields, and they exist for the same reason MSH-1/MSH-2 do: a reader must learn the delimiters before parsing the rest of the line.
BHS-11 Batch Control ID is the practical workhorse. When it is populated, the closing BTS can echo it in BTS-3, letting a receiver confirm that the trailer it read actually belongs to the header it opened with — useful when batches are concatenated or streamed.
BHS-7 Batch Creation Date/Time supports ordering and audit at the batch level. BHS-3 through BHS-6 give batch-level routing identity, though individual messages still carry their own MSH routing fields.
Version differences (2.3 to 2.8.2)
- 2.3 / 2.3.1: BHS is defined as part of the batch protocol with its twelve fields; the layout is stable from this era forward.
- 2.4: batch and file date/time fields standardize on the longer DTM/TS form with optional fractional seconds and timezone offset.
- 2.5 / 2.5.1: no material structural change to BHS; it remains a twelve-field envelope segment.
- 2.7 to 2.8.2: BHS continues essentially unchanged. The batch protocol itself is increasingly treated as legacy file transport, since modern interfaces tend to send one message per connection (MLLP) rather than batch files; receivers built for 2.3 parse later batches without trouble.
Common mistakes
- Treating BHS-1 as a normal field and shifting all field numbers by one.
- Hard-coding
^~&instead of reading the actual batch encoding characters from BHS-2. - Confusing batch fields with message fields — BHS describes the batch, MSH describes each message; they are independent envelopes.
- Opening a batch with BHS but never writing the closing BTS (or mismatching BHS-11 against BTS-3), which leaves the batch unterminated.
- Confusing the file envelope (FHS/FTS) with the batch envelope (BHS/BTS); a file can contain multiple batches.
- Relying on a BTS message count when some contained messages were filtered or dropped upstream.
Examples
Minimal valid BHS (required fields only — delimiters):
BHS|^~&
Fully-populated BHS:
BHS|^~&|SENDAPP|HOSP_A|RECVAPP|HOSP_B|20260609120000.000-0500||NIGHTLY_ADT|nightly admit feed|BATCH20260609-0001|BATCH20260608-0001
Annotated breakdown of the fully-populated example:
BHS ← segment ID
| ← BHS-1 Batch Field Separator
^~& ← BHS-2 Batch Encoding Characters
SENDAPP ← BHS-3 Batch Sending Application
HOSP_A ← BHS-4 Batch Sending Facility
RECVAPP ← BHS-5 Batch Receiving Application
HOSP_B ← BHS-6 Batch Receiving Facility
20260609120000.000-0500 ← BHS-7 Batch Creation Date/Time
← BHS-8 Batch Security (empty)
NIGHTLY_ADT ← BHS-9 Batch Name/ID/Type
nightly admit feed ← BHS-10 Batch Comment
BATCH20260609-0001 ← BHS-11 Batch Control ID
BATCH20260608-0001 ← BHS-12 Reference Batch Control ID
In-context, a complete batch wrapping two ADT messages (BHS, messages, BTS):
BHS|^~&|SENDAPP|HOSP_A|RECVAPP|HOSP_B|20260609120000||NIGHTLY_ADT||BATCH20260609-0001
MSH|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609120001||ADT^A01^ADT_A01|MSG00001|P|2.5.1
EVN|A01|20260609120001
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
PV1|1|I|ICU^101^A|||||||MED
MSH|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609120500||ADT^A03^ADT_A03|MSG00002|P|2.5.1
EVN|A03|20260609120500
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
PV1|1|I|ICU^101^A|||||||MED
BTS|2|end of nightly admit batch|BATCH20260609-0001
In-context, a file envelope (FHS) wrapping a single batch (FHS, BHS, one message, BTS, FTS):
FHS|^~&|SENDAPP|HOSP_A|RECVAPP|HOSP_B|20260609120000||DAILY_EXPORT||FILE-20260609-01
BHS|^~&|SENDAPP|HOSP_A|RECVAPP|HOSP_B|20260609120000||NIGHTLY_ORU||BATCH20260609-0007
MSH|^~&|LAB|HOSP_A|EHR|HOSP_B|20260609120100||ORU^R01^ORU_R01|CTRL-9931|P|2.5.1
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
OBR|1||ORD123|CBC^Complete Blood Count^L
OBX|1|NM|718-7^Hemoglobin^LN||13.5|g/dL|13.0-17.0|N|||F
BTS|1||BATCH20260609-0007
FTS|1|end of daily export file
FHIR mapping
No segment-level ConceptMap is published in the v2-to-FHIR IG for BHS; batch envelope segments are not represented in FHIR messaging (FHIR uses Bundle).
BHS belongs to the HL7 v2 batch protocol — a file/stream transport convention — rather than to the content of any message. FHIR has no equivalent envelope segment: where v2 wraps many messages in a BHS/BTS batch, FHIR groups resources or messages inside a Bundle (for messaging, a Bundle of type message whose first entry is a MessageHeader). Because the batching concept is expressed structurally by the FHIR Bundle, there is no field-by-field mapping table for BHS, and the v2-to-FHIR IG segment-maps index does not list one. Batch-level identity such as BHS-11 (Batch Control ID), if it needs to survive a conversion, is typically preserved as transport metadata or as a Bundle.identifier, not as a mapped clinical element.
Engine considerations
- Parse BHS-1 and BHS-2 first. As with MSH, never assume
|and^~&; read the delimiters from the BHS line before parsing the batch. - Frame detection: an engine must recognize BHS as the batch opener and switch into batch mode, then split the contained messages on their MSH boundaries until it reaches BTS.
- Pairing: enforce that every BHS has a matching BTS, and where BHS-11 is present, verify BTS-3 echoes it. An unterminated batch should fail loudly rather than be partially ingested.
- Counting: validate the message count in BTS-1 against the number of messages actually parsed; a mismatch usually means a truncated or filtered batch.
- Nesting: handle the optional outer FHS/FTS file envelope around one or more BHS/BTS batches; do not confuse file-level and batch-level headers.
- Failure mode: treating the BHS line as if it were an MSH (or vice versa) shifts every downstream parse and corrupts the whole batch.
How Vorro parses and produces BHS
On the inbound side, Vorro detects a BHS opener, seeds the delimiter set from BHS-1 and BHS-2, and enters batch mode: it splits the contained messages on MSH boundaries, processes each through its normal message pipeline, then validates the closing BTS — confirming BTS-3 matches BHS-11 and that the BTS message count agrees with what was parsed. On the outbound side, when a channel is configured for batch delivery, Vorro emits a BHS with batch routing identity and a unique BHS-11 Batch Control ID, writes each message in order, and closes with a BTS that echoes the control id and the true message count, optionally wrapping the whole thing in an FHS/FTS file envelope.
Related pages
- BTS — the batch trailer that closes a batch and echoes BHS-11.
- FHS — the file header that wraps one or more batches.
- MSH — the message header carried by each message inside the batch.
Sources
- HL7 v2-to-FHIR IG — segment maps index (no BHS entry; confirms batch envelope segments are not mapped)
- HL7 Version 2.5.1 product brief
