EDI Structure – X12 Primer

The rules for the X12 envelope structure ensure the integrity of the data and the efficiency of the information exchange. The X12 message structure has primary levels that are hierarchical. From highest to the lowest, this structure is the following:

• Interchange Envelope (Identified by ISA/IEA segment pairing)
• Functional Group (Identified by GS/GE segment pairing)
• Transaction Set (Identified by ST/SE segment pairing)

A schematic structure of X12 envelopes is shown in Figure 1 . Each of these levels is explained in more detail in the remainder of this section.

Interchange Control Envelopes (ISA/IEA)

The Interchange Envelope, often referred to as the “outer envelope,” is the wrapper for all the data to be sent in one transmission. It can contain multiple Functional Groups. This characteristic means that transactions of different types can be included in the Interchange Envelope, with each type of transaction stored in a separate Functional Group. The Interchange Envelope is defined by the header and trailer; the Interchange Control Header (designated ISA) appears at the beginning, and the Interchange Control Trailer (designated IEA) appears at the end. While the typical pattern from Enterprise Systems is to create one Functional Group (GS/GE) within an Interchange Group (ISA/IEA), the X12 enveloping supports one or more Functional Groups (GS/GE) within an Interchange Group (ISA/IEA). The ISA segment is the only segment that is fixed length record. This is done thus that EDI systems can derive the sender, receiver, element separators, sub-element separators, and segment terminators that will be used during EDI transformation. The ISA and IEA segments include:

• Data element separators and data segment terminator
• Identification of sender and receiver
• Control information (used to verify message was correctly received)
• Authorization and security information, if applicable

The sequence of information transmitted is:

1. ISA
2. Optional interchange-related control segments
3. Actual message information, grouped by transaction type into Functional Groups
4. IEA

ISA Segment

See Figure 2 for a diagram and following explanation of a definition for each element for this segment The following list describes the ISA segment elements shown in Figure 2

1. Authorization Information Qualifier
2. Authorization Information
3. Security Information Qualifier
4. Security Information
5. Interchange ID Qualifier
6. Interchange Sender ID
7. Interchange ID Qualifier
8. Interchange Receiver ID
9. Date the Envelope Was Created
10. Time the Envelope Was Created
11. Interchange Control Standard Identifier
12. Interchange Control Version Number
13. Interchange Control Number
14. Acknowledgment Requested
15. Usage Indicator
16. Sub Element Separator

IEA Segment

See Figure 3 for a diagram and following explanation of a definition for each element for this segment The following list describes the IEA segment elements shown in Figure 3

1. Number of Included Functional Groups
2. Interchange Control Number

Please note that the values in the ISA.11 and IEA.02 must match. Well formed Interchange envelopes that meets standards require this. If these values do not match, there is a high possibility of the following:

• Incomplete EDI file – Not all segments and envelopes created or delivered to recipient
• EDI Standards – The EDI system does not do control checks on these values to validate syntax relaxing validations required of an EDI System

Functional Groups Envelopes (GS/GE)

Functional Groups, often referred to as the “inner envelope,” are made up of one or more Transaction Sets. One Functional Group Envelope must include transaction of all of the same type, which can be batched together into one transmission. The Functional Group is defined by the header and trailer segments. The Functional Group Header (designated GS) segment appears at the beginning, and the Functional Group Trailer (designated GE) segment appears at the end. Many Transaction Sets of the same type can be included in the Functional Group. Within the Functional Group, each Transaction Set is assigned a functional identifier code, which is the first data element of the header segment. The Transaction Sets that constitute a specific Functional Group are identified by this functional ID code.

GS Segment

See Figure 4 for a diagram and following explanation of a definition for each element for this segment. The following list describes the GS segment elements shown in Figure 4

1. Functional ID Code (2 character transaction code..e.g. PO = Purchase Order, IN=Invoice, etc..)
2. Sender ID Code
3. Receiver ID Code
4. Date the GS Envelope Was Created
5. Time the GS Envelope Was Created
6. Functional Group Control Number
7. Responsibility Agency Code, X is the qualifier for X12
8. Version Release Identifier Code Is the EDI version “005010X222A1” positions 1-6 005010represent the ASC X 12 Procedures Review Board publications. Positions 7-13 are used to represent industry and trade association identifiers (e.g. VICS, UCS, WINS, etc..)

