Hi Kepa,
That approach does not work for us. We assume that payer test systems will mimic the behavior of payer production systems. That's why we send test claims. If we find that claims are rejecting, we'll modify our claims until they are accepted by the test systems. That's a great way to handle our business, but since we have to change all of our claim transactions between now and October 16th, I would strongly prefer getting through all of the required modifications to keep our claims being paid come H-day, rather than responding to nuances of 'good HIPAA claims' versus 'great HIPAA claims'. Having a compliance checker that tests claims at the highest level of HIPAA verification makes sense, but I hope that payer test systems will work just like their production systems.
I'd appreciate hearing from payers on how your test systems work in comparison to your production systems. Thanks.
| Kepa Zubeldia <[EMAIL PROTECTED]>
03/26/2003 11:07 AM
|
To: "WEDI SNIP Transactions Workgroup List" <[EMAIL PROTECTED]> cc: Subject: Re: Situational segments/elements and payer-specific edits |
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
--- 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
