999 Implementation Acknowledgment For Health Care Insurance (005010X231, 005010X231A1)

The purpose of this implementation guide is to provide standardized data content and structure to users of the ASC X12 999 transaction set for Health Care Insurance. This implementation guide is intended to enable a receiver of a functional group based on an X12 Implementation Guideline (TR3) related to Health Care Insurance business processes, to report the syntactical and relational analysis as specified by that implementation guideline (TR3), or to acknowledge receipt of an error-free transaction set.

This 999 is not limited to only Implementation Guide (IG) errors. It can report standard syntax errors, as well as IG errors.

This 999 implementation guide can NOT be used for any application level validations.

This implementation guide is based on the October 2003 ASC X12 standards, referred to as Version 5, Release 1, Sub-release 0 (005010). The unique Version/ Release/Industry Identifier Code for transaction sets that are defined by this implementation guide is 005010X231A1.

The two-character Functional Identifier Code for the transaction set included in this implementation guide:

• FA Functional or Implementation Acknowledgment Transaction Sets (997, 999)

The Version/Release/Industry Identifier Code and the applicable Functional Identifier Code must be transmitted in the Functional Group Header (GS segment) that begins a functional group of these transaction sets. For more information, see the descriptions of GS01 and GS08 in Appendix C.

There are multiple methods available for sending and receiving business transactions electronically. Two common modes for EDI transactions are batch and realtime.

Batch - In a batch mode the sender does not remain connected while the receiver processes the transactions. Processing is usually completed according to a set schedule. If there is an associated business response transaction (such as a 271 Response to a 270 Request for Eligibility), the receiver creates the response transaction and stores it for future delivery. The sender of the original transmission reconnects at a later time and picks up the response transaction.

This implementation guide does not set specific response time parameters for these activities.

Real Time - In real-time mode the sender remains connected while the receiver processes the transactions and returns a response transaction to the sender. This implementation guide does not set specific response time parameters for implementers.

This implementation guide is intended to support use in batch mode. This implementation guide is intended to support use in real-time mode. A statement that the transaction is not intended to support a specific mode does not preclude its use in that mode between willing trading partners.

The ASC X12 999 transaction set is designed to report only on conformance against an implementation guideline (TR3).

The 999 is not limited to only IG errors. It can report standard syntax errors, as well as IG errors.

This 999 implementation guide can NOT be used for any application level validations.

The ASC X12 999 transaction set is designed to respond to one and only one functional group (i.e. GS/GE), but will respond to all transaction sets (i.e. ST/SE) within that functional group.

This ASC X12 999 Implementation Guideline can NOT be used to respond to any management transaction sets intended for acknowledgements, i.e. TS 997 and 999, or interchange control segments related to acknowledgments, i.e. TA1 and TA3.

This ASC X12 999 implementation guide (TR3) is intended to meet the needs of the Health Care industry as a whole, for a standard implementation guideline designed for reporting of syntactical errors against a functional group based on an X12 Implementation Guideline, or to report receipt of a functional group that fully complies with an implementation guideline.

For more information on the relationship between the 999 transaction set and other response transaction sets, refer to the ASC X12 document "Reference Model for the Acknowledgment and Tracking of EDI Interchanges".

No special business terms are used in this implementation guide.

This is one of several acknowledgment transactions available for use. Acknowledgment transactions may be used at the discretion of the trading partners.

This ASC X12 999 Implementation Guide (TR3) is designed for responding to Health Care transactions based upon an Implementation Guide, including, but not limited to, the following:

269 005010X187

270 005010X203

271 005010X203

274 005030X209

275 005040X254

276 005010X212

277 005010X212

278 005010X217

820 005010X218

834 005010X220

835 005010X221

837 005010X222

837 005010X223

837 005010X224

Trading partner agreements are used to establish and document the relationship between trading partners. A trading partner agreement must not override the specifications in this implementation guide if a transmission is reported in GS08 to be a product of this implementation guide.

NOTE

See Appendix B, Nomenclature, to review the transaction set structure, including descriptions of segments, data elements, levels and loops.

The following sequence diagram (sd) shows how the 999 transaction set is used with other X12 response transactions.

Figure 1.1 - Sequence Diagram

For more information on the relationship between the 999 transaction set and other response transaction sets, refer to the ASC X12 document "Reference Model for the Acknowledgement and Tracking of EDI Interchanges".

NOTE

See Appendix B, Nomenclature, to review the transaction set structure, including descriptions of segments, data elements, levels, and loops.

The ASC X12 standards are generic. For example, multiple trading communities use the same PER segment to specify administrative communication contacts. Each community decides which elements to use and which code values in those elements are applicable.

