Ronald, Here is what I have in mind...
Let's say that the ISA looks like: ISA*00* *00* *30*731234567 *33*60054 *020207*1230*U*00401*000000001*0*T*>~ This represents a transmission from EIN:731234567 to NAIC:60054 The first step is to find who is the DNS server for the NAIC:60054 receiver. This could be done by looking up who is the DNS server for the domain 60054.naic.hipaa.net. Other mappings between the ID in the ISA (or in loop 1000 or 2010) could look like: 731234567.ein.hipaa.net or 112223456.duns.hipaa.net. Once we know who is the DNS server for that domain, we can ask that DNS server for its MX records. When we ask the DNS servers for 60054.naic.hipaa.net (operated by Aetna) ti give us its MX records it could answer with something like: 1 edi.aetna.com (110.111.112.113) 10 ftp.medunite.com (121.122.123.124) 20 edi.webmd.net (190.191.192.193) 20 x12.ndchealth.com (160.161.162.163) 90 8005551212.phone.hipaa.net (0.0.0.0) The first parameter is the "preference" value (lower values are higher preference), the second parameter is the host name, and the third parameter is the IP address of that host. As Aetna indicates all of its possible routes, the submitter will have to decide which path to take. This decision will most likely depend on which connections the submitter has available. Aetna may give preference to MedUnite, but if the submitter is only connected to NDC, then the choice is just NDC. I have also shown a direct connection to MedUnite either via the Internet or via dial-up to a specific phone number. The presence of these direct connections does not mean that the submitters can automatically pick that route, as they will need to have other information such as protocol, login, password, and probably a trading partner agreement. In fact, this is true of ALL paths, either directly or through a clearinghouse. This address discovery could have another additional value added step, perhaps optional. Once I know who the DNS server is, instead of just asking the DNS server for its entry point, I could ask the DNS server for the specific entry point for my type of transaction with the mode of response that I want. For modes of response we could recognize either "real time" or "batch". So, I would ask the DNS server for Aetna to give me the MX records that correspond to the domain batch.837.60054.naic.hipaa.net or to the domain rt.837.60054.naic.hipaa.net. The same would apply to the other transactions. This would let Aetna designate different gateways for different transactions. It would also allow Aetna to refuse a certain modality for a certain transaction by just not providing an MX record for it. With 9 transactions and two modalities, it is easy to manage the different domains for each trading partner. Even as the number of transactions increases, it is still manageable. Why is this address discovery phase so important? We currently are basing our EDI transaction addressing on the concepts of "payer", "submitter", and "receiver". With these concepts we have a relatively small set of NAIC co-codes and EINs to deal with. If this was to continue to be the case, the address discovery would not be very important. It is easy enough to put the "payer ID" in the insurance card. Even though a lot of patients come to the doctor without their insurance card, the lookup is relatively easy. But, under HIPAA, the Secretary is going to enumerate the "health plans" instead of the payers, and the "providers" instead of the submitters. And according to HHS there will be about 2-4 Million "health plans" and in excess of 1 Million providers. It is the mapping between the health plan and the actual EDI end point that represents that health plan that becomes a challenge. A substantial number (the vast majority) of these health plans will be administered by either payers or third party administrators. And the plan administrator may have dozens or hundreds of plans being administered in the same system. So, the address discovery of 987654321.ein.hipaa.net points to the DNS server for Aetna (tomorrow it could point elsewhere) and I can easily ask Aetna as to where to send those transactions. And Aetna could easily point me to a re-pricing PPO rather than to its own entry point. Trying to maintain such a database in one centralized point will be very difficult, but delegating the responsibility to those that are interested in processing the transactions is more likely to work at a minimum cost. Is this starting to make sense now? If all we needed to do was to map the ID to the delivery address for the current system, the problem would not be all that hard, but the IDs under HIPAA become very granular, to the point of making the mapping between ID and EDI address an interesting challenge. Looking even further into the future, the day will soon come when the providers need to talk with each other. This same system will allow providers to electronically find each other's preferred address and delivery point with minimal effort. For example, a provider could easily specify that for a certain EIN they are willing to receive unsolicited 277 transactions through a clearinghouse, and 835 transactions through their bank. And HL7 messages through their HIS vendor's gateway. Another provider using the same vendor could automatically discover this delivery endpoint and send HL7 messages with as minimum effort. Does this help see the vision? Kepa Currently The second step is to ask the proper domain server where it wants these transactions. Ronald Bowron wrote: > 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
