Beaverlog Tips: Volume 16 - November 19, 2003

Trials and Tribulations of HIPAA Claim Testing

Payers and clearing houses understandably want to receive electronic claims that meet certain standards to ensure that they can be read reliably and that they contain correctly formatted and placed data. Typically, some kind of testing is done before production claims can be submitted. In the halcyon days before HIPAA, electronic insurance claims used one of two formats, HCFA-1500 print image (which is a computer file that looks like a filled-in claim form minus the form) and NSF (an misnomic acronym if ever there was one for National Standard format). The format for HCFA-1500 print image claims is so simple that testing was almost non-existent. Testing NSF was not much more complex despite all the roadblocks payers used to make it difficult to submit a claim that would pass muster.

One of the goals of HIPAA was to provide a truly universal electronic claims format that had the force of law behind it. The result was a format referred to as ANSI X12 4010 837X098 (with the October 2002 addendum, this is now ANSI X12 4010A1 837X098). We usually just call it X12 claims though others refer to it as ANSI (pronounced An-see) claims. Whatever you call it, this new format is an order of magnitude more complicated than the NSF and two orders more complicated than the HCFA-1500.

The silver lining of this dark cloud of complexity is that the law does not allow payers to change the definition of what is contained nor are they permitted to make changes to how that data is formatted. These things are spelled out quite clearly in the specification. If you need something to put you to sleep, all 768 pages of the Implementation Guide (the official specification) is included with The THERAPIST version 2.0 CD as an Adobe Acrobat file called X098.pdf. In version 2.0.016 we added the 86 page addendum (X098A1.pdf).

Because of the complexity of the X12 claim format, payers and clearing houses have an even greater need to test claim formats to make sure that they meet the standard. Unfortunately, they are all too often making the testing (and by extension, actual claim submission) somewhere between difficult and impossible. In some cases, they are flaunting the law and requiring data to be submitted in a format not specified in the standard. They are also (again counter to the specification and the law) rejecting claims with more information than they require in their own implementation guidelines. This tactic is pointedly not allowed by law.

The Beaver Creek Software policy on testing has always been that we will assist our customers through the testing process but that we will not do the testing ourselves. We found that this policy doesn't work with HIPAA and the new X12 claim format. Payers now require vendor testing prior to accepting any claims from providers. As we discovered, this has proven to be yet another way to put up roadblocks to their accepting and paying on your claims.

Joel Hackett, our intrepid technical support representative, has been given the additional task of doing the vendor testing. This article will take you through the difficulties and frustrations he has experienced (and is still experiencing) along the way.

In Joel's Words

Since they were the first request on my desk, I started testing with Regence Blue Cross Blue Shield of Washington in June of this year. Regence claims are submitted through THIN (Texas Health Information Network), a clearing house operated by Blue Cross/Blue Shield of Texas. It turned out that I had to go through a testing process with THIN before I could do the same thing all over again with Regence. I submitted my test claim files to THIN. and got through their Bulletin Board Testing phase after 20 files or so. I thought I had everything completed but a second level of testing rejected all of my claims and I discovered that I had been given an invalid vendor ID and misinformation about what was required for testing. All of my testing up to then was invalid and I had to start the whole process over again from the beginning.

I took the last file that I had submitted which was initially accepted and resubmitted under the new guidelines. I got a report back from THIN that there were errors in the file. On troubleshooting the errors, a couple of them were errors caused by The THERAPIST software. We quickly fixed these problems. Some of the issues were problems with the way data was entered. Others turned out to be places where THIN required data formatted differently than described in the official specification.

Some errors made no sense at all so I started resubmitting some of the same files and got back completely different error reports. By now I had submitted 30 or 40 claims and I was just getting upset over the process.

After many discussions with THIN regarding these differences between their requirement and the specification , they indicated that they would not be making any additional changes to their standard. In response we made a work-around in our program so our claims would be accepted. We also contacted the Centers for Medicare Services (CMS) and were told in no uncertain terms that what THIN was doing was not allowed.

After submitting 60-70 files for approval, I get a message from someone at THIN informing me that I must use data from the Region corresponding to the vendor number was assigned. I am in Oregon but for reasons known only to them, was issued a vendor number for New Mexico. My sample data did not have patients in New Mexico so none of the zip codes matched so all of my claims were rejected. Keep in mind that the payer I was trying to test with was Regence in Washington.