This implementation guide uses a format that depicts both the generalized standard and the insurance industry-specific implementation. In this implementation guide, IMPLEMENTATION specifies the requirements for this implementation. X12 STANDARD is included as a reference only.

The transaction set presentation is comprised of two main sections with subsections within the main sections:

2.3 Transaction Set Listing

There are two sub-sections under this general title. The first sub-section concerns this implementation of a generic X12 transaction set. The second sub-section concerns the generic X12 standard itself.

This section lists the levels, loops, and segments contained in this implementation. It also serves as an index to the segment detail.

This section is included as a reference.

2.4 Segment Detail

There are three sub-sections under this general title. This section repeats once for each segment used in this implementation providing segment specific detail and X12 standard detail.

This section is included as a reference.

This section is included as a reference. It provides a pictorial view of the standard and shows which elements are used in this implementation.

This section specifies the implementation details of each data element.

These illustrations (Figures 2.1 through 2.5) are examples and are not extracted from the Section 2 detail in this implementation guide. Annotated illustrations, presented below in the same order they appear in this implementation guide, describe the format of the transaction set that follows.

Figure 2.1 - Transaction Set Key - Implementation

Figure 2.2 - Transaction Set Key - Standard

Figure 2.3 - Segment Key - Implementation

Figure 2.4 - Segment Key - Diagram

Figure 2.5 - Segment Key - Element Summary

Industry Usage describes when loops, segments, and elements are to be sent when complying with this implementation guide. The three choices for Usage are required, not used, and situational. To avoid confusion, these are named differently than the X12 standard Condition Designators (mandatory, optional, and relational).

A transmitted transaction complies with an implementation guide when it satisfies the requirements as defined within the implementation guide. The presence or absence of an item (loop, segment, or element) complies with the industry usage specified by this implementation guide according to the following table.

Loop requirements depend on the context or location of the loop within the transaction. See Appendix B for more information on loops.

• A nested loop can be used only when the associated higher level loop is used.

• The usage of a loop is the same as the usage of its beginning segment.

  • If a loop's beginning segment is Required, the loop is Required and must occur at least once unless it is nested in a loop that is not being used.

  • If a loop's beginning segment is Situational, the loop is Situational.

• Subsequent segments within a loop can be sent only when the beginning segment is used.

• Required segments in Situational loops occur only when the loop is used.

The following example describes a 999 transaction set that is responding to a functional group that was received containing three 837 transaction sets. The first transaction set conformed fully with the X12 standard, while the second and third contained errors.

The Interchange Control and Functional Group segments (ISA, GS, GE, and IEA) are required in the ASC X12 message. See Appendix C for additional details on these segments.

ISA*00*          *00*          *ZZ*123456789

*ZZ*987654321

*041117*1024*^*00501*000000286*0*P*:~

GS*FA*RCVR*SNDR*20041117*1024*287*X*005010X231~

The ST segment indicates the beginning of the 999 transaction set, control number 2870001.

ST*999*2870001*005010X231~

The AK1 segment describes the functional group to which this 999 is responding.

AK1*HC*17456*004010X098A1~

The first Transaction Response Loop indicates that the received transaction set, control number 0001, was accepted with no errors.

AK2*837*0001~

IK5*A~

The second Transaction Response Loop indicates that the received transaction set, control number 0002, was rejected due to a missing CLM02 data element. The CTX segment identifies the Business Unit (i.e. the claim) that was in error.

AK2*837*0002~

IK3*CLM*22**8~

AK2*837*0002~

CTX*CLM01:123456789~

AK2*837*0002~

IK4*2*782*1~

IK5*R*5~

The third Transaction Response Loop indicates that the received transaction set, control number 003, was rejected due to a missing REF (Original Reference Number ICN/DCN) segment. This segment is required by the implementation guide when CLM05-3 = 6, 7, or 8. The IK3 segment indicates the missing REF segment, and the first CTX segment indicates the CLM05-3 as the reason for the missing REF segment. The second CTX identifies the Business Unit (i.e. the claim) that was in error.

AK2*837*0003~

IK3*REF*57**3~

CTX*SITUATIONAL TRIGGER*CLM*43**5:3*C023:1325~

CTX*CLM01:987654321~

IK5*R*5~

The Trailer section provides a summary of the disposition of the received functional group, and ends the transaction set.

AK9*P*3*3*1~

SE*16*2870001~

GE*1*287~

IEA*1*000000286~

Appendix A is a listing of all external code sources referenced in this implementation guide.

77 X12 Directories

SIMPLE DATA ELEMENT/CODE REFERENCES

721, 725

SOURCE

X12.3 Data Element Dictionary

X12.22 Segment Directory

AVAILABLE FROM

Data Interchange Standards Association, Inc. (DISA)

Suite 200

