FHS - File Header Segment

The FHS segment is used to head a file (group of batches) as defined in Section 2.10.3, "HL7 batch protocol".

HL7 Attribute Table - FHS - file header segment

Seq#	Data Element Name	DataType	Usage	Vocabulary	Cardinality	Item #	Length	C.LEN	Flags
FHS
1	File Field Separator	ST	R		[1..1]	00067	[1..1]
2	File Encoding Characters	ST	R		[1..1]	00068	[4..5]
3	File Sending Application	HD	O		[0..1]	00069
4	File Sending Facility	HD	O		[0..1]	00070
5	File Receiving Application	HD	O		[0..1]	00071
6	File Receiving Facility	HD	O		[0..1]	00072
7	File Creation Date/Time	DTM	O		[0..1]	00073
8	File Security	ST	O		[0..1]	00074		40	#
9	File Name/ID	ST	O		[0..1]	00075		20	#
10	File Header Comment	ST	O		[0..1]	00076		80	#
11	File Control ID	ST	O		[0..1]	00077		20	#
12	Reference File Control ID	ST	O		[0..1]	00078		20	#
13	File Sending Network Address	HD	O		[0..1]	02269
14	File Receiving Network Address	HD	O		[0..1]	02270
15	Security Classification Tag	CWE	C	0952(S) Confidentiality Classification(Suggested)	[0..1]	02429
16	Security Handling Instructions	CWE	C	0953	[0..*]	02430
17	Special Access Restriction Instructions	ST	C		[0..*]	02431

FHS-1: File Field Separator (ST) 00067

Definition: This field has the same definition as the corresponding field in the MSH segment.

FHS-2: File Encoding Characters (ST) 00068

Definition: This field has the same definition as the corresponding field in the MSH segment.

FHS-3: File Sending Application (HD) 00069

Definition: This field has the same definition as the corresponding field in the MSH segment.

FHS-4: File Sending Facility (HD) 00070

Definition: This field has the same definition as the corresponding field in the MSH segment.

FHS-5: File Receiving Application (HD) 00071

Definition: This field has the same definition as the corresponding field in the MSH segment.

FHS-6: File Receiving Facility (HD) 00072

Definition: This field has the same definition as the corresponding field in the MSH segment.

FHS-7: File Creation Date/Time (DTM) 00073

Definition: This field has the same definition as the corresponding field in the MSH segment.

FHS-8: File Security (ST) 00074

Definition: This field has the same definition as the corresponding field in the MSH segment.

FHS-9: File Name/ID (ST) 00075

Definition: This field can be used by the application processing file. Its use is not further specified.

FHS-10: File Header Comment (ST) 00076

Definition: This field contains the free text field, the use of which is not further specified.

FHS-11: File Control ID (ST) 00077

Definition: This field is used to identify a particular file uniquely. It can be echoed back in FHS-12-reference file control ID.

FHS-12: Reference File Control ID (ST) 00078

Definition: This field contains the value of FHS-11-file control ID when this file was originally transmitted. Not present if this file is being transmitted for the first time.

FHS-13: File Sending Network Address (HD) 02269

Definition: Identifier of the network location the message was transmitted from. Identified by an OID or text string (e.g., URI). The reader is referred to the "Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations".⁴

FHS-14: File Receiving Network Address (HD) 02270

Definition: Identifier of the network location the message was transmitted to. Identified by an OID or text string. (e.g., URL).

This is analogous with the Sending Network Address, however in the receiving role.

This field SHOULD only be populated when the underlying communication protocol does not support identification receiving network locations.

FHS-15: Security Classification Tag (CWE) 02429

Definition: This field defines the security classification (as defined by ISO/IEC 2382-8:1998(E/F)/ T-REC-X.812-1995) of an IT resource, in this case the message, which MAY be used to make access control decisions. It is conditionally required when MSH-27 or MSH-28 are used.

Conditionality Predicate: Required if FHS-16 or FHS-17 is valued, or any contained MSH-26 is valued, Optional if neither FHS-16 nor FHS-17 or any contained MSH-26 is valued.."

Use of this field supports the business requirement for declaring the level of confidentiality (classification) for a given message.

Note: This field is used to declare the ‘high watermark’, meaning the most restrictive handling that needs to be applied to the message based on its content requiring a certain security classification level and SHOULD be viewed as the v2 equivalent of the document header in CDA, in v3 models, and in FHIR Security Labels on Resources and Bundles. The use of confidentiality codes to classify message content and its inclusion in the high water mark in the header of message content is -described in the Guide to the HL7 Healthcare Privacy and Security Classification System, Release 1, which is platform independent.

Refer to Externally-defined HL7 Table 0952 – HL7 Confidentiality Code in Chapter 2C, Code Tables, for suggested values. Use of this table is recommended. The codes in this table are comprehensive, non-overlapping hierarchical codes: Very Restricted > Restricted > Normal > Moderate > Low > Unrestricted. Restrictions to a comprehensive, non-overlapping set of codes is required for purposes of access control system algorithms such as Bell–LaPadula Mode, which isl used to adjudicate access requests against privacy policies.

FHS-16: Security Handling Instructions (CWE) 02430

Definition: This field is repeatable and conveys instructions to users and receivers for secure distribution, transmission, and storage; dictate obligations or mandated actions; specify any action prohibited by refrain policy such as dissemination controls; and stipulate the permissible purpose of use of an IT resource.

Refer to HL7 Table 0953 – Security Control in Chapter 2C, Code Tables, for suggested values.

FHS-17: Special Access Restriction Instructions (ST) 02431

Definition: Used to convey specific instructions about the protection of the patient's data , which must be rendered to end users in accordance with patient consent directive, organizational policy, or jurisdictional law. For example, in US law 42 CFR Part 2, disclosed information made with patient consent must include a renderable “Prohibition on re-disclosure” warning (§ 2.32⁵) In addition, organizational policy might require that some or all of the ARV field privacy tag values be rendered to end users, e.g., marking a consult note with “Restricted Confidentiality” or with sensitivity tags such as “VIP” or “EMP” for employee of the organization.

This field MAY also be used to specify instructions about the release of information to family and friends (e.g., "Do not release information to patient's brother, Adam Everyman"). These instructions MAY be in conjunction with other fields (as elected by the system).