Kepa, If the industry (or whoever) decides that the entire 837 must be rejected if a single claim within is non-compliant, then the front-end edits you were apparently trying to lobby against would become mandatory. If we can't accept or reject individual claims within an 837, then we have to determine all that on the front end, and cannot rely upon the existing logic contained within our application system - which is the product of years of development, in our case.
Then of course there's the case you've already made regarding the impact on business caused by rejecting lots of perfectly acceptable claims. But then, the non-compliant claims might be perfectly acceptable to our adjudication system. So we're already impacting our business in order to comply with a "standard" that may or may not provide any tangible benefits to us. Frankly, I think that it would have been sufficient to simply mandate the part of the rule that says that, "(2) The health plan may not delay the transaction or otherwise adversely affect, or attempt to adversely affect, the person or the transaction on the ground that the transaction is a standard transaction." If that were the case, then those entities that truly felt this standardization to be beneficial could conduct standard transactions, and their trading partners would be required to accept them, while those of us who don't see the benefit could continue to do business the way we have been for years - quite successfully, I might add. The unintended consequences of all this will haunt us for years to come. Remember, you heard it here first... -----Original Message----- From: Kepa Zubeldia [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 20, 2002 11:43 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: When is a claim a standard claim? Rachel, Some of this was responded in my message to your response to Chris. Here is the rest. There was indeed much debate before the Secretary adopted the 837. The other two choices (NSF and UB92) had great support and an installed base much bigger than the 837. At the end the 837 was chosen as the standard for the claim, but it was not easy. Evidently the same definition of a "transaction" ought to apply not only for the 837, but for all other transactions. It is rather murky, since the terminology and the X12 messages are somewhat fuzzy. For example, the 835 contains one single payment but the explanation of benefits covers multiple claims. In fact, the explanation of benefits in one 835 could very well cover multiple healthcare claims as well as the claims contained in multiple 837 "EDI messages" (a.k.a. X12 837 EDI Transactions). Still, one payment, one remittance advice, but multiple claims in the remittance advice. The position of rejecting the entire EDI message because one "claim" in it (or one single X12 segment for that matter) is not in compliance with HIPAA is very understandable from the EDI perspective. But it will be a killer for business, causing massive rejections of otherwise perfectly good claims. However, if HHS makes the determination that "the claim is the 837" under HIPAA, we need to know immediately. Soon is not soon enough. If the translation maps need to be changed to only put one claim in each 837 transaction/message, most everybody will have to change the way they are translating these critters. And this applies not only to the claim, but to all other transactions also. OK, I am afraid I am showing too much of my bias here. So I am going to try to be relatively quiet for the next few days to let other people discuss this, especially since it is a weekend. I would like to get a reaction from lots of other people. Kepa Zubeldia Claredi ----------------------------- On Saturday 20 July 2002 09:30 am, Rachel Foerster wrote: First, no where in the law or the regs is either the UB92 or HCFA-1500 mentioned. Thus, I think we need to abandon thinking that DHHS was looking for an equivalent in another standard format. If DHHS just wanted a simple (!!!???) claim transaction, then why not just adopt these two formats and be done with it. Second, since DHHS adopted the X12 837 "transaction set" as the standard, I would have to assume (I know...that's a risky thing to do!!!) that it did so knowing that the 837 is actually a container for one or more claims. Thus, if any portion of what's in the container fails compliance, the entire container is "tainted" as you say and must be rejected. This is the position I've maintained for quite some time and I still believe it's the appropriate way to go. For example, if the 837 container holds only one claim that fails compliance, the entire 837 must be rejected - container and all. The same would be true for a 270 containing inquiries for multiple individuals, and also the 276 and a 278. I don't think we can have one rule for the 837 transaction set and a different one for the others. Furthermore, it's my opinion that any covered entity conducting a non-complying transaction is subject to penalties under the law, there needs to be much more black/white decision points (after all, computers only think in terms of on/off, true/false) that can then be embodied in program logic. It's all of this interpretative stuff that causing all the heartburn now as it is. Rachel 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. 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.