1800 Diagonal Road

Alexandria, VA 22314-2852

ABSTRACT

The data element dictionary contains the format and descriptions of data elements used to construct X12 segments. It also contains code lists associated with these data elements. The segment directory contains the format and definitions of the data segments used to construct X12 transaction sets.

881 Version / Release / Industry Identifier Code

SIMPLE DATA ELEMENT/CODE REFERENCES

480

SOURCE

Data Interchange Standards Association

AVAILABLE FROM

Data Interchange Standards Association

333 John Carlyle Street, Suite 600

Alexandria, VA 22314

ABSTRACT

Code indicating the version, release, sub-release, and industry identifier of the EDI standard being used, including the GS and GE segments; if code in DE455 in GS segment is X, then in DE 480 positions 1-3 are the version number; positions 4-6 are the release and sub-release, level of the version; and positions 7-12 are the industry or trade association identifiers (optionally assigned by user); if code in DE455 in GS segment is T, then other formats are allowed.

Appendix B is provided as a reference to the X12 syntax, usage, and related information. It is not a full statement of Interchange and Control Structure rules. The full X12 Interchange and Control Structures and other rules (X12.5, X12.6, X12.59, X12 dictionaries, other X12 standards and official documents) apply unless specifically modified in the detailed instructions of this implementation guide (see Section B.1.1.3.1.2 - Decimal for an example of such a modification).

The transmission of data proceeds according to very strict format rules to ensure the integrity and maintain the efficiency of the interchange. Each business grouping of data is called a transaction set. For instance, a group of benefit enrollments sent from a sponsor to a payer is considered a transaction set.

Each transaction set contains groups of logically related data in units called segments. For instance, the N4 segment used in the transaction set conveys the city, state, ZIP Code, and other geographic information. A transaction set contains multiple segments, so the addresses of the different parties, for example, can be conveyed from one computer to the other. An analogy would be that the transaction set is like a freight train; the segments are like the train's cars; and each segment can contain several data elements the same as a train car can hold multiple crates.

The sequence of the elements within one segment is specified by the ASC X12 standard as well as the sequence of segments in the transaction set. In a more conventional computing environment, the segments would be equivalent to records, and the elements equivalent to fields.

Similar transaction sets, called "functional groups," can be sent together within a transmission. Each functional group is prefaced by a group start segment; and a functional group is terminated by a group end segment. One or more functional groups are prefaced by an interchange header and followed by an interchange trailer. Figure B.1 - Transmission Control Schematic, illustrates this interchange control.

Figure B.1 - Transmission Control Schematic

The interchange header and trailer segments envelop one or more functional groups or interchange-related control segments and perform the following functions:

A data element corresponds to a data field in data processing terminology. A data segment corresponds to a record in data processing terminology. The data segment begins with a segment ID and contains related data elements. A control segment has the same structure as a data segment; the distinction is in the use. The data segment is used primarily to convey user information, but the control segment is used primarily to convey control information and to group data segments.

The section that follows is designed to have representation in the common character code schemes of EBCDIC, ASCII, and CCITT International Alphabet 5. The ASC X12 standards are graphic-character-oriented; therefore, common character encoding schemes other than those specified herein may be used as long as a common mapping is available. Because the graphic characters have an implied mapping across character code schemes, those bit patterns are not provided here.

The basic character set of this standard, shown in Table B.1 - Basic Character Set, includes those selected from the uppercase letters, digits, space, and special characters as specified below.

Table B.1 - Basic Character Set

A...Z	0...9	!	"	&	'	(	)	+	*
,	-	.	/	:	;	?	=	“” (space)

An extended character set may be used by negotiation between the two parties and includes the lowercase letters and other special characters as specified in Table B.2 - Extended Character Set.

Note that the extended characters include several character codes that have multiple graphical representations for a specific bit pattern. The complete list appears in other standards such as CCITT S.5. Use of the USA graphics for these codes presents no problem unless data is exchanged with an international partner. Other problems, such as the translation of item descriptions from English to French, arise when exchanging data with an international partner, but minimizing the use of codes with multiple graphics eliminates one of the more obvious problems.

For implementations compliant with this guide, either the entire extended character set must be acceptable, or the entire extended character set must not be used. In the absence of a specific trading partner agreement to the contrary, trading partners will assume that the extended character set is acceptable. Use of the extended character set allows the use of the "@" character in email addresses within the PER segment. Users should note that characters in the extended character set, as well as the basic character set, may be used as delimiters only when they do not occur in the data as stated in Section B.1.1.2.4.1 - Base Control Set.

Two control character groups are specified; they have restricted usage. The common notation for these groups is also provided, together with the character coding in three common alphabets. In Table B.3 - Base Control Set, the column IA5 represents CCITT V.3 International Alphabet 5.

