1. Purpose and Scope

While the X12 standards provide a clear distinction between the syntax of X12 structures and the semantics of transaction set usage, there are cases where the relative positioning of segments within those structures provides semantic information in their implementation.

The purpose of this standard is to describe the semantic relationships inherent in the implementation of those X12 structures:

• The meaning that is to be associated with data due to their positioning within the exchange of X12 information, and

• The data relationships that can be inferred from the data structure.

The clearest description of this issue arises from the definition of each individual transaction set. Syntax and semantic notes provide explicit rules to be followed in the creation (for the sender) and decoding (for the receiver) of any use (instance) of that transaction set.

This standard provides the rules inherent in the structure of X12 interchanges that govern such creation and decoding. These rules shall be considered part of the standard, to be followed in using a specific transaction set, unless superseded by syntax or semantic notes for that transaction set. Such rules, if any, that apply to structures at levels higher or lower than the transaction set level will be provided as well.

2. Referenced and Related Standards

This standard is used with the ASC 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

3. Terms and Definitions

X12.5 Interchange Control Structures provides formal definition of terminology related to the interchange of information formatted as Electronic Data Interchange, as developed by ASC X12. X12.6 Application Control Structure provides formal definition of terminology related to the Electronic Data Interchange standards developed by ASC X12.

The following are terms and definitions for Semantic Structures:

ADDRESSING
"Addressing" is a term used to cover both the naming and semantic address of the logical or physical location of a person or position.

ADJACENT LEVEL
The term "adjacent" is used in a hierarchical sense. Two levels are adjacent to one another by reason of their relative positioning in the hierarchy of levels; one is at an immediately adjacent level to the other within the hierarchy.

AREA
An area is a distinct section of an X12 transaction set definition. The areas of a transaction set are "heading," "detail," and "summary."

BELONGING
The term "belonging" is used to identify the relationship of the data contents of a child structure to its parent structure. For example, line items are said to belong to an order.

CHILD
A child is a semantic entity that has meaning, in a transaction set instance, only through the parent structure to which it belongs. For example, an order line item has relevance only in the context of a total order.

DETAIL AREA
A detail area is any looping structure between the heading area and summary area of a transaction set. Detail areas encompass the actual body of the business transaction.

FUNCTIONAL EQUIVALENCE
Functional equivalence is the determination that the data contents of a segment or loop at one semantic level are meant to convey the same semantic intent as the data contents of a segment or loop at an adjacent level. For example, a line item ship-to address is functionally equivalent to a ship-to address in the order heading area. See the definition of PRECEDENCE below.

HEADING AREA
The heading area is an area at the beginning of a transaction set containing information pertaining to the entire transaction set.

INTERCHANGE
See X12.5 Interchange Control Structures.

NAMING
X12 uses naming structures to allow for the identification of a person or position. See ADDRESSING.

ORDER INDEPENDENCE
Order independence denotes a lack of any semantic significance in the order within the same semantic entity.

PARENT
A parent is a semantic entity that has a scope of applicability over at least one other semantic entity. For example, the data contents of the heading area of a purchase order are valid for all information in the order line items, barring precedence override.

PRECEDENCE
The term "precedence" describes a relationship among semantic levels such that, in the case of conflict between levels, the data contents at one level override (replace) the data contents of the other level. For example, if a line item ship-to address has precedence over a ship-to address in the heading area, it overrides the heading area address.

SEMANTIC ENTITY
A semantic entity is a segment or set of segments that, when taken together, convey meaning with the same scope of applicability. For example, the segments of a heading area of a purchase order provide the data contents that apply over the whole of that purchase order. Similarly, the scope of applicability of a GS segment is over the semantic entities included after it, up to and including its corresponding GE segment.

SEMANTIC ENTITY DEFINITION
The structure of a semantic entity, as published in a standards document, is its definition. The definition includes the sequence of data segments, their requirement for inclusion in any semantic entity instance, their maximum repeat counts, their placement within loops, and the requirement and repeat characteristics of such distinct loops. Segments may also be grouped in distinct areas (heading, detail, summary) to impart additional semantic significance.

