ANSI modal verbs

An effort has been made in this version of Chapter 2 to use the ANSI MODAL verbs as described in ISO/IEC Directive, Appendix G, as delineated in the following table:

Assumptions

The HL7 Standard makes no assumptions about the ownership of data. It also makes no requirements of its own on the subsequent action of the recipient of data, nor does it make any assumption about the design or architecture of the receiving application system. The scope of HL7 is restricted to the specification of messages between application systems, and the events triggering them. HL7 does not explicitly support, but can be used with, systems that support store and forward and data broadcast facilities (see the HL7 Implementation Support Guide).

Trigger events

The Standard is written from the assumption that an event in the real world of healthcare creates the need for data to flow among systems. The real-world event is called the trigger event. For example, the trigger event a patient is admitted MAY cause the need for data about that patient to be sent to a number of other systems. The trigger event, an observation (e.g., a CBC result) for a patient is available, MAY cause the need for that observation to be sent to a number of other systems. When the transfer of information is initiated by the application system that deals with the triggering event, the exchange is termed an unsolicited update.

Note: No assumption is made about the design or architecture of the application/ system creating the unsolicited update. The scope of HL7 is restricted to the specification of messages between application/ systems and the events triggering them.

HL7 allows the use of trigger events at several different levels of data granularity and inter-relationships. For example, most Patient Administration (ADT) trigger events concern single objects (such as an admit event, which creates a message that contains data about a single person and/or account). Other ADT trigger events are concerned with relationships between more than one object (e.g., the merge events, which specify patient or account merges). Some ADT trigger events pertain to a collection of objects that MAY have no significant inter-relationships (e.g., a record-oriented location-based query, whose response contains data about a collection of inpatients who are related only temporarily, by local geography).

Acknowledgments: original mode

When the unsolicited update is sent from one system to another, this acknowledgment mode specifies that it be acknowledged at the application level. The reasoning is that it is not sufficient to know that the underlying communications system guaranteed delivery of the message. It is also necessary to know that the receiving application processed the data successfully at a logical application level.

The acknowledgment MAY contain data of interest to the system that initiated the exchange. For example, if a patient care system has processed the trigger event a lab test is ordered for a patient, it MAY send an unsolicited update to a lab application identifying the patient, the test ordered, and various other information about the order. The ancillary system will acknowledge the order when it has processed it successfully. For some pairings of patient care and ancillary department systems the acknowledgment MAY also include the ancillary identification number that was assigned (HL7 does not require Order Entry and Results Reporting applications to interface in this manner, but it supports those that do).

Note: Original mode acknowledgment was replaced by enhanced mode acknowledgment in version 2.2. Implementers SHALL always value MSH-15 and MSH-16 Original mode allows the sender to transmit and receive on a single communication channel.

The HL7 Standard makes no functional interpretation of the requirement that a system commit the data in a message to its database before acknowledging it. All that is required is that the receiving system accept responsibility for the data, providing the same integrity test that it would apply to data from any source. To continue the prior example, the ancillary system MAY acknowledge the order after placing it in an input queue, expecting to fully process the order into its database at a future time. The only assumption is that the input queue is maintained at the same level of integrity as the database.

Instances of messages are transient by nature, and can not be expected by transmitter and/or receiver to be persistent after acknowledgment.

Acknowledgments: enhanced mode

The HL7 acknowledgment paradigm has been extended to distinguish both accept and application acknowledgments, as well the conditions under which each is required. With a positive accept acknowledgment, the receiving system commits the message to safe storage in a manner that releases the sending system from the need to resend the message. After the message has been processed by the receiving system, an application acknowledgment MAY be used to return the resultant status to the sending system.

Queries

Query documentation including messages, segments, special protocols, implementation considerations and examples have been moved to chapter 5. The unsolicited display messages were also moved because their message syntax is query-like in nature.

Messages

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 Patient Administration (ADT) data from one system to another. A three-character code contained within each message identifies its type. These are listed in the Message Type list, Appendix A.

The real-world event that initiates an exchange of messages is called a trigger event. See Section 2.3.1, "Trigger events," for a more detailed description of trigger events. Refer to HL7 Table 0003 – Event type in Chapter 2C, Code Tables, for a listing of all defined trigger events. These codes represent values such as A patient is admitted or An order event occurred. There is a one-to-many relationship between message types and trigger event codes. The same trigger event code SHALL NOT be associated with more than one message type; however a message type MAY be associated with more than one trigger event code.

All message types and trigger event codes beginning with the letter "Z" are reserved for locally defined messages. Z codes SHALL NOT be defined within the HL7 Standard.

Segments and segment groups

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 (MSH), Event Type (EVN), Patient ID (PID), and Patient Visit (PV1).

Each segment is identified by a unique three-character code known as the Segment ID. Although the actual segments are defined in various chapters, the ID codes assigned to the various segments are listed in Appendix A.

All segment ID codes beginning with the letter Z are reserved for locally defined segments. Z Codes SHALL NOT be defined within the HL7 Standard.

