Catherine, I sense the frustration implied in your (and others') recommendation to essentially "force" this matter to a clear and unambiguous resolution. I'm not suggesting that anyone has proposed an outright "dumb" resolution (i.e., one that is inordinately expensive, unfair, or might negatively impact someone's health) , but... if the industry's only alternatives were "clear and dumb" or "fuzzy and smart (in terms of business and/or health)"... I suspect that many of us would consider voting for the "clear and dumb" option... because we could at least go home and BUILD THE DAMNED THING!! Allowing the "smart and fuzzy" solution to remain in a prolonged state of high-level discussion will cause industry players to become "fed up with this approach to standardization", in which case they will drop out of the discussion and implement whatever "makes sense" to their individual companies.
As I have asserted (somewhere in one of these threads)... the Secretary has... either by accident or stroke of genius... apparently defined "standard" to be any part or all of the "standard rule set", and he has apparently defined "transaction" to be any part or all of the process of the process of exchanging information for some general business purpose such as "asking about a patient's eligibility". As to which specific part of a standard applies to which specific part of a particular transaction, the Secretary appears to have chosen to remain silent... suggesting that the industry is free to do (I would read this as *encouraged* to do) whatever makes sense for the core business of the industry: taking care of peoples health in the most efficient way possible. I would specifically apply this ethic to the present discussion by suggesting that the Secretary intends for payors to accept *all parts* of any data stream that are faithful (to the corresponding parts of the standard) and to reject those parts that are in conflict with the the standard. The ability to do this in a highly granular fashion will vary with trading partner capabilities, but if a payor had the ability to reject a "non standard" service line on a single claim and to process the other service lines, I would say that the present rule permits it... and that providers in that case would want to kiss that payor on the lips!! Regards, Chris At 12:15 PM 7/22/2002 -0400, [EMAIL PROTECTED] wrote: >Kepa - The only problem I have with that analysis is: At what point within >the 837 are you talking about a distinct "claim"? At the 2300 CLM loop I >imagine. But what if the problem with the transaction occurs at the >Billing Pay-To Provider level? Are all the claims under that HL to be >considered "good" or "bad"? >Or what if the problem is a single service line within a CLM? Should the >single service line be considered "bad" and rejected by the payer and the >remaining service lines that are good be processed under the now "good" >CLM? What if the problem occurs in a level that is situational and is >really not needed by the payer to pay the claim (for example, what if there >is an incorrect value in the REF01 of the Supervising Provider Secondary >Identification Number...the payer, in this example, doesn't even use this >data to adjudicate a claim....should the Plan accept or reject the claim or >transaction in this circumstance?) > >It seems to me that until we come up with an fair and impartial way to >split claim transactions into distinct good and bad claims, that health >plans will need to consider the entire transmission (from the ISA to the >IEA) and should either accept it or reject it IN TOTAL. > >This is just my opinion. I am aware of some health plans that are putting >preprocesses into place that will parse the 837 batch transmission into >individual claims and will accept and reject claims on a claim-by-claim >basis. I am also aware of health plans that will be rejecting the entire >837 batch transmission even when a single data element is invalid...no >matter how many claims that batch contains or how many would be considered >"good". > >Catherine Schulten >Sybase, Inc >6550 Rock Spring Drive >Suite 800 >Bethesda, MD 20817 >W: 301-896-1467 >C: 703-338-6955 > > > > > > Kepa > Zubeldia > > <Kepa.Zubeldia@cl To: "William J. Kammerer" > <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > aredi.com> cc: > > Subject: Re: When is a > claim a standard claim? > 07/22/2002 > 10:01 > > AM > > Please respond > to > > Kepa.Zubeldia > > > > > > > > >William, > >When a provider sends 3,654 claims, and one of them is bad... I don't think > >the providers are going to agree with the idea that it is OK to reject all >of >them because the one bad claim in the file. If the other 3,653 claims are >HIPAA compliant, can the payer refuse them? Isn't the payer required to >conduct the standard transactions? > >Here is where the world of EDI and the world of business collide. It may >be >an invalid 837 because it is tainted by a bad claim... but is that what was > >intended when the Secretary adopted the 837? > >Kepa > > > >On Sunday 21 July 2002 10:32 am, William J. Kammerer wrote: > > May I suggest that this thread be moved to just one or the other of the > > WEDI/SNIP Business Issues or Transactions listserves? Cross-posting (on > > the WEDI/SNIP listserves) runs counter to Zon Owen's SNIP Listserv Usage > > & Etiquette Guidelines (2002-04-01) at > > http://www.mail-archive.com/business%40wedi.org/msg00311.html. > > > > A recipient *may* reject an entire 837 transaction set if even only one > > claim within is "tainted," but I doubt the law forbids more > > "fine-grained" rejection. As Kepa noted, many of the semantic issues > > may not be discovered until well into the back-end, long after the > > transaction set has been translated. It may be difficult to "rollback" > > thousands of correct "claims" within a single 837, for example, just > > because the 3654th claim had a semantic inconsistency of the type Ellen > > Falbowski mentioned: e.g., data from the CR1 Ambulance Transport > > Information segment is missing when the payer finally discovers, deep in > > the back-end, that an ambulance type Procedure Code was used. > > > > Since the 824 (004050X166) allows for selective rejection, the payer, if > > she prefers, could accept all but the erroneous claim (items), or all > > claims for the particular patient which contained the erroneous claim > > line item, or the entire 837 - depending on what floats her boat > > (technically and business-issue wise). The provider (or billing service > > or CH) would have no call to complain if the payer were to reject the > > entire 837 since it is, in effect, non-compliant; but at the same time, > > he certainly would not object to the selective rejection of erroneous > > claims - which obviously allows him to get paid for the clean claims, > > however. > > > > The payer is not refusing to accept the standard transaction - the most > > important part of the law, strongly emphasized throughout the TCS Rule. > > And the provider still has not been given an artificial incentive to not > > use the standard transaction, because he still hasn't gotten paid (for > > the one invalid claim) even if the payer adjudicates the remainder of > > the 837 (not because she is necessarily generous, but probably because > > it's actually simpler for her). Everyone's happy: why should the HIPAA > > Stasi get involved? > > > > William J. Kammerer > > Novannet, LLC. > > Columbus, US-OH 43221-3859 > > +1 (614) 487-0320 > > > > ----- Original Message ----- > > From: "Rachel Foerster" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > > <[EMAIL PROTECTED]> > > Sent: Saturday, 20 July, 2002 11:30 AM > > Subject: RE: When is a claim a standard claim? > > > > Ok Kepa....here's my take. Hopefully others will chime in. > > > > 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 > > RFA, Ltd. > > > > > > > > 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. > >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. Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268 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.