SEMANTIC ENTITY INSTANCE
The data contents of a semantic entity, formatted in accordance with the rules of the semantic entity definition, comprises an instance of the semantic entity.

SEMANTIC LEVEL
The identification of semantic level is a designation allowing the description of a hierarchical relationship among semantic entities.

SEMANTICS
The term "semantics" typically pertains to the meaning of the information contained within a data structure, independent of the structure itself, such that the conversion from one structure to another would not change the meaning of the data. In this paper, the discussion focuses on what meaning can be inferred by the placement of information in the structure of EDI data.

SUMMARY AREA
The summary area is an area at the end of a transaction set containing information that addresses the results of summarizations of information in the detail area.

X12 STRUCTURE
An X12 structure is defined both in terms of its design (see SEMANTIC ENTITY DEFINITION) and its use (see SEMANTIC ENTITY INSTANCE). The design of an X12 structure is the sequencing of data elements within segments, and then, if applicable, the combination of segments in a sequence to make up a semantic entity. A use of an X12 structure is the formatting of specific data according to the structure's design, to convey a specific meaning.

4. Introduction

4.1 Syntax and Semantics in EDI Implementations

The terms "syntax" and "semantics," when used in the context of EDI implementations, refer to the structure and meaning of X12-formatted information, respectively.

• Syntax is the structure of the data. This includes establishing the method of encoding a piece of data by its attributes and identifying that data in the transfer, and is provided by the following aspects of the following X12 standards:

  • X12.6 Application Control Structure describes the basic structure of the components of an X12 functional group and provides the control segments used to bound loops of data segments, transaction sets, and groups of related transaction sets, and the special control segments used to bound transaction sets and groups of transaction sets for security purposes.

  • X12.3 Data Element Dictionary provides the attributes of type, minimum and maximum length, and if applicable, the relevant code list, of each data element that can be used in an X12 segment.

  • X12.22 Segment Directory provides the segment label, data elements within the segment (in sequence), requirements for use of each element, and syntax notes indicating relationships among data elements, if any.

  • Management transaction sets provide both the format and data content of transactions related to the interoperation of X12 systems. For example, the Functional Acknowledgment Transaction Set (997) describes the syntax-level acknowledgment of the receipt of an X12 functional group. Also, the Electronic Form Structure Transaction Set (868) describes the transfer of the EDI standards, or portions thereof, in electronic form.

  • All other transaction sets (defined as "business application" transaction sets) provide the structure of the segments to be used within each, including a heading area (Table 1, unless otherwise identified in the transaction set definition), detail area (Table 2), summary area (Table 3), looping structures within those areas (and nested within each other), and the segment sequence within the transaction set. In addition, each segment and loop is further defined in terms of requirement for use and maximum use.

• Semantics relates to the meaning of the data transferred to the business application. The meaning of X12 data is derived from the descriptions of the components of the standard used in a specific implementation and is provided by the following aspects of the following X12 standards:

  • X12.3 Data Element Dictionary provides the name and definition of each data element that can be used in an X12 segment, and if a code list is included, the description of each code. For ID data elements where the code list is maintained external to the X12 Secretariat, that external source provides the meaning of each code in the list.

  • X12.22 Segment Directory provides the name and definition of each segment that can be used in an X12 transaction set, as well as any semantic notes indicating relationships in the meaning of the use of one or more data elements in any one instance of the segment.

  • Business application transaction sets provide semantics in the name, description of purpose and scope, and transaction set notes and comments.

• Additional control: There are additional standardized components of the structure of X12 that control the distribution of X12 information through the enveloping of X12-formatted information, including:

  • X12.58 Security Structures defines the structures used for authentication and encryption of X12 transaction sets and functional groups.

  • X12.5 Interchange Control Structures provides the control structures for the electronic interchange of one or more functional groups.

  • X12.56 Interconnect Mailbag Control Structures defines the control segments used to bound a mailbag containing one or more X12 interchanges.

Taken together, the control components of X12 provide the structure in which the semantics of X12 can be exchanged between trading partners. The question to be addressed in this standard is whether the structure itself, by reason of the positioning of control information, provides any semantic content in the exchange of X12-formatted information.

