Let me add something here... It would be trivial to create a database in which you could take the NAIC or DUNS number from the ISA and look up the electronic route to that entity, except... 1) who would create or maintain such a large database? 2) a centralized database could pose a security threat to the entire healthcare system if it ever went down, and 3) other political considerations get in the way of such a central database.
Going to a DNS model of distributing the database over different domains, even thousands of domains, would solve some of these problems and would give the payers, clearinghouses, and providers certain control. For instance, if we were to agree on a naming convention that gives the sender the freedom to use just the number in the ISA, the 60054 NAIC co-code from the ISA could be translated, as William has proposed, into something like 60054.naic.hipaa.net, or taking the GS08 into account, into something like 004010X098.60054.naic.hipaa.net. At that point, the DNS server for 60054, operated by Aetna (they "own" the 60054 NAIC co-code) would say that the MX records for 004010X098 point to MedUnite, WebMD, and NDC (just an example) and would give a priority level to each route, as well as the three routes to get your claims to Aetna. If instead of claims you were sending eligibility inquiries, the GS08 would be different, the standard EDI "name could be something like 004010X092.60054.naic.hipaa.net, and the MX records could point to different routes for real time eligibility hosts. Some of these claim routes resolved by the MX records for Aetna could look like: aetna.medunite.com, 60054.batch.webmd.net, or kermit.8005551212.phone.hipaa.net. The sky is the limit. As long as we have some standard way to name them. We may need to "create" such a standard. If instead of and NAIC number, the ISA says the number is the DUNS, the naming convention could point to 004010X098.110149127.duns.hipaa.net. From that point on, the distribution of authority and lookup would be exactly as above, with the DNS server for 110149127 operated by Aetna (that is not their real DUNS number). It has been pointed out by Bob Poiesz that the ISA would most likely not point to the payer or provider that is the source or destination of the transaction, but rather point to the clearinghouse or VAN that is the next hop in the chain. So, if Provider A sends a claim file to WebMD that contains claims for multiple payers, the ISA will have the WebMD identifier instead of the payer identifier. The payer is identified inside the 837 itself, and there will be multiple payers inside. This means that the ISA will have WebMD as the receiver. Then, if WebMD finds out that one of those payers needs to go to NDC, it is up to WebMD to route the transaction for that one payer to NDC, along with other transactions for that payer. If the provider was to identify that the transaction needed to go to NDC, it could be confusing, because the provider may not have a route to NDC, only to WebMD. So, this provider is using WebMD as its "intelligent gateway" and the actual ISA will reflect the WebMD identifier in all cases, hard coded by the translator. The trick is to build a mechanism that will work both with legacy systems that do not make routing decisions but use a gateway or clearinghouse to make routing decisions, as well as with future systems that want to make the routing decisions themselves. Making a routing decision could still result in the transaction being sent to the very same clearinghouse for further routing, but at least the system has to be flexible enough to accommodate both modes of operation. And be simple enough to use, build, and maintain. And be inexpensive or free. And give each entity control of its own destiny. And be secure. And... many more attributes. Just some thoughts. Kepa William J. Kammerer wrote: > "...would the current ISA ID values be used to do a lookup in the DNS > table by the VAN/CH to get the proper routing, or will the entire route > be in the ISA?" Only the entity ID (NAIC, DUNS, etc.) would be in the > ISA receiver field. We are advocating no changes to the existing ASC > X12 standards. All proposals assume a lookup for the routing would be > done based on that ID (and its qualifier). > > I can't imagine changes would be needed (or possible, given the time > needed for data maintenance to wend its way through the standards > bureaucracy) to the X12N standards in order to support any > recommendations that come out of this sub-working group. > > "Are we attempting to introduce new standards based on a transport layer > function (IP)?" New standards, or "recommendations," are a very real > possibility: e.g., a recommendation for exchanging interconnect > information, or Kepa's proposed DNS structure for obtaining routing > information, etc., etc. These would augment the existing X12 standards > and the HIPAA IGs - not replace any parts of them: we have to live with > what's already in place. > > William J. Kammerer > Novannet, LLC. > +1 (614) 487-0320 > > ----- Original Message ----- > From: "Ronald Bowron" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, 01 February, 2002 05:47 PM > Subject: Re: Using a hybrid DNS > > > Kepa, > > Based on the possible identifiers that are being discussed here, I'm > curious how they will be used in context of the ISA? > > Does your vision of how this DNS table would be utilized include the > use of the existing Sender/Receiver Identifiers (DUNS, HCFA, NAIC) in > the ISA? For example, would the current ISA ID values be used to do a > lookup in the DNS table by the VAN/CH to get the proper routing, or will > the entire route be in the ISA? > > The reason I ask is that the ISA06 and ISA08 only support 15 > characters, not much room to define a complete route. > > Clarification again on group objectives: > > Is the purpose of the routing sub-group to recommend changes to the EDI > X12N standards, if needed, to support this routing method? > > Or, work within the confines of the existing standards to identify the > best available routing method? > > Are we attempting to introduce new standards based on a transport layer > function (IP)? Or simply identify the best way to use the existing > standards to leverage the different transport technologies available > (Dedicated IP, Dial-up IP, Async, Bisync, etc.)? > > Thanks, > > Ronald Bowron
