RE: 276 routing question, esp. interested in Clearinghouse guru's opinion
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 TCS 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.
RE: 276 routing question, esp. interested in Clearinghouse guru's opinion
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
RE: 276 routing question, esp. interested in Clearinghouse guru's opinion
Chris, It appears to me that you may not have a clear conception/understanding of what a use case is. Thus, I'm inserting here some explanations that are incorporated into the UN/CEFACT UMM as well as ebXML. Use case analysis is very commonly used today by all major software developers. What Is a Use Case? Rational Unified Process defines a use case as a set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor. In other words A use case is a single task, performed by the end user of a system that has some useful outcome -Allen Holub IBM An article by Kurt Bittner from Rational describes a use case as simply a story about some way of using a system to do something useful. Why do we use them? Use cases give a clear picture of what a system is going to do and how large or small it is going to be Can be used for documenting business process or system process Can be used to identify present state or future state Developing the Use Case Model Composed of two parts: Use Case Diagrams Use Cases shown through UML representation including the relation Use Case Survey Brief description of what each use case does What Is a Use Case? A use case defines a sequence of actions performed by a system that yields an observable result of value to an actor. Benefits of Use Cases Give context for requirements Are easy to understand Facilitate agreement with customers Illustrate why the system is needed Use cases: why the system is used Actors: who/what wants to interact with the system The idea behind use cases is to decide what the system will be used for before defining what the system is supposed to do. Identifying Use Cases In General: What are the major areas of functionality? How can they be divided up in a way that makes sense? What value do the actors expect? The above was extracted from the Requirements Management Educational Sesson sponsored by X12N at the Minneapolis X12 Trimester meeting. The full workshop material can be downloaded from X12 web site at www.x12.org. Drill down to the X12N pages and then follow the links to the download documents. The first one listed, Introduction to Requirements Management Using the UN/CEFACT Unified Modeling Methodology, is the one I'm referring to. Rachel Foerster -Original Message- From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 13, 2002 5:45 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: 276 routing question, esp. interested in Clearinghouse guru's opinion 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
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 TCS 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.
RE: 276 routing question, esp. interested in Clearinghouse guru's opinion
This is what the X12 standards defines this data element to be: GS02 142 Application Senders Code Code identifying party sending transmission; codes agreed to by trading partners TYPE= AN MIN=2 MAX= 15 MANAGEMENT DATA ELEMENT - NOT INTENDED TO CONVEY DATA TO AN APPLICATION GS03 124 Application Receivers Code Code identifying party receiving transmission. Codes agreed to by trading partners TYPE= AN MIN=2 MAX= 15 MANAGEMENT DATA ELEMENT - NOT INTENDED TO CONVEY DATA TO AN APPLICATION Note that the standards are silent on which party assigns the code and indicate only that the trading partners agree on the codes to be used. Rachel Foerster -Original Message- From: Hipaa Guru Jr. [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 5:38 PM To: [EMAIL PROTECTED] Subject: Fw: 276 routing question, esp. interested in Clearinghouse guru's opinion I believe I have interpreted the use of GS02 and GS03 in a different way. The IGs state that these data elements are to be used to identify the party sending/receiving the transmission. And that these codes are agreed to by the trading partners. I took this to mean that party 'A' (the Clearinghouse, Provider, etc.) would assign party 'B' (Payer) a unique ID and that party 'B' would assign party 'A' a unique ID (Note: by Unique ID I mean unique within the assigning party's system). These ID's would be exchanged when the Trading Partner agreement is established. Then if there was a need to differentiate transmissions sent using the same ISA ID (Fed. ID Nbr) but from different offices, departments, etc.; they would request to be assigned an additional ID for that use. From the prior posts, it would appear that my view of the use of the GS02/03 elements is way off. Any thoughts on my interpretation are welcomed. Keith Reichert Senior Software Developer Premier Data Software Inc. - Original Message - From: William J. Kammerer [EMAIL PROTECTED] To: WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Tuesday, August 06, 2002 7:12 PM Subject: Re: 276 routing question, esp. interested in Clearinghouse guru's opinion Though I'm sympathetic to Michael's subtle hint that ISA receiver IDs not be used to route interchanges among different internal application systems, I think we can accommodate Rachel's suggestion. Once the CPP for the receiver has been located (using some unique ID from one of any number of domains), it will be possible to specify what is to appear in the ISA (or GS) receiver IDs depending on the particular Delivery Channel selected. The receiver has every right to specify what goes in the GS receiver ID. And with no more effort on our part, we can likewise give her the capability to demand a particular ISA receiver ID (and qualifier). The converse is neither possible nor desirable: the receiver has no business - nor means within the CPP - to tell the sender what to use as his ISA or GS sender codes. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Michael Mattias/Tal Systems [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, 06 August, 2002 08:27 PM Subject: Re: 276 routing question, esp. interested in Clearinghouse guru's opinion - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 06, 2002 5:36 PM Subject: RE: 276 routing question, esp. interested in Clearinghouse guru's opinion Freida, There are a couple of other mechanisms that can be used by a payer to route the various HIPAA transactions to the correct internal application system. 1. The payer could elect to use a different ISA Receiver ID 2. The payer could elect to use a different GS Receiver Code Not the ISA ID!!! Do not do that! Bad, Bad Idea! OTOH, the GS ID was designed EXACTLY for this purpose - to identify the correct applications party within the destination defined by the Communications (ISA-IEA) envelope. Also, changing the ISA ID means THIS LISTSERVER GROUP would need to allow for (are you ready for this?) 'multiple unique identifiers and senders (providers) would have to look up different entries/establish separate payer master records for different claim types supported by a payer. (You want to imagine where that might go?) Let's nip this additional ISA ID idea in the bud! MCM 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