The base control set includes those characters that will not have a disruptive effect on most communication protocols. These are represented by:

The Group Separator (GS) may be an exception in this set because it is used in the 3780 communications protocol to indicate blank space compression.

The extended control set includes those that may have an effect on a transmission system. These are shown in Table B.4 - Extended Control Set.

A delimiter is a character used to separate two data elements or component elements or to terminate a segment. The delimiters are an integral part of the data.

Delimiters are specified in the interchange header segment, ISA. The ISA segment can be considered in implementations compliant with this guide (see Appendix C, ISA Segment Note 1) to be a 105 byte fixed length record, followed by a segment terminator. The data element separator is byte number 4; the repetition separator is byte number 83; the component element separator is byte number 105; and the segment terminator is the byte that immediately follows the component element separator.

Once specified in the interchange header, the delimiters are not to be used in a data element value elsewhere in the interchange. For consistency, this implementation guide uses the delimiters shown in Table B.5 - Delimiters, in all examples of EDI transmissions.

The delimiters above are for illustration purposes only and are not specific recommendations or requirements. Users of this implementation guide should be aware that an application system may use some valid delimiter characters within the application data. Occurrences of delimiter characters in transmitted data within a data element will result in errors in translation. The existence of asterisks (*) within transmitted application data is a known issue that can affect translation software.

The ASC X12 standards define commonly used business transactions (such as a health care claim) in a formal structure called "transaction sets." A transaction set is composed of a transaction set header control segment, one or more data segments, and a transaction set trailer control segment. Each segment is composed of the following:

The data element is the smallest named unit of information in the ASC X12standard. Data elements are identified as either simple or component. A data element that occurs as an ordinally positioned member of a composite data structure is identified as a component data element. A data element that occurs in a segment outside the defined boundaries of a composite data structure is identified as a simple data element. The distinction between simple and component data elements is strictly a matter of context because a data element can be used in either capacity.

Data elements are assigned a unique reference number. Each data element has a name, description, type, minimum length, and maximum length. For ID type data elements, this guide provides the applicable ASC X12 code values and their descriptions or references where the valid code list can be obtained.

A simple data element within a segment may have an attribute indicating that it may occur once or a specific number of times more than once. The number of permitted repeats are defined as an attribute in the individual segment where the repeated data element occurs.

Each data element is assigned a minimum and maximum length. The length of the data element value is the number of character positions used except as noted for numeric, decimal, and binary elements.

The data element types shown in Table B.6 - Data Element Types, appear in this implementation guide.

The data element minimum and maximum lengths may be restricted in this implementation guide for a compliant implementation. Such restrictions may occur by virtue of the allowed qualifier for the data element or by specific instructions regarding length or format as stated in this implementation guide.

A numeric data element is represented by one or more digits with an optional leading sign representing a value in the normal base of 10. The value of a numeric data element includes an implied decimal point. It is used when the position of the decimal point within the data is permanently fixed and is not to be transmitted with the data.

This set of guides denotes the number of implied decimal positions. The representation for this data element type is "Nn" where N indicates that it is numeric and n indicates the number of decimal positions to the right of the implied decimal point.

If n is 0, it need not appear in the specification; N is equivalent to N0. For negative values, the leading minus sign (-) is used. Absence of a sign indicates a positive value. The plus sign (+) must not be transmitted.

EXAMPLE

A transmitted value of 1234, when specified as numeric type N2, represents a value of 12.34.

Leading zeros must be suppressed unless necessary to satisfy a minimum length requirement. The length of a numeric type data element does not include the optional sign.

A decimal data element may contain an explicit decimal point and is used for numeric values that have a varying number of decimal positions. This data element type is represented as "R."

The decimal point always appears in the character stream if the decimal point is at any place other than the right end. If the value is an integer (decimal point at the right end) the decimal point must be omitted. For negative values, the leading minus sign (-) is used. Absence of a sign indicates a positive value. The plus sign (+) must not be transmitted.

Leading zeros must be suppressed unless necessary to satisfy a minimum length requirement. Trailing zeros following the decimal point must be suppressed unless necessary to indicate precision. The use of triad separators (for example, the commas in 1,000,000) is expressly prohibited. The length of a decimal type data element does not include the optional leading sign or decimal point.

EXAMPLE

A transmitted value of 12.34 represents a decimal value of 12.34.

While the ASC X12 standard supports usage of exponential notation, this guide prohibits that usage.

For implementation of this guide under the rules promulgated under the Health Insurance Portability and Accountability Act (HIPAA), decimal data elements in Data Element 782 (Monetary Amount) will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). Note the statement in the preceding paragraph that the decimal point and leading sign, if sent, are not part of the character count.