Two or more segments MAY be organized as a logical unit called a segment group. A segment group MAY be required or optional and might or might not repeat. As of v 2.5, the first segment in a newly defined segment group will be required to help ensure that unparsable messages will not be inadvertently defined. This required first segment is known as the anchor segment.

A segment group is assigned a name that represents a permanent identifier that SHALLNOT be changed.

A named segment X MAY occur more than once in an abstract message syntax. This differs from repetition described earlier in this section. When this occurs, the following rules SHALL be adhered to:

If, within an abstract message syntax, a named segment X appears in two individual or group locations, and

1. Either appearance is optional or repeating in an individual location or,

2. either appearance is optional or repeating in a group location

then, the occurrences of segment X SHALL be separated by at least one required segment of a different name so that no ambiguity can exist as to the individual or group location of any occurrence of segment X in a message instance.

In each of these examples it is not possible to tell which part of the message SEG1 belongs.

Fields

Definition: A field is a string of characters. Fields for use within HL7 segments are defined by HL7. A comprehensive data dictionary of all HL7 fields is provided in Appendix A.

Refer to section 2.10.5, "Protocol for interpreting repeating segments or segment groups in an update Message" for information on updating records in a database.

Version control rules regarding fields can be found in section 2.8, "Version compatibility definition".

Local extension rules regarding fields can be found in section 2.11, "Local Extension".

Message delimiters

In constructing a message, certain special characters are used. They are the segment terminator, the field separator, the component separator, subcomponent separator, repetition separator, escape character and truncation character. The segment terminator is always a carriage return (in ASCII 13,hex 0D).. The other delimiters are defined in the MSH segment, with the field delimiter in the 4th character position, and the other delimiters occurring as in the field called Encoding Characters, which is the first field after the segment ID. The delimiter values used in the MSH segment are the delimiter values used throughout the entire message. In the absence of other considerations, HL7 recommends the suggested values found in Figure 2-1 delimiter values.

At any given site, the subset of the possible delimiters MAY be limited by negotiations between applications. This implies that the receiving applications will use the agreed upon delimiters, as they appear in the Message Header segment (MSH), to parse the message.

Note: The binary representation of the delimiter characters will vary with the character set used in the message.

Length

While the length is not generally of conceptual importance in HL7 messages, most HL7 aware applications are implemented using some form of data storage that imposes length limitations on the data. This section describes how the lengths of the fields are controlled, and how interoperability can be arranged in this context.

Acknowledegment Choreography

Acknowledgment Choreography is defined as the definition of the acknowledgments to be expected for a given trigger event. It is required to document the expected acknowledgment based on the values in MSH-15 and MSH-16.

As of V2.9, all chapters SHALL include in their trigger event definitions the acknowledgment choreography.

The first row SHALL contain the words "Acknowledgment Choreography". The second row SHALL contain the message definition being described. When multiple message definitions have the same response in the same chapter all of the message pairs MAY be listed in the second row.

The values rows MSH-15 and MSH-16 are extracted from the valid values for the field.

The Application ACK row SHOULD contain the message expected in reponse to the processing of the message named in third row containing the value(s) for MSH-16 in that column.

An example can be found in Section 2.12.3

For proper formatting please consult the styleguide.

Message Construction Pseudocode

procedure construct_message ( data ) {

    identify_message_needed;

    identify_separators_used;

    validate( data );

    order_segments( data, segment_list );

    foreach segment in ( segment_list ) {

        insert segment.name; /* e.g., MSH */

        /* gather all data for fields */

        foreach field in ( fields_of( segment ) ) {

            insert field separator;            /* e.g., |    */

            /* gather occurrences (may be multiple only for fields that are allowed to repeat */

            foreach occurrence in ( occurrences_of( field ) ) {

                construct_occurrence( occurrence );

                if not last ( populated occurrence ) insert repetition_separator; /* e.g., ~ */

            }

            break if last ( populated field );

        }

        insert segment_terminator; /* always<cr>! */

    }

    return;

}

procedure construct_occurrence ( occurrence ) {

    /* gather populated components */

    foreach component in ( components_of( occurrence ) ) {

        get_subcomponent_data( component );

        /* gather all data for subcomponents */

        foreach subcomponent in ( subcomponents_of( component ) ) {

            substitute( escape_character, \E\ );

            /* escape the field separator */

            substitute( field_separator, \F\ );

            /* escape the encoding characters */

            substitute( component_separator, \S\ );

            substitute( repetition_separator, \R\ );

            substitute( subcomponent_separator, \T\ );

            substitute (truncation_character, \P\ ) /*See 2.7.2Truncation Character escape*/

            insert subcomponent;

            if not last ( populated subcomponent ) insert subcomponent_separator; /* e.g., & */

        }

        if not last ( populated component ) insert component_separator; /* e.g., ^ */

    }

    return;

}

Message Construction Flow Chart

The flow charts on the following pages represent another view of the message construction rules. The first shows the rules for transmitting a message; the second shows transmitting field occurrences.

Rules for the recipient

