One of our clients received an entire batch rejection of ~80 claims due to 3 claims in that file containing incorrect segment data. The rejections look like:
What is causing these rejections is the “REF*87” in the X12 file itself. I looked at the gen_x12_837.inc.php file to see how this is happening. The lines of code this pertains to is 79-86, and it looks like this was supposed to be removed or commented out, but was kept. The code is as follows:
if (!$CMS_5010) {
// This segment was deleted for 5010.
++$edicount;
$out .= "REF" .
"*87" .
"*" . $claim->x12gsversionstring() .
"~\n";
}
The gen_x12_837.inc.php code means that “if the version is not 5010 add the segment REF*87*004010X098A1~” It is the TRANSMISSION TYPE IDENTIFICATION segment for the 4010 version. It is not in any of my 5010 version batch files. If it is in your batch, it should follow the BHT segment. However, your error message may indicate a REF segment in the ST*837*0034*005010X222A1~ set (claim 34) (note that the version is the third element), so you should check your file carefully to be sure which segment is causing the error. If the error is REF*87, then you should find ST*… BHT*… REF*87…. I have had a batch rejected due to set-up errors and the error messages were wrong because the clearinghouse parser was thrown off. My comments may be of no help, x12 errors can be tricky.
I think I made a similar error go away by taking the dash out of the zip codes in insurance plan addresses, particularly for medicare secondary plans. So the zip format would be xxxxxxxxx instead of xxxxx-xxxx. I believe what happened was that the bug fix for dashes removes the dash, but the field has only 9 spaces so drops the last digit leaving an invalid address. This causes the clearing house to fail the whole batch, and you get a batch report for zero claims. Anyway, that worked for me, but it may not be your same problem.
Tony and I looked at this issue yesterday and commented out lines of:
// if (!$CMS_5010) {
// This segment was deleted for 5010.
// ++$edicount;
// $out .= "REF" .
// "*87" .
// "*" . $claim->x12gsversionstring() .
// "~\n";
// }
This code was causing random inserts of ref*87 into claims. A snippet of what the insert looks like on the X12 files starting at Loop 0000D, where ref*87 appears in Loop 0000E is:
In testing this out to see how/when it happens, we generated the affected claims individually instead of in a batch, and the ref*87 didn’t appear. We then generated a larger batch including the person before and after the claim affected, and the ref*87 issue didn’t appear. At that point, we ran the full batch again, and it shifted who it placed the ref*87 insert to.
Though I haven’t found it yet, I suspect that there is an assignment to $CMS_5010 that should be a compare somewhere that is being triggered by something that seems random but then the next pass it resets the value back or maybe a scoping issue. The batch size was an average of 80 claims, the REF*87 appeared randomly about 3 times in the batch…
-Tony
Check if you have any row in the x12_partners table where the value for x12_version is empty or null. In that case plenty of other things will also be wrong with the affected claims.
Yay, we checked all that, there is only one X12 partner in the system, there are no provider overrides in the practice insurance tables and the REF*87 ghost moves around. The ONLY thing that causes that code to run is $CMS_5010 being false and it’s fine for most of the run. It’s weird. Commenting it out solved the problem for the customer since it should only run for 4010 and they are not running 4010. Makes me worry other 4010 things might happen though.
-Tony
115 entries with a value of “0”, 1537 entries with a value of "null, the rest are ‘58’ which it the correct ID for Office Ally in this system. So is ‘0’ a valid, I bet not. NULL is likely to mean “no X12 partner”, but ZERO is fuzzy…
What you should do it look at the billing table items for a claim that failed. What’s supposed to happen is that when the claim is billed, it sets x12_partner_id to the correct x12 partner. I guess that comes from the insurance. So it may be that something in that process is going wrong. Claims billed with insurance should not have a null or zero value for that ID. Can’t really give you a pat answer, it will take some study.
Though I haven’t found it yet, I suspect that there is an assignment to $CMS_5010 that should be a compare somewhere that is being triggered by something that seems random but then the next pass it resets the value back or maybe a scoping issue. The batch size was an average of 80 claims, the REF*87 appeared randomly about 3 times in the batch…
Since 5010 is or will soon become more of the norm than 4010, consider a change to this line in gen_x12 to make 5010 the “default” unless 4010 is explicitly specified.
I have been chasing this for awhile now, could not determin where or why it was happening. I plugged yehster’s code fix in and all is well so far. I was having this happen with batches as low as three claims. Way to go yehster, this is aq important fix.