Bruce: Actually, there is a very practical reason why payer-centric mailboxes are not being considered in our recommendations. Not once in 4 or so months had any payer (or anyone else, for that matter) brought up a requirement for payer-centric mailboxes which need to be polled or "pulled" from. I believe the first explicit mention - ever - of payer-centric mailboxes on this listserve was by Peter Barry in "Why CPP is Needed," on 30 May, 2002. And he was arguing for their demise!
We're not making the payer-centric model go away. We just never considered it! Quite seriously, it's not for me to anticipate and establish requirements for something I don't care about, and, indeed, see as very damaging to the notion of equality for providers. The CPP electronic partner profile we've been talking about all this while includes the concept of one or more Deliverychannels (or EDI Addresses) for defining one's own send/receive portals. The sender knows where to send, or "push," interchanges by examining the EDI addresses in his partner's CPP. Of course, as we've long said, an EDI Address may well point to one's own Clearinghouse; the "polling" arrangement the subscriber uses to access a mailbox at his own clearinghouse is out of scope for this project - there are probably as many or more techniques for accessing and "polling" CH mailboxes as there are CHs! But now that you've spoken up, even if you were to articulate requirements for payer-centric mailboxes I doubt there's much we could do to support them in the context of the ebXML CPP. A lot of work will be needed to accommodate "legacy" protocols and other requirements for traditional EDI in the CPP DeliveryChannel, but that's really an extension that ebXML has anticipated (though they initially only included SMTP and HTTP). On the other hand, the CPP is kind of passive in that it just says if you've got messages for me, send them to one of these portals (or DeliveryChannels or EDI Addresses), limited only by various selection criteria and the intersection of common protocol support on the part of either partner. Yes, Peter is usually a very well-reasoned fellow. Did you read the EDI Communications Security and Interoperability Requirements, which Peter offered to send out? In it, Peter fully lays out the justification for the "push" model, whereby a receiver is not "forced to poll separate mailboxes at every possible sender to see if a transmission should happen to be there." Actually his view on this issue predates my own by over a year, judging by the date on the report: 2000-12-31: is this what Peter does on New Year's Eve? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Bruce T LeGrand" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, 21 June, 2002 01:26 PM Subject: The payer centric model I have worried over something that was in a response from Peter Barry for some time. I usually find his arguments well reasoned and well documented. In this instance, I have been unable to locate information in the law or the rules that would make me understand his position. If anyone can point me to the appropriate place in the regulations to support the conclusion drawn in the following snippet, I'd be appreciative. <SNIP> Can a provider, under the transaction rules, require a plan to transmit, say, an 835 to its central receiving queue or port rather than being required by the plan to poll a mailbox on the plan's computer? That is an ambiguity in the rules. My interpretation has been, yes, and have advised clients to expect providers to make the requirement of them. Plans that are not capable of responding can make a reasonable legal argument but will probably not prevail. <END> discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
