HL7 FHS File Header
HL7 field reference FHS fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| FHS.1 | File Field Separator | Yes | No | ST | |
| FHS.2 | File Encoding Characters | Yes | No | ST | |
| FHS.3 | File Sending Application | No | No | HD | |
| FHS.4 | File Sending Facility | No | No | HD | |
| FHS.5 | File Receiving Application | No | No | HD | |
| FHS.6 | File Receiving Facility | No | No | HD | |
| FHS.7 | File Creation Date/Time | No | No | TS | |
| FHS.8 | File Security | No | No | ST | |
| FHS.9 | File Name/ID | No | No | ST | |
| FHS.10 | File Header Comment | No | No | ST | |
| FHS.11 | File Control ID | No | No | ST | |
| FHS.12 | Reference File Control ID | No | No | ST |
FHS starts an HL7 file wrapper and tells the receiver about the sender, receiver, creation time, and file-level identity.
Batch and file wrappers are operational plumbing: they tell you where a file or batch starts, where it ends, who sent it, who should receive it, and how to reconcile the contents.
The messages inside still have their own MSH headers. The wrapper fields are about file-level routing, batching, duplicate handling, retry behaviour, and counts.
The imported v2.5.1 message-structure catalog does not list a common message structure for FHS here, so I would treat it as profile-driven. Use it when your sending and receiving systems have explicitly agreed how the segment is carried.
For practical interface work, read the generated field panel for datatype, required, repeatable, and table details, then use the notes below to decide what the field should mean in the receiving workflow.
FHS-1 is the separator used by the wrapper line itself. In normal HL7 traffic this is the pipe character, |, and changing it is only sensible when both systems have explicitly agreed to parse the wrapper that way.
FHS-2 carries the component, repetition, escape, and subcomponent characters for the wrapper line. The usual value is ^~\&; if this does not match the actual message encoding, parsing problems start before the receiver even reaches the clinical content.
FHS-3 identifies the sending application or facility at the wrapper level. Use stable values that match routing and reconciliation rules, not whatever display label happened to be configured this week.
Because this field uses HD, it can carry a namespace and universal identifier when the local name alone is not precise enough.
FHS-4 identifies the sending application or facility at the wrapper level. Use stable values that match routing and reconciliation rules, not whatever display label happened to be configured this week.
Because this field uses HD, it can carry a namespace and universal identifier when the local name alone is not precise enough.
FHS-5 identifies the receiving application or facility at the wrapper level. Use stable values that match routing and reconciliation rules, not whatever display label happened to be configured this week.
Because this field uses HD, it can carry a namespace and universal identifier when the local name alone is not precise enough.
FHS-6 identifies the receiving application or facility at the wrapper level. Use stable values that match routing and reconciliation rules, not whatever display label happened to be configured this week.
Because this field uses HD, it can carry a namespace and universal identifier when the local name alone is not precise enough.
FHS-7 is the timestamp for creating this wrapper or record, not necessarily the time of the clinical event inside it. Use the real source-system precision and agree timezone behaviour before using it for reconciliation.
FHS-8 is rarely the right place for modern authentication. If a legacy profile uses it, document the exact value and rotation rule; otherwise keep security in the transport, certificates, network controls, or authenticated service layer.
FHS-9 is part of the control identity for this file wrapper. Make it stable enough for duplicate detection, retries, audit trails, and support conversations.
FHS-10 is human-readable context. Keep it useful for display and troubleshooting, but do not hide required workflow logic here unless the implementation guide explicitly says the receiver parses it.
FHS-11 is part of the control identity for this file wrapper. Make it stable enough for duplicate detection, retries, audit trails, and support conversations.
FHS-12 is part of the control identity for this file wrapper. Make it stable enough for duplicate detection, retries, audit trails, and support conversations.
When this references a prior control ID, preserve the original value exactly. A receiver trying to match a correction or continuation cannot repair a changed identifier by guesswork.