The positioning of X12 control information is in terms of hierarchical levels of control, which will be described in detail in Section 5. For the purposes of highlighting the focus of this paper on the semantic content of any information provided at a particular control level, these levels will be referred to as "semantic levels." Of course, these semantic levels correspond to the hierarchy of the control levels.

4.2 Issues of Semantic Impact in X12 Syntax

This standard, therefore, will address the semantics implied by positioning within an EDI interchange. The document will address such issues as:

• Scope of Applicability
  For example, does the information content present in the heading area of a transaction set have any applicability to the detail area of the transaction set? (See example 2 in Section 6.1.)

• Precedence of Areas
  Assuming the answer to the previous question is "yes," how should a transaction set receiver treat the appearance of content in the detail area that is similar to content in the heading area? How can the receiver determine that such a "similarity" is intended? Does such information replace or add to the information content in the heading area? (See Section 6.3.)

• Intra-interchange and Intra-group Relationships
  Can a sender imply any relationship among transaction sets within the same functional group, or groups within the same interchange? (See Sections 5.1 and 5.2 for descriptive information, and example 1 in Section 6.2 for a review of the topic.)

• Order of Segments
  Is there any meaning in the order of segments within an area? Within a loop? (See example 3 in Section 6.2.)

• Loops
  What is the relationship among segments contained in an instance of a loop? (See example 2 in Section 6.2.)

• The HL Segment
  What is the meaning in the use of an HL segment to begin a loop? (See Section 5.6 for a description of the handling of loops beginning with the HL segment.)

• Routing
  What is the relationship, if any, between addressing information in the ISA and the GS? (See Section 6.4.)

This standard begins with definitions of the concepts and semantic relationships under discussion, followed by detailed descriptions of the rules governing those relationships. Examples are provided where applicable.

5. Semantic Levels of an EDI Interchange

The purpose in this section is to introduce the terms that are relevant to any discussion of the structure of an EDI interchange. A particular interest is to present these terms in such a way that the semantic relationship to their adjacent levels may be defined as well.

Items preceded by an asterisk under each section are the rules for the use of particular semantic levels that would have impact on their relationship to adjacent levels.

5.1 Interchanges Within a Logical Communications Exchange

Logical Communications Exchange
A logical communications exchange is any environment in which EDI information can be exchanged between trading partners in electronic format.

Interchanges
Each interchange between EDI trading partners occurs during a logical communications exchange. Each exchange includes the transfer of one or more EDI interchanges, possibly in both directions.

Each instance of a logical communications exchange shall be considered to be an external, enveloping structure of the interchanges that are transferred within that session. However, the semantic relationship between the interchanges and the logical communications exchange of which they are a part is beyond the scope of this standard.

5.2 Groups within an Interchange

Interchange Control Segments
Each interchange between EDI trading partners may contain interchange-level control segments related to prior interchanges. The only segment defined as an interchange control segment, which can be included within the interchange header and trailer, is the TA1, which references the acceptance or rejection of a prior envelope.

Functional Groups
Each interchange between EDI trading partners may contain functional groups. Each instance of a functional group applies to a specific business function, defined by the specific application to which it applies.

Each instance of an interchange shall be considered the parent structure of the interchange control segments and functional groups that are enclosed within the boundaries of that interchange. An interchange control segment is the parent structure of the data elements defined to be part of that segment.

5.3 Transaction Sets Within a Group

Transaction Set
Each functional group exchanged between EDI trading partners will contain one or more transaction sets. Each instance of a transaction set will identify a separate business transaction within the business function to which that group applies.

Each instance of a functional group shall be considered the parent structure of the transaction sets that are enclosed within the boundaries of that functional group.

5.4 Heading/Summary Areas of a Transaction Set

Areas
Most EDI transaction sets are designed so as to be divided into discrete "areas," which are typically identified in the transaction set definition by distinct tables of segments.

For example, the Price Sales Catalog Transaction Set (832) contains:

• A heading area, composed of reference information for the entire catalog

• A detail area, with individual line item information for each item in the catalog

• A summary area, containing a hash total count for the line items

