References to other Chapters

2

• 2.
  Chapter 2
  • 2.1 INTRODUCTION
  • 2.2 ABSTRACT MESSAGE DEFINITION
    • 2.2.1 Definitions
      • 2.2.1.1 Message.
      • 2.2.1.2 Segments.
      • 2.2.1.3 Data Fields.
    • 2.2.2 Characteristics of Data Fields
    • 2.2.3 The Null Value.
    • 2.2.4 Format for Defining Abstract Messages
    • 2.2.5 Application (Level 7) Processing Rules, Immediate Processing
      • 2.2.5.1 Initiation.
      • 2.2.5.2 Response.
    • 2.2.6 Application (Level 7) Processing Rules, Deferred Processing
      • 2.2.6.1 Initiation.
      • 2.2.6.2 Response:
  • 2.3 MESSAGE ENCODING RULES
    • 2.3.1 Definitions
    • 2.3.2 Segment Terminator.
      • 2.3.2.1 Field Separator.
      • 2.3.2.2 Component Separator.
      • 2.3.2.3 Sub-Component Separator.
      • 2.3.2.4 Repetition Separator.
      • 2.3.2.5 Escape Character.
    • 2.3.3 Encoding HL7 Data Types
      • 2.3.3.1 ST String data.
      • 2.3.3.2 NM Numeric.
      • 2.3.3.3 DT Date.
      • 2.3.3.4 TM Time.
      • 2.3.3.5 TS Time stamp.
      • 2.3.3.6 PN Person Name.
      • 2.3.3.7 TN Telephone Number.
      • 2.3.3.8 AD Address.
      • 2.3.3.9 ID Coded Value.
    • 2.3.4 Use of Escape Sequences in Text Fields
      • 2.3.4.1 Formatting Codes.
      • 2.3.4.2 Highlighting.
      • 2.3.4.3 Special Character.
      • 2.3.4.4 Hexadecimal.
      • 2.3.4.5 Formatted Text.
      • 2.3.4.6 Local.
    • 2.3.5 HL7 Protocol Variants
      • 2.3.5.1 Sequence Number Protocol.
      • 2.3.5.2 Continuation messages and segments.
    • 2.3.6 HL7 Batch Protocol
      • 2.3.6.1 Structure of an HL7 batch file.
      • 2.3.6.2 Related Segments and Data Usage.
      • 2.3.6.3 Acknowledging Batches.
  • 2.4 CONTROL MESSAGES
    • 2.4.1 ACK: General Acknowledgement
    • 2.4.2 MCF: Delayed acknowledgement
  • 2.5 MESSAGE CONTROL SEGMENTS
    • 2.5.1 ADD - ADDENDUM
    • 2.5.2 BHS - BATCH HEADER - Stapeldatei - Kopfsegment
    • 2.5.3 BTS - BATCH TRAILER - Stapeldatei Folgesegment
    • 2.5.4 ERR - ERROR -Fehler
    • 2.5.5 FHS - FILE HEADER -File-Kopfsegment
    • 2.5.6 FTS - FILE TRAILER -File-Folgesegment
    • 2.5.7 MSA - MESSAGE ACKNOWLEDGMENT -Bestätigung einer Nachricht
    • 2.5.8 MSH - MESSAGE HEADER- Nachrichtenkopf
    • 2.5.9 NTE - NOTES AND COMMENTS -Bemerkungen und Kommentare
  • 2.6 SAMPLE CONTROL MESSAGES
    • 2.6.1 Simple Acknowledgement
    • 2.6.2 Error Return
    • 2.6.3 Sequence Number: Initial Message

2.
Chapter 2

2.1 INTRODUCTION

The Control chapter of this Standard defines the generic rules that apply to all messages. Subsequent sections define functionally specific messages to be exchanged among certain applications. The specific aspects of message definition that are addressed herein are:
- The form to be used in functional chapters for describing messages. This includes their purpose, their contents, and the inter-relationships among them. This form is called an abstract message definition because it is purely a "level 7" (application definition).
- The HL7 encoding rules for converting an abstract message into a string of characters that comprise an actual message.
- The programming procedures required to exchange messages using the HL7 specifications.
- The anticipated relationship with lower level protocols.
- Certain message segments that are components of all messages.
- A single message, the Acknowledgement message, that may be used unchanged in multiple applications.

2.2 ABSTRACT MESSAGE DEFINITION

The Standard defines messages at a level of abstraction appropriate to layer 7. This defines the data content and certain procedures that are relevant to the application. This section defines the format used to define the abstract message in all the functionally specific chapters. Section C of this chapter gives the rules for generating the actual Standard character string to correspond to any abstract message.
Although subsequent chapters define the messages abstractly, the examples in those chapters assume the encoding rules defined in this chapter.

2.2.1 Definitions

2.2.1.1 Message.

A message is the atomic unit of data transferred between systems. It is comprised of a group of segments in a defined sequence. Each message has a message type that defines its purpose. For example the ADT Message type is used to transmit portions of a patient's ADT data from one system to another. A 3 character code contained within each message identifies its type. These are listed in the Message Type list, Appendix A, page 2.
The event that initiates an exchange of messages is called a "trigger event." Table 3 (Appendix A) contains the codes that represent all defined trigger events. These codes represent values such as "A Patient is Admitted" or "An order is cancelled." There is a one-to-many relationship between message types and trigger event codes. The same trigger event code may not be associated with more than one message type.
All message type and trigger event codes beginning with Z are reserved for locally defined messages. No such codes will be defined within the HL7 Standard.

2.2.1.2 Segments.

A segment is a logical grouping of data fields. Segments of a message may be required or optional. They may occur only once in a message or they may be allowed to repeat. Each segment is given a name. For example, the ADT message may contain the following segments: Message Header, Event Type Patient ID, and Patient Visit.
Each segment is identified by a unique 3 character code known as the Segment ID. Although the actual segments are defined in various chapters the ID codes assigned to all segments are listed in a Segment Table, Appendix A, page 3.
All segment id codes beginning with Z are reserved for locally defined messages. No such codes will be defined within the HL7 Standard.

2.2.1.3 Data Fields.

The chapters listed above contain segment definition tables. These tables list and describe the data fields in the segment and characteristics of their usage. Appendix A, the data dictionary, provides an alphabetical listing of data elements, listings of recommended coded values, and a cross reference from data elements to segments.

2.2.2 Characteristics of Data Fields

