Kepa - This approach is indeed one we discussed years ago. It provides an opportunity for success to all.
Flexibility is the name of the game. The phased approach will facilitate communication among our industry as well as ensure we're all on the same page of music. ----- Original Message ----- From: "Kepa Zubeldia" <[EMAIL PROTECTED]> To: "Koller, Greg" <[EMAIL PROTECTED]>; "'Christopher J. Feahr, OD'" <[EMAIL PROTECTED]>; "George Kaye" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, April 15, 2002 10:18 AM Subject: Re: Code Set effectivity compliance testing > Greg, > > That is a great approach. I proposed a staged implementation back in 1998, > but was summarily rejected in favor of the all or nothing approach. > > I think (for whatever that is worth :-) that there should be flexibility. > Some trading partners may want to start sending/receiving a "relaxed" version > of the HIPAA transactions now, and then start tightening it as time goes by. > For instance, where the guide does not explicitly forbid something, let's > have some flexibility. > > One example: What if the Place of Service in the service line (Loop 2400) is > the same as the Place of Service in the 2300 loop (claim level)? The guide > says that the POS at the service line is sent when it is different than the > one at the claim level. The strict interpretation is that if it is the same > in both places, you don't send it at the service line. But, what is the harm > if you do send it at the service line? They are the same, right? So there > is no confusion. For a transitional time we should relax these requirements. > There are many more examples. Then, once people are using these > transactions, as an industry we could tighten the requirements one step at a > time. > > We are conducting an experiment with Claredi customers. On April 1st we > released, for our customer's use, a version of the testing and certification > system that uses this "relaxed" approach to compliance. Where the normal > (strict) compliance requirements would make a transaction fail, the "relaxed" > version will pass with a "business error" or "warning". The "relaxed" > version is based on our interpretation of the TG8 Opinion letter. So far it > has only been two weeks, but the "vote" seems to be that the Claredi > customers are choosing the "strict" analysis over the "relaxed" analysis by a > factor of 20:1. This is shocking. I was expecting it to be the other way > around. We will see what happens after one full month. Claredi's customers > are the experts, pioneers, and early adopters, so our population is probably > biased and favors the more strict interpretation of the guides. > > For entities that are mapping from NSF to the 837, and for clearinghouses, I > think the relaxed edits is the best way to go. As the data stream improves > in data content and providers migrate away from the NSF as an intermediate > format, the requirements can be better aligned with the letter of the > implementation guides. > > So, the staged approach that you are talking about makes a lot of sense. The > trick is that the entire industry would have to agree to have approximately > the same interpretation of what a staged approach means. If we could get > some of the largest clearinghouses (you know who you are) on board with this > concept, maybe SNIP could coordinate some sort of white paper on what would > be the staged approach to compliance. I have been involved in some > conversations in this area that seem very encouraging. > > Perhaps there should be an option, at least for the transition time until > October 2003, and people could decide whether to transition in one step to > the full strict compliance with the guides, or through a series of more > relaxed compliance steps. The problem is that if you have thousands of > systems to adjust, you don't want to adjust them several times. OK, then do > it in one step. Your choice. > > Is this a topic we could put in the agenda for the Business meeting tomorrow? > > Kepa > > > > > On Sunday 14 April 2002 07:50 pm, Koller, Greg wrote: > > Chris, > > > > I concur. > > > > Every time I meet with a provider they start looking like deer in the > > headlights when I try to explain this. Part of the problem is the number > > of vendors out there consistently telling them they will be compliant. I > > am not so sure the vendors are far off with their understanding. Yet, we > > continue to see major payers that are not yet at the point of introducing > > anything. The all or nothing concept with HIPAA is going to be devastating > > to these providers, because they do not understand the additional data they > > will be required to collect. > > > > As a clearinghouse, we have advocated strongly for the staged approach. > > Start publishing elements that are required and setting timeframes for > > them. I think the biggest step for most entities will be moving from a flat > > NSF or HCFA to a Looping ANSI, 4010 but not compliant. Payers should be > > doing that - NOW! Next, start asking for and setting timeframes for the > > required elements, specifically those that are readily available or > > relational to current data. Lastly, set timeframes for non-relational and > > optional/situational data that the payer will require. That basically > > brings us to compliance. This will not only start getting reasonable > > efforts made towards compliance, but it will educate the providers on what > > is at hand as we go along. I think the perfect opportunity to make such a > > method viable would be to have CMS take the lead in such a program. > > > > Just a theory. > > > > Greg Koller > > Manager of Operations and Business Development > > United Wisconsin Proservices > > (414)226-5520 > > [EMAIL PROTECTED] > > > > > > > > -----Original Message----- > > From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] > > Sent: Saturday, April 13, 2002 1:07 PM > > To: [EMAIL PROTECTED]; George Kaye; [EMAIL PROTECTED] > > Subject: Re: Code Set effectivity compliance testing > > > > Kepa, > > Has there been any discussion of the mechanism (and where its funding might > > come from) by which providers' software vendors can be EDUCATED regarding > > this critically important issue? I have not met a single Office Management > > System vendor yet who understands that even if the X12 EDI messages are not > > going to be flying right out of the doctor's software, the required data > > elements for populating an 837 DO have to be in there and WILL have to be > > packaged up and handed off at some point to a "translator engine/entity" > > for conversion to the standard. I doubt that more than 5% of the OMS > > vendor community gets it that NONE of the old claim standards map reliably > > and consistently to the new HIPAA standards, and that sending NSF and "1500 > > print images" to a clearinghouse is NOT going to be much help to the > > doctor. Unless CHs and payors are prepared to massively "relax" these > > standards for awhile, we will be looking at a 90% reject rate for claims > > from small providers. This global misunderstanding (they don't even know > > that they don't know) may explain why almost no software vendors or doctors > > are coming to X12 meetings or asking questions about this... only a year > > before they are supposed to be in "testing mode". > > > > (And if you think the OMS community is out of the loop on TCS standards, > > try asking a few doctors what they know about this! I'm doing a primarily > > TCS-related HIPAA presentation to 50 or 60 eye doctors in N. Calif. next > > week and they are pretty excited about hearing this. To date, all doctors > > have heard/read about HIPAA is the Privacy Rule. They just assume that > > their OMS vendors are wiring the TCS stuff into their next system upgrade.) > > > > Regards, > > Chris > > > > At 09:56 PM 4/8/02 -0600, Kepa Zubeldia wrote: > > >George, > > > > > >That is a very interesting point. Is your assumption that the > > > > clearinghouse > > > > >creates the transactions and has control of the code sets? The fact that > > > > the > > > > >clearinghouse has demonstrated the "capability" to use a certain code set > > >does not necessarily mean that each one of the providers clients of that > > >clearinghouse is using that same code set. I wish life was that easy. > > > > > >One of the typical "HIPAA Myths" is that the clearinghouses can magically > > >make the providers compliant. That is not the case. Let's make sure that > > >all the players understand what is their own responsibility. If the > > >expectations from providers are that their vendor or clearinghouse will > > > > take > > > > >care of HIPAA much like they took care of Y2K, we will run into big > > > > problems > > > > >when they wake up to the reality. > > > > > >Kepa > > > > > >On Monday 08 April 2002 02:58 pm, George Kaye wrote: > > > > If a payer performs compliance testing with a clearinghouse for code > > > > set effectivity for a professional claim (for example), has anyone > > > > thought through the process of what that testing should consist of, so > > > > that the payer can assume that those code sets will continue to be > > > > compliant from that clearinghouse on an ongoing basis regardless of: > > > > the type of professional claim (office visit, ambulance, physical > > > > therapy etc.), or when the code is impacted by new code set releases by > > > > the DSMO's? > > > > > >To be removed from this list, go to: > > >http://snip.wedi.org/unsubscribe.cfm?list=business > > >and enter your email address. > > > > > >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. > > > > Christopher J. Feahr, OD > > http://visiondatastandard.org > > [EMAIL PROTECTED] > > Cell/Pager: 707-529-2268 > > > > > > To be removed from this list, go to: > > http://snip.wedi.org/unsubscribe.cfm?list=business > > and enter your email address. > > > > 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. > > -- > This email contains confidential information intended only for the named > addressee(s). Any use, distribution, copying or disclosure by any other > person is strictly prohibited. > > To be removed from this list, go to: http://snip.wedi.org/unsubscribe.cfm?list=business > and enter your email address. > > 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, go to: http://snip.wedi.org/unsubscribe.cfm?list=business and enter your email address. 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.
