X12 Technical Tutorial - Syntax and Control

1 Introduction and Overall Structure

The essence of X12 is defined in X12.5 and X12.6. These standards provide the syntax and control structures which allow data elements, segments, and transaction sets to be defined. For those with a background in computer science, the basic X12 grammar qualifies as a context free grammar. It is specified in X12.5 and X12.6 using Backus-Naur Form (BNF) notation.

The overall structure of X12 data is shown below.

2 Terminology and Basic Concepts

In this tutorial, only the basic concepts of the X12 syntax are addressed. The X12.58 security standards are relevant to X12.5 and X12.6 as discussed here, but are not included in the discussion.

2.1 Simple Data Element

Data elements are defined in the X12 Data Element Dictionary - X12.3. A data element is equivalent to a field in a data dictionary. Data elements have a name, a data element number, a brief description, a data type, and a minimum and maximum length. For elements which represent codes, either a list of valid codes is included or a reference is included to a source outside of the X12 standard.

Data Types

Data elements may have the following types:

• N - Numeric with implied decimal point, signed. Example: N2 indicates a numeric with two decimal places. 12.34 becomes 1234. N0 indicates in integer.
• R - Decimal Number with explicit decimal point, signed. Example: 12.34 represented in R format is 12.34. Starting with 4010, exponential notation is also supported.
• ID - Identifier - A coded value, usually alphanumeric.
• AN - String - alphanumeric.
• DT - Date - YYMMDD. As of 4010, CCYYMMDD is also supported.
• TM - Time - HHMM, with optional seconds and hundredths.
• B - Binary - Any sequence of 8 bit bytes.

2.2 Composite Data Structure

A composite data structure consists of two or more simple data elements separated by a delimiter character known as the component data element separator. The individual component data elements in the composite may be designated as either mandatory or optional.

2.3 Segment

Segments are defined in the X12 Segment Directory - X12.22. A segment is equivalent to a record type. A segment is composed of one or more data elements or composite data structures, which are equivalent to the fields in a record. Segments start with a two or three character segment tag which identifies the segment, equivalent to a record type field. Data elements are separated by a delimiter character known as an element separator, and end with a different delimiter character known as the segment terminator.

Elements which are not assigned values in a particular instance of a segment are represented by consecutive delimiters, and such trailing delimiters are not transmitted. For example, if a segment XYX has five elements and in a particular transmission only the second has a value, it is represented as XYZ**123<CR>, where "*" is the element separator and <CR> is the segment terminator.

2.3.1 Elements

The elements in a segment may be assigned the following attributes:

• Requirements - Mandatory, Optional, or Conditional
• If Conditional - Two or more elements together may have the following conditional attributes:
  • P - Paired or multiple. If any are used, all must be used
  • R - Required. At least one of those noted must be used
  • E - Exclusion. No more than one may be used
  • C - Conditional. If the first element is present, then the others must be present
  • L - List Conditional. If the first element is present, then at least one of the others must be present

Example: In the N1 Name segment, the first element, N1_01, data element number 98 (Entity Identifier Code), is mandatory. Elements three and four ( 66 Identification Code Qualifier and 67 Identification Code) have a Semantic Note indicating a Conditional Relationship of P0304. If one is present, then both must be present.

2.3.2 Semantic Notes

Segments may have Semantic Notes indicating the meaning to be applied to data elements, beyond just their name and description. For example: In the N9 Reference Number Segment, a Semantic Note indicates that the sixth element, 623 Time Code, indicates the time zone of the fifth element, 337 Time.

2.4 Transaction Set

A Transaction Set is a group of one or more data segments conveyed between trading partners. It usually represents a business document such as a Purchase Order, but any unit of information meaningful to both parties is sufficient. Transaction Sets are defined in the X12 standard with a number and name, a statement of purpose, a Functional Group ID, and a table listing the included segments, their position numbers, requirement designation, maximum usage, and loop repeat counts. Transaction Sets start with an ST Transaction Set Header segment and end with an SE Transaction Set Trailer segment.

A specific segment may occur in several positions within a transaction set, representing different information in each different position. For example, an N3 segment in the previous example regarding the 837 Health Care Claim applies to the Subscriber's street address in the first NM1 loop, but would represent the provider's address in the 2310 NM1 loop. Transaction Sets are structured such that, in any given data stream containing a Transaction Set, a segment's position in the defined standard for the Transaction Set may be determined solely by the segment tag (except when LS/LE loops are used). In other words, the segments defined position in regard to the standard is determined by considering the segments that appeared before it in the data stream.

2.4.1 Segment Attributes

