Solving User Requests with the Interchange Syntax Extension

By Steve Rosenberg, Chair of X12’s Supply Chain Subcommittee (X12M)

X12 EDI (Electronic Data Interchange) standards have been around since the late 1970s, when computers, data communications, data storage and business relationships were infinitely different from what we have today.

After the breakout innovation of Internet technologies in the 2000s, X12 adapted to incorporate new languages such as XML, which fostered a changing business environment enabling individuals to reach a worldwide audience. Built on years of member supported development, X12 has a significant product library that includes more than 300 transaction sets representing a myriad of business processes, accompanied by an extensive set of internal code lists.

As we move further into the 21st Century, our work continues to evolve as X12 standards remain the workhorse for daily business-to-business exchanges. Our transactions enable product information sharing, the purchase order process, forecasting, inventory reporting, product activity reporting, product replenishment, healthcare reporting and transportation processes.

Although the origin of X12 is an older technology, our immense volume of proven work endures as the relevant, effective and efficient standard that interacts seamlessly with other standards. In our current environment, we recognize life as we know it has changed dramatically. "Business Not-as-Usual" is the new norm as the world battles the pandemic. We're proud that X12 standards are actively used by the healthcare industry to electronically transport medically necessary information amongst the various healthcare partners.

Our commitment to consensus-based standards development is solid in our quest to enhance enterprise productivity. The forward-thinking mindset of X12 subcommittees and staff strengthens our foundation for continued progress by respecting varying viewpoints and collaborating with other standards development organizations (SDOs), industry groups, government and business-focused entities. We are unwavering in our open-mindedness and responsiveness to addressing complex business needs from members and other organizations.

X12, with assistance from members and the user community, is:

• Responding to the needs of the X12 member community in today's fast-moving world
• Recognizing the value of varying viewpoints and diverse perspectives as technologies and business needs change, including fostering relationships with other SDOs and groups
• Focusing on solid leadership to guide X12 through the coming years by welcoming leaders who possess standards industry experience and X12 standards domain knowledge
• Examining avenues for future development with other technologies

Presenting the ISX Segment to solve user requests

On October 21, 2020, I had the privilege of introducing the Interchange Syntax Extension (ISX), a new optional segment recently added to the X12 Standard, at the New England Electronic Commerce Users' Group (NEECOM) Virtual Fall Conference.

With X12 version 8010, released in January 2020, we've enabled three pieces of new business functionality aimed at significantly enhancing trading partner relationships. Each of the three business requirements underwent a comprehensive review process. During the individual assessments, we recognized that each requirement can have an impact on all transactions within a GS/GE functional group.

Therefore, we needed a solution that would support each business need individually as well as in concert with each other.

The result of our analysis was the creation of the new ISX optional interchange segment. The ISX segment allows us to provide information to the EDI software that governs processing of all GS Functional Groups and their transactions within an ISA/IEA Interchange.

The benefit of this enhancement is that should X12 encounter future business requirements similarly having an impact on the processing of transactions, the ISX can easily expand to fulfill those needs.

Intended to increase standardization as well as provide enhanced flexibility, this X12 standard empowers the sender to specify additional information required by the receiver to perform syntax interpretation of the interchange.

Since the transactions that X12 developed represent cross-industry functionality, we recognized a need to provide additional guidance in the use of the standard. To support our community, and with their assistance, we have created implementation guidelines, reference models and clarification papers.

The following are the three business requests:

1. The ISX Segment and EDI Delimiters: Resolving data conflict with a data element delimiter

One of the guiding principles in the philosophy of EDI is that text data is minimized in a transmission. Previously, retailers and other trading partners required minimal product information for their item database as the consumer would visit a brick-and-mortar storefront to see, touch and purchase a product. Since EDI was developed at a time of high data communication costs, high data storage costs and large mainframe processors, a primary goal of EDI was to minimize all processing costs. Understandably, "small" was considered better back then.

With the rise of the online business-to-consumer relationship and online marketplaces, the need for easily available, accurate product information on websites exploded. Retailers not only re-examined their products to develop much needed information to publish online, they also put pressure on their suppliers to provide enhanced product-specific data.

For example, visualize a product you desire to purchase and the frustration that you felt when clicking onto a website only to find its description is limited. To help the consumer/purchaser make the right buying decision, many types of product information are essential, such as specifications (e.g., size, color, etc.), functional use, warranty and care instructions, just to name a few.

