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


Reply via email to