The split of transaction sets into heading, detail, and summary areas is very common among EDI transaction set definitions. Unless otherwise defined in the publication of a transaction set definition, the heading, detail, and summary areas of a transaction set will be referred to as Tables 1, 2 and 3, respectively, excluding the transaction set header (ST) and trailer (SE) segments. Note that Table 2 would encompass multiple detail areas, if applicable.

The ST and SE segments are considered boundaries of the transaction set itself. However since these segments contain no semantic content (meaning) intended for the business application, they are part of the transaction set, but not part of any area in the transaction set.

Heading Area
Information in the heading area pertains to the entire transaction set:

• Every transaction set definition will have one and only one heading area, composed of at least one segment.

• At a minimum, the heading area of a transaction set definition typically contains data elements that identify each instance of a transaction set and its date. These elements are included to prevent replay of transaction set instances in a secure EDI environment.

• The use of any one segment in the heading area in any one instance of a transaction set is required only if the segment has been designated as "mandatory." If the transaction set definition does not include a mandatory segment in the heading area, then it is possible for one instance of the transaction set to have no heading area.

• The entire heading area comprises a segment group (see Section 5.6), which is not repeated.

Summary Area
Information in the summary area addresses the results of summarizations of information in the detail area (see the next section), or additional information about the entire transaction that cannot be expressed until the heading and detail areas have been generated. The summary area contains information such as control totals, balance totals, hash totals, etc.

• A summary area is not required in a transaction set definition.

• The use of any one segment in the summary area in any one instance of a transaction set is required only if (a) the summary area for the transaction set exists and (b) the segment has been designated as "mandatory" in that area.

• The entire summary area comprises a segment group, which is not repeated.

Each instance of a transaction set shall be considered the parent structure of the heading and summary areas that are enclosed within the boundaries of that transaction set.

5.5 Detail Areas of a Transaction Set

Detail Area
A detail area is any looping structure between the heading area and the summary area (or the SE, if no summary area exists). Detail areas encompass the actual body of the business transaction.

• There can be multiple detail areas in a transaction set definition.

• There is no requirement for a detail area in a transaction set definition.

• The use of any one detail area in any one transaction set instance is required only if the transaction set is designed to require at least one instance of the area.

Each instance of a transaction set, and the contents of its heading area, shall be considered the parent structure of any and all detail areas that follow the last segment of the heading area (or the ST segment if no heading area exists), and precede the first segment of the summary area (or the SE segment, if no summary area exists).

The summary area is NOT defined as a parent structure to the detail area.

5.6 Looping Structures Within an Area

Single Segment Repeat
Each segment in a transaction set is given an ordinal position assignment indicating its sequence within the transaction set relative to the other segments in that transaction set. Any individual segment may be repeated, in that same ordinal position, in a transaction set instance, if permitted by the transaction set design. However, the design should not allow repeat of the first segment in any loop (see below). If an individual segment is repeated in any one instance of a transaction set, and it is the first segment in a loop, a repeated occurrence of the segment indicates a new loop occurrence.

Segment Group
An ordered group of segments (more than one) within a transaction set is identified as a segment group. In the definition of a transaction set, segment groups are identified by the following: the entire transaction set; each area of the transaction set; the segments in an area not inside loops (see below) in that area; all of the segments of a loop or nested loop; and those segments in a loop not inside nested loops within that loop.

Loop
A segment group may be repeated in a transaction set instance, if permitted by the transaction set definition. Such an ordered group is called a loop. Note that each instance of a loop is a segment group.

Nested Loop
A loop may contain a loop. This condition is referred to as "nesting." In a transaction set definition, a loop whose first segment appears after the first segment of an immediately preceding loop, and whose last segment appears no later than the last segment of that preceding loop, is a nested loop within that preceding loop.

HL-initiated Loop
A looping structure in a transaction set definition may begin with an HL ("Hierarchical Level") data segment. When used in any transaction set instance, successive occurrences of the HL structure could indicate a parent-child relationship among the occurrences. The HL segment, therefore, allows the identification of an explicit nested loop in a transaction set. This nesting is not identified in the transaction set definition, but rather in the instance of the loop, in the data content in the HL segment. All semantic relationships that apply to nested loops will, then, apply equally to relationships between an HL-initiated parent loop and its HL-initiated child loops.

