William, What you're describing is, as you know, how EDI works in the supply chain today. The other challenge to think about, though, is when one uses the public internet (privacy and encryption requirements aside). Then EDI addressing is complicated by the fact that the X12 interchange must be put into some "package." I've earlier argued that health care seriously examine the ebXML Message Services specification, which I know you're very familiar with.
So....do we have two separate but related EDI addressing issues? 1. EDI addressing in the ISA envelope 2. EDI addressing when the ISA envelope is the payload within another message handling specification Then we also need to keep in mind the coding systems already allowed as valid for HIPAA: 01 Duns (Dun & Bradstreet) 14 Duns Plus Suffix 20 Health Industry Number (HIN) 27 Carrier Identification Number as assigned by Health Care Financing Administration (HCFA) 28 Fiscal Intermediary Identification Number as assigned by Health Care Financing Administration (HCFA) 29 Medicare Provider and Supplier Identification Number as assigned by Health Care Financing Administration (HCFA) 30 U.S. Federal Tax Identification Number 33 National Association of Insurance Commissioners Company Code (NAIC) ZZ Mutually Defined Thus, the originator of an interchange can select its unique EDI address from one of these systems and the receiver can select its own EDI address, not necessarily from the same coding system. The challenge is how to know when EDI address to use for the intended receiver. Rachel Foerster -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Monday, January 21, 2002 9:56 PM To: WEDi/SNIP ID & Routing Subject: The "Domain Name Server" for Health Care Ronald Bowron asked Chris Feahr "why is this any different than DNS over TCP/IP? The internet routes users to companies and WEB sites on a regular basis. Are the business requirements for managing this 'Trading Partner Directory' any different? Wouldn't that be a good model to follow?" The Domain Name Server (DNS) system is indeed a distributed database that does seem to do a good job of keeping abreast of all high-level domain names. It relies on each node's incentive to be accurately recorded. For example, I have every incentive to ensure the DNS system knows which web server http://www.novannet.com/ is to resolve to, or which e-mail server handles [EMAIL PROTECTED] I do want to be found. I even pay money to a registrar to ensure everything is up to date so you can find me! I'll put aside the impertinent question of "how many payers want to be found easily by providers?" Seriously, DNS is a lot like the model I thought VANs and Clearinghouses should employ: ...why couldn't the VAN or CH see that it doesn't recognize the NAIC code [in the ISA receiver field] as belonging to one of its customers, and automatically set up the interconnect? The VAN or CH could query every other intermediary it knows about to see if they own a direct connection. There's no need for a centralized monolithic database. Every intermediary (VAN or CH) has incentives enough to know where their own customers are. Likewise, each of their paying customers - providers and payers, alike - has an incentive to keep their own intermediary aware of where they are on the information super-highway. More problematical is whether an intermediary has any incentive to let another (intermediary) know that a provider or payer is on its network. Currently, it appears not to be the case because of the very weak interconnection support provided by VANs and CHs. William J. Kammerer Novannet, LLC.
