I've had a few brief moments to read Kepa's message and self-correction, Peter Barry's white paper about Managed Legal Relief, the WEDI Board letter to HHS and the AHA letter.
Unfortunately, in my opinion, all of these papers and documents totally miss the mark. What they propose is the equivalent of a bandaid on a open artery....this is treating the symptoms and not the illness. Total Quality Management principles dictate that a root cause analysis must be performed before one can correct an error. My opinion is that the root cause problem is the attempt by federal fiat to foist upon the healthcare industry the use of technology standards for EDI that are too complex, too cumbersome, too abstract, and too costly to implement. Other industries discovered this a decade and a half before healthcare and while not abandoning their current EDI infrastructure, are focusing and allocating their resources for new IT and electronic business messaging development into new technologies, such as XML, web services, and the internet...in other words, they are living in the 21st century. Healthcare will never fully implement or transition to these HIPAA EDI standards....they don't work for the small organization and they never will. It's high time that healthcare and the "powers that be" in Washington and elsewhere recognize this fact and begin to change the paradigm in which they currently live. Rachel Foerster Chief Executive Officer Rachel Foerster & Associates, Ltd. Ideas - Promotion - Innovation Voice: 847-872-8070 email: [EMAIL PROTECTED] http://www.rfa-edi.com -----Original Message----- From: Christopher Feahr [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 9:01 PM To: Rachel Foerster; WEDI SNIP Transactions Workgroup List Subject: Re: TCS market forces will cause convergent HIPAA compliance (essay) Dear Kepa, I certainly appreciate your efforts to identify a workable compromise position regarding "compliance". But I am afraid that it presumes a far greater willingness to support (or even try to implement) the standard than providers have thus far demonstrated. Most providers who are not simply dropping to paper or using DDE this Fall, will likely believe that they have pushed their compliance, testing, and certification problems on to their CHs... in which case, they may not even be privy to the specific nature of the problem that triggers each claim rejection. Even if they have managed to create a standard claim, I doubt they will have the patience... or that it will even occur to them to have the patience... to wait for the system to "self-correct" as you have described. Billing managers in most practices have been conditioned by decades of tweak-and-resubmit strategies... persisting until they finally get the payments flowing with a troublesome payer. A couple weeks ago, I made a valiant effort to actually speak with a live human in the EDI department of about 8 Medicare regional carriers around the country. I had originally intended to call them all up to inquire about the status of their "free billing software" for small providers... but I gave up after 8. Of the 8, I only ended up speaking with two live humans (who knew what EDI was) after several days of phone-tag. My point is that a provider who is determined to chase down every payer he believes is incorrectly denying his compliant claims would be looking at a significant expense to do that. And when the dust settles, who is most likely going to end up reprogramming his system... the "right" provider or the "wrong" payer? I agree that provider's voluntary adaptation to non-standard payer requirements is self-defeating (not to mention, technically illegal). You are absolutely correct that it will inhibit standardization over the long haul. But that's what's going to happen, because attempting to correct a payer and/or file a complaint with CMS would be MUCH more expensive for the provider than simply accommodating a payer's quirky needs. Here's the larger problem, in my humble opinion: Payers (like all normal, healthy Gorillas) have special needs and wants that their non-Gorilla trading partners SHALL meet. That's why every business in America wants to be a Gorilla when it grows up... because life is smoother for you when you get to make all your trading partner rules. So that will never... let me repeat, NEVER... change. It may as well be an amendment to the U.S. Constitution. Therefore, the standard for B2B collaboration in healthcare MUST permit unique trading partner requirements... which pretty much rules out EDI as a candidate for a standard for 500,000 providers. EDI is fine for Gorillas talking to other Gorillas. All the Gorillas show up in the Standards Tent 3 times a year and duke it out in a very EVENLY BALANCED and consensus-driven discussion, and everybody goes home [reasonably] happy. That has worked well for 30 years. We need something different now if Gorillas want to talk to Little People in a way that saves BOTH of them $. All the Gorilla-world has been able to come up with so far is DDE... which looks very efficient on the Gorilla end, but is even MORE labor-intensive than paper on the Little Person end. Let's PLEASE stop this EDI foolishness, folks. It will not work in healthcare if the point is to save money. We need ebXML and Web Services type solutions to allow Little People to communicate with Gorillas (or anyone) in a cost-effective manner. Either that, or let's bid a fond farewell to the small practice business model in healthcare. Best regards, -Chris Christopher J. Feahr, O.D. Optiserv Consulting (Vision Industry) Office: (707) 579-4984 Cell: (707) 529-2268 http://Optiserv.com http://VisionDataStandard.org ----- Original Message ----- From: "Rachel Foerster" <[EMAIL PROTECTED]> To: "WEDI SNIP Transactions Workgroup List" <[EMAIL PROTECTED]> Sent: Saturday, May 17, 2003 12:31 PM Subject: RE: TCS market forces will cause convergent HIPAA compliance (essay) Kepa, in general, I am in complete agreement with your concept of the "self-correcting" forces that will come into play here. On the other hand, my concern is how quickly those self-correcting forces will begin to change behaviors - and most importantly, bring about the systems changes needed - so that neither the provider nor the payer suffers substantial negative economic consequences....for example, rejected/denied claims and negative cash flow for providers, and/or increased fines for failure to comply with prompt pay requirements by the various states. So, I think the train wreck is still going to happen....the only unknown is how long it will take to clean up the wreckage. Rachel Foerster Chief Executive Officer Rachel Foerster & Associates, Ltd. Ideas - Promotion - Innovation 39432 North Avenue Beach Park, IL 60099 Voice: 847-872-8070 email: [EMAIL PROTECTED] http://www.rfa-edi.com -----Original Message----- From: Kepa Zubeldia [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 13, 2003 5:44 PM To: WEDI SNIP Transactions Workgroup List Subject: TCS market forces will cause convergent HIPAA compliance (essay) Part 3 of 3 parts. This is another "essay". The focus of this one is specifically on how I believe the HIPAA covered entities will use their resources to make sure their business is not disrupted much by this potentially very disruptive transition. Sorry about the extended time lapse between the previous piece and this one. I was busy with something of much higher priority than HIPAA. Both mother and baby are doing great, although we are all sleep deprived :-) So you have read my previous pieces, right? I have talked about issues related to testing for transaction compliance versus testing prior to production versus testing the production stream. I have also discussed how each covered entity should make their own assessment of where they stand before engaging the trading partners, and make their own decision on what to do. The second piece discussed the definition of healthcare claim versus an 837TS that can contain multiple claims, and how it is improper to reject an entire batch just because a single claim in the batch is bad. So, let me build on these concepts. Again, let me say that I am not a lawyer, and I am speaking from personal experience. Since you probably have different experience than mine, your mileage may vary. This is NOT legal advice of any sort. If you want legal advice don't ask me, ask your lawyer. In the previous essays some people thought I was harsh to providers. I am sure some will think I am harsh to payers in this one. Oh, well, I can't please everybody all the time. Currently the industry operates with an imperfect system, and does so rather well. For instance, the auto-adjudication rate of most payers run somewhere between 40-60-80 percent, depending on the payer and the type of claim. The front-end error rate runs around 2-5% and the quality of paper claims is worse than electronic claims, even when produced by a computer. Yet, even though these errors introduce some inefficiency, we have all learned to live with it. We would like it to be better, but it is good enough for now. One of the expectations of HIPAA back in 1996 was that by going to a standard transaction, the quality of the transactions will improve, the number of front-end errors will decrease, the auto adjudication rate will increase, and the administrative costs will decrease. This is great. However, seven years later, when we are about to really try this out, the fear is that the reality could be very different from the original predictions. And thus more and more people are getting scared. In fact, some want to throw in the figurative towel instead of keep fighting for it. While we would like to see the numbers improve, we are not ready, in fact cannot allow, for the numbers to get worse than they are today. There is not enough "fat" in the system to take a big "hit" in the rate of electronic claims or the auto adjudication rate. Converting back to paper transactions is totally out of the question and would cause the system to collapse. Don't fear, I am confident it is not going to happen, and let me explain why. I firmly believe that the covered entities, payers, providers, clearinghouses, and even the non-covered entities such as vendors and consultants, have in general become aware that there may be a problem with the transactions. In fact people are starting to realize that this, perhaps, could be THEIR problem rather than their trading partner's problem. Maybe they can even do something about it? If a payer has chosen the "heroic" route of "rigorous" transaction compliance testing in their EDI front-end (rejecting anything that is presented to their door not in perfect conformance to the HIPAA guides), it will not take them long to realize that they are hurting themselves. Are they rejecting the claims because they are coming in with punctuation in the SSN and the payer does not want punctuation? Are they rejecting the claims because they come with a 4 digit revenue code (with a leading zero, as NUBC says it should be) and the payer wants to see only 3 digits in the revenue code? It does not take a rocket scientist to see that the payer will, without intervention from the HIPAA police, have to change its front-end edits to be more accommodating of the data coming in. What choice does the payer have but to be more accommodating? After all, it is relatively simple to make these programming changes in the translator. If the payer heroically persists on maintaining all those "rigorous" edits, the immediate result will be a reduction of the EDI volume, followed by an increase in paper. After all, the providers want to get paid, so they will do whatever it takes to get paid by that payer. And the payer will have nobody else to blame for the reduction in EDI volume but itself -- a self-inflicted problem. Not likely to happen. As soon as the payers see that they are, by their own self-inflicted choice, rejecting a substantial amount of claims, they will hurry and "relax" their own "rigorous" edits, before the ill conceived "rigorous" edits cause the payer to go into "rigor mortis" (sorry, I could not resist the pun). However, if it is only one specific provider's claims that are being rejected by the payer, the payer will advise the provider to get their act together (the provider probably already knows about the problem) and if the provider is a very large provider for that payer, the payer may try to accommodate that provider somehow even if this means some sort of temporary "relief" for that provider. Perhaps even softening some of the rigorous edits for that provider for a while. On the provider's end, the situation will be very similar. If during the testing with a variety of payers, or with its clearinghouse, the provider sees that too many of the claims are being rejected... It does not matter who is to blame. Is it the vendor, clearinghouse, payer, or provider? Who cares! The provider will do whatever it takes to get paid. Does that mean that the Taxonomy code must be sent in all claims? Does it mean that the Revenue Code needs to be sent with 4 digits? "Tell me what I need to do, and I will do it." seems to be the prevailing attitude. In fact, right now, this is being taken to an extreme, and that needs to be corrected (see below). But, in general, as soon as the providers start testing the HIPAA transactions, the feedback, and the potential impact on the revenue, will be such that the providers will adjust their system, their office procedures, their data collection process, anything within their control, to improve the quality of the data they are producing and to increase the likelihood of the claims being paid. If this means getting a software update, getting a consultant, designing new super-bills, using a clearinghouse to "supplement" and correct the data, JUST DO IT. We are going to see an increase in the amount and quality of "data supplements" fed into the provider's data stream by the clearinghouses. Of course under the direction of the providers to their clearinghouses. For example, the provider will instruct the clearinghouse to "supplement" the data with a taxonomy code, with a Payer ID, with the corrected ZIP code, with whatever is necessary to make the transaction work. Of course the clearinghouses cannot create data out of the blue sky, and the provider still has the responsibility to produce the data in the first place. But we are seeing more and more clearinghouses using these data "supplements", at the request of the providers, to improve the data quality of their customers. These vitamin injections fortify the data to make it compliant. It is happening today, and the results are sometimes spectacular. It will happen even more in the months to come. So, this is the self-adjusting effect of HIPAA transaction compliance. If I am a payer and my front-end system is too rigorous in its transaction edits, I will have to add the flexibility necessary before it kills me. If I am a provider and my data does not have the necessary quality, I will improve it, either myself, or contracting with someone that can do it for me. The tolerance for worsening the current situation is very low, so upon the early signs of worsening, the remediation actions will take place quickly. But this assumes two things: we can detect these problems before it is too late, and the remediation can be mostly generic rather than trading partner specific remediation. Early detection of the problems is crucial. If we wait until the deadline there will not be enough time or resources to correct the problems. This is why ASCA had the requirement to start testing in April rather than letting people delay their testing until the last minute. Testing with one trading partner does not achieve this early detection, as the results will be distorted by that trading partner. You either have to test with many trading partners to find the common recurrent errors (they are probably in your system if everybody is agreeing that it is an error) or you have to test with one of the third party testing systems that provides results equivalent to testing with multiple payers in one stop shopping. The remediation then needs to be applicable to all (or most) of your transactions. If we were to apply remediation steps that are trading-partner specific, we would fall into the very same trap of years past, with hundreds of different implementations of the same non-standard. Don't fall into that trap, unless you absolutely have no other choice and it is a self preservation measure for a short period of time. As a provider, if you run into a payer that is an offender and requires non-compliant transactions, rest assured that other providers will run into the same problem with that payer. That payer's transaction volume will plummet, and they will have to correct their own problem. Be patient, the system will self balance, and that payer will fall in line with the rest. As a payer, if a specific clearinghouse or provider insists on sending you non-standard transactions, they will have the same problem with other payers and eventually have to fix their system, or they will go out of business. The market pressures will cause the system to self-adjust and correct these outlier issues. The risk we run is that under the pressure to make things work without disrupting the cash flow, we may take the easy route and start making trading partner specific adjustments, without waiting for the system to self-adjust. When we make trading partner specific adjustments we are really hurting ourselves with the expectation of a short term gain. If you feel like you need to make trading partner specific adjustments, because payer X represents 40% of your business and you cannot afford not to accommodate their peculiar requirements, do yourself a favor: complain loudly to the payer, to the rest of the industry, to the Secretary. Put the pressure on that payer to come into alignment with the rest of the world. Sure, you still will make some trading partner specific adjustments, but it will not be long until that payer bows to the pressure and starts accepting standard transactions. The same applies to payers: if your largest providers or clearinghouses want you to accommodate their peculiar requirements, complain about it. Rest assured, you are not the only one facing that problem, and the problem, if enough trading partners complain, will be self-adjusting. So, how do we move along these lines? The first step is for you to know where you are. How many of your transactions are good and acceptable to most of your trading partners? How many of the transactions coming to your door are being rejected by your front end edits? Are these numbers acceptable to YOU, or can YOU do something to improve YOUR situation? Take some measurements from your error reports. Make some changes to your data quality or your front-end edits. Measure again. Did it improve? Is it where you want it to be? You control what your numbers are. Measure your own transaction compliance and fix whatever you need to fix to make it work for you. In this process you need to keep in mind that EDI is electronic data INTERCHANGE, rather than electronic data processing. For the last couple of decades we-have lived in a world of electronic data processing. When a payer published its proprietary edi data format, it was actually publishing its internal data structures. If the provider wanted to send transactions to that payer, the provider needed to prepare the data according to the payer's internal data structures. This was (and still is) mostly true even for the NSF and UB92 flat file formats. The result of this is that since the internal systems are somewhat different, the data sent by the providers need to accommodate these differences, and this produces a multitude of non standard formats that are very similar but different. Remember in the early '80s before de-regulation of the phone companies? The phone company owned and maintained the line all the way into my living room, including the phone set. The phone company decided the choices I had for phone sets, and I had to rent it from them. And if the line had a problem, they fixed it for me, all the way into my living room. With de-regulation I have more choices, I can buy my own phone, I can install as many phones as I want in my house, I have a choice of long distance companies, etc. The first noticeable difference was that the phone company installed an ugly "network interface" or "demarcation point" outside my house, and their service ends there. If I have a problem inside my house, I can either contract with the phone company to fix it or I can get my own electrician. If my phone set breaks up, I can get it fixed, or buy another one. It is now my responsibility. The responsibility of the phone company ends at the demarcation point outside my house. But, because the phone lines are standard, and the phone jacks are standard, and the dial tones are standard, I know that I can buy any standard phone and a standard extension cord and they will work. The same is true with EDI and particularly with X12. In the past the payer's internal formats were visible inside the provider's computer. Now the HIPAA transactions act as the demarcation point. The payers have to accept HIPAA transactions. The providers have to produce HIPAA transactions. There is a little wiggle room in those Implementation Guides, but as long as everyone uses the same standard, the transactions will work for all. It is when one trading partner wants to force its own internal structures into its other trading partners that the whole system breaks down. It may seem like it will work OK for that one trading partner in the short term, but the long term with multiple trading partners forcing non-standard requirements on each other, reality will show otherwise. Just remember this: These are electronic data INTERCHANGE standards. They are the demarcation point. Your authority extends to your end of the demarcation point and does NOT extend to the other side of the demarcation point. It is your responsibility to make sure the data you present to the demarcation point is compliant with the standard, and that you can receive from the demarcation point data that has been submitted in compliance with the standards by your trading partners. What happens inside your side of the demarcation point is your responsibility, what happens on the other side is not. If you cannot meet the standard you need to buy yourself an adapter plug (remember the old 4-prong plugs?) and it will cost you some money. Buy it and move on. Take home summary: - The system is not perfect today, yet we operate and understand imperfections. - A small temporary degradation of the system may be acceptable as part of the HIPAA transition, but it must be small and for a short time. - If your transactions have a problem, YOU must do something about it. - The "heroic" attempts to "rigorous" transaction compliance could end up hurting you more than your trading partners. This would be self-inflicted. You can do something about that. - You need to fix your system ahead of the deadline. If you need help, get it soon. Your clearinghouse or vendor may be able to help you. - Early detection, remediation, measured transaction compliance, are important steps. - Trading partner specific solutions will create further inefficiencies. Try to use trading partner neutral solutions instead. The outliers will come back in line in due time. - The HIPAA transactions are the "demarcation point" anything on your side of the demarcation point is YOUR responsibility. Anything on the other side is NOT your responsibility. Still trying to reduce friction... Kepa Zubeldia Claredi --- The WEDI SNIP listserv to which you are subscribed is not moderated. The 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org --- The WEDI SNIP listserv to which you are subscribed is not moderated. The 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org --- The WEDI SNIP listserv to which you are subscribed is not moderated. The 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org
