Rachel, If I'm understanding this correctly, the use-case for the provider is "Payor system accepts my transaction", and for the payor, it would be "My system receives the provider transaction and routes it to the appropriate application... based on the value in GS03". But there are potentially infinite # of sub-use-cases, all taking the form of: "I route the transaction to application X if GS03 value is Y".
I think where we are getting stuck here is that there are an unlimited # of unique conditions that might affect/determine internal routing on the payor end. William and others have mentioned the geographic location of the subscriber or provider, what sort of transaction it is, batch vs. real-time, etc. In some ways, I agree with William's assertion that Dr. Bob should only have to worry about getting his claim to the payor's designated "front door" and that expecting him to preconfigure the GS03 according to the companion guide, so as to route to the correct payor application is both unreasonable and burdensome. Not only that, but Dr. Bob will get it wrong half the time or just hardwire some default value in GS03 that does not trigger a rejection notice (the provider's definition of a "successful transmission"). So... how about a compromise in which we have the CPP specify GS03 values to accomplish internal routing on the receiver end, but based only on the two things we've talked about the most: the transaction # and the expected response time... i.e., using "expected response time" value to distinguish between a "real time" or "batch" paradigm. I would like to discourage burdening senders with other internal routing requirements, because i have a feeling that there will be too many such use-cases to codify. I'm not categorically opposed to "companion guides", provided there is at least a theoretical way to eventually machine-code the information so that a system could (some day) auto-configure itself by reading the companion guide... that it found by querying the CPP. BTW, I do appreciate the periodic reality-checks from Bob and Kepa and others about what payors are expecting/demanding today. I suspect that the less flexible payor systems will be getting their claims via a CH who has learned EXACTLY how Mr. payor wants his "mail" sorted and stacked. Once the CPP specification is stable, however, payors may consider opening up to any sender whose system is conversant with the CPP. Regards, Chris At 10:40 AM 8/13/2002 -0500, Rachel Foerster wrote: >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. Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268 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.