Loop Levels
For the purposes of this discussion, a loop which is nested within another loop is defined to be at a higher nesting level than the loop which nests it. The outermost loop is the lowest level loop; the innermost loop is the highest level loop.

• There are no limitations on the placement of loops. Looping structures may exist in any area of any transaction set.

• Transaction sets are defined to include a minimum number of occurrences of the loop. If the requirement designator of the loop's first segment is optional, the minimum number of occurrences of the loop is zero. If the requirement designator is mandatory, the minimum number of occurrences is one.

• Transaction sets are defined to include a specific maximum number of occurrences of the loop, or will be identified as having no maximum (>1).

• There is no limit to the level to which loops may be nested.

Each instance of an area shall be considered the parent structure of any looping structures enclosed within the boundaries (the first and last segments, per the transaction set definition) of that area.

Any loop that contains a nested loop shall be considered the parent structure of that nested loop.

5.7 Segments Within a Loop

Segments
Each instance of a loop (i.e., a segment group; note again that the header and summary areas are segment groups as well) contains one or more segments:

• Each segment within a loop structure is identified by its ordinal positioning within the complete transaction set definition. Each segment's order within the loop, relative to other segments within the loop, is defined by the sequential order of the ordinal positioning identifiers.

• The beginning segment of a loop defines an instance of a loop. For any instance of a transaction set, for any loop within any area of a transaction set, the first occurrence of the beginning segment of the loop (which must be present if any other segments in the loop are present) will identify the first instance of the loop, the second will identify the second instance, etc.

Each instance of a loop shall be considered the parent structure of any segments enclosed within the boundaries of that loop (the first and last segments, inclusive, of the loop, per the transaction set definition).

Each instance of a segment shall be considered the parent structure of any data elements used in that segment, as allowed by the segment definition.

5.8 Hierarchy of Semantic Levels

The following graph is a summary, hierarchical picture of the semantic levels outlined in the previous sections.

Note that "segment" has been identified as the bottom level, even though "data element" is certainly a level under segment. The semantic meaning of a data element or composite in relationship to the segment which contains it, and of data elements in relationship to a composite, is defined by X12.6, and will not be discussed further in this document.

Note also that the hierarchical flow of this graph applies equally to the cases of definition and instance of the standards. However, the level numbering in Figure 1 and the discussion about level numbering following it pertain to instances of EDI communications only.

Figure 5.1 - Semantic Levels in the Structure of EDI

Figure 1 presents a level numbering system that is useful for the determination of parent-child and same-level relationships among semantic entities. Note that outermost layers are identified by lower numbers. While this may be counter-intuitive, it reflects the fact that there is no limit to the nesting of loops at the innermost layers. So, the hierarchical level of the parent will be numerically lower than that of the child. To complete the numbering system, for any instance of a semantic entity within any one communications exchange, the following is noted:

• From levels 1 through 5, an instance of a semantic entity will be sub-indexed. For example, the first instance of an interchange within a communications exchange can be identified as entity 1.1, the second as 1.2, etc. (the ".1" an ".2" represent the sub-indexes). Similarly, the first instance of a detail area would be 5.1, the second 5.2, etc. Since only one heading area and one summary area are included in any transaction set, these levels are not sub-indexed.

• Below levels 4 and 5, instances of loops are identified by sub-indexing, within the semantic entity to which they belong, to the level at which they are nested. For example, the following level identifiers would pertain:

Figure 5.2 - Semantic Level Numbering Example

Note that, under this numbering scheme, level 4 is the combination of the header and summary areas, which are at the same level but distinct, so that any looping structure in one area is not a child structure to the other area.

The example leads to rules for identifying the hierarchical positioning among levels:

• If one semantic entity is a component of another, and the numerical value of the component entity's level is greater than that of the entity of which it is a component, the latter is a parent of the former. For example, each of the two semantic entities at level 4 (header and summary areas) will be a child of its corresponding semantic entity at level 3 (a transaction set). As another example, note that while the detail area (level 5) is a child of the header area at level 4.1, it is not a child of the summary area at level 4.2, because the detail area is considered a component of the header area, but not of the summary area.