GE Segment

See Figure 5 for a diagram and following explanation of a definition for each element for this segment The following list describes the GE segments shown in Figure 5

1. Number of Transaction Sets Included (e.g. ST/SE combinations)
2. Functional Group control number (originated and maintained by the sender)

Please note that the values in the GS.06 and GE.02 must match to pass proper EDI X12 validation

Transaction Set Envelopes (ST/SE)

Each Transaction Set also known as a transaction contains:

• Transaction Set header (designated ST)
• Transaction Set trailer (designated SE)
• Single message, enveloped within the header and footer

A Transaction Set has a three-digit code, a text title, and a two-letter code, for example, 850, Purchase Order (PO). The Transaction Set is composed of logically related data grouped into units called segments. For example, one segment used in the Transaction Set might convey the address: city, state, postal code, and other geographical information. A Transaction Set will contain multiple segments. For example, the address segment might be used repeatedly to convey multiple sets of address information. The X12 standard defines the sequence of segments in the Transaction Set and also the sequence of elements within each segment. The relationship between segments and elements can be compared to the relationship between records and fields in a database environment. See Figure 6 and Figure 7.

ST Segment

See Figure 6 for a diagram and following explanation of a definition for each element for this segment. The following list describes the ST segments shown in Figure 6

1. Transaction Set Identifier Code (3 character code to represent transaction type e.g 850 = Purchase Order, 810 = Invoice, etc..)
2. Transaction Set Control Number

SE Segment

See Figure 7 for a diagram and following explanation of a definition for each element for this segment The following list describes the SE segments shown in Figure 7

1. Number of Included Segments in the transaction (includes ST and SE segments)
2. Transaction Set Control Number

Please note that the values in the ST.02 and SE.02 must match to pass proper EDI X12 validation

X12 EDI Envelope Control Number Validation

To put this all together, please refer to the following:

Elements of X12 Envelopes

The X12 messages are all in ASCII text, with the single exception that the BIN segment is binary. Each X12 message is made up of a combination of the following elements:

• Data
• Segments
• Loops

Elements are separated by delimiters. The remainder of this section explains these elements.

Data

The data element is the smallest named unit of information in the X12 standard. Data elements can be broken down into types. The distinction between the types is strictly a matter of how they are used. The types are:

• Simple– If a data element occurs in a segment outside the defined boundaries of a composite data structure, it is called a simple data element.
• Composite– If a data element occurs as an ordinally positioned member of a composite data structure, it is called a composite data element. A telephone number is a simple example of a composite. It has a three-digit area code, which must precede the three-digit central office code, which must precede the final four digits.

Each data element has a unique reference number, and it also has a name, description, data type, and minimum and maximum length.

Segments

A segment is a logical grouping of data elements. In X12, the same segment can be used for different purposes. This means that a field’s meaning can change based on the segment. For example:

• The NM1 segment is for any name (patient, provider, organization, doctor)
• The DTP segment is for any date (date of birth, discharge date, coverage period)

Loops Loops are sets of repeating ordered segments. In X12 you can locate elements by specifying:

• Transaction Set, for example 270 or 271
• Loop, for example “info. receiver loop”
• Occurrence of the loop
• Segment, for example BGN
• Field number, for example 01
• Occurrence of the segment (if it is a repeating segment)

Delimiters

In an X12 message, the various delimiters are part of the syntax, dividing up the different elements of a message. The delimiters used in a message are defined in the interchange control header, the outermost layer enveloping the message. For this reason, there is flexibility in the delimiters that are used. No suggested delimiters are recommended as part of the X12 standards, but the industry-specific implementation guides do have recommended delimiters. TSegment terminator ~ (tilde) Data element separator * (asterisk) Subelement (component) separator : (colon) Repetition separator (version 4020 and later) + (plus sign) Within exchange, delimiters are specified at the enveloping level. The delimiters defined for an envelope apply to all transactions in the same business service (a predefined dialog between the two parties). Note – It is important to note that errors could result if the transmitted data includes any of the characters that have been defined as delimiters. Specifically, the existence of asterisks within transmitted application data is a known issue in X12 and can cause problems with translation.