The service provider can offer both batch and real time services by
pointing to the same or different addresses.
Send any transaction to this address and my transaction processor will
decide how to handle your request.
-or-
270s are always sent to address A, 837s are sent to B, 276's and 277
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 pro
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 -
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 payer
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 real
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 pa
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
