Paul, unless I'm missing something (which is all too likely), I think you're making too big a deal over words like "accept" and "process." A payer must accept AND process any standard transaction given to it. And how does the payer know it's going to pay a claim - or even, indeed, know if the claim is for services done to one of its subscribers - until the transaction has been "processed"?
No, HIPAA does not mandate that payers "change their core business processes in order to process a standard transaction." But what's that got to do with handling lines within claims? Now, when I get that deep into the IG, my eyes start to glaze over - but it doesn't say in there that the provider can't use line level segments to override stuff at the claim level. And it does seem like a neat "feature." So the sender (the provider) should be able to cobble together whatever combination of line level and claim level loops that make sense and are compliant - and the payer should be prepared to handle them. If this was going to be a problem for payers, the time to bring it up to X12N was a couple of years ago, wasn't it? Now, I would probably stick your example of surgical vs. anesthesia CPT codes in the category of "Business process." If a payer would have refused (to pay) a claim using the wrong (or undesirable) combination of codes on a paper claim, it only stands to reason it can refuse (to pay) an equivalent claim within the 837. But would this kind of stuff be better explained in documents like provider bulletins or manuals? These could be made applicable whether the claim is paper or electronic - and avoid having the "companion" guide contain redundant "business process" kinds of information. Instead, the "companion" guide is where you can get real snotty with the provider - discouraging her from ever wanting to do anything electronic. It's the payer's opportunity to demonstrate the "Golden" Rule: "he who has the gold, rules." You can put arbitrary one-off requirements and special "needs" in there, like "no more than one transaction per GS, and only one GS per interchange." And "no more than 999 segments or 500 claims per 837." Or real doozies like "You can't use decimal points in real numbers." The "companion" guide is for making up new X12 rules as you go along - to show 'em who's boss. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Paul Costello" <[EMAIL PROTECTED]> To: "WEDI SNIP Transactions Workgroup List" <[EMAIL PROTECTED]> Sent: Friday, 07 March, 2003 12:13 PM Subject: Accept v. Process Standard Transactions Group, I have a question regarding "accepting" and standard transaction and "processing" a standard transaction. I was under the impression that in order to meet the HIPAA guidelines, a covered entity only had to be able to accept a standard transaction, but not necessarily process with all the data elements that come in. Also, my understanding was that from a payer's perspective, HIPAA does not mandate that payers completely change their core business processes in order to process a standard transaction. Am I off-base? For example, if a payer only processes claims that come in at the line-level and it receives claims at the claim-level, is the payer still obligated to pay the claim-level claims, or can it just accept the claim-level claim (meeting HIPAA requirements) but not pay? Another example would be when anesthesia charges are billed on a claim, certain health plans currently require the surgical CPT code rather than the anesthesia CPT code. If a provider, post October 16, 2003, sends an anesthesia CPT code, payers have to accept the claim with the anesthesia codes (understood), but do they have to pay? Can they say that their systems only process using surgical CPT codes, so in order to get paid, providers must send anesthesia charges using surgical CPT codes? Wouldn't these two examples be instances where "companion guides" might be used? Any insight is appreciated. Thanks, Paul --- 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
