Dave, I totally concur with you. And as a matter of fact what Dave describes is exactly how the ISA/IEA envelope (control segments) are intended to work and how the supply chain sector of not only medical products, but other industries as well operates.
Routing is not the significant issue - the originator needs to know only where they should send the interchange to for the first hop (their local post office so to speak). Could be a VAN, clearinghouse, or even a direct point-to-point connection. What's critical is the EDI address specified in the ISA receiver ID. Thus, I suggest we change the subject from payer identification codes to EDI addressing. Rachel Foerster -----Original Message----- From: David A. Feinberg, C.D.P. [mailto:[EMAIL PROTECTED]] Sent: Monday, January 21, 2002 7:08 PM To: [EMAIL PROTECTED] Subject: Re: Payor Identification Codes Chris, Look at Ronald Bowron's message of just a few minutes ago. It's another example of what I'm suggesting ... We don't need to know routing -- just addressing. When you post a letter via the United States Postal Service or Federal Express or private courier, you don't know nor care how they route it to its ultimate destination -- per the address on the envelope! All you care is that (a) you've got the proper address, and (b) the letter gets there in a timely manner. I really think we need to approach the electronic transactions 'mailing' issue the same way. Make sure we know the proper (current) address, and then turn our 'letter' over to a service that will get it where we want it to go in a timely manner -- without requiring us to know how the routing occurs. Thus our addressing tables (address book) only need know the name of each receiving entity, each entity's address, and the service to which we give the message for delivery. [And we can even allow for differing entity addresses based on the delivery service if we wish.] And all of this addressing can / should be done outside of the X12N ISA-IEA structure. In fact the receiver name most likely would be the entity name which is used to access our table for the entity address and delivery service. [And if we really wish to, we can also add an entry to our table for a 'via' address in addition to the 'to' address.] Unless I'm missing something [which I hope somebody will tell me], this is really a straight-forward issue. There's already plenty of technology around to implement it. Let's not make it too difficult. Dave Feinberg Rensis Corporation 206-617-1717 [EMAIL PROTECTED] ----- Original Message ----- From: "Christopher J. Feahr, OD" <[EMAIL PROTECTED]> To: "David A. Feinberg, C.D.P." <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, January 21, 2002 4:32 PM Subject: Re: Payor Identification Codes Dave, I will accept your (and Rachel's) wisdom and the benefit of your experience here and (for the moment, anyway) accept that a reliable central DB is unlikely for many reasons. If we can identify all the data elements that would be in such a master-table AND a messaging system, then each trading partner could maintain his/her local table of "routing information". Of course, one would need that very routing info in order to collect the information to put in his local routing table! We got a bunch of chickenless eggs (eggless chickens) here! Ron's right though... we should develop that list of data elements first, and then figure out how to keep the current version in every sender/receiver's system. -Chris Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