EXAMPLE

For implementations mandated under HIPAA rules:

An identifier data element always contains a value from a predefined list of codes that is maintained by the ASC X12 Committee or some other body recognized by the Committee. Trailing spaces must be suppressed unless they are necessary to satisfy a minimum length. An identifier is always left justified. The representation for this data element type is "ID."

A string data element is a sequence of any characters from the basic or extended character sets. The string data element must contain at least one non-space character. The significant characters shall be left justified. Leading spaces, when they occur, are presumed to be significant characters. Trailing spaces must be suppressed unless they are necessary to satisfy a minimum length. The representation for this data element type is"AN."

A date data element is used to express the standard date in either YYMMDD or CCYYMMDD format in which CC is the first two digits of the calendar year, YY is the last two digits of the calendar year, MM is the month (01 to 12), and DD is the day in the month (01 to 31). The representation for this data element type is "DT." Users of this guide should note that all dates within transactions are 8-character dates (millennium compliant) in the format CCYYMMDD. The only date data element that is in format YYMMDD is the Interchange Date data element in the ISA segment and the TA1 segment where the century is easily determined because of the nature of an interchange header.

A time data element is used to express the ISO standard time HHMMSSd..d format in which HH is the hour for a 24 hour clock (00 to 23), MM is the minute (00 to 59), SS is the second (00 to 59) and d..d is decimal seconds. The representation for this data element type is "TM." The length of the data element determines the format of the transmitted time.

EXAMPLE

Transmitted data elements of four characters denote HHMM. Transmitted data elements of six characters denote HHMMSS.

The binary data element is any sequence of octets ranging in value from binary 00000000 to binary 11111111. This data element type has no defined maximum length. Actual length is specified by the immediately preceding data element. Within the body of a transaction set (from ST to SE) implemented according to this technical report, the binary data element type is only used in the segments Binary Data Segment BIN, and Binary Data Structure BDS. Within those segments, Data Element 785 Binary Data is a string of octets which can assume any binary pattern from hexadecimal 00 to FF, and can be used to send text as well as coded data, including data from another application in its native format. The binary data type is also used in some control and security structures.

Not all transaction sets use the Binary Data Segment BIN or Binary Data Structure BDS.

Simple or composite data elements within a segment can be designated asrepeating data elements. Repeating data elements are adjacent data elements that occur up to a number of times specified in the standard as number of repeats. The implementation guide may also specify the number of repeats of a repeating data element in a specific location in the transaction that are permitted in a compliant implementation. Adjacent occurrences of the same repeating simple data element or composite data structure in a segment shall be separated by a repetition separator.

The composite data structure is an intermediate unit of information in a segment. Composite data structures are composed of one or more logically related simple data elements, each, except the last, followed by a sub-element separator. The final data element is followed by the next data element separator or the segment terminator. Each simple data element within a composite is called a component.

Each composite data structure has a unique four-character identifier, a name, and a purpose. The identifier serves as a label for the composite. A composite data structure can be further defined through the use of syntax notes, semantic notes, and comments. Each component within the composite is further characterized by a reference designator and a condition designator. The reference designators and the condition designators are described in Section B.1.1.3.8 - Reference Designator and Section B.1.1.3.9 - Condition Designator.

A composite data structure within a segment may have an attribute indicating that it may occur once or a specific number of times more than once. The number of permitted repeats are defined as an attribute in the individual segment where the repeated composite data structure occurs.

The data segment is an intermediate unit of information in a transaction set. In the data stream, a data segment consists of a segment identifier, one or more composite data structures or simple data elements each preceded by a data element separator and succeeded by a segment terminator.

Each data segment has a unique two- or three-character identifier, a name, and a purpose. The identifier serves as a label for the data segment. A segment can be further defined through the use of syntax notes, semantic notes, and comments. Each simple data element or composite data structure within the segment is further characterized by a reference designator and a condition designator.

Syntax notes describe relational conditions among two or more data segment units within the same segment, or among two or more component data elements within the same composite data structure. For a complete description of the relational conditions, See Section B.1.1.3.9 - Condition Designator.

Simple data elements or composite data structures may be referenced by a semantic note within a particular segment. A semantic note provides important additional information regarding the intended meaning of a designated data element, particularly a generic type, in the context of its use within a specific data segment. Semantic notes may also define a relational condition among data elements in a segment based on the presence of a specific value (or one of a set of values) in one of the data elements.

A segment comment provides additional information regarding the intended use of the segment.

Each simple data element or composite data structure in a segment is provideda structured code that indicates the segment in which it is used and thesequential position within the segment. The code is composed of the segmentidentifier followed by a two-digit number that defines the position of thesimple data element or composite data structure in that segment.

