Hi Larry, I guess I was on a bit of a tear this morning... maybe it was that third espresso! I would have to agree with you that during this transitional period (however long it turns out to be) we would be wise to keep claims as identical as humanly possible... partly because the law requires it, but also because provider systems have nowhere near the ability to auto-configure themselves that my "Buck Rogers" scenario would require. I think "standards" will always be in a tug of war with the natural desire of businesses to do things "their way". So the more flexible the standard is and the more easily/automatically it can accommodate *certain types* of differences... the better. Companion guides represent that hard, almost standard-resistant layer. So I guess the point of this morning's rant was that eliminating it would be virtually impossible and not even necessarily desirable. In fact, IF there was a clean standard methodology for auto-implementing, it *might* even be OK to let that layer increase in size... a little. (I really don't want to see unique formats for every payor... I must have been temporarily insane!)
Regarding scope: Even if the details of auto-configuration belong in another discussion venue (and I agree)... would you agree that the CPP record is the logical place for a partner's system to [some day] look for the auto-config data elements? Or should we just put in a single field for the URL to the companion guide, and leave it there for now? Have a good evening, Chris At 05:41 PM 7/12/2002 -0400, Larry Watkins wrote: >Chris -- Wow! Since you're a provider, this REALLY surprises me. And, >again, I believe this is the wrong listserv to be discussing this. However, >I would think that you would care very much if there are lots of 'flavors' >of the claims standards. Why? Because ultimately the differences result in >complexity in the implementation of your systems (however automated this >complexity is), and complexity leads to difficult, error-prone, and >expensive implementation and maintenance, which leads to problems in getting >paid. Granted, some of this is automatable, but ultimately someone on your >staff has to understand the rules so that they can figure out where your A/R >is. It particularly surprises me that non-standard data content is >considered acceptable in an environment where a SINGLE standard must, by its >very nature, be so complex as a claim is. > >Don't get me wrong. I believe CG's are very important in this industry. >And, I think there should be a full discussion relating to how to automate >the information within CG's to simplify those things that must be unique >from trading partner to trading partner. This discussion should start, in >my view, at that level. Then, we can talk about the key elements within >CG's to link to within a CPP to link to so that addressing and routing (and >other things) can be automated out of the CG's. > >As for the 'flavors' issue, I still believe we can have a true standard with >flexibility where necessary, and that this data content can then be much >more efficiently automated to gain administrative simplification. Our major >obstacle has not been technology, but the lack of such standard data >content. > >Larry > > >-----Original Message----- >From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] >Sent: Friday, July 12, 2002 1:10 PM >To: 'WEDi/SNIP ID & Routing' >Subject: RE: CPP and COB [and companion guides] > > >While the mission of this group is superficially about how to "find and >connect with" partners, our discussion has consistently included >consideration of how to "find, connect, and do business with" a >partner. If the CPP will be the primary source of information about this, >then it will definitely need to include or point to the details of various >supported COB arrangements and any important "companion guide" info. To >me, this seems no less critical than information about which transactions >are supported, real-time vs. batch mode support, what sort of testing >certification is required, etc. > >In "phase one" we want to at least identify all the CPP elements, but I >think it's safe to assume that none of them will be machine-understandable >in the first version. In the context of this workgroup, I would suggest >that the "legality" of a companion guide element is irrelevant because all >CG or IG elements are simply instructions. The goal of the CPP is to >convey those and all other relevant instructions to the sender system. At >the moment both "guides" are published exclusively in human readable form >and everyone already has a copy of (or knows where to find) one of them, so >only the supplemental CG instructions need to be referenced in the CPP. > >I'm not sure if anyone is currently working on a methodology for reducing >all X12 IG instructions (whether the "real" or the "companion" variety) to >a universal, machine readable XML format... but this would be a terrific >idea. When IGs are machine-readable by compliant EDI manager applications, >the maintainers of the CPP standard may wish to consider supplementing the >pointer to the .pdf version of the CG with a group of XML instructions for >auto-implementation of the CG instructions. > >SIDE BAR: There seems to be a general feeling today that CGs are "bad" >because they move us away from "true standardization"... i.e., that CGs >essentially spawn different "flavors" of the standard, leading to a world >that looks like the one we are trying to get away from. As a provider, >however (and I can't imagine that payors would feel differently) I could >care less if there 100 or 1000 "flavors" of the "837-P"... or even a unique >one for every payor... provided there was an EASY/CHEAP/AUTOMATIC means for >my system to discover and implement these business requirements. The >requirements, themselves, do not have to be identical... only the method >for implementing them. Same goes for the main IGs coming out of the X12 >workgroups. As long as my billing system can suck new IGs in as easily as >QuickBooks gobbles down and installs its updates every few weeks, then I >could care less how complex they are or how may variants are supported. > >Payor-payor COB and companion guides might be examples of trading partner >business requirements that are not fully fleshed out and agreed upon at the >moment... in which case, the CPP should at least include a place-holder >element to let the world know that we consider the CPP to be the ultimate >home for this information. > >Regards, >Chris > > > >At 10:21 AM 7/8/2002 -0400, Fody, Kenneth W. wrote: > >Larry, William, et al -- > > > >I would agree with Larry's point with regard to COB on both aspects. > > > >First, for a payer to accept a COB transaction from either a provider or > >another payer, there will have to be some type of agreement in place >between > >the sender and receiver -- the same way there is with any other >transaction. > >This is particularly true if a Payer is truly hoping to use EDI to simplify > >and improve their COB process, because real improvement requires a lot more > >work than just taking in an 837. > > > >Second, I agree with Larry that CPP is valuable in this context and I would > >offer a some details on why that is true. Independence Blue Cross and >Aetna > >are the two biggest players in the tri-state Philadelphia area (e.g. > >PA/southern NJ/DE). Lets say we decided to collaborate on COB. > > > >If you look behind the curtain, you'll see Aetna is not just one company. > >Rather Aetna is a lot of different HMOs -- probably at least one for every > >state in which they do business -- and some insurance companies all trading > >under the name Aetna. > > > >And the same is true for us, albeit not on as grand a scale. We do >business > >in just three states, but we have six different entities underwriting > >coverage and a TPA. All of these use the same entry point for electronic > >transactions. > > > >So, as you can see, when two carriers get together to do COB, Larry is > >correct when he says it is not just a connect and send type of arrangement. > >There clearly is a fair amount of routing that has to take place, which > >depends on one party correctly identifying the other carrier to whom they > >are sending the transaction. > > > >As Larry said, anything that makes that process easier is a good thing. > > > >Ken Fody > >Independence Blue Cross > > > >-----Original Message----- > >From: Larry Watkins [mailto:[EMAIL PROTECTED]] > >Sent: Saturday, July 06, 2002 11:34 AM > >To: William J. Kammerer; 'WEDi/SNIP ID & Routing' > >Subject: RE: CPP and COB, was The use of Supplemental IG's > > > > > >William, et al -- > > > >There are 2 issues I'd like to weigh in on: > > > >1) While you (via Kepa) make a valid point that payer-to-payer COB will not > >necessarily always mean a separate trading partner agreement, the fact is > >that real business payer-to-payer almost certainly does have such > >contracts/agreements. Remember the complex business arrangement implicit >in > >payer-to-payer COB. It's not just a simple connect-and-send type > >arrangement, and is not treated as such today. And, where such agreements > >exist, HIPAA mandates that the standard be used. Regardless, it seems to >me > >that any CPP solution that is to help with COB relationships would need to > >support TPA's. We can work towards automation in this regard within the > >industry, but that will take time. > > > >2) It seems clear to me that the discussion relating to Companion Documents > >most certainly does belong outside of the Addressing/Routing group. There > >are a multitude of issues related to this topic, and it warrants its own > >discussion. I believe the Transactions WG is already considering how to > >proceed with this issue (SIG, white paper, etc.). As this discussion / >work > >ensues, clearly the Addressing/Routing group needs to coordinate with that > >work, taking into account recommendations coming out of such discussions. > >However, this group needs to keep the focus narrow enough to accomplish its > >objectives. Issues like the Companion Documents can easily bog your group > >down, since they have their own multitude of complexities and rabbit >trails. > > > >Larry > > > > > >CONFIDENTIALITY NOTICE: This E-Mail is intended only for the > >use of the individual or entity to which it is addressed and > >may contain information that is privileged, confidential and > >exempt from disclosure under applicable law. > >If you have received this communication in error, please > >do not distribute and delete the original message. > >Please notify the sender by E-Mail at the address shown. > >Thank you for your compliance. > > > >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. 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.
