For a provider who bills electronically today using an NSF or print image format, where's the ROI on claims? If a provider sends 70% of its claims electronically today, where's the ROI on the 837? How does the provider benefit financially from collecting data that is not needed for adjudication so that they can send it to a payer who is going to strip it out in order to adjudicate the claim? If the single most important goal of HIPAA was to save money by implementing a standard claim, I think they missed the mark.
Most of the folks on this list come from organizations that have pretty deep pockets compared to a provider. When you come from a firm that charges more per billable hour than some providers do, it's probably pretty hard to relate to how the cost of say $50K could seem like such a big deal. Is it 50K? Well, if you hope to implement the transactions that would come with a return on the investment in probably is. I haven't seen a lot of the 10K PMS systems supporting claims, ERA, claim status and eligibility transactions which is about the only place we see a HIPAA ROI. Vendors who have 10K solutions that support all HIPAA standards, please correct me and I'll be sure to add you to a referral list. Now not only do we have the HIPAA police but we have the HCCO police. Lions and tigers and fines - oh my ;)! -----Original Message----- From: Julie Thompson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 8:14 PM To: WEDI SNIP Testing Subworkgroup List Subject: Re: Does one bad transaction spoil the whole transaction set? Kepa: The allowance (90%-98%) or error tolerance is exactly what QA standards are designed to measure. There is a real difference from deviating from the standard and occasionally producing an error. This is where HCCO will excel, in educating or assisting the industry in how that acceptance level is determined and what that level should be. HHS is unlikely to engage is such details, they are only concerned with compliance with the standard. If we deviate from the HIPAA standards, then we may as well not implement the new ones. Remember, there are 400 versions of the NSF format being used today. We may end up with a lot more than 400 different 837s, if we do NOT stick with the implementation guides. I am not demanding perfection, I am requesting the industry to focus on the single most important goal of the HIPAA legislation ***saving money by using a single standard***. Yes, the standard is far from being completed, but it will work for a huge majority of claims, and can be used as it stands today. Sometimes, we just have to think a little harder or work a little longer to make them work, but the transactions are doable. There have been a few consistent number of voices trying to avoid implementing the HIPAA Compliant versions. This is a more than a tremendous disservice to our industry, it is sabatoge and distructive. (Sorry, for the strong words here, but enough is enough) How do I say this nicely....Quite whining and get the job done. A trading partner will never have a problem with other trading partners as long as they remain HIPAA compliant (not X12 only). Those who want to save **HUGE AMOUNTS OF MONEY** in their IT budgets will adhere to the HIPAA* standard and insist their trading partners do the same. An avenue for complaints against non-compliant tryants has been established by CMS. HCCO will provide a public venue for those who insist on participating with non-compliant transactions. LET'S BE CAREFUL OUT THERE :-)) Julie A. Thompson From: Kepa Zubeldia <[EMAIL PROTECTED]> Reply-To: "WEDI SNIP Testing Subworkgroup List" <[EMAIL PROTECTED]> To: "WEDI SNIP Testing Subworkgroup List" <[EMAIL PROTECTED]> Subject: Re: Does one bad transaction spoil the whole transaction set? Date: Wed, 4 Dec 2002 20:15:10 -0700 Marcallee, So, what is the target "compliance" point? Given than the "all or nothing" approach is probably not a practical one, what should constitute "good enough" for HIPAA transactions sets? As an industry we currently operate around an average of 95% good claims coming out of the provider's system. In some cases it is higher, but that is unusual. What will be the goal under HIPAA? The same 95% good? Can a provider that sends 90% good claims say that is good enough? How about WEDI recommending a "good enough" threshold or series of thresholds (improving every 6 months?) for HIPAA compliance targets? Right now, if we look for 100% perfection, probably nobody passes. But if we look for only 50% good claims per file, is that good enough? What is the magic number? Should we hold a poll? To the payers in the room I would ask the question: "Under HIPAA, what is your expected percentage of bad claims that will be acceptable in a transaction set (837) before the entire transaction set (837) is rejected for insufficient data quality?" If the answer is higher than 0%, something like 5-25% then there is hope. If the answer is 0%, meaning that a single bad claim spoils the entire transaction set, then lets get ready for a lot of paper. Because, at the end, if an electronic claim is rejected by a payer for a data error, there is over 99% chance that the SAME claim will be printed on paper and mailed to the payer. Who wants that? Kepa On Wednesday 04 December 2002 07:32 pm, Marcallee Jackson wrote: > Julie- > > Many, many, many providers will be exempt from Medicare's EDI > requirement and CMS has not even really begun speaking formally about > enforcement of that. Many exempted providers aren't really all that > small either and together their paper volume could nickel and dime a > payer to death. But even with ASCA's requirement there are few payers > who carry a stick as big as Medicare and large providers aren't always > as accepting of strict, hard to comply with rules set by commercial > plans where contracts are negotiated. Now there may be lots of payers > who "plan" to reject transaction sets but you know what they say about > the best laid plans . . . > > I'm aware of many payers that bought translators and "planned" to > implement 100% compliant transactions when they brought the system up. > Most are very unhappy to learn that in the real world of HIPAA > implementation, this doesn't work unless you plan to: > > A. Bring up the system on October 17, 2003 > B. Bring up the system and have very (and I mean very) few transactions > process through it for many months to come > > Most that I talk to, once they understand the impact their original plan > would actually have on their claim volume and their HIPAA > implementation, change their plans from hard-line to real world. I > predict the same result to the hard line approach of rejecting > transaction sets. It's easier to sit in a meeting and talk about > rejecting transaction sets for one bad transaction. It's harder to turn > the switch and watch your EDI volume drop. > > On average, even the best billing entity will experience about a 5% - > 15% error rate. Initially, that number is expected to increase with > HIPAA as we all make adjustments to transactions or edits. Have your > clients analyzed their in bound files to see, if they had this policy in > place today, how many files would make it through the front-end system? > If they didn't reject at the claim level and instead rejected whole > files, how many files could make it through? > > We can't continue down the compliance path with our blinders to the real > challenges of HIPAA implementation. The "it'll be daunting but here we > go" approach no longer works. What becomes clearer each day is that > it's damn near impossible, full compliance by October 16, 2003 won't > happen and it's fast approaching time to talk about how close we can get > to 100%. Not that I expect CMS to discuss that in an FAQ. > > > > -----Original Message----- > From: Julie Thompson [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 04, 2002 5:47 PM > To: WEDI SNIP Testing Subworkgroup List > Subject: Re: Does one bad transaction spoil the whole transaction set? - > used to be defining a health care claim within the context of the 837 > implementation guide > > Good to hear from you Marcallee! > > By Federal Law, Medicare requires 837 compliance by October, 2003. > > If you are compliant with Medicare, why not all other payers? > So the paper option has been pretty much eliminated. > > We are AGREE, the task at hand is more than DAUNTING, but here we go! > > Some implementation will go smooth as silk, others will take a while. > > IT Developers are familiar with lengthy, complicated testing processing > and > are well trained for these jobs. > > I am not so concerned about element by element validation, but by the > last > items on the list....integration. But this is a lengthy discussion. > > All trading partners are going to as much work done as they can in the > short > time left by October. > > Keep in the mind, the implementation will appear in waves, NOT just one > fell > swoop. This will be helpful. > > Julie A. Thompson > > > > From: "Marcallee Jackson" <[EMAIL PROTECTED]> > Reply-To: "WEDI SNIP Testing Subworkgroup List" > <[EMAIL PROTECTED]> > To: "WEDI SNIP Testing Subworkgroup List" <[EMAIL PROTECTED]> > Subject: Re: Does one bad transaction spoil the whole transaction set? > - > used to be defining a health care claim within the context of the 837 > implementation guide > Date: Wed, 4 Dec 2002 17:17:50 -0800 > > This is not a clearinghouse issue to fix. What if the 300,000 claims are > coming from an entity that is not a clearinghouse? What if it's 3000 > files of 100 claims each with 1 problem? Very, very, very few > submitters have front-end editing to ensure compliance, with HIPAA or > payer specific requirements, so payers who accept direct transactions > can expect to see errors in many of the transaction sets they receive. > > When it comes to real life production, hard-line approaches like this > simply will not work. I think your clients might need to get ready to > receive an awful lot of paper. I know of a good scanning solution if > you think that might help ;). > > Marcallee > > > -----Original Message----- > From: Julie Thompson [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 04, 2002 4:57 PM > To: WEDI SNIP Testing Subworkgroup List > Subject: RE: Defining a health care claim within the context of the 837 > implementation guide > > Isn't it the job of clearinghouses to fix these issues? > > A compliant transaction will use dummy or default values in order to > achieve > compliance. Yes, this is the plan for numberous BCBS across the U.S., > including several of our clients. > > Julie A. Thompson > Vice President, Concio > > > > From: "Marcallee Jackson" <[EMAIL PROTECTED]> > Reply-To: "WEDI SNIP Testing Subworkgroup List" > <[EMAIL PROTECTED]> > To: "WEDI SNIP Testing Subworkgroup List" <[EMAIL PROTECTED]> > Subject: RE: Defining a health care claim within the context of the 837 > implementation guide > Date: Wed, 4 Dec 2002 16:46:17 -0800 > > Yeah well there're the FAQ's and then there's real life. You're going > to have a hard time convincing many of us that Medicare intermediaries > will be rejecting a batch (transaction set) of 300,000 claims > (transactions) because claim # 299,996 is missing a zip code. Are you > seeing this in real life implementations and if so, can you share the > names of the carriers? > > > -----Original Message----- > From: Julie Thompson [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 04, 2002 9:32 AM > To: WEDI SNIP Testing Subworkgroup List > Subject: RE: Defining a health care claim within the context of the 837 > implementation guide > > HHS is the group to answer the question of whether to accept a non HIPAA > > compliant transactions in production (X12 alone is NOT compliant). > > I have spoken with Stanley Nachimson and non compliant production > transactions are subject to fine for both the transmitting and the > receiving > partners. > > There was an HHS FAQ I am unable to find the FAQ stating the above, but > here > are some other helpful related HHS FAQs. > > To submit a questions for publication go to: > http://aspe.hhs.gov/admnsimp/bannertx.htm > > HERE ARE SOME VERY HELPFUIL HHS FAQs: > > > > HHS FAQ: Question > How would someone file a complaint against a covered entity? > > Answer > CMS will develop a web-based complaint management process, and will > provide information on this process as part of our HIPAA outreach > activities. > > > Question > What will the enforcement process look like? > > Answer > The enforcement process for HIPAA transactions and code sets (and > for > security and standard identifiers when those are adopted) will be > primarily > complaint-driven. Upon receipt of a complaint, CMS would notify the > provider > of the complaint, and the provider would have the opportunity to > demonstrate > compliance, or to submit a corrective action plan. If the provider does > neither, CMS will have the discretion to impose penalties. > > > Question > Who will enforce the HIPAA standards? > > Answer > The Department of Health and Human Services (HHS)has determined that > CMS > will have responsibility for enforcing the transactions and code set > standards, as well as security and identifiers standards when those are > published. CMS will also continue to enforce the insurance portability > requirements under Title I of HIPAA. The Office for Civil Rights in HHS > will > enforce the privacy standards. > > HHS FAQ: Who is required to use the standards? > All private sector health plans (including managed care organizations > and > ERISA plans, but exlcuding certain small self administered health plans) > and > government health plans (including Medicare, State Medicaid programs, > the > Military Health System for active duty and civilian personnel, the > Veterans > Health Administration, and Indian Health Service programs), all health > care > clearinghouses, and all health care providers that choose to submit or > receive these transactions electronically are required to use these > standards. These "covered entities" must use the standards when > conducting > any of the defined transactions covered under the HIPAA. > > A health care clearinghouse may accept nonstandard transactions for the > sole > purpose of translating them into standard transactions for sending > customers > and may accept standard transactions and translate them into nonstandard > > transactions for receiving customers. > > > > > > > > > From: "Marcallee Jackson" <[EMAIL PROTECTED]> > Reply-To: "WEDI SNIP Testing Subworkgroup List" > <[EMAIL PROTECTED]> > To: "WEDI SNIP Testing Subworkgroup List" <[EMAIL PROTECTED]> > Subject: RE: Defining a health care claim within the context of the 837 > implementation guide > Date: Mon, 2 Dec 2002 09:50:01 -0800 > > I agree with you that once in production - compliance may or may not be > a critical issue but the discussion started out around certification. > Take a look at the message posted under that subject and let me know > your thoughts. > > Thanks > > -----Original Message----- > From: William J. Kammerer [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 02, 2002 9:30 AM > To: WEDI SNIP Testing Subworkgroup List > Subject: Re: Defining a health care claim within the context of the 837 > implementation guide > > I guess there's no doubt that the 2300 loop is a "claim" - 'cause it's > right there in the HIPAA IG called "Claim information." > > But in any event, where does it say that you're going to get into > trouble if you accept a claim (or 837) which is not perfectly > "compliant"? I see in the Rule where it says the Plan has to accept > standard transactions. Therefore, I can imagine a provider who's sent a > perfectly compliant 837 - which has been rejected - now has a leg to > stand on when she complains to HHS about the big bad payer. Thus, it > certainly behooves the payer to be able to accept any compliant claim. > > But whoever is going to complain when the payer accepts and pays claims > with bad zip codes, or no service facility address (how would anyone > know it was needed anyway), or phony newborn weights when it doesn't > otherwise require them? > > Before penalties kick in, I would expect someone to have been harmed - > i.e., the provider. A provider who sends an otherwise compliant claim > is harmed when the payer refuses to accept it - she can't make it any > more "compliant," can she? Her only other choice with an obstinate > payer would be to submit paper or else she won't get paid. > > And it's unlikely a payer is going to complain about "non-compliant" > transactions from a provider; if he chooses not to process them, and if > the provider whines, he can always tell her to go check out her > transaction with Claredi or whoever to satisfy herself that the > transaction is slop. > > Is this "penalties" business more HIPAA-hysteria? > > William J. Kammerer > Novannet, LLC. > Columbus, US-OH 43221-3859 > +1 (614) 487-0320 > > ----- Original Message ----- > From: "Rachel Foerster" <[EMAIL PROTECTED]> > To: "WEDI SNIP Testing Subworkgroup List" <[EMAIL PROTECTED]> > Sent: Monday, 02 December, 2002 12:03 PM > Subject: Defining a health care claim within the context of the 837 > implementation guide > > > Marcallee, > > I propose that you change the subject line for this specific message > thread, since it appears the issue is not one of validation or > certification, but rather, > > Rachel Foerster > > > ----- Original Message ----- > From: "Marcallee Jackson" <[EMAIL PROTECTED]> > To: "WEDI SNIP Testing Subworkgroup List" <[EMAIL PROTECTED]> > Sent: Monday, 02 December, 2002 10:52 AM > Subject: RE: RE: VALIDATION or Certification > > > My initial suggestion that, for the purpose of this message string, we > define a claim as each 2300 loop was based on item 3 from Kepa's earlier > message > > On Monday, November 25, 2002 10:15 PM Kepa Zubeldia wrote: > > > What is a claim? Is it the entire 837 with hundreds of 2300 loops, or is > it each one of the 2300 loops? From the business perspective of > healthcare, it is each one of the 2300 loops. From the EDI perspective, > it could well be the entire 837. It would be nice to get a clarification > from HHS on this, as it could very well affect the penalties. I believe > the covered entities are required to have perfect claims, but we need to > know the scope of a claim. See point #4. As for the certification, both > should be measured, how Many 2300 loops are good and how many ST-SE > transactions are good. The number of 2300 loops per ST-SE is another > important metric. Of course, I am assuming that all transactions must at > least be compliant with X12 syntax or the whole ST-SE would be bad. But, > will a bad ZIP code cause an entire 837 to be bad even if it only > happens in one out of 10,000 claims? I say that is too drastic a > position. > > > So sounds like in terms of defining a claim - we are in agreement that > each 2300 loop would equal a business transaction a/k/a claim. > --- 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-testing 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 new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail --- 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-testing 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-testing 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
