Isn't the small size of these identifiers the main reason why we have to "map" the identifiers into an address?
It is still trivial and reliable and cheap to do this using the currently existing DNS, using a small XML tag in the TXT component of the DNS directory, just like William has his setup. The XML code can point to a URL or a phone number or any other sort of "address" and specify additional parameters like hours of operation, transactions supported, etc. If we could just agree on one way to do this... It does not have to be perfect. It does not have to be complete. Maybe it does not even need to cover all the possibilities. But it needs to be useful/usable TODAY. Just a thought... Kepa On Tuesday 02 April 2002 02:04 pm, Christopher J. Feahr, OD wrote: > well... the small size of the ISA08 field, combined with the variety of > application-specific addressing requirements, and the general reluctance to > require receivers to "drill" further in to ferret out more addressing > "clues"... would certainly seem to MANDATE the existence of one or more > registries that contain the Full Story of how to send anything to a > particular receiver. > > Every time we hit this wall, someone reminds the group how unlikely and/or > expensive such a registry would be. But if we don't have the room or the > legal option of creating room for the Full Story inside the message > envelope, what other option is there? (I can't think of any, other than > the laborious paper TPA negotiation process between each trading pair). > > -Chris > > At 02:23 PM 4/2/02 -0500, William J. Kammerer wrote: > >Now, as Rachel would say, I think I'm getting "wrapped around an axle" > >with this ISA and GS stuff. After thinking about it, the GS should only > >be used for internal routing by the recipient - something we all learned > >in EDI 101. No intermediary or communications package should ever have > >to "drill" down within an interchange to look at functional group > >envelopes. > > > >So we probably only have the ISA available for routing. And if only the > >ISA can be used, that probably implies only the 15 character ISA08 > >Receiver Code is available for discerning EDI addresses - which might > >require different recipient IDs for various purposes. > > > >So where does that leave us if a "real-time" 270 has to be sent to a > >different "portal" than a "batch" 837? Do we have to use a suffix on > >the payer's NAIC company code in the ISA08 receiver field to distinguish > >between batch and real-time? > > > >William J. Kammerer > >Novannet, LLC. > >+1 (614) 487-0320 > > > >----- Original Message ----- > > From: "William J. Kammerer" <[EMAIL PROTECTED]> > > >To: "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]> > >Sent: Tuesday, 02 April, 2002 11:51 AM > >Subject: Are only 15 characters in the ISA receiver ID enough? > > > > > >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 > > Christopher J. Feahr, OD > http://visiondatastandard.org > [EMAIL PROTECTED] > Cell/Pager: 707-529-2268
