Draft Website - For Review Purposes Only

The BHS segment defines the start of a batch.

HL7 Attribute Table - BHS - batch header segment

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
BHS
1	00081	Batch Field Separator	SHALL		[1..1]	[1..1]			ST
2	00082	Batch Encoding Characters	SHALL		[1..1]	[4..5]			ST
3	00083	Batch Sending Application			[0..1]				HD
4	00084	Batch Sending Facility			[0..1]				HD
5	00085	Batch Receiving Application			[0..1]				HD
6	00086	Batch Receiving Facility			[0..1]				HD
7	00087	Batch Creation Date/Time			[0..1]				DTM
8	00088	Batch Security		=	[0..1]		40		ST
9	00089	Batch Name/ID/Type		=	[0..1]		40		ST
10	00090	Batch Comment		=	[0..1]		80		ST
11	00091	Batch Control ID		=	[0..1]		20		ST
12	00092	Reference Batch Control ID		=	[0..1]		20		ST
13	02271	Batch Sending Network Address			[0..1]				HD
14	02272	Batch Receiving Network Address			[0..1]				HD
15	02429	Security Classification Tag	MAY True: False:	C	[1..1] [0..1]			0952	CWE
16	02430	Security Handling Instructions	MAY True: False:	C	[1..1] [0..1]			0953	CWE
17	02431	Special Access Restriction Instructions	MAY True: False:	C	[1..1] [0..1]				ST

Definition: This field contains the separator between the segment ID and the first real field, BHS-2 Batch Encoding Characters. As such it serves as the separator and defines the character to be used as a separator for the rest of the message. Recommended value is | (ASCII 124).

Definition: This field contains the five characters in the following order: the component separator, repetition separator, escape characters, subcomponent separator, and truncation character. Recommended values are ^~VALUE#38;# (ASCII 94, 126, 92, 38,and 35, respectively). See Section 2.5.4, "Message delimiters."

Definition: This field uniquely identifies the sending application among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined.

Definition: This field contains the address of one of several occurrences of the same application within the sending system. Absent other considerations, the Medicare Provider ID might be used with an appropriate sub-identifier in the second component. Entirely site-defined.

Definition: This field uniquely identifies the receiving applications among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined.

Definition: This field identifies the receiving application among multiple identical instances of the application running on behalf of different organizations. See comments 2.14.2.4, "BHS-4 Batch Sending Facility (HD) 00084." Entirely site-defined.

Definition: This field contains the date/time that the sending system created the message. If the time zone is specified, it will be used throughout the message as the default time zone.

Definition: In some applications of HL7, this field is used to implement security features. For codified expression of security tags using BHS-15 through BHS-17.

Definition: This field can be used by the application processing the batch. It can have extra components if needed.

(Definition from BHS.10 in Ch. 2)

Definition: This field is a comment field that is not further defined in the HL7 protocol.

(Definition from BTS.2 in Ch. 2)

Definition: This field is a comment field that is not further defined in the HL7 protocol.

Definition: This field is used to uniquely identify a particular batch. It can be echoed back in BHS-12 Reference Batch Control ID if an answering batch is needed.

Definition: This field contains the value of BHS-11 Batch Control ID when this batch was originally transmitted. Not present if this batch is being sent for the first time. See definition for BHS-11 Batch Control ID.

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

As with the Sending/Receiving Responsible Organization, the Sending Network Address provides a more detailed picture of the source of the message. This information is lower than the application layer, but is often useful/necessary for routing and identification purposes. This field SHALL only be populated when the underlying communication protocol does not support identification of sending network locations.

The specific values and usage must be site negotiated

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 SHALL only be populated when the underlying communication protocol does not support identification receiving network locations.

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

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

(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.32²) 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.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).

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