The following information is specified about each data field:
position - the ordinal position of the data field within the segment. This number is used to refer to the data field in the text comments that follow the segment definition table. It is also significant in the HL7 message encoding rules.
name - a globally unique descriptive name for the field.
id number - a small integer that uniquely identifies the data field throughout the Standard. The id number is not significant under the HL7 message encoding rules, but is included as a convenience for those who would apply the HL7 Standard using other message encoding rules.
maximum length - the maximum number of characters that one occurrence of the data field may occupy in any message. The maximum length is not of conceptual importance in the abstract message or the HL7 coding rules. It is included because it helps readers understand the purpose of the field and it may have pragmatic importance in specific implementations. It is calculated assuming that the HL7 encoding rules are applied. As such, it includes the component and sub-component separators that are defined below. Because the maximum length is that of a single occurrence, the repetition separator is not included in calculating the maximum length.
optionality - whether the data field is required in a segment or is optional. The designations are
R - required
O - optional
repetition - whether the field may repeat. The designations are:
N - no repetition
Y - the field may repeat an indefinite or site determined number of times
(integer) - the field may repeat up to the number of times specified in the integer.
table - HL7 publishes a table of values for this field. See the discussions for data type ID, below.
type - restrictions on the contents of the data field. The following types are defined:
ST String. Any display characters are allowed. String data is left justified with trailing blanks optional.
TX Text. String data meant for user display (on a terminal or printer). Such data would not necessarily be left justified since leading spaces may contribute greatly to the clarity of the presentation to the user.
Because this type of data is intended for display, it may contain certain special character sequences designed to control the display. These are defined specifically in the HL7 encoding rules.
FT Formatted Text. This is a text string with embedded formatting instructions. These instructions are limited to those that are intrinsic and independent of the circumstances under which the field is being used. The actual instructions and their representation are described below where the encoding rules for the FT data type are given.
NM Numeric. A leading "+" or "-" sign may be included. In the absence of a sign, the number is assumed to be positive. A decimal point may be included. If there is no decimal point the number is assumed to be an integer.
DT Date. Always includes 4-digit year.
TM Time. 24 hour clock notation. The optional time is local time of the sender. Seconds are optional.
TS Time stamp. Contains the exact time of an event, including the date and time. The time zone of the sender may be sent optionally as an offset from the coordinated universal time (previously known as Greenwich Mean Time.) Where the time zone is not sent, the time is understood to refer to the local time of the sender. All HL7 systems operating in a domain that crosses time zones are required to send the time zone offset. The HL7 committee strongly recommends that all systems routinely send the time zone offset but does not require it.
All HL7 systems are required to accept the time zone offset, but its interpretation is application specific. For many applications the time of interest is the local time of the sender. For example, an application in the Eastern Standard Time zone receiving notification of an admission that takes place at 11:00 PM in San Francisco on December 11 would prefer to treat the admission as having occurred on December 11 rather than advancing the date to December 12.
One exception to this rule would be a clinical system that processed patient data collected in a clinic and a nearby hospital that happens to be in a different time zone. Such applications may choose to convert the data to a common representation. Similar concerns apply to the transitions to and from daylight saving time. HL7 supports such requirements by requiring that the time zone information be present when the information is sent. It does not, however, specify which of the treatments discussed here will be applied by the receiving system.
The specific data representations used in the HL7 encoding rules are compatible with ISO 8824-1987(E). They are defined in the Encoding Rules section of this chapter (Section 19).
PN Person Name. A person's name including given name, middle name, family name, prefix (e.g., DR), suffix (e.g., JR or III), and degree (e.g., MD).
TN Telephone number.
AD Address. The street or mailing address of a person or institution.
ID Coded value. The value of such a field follows the formatting rules for an ST field except that it is drawn from a table of legal values. Examples of ID fields include physician ID, religion and sex.
The manner in which the valid values are defined for ID fields will vary. Certain fields like Physician ID or Patient Location will have values that vary from institution to institution.
Others, like Event Type, are a part of the HL7 Standard because they affect the interpretation of the messages that contain them. These are limited to the values established by the HL7 Standard. These values are listed in Appendix A. Additions may be included on a site-specific basis.
Still other ID fields contain values that are encoded by reference to other Standards documents. For example, the encoding for Lab procedures is defined by ASTM 1238-88.
Finally, some ID data fields will contain values that might be standardized across institutions, but for which no applicable official Standard exists. For these a set of suggested values may be listed in Appendix A. It is expected that these values will be used where applicable within an institution and serve as a basis for extensions as required. The appropriate functional committee within HL7 solicits suggestions for additional values from institutions that are applying the Standard.
SI Sequence ID. A positive, non-zero integer.
CM Composite. A field that is a combination of other meaningful data fields. Each portion is called a component. Certain composites have been separately identified and are described below.
CK Composite ID with check digit. A composite consisting of three components: an id number, a check digit, and a code showing the check digit scheme employed. The codes are defined in Table 60 (appendix A.)
CN Composite ID and Name. A field identifying a person both as a coded value and with a text name. The first component is the coded id according to a site-specific table. The second and subsequent components are the person's name as a PN field. For specific fields individual sites may elect to omit the id or the name.
CQ Composite quantity with units. The first component is a quantity and the second is the units in which the quantity is expressed. Field by field, default units may be defined within the specifications.
CE Coded Element. This data type transmits codes and the text associated with the code. This type has six components arranged in two groups as follows:
<identifier>^<text>^<name of coding system>^<alternate identifier>^<alternate text>^<name of alternate coding system>
These are defined as follows:
Identifier. This is the sequence of characters (the "code") that uniquely identifies the item being referenced by the <text>. Different coding schemes will have different elements here.
Text. This is the name or description of the item in question. E.g., "myocardial infarction" or "x-ray impression."
Coding system. Each coding system will be assigned a unique identifier. This field will serve to identify the coding scheme being used in the identifier field. For backward compatibility, if this field is absent, it will be taken to mean the CPT-4 with ASTM extensions, i.e., AS4.
Other coding systems that might appear here are ICD-9, ICD-10, SNOMED, etc. Each system will be given a unique identifying string.
The ASTM 1238-88 proposed codes are:
ACR American College of Radiology Finding Codes
AS4 astm universal code
FDK FDA k10 Food & Drug Administration
FDT FDA test types
I9 ICD-9
I9C ICD-9 CM Commission of Professional Hospital Activities
I10 ICD-10 World Heath Organization
L Locally-defined codes
RC Read Classification proposed for usage in England
SNM Systematized Nomenclature of Medicine (SNOMED)
Others may be added as needed.
The combination of the identifier and coding system fields will be a unique code for a data item.
Alternate fields: these three fields are defined analogously to the above for the alternate or local coding system.
If the Alternate Text field is absent, and the Alternate Identifier is present, the Alternate Text will be taken to be the same as the Text field.
If the Alternate Coding System field is absent, it will be taken to mean the locally defined system.

2.2.3 The Null Value.

Except where noted, HL7 data fields may take on the null value. Sending the null value is different from omitting an optional data field. The difference appears when the contents of a message will be used to update a record in a database rather than create a new one. If no value is sent, (i.e., it is omitted) the old value should remain unchanged. If the null value is sent, the old value should be changed to null.

2.2.4 Format for Defining Abstract Messages

Subsequent chapters of this document describe messages that are exchanged among applications in functionally specific situations. Each chapter is organized as follows.
1.Purpose. This is an overview describing the purpose of the chapter, general information and concepts.
2.Trigger Events and Messages. There is a list of the trigger events. For each trigger event is listed the messages that are exchanged when the trigger even occurs.
Each message is defined in special notation that lists the segment ids in the order they would appear in the message. Braces, "{ . . . }," indicate one or more repetitions of the enclosed group of segments. (Of course, the "group" may contain only a single segment.) Brackets, "[ . . . ]," show that the enclosed group of segments is optional. If a group of segments is optional and may repeat it should be enclosed in brackets and braces, "{ [ . . . ] }."
Whenever braces enclose more than one segment id a special stylistic convention is used to help the reader understand the hierarchy of repetition. The first segment id appears on the same line as the brace, two columns to the right. The subsequent segment ids appear under the first. The closing brace appears on a line of its own in the same column as the opening brace. This convention is an optional convenience to the user. If there is conflict between its use and the braces that appear in a message schematic, the braces define the actual grouping of segments that is permitted.
3.Message Segments. The segments defined in a chapter are then listed in alphabetical order by segment id.
4.Examples. Complete messages are included.
5.Implementation Considerations. Special supplementary information is presented here. This includes issues that must be addressed in planning an implementation.
6.Outstanding Issues. Issues still under consideration or requiring consideration are listed here.

