Judging from our conversations over the last few months, it seems folks have a "problem" finding out how to exchange EDI transactions with their partners without burdensome and manual processes. If that's not a problem - i.e., either the processes are not that manual or burdensome, or just not worth fixing considering the exigencies of other HIPAA issues - then there's no need to devise requirements for a solution to an imaginary problem. And if there's no problem to solve, then there's certainly no need to deliver a solution "within any acceptable timeframe."
I did get a message the other day from a gentleman at a Blue who wrote: "Why, as a payer, am I going to go looking for a provider to send me anything? Those with whom I have a working relationship, such as I have certified their credentials, entered into a participation contract or HMO agreement and distributed my EDI requirements documentation, are already going to know who what and how." This is a fair question. At this juncture, he obviously doesn't see a problem needing to be solved - his (presumably manual) EDI enrollment processes are apparently sufficient. On the other hand, if I understood Marcallee Jackson (who stands on the other side of the fence) earlier, she views these same manual processes for enrolling providers as onerous and expensive - something she'd like to see automated. At this point, we may have the payers agreeing with my correspondent, and the providers (and perhaps even the clearinghouses) agreeing with Marcallee. The HIPAA law, as I understand it, may tip the scales in favor of Marcallee's view when we consider the oft-discussed clauses barring discriminatory barriers to using the standard transactions. I shouldn't have to jump through metaphysical hoops here. Either manual EDI enrollment processes are a problem, or they aren't. If they are, I believe that an open standard based on a Registry of electronic partner profiles is an effective technical solution worth pursuing by the WEDI/SNIP ID & Routing SIG. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Rachel Foerster" <[EMAIL PROTECTED]> To: "'WEDi/SNIP ID & Routing'" <[EMAIL PROTECTED]> Sent: Saturday, 11 May, 2002 11:17 AM Subject: RE: CPP Data elements draft for comment William, What you've listed below are a bunch of questions, not clearly defined problem statements for which specific requirements can be developed to solve the problem. Any resultant work product must then have clear specifications traceable back to each requirements statement such that the complete work product then satisfies the requirements and solves the problem. And firstly, the targeted user of the final work product must agree that the problem is both accurately defined and one that they want solved. Without these prerequisites, any work effort is not going to deliver anything the user or the marketplace wants, needs, or will accept. And lastly, without such a roadmap, it's impossible to manage/lead a project that achieves the goal of the project to any successful conclusion within any acceptable timeframe. Rachel Foerster Principal Rachel Foerster & Associates, Ltd. Professionals in EDI & Electronic Commerce 39432 North Avenue Beach Park, IL 60099 Phone: 847-872-8070 Fax: 847-872-6860 http://www.rfa-edi.com -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 09, 2002 5:24 PM To: WEDi/SNIP ID & Routing Subject: Re: CPP Data elements draft for comment Rachel: I'm sorry, I misunderstood. I kept seeing "software developers," or their pronoun, in your response to Michael Mattias. I thought you were talking about software development. Anyway, plenty of problems have been discussed in the last few months. And for the benefit of new folks who have subscribed recently, I'll list a few that come to mind: (1) How would a provider know where to even send a standard transaction to whatever entity handles them on behalf of the plan or payer? (2) A payer might have multiple "portals" for different types of transactions (say, "real-time" vs. batch) - how does he convey that to any provider who might want to send standard transactions? (3) How does a payer know whether a provider even supports EDI in the first place? (4) Assuming a provider *does* EDI, how would a payer know that a particular provider supports particular transactions (e.g, an 835 EOB - there's nothing in the 837 which says 835s are expected in return). Where would the payer send the transactions? (5) How would a payer or provider tell trading partners the communication protocols he supports? If he's using some of dial-up system, how does he convey logon IDs and passwords? Where does his X.509 digital ID public key reside? (6) How does a payer say what his requirements are for ISA and GS fields? How can he tell the provider that he can't handle more than 5000 claims in an individual 837? (7) How does someone report errors beyond the standard TA1 and 997? Does he support the 824? Or e-mail? - if so, what e-mail address should be used for sending error messages? You can add "or his agent" (such as a Clearinghouse, repricer or Third Party Administrator) to "provider" or "payer" above. This list certainly isn't exhaustive - I'm not the keenest when it comes to keeping crap organized, and Microsoft Project would only confuse me. Any of these problems can be solved the old fashioned way: through telephone calls, e-mail and paper TPAs. They can sometimes be delegated to one's Clearinghouse. On the other hand, if we agree that paper TPAs, paper "Companion" documents and lots of e-mail and phone tag are undesirable, we might ask if any or all of these problems can be solved in an automated fashion. Or - along the road to complete automation of EDI enrollment - can this information be advertised somehow where partners know where to look? Can it be expressed in a mechanical fashion for consistency and rudimentary automation? Do you agree that these are problems at least some payers and providers would like to see resolved? If any of these struck a chord, then our proposed solution - which entails recommendations based on the open ebXML CPP (electronic Partner Profile) and Registry specifications - seems to satisfy many of the requirements posed by the problems. Do you have alternative solutions? Are these problems so critical to solve that a solution has to be in place by April 2003? If these aren't problems at all and we've overlooked something obvious, let us know - we can wrap this up more quickly as I'm sure most of us are not interested in self-perpetuating standards projects. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320
