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.