For purposes of creating reference designators, the composite data structureis viewed as the hierarchical equal of the simple data element. Each componentdata element in a composite data structure is identified by a suffix appended tothe reference designator for the composite data structure of which it is amember. This suffix is prefixed with a hyphen and definesthe position of the component data element in the composite data structure.

EXAMPLE

This section provides information about X12 standard conditions designators. It is provided so that users will have information about the general standard. Implementation guides may impose other conditions designators. See implementation guide section 2.1 Presentation Examples for detailed information about the implementation guide Industry Usage requirements for compliant implementation.

Data element conditions are of three types: mandatory, optional, and relational. They define the circumstances under which a data element may be required to be present or not present in a particular segment.

Any simple data element that is indicated as mandatory must not be empty if the segment is used. At least one component data element of a composite data structure that is indicated as mandatory must not be empty if the segment is used. Optional simple data elements and/or composite data structures and their preceding data element separators that are not needed must be omitted if they occur at the end of a segment. If they do not occur at the end of the segment, the simple data element values and/or composite data structure values may be omitted. Their absence is indicated by the occurrence of their preceding data element separators, in order to maintain the element's or structure's position as defined in the data segment.

Likewise, when additional information is not necessary within a composite, the composite may be terminated by providing the appropriate data element separator or segment terminator.

If a segment has no data in any data element within the segment (an "empty" segment), that segment must not be sent.

A control segment has the same structure as a data segment, but it is used fortransferring control information rather than application information.

Loop control segments are used only to delineate bounded loops. Delineation of the loop shall consist of the loop header (LS segment) and the loop trailer (LE segment). The loop header defines the start of a structure that must contain one or more iterations of a loop of data segments and provides the loop identifier for this loop. The loop trailer defines the end of the structure. The LS segment appears only before the first occurrence of the loop, and the LE segment appears only after the last occurrence of the loop. Unbounded looping structures do not use loop control segments.

The transaction set is delineated by the transaction set header (ST segment) and the transaction set trailer (SE segment). The transaction set header identifies the start and identifier of the transaction set. The transaction set trailer identifies the end of the transaction set and provides a count of the data segments, which includes the ST and SE segments.

The functional group is delineated by the functional group header (GS segment) and the functional group trailer (GE segment). The functional group header starts and identifies one or more related transaction sets and provides a control number and application identification information. The functional group trailer defines the end of the functional group of related transaction sets and provides a count of contained transaction sets.

The control segment of this standard must have a nested relationship as is shown and annotated in this subsection. The letters preceding the control segment name are the segment identifier for that control segment. The indentation of segment identifiers shown below indicates the subordination among control segments.

GS Functional Group Header, starts a group of related transaction sets.

ST Transaction Set Header, starts a transaction set.

LS Loop Header, starts a bounded loop of data segments but is not part of the loop.

LS Loop Header, starts an inner, nested, bounded loop.

LE Loop Trailer, ends an inner, nested bounded loop.

LE Loop Trailer, ends a bounded loop of data segments but is not part of the loop.

SE Transaction Set Trailer, ends a transaction set.

GE Functional Group Trailer, ends a group of related transaction sets.

More than one ST/SE pair, each representing a transaction set, may be used within one functional group. Also more than one LS/LE pair, each representing a bounded loop, may be used within one transaction set.

The transaction set is the smallest meaningful set of information exchanged between trading partners. The transaction set consists of a transaction set header segment, one or more data segments in a specified order, and a transaction set trailer segment. See Figure B.1 - Transmission Control Schematic.

A transaction set identifier uniquely identifies a transaction set. This identifier is the first data element of the Transaction Set Header Segment (ST). A user assigned transaction set control number in the header must match the control number in the Trailer Segment (SE) for any given transaction set. The value for the number of included segments in the SE segment is the total number of segments in the transaction set, including the ST and SE segments.

The data segments in a transaction set may be repeated as individual data segments or as unbounded or bounded loops.

When a single data segment is allowed to be repeated, it may have a specified maximum number of occurrences defined at each specified position within a given transaction set standard. Alternatively, a segment may be allowed to repeat an unlimited number of times. The notation for an unlimited number of repetitions is ">1."

Loops are groups of semantically related segments. Data segment loops may be unbounded or bounded.

Unbounded Loops

To establish the iteration of a loop, the first data segment in the loop must appear once and only once in each iteration. Loops may have a specified maximum number of repetitions. Alternatively, the loop may be specified as having an unlimited number of iterations. The notation for an unlimited number of repetitions is ">1."

A specified sequence of segments is in the loop. Loops themselves are optional or mandatory. The requirement designator of the beginning segment of a loop indicates whether at least one occurrence of the loop is required. Each appearance of the beginning segment defines an occurrence of the loop.

