 | JANUARY 2023 Copyright © 1988-2023, X12, Format © 1988-2023 Washington Publishing Company. Exclusively published by the Washington Publishing Company. No part of this publication may be distributed, posted, reproduced, stored in a retrieval system, or transmitted in any form or by any means without the prior written permission of the copyright owner. All rights reserved. Intellectual Property
X12 holds the copyright on the Standards and associated publications designed to facilitate implementation of the Standards. Users of all X12 publications should be aware of the permissible uses, as well as the limitations on such usage, as outlined here: x12.org/products/ip-use. |
1.1. Referenced and Related Standards
This standard is used with the X12 series of standards on electronic data interchange.
The following material is from The Internet Engineering Task Force (IETF®). The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.
The following verbatim text is from the cited document as noted immediately below.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. -
MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. -
MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. -
SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. -
SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED", mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. -
MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) |
These Design Rules and Guidelines are to assist the developers of X12-syntax-based EDI transaction sets to achieve consistent and technically appropriate transaction sets that meet the needs of the user community. The Design Rules shall be adhered to during the development process without any deviation. The Design Guidelines (Section 3) provide a framework in the development process that should be followed.
Developers of all new X12-syntax-based standards are expected to use these Design Rules and Guidelines. The adoption of these rules and guidelines is not intended to require a review and change for the purpose of retrofit of approved X12 Standards. However, subcommittees are encouraged to update existing standards to bring them into compliance during the maintenance process.
This document is intended to be flexible to meet new requirements. Modifications and suggestions for improvement of this guideline are welcome and should be sent to Task Group 1 of Subcommittee J, Technical Assessment, care of:
Accredited Standards Committee X12
info@ascx12.org
It is of prime importance to set forth a clear statement of the business problem to be addressed by a proposed transaction set. A reasonable number of different viewpoints should be sought to ensure that the solution is developed for application to a broad base of potential users. Developers are encouraged to examine the applicability of a transaction set in more than one industry. This analysis needs to consider related EDI transaction sets and other business technologies, so that the resulting transaction set will integrate smoothly into the business environment. The role of EDI in these business processes is to provide electronic commerce, which promotes the synchronization of the databases between the trading partners with the minimum amount of actual data transfer between the involved applications.
It is important to consider alternative, creative business process solutions that make efficient use of the business resources rather than engaging in a strict electronic codification of current business practices. This progression toward improved business processes, as well as the incorporation of best business practices, will contribute significantly to the value of the resulting transaction set.
In order to achieve this process solution, the developer needs to articulate the business case that demonstrates the need and value for the proposed transaction set. This valid business case is used in preparing the work request and project proposal for the transaction set's development cycle.
From the business case flows the business scenario. This scenario describes the transaction set and the business environment within which the transaction set will operate. The scenario exposition may include diagrams of the business process as well as verbal descriptions of how the transaction set is intended to be used.
At the conclusion of the initial design effort, the developing subcommittee shall include implementation guidance in the form of at least one example. These examples are also very beneficial in explaining the transaction to the X12 voter and to other standards developers and implementers.
2.1.1
All transaction sets shall conform to the design syntax approved by X12.6 Application Control Structure.
2.1.2
All transaction sets, segments, and data elements shall be clearly explained. Each transaction set shall have a purpose and scope; each segment shall have a purpose; each data element shall have a description; and each code value shall have a definition. Acronyms and abbreviations shall be used only if they themselves are defined.
2.1.3
Existing standards, i.e., transaction sets, segments, data elements, and code lists shall be evaluated and, where possible, used to meet a business function. If, in the opinion of the sponsoring subcommittee, it is neither possible nor desirable to modify an existing standard, then the subcommittee is obligated to address the business need by developing a new standard.
2.1.4
A business case clearly stating the business requirements shall be prepared in support of new transaction sets. The business case shall consist of a textual description and may be accompanied by diagrams that demonstrate the need and value of the request.
2.1.5
One or more business scenarios based upon the business case shall describe the use of the transaction set in specific business conditions and environments. The business scenario need not be inclusive of all business conditions. Text, or diagrams, or both are acceptable.
2.1.6
An example supporting a specific business condition of the transaction set shall be provided. The example shall consist of a complete transaction set with syntactically correct segments composed of data elements. The example shall include a translation of the data for human understanding. Not all loops, segments, or elements need be used, but a fair representation of detail supporting the business condition shall be included.
2.2.1
The transaction set purpose and scope shall include typical applications, what business function it supports, what data would be typically conveyed, and how it is different from similar transaction sets already developed (if any).
2.2.2
Any expansion of the transaction set scope shall be within the business function stated in the purpose, or the purpose shall be expanded to accommodate the new scope.
2.2.3
All segments added to a transaction set shall be within the scope of the transaction set, or the scope of the set shall be expanded to accommodate the new segments.
2.2.4
A transaction set shall be made up of the mandatory ST and SE control segments and at least one segment between ST and SE.
2.2.5
If multiple areas (e.g., heading, detail, and summary in the Purchase Order) are used, a positive means to mark the transition from one area to another shall be provided. It is preferable that the sequence and requirement designators for the segments provide the method for establishing the change between areas. If this cannot be accomplished, a separate "begin area segment" may be used.
2.2.6
Each segment in a transaction set sequence shall be assigned a requirement designator of either mandatory or optional. There shall be no segments designated as floating or conditional.
2.2.7
Maximum use designations for segments shall be set at a specific number of iterations to meet a demonstrated business need. If a specific number of iterations cannot be determined or is unknown then 'more than one' (>1) shall be used.
Note:
If the "more than one" number of iterations is used, the ability to do syntactical edits based on these counts is negated.
2.2.8
Hash Total, Data Element 347 in CTT02, is discouraged from use. If a hash total is called for in a transaction set, the data element and its specific location within the transaction set used to calculate the hash total shall be specified in the transaction set standard. The data element(s) being hashed shall be R-type data elements.
2.2.9
Transaction sets shall only include segments that accommodate the specific need of the transaction set. Segments shall not be included for the sole reason that they appear in other similar or related transaction sets.
2.2.10
If a segment, except LS or LE, is used more than once in a transaction set, there are several ways to show their separation. This can be accomplished by the following techniques.
| 5 |
| N1 | Name | O | 1 | | |
| N2 | Additional Name Information | O | 2 | | |
| N3 | Address Information | O | 2 | | |
|
|
| 10000 |
| PTD | Product Transfer and Resale Detail | M | 1 | | |
| 5 | |
| N1 | Name | O | 1 | | |
| N2 | Additional Name Information | O | 2 | | |
| N3 | Address Information | O | 2 | | |
Example 2.1. Segment PTD, which begins a loop, separates the two N1 loops.
| PER | Administrative Communications Contact | O | 3 | | |
|
|
| 10000 |
| PTD | Product Transfer and Resale Detail | M | 1 | | |
| 5 | |
| REF | Reference Information | O | 12 | | |
| PER | Administrative Communications Contact | O | 3 | | |
Example 2.2. Segment PTD, which begins a loop, separates the two PER segments.
Note that none of these examples has a segment whose requirement designator is mandatory. The "mandatory" segment that separates the occurrences of the same segment is the segment that begins the loop, since the use of any segment within a loop requires that the beginning segment also be used. In most loops, this is only the trigger segment, but in bounded loops, the LS and LE must also occur.
| 200 |
| N1 | Name | O | 1 | | |
| N2 | Additional Name Information | O | 2 | | |
| N3 | Address Information | O | 2 | | |
|
|
| LS | Loop Header | M | 1 | | |
| 200 |
| N1 | Name | O | 1 | | |
| N2 | Additional Name Information | O | 2 | | |
| N3 | Address Information | O | 2 | | |
|
|
| LE | Loop Trailer | M | 1 | | |
Example 2.3. The loop, bounded by LS/LE separated the two N1 segments.
Another possibility for an intervening mandatory segment is an explicit mandatory segment positioned between the two occurrences as shown.
| 200 |
| N1 | Name | O | 1 | | |
| N2 | Additional Name Information | O | 2 | | |
| N3 | Address Information | O | 2 | | |
|
|
| PTD | Product Transfer and Resale Detail | M | 14 | | |
| 200 |
| N1 | Name | O | 1 | | |
| N2 | Additional Name Information | O | 2 | | |
| N3 | Address Information | O | 2 | | |
|
|
Example 2.4. The mandatory PTD segment separates the two N1 loops.
| REF | Reference Information | O | 12 | | |
| PER | Administrative Communications Contact | O | 3 | | |
| PTD | Product Transfer and Resale Detail | M | 14 | | |
| REF | Reference Information | O | 12 | | |
| PER | Administrative Communications Contact | O | 3 | | |
Example 2.5. The mandatory PTD segment separates the two sets of REF and PER segments.
The last intervening "mandatory" segment would be the LE, the end of a bounded loop.
| LS | Loop Header | O | 1 | | |
| 200 |
| N1 | Name | O | 1 | | |
| N2 | Additional Name Information | O | 2 | | |
| N3 | Address Information | O | 2 | | |
|
|
| LE | Loop Trailer | O | 1 | | |
| N1 | Name | O | 5 | | |
Example 2.6. The LE segment separates the two N1 segments.
However, the mere presence of a segment with a requirement designator of mandatory that is positioned sequentially between the two occurrences of the same segment does not guarantee that it meets the criteria of a mandatory segment that separates the two.
| 200 |
| N1 | Name | O | 1 | | |
| N3 | Address Information | O | 2 | | |
| N4 | Geograhic Location | M | 1 | | |
|
|
| PTD | Product Transfer and Resale Detail | O | 14 | | |
| 200 |
| N1 | Name | O | 1 | | |
| N2 | Additional Name Information | O | 2 | | |
| N3 | Address Information | O | 2 | | |
|
|
Example 2.7. The mandatory N4 segment does NOT separate the two N1 segments because the first N1 loop is optional and the N4 may not be encountered.
2.2.11
Use the BDS segment when creating a new transaction set that carries binary data, or when modifying an existing transaction set to add the capability to carry binary data.
2.3.1
Conditionality among segments shall be identified by a loop structure. If a segment cannot be used unless a prior segment has been used, then these segments shall be identified in their own loop. Segments in a loop are subordinate only to the first segment in the loop.
2.3.2
Two or more different loops shall not begin on the same segment at the same ordinal position in a transaction set.
2.3.3
A segment that begins any loop or nested loop structure shall be unique to, and not recur anywhere within, that and any subordinate loop structure within the same looping structure, unless LS/LE segments bound the subordinate loop.
2.3.4
Loops shall only include segments that accommodate the specific need of the loop. Segments shall not be included for the sole reason that they appear in other loops.
2.3.5
Loop repeat counts shall be set at a specific number of iterations or "more than one."
Note:
If the "more than one" number of iterations is used, the ability to do syntactical edits based on these counts is negated.
2.3.6
Since the first segment of a loop is always mandatory if the loop is used, the requirement designator of the first segment specifies the usage of the loop. If one or more than one iteration of a loop is required, the first segment of the loop shall be assigned a requirement designator of mandatory. If no iterations of a loop are required, the first segment of the loop shall be assigned a requirement designator of optional.
2.3.7
In addition to the first segment in a loop, mandatory segments within an optional loop are permissible. They are mandatory only upon the use of the loop and shall be identified with a requirement designator of (M).
2.3.8
Within any logical area, loop, or nested loop, all standalone segments belonging to the parent structure (i.e., logical area, loop, or nested loop) shall appear in the sequence ahead of any subordinate or nested loop with the exception of trailer segments required to close the transaction, logical area, loop or nested loop. Loops at the same nesting level should be contiguous at the end of the parent structure. (See Example 2.8, "Standalone segments appear in sequence ahead of subordinate loops.".)
2.3.9
The Hierarchical Level (HL) shall be used to generically define hierarchical (for example, "tree" or parent-child) looping structures.
2.3.10
The Hierarchical Level (HL) segment shall be used only to start a loop. It shall not be used outside a loop as an individual segment.
2.4.1
Each segment shall have a stated purpose, which should be sufficiently generic as to encourage the segment's use in other transaction sets. All data elements in the segment shall contribute to that purpose.
2.4.2
Elements within a segment shall be assigned a condition designator of mandatory, optional, or relational.
2.4.3
If a relational condition designator is used, its basis must be specified in syntax notes.
2.4.4
When designing new segments, where a data element is qualified by another data element in the segment, the qualifier shall precede the data element, which is being qualified.
Note:
In the event that a qualifier is not mandatory and this rule is in conflict with Rule 2.4.5 (below), then Rule 2.4.5 takes precedence.
2.4.5
When designing new segments, data elements designated, as mandatory shall be arranged in the first positions in the segment.
2.4.6
New data elements shall be either added at the end of an existing segment or incorporated into a new segment.
2.4.7
All data elements added to a segment shall be within the purpose of the segment or the purpose shall be expanded to accommodate the new data elements.
2.4.8
A data element defined as a Qualifier shall be linked to one or more data elements in the same segment. A qualifier data element shall not be included in the segment construction when the value of the qualifier, if used, would be a constant. The definition of the value shall be placed in a semantic note.
2.4.9
When specifying date (data element type DT), data element #373 (Date) shall be used and when specifying time (data element type TM), data element #337 (Time) shall be used. If a date or time qualifier is required, data element #374 (Date/Time Qualifier) shall be used.
2.4.10
Data elements shall not be used in a segment to contain the results of a calculation if all the data elements necessary to perform the calculation are present in the segment. The receiver's computer can make the calculation.
2.4.11
The semantic note designator shall be associated with the data element or composite data element that it defines.
2.4.12
A relationship defined by a semantic note shall be among data elements or composite data elements within the same segment.
2.4.13
Semantic notes shall not contradict data elements, composite data elements, or segment definitions.
| Table 1 |
| 0100 | ST | Transaction Set Header | M | 1 | |
| 0200 | BGN | Beginning Segment | M | 1 | |
| 0300 | BLR | Transportation Carrier Identification | M | 1 | |
| 0400 | G62 | Date/Time | O | 10 | |
| 10 |
| 0500 | N1 | Party Identification | M | 1 | |
| 0600 | N2 | Additional Name Information | O | 1 | |
| 0700 | N3 | Party Location | O | 2 | |
| 0800 | N4 | Geographic Location | O | 1 | |
| 0900 | PER | Administrative Communications Contact | O | 5 | |
|
|
| 99999 |
| 1000 | CA1 | Rate Request Identifier | M | 1 | |
| 1100 | LC1 | Lane Commitments | M | 1 | |
|
|
| 1200 | SE | Transaction Set Trailer | M | 1 | |
Example 2.8 - 108 Response to a Motor Carrier Rate Proposal - Illustrates standalone segments appearing ahead of other loops
| Table 1 |
| N | 0100 | ST | Transaction Set Header | M | 1 | | |
| N | 0200 | AK1 | Functional Group Response Header | M | 1 | | |
| >1 |
| N | 0300 | AK2 | Transaction Set Response Header | O | 1 | | |
| >1 | |
| C | 0400 | AK3 | Data Segment Note | O | 1 | | |
| 0500 | AK4 | Data Element Note | O | 99 | | |
| |
| |
| 0600 | AK5 | Transaction Set Response Trailer | M | 1 | | |
|
|
| 0700 | AK9 | Functional Group Response Trailer | M | 1 | | |
| 0800 | SE | Transaction Set Trailer | M | 1 | | |
Example 2.9 - 997 Functional Acknowledgment – Illustrates the exception for standalone trailer segments (AK5 and AK9)
2.4.14 Relational Conditions
Relational conditions may exist among two or more data elements within the same data segment, or among two or more component data elements within the same composite data structure, based on the presence or absence of one of those data elements. Relational conditions are specified by a condition code and the identity of the subject elements or structures. Relational conditions may not exist between a component data element and anything outside its parent composite data structure.
Note:
The purpose of this rule is to amplify and clarify the Backus-Naur Form relational conditions expressed in X12.6. Should any conflict in interpretation arise between this rule and X12.6, X12.6 shall prevail.
A data element may be subject to more than one relational condition.
Five such relational conditions exist within X12 syntax. To assist developers in understanding and using relational conditions, the following definitions and examples are provided:
2.4.14.1 Syntax Code "P" (Paired or Multiple)
Definition: If any data element specified in the relational condition is present, then all data elements specified must be present.
As shown in Example 2.10, if the PDP segment contains either DE 23 (PDP02) or DE 22 (PDP03), then the other is required. The Paired conditional relationship is expressed as shown in Example 2.10 as P0203.
| 01 | 1188 | Type of Personal or Business Asset Code | 1 | M | ID | 2/2 |
| 02 | 23 | Commodity Code Qualifier | 1 | X | ID | 1/2 |
| 03 | 22 | Commodity Code | 1 | X | AN | 1/30 |
Example 2.10. PDP Product Description - Personal
Multiple paired relationships are also possible. As shown in Example 2.11, if the SAL segment contains any one of DE 543 (SAL03) or DE 616 (SAL04) or DE 344 (SAL05), then all the others are required. The Paired Multiple relationship is expressed as shown in Example 2.11 as P030405.
| 01 | 1073 | Yes/No Condition or Response Code | 1 | M/Z | ID | 1/1 |
| 02 | 610 | Amount | 1 | O/Z | N2 | 1/15 |
| 03 | 543 | Labor Rate | 1 | X | N2 | 3/6 |
| 04 | 616 | Number of Periods | 1 | X | N0 | 1/3 |
| 05 | 344 | Unit of Time Period or Interval Code | 1 | X | ID | 2/2 |
| 06 | 373 | Date | 1 | O/Z | DT | 8/8 |
| 07 | 373 | Date | 1 | O/Z | DT | 8/8 |
Example 2.11. SAL Salary Information
2.4.14.2 Syntax Code "R" (Required)
Definition: At least one of the data elements specified in the relational condition must be present. It is permissible to use all.
As shown in Example 2.12, the CLI segment must contain at least one of DE 98 (CLI01) or DE 1196 (CLI02) or DE 350 (CLI03). It may contain all three or any combination, but must contain at least one. The Required conditional relationship is expressed as shown in Example 2.12 as R010203.
| 01 | 98 | Entity Identifier Code | 1 | X | ID | 2/3 |
| 02 | 1196 | Breakdown Structure Detail Code | 1 | X | ID | 2/2 |
| 03 | 350 | Assigned Identification | 1 | X/Z | AN | 1/20 |
| 04 | 369 | Free-form Description | 1 | O | AN | 1/45 |
| 05 | 562 | Rate or Value Type Code | 1 | O/Z | ID | 1/2 |
| 06 | 1166 | Contract Type Code | 1 | O | ID | 2/2 |
Example 2.12. CLI Cost Line Item
2.4.14.3 Syntax Code "C" (Conditional)
Definition: If the first data element specified in a relational condition is present, then all other data elements must be present. However, any or all of the data elements not specified as the first data element may appear without requiring that the first data element be present. The order of the data elements in the Conditional relationship does not have to be the same as the order of the data elements in the segment.
As shown in Example 2.13, if DE 623 (BLN06) is present, then DE 337 (BLN05) must be present. While DE 623 (BLN06) is the first element in the Conditional relationship, it is not the first element in order of appearance in the segment. The Conditional relationship is expressed as shown in Example 2.13 as C0605.
| 01 | 1270 | Code List Qualifier Code | 1 | M | ID | 1/3 |
| 02 | 1271 | Industry Code | 1 | M | AN | 1/30 |
| 03 | 782 | Monetary Amount | 1 | M/Z | R | 1/18 |
| 04 | 373 | Date | 1 | O | DT | 8/8 |
| 05 | 337 | Time | 1 | X | TM | 4/8 |
| 06 | 623 | Time Code | 1 | O | ID | 2/2 |
Example 2.13. BLN Balance Information
2.4.14.4 Syntax Code "L" (List Conditional)
Definition: If the first data element specified in the relational condition is present, then at least one of the remaining data elements must be present. However, any or all of the data elements not specified as the first data element may appear without requiring that the first data element be present. Like the Conditional relationship, the order of the data elements in the List Conditional relationship does not have to reflect the order of appearance in the segment.
As shown in Example 2.14, if DE 1303 (LUI04) is present, then at least one of DE 67 (LUI02) or DE 352 (LUI03) must be present. While DE 1303 (LUI04) is the first data element in the List Conditional relationship, it is not the first data element in order of appearance in the segment. The List Conditional relationship is expressed as shown in Example 2.14 as L040203.
| 01 | 66 | Identification Code Qualifier | 1 | X | ID | 1/2 |
| 02 | 67 | Identification Code | 1 | X/Z | AN | 2/80 |
| 03 | 352 | Description | 1 | X/Z | AN | 1/80 |
| 04 | 1303 | Use of Language Indicator Code | 1 | O | ID | 1/2 |
| 05 | 1476 | Language Proficiency Indicator Code | 1 | O | ID | 1/1 |
Example 2.14. LUI Language Use
2.4.14.5 Syntax Code "E" (Exclusion)
Definition: Only one of the data elements specified in the relational condition may be present. It is permissible that none of the data elements be present.
As shown in Example 2.15, only DE 301 (CIC03) or DE 1482 (CIC05) may be present, but not both. It is acceptable for neither to be present. The Exclusion relationship is expressed as shown in Example 2.15 as E0305.
| 01 | 206 | Equipment Initial | 1 | O | AN | 1/4 |
| 02 | 207 | Equipment Number | 1 | O | AN | 1/15 |
| 03 | 301 | Car Type Code | 1 | X | ID | 1/4 |
| 04 | 207 | Equipment Number | 1 | O/Z | AN | 1/15 |
| 05 | 1482 | Mechanical Car Code | 1 | X | ID | 4/4 |
Example 2.15. CIC Car Information Control
2.4.15
Repeating data elements shall only represent one-to-many or many-to-one relationships in which the "one" serves as the basis for the relationship. Multiple one to one relationships between and among repeating data elements or composite data structures are not allowed.
2.4.16
Segment names shall be unique throughout the X12.22 Segment Directory. Further, a segment name shall not duplicate a simple data element name or a composite data structure name appearing in the X12.3 Data Element Dictionary.
2.5.1
A data element description shall specify what information will be conveyed in the data element.
2.5.2
New data element descriptions shall be sufficiently generic as to encourage their use in other segments.
2.5.3
ID type data elements shall contain either the word "Qualifier," "Code," or both in the data element name.
2.5.4
ID type data element descriptions shall begin with the words "Code indicating," "Code identifying," or "Code specifying."
2.5.5
ID type data elements require either a Data Dictionary Appendix A reference to a source for externally developed code lists, or a code list shall be provided in X12.3 Data Element Dictionary.
2.5.6
If an individual qualifier value defines an external reference source, then an X12.3 Data Dictionary Appendix A reference is required.
2.5.7
ID type data elements may cite a code with the definition "mutually defined." The code shall be for interim use only, until a precise code is added to the approved code list. The code assigned shall be "Z" and shall be "Z" filled to the minimum length of the data element.
2.5.8
All new code definitions added to a data element code list shall be consistent with the description of the data element, or the data element description shall be expanded to accommodate the new code definition.
2.5.9
Codes developed for code lists shall be defined. This definition shall not include instructions on its usage.
2.5.10
Data element minimum and maximum lengths shall serve a demonstrated business need of practical dimensions.
2.5.11
When specifying reference numbers, data element #127 (Reference Identification) shall be used. If a reference number qualifier is required, data element #128 (Reference Identification Qualifier) shall be used. If data element #127 (Reference Identification) is used by itself, then a semantic note on its use shall be specified for the segment in which the data element appears.
2.5.12
Code values assigned by X12 shall have no meaning and shall contain only uppercase A to Z letters and 0 to 9 numerals.
2.5.13
No codes in code lists shall be less than the minimum length or greater than the maximum length attributed to the data element.
2.5.14
A composite data element shall not be qualified, nor shall it be a qualifier of another data element or composite.
2.5.15
Composite data elements shall meet all of the relevant rules within this Section.
2.5.16
Simple data element names shall be unique throughout the X12.3 Data Element Dictionary. Further, a simple data element name shall not duplicate a composite data structure name appearing in the X12.3 Data Element Dictionary or a segment name appearing in the X12.22 Segment Directory.
2.6.1
Each composite data structure shall have a stated purpose and definition, which should be sufficiently generic as to encourage the composite data structure's use in other segments. All component data elements of the composite data structure shall contribute to that purpose. All component data elements added to the composite data structure shall be within the purpose and definition, or the purpose or definition shall be expanded to accommodate the new data elements.
2.6.2
Component data elements within the composite data structure shall be assigned a condition designator of mandatory, optional, or relational. If the relational condition designator is used, then its basis must be specified in syntax note.
2.6.3
The composite data structure shall be constructed using the following precedence:
-
Component data elements designated as mandatory shall be arranged in the first positions of the composite data structure.
-
Where one component data element is qualified by another component data element within the same composite data structure, the qualifier shall precede the component data element being qualified. A qualifier component data element shall not be used in the composite data structure when the value of the qualifier, if used, would be a constant. The definition of the value shall be placed in a semantic note.
Note:
If 2.6.3b conflicts with 2.6.3a, then 2.6.3a takes precedence over 2.6.3b.
2.6.4
Additional component data elements added as a result of standards maintenance shall be added at the end of the composite data structure.
2.6.5
Composite data structure names shall be unique throughout the X12.3 Data Element Dictionary. Further, a composite data structure name shall not duplicate a simple data element name appearing in the X12.3 Data Element Dictionary or a segment name appearing in the X12.22 Segment Directory.
2.7.1
A repeating data element can be either a simple data element or a composite data structure.
2.7.2
The number of times a repeating data element or composite data structure occurs within a segment shall be specific. The business case shall determine the specified limit. The number of repetitions shall not exceed 999.
2.7.3
Two or more occurrences of a data element or a composite data structure can be adjacent to each other within an existing segment and not be deemed to represent a repeating condition.
2.7.4
If a repeating condition exists, there shall be a semantic note stating whether or not positionality of the repeating data element or composite data structure is significant.
2.7.5
A repeating composite data structure can replace a stand-alone simple data element in an existing segment if the following criteria are met:
-
The stand-alone data element being replaced is specified with its original condition designator as the first component data element in the repeating composite data structure.
-
The condition designator of the composite data structure is equivalent to the condition designator of the first component data element in the composite data structure.
-
The other component data element(s) in the composite data structure has a relational conditionality with the first component data element in the composite data structure.
2.7.6
For new segment development, adjacent multiple occurrences of the same data element or composite data structure shall not be defined as repeating unless they have the same semantic definition. Adjacent occurrences of semantically identical data elements or composite data structures shall be permitted without being defined as repeating.
3.2.1
Segments within a transaction set may be grouped into logical areas, e.g., heading, detail, summary. A transaction set may consist of any configuration of areas.
3.2.2
In a transaction set, mandatory segments are not required between the ST and SE segments.
3.2.3
Transaction sets are not required to have a unique "Beginning Segment." General information regarding the transaction that will most often be sent should be structured into the first segment(s) after the ST segment.
3.2.4
A beginning segment should contain the data required to clearly distinguish the intended purpose or use of a transaction set, specify sufficient information to uniquely identify the transaction set between trading partner applications, and indicate to the application additional processing that may be required.
3.2.5
For transaction sets employing Hierarchical Level (HL) looping structures in a beginning segment, transaction set notes, comments, and Data Element 1005 (Hierarchical Structure Code) may be used to clarify and define the business function.
3.3.1
Hierarchical Level (HL) looping structures may be used at any position within the transaction set.
3.3.2
Use the following Name Party Identification loop within a transaction set to provide a consistent pattern, which can meet the business needs of a range of potential users. Begin the loop with the N1 (Name Party Identification) segment when the business need is oriented toward identification of a nonhuman entity. Substitute the NM1 (Individual or Organization Name) segment when a human or nonhuman entity may be identified. When the business need requires a more robust functionality, adjust the loop content and usage designations, as required.
Segment Name=N1 Party Identification; Max. Use=1; and Loop=>1
Segment Name=N2 Additional Name Information; Max. Use=2
Segment Name=N3 Party Location; Max. Use=2
Segment Name=N4 Geographic Location; Max. Use=1
Segment Name=PER Administrative Communications Contact; Max. Use=>1
Segment Name=N9 Extended Reference Information; Max. Use=>1
The requirement designator and max. use for each segment within the loop is discretionary for the developer, based on the business need.
3.4.1
A segment may contain all optional data elements.
3.4.2
Segments should use a composite when multiple paired data elements are required. Use a repeat value on the composite if necessary. Excessive use of data element groups, such as the data element 235/234 pair, should be avoided in the same segment.
3.4.3
Segments should be limited to include only related data elements to support a specific business need.
3.4.4
Semantic notes may be used to assign meaning to the absence of data.
3.5.1
The maximum length of data elements to be used for totals should be large enough to accommodate the size of the detail amounts combined with the number of likely iterations or uses. If truncation is to be used, these rules should be stated in the appropriate location (e.g., transaction set comments, segment comments, or data element description).
3.5.2
Definitions for new codes must be complete. An expanded code definition should be provided for each code that is not completely self-explanatory, that is, terms that are not in general business use or that are industry specific.
Developers are encouraged to use existing standards configurations wherever possible. Segment development should be limited to a single functionality rather than formulation of a new segment which includes a compound functionality derived from two or more existing segments. The use of composite data structures to capture contextually related, singular functionality information within the context of a new segment is also favored in lieu of expansive arrays of simple data elements.
The following comparisons are provided for consideration in any new development work. Preferences for use and differences in functionality are provided to assist in determining the appropriate structures for use.
3.6.1 Transaction Sets
Reserved for future use.
3.6.2 Segments
Note 1:
Developers should note that the use of free form text capabilities is, under X12 standard interpretations, not machine processable, and should be avoided if at all possible in an automated environment.
3.6.3 Composite and Simple Data Elements
The preferred configuration for conveying binary data is Transaction Set 102 Associated Data.
Association linkage is provided through DE 1690 'Associated Object Reference' in the 'OOI Object identifier' segment that precedes the 'BDS Binary Data' segment in TS 102; and through DE 128 'Reference Identifier Qualifier', Code 'OIC Object Identifier' and DE 127 'Reference identifier' in which the value found in DE 1690 is placed.
Binary Data may be conveyed within any X12 Transaction set.
The preferred configuration to convey binary data within a transaction set is to provide a repeating OOI segment, followed by a single BDS segment. The OOI segment replaces and extends the capability of the EFI segment, except that the Filter ID Code (DE 1570) is located in the BDS segment. Transaction sets which contain neither a BIN nor a BDS segment may only be extended using the OOI/BDS configuration.
Existing transaction sets which already use the EFI/BIN configuration may continue to do so, and may be extended to include additional EFI/BIN instances, though the preferred configuration is to convert all EFI/BIN occurrences to OOI/BDS occurrences.
Existing transaction sets which already use the EFI/BIN configuration may change the configuration to EFI/BDS, in which case the DE 1570 Filter ID Code specified in the BDS segment shall override the DE 1570 Filter ID Code if present in the EFI segment.
The EFI segment should not be extended. If extended capability is required, the OOI/BDS configuration should be used. Such extension may require the addition of new code values for DE 1691 'Object Type Qualifier'.
Existing Usage - EFI does not repeat
EFI
BIN
Recommended Usage - OOI repeats (OOI qualifiers exist for all EFI DEs)
OOI
BDS
Acceptable Usage
EFI
BDS
EFI15/EFI16 should not be used
If EFI16 is present, value should match BDS01
If mismatched
A - Reject Document
B - Use BDS01, ignore EFI16
Note:
The BDS is a special purpose segment used to convey binary data in a single data segment and to allow identification of the end of the data segment through a count. No identification of the internal structure of the data is provided in the segment. Examples of such data can include image, computer automated design, numerically controlled machine tool, spreadsheet, and text processing files. Because ambiguity can result in the proper description of "binary data," it may better be thought of as "transparent data," data that, in data transmission is not recognized by the receiving program or device as transmission control characters. The BDS segment should not be used to replace other EDI functional area transaction set capabilities. In fact, it is used to convey transparent data as an augmentation to the other functional data. Inclusion of the BDS segment within a transaction may require the establishment of special translation, processing and procedures by both the sender and receiver.