Chris: We probably shouldn't call ISA08 an "EDI Address." It's the recipient's EDI Identifier. An "EDI Address," as Peter Barry would remind us, is all the technical mumbo-jumbo that defines the protocols, port addresses and other desiderata for moving EDI data to a particular point (e.g., FTP addresses, dial-up telephone numbers, etc.). The EDI Identifier in ISA08 will be used to retrieve the recipient's CPP (Electronic Trading Partner Profile), which in turn will contain the appropriate EDI addresses.
And yes, it's possible that interchanges can be "going out the door with identical ISA08 values (identifying the receiver), but be going to different EDI addresses... because of their specific transaction payloads." This seems to be a requirement raised in previous discussions; e.g., "real-time" 270s might be directed to a different EDI address than "batched" 837 claims. I don't know how this could be done today with current translators and communication software: how does the translator convey to the communication software that the interchange is "real-time" vs. "batch"? If anyone has an idea how they would implement this with their current systems, please don't hesitate to write in! If there is no direct link between the translator and communication software, then the comm software does have to be sensitive to the payload contained in the interchange - at a minimum it will have to "drill" into the GS envelope to distinguish eligibility inquiries from claims, or to examine the GS Application Receiver's Code for hints in selecting the appropriate EDI address. Likewise, if all interchanges are sent to a single intermediary, such as a VAN, then the VAN would have to "drill" into the interchanges (so the correct EDI address can be determined). As an example to show why "drilling" down into the GS may be required, consider the scenarios presented by Doug Renshaw earlier. Highmark might want interchanges delivered to a different EDI "gateway" depending on whether "V" (vision claims), "W" (if an institution is in its Western Region), or "C" (if in its Central Region) is appended to its NAIC in the GS Application Receiver's Code - these suffixes would determine the appropriate EDI address to send the interchange to. If only X12 had adopted ISO 9735 UN/EDIFACT Syntax Version 4 for interchange control, then we could have avoided the problem of drilling into the interchange (to retrieve distinguishing information from the GS). The UNB Interchange Header in EDIFACT not only lets you specify the recipient identifier (in D.E. 0010 - Interchange recipient identification), but also an internal routing code (in D.E. 0014 - Interchange recipient internal identification), so you can make all your decisions for routing just by looking at the UNB without going further in the interchange. See http://www.gefeg.com/jswg/ if you're the least bit interested in the layout of the ISO 9735 EDIFACT interchange envelopes. But unfortunately, adopting ISO 9735 interchange envelopes is not in the cards, so we have to rule out this elegant solution! As an aside, I'm left wondering how all those translators out there today are going to handle out-of-network claims from a provider the payer has never seen before - will they have the capability to automatically create Trading Partner table entries, dynamically adapting to new ISA sender IDs as they arrive? William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Christopher J. Feahr, OD" <[EMAIL PROTECTED]> To: "William J. Kammerer" <[EMAIL PROTECTED]>; "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]> Sent: Friday, 29 March, 2002 08:23 PM Subject: Re: Payers sure do like proprietary provider IDs! Do providers feel the same way? The ISA receiver ID is defined as follows in the IG: "Identification code published by the receiver of the data; When sending, it is used by the sender as their sending ID, thus other parties sending to them will use this as a receiving ID to route data to them" The definition seems to imply that ISA08 is some sort of an "EDI address". But even if you can identify the receiving entity with one of the permitted numbers, it is still likely to have a variety of application-specific or possibly sender-specific EDI addresses... that might change over time. Can interchanges be going out the door with identical ISA08 values (identifying the receiver), but be going to different EDI addresses... because of their specific transaction payloads? With only 15 characters in the receiver ID, I don't see how we can identify the entity (via DUNS, FEIN, etc.) and have enough room left to fully specify even a unique registry-pointer to the rest of the "collaboration" details. This fuzziness about what the standard requires in ISA identifiers, combined with the "creative" uses that Michael Mattias has described is making it hard for me to visualize how anyone could route these messages WITHOUT drilling down into the transactions to get information about the true communicating parties. I'm beginning to think that there may not be enough intelligence in the ISA/ISE envelope to route these things. Either the current (several week long) trading partner negotiation and testing process would have to take place for every messaging-entity-pair, or we would have to implement something like the full-bore ebXML CPP/CPA for fully automatic negotiation. In that case, we could use the ebXML transport protocol to carry the X12 interchange as a "dumb" payload... rendering the ISA identifier unimportant. Does it still seem feasible to the group to have hundreds of thousands of communicating parties trying to route these messages on the basis of a 15 character ISA identifier? -Chris At 04:40 PM 3/29/02 -0500, William J. Kammerer wrote: >Keep in mind that if the Registry is powerful enough to be searched by >any (non-proprietary) ID, then the sender could just blindly stick the >FEIN in the ISA receiver ID, knowing full well that a VAN or CH >intermediary could search the Registry for the CPP which contains the >EDI addresses and ports. The whole concept of a "preferred" ID may give >way to a more powerful notion whereby a receiver can be identified in >the ISA by any of its known IDs (whose domains or type are allowed by >the HIPAA IG). Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