The requirement designator of any segment within the loop after the beginning segment applies to that segment for each occurrence of the loop. If there is a mandatory requirement designator for any data segment within the loop after the beginning segment, that data segment is mandatory for each occurrence of the loop. If the loop is optional, the mandatory segment only occurs if the loop occurs.

Bounded Loops

The characteristics of unbounded loops described previously also apply to bounded loops. In addition, bounded loops require a Loop Start Segment (LS) to appear before the first occurrence and a Loop End Segment (LE) to appear after the last consecutive occurrence of the loop. If the loop does not occur, the LS and LE segments are uppressed.

When data segments are combined to form a transaction set, three characteristics are applied to each data segment: a requirement designator, a position in the transaction set, and a maximum occurrence.

A data segment, or loop, has one of the following requirement designators for health care and insurance transaction sets, indicating its appearance in the data stream of a transmission. These requirement designators are represented by a single character code.

The ordinal positions of the segments in a transaction set are explicitly specified for that transaction. Subject to the flexibility provided by the optional requirement designators of the segments, this positioning must be maintained.

A data segment may have a maximum occurrence of one, a finite number greater than one, or an unlimited number indicated by ">1."

A functional group is a group of similar transaction sets that is bounded by a functional group header segment and a functional group trailer segment. The functional identifier defines the group of transactions that may be included within the functional group. The value for the functional group control number in the header and trailer control segments must be identical for any given group. The value for the number of included transaction sets is the total number of transaction sets in the group. See Figure B.1 - Transmission Control Schematic.

Typically, the term "interchange" connotes the ISA/IEA envelope that is transmitted between trading/business partners. Interchange control is achieved through several "control" components. The interchange control number is contained in data element ISA13 of the ISA segment. The identical control number must also occur in data element 02 of the IEA segment. Most commercial translation software products will verify that these two elements are identical. In most translation software products, if these elements are different the interchange will be "suspended" in error.

There are many other features of the ISA segment that are used for controlmeasures. For instance, the ISA segment contains data elements such asauthorization information, security information, sender identification, andreceiver identification that can be used for control purposes. These dataelements are agreed upon by the trading partners prior to transmission. Theinterchange date and time data elements as well as the interchange controlnumber within the ISA segment are used for debugging purposes when there is aproblem with the transmission or the interchange.

Data Element ISA12, Interchange Control Version Number, indicates the versionof the ISA/IEA envelope. GS08 indicates the version of the transaction setscontained within the ISA/IEA envelope. The versions are not required to be thesame. An Interchange Acknowledgment can be requested through data element ISA14.The interchange acknowlegement is the TA1 segment. Data element ISA15, TestIndicator, is used between trading partners to indicate that the transmission isin a "test" or "production" mode. Data element ISA16, Subelement Separator, isused by the translator for interpretation of composite data elements.

The ending component of the interchange or ISA/IEA envelope is the IEAsegment. Data element IEA01 indicates the number of functional groups that areincluded within the interchange. In most commercial translation softwareproducts, an aggregate count of functional groups is kept while interpreting theinterchange. This count is then verified with data element IEA01. If there is adiscrepancy, in most commercial products, the interchange is suspended. Theother data element in the IEA segment is IEA02 which is referenced above.

See Appendix C, EDI Control Directory, for a complete detailing of theinter-change control header and trailer. The authors recommend that when twotransactions with different X12 versions numbers are sent in one interchangecontrol structure (multiple functional groups within one ISA/IEA envelope), theInterchange Control version used should be that of the most recent transactionversion included in the envelope. For the transmission of HIPAA transactionswith mixed versions, this would be a compliant enveloping structure.

Control structures within the functional group envelope include the functionalidentifier code in GS01. The Functional Identifier Code is used by thecommercial translation software during interpretation of the interchange todetermine the different transaction sets that may be included within thefunctional group. If an inappropriate transaction set is contained within thefunctional group, most commercial translation software will suspend thefunctional group within the interchange. The Application Sender's Code in GS02can be used to identify the sending unit of the transmission. The ApplicationReceiver's Code in GS03 can be used to identify the receiving unit of thetransmission. The functional group contains a creation date (GS04) and creationtime (GS05) for the functional group. The Group Control Number is contained inGS06. These data elements (GS04, GS05, and GS06) can be used for debuggingpurposes. GS08,Version/Release/Industry Identifier Code is theversion/release/sub-release of the transaction sets being transmitted in thisfunctional group.

The Functional Group Control Number in GS06 must be identical to data element02 of the GE segment. Data element GE01 indicates the number of transaction setswithin the functional group. In most commercial translation software products,an aggregate count of the transaction sets is kept while interpreting thefunctional group. This count is then verified with data element GE01.