The following rules apply to receiving HL7 messages and converting their contents to data values:

1. ignore segments, fields, components, subcomponents, and extra repetitions of a field that are present but were not expected.

2. treat optional 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.

Encoding rules notes

If a segment is to be continued across messages, use the extended encoding rules. These rules are defined in terms of the more general message continuation protocol (see Section 2.10.2, "Continuation messages and segments").

Formatting codes

When delimiters are included in any component, the delimiters SHALL be escaped. Failure to do so canalter the meaning of the component. The escape character is whichever ASCII character is specified in the component of MSH-2 Encoding Characters. 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, zero (0) or more data characters, and another occurrence of the escape character. The following escape sequences are defined:

When a field, component or sub-component of type TX, FT, or CF is being encoded, additional escape character(s) 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 component of MSH-2 Encoding Characters.

The following additional escape sequences are defined:

Escape sequences SHALL NOT contain nested escape sequences.

For the purposes of determining length, all the characters inside the escape (all between the opening and closing \, not including the \ symbols themselves) count towards the length. This applies to all the escape sequences, including the formatting ones described below.

Truncation Character escape

When the last character of a value that is expected to be truncated is the truncation character, the truncation character SHALL be escaped.

Examples of truncation character usage.

Escape sequences supporting multiple character sets

The following HL7 escape sequences are defined to support multiple character sets for fields, components and sub-components that are defined as data types FT, ST, and TX. They allow HL7 parsers to use escape codes (defined in the standards used below), without breaking, and without being non-conformant to the HL7 escape paradigm defined in this section.

\Cxxyy\    single-byte character set escape sequence with two hexadecimal values, xx and yy, that indicate the escape sequence defined for one of the character repertoires supported for the current message (i.e., ISO-IR xxx).

\Mxxyyzz\    multi-byte character set escape sequence with three hexadecimal values, xx, yy and zz. zz is optional.

Common character set escape sequences include the following which are defined in the standards mentioned:

Single-byte character sets:

Multi-byte codes:

Highlighting

In designating highlighting, the sending application is indicating that the characters that follow somehow can be made to stand out, 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 \H40*\N\ [90 - 200]

might cause the following data to appear on a screen or report:

TOTAL CHOLESTEROL 240* [90 - 200]

whereas another system might choose to show the 240* in red.

Special character

The special character escape sequences (\F\, \S\, \R\, \T\, \P\ 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 \F0 - 200\F\

DSP|    \S\----------------\S\

would cause the following information to be displayed, given suitable assignment of separators:

TOTAL CHOLESTEROL 180 |90 - 200|

^----------------^    

Hexadecimal

When the hexadecimal escape sequence (\Xdddd...\) is used the X SHALL 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.

Usage and Examples of Formatted Text

If the field is of the formatted text (FT) data type, formatting commands also SHALL be surrounded by the escape character. Each command begins with the "." (period) character. The following formatting commands are available:

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 2-3 is an example of the FT data type from a radiology impression section of a radiology report:

Figure 2-4 shows one way of presenting the data in Figure 2-3. The receiving system can create many other interpretations by varying the right margin.

Local

When the local escape sequence (\Zdddd...\) is used the Z SHALL 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.

Adding messages or message constituents

When a new message or a new constituent of an HL7 message is introduced it SHALL be defined as described below. A sending system SHOULD be able to send a new message or new constituent; the receiver, regardless of its version level, SHALL ignore any message or message constituent it is not expecting without generating an application failure. This does not preclude a receiver notifying the sender that additional element was ignored, but the receiving application SHOULD NOT fail just from the existence of additional element.

1. New messages MAY be introduced.

2. A new segment group MAY be defined.

3. As of V2.5 the first segment in a newly-defined segment group SHALL be marked as required.

4. New segments MAY be introduced to an existing message. In general these SHOULD be introduced at the end of a message or a segment group, but they MAY be introduced elsewhere within the message if the segment hierarchy makes this necessary. Unless needed as a technical correction or for regulatory reporting purposes, a new segment SHALL NOT be added to a deprecated message. As of v2.6 all new segments, except for those pertaining only to message transmission or control, SHALL include an Action Code field as the first or second field as appropriate.

5. Care must be taken when introducing a new segment if this results in a situation in which a named segment X appears in two individual or group locations. See section 2.6, "Message construction rules".

6. New fields MAY be added at the end of a segment. A field that changes the semantic meaning of a segment (e.g., an Acton Code, or Mood code) SHALL only be introduced in a pre-existing segment if the usage of the field is conditional on it not being used in messages with pre-existing trigger events. This is to avoid the risk of reversing the intent of the segment as it is known to the recipient of an earlier version. For example, if the Sender were to send the segment with a delete action code, the recipient would not understand that the information SHOULD be deleted.

7. A new data type MAY be introduced.

8. New components MAY be added at the end of a data type.

9. A new table MAY be introduced.

Changing messages or message constituents

Allowable changes to messages or message constituents can be categorized as name, data type, optionality, repeatability, length or definition changes.

1. The descriptive text name of a message or message constituent (except for segment group name) MAY be changed. This is not expected to have impact on either the sender's ability to transmit a message or the receiver's ability to receive and understand the message. Reasons for changing the descriptive text name include: 1) clarify a misleading name, and 2) encompassing a broader use without jeopardizing current use.

