Novannet, LLC LogoThe 10-10-EDISM of B2B Transport


Interchange Envelopes

EDI standards are independent of the transport method

The ANSI ASC X12 and UN/EDIFACT EDI standards are independent of the particular transport method chosen for exchanging messages or transactions. The X12 ISA and UN/EDIFACT UNB interchange envelope headers only accommodate logical identifiers representing the sending and receiving entities. The 15 characters in the ISA (or the 35 characters in the UN/EDIFACT UNB) for the sender or receiver are more than enough for most any conceivable identifier, such as the D-U-N-S, FEIN, and so on.

There is no way to address your partner in the interchange header using an e-mail address, TCP/IP address or URL. The interchange receiver ID in the ISA or UNB segments is not an "EDI Address," but rather it's simply the recipient's logical Identifier. An "EDI Address," on the other hand, is all the technical information defining the protocols, port addresses and other technical mumbo-jumbo for moving EDI data to a particular point (e.g., FTP addresses, URLs, e-mail addresses, dial-up telephone numbers, etc.)

Generally, some sort of mapping table (whether at the VAN or Clearinghouse, or even within EDIINT software) takes the logical identifier in the interchange envelope and maps it to an "EDI Address." An EDI Address could be a particular mailbox (in the context of a VAN or Clearinghouse), or the protocol and addressing specifications in the case of EDIINT or FTP. When you send an EDI interchange, your 10-10-EDISM client reads the ISA or UNB interchange header segment and uses the receiver ID to transparently and dynamically determine not only the internet address of the receiver's 10-10-EDI client, but also the public key needed for encryption.

The logical identifiers used in the ISA or UNB are fairly static, as the D-U-N-S, GLN or FEIN IDs don't often change for the same entity. But EDI Addresses are ephemeral, subject to the whim of the party being identified. For example, you may move your copy of the 10-10-EDI client to another machine with a different IP address. The 10-10-EDI network automatically detects this and transparently records your new IP address without you having to inform your trading partners. All interchanges addressed with the same receiver ID will always be delivered to a single recipient's 10-10-EDI client. It is possible that separate interchanges intended for two different trading partners end up being sent to the same 10-10-EDI client, as in the case when both trading partners just so happen to use the same EDI out-sourcing service. Likewise, your trading partner may have set himself up with multiple identifiers, where all interchanges using any of the specified identifiers are delivered to his single 10-10-EDI client.

mutually defined identifiers are the bane of standardized identification

The ZZ qualifier is usually used for hub or VAN assigned sender and receiver "mailbox" IDs. These mutually defined identifiers are the bane of standardized identification and also serve to lock trading partners into a particular VAN, since other VANs are unlikely to use the same IDs to identify partner mailboxes. For this reason, a sender should generally not be compelled to identify herself with a proprietary ID. And given the Open-EDI aspect of HIPAA, a payer may not even know ahead of time that he's about to receive a transaction from some provider. This is all the more reason that standard identifiers, such as the D-U-N-S or GLN, be used. Nonetheless, as a migration feature, the 10-10-EDI network allows you and your trading partners to use "ZZ" mutually defined identifiers, as we can simulate multiple logical networks to avoid identifier conflicts.

Functional Group Envelopes

...the GS02 and GS03 data elements can be used for a second level of routing. The GS03 is the application receiver's code. Some EDI users use the GS03 for routing a functional group to a particular department or application within the receiver's corporation. For example, you could use the ISA08 to identify the receiver as "Acme Corporation" and use the GS03 to identify the receiving application as the "Purchasing department (within Acme Corporation)". Many EDI users simply put the same value in the ISA06 and the GS02, and put the same value in the ISA08 and the GS03.

EDI Meets the Internet: Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet, IETF RFC 1865

In the supply chain sector, the common practice has been to use the same values at both the interchange (ISA) and functional group (GS) levels, unless the sender and receiver have agreed to use the GS identifiers to identify a business or operating unit within a larger enterprise. The GS segment contains neither a Sender ID or a Receiver ID, but rather an Application Sender's Code and an Application Receiver's Code. These are intended for use in internal routing and translation map identification, and are mutually agreed upon by the trading partners. In some cases, this GS information is needed to determine which application ultimately gets the translated data.

Employing the GS application sender or receiver codes used solely for internal routing by the recipient is certainly preferable to overloading the ISA sender or receiver IDs. Different operating units within the receiving enterprise should generally not be identified on the ISA using separate D-U-N-S identifiers, but rather within the GS by using unique application receiver codes if required. 10-10-EDI allows you to define multiple logical mailboxes or mailslots for one or more application receiver codes. For example, you can specify that incoming functional groups with "ACCTNG" in the GS application receiver code are shunted off to a separate directory for different treatment from all other functional groups.

Valid XHTML 1.0!