Dave, I believe that each of your descriptions below represents a specific use case. Furthermore, each description represents a binary collaboration and possibly multiparty collaborations. The ebXML BPSS V 1.05 currently out for draft review addresses these concepts. Here's an excerpt from the Executive Summary of that specification:
"The ebXML Business Process Specification Schema provides a standard framework by which business systems may be configured to support execution of business collaborations consisting of business transactions. It is based upon prior UN/CEFACT work, specifically the metamodel behind the UN/CEFACT Modeling Methodology (UMM) defined in the N090R10 specification. The Specification Schema supports the specification of Business Transactions and the choreography of Business Transactions into Business Collaborations. Each Business Transaction can be implemented using one of many available standard patterns. These patterns determine the actual exchange of Business Documents and business signals between the partners to achieve the required electronic commerce transaction. The current version of the specification schema addresses collaborations between two parties (Binary Collaborations) as well as collaboration involving more than two business partners (Multiparty Collaborations) as a synthesis of binary collaborations. It is anticipated that a subsequent version will address additional features such as the semantics of economic exchanges and contracts, more complex multi-party choreography, and context based content." And more from the Design Objectives section: "6.1 Goals/Objectives/Requirements/Problem Description . . . The ebXML Business Process Specification Schema provides for the nominal set of specification elements necessary to specify a collaboration between business partners, and to provide configuration parameters for the partners’ runtime systems in order to execute that collaboration between a set of e-business software components." "7 System Overview The ebXML Business Process Specification Schema provides a standard framework for business process specification. As such, it works with the ebXML Collaboration Protocol Profile (CPP) and Collaboration Protocol Agreement (CPA) specifications to bridge the gap between Business Process Modeling and the configuration of ebXML compliant e-commerce software, e.g. an ebXML Business Service Interface, as depicted in Figure 2." Design Phase = : Business Process and Information Model Specification Phase =: ebXML Business Process Specification; ebXML CPP/CPA Run-time Phase =: ebXML Business Service Interface Configuration "The following section describes the concepts of a Business Collaboration, a Business Transaction, a Business document flow, and Choreography Multiparty Collaborations are between more than two roles, but such Multiparty Collaborations are always synthesized from two or more Binary Collaborations. For instance if Roles A, B, and C collaborate and all parties interact with each other, there will be a separate Binary Collaboration between A and B, one between B and C, and one between A and C. The Multiparty Collaboration will be the synthesis of these three Binary Collaborations. Binary Collaborations are expressed as a set of Business Activities between the two roles. Each Business Activity reflects a state in the collaboration. The Business Activity can be a Business Transaction Activity, i.e. the activity of conducting a single Business Transaction, or a Collaboration Activity, i.e. the activity of conducting another Binary Collaboration. An example of the former is the activity of placing a purchase order. An example of the latter is the activity of negotiating a contract. In either case the activities can be choreographed relative to other activities as per below. The ability of a Binary Collaboration to have activities that in effect are executing other Binary Collaborations is the key to recursive compositions of Binary Collaboration, and to the re-use of Binary Collaborations. An activity, whether it is a Business Transaction Activity or a Collaboration Activity represents the usage of a definition within a Binary Collaboration Specification. For instance, a Business Transaction is defined once and for all, but could appear several times – as a Business Transaction Activity -, sometimes even with opposite roles, within the same binary collaboration definition." "7.4 How to design collaborations and transactions, re-using at design time This section describes the ebXML Business Process Specification Schema modeling relationships by building a complete Multiparty Collaboration from the bottom up, as follows: 1. Specify a Business Transaction 2. Specify the Business Document flow for a Business Transaction 3. Specify a Binary Collaboration re-using the Business Transaction 4. Specify a Choreography for the Binary Collaboration 5. Specify a higher level Binary Collaboration re-using the lower level Binary Collaboration 6. Specify a Multiparty Collaboration re-using Binary Collaborations" As such, the use case analysis should be completed from which the appropriate CPP requirements can be determined. A CPP - at least in concept in my mind - contains the complete picture of a given entity's capabilities. This is the starting point for two entities to then reach agreement (CPA) on how they will conduct business electronically. Trying to develop a CPP without first going through the use case analysis and rigorously documenting the results will only result in an incomplete/inaccurate/unusable CPP. Rachel Foerster -----Original Message----- From: Dave Minch [mailto:[EMAIL PROTECTED]] Sent: Monday, August 12, 2002 6:31 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; William J. Kammerer Subject: RE: 276 routing question, esp. interested in Clearinghouse guru's opinion Kepa's response raises an interesting question, and one which I have been contemplating for some time - would a Plan, Provider, or CH (or other third party) want to post multiple CPPs based on the usage? In other words, there's 3 collaboration agreements and potentially 6 CPPs implied in Kepa's discussion: A) Plan<--->CH Agreement 1) CPP defined by a Plan which is to be used by its contracted clearinghouses; 2) CPP defined by the CH for use with contracted Plans; B) CH<--->Provider Agreement 3) CPP defined by the clearing house for Provider's use; 4) Provider's CPP to be used with contracted clearing houses; C) Provider<--->Plan 5) CPP defined by a Plan which is to be used by Providers; 6) Provider's CPP to be used with Plans. As a Provider, I wouldn't want to have to maintain multiple CPPs, given that each CPP should be a complete description of how electronic business is transacted. As a Payer, I also wouldn't want to maintain multiple CPPs - same reason. Therefor, both Kepa and William are correct in that the CPP must contain the ability to differentiate 276 routing based on healthcare_type, and more to the point, any kind of routing (real-time vs batch, for example, within a particular transaction type) for any of the transactions. However, if I don't want to maintain multiple CPPs, how can I create one CPP which provides one set of information for the transactions I want routed directly, and another set for those routed through a CH? It appears to me that the CPP must also accommodate the concept of collaboration nesting. That is, at certain defined levels in the CPP, I should have the flexibility to point to another CPP (e.g. that of my contracted CH or other third party). Only by doing this can I describe in a single document the protocols needed for all transaction routing variants. Dave Minch T&CS Project Manager John Muir / Mt. Diablo Health System Walnut Creek, CA (925) 941-2240 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. 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.