The Transaction Set definition includes attributes which apply to segments in a Transaction Set. These are:

• Position
• Requirement - Mandatory or Optional (and in earlier version of X12, Floating)
• Maximum Occurrences - If more than 1, then the segment may be repeated at that position in the Transaction Set up through the maxim usage indicated.

2.4.2 Loops

A loop is a set of related segments in a Transaction Set. Segments are grouped together in this way to conveniently represent a block of related information. No formal Loops are defined, but several basic loop types, such as a Name/Address loop, appear with minor variations in many Transaction Sets. Different loops may be nested within each other, and loops may repeat up to the maximum loop occurrences specified within the Transaction Set. X12 defines two types of loop formats: Unbounded and Bounded.

2.4.2.1 Unbounded

An Unbounded loop starts with a specific segment, and all of the other segments in the loop may be considered children of that segment. The start segment may appear once and only once in the loop, and each new occurrence of the starting segment starts a new loop. A loop has a requirement designation of optional or mandatory (corresponding to the requirement designator of the first segment in the loop), and a repeat count indicating the maximum number of times it may repeat. If any of the segments in the loop are used, the starting segment must be used even if the loop itself is optional. An example of an unbounded loop is the N1/N2/N3/N4 Name and Address loop. It starts with the N1 Name segment, and includes the N2 Additional Name, N3 Address, and N4 Geographic Location segments.

2.4.2.2 Bounded (LS/LE)

A bounded loop has the same characteristics as an unbounded loop, except it is bracketed by LS Start Loop and LE End Loop segments. Any of the segments in the loop may be the first in a specific instance of the loop, depending on requirement designation of the loop. Bounded loops are used to identify loops that otherwise would be indistinguishable from each other. If the loop does not appear in a particular transmission, the LS and LE segments should not appear.

An example of a bounded loop appears in the 837 Health Care Claim ( Version 3040 in this example ). At Position 2110, we start an NM1 loop identifying the subscriber. Within this NM1 loop, we have several other NM1 loops identifying other entities related to this subscriber. Such as, at 2310 there is an NM1 loop describing the Health Care provider. This 2310 loop is bounded by an LS/LE structure. Without the LS/LE, it would appear that we are starting a new NM1 loop at 2110 for the Subscriber. This section of the 837 appears below:

NM1* subscriber info...
...
    LS*2310
    NM1* Provider info ...
    ...
    LE*2310
...
NM1* Next subscriber loop

2.6 Functional Group

A Functional Group is a group of one or more related Transaction Sets sharing the same Functional Group ID. Functional Groups start with a GS Functional Group Header segment and end with a GE Functional Group Trailer segment. The details in the Functional Group GS/GE envelope are often used to route the group's transaction sets to the appropriate department or business application within a company.

2.7 Interchange

An Interchange is the lowest unit of data exchanged between trading partners. It consists of one or more Functional Groups enclosed in an envelope defined by an ISA Interchange Control Header segment and ending with an IEA Interchange Control Trailer segment. The details in the ISA segment are often used to route the Interchange between trading partners in an EDI Value Added Network, or VAN.

3 Envelope Details

Listed here are brief descriptions of the control segments for the interchange, group, and transaction set envelopes. For full explanation of these segments, their purposes, and their data elements, refer to X12.5 Interchange Control Structures, X12.6 Application Control Structure, X12.22 Segment Directory, and X12.3 Data Element Dictionary.

3.1 Interchange Envelope - ISA/IEA

ISA - Interchange Control Header

The ISA is effectively fixed length, since all of the elements are fixed length. This results in the segment terminator always being in position 106. The element separator can be obtained from position 4, and the subelement separator from 105. These delimiters allow the remainder of the interchange to be parsed.

• ISA01 - Authorization Information Qualifier
• ISA02 - Authorization Information
• ISA03 - Security Information Qualifier
• ISA04 - Security Information - This was originally used as a kind of a password. The receiver ID might be public information such as a DUNS number, but this field might contain a value which is not public information. It is however clear text, so the security provided is not at a very high level.
• ISA05 - Interchange ID Qualifier
• ISA06 - Interchange Sender ID - Identifies the sender.
• ISA07 - Interchange ID Qualifier
• ISA08 - Interchange Receiver ID - Identifies the receiver.
• ISA09 - Interchange Date - YYMMDD
• ISA10 - Interchange Time - HHMM
• ISA11 - Interchange Control Standards Identifier
• ISA12 - Interchange Control Version Number - Indicates the version of the ISA/IEA envelope
• ISA13 - Interchange Control Number - Uniquely identifies an interchange for tracking by trading partners and VANS, and can be used to detect duplicate, missing, or out of sequence transmissions. May take any numeric value, but is usually incremented by one for each interchange sent to the same trading partner.
• ISA14 - Acknowledgment Requested - Indicates a request for a TA3 Interchange Acknowledgment to be sent.
• ISA15 - Test Indicator - Test or Production
• ISA16 - Subelement Separator