Consider the hypothetical triggering event "a widget report is requested." It might be served by the Widget Request (WRQ) and Widget Report (WRP) messages. These would be defined in the Widget chapter (say Chapter XX). The Widget Request message might consist of the following segments: Message Header (MSH), Widget ID (WID). The Widget Report message might consist of the following segments: Message Header (MSH), Message Acknowledgement (MSA), one or more Widget Description (WDN) Segments each of whichis followed by a single Widget Portion segment (WPN) followed by zero or more Widget Portion Detail (WPD) segments.
The schematic form for this hypothetical exchange of messages is shown if Figure II-1:
Trigger Event: WIDGET REPORT IS REQUESTED
WRO Widget Request Chapter
MSH Message Header II
WID Widget ID XX
WRP Widget Report Chapter
MSH Message Header II
MSA Message Acknowledgement II
{ WDN Widget Description XX
WPN Widget Portion XX
{ [WPD] } Widget Portion Detail XX
}
Figure II-1. Hypothetical schematic message.
The WID, WDN, WPN, and WPD segments would be defined by the widget committee in the widget chapter, as designated by the roman numeral XX in the right column. The MSH and MSA segments, although included in the widget messages, are defined in another chapter. They are incorporated by reference into the widget chapter by the roman numeral II.
On the other hand, the widget committee might decide that the WPN and WPD segments should appear in pairs, but the pairs are optional and can repeat. Then the schematic for the WRP message would be as shown in Figure II-2.
WRP Widget Report Chapter
MSH Message Header II
MSA Message Acknowledgement XX
{ WDN Widget Description XX
[ { WPN Widget Portion XX
WPD Widget Portion Detail XX
} ]
}
Figure II-2. WPN and WPD segments in pairs.
If the widget committee determined that at least one pair of WPN and WPD segments must follow a WDN, then the notation would be as shown in Figure II-3.
WRP Widget Report Chapter
MSH Message Header II
MSA Message Acknowledgement XX
{ WDN Widget Description XX
{ WPN Widget Portion XX
WPD Widget Portion Detail XX
}
}
Figure II-3. At least one pair of WPN and WPD.

2.2.5 Application (Level 7) Processing Rules, Immediate Processing

The processing rules described here apply to all exchanges of messages, whether or not the HL7 encoding rules or Lower Layer Protocols are used. They represent the primary message processing mode. Certain variants are documented elsewhere in the next section. These include:
- the Application processing rules for a special processing mode, deferred processing.
- an optional sequence number protocol.
- An optional protocol for continuing a very long message.
Because the protocol describes an exchange of messages, it is described in terms of two entities, the initiating and responding systems. Each is both a sender and receiver of messages. The initiating system sends first and then receives, while the responding system receives and then sends.
In overview this exchange proceeds as follows:Initiator receives message from sending application and sends it to the responding system.
Responder receives message and
(a) validates it syntactically and against the detailed rules described on page II-16; if it fails, a reject message is constructed by the protocol software and returned to the initiator
(b) passes it to the application, which:
(1) creates a response message, or
(2) creates an error message, or
(3) creates a reject message
(c) sends the response, error, or reject message
Initiator passes the message to the initiating application.
The details follow.

2.2.5.1 Initiation.

The initiating application process creates a message with data values as defined in the appropriate chapter of this Standard.
The data values shown below should be provided in the MSH segment (as defined under the MSH segment in section E of this chapter). The message is encoded according to the applicable rules and sent to the lower level protocols, which will attempt to deliver it to the responding application.
Special tab stops for following table. Restored with Normal Style at end.
Field Contents
Message Time Stamp The date and time the data values are combined into the message. This field is not used in the processing logic of the HL7 protocol. It is optional.
Message Type A two-component field. The first component is a 3-letter code identifying this message (as defined above). The second component is a 3-digit trigger event code as listed in Table 3, Appendix A.
Receiving Application A code defined for the communication environment to identify the application to which the message should be sent.
Sending Application A code similar to Receiving Application used to identify the source of the message.
Receiving Facility A code defined for the communication environment to identify which instance of the application should receive the message.
Sending Facility A code similar to Receiving Application used to identify the source of the message.
Message Control ID Unique identifier used to relate the response to the initial message.
Processing ID A code that show whether this transaction is to be used for production, training, debugging.
Version ID The version number of the HL7 spec for which the software was defined.
Sequence Number Sequence number: used in implementation of sequence number protocol. See "Control Protocol Variants."
Continuation Pointer Used in implementation of message continuation protocol. See "HL7 Protocol Variants," and Chapter V.
Certain other fields in the MSH segment are required for the operation of the HL7 encoding rules; they will not be relevant if other encoding rules are employed.
The event code in the second component of the Message Type field is redundantly shown elsewhere in some messages. For example, the same information is in the EVN segment of the ADT message. This is for compatibility with prior versions of the HL7 protocol. Newly defined messages should only show the event code in the Message Type field of the MSH segment.

2.2.5.2 Response.

The protocol software in the responding system:(a) accepts the message
(b) validates it against at least the following criteria:
1. The Message Type in the MSH segment is one that is acceptable to the receiver
2. The Version ID in the MSH segment is acceptable to the receiver.
3. The Processing ID in the MSH segment is appropriate for the application process handling the message.
If any of these edits fail, the protocol software rejects the message. That is, it creates an ACK message with 'AR' in the Acknowledgement Code.
(c) if the message passes the edits, the message is passed to the receiving application, which performs one of these functions:
1. Process the message successfully, generating the functional response message. The MSA segment of the response message should contain AA in the Acknowledgement Code.
- OR -
2. Send an error response, providing error information in functional segments to be included in the response message. The MSA segment of the response should contain AE in the Acknowledgement Code.
- OR -
3. Fail to process (reject) the message for reasons unrelated to its content or format (system down, internal error, etc.) For most such problems it is likely that the responding system will be able to accept the same message at a later time. The implementors must decide on an application-specific basis whether the message should be automatically sent again. The MSA segment of the response message should contain AR in the Acknowledgement Code.
(d) passes the message to the initiating system.
(e) the protocol software in the initiating system passes the response message to the initiating application.
In all the responses described above the following values are put in the MSA segment:
Special tab stops for this table.
Field Contents
Message Control ID Message Control ID from MSH segment of incoming message
Acknowledgement Code (as described above)

Acknowledgement Message Text description of error
Expected Sequence Number As described in "Sequence Number Protocol," below, (if the sequence number protocol is being used).
Delayed Acknowledgement Type For immediate processing this field should not be present.
The MSH segment in the response is constructed anew following the rules used to create the initial message described above. In particular, the date, time, and message control id refer to the response message; they are not echoes of the fields in the initial message. The Receiving Application and Receiving Facility, and Processing ID fields contain codes that are copied from the Sending Application, Sending Facility and Processing ID fields in the initiating message.

2.2.6 Application (Level 7) Processing Rules, Deferred Processing