• Two semantic entities are related in a parent-child structure if the numerical value of the subscripting of the two entities is the same, except that the latter has one more digit. For example, loop 5.1.1 is a child of loop 5.1. Conversely, loop 5.2.1 is not a child of loop 5.1.

• Two semantic entities are at the same level in an instance if they share the same subscripting up to the last digit. Thus, loops 5.1.1 and 5.1.2 above are at the same level. Conversely, note that there is no similar semantic level relationship between loops 5.1.1 and 5.2.1.

This, of course, does not apply to loops only. Two transaction sets in the same functional group would be identified as 3.1 and 3.2, for example, and therefore be at the same semantic level.

The discussion that follows identifies the rules governing the definition and instances of parent-child and same-level semantic entity relationships.

6. Relationships Between Semantic Levels

6.1 Belonging

The data contents of each parent structure are relevant to the data contents of the levels to which it is a parent. In this way, the instances of data content at one level belong to its parent structure.

EXAMPLES:

1. Inter-level Referencing
Each level in the EDI structure (other than the communications exchange; see the note above in describing that level) contains a unique referencing component between adjacent levels.

Each instance of data content at one level, therefore, can be referenced to its parent structure. Multiple instances at any one level, for the interchange, functional group, and transaction set levels, can be distinguished uniquely by their respective control numbers.

In addition, since the heading and summary areas can be uniquely identified within any one transaction set instance, their contents can share the unique reference of the transaction set.

However, in the case of multiple detail areas, and with respect to loops and segments, the transaction set definition must allow a means of uniquely identifying each instance. Examples are:

• The Payment Order/Remittance Advice Transaction Set (820) has two detail areas, which are distinguished by the loop names (ENT and TXP) that start each.

• The N1 loop starts with an N1 segment, the contents of which should be unique for every instance of its use.

• The LIN segment is often used to begin a detail area definition. This segment allows a unique "line item identification."

2. Transaction Set Areas
The definition of the heading area above has indicated that it maintains a scope of applicability over the entire detail area. A discount factor in the heading area would apply to each line item in the detail area. A discount factor for a specific line item in the detail area would apply to that line item only (note the issue on "functional equivalence" below).

6.2 Order Independence

There is no implied relationship among instances at the same level (two functional groups within the same envelope; two transaction sets within the same functional group, etc.).

Each instance of data content at one level is independent of any other instance of data content at the same level.

EXAMPLES:

1. Transaction Set Independence
Each transaction set instance in a functional group is a separate unit. The data contents in one cannot reference the data contents in another, except through explicit application data, such as a reference number. Such references are outside the scope of this standard.

2. Loop Independence
There is no semantic relationship implied in the order of instances of the same loop. Often, in the transmission of multiple detail line items, the sender would like to identify data content (e.g., a discount factor) in the loop containing the first line item and have it apply to all subsequent line items. This is a violation of "order independence," since the data contents of the second loop are in no way referenced to the data contents of the first.

Note also that the standards are moot on the multiple use of "functionally equivalent" information in loop instances at the same level. For example, there is no specific prohibition for a sender to use the N1 loop twice, and identify a different "bill-to address" in each instance.

Such an occurrence may represent an error in the transaction, but it is also conceivable that there could be a trading partner agreement in which the duplication is understood. If a semantic note is provided that justifies such a duplication, the structure of any instance of the transaction set must reflect the meaning of the semantic note. Unless such an agreement is desirable, the transaction set definition should indicate semantic notes to eliminate or justify such conflicts.

3. Segment Independence in a Loop
All of the segments within a loop are semantically related to one another only in that they are of the same instance at the same level. However, there is no semantic content implied by the order of segments within the same level of a loop. Rearranging the order of segments within the same level does not alter the semantics.

This applies equally to the first segment in a loop, which is often assumed to have special meaning to the loop. This meaning must be explicitly stated in a semantic note to the transaction set for its meaning to be different from that of the other segments in the loop. The exception is when the loop begins with an HL segment, the content of which identifies the nesting level of each instance.

