Chris, If you only use one clearinghouse, there is no discovery process. If you have several direct connections, the discovery could help. If you have more than one clearinghouse, the discovery is necessary.
Kepa Christopher J. Feahr, OD wrote: > Kepa, > Thank you for continuing to re-explain this with examples... the beauty > of this proposal is finally sinking in for me. Am I correct in assuming > that the practice we discussed earlier of having several primary payors > (i.e., several PlanIDs) in a single 837 would not break this model? I > suppose that anyone creating a multi-payor 837 would already have to > know which clearinghouse to send it to and would, therefore, not need > this address discovery process (?). > -Chris > > At 03:22 PM 2/9/02 -0700, Kepa Zubeldia wrote: > >> Ronald, >> >> Let me clarify something that may not have been properly expressed. >> One of the problems we are facing today, and will face more acutely >> tomorrow with the HIPAA PlanID, is how to identify the entry point for >> a plan ID. The entry point may not be the payer, but a PPO instead. >> Or we may not know who the payer is, and only know the PlanID. So >> trying to resolve the first phase of the DNS with a >> PlanID.PayerID.naic.hipaa.net sort of convention may be impossible. >> We probably don't know who the PayerID will be. That is why I believe >> we will need a double lookup, once to look up the DNS server based >> only on PlanID.naic.hipaa.net, and another to look up the entry point >> itself, by asking that DNS server. The first lookup could have a >> relatively static resolution, based on a central database that changes >> infrequently and points to the DNS servers, and the second lookup will >> probably benefit from the distributed maintenance due to its high >> volatility. In that second lookup, if the payer chooses to use >> something like your proposed PlanID.PayerID.naic.hipaa.net, so be it. >> But I suspect they will choose something more under their own control, >> like PlanID.Payer.com >> >> The other concept that I need to clarify is that of the relationship >> between the ISA and the transaction content. Or the lack thereof. >> When you say: "The biggest assumption this model seems to make is an >> ISA/IEA will only contain transactions destined for a single >> Transaction Receiver (PayerID)." I can see that I have not quite >> explained this right. >> >> The assumption here is that there is NO relationship between the ISA >> and the actual payers inside the transactions. There could be a >> relationship, and I have used the example of when the two are related, >> but most of the time there will be no relationship. >> >> For example, if I find that the payer in the claim is identified with >> PlanID:987654321, I would look for the DNS server for this plan by >> looking up 987654321.PlanID.hipaa.net. This would point to a DNS >> server that says (in the MX records) that I have a choice of three >> clearinghouses to get to this PlanID. Let's say that one of those >> clearinghouses is WebMD. This can be easily determined even before >> the transaction is translated into X12. At that point I would put the >> transaction in the WebMD "queue". Later in the day, I could gather >> all the claims in the WebMD queue and build an 837 transaction for >> WebMD that contains a lot of claims for a lot of different payers, all >> of which are pointing to WebMD as their clearinghouse. >> >> So, I create this 837 ready to send to WebMD. Then I lookup in the >> DNS to find what is the access point for WebMD and it gives me a >> telephone number or a web site or an FTP site through which I can >> reach WebMD. >> >> The trick here is that I have not made any assumptions about the >> association between the content of the transaction and the ISA being >> for the same delivery point. >> >> Essentially I am describing a spooling system, with address discovery >> before you queue the transactions into one of the queues, and not >> necessarily a tying between the spool queues and the physical devices. >> You could have multiple queues for the same device, as long as the >> device can handle it. >> >> If you were to tie the PayerID or PlanID from inside the transaction >> to the one in the ISA, you would force the entire industry to change >> what we are doing today, and would create havoc with clearinghouses >> and providers alike. I am NOT proposing anything of that sort. >> >> Echoing Bob Poiesz's comments, we need a system that will work in the >> future, but more importantly, we need a system that will work today. >> Today we send multiple payers into the same queue/clearinghouse. We >> need to continue to do this. We also need the capability to have more >> than one queue, so we have a choice. In any case, the ability to >> discover the delivery point(s) for any one health plan is the core of >> my proposal. And I propose to do so without a centralized database >> that would be almost impossible to manage, but rather give each payer >> the control over their own "domain of authority" for their own PlanIDs. >> >> I hope this helps. >> >> Kepa >> > > Christopher J. Feahr, OD > http://visiondatastandard.org > [EMAIL PROTECTED] > Cell/Pager: 707-529-2268
