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 - through his CPP - is offering "services" to the provider: saying, in effect, "we do all these types of transactions: 837, 270-271, 835, 834, 276-277, etc." But should the provider have to make the decisions to implement the split - i.e., decide to send the 270 to the payer's designated "real-time" portal, and 837s to the payer's "batch" portal? Or should the payer always make it easy on the provider by saying "Send everything to this one portal," and then separate 270s from 837s for subsequent processing behind the scenes? William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "joe mcverry" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "'WEDi/SNIP ID & Routing'" <[EMAIL PROTECTED]> Sent: Wednesday, 03 April, 2002 02:53 PM Subject: Re: How can we treat real time as a secondary issue? 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. Joe McVerry American Coders Ltd. POBox 97462 Raleigh, NC 27624 USA 919.846.2014 (voice/fax) http://www.americancoders.com Home Of OBOE - an EDI and EDI/XML Translator and xBaseJ - xBase Database Engine For Java
