NEWFree ROI Calculators — quantify what prior auth and siloed data are costing your organization.Prior Auth ROI Siloed Data ROI
HL7 v2Segment⏱ 8 min read

HL7 FHS Segment: File Header

FHS opens an HL7 file. When messages are exchanged in bulk as a flat file rather than one message per connection, the file is wrapped: FHS at the top, one or more batches inside, and FTS at the bottom. FHS is the outermost envelope — it names the file's sender and receiver, stamps the creation time, and carries a file control id that FTS echoes back. Like MSH and BHS, two of its fields are structurally special: FHS-1 defines the field separator and FHS-2 defines the encoding characters, so a parser reading a wrapped file learns the delimiters from FHS before reading anything that follows. FHS does not carry clinical content; it is pure transport framing, and its structure parallels BHS field for field.

Purpose

FHS marks the start of an HL7 file and tells the receiver who sent the file, who it is for, and when it was created. Because FHS-1 and FHS-2 carry the delimiters, a parser reads them first and uses them for the rest of the file. The file it opens is closed by a matching FTS, and may contain one or more BHS...BTS batches between them.

Used in

FHS is used in HL7 file exchange: a single file wraps one or more batches of messages for bulk transfer (for example a nightly results dump or a batched billing feed). It is always paired with a closing FTS at the end of the file. Between FHS and FTS sit one or more batches, each opened by a BHS and closed by a BTS. FHS appears only in the file-transfer protocol; messages exchanged one at a time over a live connection do not use it.

Field-by-field reference

Source: HL7 v2.5.1 standard definition of the FHS segment (file-protocol envelope). R = required (cardinality min ≥ 1). Repeat = field may repeat. No segment-level ConceptMap is published in the v2-to-FHIR IG for FHS, so data types and sequence follow the v2.5.1 standard; the structure parallels BHS. Length pending authoritative v2.5.1 data.

