I've been silent for a while, but this has caught my attention, again. Let's step back from the payer issue just a little. As a provider, I can probably address three or four direct connects in any state and deal with 80% plus of my claims volume. For the lower volume, infrequent connect payers, I can find a clearinghouse, probably no more than one or two, to address the remainder. I don't have an overwhelming burden in ensuring the efficient flow of claims, encounters, eligibility, status and other tasks. I have some issues dealing with reporting, but that's not a part of routing. Many vendors are actively developing solutions to remove these addressing burdens from the provider in the payment arena.
Where my problem comes in is in the grand scheme of public health, where information I have related to a patient is effectively shared electronically with the potential thousands of specialists and others that will allow health care to be improved. I believe I understood that the objective was to reduce costs and improve health care. If I am looking for a good way to do automation, I don't think that provider to payer is the primary model. Look at provider to provider. A workable means of exchanging this type of data in a wholly automated fashion would indeed be a long term boon to the overall care of health. ------------------( Forwarded letter 1 follows )-------------------- Date: Tue, 13 Aug 2002 16:04:41 -0700 To: Michael.Mattias/Tal.Systems[mmattias]@talsystems.com.comp, [EMAIL PROTECTED], WEDI/SNIP.Listserve[routing]@wedi.org.comp From: OD.ChristopherJ.Feahr[chris]@optiserv.com.comp Sender: [EMAIL PROTECTED] Subject: Re: Project Overview draft Michael, Thanks for the vote of confidence. As I imagine all the possibilities for an external EDI control structure (for 300,000 EDI neophytes with brand new computer systems) I cannot visualize it without this CPP component. I'm VERY glad that we are also retaining the vision of "auto configuration" and designing the CPP with that theoretical possibility in mind. We really need to have "machine readable" and "auto-configurable" in mind, as we conceive of the standard "distribution" formats for the companion guide and even the basic IG. AUTO... AUTO... AUTO! -Chris At 08:16 AM 8/13/2002 -0500, Michael Mattias/Tal Systems wrote: >8/12/02 > >As idealistic as it surely is, and as jaded as I became about "paperless >business absent a TPA" in the early EDI days, I am not so >sure a CPP for the healthcare industry is pie in the sky for one reason: >volume. > >Unsolicited and TPA-less Electronic Business never took off for one >reason: every player used his own implementation. But even the >364-kilogram simians like Walmart, Ford Motor and Medicare were only >mandating implementations to at most two or three thousand >partners. Regardless of what one thinks of the HIPAA mandates, we will now >have some 360,000 possible partners using the same >implementation rules. > >Surely if the underlying business transactions can be put into a standard >implementation, so then can the communications and routing >parameters - which are far, far, simpler. > >Biggest obstacle? Hands down, it's inertia: the tendency of anything to >remain in its current state; and the bigger the object >(i.e., entities the size of payers), the greater the inertial forces. > >FWIW, I am fnally getting back to an analysis of the CPP, and so far - >viewed as an applications developer - it looks as though >almost all the info I would need to create applications software for Suzy >Provider is pretty much in place. For these 360,000 Suzys, >that means... > >"I got this patient's insurance card. I want to send his payer a claim. I >only want to enter this one magic number (e.g., UPIN, >NAIC, whatever) from the card and let my software handle all that ID and >routing stuff." > >If it isn't this easy, ten bucks says Suzy never even makes the effort to >'go electronic' - she just puts a HCFA-1500 form in the >typewriter and reaches for a postage stamp. (You younger folks can find >'typewriter' in any good dictionary). > >Now the software may come back and say, "Sorry, Suzy, but that payer is >not yet accepting electronic claims, so put a HCFA-1500 form >in the typewriter and reach for a postage stamp" - but if *one entry* by >Suzy can tell her this, she will make that one entry each >time. > >And maintenance? For the payers, maintaining their own CPP entry is just >plain smart business - if you assume processing claims >electronically is less expensive than processing paper claims. > > >Michael Mattias >Tal Systems, Inc. >Racine WI >[EMAIL PROTECTED] > >----- Original Message ----- >From: "Martin Scholl" <[EMAIL PROTECTED]> >To: "William J. Kammerer" <[EMAIL PROTECTED]>; "WEDi/SNIP ID & >Routing" <[EMAIL PROTECTED]> >Sent: Tuesday, August 06, 2002 11:15 AM >Subject: RE: Project Overview draft > > > > > > My problem with the CPP is that it is a pie in sky. Yes, I can see that it > > is cute to have an XML exchange that returns all the parameters for a > > trading partner relationship, but I can as well call and have them fax > me or > > email me a fact sheet on trading relationships. I don't believe there will > > be automated and instant trading partner relationships without testing and > > certification for a while. > > > > I would like to hear which modes of routing others in this group are using > > or planning to use. > > > > > > >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. 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.