So I changed my patient and carrier data to show New Mexico addresses and information. When I submitted with the new data I got back an error report with many more errors than I got with the original Oregon information. I made the corrections from the error report and resubmitted. The claim file was accepted by the validating software but rejected by the person reviewing the data because I did not have valid subscriber identification for New Mexico. So I called THIN and was told my fake data was not acceptable and that I needed real data for real patients and would have to start the process over again. Arrrrrrgh!

At this point I also asked whether, after I get everything submitted for the New Mexico area taken approved, would that approval cover the THIN part of the testing for all payers using THIN. Their answer was no and that I would have to go through this process for each state/region that they service. I asked why since they already know that our Software can create the claim files to meet the standard. As I found out with this conversation, "Standard" has many definitions depending on who you are and where you are. I also asked what the differences were from one state/region to another since everyone is suppose to be following the same Implementation Guide? Their reply was that different States/Regions require different information. Well that is not what the Implementation Guide says.

Finally after several months of the battle with THIN, sometimes with weeks going by and not having my phone calls returned or emails answered, I asked Peter Gysegem, president of Beaver Creek Software, for assistance. He called the vice president of THIN (we were told that he was the top guy) in an attempt to cut through the run around we were getting. Peter left three messages for the VP in late August and early September and has never received a return call. At this point we decided to discontinue testing with THIN since they would not work with or even communicate with us.

Unfortunately, THIN is not the only problem. Southern California Medicare (NHIC) is another interesting example. NHIC requested that we test with them first using LIVE data and I indicated to them that I had a Customer in the area who was willing to test with them using our Software. NHIC indicated that this would fine with them and that Beaver Creek Software would be approved after our customer successfully completed the testing. After a few weeks of working with our customer to complete the testing, she got an approval to go into production. Hooray!

Since we were told that it would be so, I assumed that Beaver Creek Software was now approved and other customers could submit claims to NHIC. Well, another one of our customers called Southern California NHIC and indicated they wanted to submit a test file so they could go into production. They were told they couldn't do it until Beaver Creek Software is approved. So I called NHIC only to be informed that Beaver Creek Software was not approved and that we would have to do our own testing. Arrrrrrgh!

So, I started the testing process with them. I submitted a couple of files and did not hear anything from them, no email, no fax, no phone calls. I called back again and again and left messages for someone to return my phone call. I left two telephone numbers and my email address. One day, then two passed and I still did not hear from them so I called and asked for a supervisor. She told me that the testing person tried to call on a couple of occasions, got a busy signal and just stopped trying. So, I asked her to have the testing person call me back and she agreed. A couple more days went by and I had not heard anything so again I called the supervisor and she gave me the same story. I give her both phone numbers again and my email address. I did not hear anything for yet another day and then I got an email with a report that I was not able to read. So I called NHIC and they indicated that the report I was sent was an X12 997 Acknowledgement file. I told her that our software is not yet able to decode the 997, which NHIC indicated was the only way I could find out what errors were in the claim files. (Editors note: the upcoming new version of The THERAPIST will be able to read and decode the 997). Eventually, NHIC agreed to send us a human readable version of the 997 Acknowledgement (which they could have sent from the beginning if they had wanted to).

About a week later I called them back and inquired about our customers being able to test with them and I was told that they would allow our customers to test with them as long as we were willing to assist our customers with any errors. I indicated that I would be willing to assist. I also indicated that we have a customer in their area that is already in production with our software and why would that not qualify for our test. I was told that vendors are treated much differently than providers and that a vendor had to test with more stringent requirements. True to form, there was no documentation they could provide describing the requirements which exceeded the Implementation Guides in mysterious ways.

At the request of one of our customers, a representative of THIN contacted us a couple of weeks ago indicating that they have corrected (or will correct) some of their problems and assured us that we would get timely responses. We started testing with them again but "Timely" is not a word I would use to describe the promptness of their responses to my submissions.

I wish I could say that our customers would be immune from the problems we have experienced in our ongoing testing efforts. Unfortunately, they may only be the beginning. The one suggestion I can make is to use a clearing house, and one not owned by a payer. Keep in mind the adage to follow the money. It is not in the financial interest of payers to facilitate your claims submission. They make more money by using any and all excuses to deny your claims at any and every turn.