The Application processing rules for deferred processing are described here. In this mode the responding system sends an acknowledgement to the initiating system that means the message has been placed in some type of secure environment (e.g., disk storage), and the receiving system commits to processing it within a "reasonable" amount of time, if a) the message contains the necessary information, and b) nothing causes the message's request for action to be cancelled before the responding system processes the request. Note that neither of these two conditions is completely checked at the time of the first acknowledgement. They are both checked at the time of processing.
The receipt of the first delayed acknowledgment by the initiating system means that the responding system has taken responsibility for the subsequent processing of the message. This also implies that the initiating system no longer needs to keep the particular message in its current form to send out later. For example, if the sending system were maintaining a queue of outgoing messages, the particular message could be deleted from the output queue at this point.
The receipt of the second delayed acknowledgement message informs the initiating application of either (a) the application's successful processing of the initial message, or (b) an error that prevented its processing. If the receiving application needs to return detailed change of status information, an application-specific message will be used. An example of the latter is the order confirmation message (ORM) described in Chapter IV.
The general delayed acknowledgement protocol is implemented on a site-specific and application-specific basis as needed. At a particular site, for a given transaction type the choices are:
i. Don't allow deferred acknowledgements.
ii. All messages will have a deferred acknowledgement.
iii. Only exceptional cases (errors) will receive the deferred acknowledgement.
In overview the processing for options (ii) and (iii) proceeds as follows:
Initiator receives message from sending application and sends it to the responding system.
The responding system receives the message from the initiating system and
(a) partially validates it syntactically and against the detailed rules described on page II-16. This validation need not be complete but should be sufficient to determine the application that will ultimately respond to the message. If this validation fails, a reject message is constructed by the protocol software and returned to the initiator.

(b) (if the message passes this validation) stores it and constructs a response message that simply acknowledges receipt.
(c) subsequently passes the message to the application, which:
(1) creates a response message, or
(2) creates an error message, or
(3) creates a reject message
(d) The protocol software sends the response, error, or reject message to the initiating system as an unsolicited update with no value present in the Delayed Acknowledgement Type field.
The protocol software of the initiating system responds to the response, error, or reject message with simple acknowledgement and passes it to the initiating application.
The details follow.

2.2.6.1 Initiation.

The rules for creating the initial message are exactly as defined under "Application (Level 7) Processing Rules, Immediate Processing" on page II-Fehler! Textmarke nicht definiert..

2.2.6.2 Response:

The processing in the responding system follows this pattern:
(a) The protocol software accepts the message and validates it against at least the following criteria:
1. The Message Type in the MSH segment is one that is acceptable to the receiver.
2. The Version ID in the MSH segment is acceptable to the receiver.
3. The Processing ID in the MSH segment is appropriate for the application process handling the message.
If any of these edits fail, the protocol software rejects the message. That is, it creates an ACK message with 'AR' in the Acknowledgement Code.
(b) If the message passes the edits, the protocol software stores it and a generates a response message of type ACK. The MSA segment of the response message should contain "AA" in the Acknowledgement Code field and "D" in the Delayed Acknowledgement Type field.
(c) Subsequently the protocol software passes the message to the application, which performs one of these functions:
1. Processes the message successfully, generating the functional response message (message type MCF). The MSA segment of the response message should contain AA in the Acknowledgement Code.
- OR -
2. Creates an error response, providing error information in functional segments to be included in the response message. The MSA segment of the response should contain AE in the Acknowledgement Code.
- OR -
3. Fails to process (rejects) the message for reasons unrelated to its content or format (system down, internal error, etc.) For most such problems it is likely that the responding system will be able to accept the same message at a later time. The implementors must decide on an application-specific basis whether the message should be automatically sent again. The MSA segment of the response message should contain AR in the Acknowledgement Code.
(d) The application passes the message to the protocol software, which constructs a message of type MCF with "F" in the Delayed Acknowledgement Type field.
(e) the protocol software passes the message to the initiating system as an unsolicited update
(f) the protocol software in the initiating system passes the response message to the initiating application and generates a simple ACK message. No value is present in the Delayed Acknowledgement Type field.
All other values are put in the MSA segment as described in "Application (Level 7) Processing Rules, Immediate Processing" on Page II-Fehler! Textmarke nicht definiert..

2.3 MESSAGE ENCODING RULES

In previous sections HL7 messages were defined as abstract sequences of segments. To construct the actual sequence of bytes that represents an abstract message one must apply encoding rules. Any set of rules may be used by site agreement and the systems at the site will be considered in conformance with HL7 at the level of the abstract message. This section describes one particular set, the HL7 encoding rules. Systems that follow these rules are compatible with HL7 at the Encoding Rules level.
The encoding rules describe how each segment is constructed and some related processing logic. Constructing the segments in sequence creates a complete HL7 message.

2.3.1 Definitions

In constructing a message certain special characters are used. They are the segment terminator, the field separator, the component separator, subcomponent separator and the repetition separator.

2.3.2 Segment Terminator.

The segment terminator is the last character of every segment. It is always the ASCII CR character (hex 0D).

2.3.2.1 Field Separator.

The field separator separates two adjacent data fields within a segment. It also separates the segment ID from the first data field in the segment. The value that represents the field separator may be defined differently for each message. Whatever character is the fourth character of the MSH segment serves as the field separator for all segments in the message. Absent other considerations, it is recommended that all sending applications use '|' as the field separator. However, all receiving applications are required to accept whatever character is included in this position and use it to parse the message.

2.3.2.2 Component Separator.

The component separator is used to separate adjacent components of some data fields. Its use is described in the descriptions of the relevant data fields. The character that represents the component separator is specified for each message as the first character in the Encoding Characters data field of the MSH segment. Absent other considerations it is recommended that all sending applications use '^' as the component separator. However, all applications are required to accept whatever character is included in the Message Header and use it to parse the message.

2.3.2.3 Sub-Component Separator.

The sub-component separator is used to separate adjacent sub-components of some data fields. Its use is described in the descriptions of the relevant data fields. The character that represents the sub-component separator is specified for each message as the fourth character in the Encoding Characters data field of the MSH segment. Absent other considerations it is recommended that all sending applications use '&' as the sub-component separator. However, all applications are required to accept whatever character is included in the Message Header and use it to parse the message.

2.3.2.4 Repetition Separator.

The repetition separator is used in some data fields to separate multiple occurrences of a field. It is used only where specifically authorized in the descriptions of the relevant data fields. The character that represents the repetition separator is specified for each message as the second character in the Encoding Characters data field of the MSH segment. Absent other considerations it is recommended that all sending applications use '~' as the repetition separator. However, all applications are required to accept whatever character is included in the Message Header and use it to parse the message.

2.3.2.5 Escape Character.