As these informational needs ballooned, X12 processors began to encounter conflicts with text fields including delimiter valued data, for instance, the asterisk. In order to alleviate this processing problem with the EDI translator, we implemented the concept of a 'release character'. By allowing the sender to declare a 'release character', if that character precedes a data element separator value in a text string, the EDI translator will allow the data string to process without incident.

The release character is the first element in the ISX segment.

A new data element, ISX01, Data Element I69, Release Character, has been added to the ISX segment. This new syntax object (release character) was added to the X12 Application Control Structure Standard, which prevents the character immediately following its appearance from being treated as a delimiter.

2. The ISX Segment and Character Encoding: Resolve a need to support other languages

Another business requirement was presented to X12 from an organization that interacts with trade parties requiring languages other than English in its text fields. X12 defines a Basic and Extended character set, and allows for certain foreign characters to be carried in a transmission.

Additionally, a language code data element (data element 819 Language Code that refers to ISO 639) can be used with some text fields; however, a number of language sets beyond ISO 639 are needed to be supported.

By incorporating another data element in ISX at data element position 2, the trade parties now have the ability to specify the language that pertains to all of the transaction text fields beyond the ISX.

A new data element, ISX02, Data Element I70, Character Encoding, was added to the ISX segment specifying the encoding of the interchange beyond the ISX segment. We now have the ability to identify one of 16 possible ISO values, which can be updated over time as necessary.

3. The ISX Segment and Code Versions: To resolve access to yearly code changes

The X12 standard continues to grow on a yearly basis. A new version is issued annually and includes updates to the transaction sets, segments, data elements and code values. Since X12 is a mature standard, most changes revolve around the addition of new codes.

X12 was requested by several members to determine the possibility of using a newer code set in tandem with an older transaction set version, such as a version 4010 transaction working with an 8010 code set.

We were able to resolve this business need by using the ISX segment for Unversioned Code List functionality. Data element ISX03 carries the value of the code set version used in the transmission that overrides the GS08 value of each functional group.

ISX03, Data Element 171 allows the sender to specify the version of code that will be processed within the interchange ─ a value different from the version declared in the GS08 data element.

Use of the ISX segment requires trading partner agreement and agreement of any intermediary processing parties.

We also introduced new data element ISX04 that carries an optional industry identifier code pertaining to the ISX03 value.

For example, the Pharmaceutical Research and Manufacturers of America or PhRMA uses a member-produced set of EDI industry guidelines in version 4010. Members now desire to use the X12 version 7010 code set containing updated codes important to their business processes. 

Thus, ISX03 would carry the EDI override version 7010, and ISX04 could carry the industry identifier PhRMA.

Companies must migrate to the 8010 ISA Interchange Control Standard to use the Unversioned Code list functionality.

The prior illustration shows the:

• Interchange control standard ISA is version 8010.
• ISX segment code set override version is 7010 with PhRMA as the industry identifier.
• GS functional group transaction set version is 4010.

Certain operational restrictions and considerations apply to using the ISX Unversioned Code List functionality:

• ISX03 does not override the transaction set, loop, segment or data element attributes.
• ISX03 pertains only to X12 internal code sets.
• ISX03 is applicable starting with version 4010, and only with full releases.
• All sub-releases (e.g., 4011, 5012, etc.) are officially removed from X12.
• Starting with version 8010, X12 standards maintenance adheres to an annual release cycle (ARC).

Implementation of ISX segment and code versions

To implement this functionality, X12 members are advised to do the following:

• Implement v8010 ISA interchange control standard, as that is the first version enabled with the ISX segment. Once added, you can use the 'override' code set going forward.
• Check with your EDI translator company to determine whether they have enabled this logic, as it requires access to the 'other' code list which supersedes the GS version.
• A trading partner agreement is required.
• Ensure that any third-party processor is aware and capable of handling this enhancement.
• Be aware that some code numbers were re-purposed and some code numbers were deleted. A few data elements have had size changes since version 4010, such as data elements 127 Reference Identification and 234 Product/Service ID.
  • If an element has increased, the longer value cannot be used in a host version where the length does not accommodate the longer value. Forty-four data elements have increased in size since version 4010.
  • Example: Data element 127 has increased from 50 characters to 80 characters; therefore, a version 5020 transaction is unable to accommodate a version 8010 51 to 80 character value.