Dave, Take a look at the last part of Section 3.1 of the Guides, where it talks about industry usage, specifically the definition of "situational". It says:
"The use of this item varies, depending on data content and business context. The defining rule is generally documented in a syntax or usage note attached to the item.* The item should be used whenever the situation defined in the note is true; otherwise, the item should not be used. *NOTE If no rule appears in the notes, the item should be sent if the data is available to the sender." As an editorial, I would advise the receivers of the transactions to do exactly what you are doing: If you get an element you don't need, or a situational element that perhaps should not have been sent, just ignore it. There is not much of a reason to reject the claim because it contained the CLIA number on a non-Medicare claim. At least, there is not much reason to reject such claim in production. In a test environment, however, you ought to know about the possible problem, and then make your own decision whether to change your transactions or not. Obviously, the test environment needs to identify all possible problems with your transactions, and, hopefully, the production environment will be a lot more lenient than the test environment. If the production environment was to be as strict as the test environment, and the test environment detects all possible issues, then most likely nothing would get passed into production. There is a significant difference between testing and production. The test environment should be a "pedantic" environment. The production environment should be a "reasonable" environment. Perhaps you can pedantically detect the errors in the production environment, but then act reasonably. This could involve leniency with certain errors, rather than pedantic rejections. As for the providers applying the payer specific edits based on the final destination payer, that is probably not going to happen. Keep in mind that the providers systems see you, the repricer, as the payer. At least for claims. If they saw the final destination payer, they would send the claims to the final destination payer instead of sending them to you. So, until the provider's systems can make the dichotomy between the payer and the repricer, you are stuck. But (rhetorical question) wasn't one of the goals of HIPAA to eliminate these differences in data interchange requirements for these transactions? What has happened here? Kepa Zubeldia Claredi On Wednesday 26 March 2003 10:51 am, WEDI SNIP Transactions wrote: > I have a general question about Situational segments and elements and a somewhat related question about payer-specific edits. My Situational question deals with 837 transactions but it could be applied to all transactions. > > I'd like to know if any receivers will reject claims that have unneeded Situational segments or elements. I have a couple of examples: > Onset Date at Service Level (2400 loop) being the same as the Onset Date at Claim Level (2300 loop) > CLIA Number submitted on non-Medicare/Medicaid claims > > I haven't found any explicit language saying unneeded Situational items cannot be sent, but it's clear that they "should not" be sent, leading to individual interpretation of the language to determine if it's allowable when not needed. I'm asking because, as a repricer of claims, I receive claims from many sources (direct-submitting providers and clearinghouses) and then send those repriced claims on to payers. All inbound EDI transactions will be HIPAA compliant and I'll be inserting my HCP segments at the appropriate location within each claim and then sending those claims on to payers. When I receive claims with unneeded Situational segments or elements, I simply ignore the unneeded information and I'm hoping the payers I send to will do as well, which does seem to be the case in most I have spoken with. I'm trying to limit the number of claims that I originally accept from a sender, only to have those claims rejected by a receiver for some reason. > > As for my question about payer-specific edits; most of these submitters only identify the claim as our claim, rather than identifying the ultimate destination of the claim - the payer. I've been asked by the submitters what edits I want applied but the few edits I want may not include the payer-specific edits that a payer may want. Is it fair of me to ask these submitters to identify the payer of the claim and apply those specific edits according to their companion guides? Since I'm not the creator of the claim and the source of the data, I don't feel that I can apply many of these payer-specific edits. > > Thanks in advance for any advice. > > Dave Sell > Sr. Programmer/Analyst > The Alliance > [EMAIL PROTECTED] --- 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