In text fields (Type TX or FT) another special character is allowed, the escape character. Any character allowed in a TX or FT field may serve as the escape character. Its use is described in the discussion on coding text fields, below. The single character that represents the escape character is specified differently for each message as the third character in the Encoding Characters data field of the MSH segment. This field is optional. Applications that do not need to use an escape character may omit this character. Absent other considerations it is recommended that all sending applications use '\' as the escape character. However, all applications are required to accept whatever character is included in this field and use it to parse text fields within the message.
2.3.2. Message Construction Rules
1) Construct the segments in the order defined for the message. Each message is constructed as follows:
a) The first 3 characters are the segment id code.
b) Each data field in sequence is inserted in the segment in the following manner:
i) A field separator is placed in the segment.
ii) If the value is 'not present', no further characters are required.
iii) If the value is present, but null, the characters '""' (two consecutive double quotation marks) are placed in the field.
iv) Otherwise, place the characters of the value in the segment. As many characters can be included as the maximum defined for data field. It is not necessary, and is undesirable, to pad fields to fixed lengths. Padding to fixed lengths is permitted.
Encode the individual data fields as shown in "Encoding HL7 Data Types," below.
v) If the field definition calls for a field to be broken into components, the following rules are used:
(a) If more than one component is included they are separated by the component separator.
(b) components that are present but null are represented by the characters "".
(c) components that are not present are treated by including no characters in the component.
(d) components that are not present at the end of a field need not be represented by component separators. For example, the two data fields are equivalent:
|ABC^DEF^^| and |ABC^DEF|.
vi) If the component definition calls for a component to be broken into sub-components, the following rules are used:
(a) If more than one sub-component is included they are separated by the sub-component separator.
(b) sub-components that are present but null are represented by the characters "".
(c) sub-components that are not present are treated by including no characters in the sub-component.
(d) sub-components that are not present at the end of a component need not be represented by sub-component separators. For example, the two data components are equivalent:
^XXX&YYY&&^ and ^XXX&YYY^.
vii) If the field definition permits repetition of a field, the following rules are used, the repetition separator is used only if more than one occurrence is transmitted and is placed between occurrences. (If three occurrences are transmitted, two repetition separators are used.) In the example below, two occurrences of telephone number are being sent:
|234-7120~599-1288B1234|
c) Repeat step (b) while there are any data elements 'present' to be sent. If all the data fields remaining in the segment definition are "not present" there is no requirement to include any more delimiters.
d) End each segment with an ASCII carriage return character.
2) Repeat step (1) until all segments have been generated.
The following rules apply to receiving HL7 messages and converting their contents to data values:
1) Ignore segments, fields, components, and extra repetitions of a field that are present but were not expected.
2) Treat segments that were expected but are not present as consisting entirely of fields that are "not present."
3) Treat fields and components that are expected but were not included in a segment as "not present."
4) In applications that cannot deal with the distinction between data fields that are not present and those that are null, treat data fields that are not present as null.
Encoding rules notes:
If a segment is to be continued across messages, use the extended encoding rules given below. These rules are defined in terms of the more general message continuation protocol (described below and in Chapter V).

2.3.3 Encoding HL7 Data Types

2.3.3.1 ST String data.

String data is left justified with trailing blanks optional. Example: |almost any data at all|TX Text data.
Leading spaces should be included. Trailing spaces should be removed. See the discussion below on the use of escape sequences in text fields. Example: | leading spaces are allowed.|
FT Formatted text data.
Differences from text data are: field is of arbitrary length, and contains formatting commands enclosed in escape characters. Example:
|\.sp\(skip one vertical line)|
For additional examples of formatting commands see "Escape Sequences in Text Fields," below.

2.3.3.2 NM Numeric.

Represent as a series of ASCII characters consisting of an optional leading sign ("+" or "-"), the digits and 0 or 1 decimal point. Examples:
|999|
|-123.792|
Leading zeros, or trailing zeros after a decimal point, are not significant. The two values "01.20" and "1.2" are identical.

2.3.3.3 DT Date.

Always in the format YYYYMMDD. Example:
|19880704|

2.3.3.4 TM Time.

Always in the format HHMM[SS][+/-ZZZZ] using a 24 hour clock notation. The seconds designation (SS) is optional. If not present it will be interpreted as 00. The time zone (+/-ZZZZ) is optional. If not otherwise specified it is local time zone of the sender. Midnight is represented as 0000. Examples:
|235959+1130| 1 second before midnight in a time zone eleven and half hours ahead of Universal Coordinated Time (i.e., east of Greenwich).
|0800| eight AM, local time of the sender.

2.3.3.5 TS Time stamp.

Always in the format
YYYYMMDDHHMM[SS][+/ZZZZ].
The seconds designation (SS) is optional. If not present it will be interpreted as 00. The time zone (+/-ZZZZ) is optional. If it is present either the "+" or the "-" sign must be included, but not both. Midnight is represented as the time 0000 combined with the date of the day that is just beginning. The maximum length of a TS field is 19 characters.
Examples:
|17760704010159-0600| 1:01:59 on July 4, 1776 in the Eastern Standard Time zone.
|17760704010159-0500| 1:01:59 on July 4, 1776 in the Eastern Daylight Saving Time zone.
|198807050000| Midnight of the night extending from July 4 to July 5, 1988 in the local time zone of the sender.

2.3.3.6 PN Person Name.

Specified as multiple free text components: family name, given name, middle initial or name, suffix (e.g., JR or III), prefix (e.g., DR), and degree (e.g., MD). The maximum length of a PN field is 48 characters including component separators.
The sending system may send upper and lower case or all upper case. The receiving system may convert to all upper case if required. Example:
|SMITH^JOHN^J^""^DR^PHD| (note that the suffix is explicitly null rather than "not present.")

2.3.3.7 TN Telephone Number.

For use in the United States and conforming countries, the telephone number is always in the form: [NN] [(999)]999-9999[X99999][B99999][C any text]
The optional first two digits are the country code. The optional 'X' portion gives an extension. The optional 'B' portion gives a beeper code. The optional 'C' portion may be used for comments like "After 6:00." While no explicit limit is placed on the text field, receiving systems may be expected to truncate values that are more than 10 characters long. Examples:
|(415)925-0121X305|
|234-4532CWEEKENDS|

2.3.3.8 AD Address.

Has the following components separated by the component separator: street address, other designation, city, state or province, zip, country. For use within the United States, state or province should be represented by the official US Postal service two-letter codes. For use within the United States, zip takes the form 99999[-9999]. For use within the United States, the country code is assumed to be USA if null. Example:
|10 ASH LN^#3^LIMA^OH^48132^""^|

2.3.3.9 ID Coded Value.

In the form of an ST field.SI Sequence ID.
In the form of an NM field.Composite fields.
Composite fields are encoded as described in step (v), above. The following examples of specifically defined composite types are included.
CK Composite ID with check digit: |128952^6^M11|
CN Composite ID number and name:
|12372^RIGGINS^JOHN^""^MD|
|12372|
|^RIGGINS^JOHN^""^MD|
CQ Composite quantity with units: |123.7^ML|
CE Coded element
|54.21^Laparoscopy^I9C^42112^^AS4|

2.3.4 Use of Escape Sequences in Text Fields

2.3.4.1 Formatting Codes.

When a field of type TX is being encoded, the escape character may be used to signal certain special characteristics of portions of the text field. The escape character is whatever display ASCII character is specified in the Escape Character Field in the MSH segment. For purposes of this section, the character '\' will be used to represent the character so designated in a message. An escape sequence consists of the escape character followed by an escape code id of one character followed by 0 or more data characters followed by another occurrence of the escape character. The following escape sequences are defined:
\H\ start highlighting
\N\ normal text (end highlighting)
\F\ field separator
\S\ component separator
\T\ subcomponent separator
\R\ repetition separator
\E\ escape character
\Xdddd\ hexadecimal data
\Zdddd\ locally defined escape sequence

2.3.4.2 Highlighting.

In designating highlighting, the sending application is indicating that the characters that follow somehow should be made to standout, but leaving the method of doing so to the receiving application. Depending on device characteristics and application style considerations, the receiving application may choose reverse video, boldface, underlining, blink, an alternate color or another means of highlighting the displayed data. For example the message fragment:
DSP| TOTAL CHOLESTEROL \H\240*\N\ [90 - 200]
might cause the following data to appear on a screen or report:
TOTAL CHOLESTEROL 240* [90 - 200]
whereas another system may choose to show the "240*" in red.