SeqNameData TypeLengthReqRepeatTable #Description
FHS-1File Field SeparatorST—R——The character (almost always `
FHS-2File Encoding CharactersST—R——Component, repetition, escape, and sub-component characters — almost always ^~&.
FHS-3File Sending ApplicationHD—O——The application that created the file.
FHS-4File Sending FacilityHD—O——The facility or organization that sent the file.
FHS-5File Receiving ApplicationHD—O——Intended receiving application.
FHS-6File Receiving FacilityHD—O——Intended receiving facility.
FHS-7File Creation Date/TimeDTM—O——When the file was created (YYYYMMDDHHMMSS[.S+][+/-ZZZZ]).
FHS-8File SecurityST—O——Rarely used; site-defined security info for the file.
FHS-9File Name/IDST—O——A name or identifier for the file.
FHS-10File Header CommentST—O——Free-text comment describing the file.
FHS-11File Control IDST—O——Unique id for this file; echoed in FTS (FTS-2) to match end to start.
FHS-12Reference File Control IDST—O——The File Control ID of an earlier file this one refers to.

Most-used fields

FHS-1 File Field Separator and FHS-2 File Encoding Characters are the load-bearing fields: a parser cannot read the rest of the file without them, exactly as with MSH-1 and MSH-2.

FHS-11 File Control ID identifies the file and is echoed in FTS-2, so the receiver can confirm the FTS it read belongs to the FHS it started with. FHS-12 Reference File Control ID lets a file point back at a prior file (for example a resend referencing the original).

FHS-7 File Creation Date/Time drives ordering and audit of file-level transfers. FHS-3 through FHS-6 mirror the sending/receiving application and facility pattern used in MSH for routing the file as a whole.

Version differences (2.3 to 2.8.2)

  • 2.3 / 2.3.1: FHS is already defined as the file-header envelope with its 12 fields; the file-transfer protocol (FHS...FTS wrapping BHS...BTS batches) is stable.
  • 2.4: file and batch date/time fields align with the longer date/time form carrying optional fractional seconds and timezone.
  • 2.5 / 2.5.1: data types settle on HD for the application/facility fields and DTM/TS for the creation time; the field count and meaning are unchanged.
  • 2.7 through 2.8.2: FHS remains a 12-field file envelope with no new fields. Unlike MSH, it was not extended with responsible-organization or network-address fields. Receivers built for an older version parse newer FHS unchanged.

Common mistakes

  • Treating FHS-1 as a normal field and shifting all field numbers by one (the same trap as MSH-1 and BHS-1).
  • Hard-coding ^~& instead of reading the actual encoding characters from FHS-2.
  • Sending an FHS with no matching FTS, or an FTS whose FTS-2 does not match FHS-11 — receivers may reject or hold the whole file.
  • Confusing the file envelope (FHS/FTS) with the batch envelope (BHS/BTS). A file can contain many batches; do not collapse the two layers.
  • Putting message-level routing logic on FHS fields when the real per-message detail lives in each MSH.

Examples

Minimal valid FHS (required structural fields only):

FHS|^~&

Fully-populated FHS:

FHS|^~&|SENDAPP|HOSP_A|RECVAPP|HOSP_B|20260609120000.000-0500||RESULTS_20260609.hl7|Nightly results file|FILE20260609-0001|FILE20260608-0001

Annotated breakdown of the fully-populated example:

FHS                       ← segment ID
|                         ← FHS-1  File Field Separator
^~&                      ← FHS-2  File Encoding Characters
SENDAPP                   ← FHS-3  File Sending Application
HOSP_A                    ← FHS-4  File Sending Facility
RECVAPP                   ← FHS-5  File Receiving Application
HOSP_B                    ← FHS-6  File Receiving Facility
20260609120000.000-0500   ← FHS-7  File Creation Date/Time
                          ← FHS-8  File Security (empty)
RESULTS_20260609.hl7      ← FHS-9  File Name/ID
Nightly results file      ← FHS-10 File Header Comment
FILE20260609-0001         ← FHS-11 File Control ID
FILE20260608-0001         ← FHS-12 Reference File Control ID

In-context: a file wrapping a single batch of ORU^R01 results (FHS...FTS around BHS...BTS):

FHS|^~&|LAB|HOSP_B|EHR|HOSP_A|20260609131500||RESULTS_20260609.hl7||FILE20260609-0001
BHS|^~&|LAB|HOSP_B|EHR|HOSP_A|20260609131500||||BATCH-0001
MSH|^~&|LAB|HOSP_B|EHR|HOSP_A|20260609131500||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
FTS|1|FILE20260609-0001

In-context: a file carrying two batches (the file envelope wraps multiple BHS...BTS blocks):

FHS|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609120000||ADT_FEED_20260609.hl7||FILE20260609-0002
BHS|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609120000||||BATCH-A
MSH|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609120000||ADT^A01^ADT_A01|MSG00001|P|2.5.1
EVN|A01|20260609120000
PID|1||123456^^^HOSP^MR||DOE^JOHN^A||19800101|M
BTS|1
BHS|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609120500||||BATCH-B
MSH|^~&|EPIC|HOSP_A|RECV|HOSP_B|20260609120500||ADT^A03^ADT_A03|MSG00002|P|2.5.1
EVN|A03|20260609120500
PID|1||654321^^^HOSP^MR||ROE^JANE^B||19750202|F
BTS|1
FTS|2|FILE20260609-0002

FHIR mapping

No segment-level ConceptMap is published in the v2-to-FHIR IG for FHS. FHS is a file-protocol envelope: it frames a transport file rather than carrying clinical or administrative content, so there is no FHIR resource it maps to.

Target: Not mapped at the segment level.

When a wrapped file is converted to FHIR, the FHS/FTS framing is consumed by the integration engine and discarded; each enclosed message (opened by its own MSH) is what maps to FHIR resources, typically into a Bundle per message. Any audit value in FHS-7 (creation time) or FHS-11 (file control id) is recorded as processing metadata out-of-band rather than mapped to a FHIR element.

Engine considerations

  • Parse FHS-1 and FHS-2 first. Never assume | and ^~&; read them from the FHS line and use them for the rest of the file. The enclosed BHS and MSH lines may in principle redeclare delimiters, but in practice they match the file's.
  • Match FHS to FTS. Confirm exactly one FHS at the top and one FTS at the bottom, and that FTS-2 (if present) equals FHS-11. Reject or quarantine a file that is missing either envelope.
  • Layering: a file (FHS/FTS) contains batches (BHS/BTS), which contain messages (MSH...). Engines must track all three levels; counts in BTS and FTS should reconcile with what was actually read.
  • Failure mode: a truncated file with no FTS, or a control-id mismatch, indicates an incomplete transfer — the whole file should be held rather than partially processed.

How Vorro parses and produces FHS

Vorro reads FHS-1 and FHS-2 to seed the delimiter set for the file, then walks the enclosed batches and messages, reconciling BTS and FTS counts against what it parsed. On the produce side, Vorro stamps FHS-7 with the file creation time and assigns a unique FHS-11 File Control ID, then writes the matching FTS so the file closes cleanly and the receiver can confirm a complete transfer. FHS framing is treated as transport metadata and is not mapped into downstream FHIR output.

  • FTS — the file trailer that closes the file FHS opens and echoes FHS-11.
  • BHS — the batch header for batches nested inside the FHS...FTS file.
  • MSH — the message header inside each enclosed message; the parallel envelope at the message level.

Sources

← Back to HL7 v2 Guide

Ready to Integrate This Into Your Workflow?

Talk to a Vorro expert about implementing HL7 v2 in your specific environment.

Browse HL7 v2 Guides
HL7 FHS Segment: File Header | Vorro Academy | Vorro