IEA - Interchange Control Trailer

• IEA01 - Number of Included Functional Groups - This is used for message integrity, developed before such things as check sums were widely implemented.
• IEA02 - Interchange Control Number - Must match the control number in the IEA.

3.2 Group Envelope - GS/GE

The Group Envelope, as noted above, may be used for internal routing. The X12 Version/Release is specified in the GS, so all of the Transaction Sets in the group must be of the same version/release.

GS - Functional Group Header

• GS01 - Functional Group Header Code - Same as the Group Type of the included Transaction Sets.
• GS02 - Application Sender's Code
• GS03 - Application Receiver's Code
• GS04 - Date - YYMMDD, or CCYYMMDD as of 4010.
• GS05 - Time - HHMM
• GS06 - Group Control Number - Like the ISA control number, is used for audit and to detect duplicates, missing, or out of sequence groups. Most importantly, the 997 Functional Acknowledgment, which acts as a return receipt for the group, references the group control number. May take any numeric value so long as there are no duplicates in the interchange, but is usually incremented by one for each group of this type sent to the same trading partner.
• GS07 - Responsible Agency Code - X for X12 or T for TDCC
• GS08 - Version/Release/Industry Identifier Code - The first six characters specify the X12 version and release, while any of the last six may be used to indicate an Industry standard or Implementation Convention reference.

GE - Functional Group Trailer

• GE01 - Number of included Transaction Sets - This is used for message integrity, developed before such things as check sums were widely implemented.
• GE02 - Group Control Number - Must match the group control number of the GS

3.3 Transaction Set Envelope - ST/SE

ST - Transaction Set Header

• ST01 - Transaction Set Identifier Code - A three digit numeric code identifying the Transaction Set type, from the Transaction Set table.
• ST02 - Transaction Set Control Number - May take any alphanumeric value so long as there are no duplicates in the functional group. Usually starts with 0001 in each group, but there are several other numbering schemes in common usage. Is referenced in the 997 Functional Acknowledgment if individual transaction sets are positively acknowledged or if there are errors in the transaction set indicating a rejection.

SE - Transaction Set Trailer

• SE01 - Number of included segments - This is used for message integrity, developed before such things as check sums were widely implemented.
• SE02 - Transaction Set Control Number - Must match the Transaction Set Control Number in the ST.

4 Example Interchange

This example has one transaction set, in one functional group, in one interchange. An asterisk "*" is used for the element separator. A carriage return "^M" is used for the segment terminator. Each segment is listed on a separate line for readability, but in reality the data appears as a single stream with the segments separated only by the <CR>. There are four N1 Name/Address loops.  Please note that the ISA segment is wrapped over two lines to enable easier reading.

ISA*00*          *00*          *01*0011223456   *01*999999999*
     950120*0147*U*00300*000000005*0*P*~<CR>
GS*PO*0011223456*999999999*950120*0147*5*X*003040<CR>
ST*850*000000001<CR>
BEG*00*SA*95018017***950118<CR>
N1*SE*UNIVERSAL WIDGETS<CR>
N3*375 PLYMOUTH PARK*SUITE 205<CR>
N4*IRVING*TX*75061<CR>
N1*ST*JIT MANUFACTURING<CR>
N3*BUILDING 3B*2001 ENTERPRISE PARK<CR>
N4*JUAREZ*CH**MEX<CR>
N1*AK*JIT MANUFACTURING<CR>
N3*400 INDUSTRIAL PARKWAY<CR>
N4*INDUSTRIAL AIRPORT*KS*66030<CR>
N1*BT*JIT MANUFACTURING<CR>
N2*ACCOUNTS  PAYABLE DEPARTMENT<CR>
N3*400 INDUSTRIAL PARKWAY<CR>
N4*INDUSTRIAL AIRPORT*KS*66030<CR>
PO1*001*4*EA*330*TE*IN*525*VN*X357-W2<CR>
PID*F****HIGH PERFORMANCE WIDGET<CR>
SCH*4*EA****002*950322<CR>
CTT*1*1<CR>
SE*20*000000001<CR>
GE*1*5<CR>
IEA*1*000000005<CR>

About  |  Services  |  Resources  |  Contact

©Rawlins EC Consulting 2007