2. The data type of a field or data type component MAY be changed. A sending system SHOULD be able to send the modified field or data type; the receiver, regardless of its version level, SHOULD be able to understand the message and to ignore any message constituent it is not expecting.

3. The data type of the field MAY be changed provided that the components of the new data type have the same structure and interpretation as the old data type. For example, an IS data type MAY be changed to a CE, but a PPN data type cannot be changed to a PN. An NM data type cannot be changed to an ST data type.

4. For existing fields in existing segments, data types MAY be changed if the leftmost (prior version) part of the field has the same meaning as it had in the prior version of HL7. This is in accordance with the rules governing the addition of new components and subcomponents described in the section above. In other words, if the new parts of the field (those that are part of the new data type) are ignored, what remains is the old field (defined by the old data type), which has the same meaning as it had in the prior version of HL7.

5. If a data type component has its data type changed, the structure and interpretation SHALL remain the same as the pre-existing component. Any new component is added at the end of the data type.

6. The optionality of a message constituent MAY be changed. A sending system SHOULD be able to send the modified field; the receiver, regardless of its version level, SHOULD be able to understand the message. This pertains as follows:

7. Existing optional segment groups MAY be made required.

8. Existing optional segments MAY be made conditional or required.

9. Existing optional fields MAY be made conditional or required.

10. Existing required fields MAY be made conditional if a new trigger event has been applied. The condition must be specified such that the field remains required for the pre-existing trigger events.

11. Existing optional components of a data type MAY be made conditional or required.

12. The repeatability of a message constituent MAY be changed. A sending system SHOULD be able to send the modified message constituent; the receiver, regardless of its version level, SHOULD be able to understand the message. Note that if a non-repeating message constituent is made repeating, information sent in the new repetitions couldbe lost to the recipient who is not expecting them.

If HL7 has given, or will give, semantic meaning to the first instance, to allow backward compatibility, the first instance of the repeating constituent SHALL have the same meaning as the non-repeating constituent had in the prior version of HL7. In this way, a receiving application that interprets the message based upon the prior standard would continue to find the same intent communicated in the message.

If HL7 has not given, and will/can not give, semantic meaning to the first instance, and one or more implementation-applied business rules exist to select one of several occurrences to populate a non-repeating constituent, those same rules SHOULD be applied when a newer version of the standard allows for repetition of the constituent. By applying the prior business rules to determine the first occurrence of a repeating constituent, a receiving application that interprets the message based upon the prior standard would continue to find the same intent communicated in the message.

If, in the judgment of the owner/author of the standard section in question, changing a message constituent from non-repeating to repeating poses logical, parsing, business, or other compatibility issues, the owner/author SHOULD create a new structure to eliminate the compatibility concern.

For example, if allowing a segment to repeat implies a change to the business intent of the message, the work group(s) responsible SHOULD define a new message structure (as a new message/trigger) and retain the old structure for backward compatibility.

This pertains as follows:

1. A segment group MAY change from non-repeating to repeating, subject to the backward compatibility concerns expressed above.

2. A segment group SHALL NOT be changed from repeating to non-repeating.

3. A segment MAY be changed from non-repeating to repeating, subject to the backward compatibility concerns expressed above.

4. A segment SHALL NOT be changed from repeating to non-repeating.

5. A field MAY be changed from non-repeating to repeating, subject to the backward compatibility concerns expressed above. A field SHALL NOT be changed from repeating to non-repeating.

6. The minimum and maximum normative lengths and the conformance length and truncation status of each field or data type component MAY be changed between versions. .

7. Table definition MAY change.

8. A table MAY be changed from user-defined to HL7 defined or externally defined.

9. A table MAY be changed from HL7 defined to an externally defined table. When this occurs, the data type of the field SHOULD be changed to a CNE or CWE.

10. A table MAY be changed from HL7 defined published in Chapter 2c to HL7 Defined sourced externally (HL7-EXT).

Deprecating messages or message constituents

Any required, optional or conditional constituent of an HL7 message, including the message itself, MAY be deprecated. This means that one of the following situations has occurred:

• The message or message constituent no longer has a meaningful purpose

• The message or message constituent has been replaced by a better method

Language will be inserted stating the fact of deprecation, the version in which the deprecation occurred, and what message or message constituent, if any, replaces it. The phrase "Retained for backward compatibility only in version 2.x; refer to section n.m instead" will be the standard language for such an occurrence.

The fact of deprecation SHOULD NOT affect either the sender or the receiver because the message or message constituent is retained for backward compatibility. Implementers, by site agreement, MAY agree to not support deprecated message constituents.

The following are allowed:

1. A message MAY be deprecated.

2. A trigger event MAY be deprecated.

3. A message structure MAY be deprecated.

