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
