Ajay Yes, this was discussed as well, and, for better or worse, X12 went the course that you are now very familiar with. I was not deeply involved in that particular thread so I am not familiar with the details of it.
Jan Ajay K sanghi wrote: > Jan, > > Thanks a lot for the rationale. It's very interesting. > > What I find intriguing is that why wasn't the release of HIPAA guide changed > from 004010X098 to 004011X098 and everything would have been fine. Given, > all the exercise that was undertaken to include loop 2440, I think, simply > changing the release to 004011X098 would not have delayed releasing the > guide, since 4011 was (a) either already out or (b) it was already decided > that loop 2440 will be present in 4011. Was this option discussed? > > Thanks and regards, > > Ajay > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jan Root > Sent: Tuesday, April 23, 2002 11:47 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. > > ********************************************************************** > 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.