2.3.4.3 Special Character.

The special character escape sequences (\F\, \S\, \R\, \T\, and \E\) allow the corresponding characters to be included in the data in a text field, though the actual characters are reserved. For example, the message fragment
DSP| TOTAL CHOLESTEROL 180 \F\90 - 200\F\
DSP| \S\----------------\S\
would cause the following information to be displayed, given suitable assignment of separators:
TOTAL CHOLESTEROL 180 |90 - 200|
^---------------^

2.3.4.4 Hexadecimal.

When the hexadecimal escape sequence (\Xdddd\) is used the "X" should be followed by 1 or more pairs of hexadecimal digits (0, 1, . . . , 9, A, . . . , F). Consecutive pairs of the hexadecimal digits represent 8-bit binary values. The interpretation of the data is entirely left to an agreement between the sending and receiving applications that is beyond the scope of this Standard.

2.3.4.5 Formatted Text.

If the field is of the formatted text (FT) data type, formatting commands also may be surrounded by the escape character. Each command begins with the "." character. The following formatting commands are available:
.sp <number> End current output line and skip <number> vertical spaces. <number> is a positive integer or absent. If <number> is absent, skip one space.
.br Begin new output line.
.fi Begin word wrap or fill mode. This is the default state. It can be changed to a no-wrap mode using the ".nf" command.
.nf Begin no-wrap mode.
.in <number> Indent <number> of spaces, where <number> is a positive or negative integer.
.ti <number> Temporarily indent <number> of spaces where number is a positive or negative integer.
.ce End current output line and center the next line.
The component separator that marks each line defines the extent of the temporary indent command (.ti), and the beginning of each line in the no-wrap mode (.nf). Examples of formatting instructions that are NOT included in this data type include: width of display, position on page or screen, and type of output devices.
Figure II-4 is an example of the FT data type from a radiology impression section of a radiology report:
|\.in+4\\.ti-4\ 1. The cardio mediastinal silhouette
is now within normal limits.^\.sp\\.ti-4\ 2. Lung
fields show minimal ground glass appearance.^
\.sp\\.ti-4\ 3. A loop of colon visible in the left
upper quadrant is distinctly abnormal with the
appearance of mucosal effacement suggesting colitis.
\.in-4\|
Figure II-4. Formatted Text as transmitted.
Figure II-5 shows one way of presenting the data in Figure II-4. The receiving system can create many other interpretations by varying the right margin.
1.The cardio mediastinal silhouette is now within normal limits.
2.Lung fields show minimal ground glass appearance.
3.A loop of colon visible in the left upper quadrant is distinctly abnormal with the appearance of mucosal effacement suggesting colitis.
Figure II-5. Formatted text in one possible presentation.

2.3.4.6 Local.

When the local escape sequence (\Zdddd\) is used the "Z" should be followed by characters that are valid in a TX field. The interpretation of the data is entirely left to an agreement between the sending and receiving applications that is beyond the scope of this Standard.
No escape sequence may contain a nested escape sequence.

2.3.5 HL7 Protocol Variants

This section contains several extensions to the basic HL7 message protocol. These extensions represent implementation choices, and are to be used on a site-specific and application-specific basis as needed.

2.3.5.1 Sequence Number Protocol.

For certain types of data transactions between systems the issue of keeping databases synchronized is critical. An example is an ancillary system such as lab, which needs to know the locations of all inpatients to route stat results correctly. If the lab receives an ADT transaction out of sequence, the census/location information may be incorrect. Although it is true that a simple one-to-one acknowledgement scheme can prevent out-of-sequence transactions between any two systems, only the use of sequence numbers can prevent duplicate transactions. Note that although this sequence number protocol is limited to the use of sequence numbers on a single transaction stream between two applications, this sequencing protocol is sufficiently robust to allow the design of HL7-compatible store-and-forward applications.
a. Definitions, initial conditions:
i. The system receiving the data stream is expected to store the sequence number of the most recently accepted transaction in a secure fashion before acknowledging that transaction. This stored sequence number allows comparison with the next transaction's sequence number, and the implementation of fault-tolerant restart capabilities.
ii. The initiating system keeps a queue of outgoing transactions indexed by the sequence number. The length of this queue must be negotiated as part of the design process for a given link. The minimum length for this queue is one.
iii. The sequence number is a positive (non-zero) integer; and it is incremented by one (by the initiating system) for each successive transaction.
b. Starting the link:
i. The value of 0 (zero) for a sequence number is reserved: it is allowed only when the initiating system (re-)starts the link.
ii. If the receiving system gets a transaction with a 0 in the sequence number field, it should respond with a general acknowledgement message whose MSA contains a sequence number one greater than the sequence number of the last transaction it accepted in the Expected Sequence Number field. If this value does not exist (as on the first startup of a given link), the MSA should contain a sequence number of -1, meaning that the receiving system will use the positive, non-zero sequence number of the first transaction it accepts as its initial sequence number (see resynching the link, item 'e' below).
iii. The initiating system then sends the transaction indexed by the expected sequence number (if that expected transaction is still on its queue). Otherwise the link is frozen until an operator intervenes.
c. Normal operation of the link:
As it accepts each transaction, the receiving system securely stores the sequence number (which agrees with its Expected Sequence Number), and then acknowledges the message by echoing the sequence number in the Expected Sequence Number field of the MSA.
d. Error conditions (from point of view of initiating system). These are generated by the receiving system, by its comparison of the Sequence Number (sent out with the MSH) with the Expected Sequence Number (received with the MSA).
i. Expected sequence number is one greater than current value.
The previous acknowledgement was lost. That transaction was sent again. Correct by sending next transaction.
ii. Expected sequence number less than current value.
Initiating system can try starting again by issuing a transaction with a sequence number of zero; or freeze the link for operator intervention.
iii. Other errors: freeze the link for operator intervention.
e. Forcing resynchronization of sequence numbers across the link. The value of -1 for a sequence number is reserved: it is allowed only when the initiating system is resynching the link. Thus if the receiving system gets a value of -1 in the sequence number field, it should return a general acknowledgement message with a -1 in the expected sequence number field. The receiving system then resets its sequence number, using the non-zero positive sequence number of the next transaction it accepts.
f. Notes.
When the initiating system sends a message with a sequence number of 0 or -1 (see b or e above), the segments beyond the MSH need not be present in the message, or, if present, all fields can be null. In terms of the responding system, for these two cases, only a General Acknowledgement message is needed.

2.3.5.2 Continuation messages and segments.

