The Demo site for our new HL7 Version 2+ (plus) Standard
visit the hl7 website

Draft Website - For Review Purposes Only

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# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
FHS
1 00067 File Field Separator SHALL [1..1] [1..1] ST
2 00068 File Encoding Characters SHALL [1..1] [4..5] ST
3 00069 File Sending Application [0..1] HD
4 00070 File Sending Facility [0..1] HD
5 00071 File Receiving Application [0..1] HD
6 00072 File Receiving Facility [0..1] HD
7 00073 File Creation Date/Time [0..1] DTM
8 00074 File Security = [0..1] 40 ST
9 00075 File Name/ID = [0..1] 20 ST
10 00076 File Header Comment # [0..1] 80 ST
11 00077 File Control ID = [0..1] 20 ST
12 00078 Reference File Control ID = [0..1] 20 ST
13 02269 File Sending Network Address [0..1] HD
14 02270 File Receiving Network Address [0..1] HD
15

02429 Security Classification Tag MAY
True:
False:
C
[1..1]
[0..1]
CWE
16

02430 Security Handling Instructions MAY
True:
False:
C
[1..1]
[0..1]
CWE
17 02431 Special Access Restriction Instructions MAY
True:
False:
C
[1..1]
[0..1]
ST

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".4

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 from BHS.15 in Ch. 2)

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 might be used to make access control decisions. It is conditionally required when MSH-27 or MSH-28 are used.

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

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. 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. Use of this field supports the business requirement for declaring the level of confidentiality (classification) for a given message.

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.

(Definition from FHS.15 in Ch. 2)

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.

(Definition from MSH.26 in Ch. 2)

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.

Conditionality Predicate: Required if MSH-27 or MSH-28 is valued, Optional if neither MSH-27 nor MSH-28 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

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 is used to adjudicate access requests against privacy policies.

FHS-16: Security Handling Instructions (CWE) 02430

(Definition from BHS.16 in Ch. 2)

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. –

(Definition from FHS.16 in Ch. 2)

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.

(Definition from MSH.27 in Ch. 2)

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 Externally define HL7 Table 0953 – Security Control in Chapter 2C, Code Tables, for suggested values.

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

(Definition from BHS.17 in Ch. 2)

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.322) In addition, organizational policy MAY 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 could be in conjunction with other fields (as elected by the system).

(Definition from FHS.17 in Ch. 2)

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.325) 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).

(Definition from MSH.28 in Ch. 2)

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.328) 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).