Note, though, that the first segment of a loop, however, is syntactically significant, in that its requirement designator determines the requirement of the loop, and it must be present if any other segments in the loop are present.

4. Multiple Detail Areas in the Transaction Set Definition
Each detail area shall be considered to be at the same semantic level. There is no precedence among detail areas.

6.3 "Functionally Equivalent Data" Override

When the data contents of a parent structure contain information that is perceived to be duplicated in the child structure, the data contents in the two areas are considered to be functionally equivalent. There are three distinct possibilities for an instance of functional equivalence.

Unqualified segment functional equivalence
In any transaction set instance, a segment will be considered functionally equivalent to a segment in its parent structure when:

• The two segments have the same segment identifier.

• No qualifier is required to identify the use of that segment uniquely.

• The maximum use of that particular segment is once in each structure.

Qualified segment functional equivalence
When the second requirement above is not the case (e.g., the N1 segment requires the "Entity ID Code" to identify its use uniquely), the following set of conditions will identify a case of functional equivalence:

• The two segments have the same segment identifier.

• For that segment, a data element must exist that qualifies the entire segment.

• The two instances of the qualifying data element must be equal.

• The maximum use of that particular segment, with that particular qualifying data element, is once in each structure.

Loop functional equivalence
In order for an instance of a loop to be considered functionally equivalent to a loop in its parent structure, the following must be true:

• In the transaction set definition, each loop must have the same beginning segment..

• The instance of that loop in the child structure must begin with a segment that is functionally equivalent to the segment in the parent structure loop, whether qualified or unqualified.

Whenever functionally equivalent data are provided in a child structure instance, the data contents in the child structure will override (i.e., replace) the data contents in the parent structure. The over-ride is in effect for that child instance only.

Functional equivalence can be circumvented in a transaction set instance through the assignment of different code values in the (otherwise) functionally equivalent entities.

Also note, to generalize the point made earlier regarding loop ambiguity (see Section 6.2, example 2), that an instance of functionally equivalent data at the same level creates an ambiguity that cannot be resolved, except possibly by prior trading partner agreement.

EXAMPLES:

1. Heading and Detail Area "Contradiction"
The heading area often contains an N1 looping structure allowing for the identification of, for example, a delivery address to which all of the line items to be described in the detail area are to be delivered (i.e., "ship-to address").

If an N1 loop exists within the detail area, an instance of that loop may specify a delivery address different from that indicated in the heading area. In this case, the information content on that specific line item (to which that N1 loop applies) overrides the delivery address in the heading area. That is, the detail area ship-to address takes precedence.

There is one cautionary note about this example, however. Consider the following two segment instances:

N1*ST*........
N1*BS*........

The first of these indicates a "ship-to address" and the latter a "bill-to and ship-to address." The user might then assume that an occurrence of the second segment in a detail area would override an occurrence of the former in the heading area of the same transaction set.

This is NOT true in this case, however, because:

• A unique use of the N1 segment is identifiable only by both the N1 segment name and the first data element, the "Entity ID Code."

• The requirements for functional equivalence include equality in the use of the Entity ID Code, which is not the case here.

2. Summary and Detail Area "Contradiction"
By definition, information in the summary area is intended to summarize the information content in the detail area. As such, incompatibilities between the two areas would indicate an application-related error.

Further, information in the summary area has a semantically different relationship to the detail area from that in the heading area. That is, the scope of applicability of heading area information is on each of the line items (unless overridden at the line item level), while the scope of applicability of the summary area is on the totals derived from the detail area.

3. Heading and Summary Areas "Contradiction"
Therefore, there is no semantic contradiction (and thus there are no precedence rules) for seemingly "equivalent" information in the heading and summary areas. Any functional equivalencies between these two areas would represent an unacceptable transaction set definition.

6.4 Semantic Addressing

The first example in the previous section introduces a topic that is of considerable semantic importance in X12 transfers, that of naming and addressing.

• A name may be thought of as a label for a person or position (e.g., John F. Doe, President of XYZ Company, etc.). A name is independent of location.