See Chapter V for a discussion of the continuation pointer segment and the continuation pointer field, and their use in the continuation of responses to queries and in the continuation of unsolicited update messages.
Besides the need to continue a message, there are occasional implementation conditions that force the continuation of a segment across messages. Such continued segments require the use of the ADD segment as follows:
a. The segment being continued (call it "ANY" for this example) is ended at an arbitrary character position and terminated with the Standard segment terminator (carriage return).
b. The following segment is the ADD segment. When it follows a segment being continued, the ADD segment contains no fields. Whether the message being continued is a response to a query, or an unsolicited update, the receiving system will use the continuation pointer (with the ADD segment) to continue the message.
c. When a response (to a query) is continued, the first segment after the QRD and QRF (on a continued query) will be the ADD segment. All the fields after the ADD segment identifier (fields 1-N) will be the continuation of the "ANY" segment. The receiving system will then use the continuation pointer to join the two parts of the "ANY" segment and continue processing the message.
d. For the continuation of an unsolicited update message, the ADD segment will be the first segment after the MSH segment. The receiving system will use the continuation pointer field in the MSH segment to identify the message being continued, and then use the ADD segment as described in (c) to join the two parts of the "ANY" segment.
e. Limitations: MSH, MSA, DSC, PID, QRD, QRF, URD and URS segments cannot be continued.
f. Although the UU example given below is for a display message, there is nothing in the protocol to prevent a record-oriented UU from being continued in this fashion. In the unsolicited display message, the ADD record on the continuation comes just after the URD/[URS] pair instead of directly after the MSH.
g. Transaction flow for a continued query-response pair with an ADD segment:
i) First query, response:
MSH
QRD
[QRF]
MSH
MSA
QRD
[QRF]
{ DSP } last DSP segment is
. incomplete; it is
ADD followed by the ADD
. segment, which contains
. no fields.
DSC
ii) Second query, response:
MSH
QRD
[QRF]
DSC
MSH
MSA
QRD
[QRF]
ADD ADD contains remainder of
. last DSP segment of
. previous response.
{DSP} Remaining DSP segments are complete.
Note that this second response could itself be continued with a second DSC and (if needed) a second ADD segment prior to it.
f. Transaction flow for a continued unsolicited message with a continued segment.
i) First unsolicited message, acknowledgement:
MSH
URD
[ URS ]
{DSP} Last DSP is incomplete.
ADD It is followed by the ADD
segment, which contains
. no fields.
.
DSC Continuation segment
MSH General Acknowledgement
MSA
ii) Second unsolicited message, acknowledgement:
MSH Contains continuation
. pointer from DSC segment
. of prior message.
ADD ADD contains remainder of
. data from continued DSP
. segment from prior
. message.
{DSP}
DSC
Note that this second message could itself be continued with a second DSC and (if needed) a second ADD segment prior to it.
MSH General Acknowledgement
MSA

2.3.6 HL7 Batch Protocol

