Dick: Thanks for the update. It looks like we're getting good traction with this ebXML CPP/A stuff!
Speaking of the ebXML Registry: yes, Kepa's DNS "directory" could certainly "locate" a CPP document containing trading partner information, using one or more identifiers as the key for the search. I always thought that this was more than adequate, not imagining that it would be particularly useful (to payers or otherwise) to do a query to find all the proctologists in the Columbus, Ohio metro area. HIPAA participants will generally already know their trading partner's ID, and the DNS directory seems entirely suited to searching on that ID. But after thinking about it, maybe we will need to employ ebXML's robust query technology: if there's nothing in the application transaction set (e.g., the 270 or 837) that definitively gives the provider's "return" EDI identifier, then perhaps the payer could use the ebXML Registry to search on known identifiers (such as the TIN) to indirectly find the provider's CPP, which in turn would have the preferred EDI identifier (say, the D-U-N-S). William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Dick Brooks" <[EMAIL PROTECTED]> To: "William J. Kammerer" <[EMAIL PROTECTED]>; "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]> Sent: Thursday, 28 March, 2002 07:39 PM Subject: Update on CPP effort. This is a brief update on the progress to date on the ebXML CPP initiative. I met with Dale Moberg, chair of the OASIS CPP TC, today to discuss the potential use of ebXML's CPP to describe trading partner profile information. We discussed the current CPP work at OASIS and timing for the next release of the specification, scheduled for June 2002. I provided Dale with an overview of the groups requirements with regard to trading partner profiles within the Interoperability and ID/Routing projects. After hearing these requirements, including the October 2003 implementation deadline, he suggested that WEDi/AFEHCT consider using a "CPA template" approach as opposed to the more complex negotiated CPP/CPA process. He explained the CPA template is more "rigid" than the negotiated CPP/CPA, however it is much "simpler" to implement. I also described the current discovery models which have been discussed (Kepa's DNS and ebXML registry/repository). Dale indicated that ebXML's CPP specifications are designed to work with ebXML's registry/repository solution. It may be possible to use DNS to "locate" a CPA document containing trading partner information, however there would likely be a loss of functionality, which the combined CPP/CPA and ebXML Registry Repository provides (e.g. search for CPA's using keywords). An ideal solution, I suspect, would combine the simplicity of the DNS approach with the robust functionality of ebXML's registry repository. Dale and I agreed to create a "white paper" describing an ebXML CPA template approach to address the trading partner profile requirements identified by the group. This paper would also clearly identify areas of the CPA template where multiple options exist and decision are needed. In these cases an analysis of the options will be provided (pros/cons). The purpose of this paper is to provide the group with enough information to decide whether or not, ebXML's CPA template approach is a viable solution to exchange trading partner information. The paper will remain neutral with regard to discovery approaches. We have set a goal to create a draft version of this paper by May 18, 2002 and release a final version by the June trimester meeting of X12N in Minneapolis. Please feel free to contact me if you have any questions/comments regarding this plan. Thank you, Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com <http://www.systrends.com> Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714
