Billing > Facility Billing

ASC Billing-Traditional Medicare is denying every Claim with CO-8



We bill for pro and facility and have been doing so for the last 10 years. A little over a month ago we started getting denials on our facility (ASC) claims- for only Medicare.  Every single claim- no matter the CPT code (all different ones)  The denial codes are all the same- CO-8- The procedure code is inconsistent with the provider type/specialty (taxonomy).   The pro claims for Medicare are all paid. We are up to 60+ denials now with this code. We have reach out to our clearing house and Medicare on multiple occasions and still have no answers on what is going on.  Nothing has changed with our system or anything. Anyone have any thoughts. Thanks in advance!!

In the absence of any solid information, here are some thoughts to trigger thinking.

Here in California, we submit our Medicare claims through Noridian.  The following is from Noridian's explanation of Adjustment Reason Codes for #8:

The procedure code is inconsistent with the provider type/specialty (taxonomy). Note: Refer to the 835 Healthcare Policy Identification Segment (loop 2110 Service Payment Information REF), if present.

The "835" is the Health Care Claim Payment and Remittance Advice - the electronic transmission of healthcare payment/benefit information.

Jennsing, have you checked the 835 for any additional information about what is going on?

We use Office Ally for some of our providers.  They have a spot on a template where the CLIA # for the provider goes if the provider uses one.  Theoretically, when we store the CLIA # in this spot on the template, the CLIA # shows up automatically when we submit the billing.  Except nothing happens when Office Ally users place the CLIA # in that spot.  Some fairly extensive digging through things with Office Ally's technical team discovered a different, unpublished location where the CLIA # needed to be.  Seems that Office Ally has several different data streams that feed into the final, official electronic record that they then send off to the various Insurance Carriers.  Turns out that the field that actually works for the CLIA # is in a different data sub-feed than what is published in their instructional material.

During the conversations that uncovered this CLIA # information, the technicians also admitted that software upgrades sometimes screw up the data fields.  Say a certain number is fed to a field, with the first digit is supposed to go in the first spot in the field.  A software update will sometimes result in the first digit being placed into the second spot in the data field (or some other spot in the data field).  The end result being that the number being fed to the Insurance Carrier (who is reading from the first spot in the field) ends up being incorrect.

These kinds of errors get noticed pretty quickly, and so get corrected pretty quicly.  So I would think that your issue would have been noticed and corrected by now if the problem was caused by something similar to this.  But - it is an idea that might help you think outside of the box in thinking what might have caused this problem to suddenly pop up.

This also sounds like it could be an enrollment issue.  Is it possible you missed the revalidation?


[0] Message Index

Go to full version