There are instances when it is convenient to transfer a batch of HL7 messages. Common examples would be a batch of financial posting detail transactions (DFT's) sent from an ancillary to a financial system. Such a batch could be sent online using a common file transfer protocol, or offline via tape or diskette.

2.3.6.1 Structure of an HL7 batch file.

[FHS] (file header segment)
{ [BHS] (batch header segment)
{ MSH (one or more HL7 messages)
....
....
....
}
[BTS] (batch trailer segment)
}
[FTS] (file trailer segment)
Notes:
The sequence numbering protocol has a natural application in batch transfers. See the discussion of batch acknowledgements that follows.
Although a batch will usually consist of a single type of message, there is nothing in the definition that restricts a batch to only one message type.

2.3.6.2 Related Segments and Data Usage.

The following segments defined in Section 38 relate to the HL7 Batch Protocol: BHS Batch Header
BTS Batch Trailer
FHS File Header
FTS File Trailer
The BTS segment contains a field, Batch Totals, which may have one or more totals drawn from fields within the individual messages. The method for computing such totals will be determined on a site or application basis unless explicitly stated in a functional chapter.

2.3.6.3 Acknowledging Batches.

In general, the utility of sending batches of data is that the data is accepted all-at-once, with errors processed on an exception basis. However, it is a permissible application of HL7 to acknowledge all messages. Several options for acknowledgement are given and will be chosen on an application basis. In these cases, the sequence numbering protocol can be useful to the applications processing the batch.
The options are:
a. All messages are acknowledged in the response batch.
b. The receiving system prints some form of batch control report, which is then dealt with manually by personnel at the sending system. No acknowledgements are performed by the protocol software.
c. an automated acknowledgement batch is created containing acknowledgement messages only for those messages containing errors.
In each case where there is a response batch, its format is a batch of individual messages. Each individual message is in the format defined for an on-line response in the chapters. Consider, for example, a batch that might be constructed to respond to a batch of Detailed Financial Transactions (Chapter VI). The messages in the response batch would consist entirely of ACK messages, since ACK is the response shown in Chapter VI.
When batches are retransmitted after the correction of errors, the Ref Batch Control Id field should contain the Batch Control Id of the original batch.

2.4 CONTROL MESSAGES

2.4.1 ACK: General Acknowledgement

The ACK message is used to respond to a message where there has been an error that precludes application processing or where the application does not define a special message type for the response. Its structure is normally given in the chapters that use it.
Where a simple ACK message is required it has the following structure:
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
[ ERR ] Error II

2.4.2 MCF: Delayed acknowledgement

The first MCF message, sent after the initial receipt has the following structure.
MCF General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
The second MCF message, sent after application processing, has this structure:
MCF General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgent II
[ ERR ] Error II

2.5 MESSAGE CONTROL SEGMENTS

2.5.1 ADD - ADDENDUM

The ADD segment is used to define the continuation of the prior segment in a continuation message. See section C for details.

FIELD NOTES: ADD ADDENDUM

1. 00641 ADDENDUM CONTINUATION POINTER This segment is used to define the continuation of the prior segment in a continuation message. See text for details When the ADD is sent after the segment being continued, it contains no fields. It is only a "marker" that the previous segment is being continued in a subsequent message. Thus fields "1-N" are not present. The sequence designation, "1-N", means "the remainder of the fields in the segment being continued". These "remainder-of-the-segment-being-continued" fields are present only when the ADD is sent with a continuation message.

2.5.2 BHS - BATCH HEADER - Stapeldatei - Kopfsegment

The BHS segment defines the start of a batch.

FIELD NOTES: BHS BATCH HEADER

1. 00685 BATCH FIELD SEPARATOR. This field has the same definition as the corresponding field in the MSH segment.
2. 00686 BATCH ENCODING CHARACTERS. This field has the same definition as the corresponding field in the MSH segment.
3. 00687 BATCH SENDING APPLICATION. This field has the same definition as the corresponding field in the MSH segment.
4. 00688 BATCH SENDING FACILITY. This field has the same definition as the corresponding field in the MSH segment.
5. 00689 BATCH RECEIVING APPLICATION. This field has the same definition as the corresponding field in the MSH segment.
6. 00690 BATCH RECEIVING FACILITY. This field has the same definition as the corresponding field in the MSH segment.
7. 00655 BATCH CREATION DATE/TIME
8. 00691 BATCH SECURITY. This field has the same definition as the corresponding field in the MSH segment.
9. 00656 BATCH NAME/ID/TYPE. This field can be used by the application processing the batch. It can have extra components if needed.
10. 00657 BATCH COMMENT. A comment field that is not further defined in the HL7 protocol.
11. 00658 BATCH CONTROL ID. This field can be used to uniquely identify a particular Batch. It can be echoed back in the REF BATCH CONTROL ID field if an answering batch is needed.
12. 00659 REFERENCE BATCH CONTROL ID. The value of BATCH CONTROL ID when this batch was originally transmitted. Not present if this batch is being sent for the first time. See note for BATCH CONTROL ID.

2.5.3 BTS - BATCH TRAILER - Stapeldatei Folgesegment

The BTS segment defines the end of a batch.

FIELD NOTES: BTS BATCH TRAILER

1. 00664 BATCH MESSAGE COUNT. A count of the individual messages contained within the batch.

2. 00665 BATCH COMMENT. A comment field that is not further defined in the HL7 protocol.

3. 00666 BATCH TOTALS. As many types of totals as needed for the batch may be carried by this field as separate components.

2.5.4 ERR - ERROR -Fehler

The ERR segment is used to add error comments to acknowledgment messages.

FIELD NOTES: ERR ERROR

1. 00080 ERROR CODE AND LOCATION. Used to identify an erroneous segment in another message. Four components: the segment ID, the SEQUENCE ID the field position, and a code identifying the error. For systems that do not use the HL7 Encoding Rules, the data item number may be used for the third component.

2.5.5 FHS - FILE HEADER -File-Kopfsegment

The FHS segment is used to head a file (group of batches) as defined in Section 36.

FIELD NOTES: FHS FILE HEADER

1. 00692 FILE FIELD SEPARATOR. This field has the same definition as the corresponding field in the MSH segment.

2. 00693 FILE ENCODING CHARACTERS. This field has the same definition as the corresponding field in the MSH segment.

3. 00694 FILE SENDING APPLICATION. This field has the same definition as the corresponding field in the MSH segment.

4. 00695 FILE SENDING FACILITY. This field has the same definition as the corresponding field in the MSH segment.

5. 00696 FILE RECEIVING APPLICATION. This field has the same definition as the corresponding field in the MSH segment.

6. 00697 FILE RECEIVING FACILITY. This field has the same definition as the corresponding field in the MSH segment.

7. 00660 DATE/TIME OF FILE CREATION. This field has the same definition as the corresponding field in the MSH segment.

8. 00698 FILE SECURITY. This field has the same definition as the corresponding field in the MSH segment.

9. 00661 FILE NAME/ID. This field can be user by the application processing file. Its use is not further specified.

10. 00662 FILE HEADER COMMENT. A free text field, the use of which is not further specified.

11. 00663 FILE CONTROL ID. This field is used to identify a particular file uniquely. It can be echoed back in the REFERENCE FILE CONTROL ID field of the FTS segment.

12. 00768 REFERENCE FILE CONTROL ID. The value of FILE CONTROL ID when this file was originally transmitted. Not present if this file is being transmitted for the first time.

2.5.6 FTS - FILE TRAILER -File-Folgesegment

The FTS segment defines the end of a file.

FIELD NOTES: FTS FILE TRAILER

1. 00667 FILE BATCH COUNT. This field contains the number of batches contained in this file.

2. 00668 FILE TRAILER COMMENT

2.5.7 MSA - MESSAGE ACKNOWLEDGMENT -Bestätigung einer Nachricht

The MSA segment contains information sent while acknowledging another message.

FIELD NOTES: MSA MESSAGE ACKNOWLEDGMENT

1. 00002 ACKNOWLEDGMENT CODE. See message processing rules.

2. 00003 MESSAGE CONTROL ID. This is the ID of the message sent by the sending system. It allows the sending system to associate this response with the message for which it is intended.

3. 00004 TEXT MESSAGE. An optional text field that further describes an error condition. This text may be printed in error logs or presented to an end user.

4. 00598 EXPECTED SEQUENCE NUMBER. An optional numeric field used in the sequence number.

5. 00632 DELAYED ACKNOWLEDGMENT TYPE. Used only in the MCF messages as described above, under "Application (Level 7) Processing Rules, Deferred response". Otherwise this field is not present.

2.5.8 MSH - MESSAGE HEADER- Nachrichtenkopf

The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message.

FIELD NOTES: MSH MESSAGE HEADER

1. 00005 FIELD SEPARATOR. This is actually the separator between the segment ID and the first real field, the 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 "|".

2. 00509 ENCODING CHARACTERS. The four characters are the component separator, the repetition separator and the escape character, and sub- component separator. Recommended values are "^~\&". See HL7 Encoding Rules, above.

3. 00006 SENDING APPLICATION. This field is available for interface with lower level protocols.

4. 00512 SENDING FACILITY. Used to address 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.

5. 00009 RECEIVING APPLICATION. This field is available for interface with lower level protocols.

6. 00513 RECEIVING FACILITY. Used to identify the receiving application among multiple identical instances of the application running on behalf of different organizations. See comments: SENDING FACILITY.

7. 00010 DATE/TIME OF MESSAGE. The date/time that the sending system created the message.

8. 00008 SECURITY. In some applications of HL-7 this field will be used to implement security features. Its use is not yet further specified.

9. 00012 MESSAGE TYPE. First component is the message type edited by table 0076; second is the trigger event code edited by table 0003. Receiving system uses this field to know the data segments to recognize, and, possibly, the application to which to route this message.

10. 00013 MESSAGE CONTROL ID. A number or other identifier that uniquely identifies the message. The receiving system echoes this ID back to the sending system in the MESSAGE ACKNOWLEDGMENT.

11. 00014 PROCESSING ID. Used to decide whether to process the message as defined in HL7 "Application (LEVEL 7) Processing rules," above.

12. 00015 VERSION ID. Matched by the receiving system to its own version to be sure the message will be interpreted correctly.

13. 00633 SEQUENCE NUMBER. A non-null value in this field implies that the sequence number protocol is in use. This numeric field incremented by one for each subsequent value.

14. 00699 CONTINUATION POINTER. Used to define continuations in application-specific ways.

2.5.9 NTE - NOTES AND COMMENTS -Bemerkungen und Kommentare

The NTE segment is defined here for inclusion in messages
defined in other chapters. It is a common format for sending
notes and comments.

1. 00573 SET ID - NOTES AND COMMENTS. May be used where multiple NTE segments are included in a message. Their numbering must be described in the application message definition.

2. 00574 SOURCE OF COMMENT. Used when source of comment must be identified.

3. 00575 COMMENT. The comment contained in the segment.

2.6 SAMPLE CONTROL MESSAGES

2.6.1 Simple Acknowledgement

LAB acknowledges the message that ADT sent identified as ZZ9380. (LAB and ADT, the sending and receiving system ids, are site-defined.) Both systems are associated with the same FACILITY, 767543. There is no trigger event for an acknowledgement, so the second component of the MESSAGE TYPE field is not present. The component separator may be present there, but need not be. The AA code in the MSA segment indicates that the message was accepted by the application.
MSH|^~\&|LAB|767543|ADT|767543|19900314130405
||ACK^|XX3657|P|2.1<CR>
MSA|AA|ZZ9380<CR>

2.6.2 Error Return

The AR code in MSA indicates that the application rejected the message for functional reasons. The optional ERR segment includes here that the 16th field of the PID segment with the SET ID value of 1 had an error which was defined by the locally-established code X3L. The optional text message UNKNOWN COUNTY CODE in the link is designed to help programmers and support personnel while reviewing message logs.
MSH|^~\&|LAB|767543|ADT|767543|199003141304-0500
||ACK^|XX3657|P|2.1<CR>
MSA|AR|ZZ9380|UNKNOWN COUNTY CODE<CR>
ERR|PIC^1^16^X3L<CR>

2.6.3 Sequence Number: Initial Message

The sender initiates the link with a message that has no functional content. The sequence number is 0. The message type and event code are not used.
MSH|^~\&|ADT|767543|LAB|767543|199003141304-0500
||^|XX3657|P|2.1|0<CR>
The responder uses a general acknowledgement. The expected sequence number is 1.
MSH|^~\&|LAB|767543|ADT|767543|199003141304-0500
||ACK^|ZZ9380|P|2.1<CR>
MSA|AA|XX3657||1<CR>