William and Rachel, I see what you mean about the CPP/A. The CPP's chief value appears to lie in the ability to use it to automatically negotiate the CPA, after which the two trading partners [previously unknown to each other] could launch right into a supported TRANSACTION. Clearly, this completely automatic model won't work in healthcare "out of the box", as you say.
But, what if... instead of defining the Business Processes to be supported as "claim submission", "eligibility query", etc... we defined one general "HIPAA2002-2003" process as "sending a classic EDI message to somebody"? Then it would seem reasonable for CEs to move forward with the creation of the ebXML "middleware" infrastructure... initially just to move around "stinky old EDI messages", but eventually (when internal systems have been redesigned to support it) to permit businesses to communicate directly at the application level. Presumably, HIPAA transaction rules permitting ebXML as an alternative strategy will be in place by the time partners are ready to begin testing ebXML-compliant applications. Is this the migration path that X12 envisions for the industry? I realize that the migration of healthcare from EDI to XML is a little off-topic for this group, but ebXML does seem to represent a reasonable system for CEs to find each other and establish a basic BUSINESS COMMUNICATION CHANNEL... today. That basic connecting part IS crying out for standardization, and that does seem to be the central mission of this group. I suppose that the relevance of this to the creation of list of "data elements for the WEDI-SNIP CPP" would be that we might want to try to fit that information into the format of the ebXML Process Specification Document... whatever that is. until monday, -Chris For what it's worth: I skimmed through the "4-4-2002" version of the CPP/A spec. and each CPP record contains a PartyInfo element with one or more of the following child elements: PartyID (globally unique ID for the organization) PartyRef (pointer to add'l trading partner info contained in an ebXML registry, UDDI repository, LDAP directory, etc.) ProcessSpecification (link to a document prepared in accordance with Business Process Specification Schema (ebBPSS)) plus a bunch of other elements to describe business role, certificates, delivery channels, message exchange protocol, etc. I tried reading the description of the Business Process Specification Schema (ebBPSS) and my brain sorta glazed over. At 07:15 PM 4/20/02 -0400, William J. Kammerer wrote: >The OASIS ebXML Collaboration Protocol Profile and Agreement TC Web page >is at https://www.oasis-open.org/committees/ebxml-cppa/, where the >current draft (ebCPP-1_11.pdf) of the spec can be obtained. An even >newer CPPA Version 1.12 can be found in the e-mail archives at >http://lists.oasis-open.org/archives/ebxml-cppa/200204/msg00055.html. > >As Rachel said, the "CPP/CPA is **NOT** about a registry at all. There >is a separate ebXML specification for the registry/repository portion of >the ebXML architecture." The examination of the ebXML Registry really >comes under the "Discovery" working paper group's aegis: Peter Barry, >Joe McVerry, Dick Brooks will be studying UDDI, the ebXML Registry and >Kepa's DNS "directory" recommendation. Your working paper group, >"Elements of the CPP," will be concentrating mostly on what's needed in >the ebXML CPP to support healthcare, and should be able to be designed >independently of whatever registry (or registries) the other group >recommends. > >I'll warn you, though, that there probably isn't too much in the CPP/A >specification that we can use directly "out of the box" - most of the >baggage in there is to support Business Processes and Messaging >Services, with nothing at all practically for "legacy" EDI support. >That's where we come in: as far as I know, we're the only folks who are >working to make the CPP support traditional EDI in a first-class way. >Except for the DeliveryChannel stuff in the CPP, you may be on your own >for defining partner capabilities as they apply to EDI. > >Distributing PDF or Word documents seems perfectly okay to me, though I >know there are Linux pin-heads (no offense intended, Kepa) out there who >get all upset at the idea of using anything M$ related!! > >William J. Kammerer >Novannet, LLC. >+1 (614) 487-0320 > >----- Original Message ----- >From: "Christopher J. Feahr, OD" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> >Sent: Saturday, 20 April, 2002 06:43 PM >Subject: RE: Data Elements for the WEDI-SNIP-CPP > > >Rachel, > >Thanks for clarifying the relationship between the CPP specification and >the separate CPP registry-structure specification. If I understand the >immediate task assigned to me, Dave, and Marcallee, however, it is to >propose a list of data elements that we consider important in the >"WEDI-SNIP CPP". I'm not sure I understand how am I getting off into >"left field" with this? I'm sure it's buried in the email archive, but >can you point me again to the draft "CPP/A specification"? I think what >we are after here is just a list of data elements, but I would welcome >any further light you can shed on the task I volunteered to help with a >few weeks ago. > >William: Given the unwieldy nature of this email-narrative type >knowledge we've accumulated over the last few months, what format would >you suggest for group collaboration on some draft documents? I'm just >now installing Adobe Acrobat 5.0 and I believe that it allows many >people to mark up .pdf documents posted on a web site, using signed >notes, etc. Is something like this feasible? The free .pdf reader would >allow the whole group to read the document and the notes, but I think >you'd have to have the full version of Acrobat to actually mark up the >draft copy. > >I see a need to move this effort to a more organized level, starting >with drafts of: > >1. Mission and requirements list >2. Definitions of terms used in "addressing and routing" >3. Proposed data elements for the CPP record > >Thanks, >-Chris > >At 04:42 PM 4/20/02 -0500, Rachel Foerster wrote: > >Chris, it's very important that you get the most current specs (draft) >on > >the CPP/A specification to see what it specifies. I fear (no pun >intended!) > >that you may be moving way off into left field where you may not want >to > >be....perhaps yet. Let's get the core of the CPP done first. > > > >Rachel Foerster > >Christopher J. Feahr, OD >http://visiondatastandard.org >[EMAIL PROTECTED] >Cell/Pager: 707-529-2268 Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