See Appendix C, EDI Control Directory, for a complete detailing of thefunctional group header and trailer.

The HL segment is used in several X12 transaction sets to identify levels of detail information using a hierarchical structure, such as relating dependents to a subscriber. Hierarchical levels may differ from guide to guide.

For example, each provider can bill for one or more subscribers, each subscriber can have one or more dependents and the subscriber and the dependents can make one or more claims.

Each guide states what levels are available, the level's usage, number of repeats, and whether that level has subordinate levels within a transaction set.

For implementations compliant with this guide, the repeats of the loopsidentified by the HL structure shall appear in the hierarchical order specifiedin BHT01, when those particular hierarchical levels exist. That is, an HL parentloop must be followed by the subordinate child loops, if any, prior tocommencing a new HL parent loop at the same hierarchical level.

The following diagram, from transaction set 837, illustrates a typicalhierarchy.

The two examples below illustrate this requirement:

Example 1 based on Implementation Guide 811X201:

INSURER

First STATE in transaction (child of INSURER)

First POLICY in transaction (child of first STATE)

First VEHICLE in transaction (child of first POLICY)

Second POLICY in transaction (child of first STATE)

Second VEHICLE in transaction (child of second POLICY)

Third VEHICLE in transaction (child of second POLICY)

Second STATE in transaction (child of INSURER)

Third POLICY in transaction (child of second STATE)

Fourth VEHICLE in transaction (child of third POLICY)

Example 2 based on Implementation Guide 837X141

First PROVIDER in transaction

First SUBSCRIBER in transaction (child of first PROVIDER)

Second PROVIDER in transaction

Second SUBSCRIBER in transaction (child of second PROVIDER)

First DEPENDENT in transaction (child of second SUBSCRIBER)

Second DEPENDENT in transaction (child of second SUBSCRIBER)

Third SUBSCRIBER in transaction (child of second PROVIDER)

Third PROVIDER in transaction

Fourth SUBSCRIBER in transaction (child of third PROVIDER)

Fifth SUBSCRIBER in transaction (child of third PROVIDER)

Third DEPENDENT in transaction (child of fifth SUBSCRIBER)

The TA1 segment provides the capability for the interchange receiver to notify the sender that a valid envelope was received or that problems were encountered with the interchange control structure. The TA1 verifies the envelopes only. Transaction set-specific verification is accomplished through use of the Functional Acknowledgment Transaction Set, 997. See Section B.1.1.5.2 - Functional Acknowledgment, 997, for more details. The TA1 is unique in that it is a single segment transmitted without the GS/GE envelope structure. A TA1 can be included in an interchange with other functional groups and transactions.

Encompassed in the TA1 are the interchange control number, interchange date and time, interchange acknowledgment code, and the interchange note code. The interchange control number, interchange date and time are identical to those that were present in the transmitted interchange from the trading partner. This provides the capability to associate the TA1 with the transmitted interchange. TA104, Interchange Acknowledgment Code, indicates the status of the interchange control structure. This data element stipulates whether the transmitted interchange was accepted with no errors, accepted with errors, or rejected because of errors. TA105, Interchange Note Code, is a numerical code that indicates the error found while processing the interchange control structure. Values for this data element indicate whether the error occurred at the interchange or functional group envelope.

The Functional Acknowledgment Transaction Set, 997, has been designed to allow trading partners to establish a comprehensive control function as a part of their business exchange process. This acknowledgment process facilitates control of EDI. There is a one-to-one correspondence between a 997 and a functional group. Segments within the 997 can identify the acceptance or rejection of the functional group, transaction sets or segments. Data elements in error can also be identified. There are many EDI implementations that have incorporated the acknowledgment process in all of their electronic communications. The 997 is used as a functional acknowledgment to a previously transmitted functional group.

The 997 is a transaction set and thus is encapsulated within the interchange control structure (envelopes) for transmission.

Object Descriptors (OD) provide a method to uniquely identify specific locations within an implementation guide. There is an OD assigned at every level of the X12N implementation:

ODs at the first four levels are coded using X12 identifiers separated by underbars:

The fifth and sixth levels add a name derived from the "Industry Term" defined in the X12N Data Dictionary. The name is derived by removing the spaces.

Said in another way, ODs contain a coded component specifying a location in animplementation guide, a separator, and a name portion. For example:

Since ODs are unique across all X12N implementation guides, they can be used for a variety of purposes. For example, as a cross reference to older data transmission systems, like the National Standard Format for health care claims, or to form XML tags for newer data transmission systems.

This is the first ASC X12N Implementation Guide for the Implementation Acknowledgment business use of the 999. In future guides, this section will contain a summary and detail of all changes since the previous guide.