• A semantic address is a set of attributes which usually describes the logical or physical location of the person or position. Examples are the traditional address on an envelope or a telephone number. Addresses are usually structured to provide sufficient information for identifying or locating the person or position (which may or may not be for routing purposes).

Much of the name and address information used in X12 is coded, with no distinction between a name and an address because the code encapsulates both. This standard, therefore, identifies name and semantic address information as a single concept, called addressing.

This section will identify and clarify the differences and relationships among four types of addressing within the structures of X12 transfers:

1. Business application

2. Internal identification

3. External routing

4. Data communications

6.4.1 Business Application Type—Within Transaction Sets

A number of different types of addressing can be transferred within instances of X12 transaction sets. Usually this information is provided in a segment group, frequently starting with the N1 data segment.

This segment group has provisions for qualifying the information to follow (e.g., "payer" or "ship-to address"), and a coded or full-text version of the addressing information itself. Through the qualifier, many different types of addressing may be provided, each serving a different business purpose.

All qualifications of business addressing are considered to be the same business application type, with no implied semantic relationship among different qualifications at the same instance level (note the N1 example in the section on functional equivalence).

However, semantic relationships can be inferred from qualifications at different levels. Each of the relationships among transaction set levels defined in the previous sections applies to business application addressing in the same way it applies to all other business information.

Business application information is conveyed from one business application to another (which may or may not be in the same organization).This business information is independent of the transfer method (e.g., printed matter, X12 transfer, voice calls to order entry clerks, etc.).

All business application addressing is included within the boundaries of a transaction set instance. There is no business application information in the addressing information at the functional group, interchange, or communications exchange level.

6.4.2 Internal Identification—Functional Group Level

Internal identification addressing information is carried as codes in the Application Sender's Code and the Application Receiver's Code control elements in the functional group header (GS segment). The values for these codes can be used for any routing internal to the organization, or any other identification purpose providing further information for trading partner record keeping.

There is no universal meaning to the data content of instances of those codes. For example, if an instance of the Application Receiver's Code contains the value "9876543", the internal identification could be a telephone number, a department (e.g., accounts payable), etc.

Because there is no universal meaning for these values, they can only be used for internal identification by the organization that understands their meaning. Meaning for particular values can be established by an individual organization, by trading partner agreements, or by industry groups.

Because of the internal nature of functional group addressing, there is no implied semantic relationship between instances of addressing at this level and that of the interchange and communications exchange levels (which are external routing levels).

Similarly, because this information has no universal meaning, there is no implied semantic relationship between instances of addressing at this level and that at the business application level (i.e., information within transaction sets).

Such relationships, if defined by trading partner agreements or by industry groups, would be outside the scope of the ASC X12 standards.

6.4.3 External Routing—EDI Interchange Level

Addressing information provided in the Interchange Sender ID and the Interchange Receiver ID of the Interchange Control Header (ISA control segment) is used for external routing.

In contrast to the functional group level, the values of instances of these control elements are qualified by the Interchange ID Qualified Code (e.g., a DUNS number, a phone number, the Standard Point Location Code, etc.). The values may then have universal meaning.

To restate the point in the previous section, addressing information provided at the EDI interchange level has no semantic relationship to addressing information at the functional group level.

Such a relationship, if defined by trading partner agreements or by industry groups, is outside the scope of ASC X12.

6.4.4 Data Communications—Communications Exchange Level

Addressing information in the interchange control header is usually not sufficient for delivery.

This information is typically mapped into a communications address for delivery, such as a modem telephone number, a CCITT X.121 address for a public data network, etc. This additional addressing information will depend on the particular data communications method being used.

Because of this close connection between the addressing at the data communications and interchange control levels, there is clearly a relationship that will have impact on proper processing (e.g., distribution, security, etc.).

For example, the receiver of an X12 logical communications exchange may determine that the interchange sender, as identified in the interchange level addressing information, is not authorized to send X12 information through the particular log-in channel that is (was) in use. This might be the case, for instance, when a VAN provides different log-in areas to indicate different distribution service levels.

Even so, such a relationship is not universal (since there are multiple, nonstandard mappings) and not part of the ASC X12 standards in any case. Therefore, there is no semantic content generated at the communications exchange level that is useful at any level inside the interchange.