Cynthia, This issue is a great one. We classify the errors in the transactions into three kinds:
- HIPAA requirements. These are composed of the X12 rules and the Implementation Guide requirements. We classify these with the SNIP six levels of testing. Claredi has added a seventh level (probably should be added by SNIP to the white paper too) that defines HIPAA Implementation Guide requirements that only apply to one specific trading partner. The HIPAA IGs have a handful of requirements that only apply to Medicare, Medicaid, or Indian Health. So those are only required if you do business with that trading partner. Even if an element is "optional" in X12 (level 1), if it is required by HIPAA, it will fail the level 2 edit. The failure of the HIPAA requirements can be communicated with the 997 (level 1, X12 syntax), the 824 (voluntary, non-HIPAA, for error levels 2 and up), the unsolicited 277 (voluntary, non-HIPAA, for the response to the 837) or other transactions like the 271, 277, 278, 835, or even with proprietary reports, just as is being done today. - Business requirements. These are generally accepted industry requirements that HIPAA does not mention. For example, the fact that the patient must be born before the services are rendered. Or that a "person" name should not contain digits in it. Technically, these can also be classified using the SNIP 6 (or 7) levels, but there will be very few at levels 1 and 2. In the generally accepted requirements there are some that apply to all payers, or to a substantial group of payers (Medicare, Medicaid, Blues) that are well known causes of rejected claims from those payers. You can customize these business requirements with the requirements of specific payers, and get very granular, as may be necessary. The failure of these business requirements is trickier. It cannot be done with the 997. Some could be reported back with the 824, as long as it clearly indicates the error to be a business error rather than a HIPAA requirement (for legal "compliance" reasons) and in most cases you will also have to indicate the error "context" as these frequently are semantic (situational) driven errors. In some cases the best way to report these errors are with HIPAA transactions that have been defined for this purpose, rather than the 824. - Warnings. These are conditions that we detect that are not necessarily an error for all trading partners. For example, if you send a "patient account number" longer than 20 bytes, most trading partners will just truncate it down to 20. These "warnings" are informational messages, but not necessarily "errors". They alert you to potential problems down the line. Again, they can be classified more or less according to the SNIP levels. And some warnings apply to all trading partners, whereas other warnings may apply to only a few trading partners, or to just one trading partner. These, in general, cannot be reported with the 997 or with the standard HIPAA transactions. They have to be reported with the 824 or some other mechanism such as a proprietary report. So, as far as "letting through" errors, clearly if a transaction has HIPAA errors of *any* sort, in violation of any of the Standards adopted by the Secretary, it is not in compliance. It is not good enough to test "up to SNIP level X" because these are not really "levels" but "types of testing" and ALL of them are required for HIPAA compliance. Even at level 7, if you are doing business with one of the specified trading partners, your transactions better be compliant for those trading partner specific requirements. Also, keep in mind that the Secretary has adopted not only the Implementation Guides, and the code sets, but also the "coding guidelines" that govern the use of the code sets. There are some HIPAA requirements buried in those guidelines! As soon as a transaction goes through the HIPAA requirements without errors, it could be certified to be HIPAA compliant. But, for trading partners to accept the transaction as valid and to actually "do" something with it, two other things must happen in today's environment: - The transaction must be free from "business" errors, and - The transaction must represent your actual business. There is some flexibility in this area, not like in the HIPAA requirements, but in general, both must be true. The trick is that there is not a single source of what are "business" errors and certainly not a standard. It takes considerable business expertise in healthcare to identify those. And, what is even better, they evolve with time and what used to be a problem a few years ago is no longer a problem. We now have new "opportunities" to deal with. As for the transaction representing your actual business, that is a long topic that I will leave for another day. Suffice it to say that this is probably as important, or even more important, than the certification itself. Say you are certified that you can do "office visit" type of claims (837) but you happen to be an ambulance company. Is that certification even relevant? As for what other companies are doing, I won't speak for them. It is probably not fair to compare testing (Claredi, Foresight, Cefeg, more on the way) with certification (Claredi) as it would be comparing apples and oranges. But even in the testing arena, the completeness of the testing is an issue. Claredi is dividing the test results as outlined above. Others may be doing other different things. I am sure that after reading this message some of Claredi's testing competitors will add some of these features to their products. Oh, well, it won't be the first time or the last time this happens. As long as it helps the industry moving to where we need to go, it's OK with me. I hope this helps answer your question. Also, there is an excellent SNIP white paper on "front end edits" that addresses some of these issues. Kepa On Friday 19 April 2002 03:18 pm, Cynthia Korman wrote: > RE: questions on the appropriate way to reply when there are error in a > transaction requestGiven the "up in the air" aspects of HIPAA TCS error > reporting, I wonder whether or not the HIPAA transaction certification > engines that are out there today come "out of the box" configured so that > they won't "let through" a transaction if it's missing a HIPAA-required > field that is optional per X12...given the obvious competence of the folks > who are working the HIPAA effort, and the fact that some of those folks use > the WEDI SNIP testing levels 1-6 model, I'd assume the answer is that they > won't "let through" these transactions...but we all know the dangers of > assuming...perhaps some certification engines do and some don't... > > More relevant to this week's discussion is the same question applied to > transactions managers that generate 997s in response to submitted > 837s...Rachel pointed out that "... the 997 can be kludged to report guide > syntax errors, such as missing mandatory segment or element..." (Thank you > Rachel!) I wonder if the transactions managers that are being billed as > "HIPAA-ready" currently come kludged (configured?) to do the appropriate > HIPAA-specific mandatory data element error reporting...(I'm not asking > about the inter-segment dependency errors, just the black-and-white > HIPAA-mandated, X12-optional). > > Sounds like there won't be a 997 or 824 IG before the 10/16/03 deadline, so > what we have today is what we have...And the 997 is what everyone is > reading as the standard if they're only looking at the IGs and addenda, > which is all that they're required by law to look at... > > Cynthia Korman, Principal > Strategic System Solutions, LLC > 973 394-9529 > [EMAIL PROTECTED] > www.healthcare-systems.com > > ----- Original Message ----- > From: Bill Chessman > To: '[EMAIL PROTECTED]' > Sent: Friday, April 19, 2002 12:41 PM > Subject: RE: compliance with x12 vs. HIPAA IG > > > > > > When X12 says an element is optional and HIPAA says it's "Not Used", that > doesn't violate X12 because transmission of the segment without that > element is OK with X12 (because it was optional anyway). When X12 says the > element is optional and HIPAA says it's "Required", that doesn't violate > X12 either because transmission of the segment with the element always > present is OK with X12 (because optional means you can use it as often as > you like...including always). So what the HIPAA IG is doing is creating > restrictions on X12 that don't violate the original definitions...that's > pretty much how IGs are supposed to work. I think the 997 reporting of > HIPAA usage errors is still up in the air (based on the discussion that's > been going on this week). > > Best regards, > Bill Chessman > Peregrine Systems, Inc. > -----Original Message----- > From: Cynthia Korman [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 19, 2002 9:11 AM > To: [EMAIL PROTECTED] > Subject: compliance with x12 vs. HIPAA IG > > > > > > Regarding Mike's comment below: "I would have to also contend that the > HIPAA IGs are a subset of X12. If you can't get the X12 right, you're > non-compliant, right?. " My understanding is that one CAN get the X12 > right and be out of compliance from a HIPAA perspective. Specifically, in > the HIPAA Implementation Guides, the data element attributes to the right > of the data element names and descriptions are X12; the "usage" column to > the left of the de names/descrips are HIPAA-specific. The two sometimes > contradict, in which case the "usage" column on the left takes precedence. > > For example: 837P IG, p. 172 shows "Claim Filing Indicator Code" as "O" > or Optional from the X12 perspective, but NOT USED from the HIPAA > perspective. That same page shows "Health Care Service Location > Information" as Optional from the X12 perspective, but REQUIRED from the > HIPAA perspective. > > To summarize, my understanding is that it's the left hand column that's > the bible when it comes to USAGE (Required/Situational/Not Used). If > anyone believes that to be off base, please advise! > > Can the 997 report errors in (HIPAA-specific) USAGE? Thanks in > advance... > > Cynthia Korman, Principal > Strategic System Solutions, LLC > 973 394-9529 > [EMAIL PROTECTED] > www.healthcare-systems.com > > > > ********************************************************************** > To be removed from this list, send a message to: > [EMAIL PROTECTED] Please note that it may take up to 72 hours to > process your request. > > > 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/. Posting of advertisements or other > commercial use of this listserv is specifically prohibited. -- This email contains confidential information intended only for the named addressee(s). Any use, distribution, copying or disclosure by any other person is strictly prohibited. ********************************************************************** To be removed from this list, send a message to: [EMAIL PROTECTED] Please note that it may take up to 72 hours to process your request. ====================================================== 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/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
