X12 is meant to be independent of the transport method. The ISA only
needs to hold logical identifiers that represent the sending and
receiving entities - and 15 characters is more than enough for any
conceivable identifier (e.g., DUNS, FEIN, HIN, NAIC, or even the
National Plan ID and National
If there are payers out there who are running eligibility on a separate
system from their claims, then I don't know how we can treat real time
as a secondary issue. Right at the start, won't these payers demand
some way to say eligibility requests go here, and claims go there? Or
do these
I think for any high volume eligibility system providers and payers will
have to maintain systems that are completely separated from their claims
processing for response time issues. I realize transport issues are not
part of this discussion.
The State of WA has built a pilot application for
With UDDI and EBXML registries the sender asks the receiver what the
receiver can do. The receiver responds with a list of services and the
addresses for each service.
Hence, the burden is on the receiver in regards to splitting.
as a secondary issue. Right at the start, won't these payers
The Web Services paradigm is not exactly analogous to what we're
grappling with here. But even if it were apt, shouldn't your conclusion
be that the *submitter* (or requestor) do the splitting? - i.e., choose
among the (possibly many) addresses to forward his interchange to?
Yes, the payer -
William:
I will be surprised if this is a significant problem. That being said, I do
not support your suggestion that this problem be laid at the doorstep of
payers.
I suspect it is true of most payers that they maintain eligibility on a
different platform than claims. In fact, the data is
