Rachel wrote:
><snip>So, yes, it could be that a given transaction violates the
underlying X12 standard, but complies with the law. In this case, the law
trumps the standard,<snip>
Technically, "law trumping the standard" is ok with me but I thought the
view few days back was that what is not X12 standard compliant is not HIPAA
compliant as well.
Assuming:
use of 997 (for X12 standard validation) and 824 (HIPAA IG validation),
following truth table applies.
824 997 //1=> positive ack, 0=> negative ack
0 0 //violates standard, violates HIPAA
0 1 //complies with standard, violates HIPAA
1 0 //violates standard, complies with HIPAA?
1 1 //complies with standard, complies with HIPAA
I would never vote for a 10 scenario. In fact, if -ve 997 then there should
be no need for a follow-up 824. For +ve 997, it is ok to have a +ve or -ve
824.
In such a "messed up" situation, I would go by adding loop 2440 to the
standard 4010 837 message and treat it just like it is part of the standard
as Bill Chessman suggested. For 837I and 837D it can be made "not used".
But then, I am more for using 997-only for HIPAA guide compliance errors.
If time is still permitting, I would even suggest that the guides version
for at least 837P be changed to 004011X098 by having a re-vote on the
situation Larry Watkins described. I am sorry, I do not understand these
"procedures" well, so I may be well "off" making such a suggestion.
Ajay
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Rachel Foerster
Sent: Thursday, April 25, 2002 2:56 AM
To: [EMAIL PROTECTED]
Subject: RE: The 2440 loop in the 837
Bill,
This is the caveat I've been providing to my clients, etc. during workshops
and seminars. So, yes, it could be that a given transaction violates the
underlying X12 standard, but complies with the law. In this case, the law
trumps the standard, but as you said, both the translator creating the
transaction and the translator interpreting the transaction must be able to
handle this anomaly....and as you and I both know, not all translators are
created equal here.
Rachel
Rachel Foerster
Principal
Rachel Foerster & Associates, Ltd.
Professionals in EDI & Electronic Commerce
39432 North Avenue
Beach Park, IL 60099
Phone: 847-872-8070
Fax: 847-872-6860
http://www.rfa-edi.com
-----Original Message-----
From: Bill Chessman [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 24, 2002 12:27 PM
To: '[EMAIL PROTECTED]'
Subject: RE: The 2440 loop in the 837
Hmm...that could almost suggest a situation in which both a 997 and an 824
could be returned: 997 says the 2440 loop doesn't comply with X12, followed
by an 824 to say everything's just what was needed based on HIPAA IGs...or
is 824 only used for a negative response?
My personal take on that would be that a given translator would need to be
sufficiently adaptable to treat the 2440 loop as part of the X12 standard
and not cause 997 rejections to be generated by its presence. (Standard
disclaimer: that's my *opinion* and may not be reflected by my employer, my
co-workers or for that matter, anyone/anything else in the known universe.)
Best regards,
Bill Chessman
Peregrine Systems, Inc.
P.S. They say "the best thing about standards is there are so many to choose
from." The other best thing is that they're so flexible. 8-)
-----Original Message-----
From: Rachel Foerster [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 24, 2002 9:13 AM
To: [EMAIL PROTECTED]
Subject: RE: The 2440 loop in the 837
Jan,
Thank you for this excellent recap of the history of the 2440 loop and how
it got into the HIPAA standard while it was not yet part of the X12
standard.
This is yet another reason why one must separate X12 compliance validation
and error reporting from HIPAA compliance validation and error reporting. In
an instance of the 837 where loop 2440 must be used, it would not be
compliant with the X12 standards but would be compliant with HIPAA. One
needs to know the boundaries and be able to manage compliance and make
decisions within each boundary.
Rachel Foerster
Principal
Rachel Foerster & Associates, Ltd.
Professionals in EDI & Electronic Commerce
39432 North Avenue
Beach Park, IL 60099
Phone: 847-872-8070
Fax: 847-872-6860
http://www.rfa-edi.com
-----Original Message-----
From: Jan Root [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 23, 2002 1:17 PM
To: [EMAIL PROTECTED]
Subject: Re: The 2440 loop in the 837
Ajay
I can report somewhat on the rationale behind adding the 2440 loop to the
827 even though it is not in the 4010 standard. The TG2 Co-Chairs or the
Co-Chair of X12N may want to add additional comments.
There were two considerations that led to the decision to violate the X12
standards and include the 2440 loop. I hope I can express both points
clearly and politically correctly. There are still some people who are very
unhappy about this decision (quite understandably). If I step on anyone's
toes or get my facts skewampus, my apologies in advance. It was a very
complex discussion
and I probably don't have everything exactly correct.
Point One: X12 TG2 was under intense pressure to make the HIPAA
implementation guides workable. Of particular focus was the 837. Medicare
was on the brink of bringing their DMERC (durable medical equipment) claims
into the EDI fold. It is my understanding that they had been planning on
this for several years (any Medicare folks out there please chime in if I've
got the story
wrong). The 837 WG had made the appropriate condition statements to make
DMERC claims work electronically for other aspects of DMERC claims. We
thought we'd completed our task.
However, if I have learned anything in my years in health care EDI it is
that health care is an incredibly complex industry. Paying for an operation
is just not the same as buying a car. It is easy to think you've got all
your bases covered only to discover, at the last hour (sometimes well after
the last hour) that you do not. Medicare (and, to be fair, several other
payers)
realized that there were several attachments that they required on their
DMERC claims (other payers needed home health attachments). Providers
generally will not send electronic claims that have paper attachments. So,
in order to get DMERC (and home health) claims electronically it was
presented as necessary to include that information in the claim. We had
hoped that the Attachments
NPRM would have taken care of this, but by the time the 2440 loop was added,
it was clear(er) that the Attachments NPRM was not going to be released in
the immediate future.
Unfortunately, there was no way, given the existing 837 structure, to
include that information in the claim in an electronically readable format.
So we were left with no X12 structure to meet a pressing business need.
Second issue: Being named in the TCS rule as the keeper of the transaction
standard for the health care claim was an honor but it brought about an
interesting dilemma for X12. We found ourselves caught between the X12
standard (one 'rock') and the Federal rules (another very, very hard place).
The X12 standard has the force of the entire ANSI process behind it - no
small thing.
Federal rule, on the other hand, has the weight of federal law behind it -
also nothing to lightly ignore. X12 found itself caught between these two
requirements.
Throughout the X12 HIPAA-transaction writing process X12N/TG2 strove to
adhere to the X12 standards. It was not easy to do and there were many
times (most times) when we choose to stick with the X12 standard and make a
kind of kludgey solution to a problem rather than violate the standard.
That was the predominant response when we found ourselves trying to make the
guides workable,
with no clear way within the standard to acomplish this. You cannot change
the X12 standards on a dime - it takes time - it is not unusual for it to
take a year to make a change. This is as it should be: changes to the
standard should be thoroughally considered and not made quickly. However,
TG2 was in a (perceived) time crunch: we were being told that we had to
finish the guides
immediately (!) so that they could be published in the federal rule (the
feds required completed guides so that they could publish the exact version
of the guides in the rule).
As I said, we did everything we could to not violate the X12 standard even
when it meant some rather in-elegant solutions to business problems.
However, with the DMERC and home health attachments issue, we were stumped.
There did not appear to be any way within the 4010 standard to pass that
information in the 837.
Hindsight is always an interesting exercise. Should TG2 have stuck to it's
X12 guns and said "we will not violate our own standards - period" or should
we have said "we'll make the guides functional for the industry"? It was a
painful and highly contested decision. To say that the discussion was
lively would be to make quite an understatement. At the time, it received a
lot of
discussion within the X12/TG2 world.
For better or worse, we took the route of making the guides functional for
the industry as a whole. In working with HHS to get these guides out, the
functionality of the guides has always been a high priority. I guess you
could say that 'realism' (from an industry perspective) won out over
'purism'... was that a good thing to do? Yes and no. It is possible for
Medicare and other
payers to get their attachment information in an electronic claim (which has
led to yet a whole other discussion regarding claims attachments and how
best to handle them - stay tuned; that one's not over yet). That is good.
However, translators (and others) have to be aware that they need to be
"HIPAA compliant" not just "X12 compliant". That is a new requirement (for
everyone) and
it poses a challenge to an accepted way of doing business. It poses a
challenge to the entire concept of 'standard' ('the problem with standards
is that we have so many of them'... ). That is not good.
However, we still have a standard: In this case we have a federal standard
that is not exactly the same as the national standard but it is still an
immense improvement over the 400+ known versions of NSF (not to mention
implementations for all the other transactions.)
Anyway, I hope this helps explain some of the rationale (and angst) behind
the decision to add the 2440 loop. I don't think this is 'news' to many
translator vendors, certainly not the ones who attended X12 during the 2440
loop discussions. (My advice to my network users is to get a "HIPAA
compliant" translator, not an "X12 complaint" translator. HIPAA is a
federal law afterall and
people seem to be ok with this advice.) It may illustrate (again) the need
for companies to get involved at X12 and not just assume that everything
will go as expected. Sometimes there are very difficult decisions to make
and, even if you don't agree with the outcome, if you were there, you can at
least vote.
Jan Root
Ajay K sanghi wrote:
> I wonder the rationale behind it. If I am not mistaken, the FRM segment in
> the 2440 loop is not even in the 4010 standard!
>
> Ajay
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher J. Feahr,
> OD
> Sent: Tuesday, April 23, 2002 3:40 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: The 2440 loop in the 837
>
> YIKES!! I had no idea that the 2440 loop ("additional supporting
> information") was not in the underlying X12 standard. Vision is "eyeing"
> (excuse the pun) this loop to provide additional identifying information
> about eyewear products. (perhaps this explains some of the controversy
> around this useful-looking part of the claim)
>
> -Chris
>
> At 10:11 AM 4/22/02 -0400, William J. Kammerer wrote:
> >Hey! I have one for you all! Take a look at the 837 Professional IG
> >(004010X098) - it uses a loop (2440) at the end of the transaction which
> >IS NOT in the underlying 004010 standard! What would you do in this
> >case? Send back a negative 997 indicating an X12 syntax error if the
> >2440 loop were actually used? See if you can make hay with that!!
>
> Christopher J. Feahr, OD
> http://visiondatastandard.org
> [EMAIL PROTECTED]
> Cell/Pager: 707-529-2268
>
> **********************************************************************
> To be removed from this list, send a message to:
> [EMAIL PROTECTED]
> Please note that it may take up to 72 hours to process your request.
>
> ======================================================
> 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.
>
> **********************************************************************
> To be removed from this list, send a message to:
[EMAIL PROTECTED]
> Please note that it may take up to 72 hours to process your request.
>
> ======================================================
> 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.
**********************************************************************
To be removed from this list, send a message to:
[EMAIL PROTECTED]
Please note that it may take up to 72 hours to process your request.
======================================================
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.