4. A segment in an existing message MAY be deprecated. Implementers, by site agreement, MAY agree to not support deprecated segments. If the segment that is to be deprecated has dependents the entire segment group SHALL be deprecated. For example, in a group [{ABC[DEF][{GHI}]], DEF and/or GHI MAY be deprecated, but ABC cannot be deprecated without deprecating the whole.

5. A field MAY be deprecated by HL7. Before deprecating a field, HL7 SHALL ensure that all message structures which use that field have an appropriate non-deprecated location to move the data. Implementers, by site agreement, MAY agree to not use deprecated fields.

6. A data type MAY be deprecated provided all fields referencing it have been deprecated or there is an explicit statement that the data type is not to be used in any field defined in the future.

7. A data type component MAY be deprecated.

8. A table MAY be deprecated. This includes HL7 tables, HL7-EXT tables, user-defined tables, imported external tables and reference to external tables. Before deprecating a table, HL7 SHALL ensure that no references to the table exist.

9. An entry in an HL7-defined table MAY be deprecated. The table itself SHOULD be reviewed if it contains a substantial number of deprecated members.

10. An entry in an imported external table SHALL NOT be deprecated.

Removing messages or message constituents

A message or message constituent MAY be removed from the standard when criteria described in this section are met. HL7 will track old names so they are not re-used.

Note: To refer to the detail of a withdrawn message constituent, the reader will need to review the appropriate earlier version of the standard. By site agreement senders and receivers MAY agree to continue to use messages and/or message constituents that have been removed.

1. A message constituent MAY be immediately removed from the standard based on the following criteria (immediately means in the same version in which the criteria are met.).

2. A message structure MAY be removed immediately provided no message references it in the standard. Care must be taken lest a message structure is prematurely removed if the associated trigger event that contributed to its name is removed. For example, if a message structure ABC_D01 is associated with trigger events D01, D02 and D03 and D01 is changed and becomes associated with another existing message structure DEF_E01, the message structure ABC_D01 is still active and valid for trigger events D02 and D03.

3. A segment MAY be removed immediately provided no message references it in the standard.

4. A data type MAY be removed immediately provided no fields reference it. This occurs when the data type for a field is changed to a new data type that incorporates the components of the old one.

5. A table MAY be deprecated provided all fields and components, where the table has been used have been removed. This applies to HL7, user-defined and external tables. It is recognized that this might have a ripple effect.

6. A message constituent, except as noted in points c, d and e below, will be withdrawn and removed, no sooner than, after 2 versions in a deprecated state. For example, if a message was originally deprecated in v 2.3.1, its definition can be removed when v 2.6 is published.

7. A message type and its definition MAY be removed.

8. A trigger event and its definition MAY be removed.

9. A segment group in an existing message MAY be removed.

10. A segment in an existing message MAY be removed.

11. A deprecated field in an existing segment SHALL NOT be removed from the standard. However, no sooner than, after 2 versions in a deprecated state, the field will be marked as withdrawn and all explanatory narrative will be removed

12. A deprecated component in an existing data type SHALL NOT be removed from the standard. However, no sooner than, after 2 versions in a deprecated state, the component will be marked as withdrawn and all explanatory narrative will be removed.

13. A deprecated member of an existing HL7 table SHALL NOT be removed from the standard. However, no sooner than, after 2 versions in a deprecated state, the table member will be marked as withdrawn and all explanatory narrative will be removed from the description and comment column.

Early adoption of HL7 changes

Early adoption of HL7 changes that have been approved by the technical committee for the next membership ballot is a common practice and is not prohibited, but carries risk. Such changes MAY be rejected or modified in the balloting process. One example is that the change might pass but MAY be positioned differently in the segment or data type.

Technical correction rules

Technical corrections MAY be applied between versions on a case-by-case basis. These corrections SHALL be published on the HL7 website. The following meet criteria for technical correction:

1. Spelling correction

2. Incorrect section reference

3. Transcription error in an imported external table

4. Correction of an inconsistency between a segment attribute table and the field narrative

5. Erroneous examples

6. Erroneous/misleading descriptions

Message initiation

The initiating application creates a message with data values as defined in the appropriate chapter of this Standard. The fields shown below SHOULD be valued in the MSH segment (as defined under the MSH segment definition 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. (For definitions of the MSH fields see Section 2.14.9, "MSH - message header segment")

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 MSH-9 Message Type 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 MSH-9 Message Type.

Message response using the original processing rules

Accept and validate the message in responding system

Upon receipt of the message, when the Original Acknowledgment rules are used, the protocol software in the responding system validates it against at least the following criteria:

Note: Both MSH-15 - accept acknowledgment type and MSH-16 - application acknowledgment type are not present.

1. the value in MSH-9 Message Type is one that is acceptable to the receiver.

2. the value in MSH-12 Version ID is acceptable to the receiver.

3. the value in MSH-11 Processing ID 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 MSA-1 Acknowledgment Code.

Note: If the Acknowledgment Code is other than AA, the reason(s) for the rejection SHOULD be sent in the ERR segment(s) to notify the sender of the exact problem.

If successful, the process moves to the next step.

Accept and validate/process the message in the receiving application

Upon successful validation by the responding system, the message is passed to the receiving application, which performs one of these functions:

1. process the message successfully, generating the functional response message with a value of AA in MSA-1 Acknowledgment Code.

2. send an error response, providing error information in functional segments to be included in the response message with a value of AE in MSA-1 Acknowledgment Code.

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 implementers must decide on an application-specific basis whether the message SHOULD be automatically sent again. The response message contains a value of AR in MSA-1 Acknowledgment Code.

The MSH segment in the response is constructed anew following the rules used to create the initial message described above. In particular, MSH-7 Date/Time of Message and MSH-10 Message Control ID refer to the response message; they are not echoes of the fields in the initial message. MSH-5 Receiving Application, MSH-6 Receiving Facility, and MSH-11 Processing ID contain codes that are copied from MSH-3 Sending Application, MSH-4 Sending Facility and MSH-11 Processing ID in the initiating message.

In all the responses described above, the following values are put in the MSA segment. Note that the field definitions for the MSA segment fields are in Section 2.14.8, "MSA - message acknowledgment segment".

Field	Notes
MSA-1-acknowledgment code	As described above.
MSA-2-message control ID	MSH-10-message control ID from MSH segment of incoming message.
MSA-4-expected sequence number	As described in Section 2.10.1, "Sequence number protocol," (if the sequence number protocol is being used).
ERR segment fields	Refer to section 2.14.5 ERR - error segment.

The receiving application then passes the response message back to the responding system for the next step in the process.

Transmit the response message

Upon receiving the response message from the receiving application, the responding system transmits it to the initiating system.

The initiator processes the response message.

Original Mode flow chart

Response using enhanced acknowledgment

1. the responding system receives the message and commits it to safe storage. This means that the responding system accepts the responsibility for the message in a manner that releases the sending system from any obligation to resend the message. The responding system now checks the message header record to determine whether or not the initiating system requires an accept acknowledgment message indicating successful receipt and secure storage of the message. If it does, the accept acknowledgment message is constructed and returned to the initiator.

2. at this point, the requirements of the applications involved in the interface determine whether or not more information needs to be exchanged. This exchange is referred to as an application acknowledgment and includes information ranging from simple validation to a complex application-dependent response. If the receiving system is expected to return application-dependent information, it initiates another exchange when this information is available. This time, the roles of initiator and responder are reversed.

Accept and validate the message in responding system

Upon receipt of the message, , the protocol software in the responding system makes an initial determination as to whether or not the message can be accepted, based on factors such as:

Note: Both MSH-15-accept acknowledgment type and MSH-16-application acknowledgment type SHALL BE valued.

1. the status of the interface

2. the availability of safe storage onto which the message can be saved

3. the syntactical correctness of the message, if the design of the receiving system includes this type of validation at this phase

4. the values of MSH-9 Message Type, MSH-12 Version ID, and MSH-11 Processing ID, if the design of the receiving system includes this type of validation at this phase

It then examines the Message Header segment (MSH) to determine whether or not the initiating system requires an accept acknowledgment.

Transmit general acknowledgment message

A general acknowledgment message is not always required by the initiating system, but if it is the responding system sends one of the following:

1. a commit accept (CA) in MSA-1 Acknowledgment Code if the message can be accepted for processing

2. a commit reject (CR) in MSA-1 Acknowledgment Code if the one of the values of MSH-9 Message Type, MSH-12 Version ID or MSH-11 Processing ID is not acceptable to the receiving application

3. a commit error (CE) in MSA-1 Acknowledgment Code if the message cannot be accepted for any other reason (e.g., sequence number error)

Note: If the Acknowledgment Code is other than CA, the reason(s) for the rejection SHOULD be sent in the ERR segment(s) to notify the sender of the exact problem.

The MSH segment in the response is constructed anew following the rules used to create the initial message described above. In particular, MSH-7 Date/Time of Message and MSH-10 Message Control ID refer to the response message; they are not echoes of the fields in the initial message. MSH-5 Receiving Application, MSH-6 Receiving Facility, and MSH-11 Processing ID contain codes that are copied from MSH-3 Sending Application, MSH-4 Sending Facility and MSH-11 Processing ID in the initiating message.

For this response, the following values are put in the MSA segment. Note that the field definitions for the MSA segment fields are in Section 2.14.8, 'MSA - message acknowledgment segment":

Field	Notes
MSA-2-message control ID	MSH-10-message control ID from the incoming message.
MSA-1-acknowledgment code	As described above.
MSA-4-expected sequence number	As described in Section 2.10.1, "Sequence number protocol" (if the sequence number protocol is being used).
ERR segment fields	Refer to section 2.14.5 ERR - error segment

Note: MSH-15-accept acknowledgment type and MSH-16-application acknowledgment type are not valued (i.e. not present or empty). At this point, the accept portion of this message exchange is considered complete.

Transmit application acknowledgment

If the message header segment indicates that the initiating system also requires an application acknowledgment, this SHALL be returned as the initial message of a later exchange.

For this message, the receiving system acts as the initiator. Since the message it sends is application-specific, the layouts of these application-level response messages are defined in the relevant application-specific chapter. If needed, this application acknowledgment message can itself require (in MSH-15 Accept Acknowledgment Type) an accept acknowledgment message (MSA). MSH-16 Application Acknowledgment Type, however, is always NE(Never), since the protocol does not allow the application acknowledgment message to have an application acknowledgment.

For this response, the following values are put in the MSA segment. Note that the field definitions for the MSA segment fields are in Section 2.14.8, "MSA - message acknowledgment segment".

Field	Notes
MSA-2-message control ID	Identifies the initial message from the original initiating system as defined in Section 2.9.1, "Message initiation".
MSA-1-acknowledgment code	Uses the application (processing) acknowledgment codes as described in Section 2.14.8.1.
MSA-3-text message	Text description of error.q
ERR segment fields	Refer to section ERR - error segment

At this point, the application acknowledgment portion of this message exchange is considered complete.

If the processing on the receiving system goes through multiple stages, chapter-defined messages MAY be used to relay status or informational changes to other systems (including the original initiating system). Such messages are not part of the acknowledgment scheme for the original message, but are considered to be independent messages triggered by events on the (original) responding system.

Note: There is no equivalent to the V2.1 original acknowledgment protocol, where the acknowledgment is always sent as a response on the same communications channel. The enhanced acknowledgment protocol with MSH-15 (accept acknowledgment type) = NE and MSH-16 (application acknowledgment type) = AL still requires that the application acknowledgment is sent on a separate communications channel.

Enhanced acknowledgment flow chart

Message Type Table (0076)

Refer to HL7 Table 0076 – Message Type in Chapter 2C, Code Tables, for valid values.

Event Type Table (0003)

Refer to HL7 Table 0003 – Event Type in Chapter 2C, Code Tables, for valid values.

Message Structure Table (0354)

The first column of this table contains the message structure code, which describes a particular HL7 "abstract message structure definition" in terms of segments, as defined in section 2.12, "Chapter Formats For Defining HL7 Messages". The second column lists the various HL7 trigger events that use the particular abstract message definition. For example, the message structure code ADT_A01 describes the single abstract message structure used by the trigger events A01, A04, A08 and A13. Refer to HL7 Table 0354 – Message Structure in Chapter 2C, Code Tables, for valid values

Coding System Table (0396)

Note: The Vocabulary T.C. is the steward of HL7 Table 0396. As of v2.6, no special characters, except for underscore if absolutely necessary, are allowed for the Value in this table.

Refer to HL7 Table 0396 - Coding System in Chapter 2C, Code Tables, for valid values.

Yes/no Indicator Table (0136)

The actual interpretation of Yes/No is context sensitive. Individual chapters will further refine the meaning of Yes/No in their specific context. Refer to HL7 Table 0136 - Yes/no Indicator in Chapter 2C, Code Tables, for valid values

Expanded Yes/no Indicator Table (0532)

This table expands on the original Yes/no indicator table by including "flavors of null". It is intended to be applied to fields where the response is not limited to "yes" or "no". Refer to HL7 Table 0532 – Expanded Yes/no Indicator in Chapter 2C, Code Tables, for valid values.

Use Case: A reporting facility/person has little or no information on a particular event or outcome and these are reported as unknown for public health reporting purposes.

General acknowledgment

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. The AA code in the MSA segment indicates that the message was accepted by the application.

MSH|^~VALUEamp;|LAB|767543|ADT|767543|19900314130405||ACK^A08^ACK |XX3657|P|2.9

MSA|AA|ZZ9380

General acknowledgment, 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|^~VALUEamp;|LAB|767543|ADT|767543|199003141304-0500||ACK^A08^ACK |XX3657|P|2.9

MSA|AR|ZZ9380|

ERR| |PID^1^11^^9|103|E

Message using sequence number: protocol

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|^~VALUEamp;|ADT|767543|LAB|767543|199003141304-0500||ADT^A08^ADT_A01|XX3657|P|2.9|0

The responder uses a general acknowledgment. The expected sequence number is 1.

MSH|^~VALUEamp;|LAB|767543|ADT|767543|199003141304-0500||ACK^A08^ACK |ZZ9380|P|2.9

MSA|AA|XX3657||1

See section 2.10.1, "Sequence number protocol" for further detail.

Message fragmentation

This summarizes the methodology for splitting a single logical HL7 message among two or more actual HL7 messages. The actual specifications for this, the segment definitions of the ADD and DSC segments, and examples are in Section 2.10.2, "Continuation messages and segments".

Continuing of messages is a generic methodology that can be used for all HL7 message types. It can be used to split based on segment boundaries, on field boundaries, and to split a single field among several messages. It utilizes two specific segments, ADD and DSC, as well as a field in the message header, MSH-14 Continuation Pointer.

When a message is continued, a unique continuation value is used. This same value will appear in MSH-14 and DSC-1 as appropriate for a single pair of messages. This allows messages to be "chained together".

Here are two examples of ways to create continuation pointers for fragmented messages. The only absolute requirement is that when the sending application values the continuation pointer, the receiving application can appropriately reconstruct the message.

Sitecode-interfaceapplicationcode-date-sequentialcounterwithindate

This will guarantee uniqueness of this field.

e.g., BWH-LDS-19990331-27 for the 27th large message to be created on March 31, within the Discharge Summary interfaces at BWH

An alternative method of valuing the continuation pointer:

Sitecode-interfaceapplicationcode-medicalrecordnumber-datetime

e.g.. MGH-PCIS-1234567-19980331121314 for a message created on March 31, at 12:13:14pm for patient medical record number 1234567, within the PCIS interfaces at MGH

Sending Application Note: In the ADD segment, a trailing field delimiter, i.e., the vertical bar character, after the final field, has explicit meaning. The sending application SHOULD NOT include a trailing field delimiter for the last field in the ADD segment unless it has completely valued the entire field from the message being continued.

Receiving Application Note: The receiving application will need to be concerned with a single segment and a single field being continued.

Receiving a message with an empty ADD segment followed by a DSC segment is the notification that the segment preceding the ADD is being continued in a subsequent message. Note that the continuing message might not be the next one received! The receiver must match up the continuation pointer value from MSH-14 of subsequent messages to the DSC-1 continuation pointer value of the prior message. Also if the continuing message contains an ADD segment, the receiver SHOULD continue appending to the fields from the segment being continued with values from the ADD segment. For example, if OBX-5 is being continued, the continuation will appear in ADD-1 of the continuing message. If there were a value for OBX-13 of the original message, that would appear in ADD-9 of the continuing message, assuming that the remainder of the OBX segment fit into the single ADD segment.

Question: if continuing a message after the completion of a complete segment, SHOULD the continuing message have an empty ADD segment or not? Answer: No. This means that a continuing message need not have an ADD segment, if the continued message was split on a segment boundary.

Notation conventions: items within angle brackets are comments and not intended to represent a portion of an actual message. For example, .

Note the multiple continuation pointer values, one for each pair of physical messages.

Message 1

MSH|...|||...

PID|...

ORC|...

OBR|...

OBX|1|FT|^Discharge Summary|1|This is the first sentence of a long

message. This is the second sentence of a long message.

This is the 967th sentence of "

ADD|

DSC|BWH-LDS-19990405-6|

Message 2

MSH|...||BWH-LDS-19990405-6|

ADD|a long message. This is the 968th sentence of a long message.

This is the 1001st line of     

DSC|BWH-LDS-19990405-7|

Message 3

MSH|...||BWH-LDS-19990405-7|

ADD|a long message. This is the 1002nd sentence of a long message. This is the final sentence of this long message!|||||F||199707211325|

DG1|...

The following examples discuss an unsolicited transmission of an observation message, ORU^R01.

The expected result values in OBX-5 Observation Value, for reports (e.g., autopsy, pathology) MAY exceed the message length restrictions of one or more interfaces.

Thus the OBX-5 Observation Value data element will be split into more than one message.

Here's an example intended to illustrate the interpretation of Chapter 2 and 7. It reflects a single logical message broken up into three distinct messages.

Example 1, a single field being split across three messages

Acknowledgment message using original mode processing

This example shows the lab system using the Master Files specification to send two update test dictionary entries to an ICU system.

Initiating Message:

MSH|^~VALUEamp;|LABxxx|ClinLAB|ICU||19910918060544||MFN^M03^MFN_M03|MSGID002|P|2.9

MFI|...

Response Message: Original mode acknowledgment of the HL7 message according to MFI Response Level Code of AL.

MSH|^~VALUEamp;|ICU||LABxxx|ClinLAB|19910918060545||MFK^M03^MFK_M01|MSGID99002|P|2.9

MSA|AA|MSGID002

MFI|LABxxx^Lab Test Dictionary^L|UPD|||MFAA

MFA|MUP|199110010000|199110010040|S|12345^WBC^L

MFA|MUP|199110010000|199110010041|S|6789^RBC^L...

Acknowledgment message using enhanced mode processing

Initial message with accept acknowledgment

MSH|^~VALUEamp;|LABxxx|ClinLAB|ICU||19910918060544||MFN^M03^MFN_M03|MSGID002|P|2.9|||AL|AL

MFI|...

MSH|^~VALUEamp;|ICU||LABxxx|ClinLAB|19910918060545||MSA|MSGID99002|P|2.9

MSA|CA|MSGID002

Application acknowledgment message

MSH|^~VALUEamp;|ICU||LABxxx|ClinLAB|19911001080504|| MFK^M03^MFK_M01|MSGID5002|P|2.9|||AL|

MSA|AA|MSGID002

MFI|...

MSH|^~VALUEamp;|LABxxx|ClinLAB|ICU||19911001080507||ACK|MSGID444|P|2.9

MSA|CA|MSGID5002