Larry,
Thanks for filling up. Ajay -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Larry Watkins Sent: Thursday, April 25, 2002 5:46 PM To: [EMAIL PROTECTED] Subject: RE: The 2440 loop in the 837 Jan -- Thank you for the good summary of the history of this. And yes, there was much discussion at the time regarding moving to the 4011 version of the standard. While this could have been done, it would have complicated the regulatory process and put the Professional claim version at a different level than the other standards. Everyone did not agree on our final decision, but the majority did -- thus the nature of consensus standards. Clearly, the fact that the 4010 IG's contain an item that didn't make the standard before 4011 indicates that translators must make an exception for syntax rejection for this loop/segment. This exception is industry-wide and a national standard. The 2440 FRM segment should not be rejected as syntactically incorrect under HIPAA. As was said earlier, HIPAA trumps the standard. This sort of "exception" happens often in other industries. I'm thankful that it happened only once in the HIPAA Implementation Guides. I believe that the current leadership of X12N sees the difficulty this type of approach causes, and will avoid this type of "solution" in the future. Regards, Larry Watkins Co-Chair, ASC X12N Health Care Task Group Vice President & COO, Claredi Corporation Office: (801) 444-0339 x204 Fax: (770) 419-5295 Mobile: (770) 331-1898 e-Mail: [EMAIL PROTECTED] -----Original Message----- From: Jan Root [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 24, 2002 10:12 AM To: [EMAIL PROTECTED] Subject: Re: The 2440 loop in the 837 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.
