Electronic Claim Processing – Can Your Software Do Math?

As a vendor of software that edits and creates ANSI 837 claim files, we try to stay informed regarding the processing of these transactions.  One method that I recommend for all Medicare providers is to make sure that you obtain the memos issued by CMS through the Medicare contractors (MAC).

From time to time, the MACs distribute top ten lists of the most common errors they find in processing claims.  I received a list today from Novitas.  This list is further broken down by state.  The one I am referencing in this article is for New Jersey for April of 2015, but I think you will find that it is representative of all Medicare part A provider claim processing throughout the country.

Can your software do math?
Electronic Claims Processing Errors

The list includes the reason code, description and the resolution for each issue.  However, even if these claims are corrected, AR days are needlessly wasted for errors that could easily be prevented.  The first issue represents the most errors down the least at number ten.  Actual counts aren’t given.

The most amazing thing is that three of the top ten errors, including the largest one, are due to mathematical errors.

Medicare accepts files only in an electronic format (ANSI 837).  This means that these files are created exclusively by computers.  These systems may compile the data as part of a complex and expensive EHR/Patient Accounting system or the claims may simply be entered through a terminal, like the Medicare DDE system.  Either way, there is one thing that computers are good at and that is math.  They just need to be told what to add.  The fact that these errors are even possible is a symptom of poorly designed and supported applications that allow these files to be created without the simplest validation rules in place.

Most of the other errors could also be prevented by implementing simple business rules that validate claims prior to allowing them to be included in a file.  For example, error number two:

“When billing revenue code(s) 036x, 045x, or 076x on a bill type 11x and/or 13x filed with a principle procedure, an operating physician National Provider Identifier (NPI), physician last name, and first initial are required.”

This only requires that the software check three fields on the claim, if these codes are present, the operating physician is required.

Here is one of my favorites, number 7:

“The attending physician National Provider Identifier (NPI) must not be the same as billing provider’s NPI.”

On institutional claims, attending physician is always a person, the billing provider is always a facility.  These are two distinctly different types of NPI’s each with a different qualifier code designating them as a person or a place.  It is difficult to understand how someone experienced in billing could think they are the same.  It is inexcusable for a software application designed to process claims to allow this error to occur since all you have to do is check the qualifier used for the NPI and not the NPI itself.

Now for the real winners in this list, the ones caused by simple math.  In the tradition of all countdown lists, we will go with the smallest one first.  Coming in to the top ten at number six is the total charges line on the bill:

“The amount associated with revenue code 0001 must be the sum of all the charge entries associated with all other revenue codes.”

Really?  How can it be possible to screw up the total of a few dollar amounts?  I would assume that most systems don’t require the user to key in the total, this means that they can’t add these numbers correctly.  If your system allows this type of error, it should send a chill up your spine.  What other types of more complex errors might be happening?  Considering that just about anything else is more complex.

The next error is related to date math, calculating the number of days between two dates.  Coming in at number 3:

“The sum of covered and non-covered days does not equal the days calculated between the statement covers ”From’ and ‘Through’ date.”

Many programming languages include a function that calculates the number of days between two dates if you provide the two dates.  This number, should be equal to covered days + non-covered days.  Catching this error would take two lines of code at most in any programming environment.

Finally, coming in at number one on our top ten list of most frequent claim errors is:

“For inpatient or skilled nursing facility claims, the number of ‘covered days’ on page 1 of the claim, must equal the number of accommodation units associated with accommodation revenue codes on page 2 of the claim.”

Once again, this is as simple as comparing one number with another number.  Are they equal?  If not, the claim should not be processed until it is corrected.

Without actual numbers associated with these errors and the dollars involved, it is difficult to calculate how much these errors cost the industry in delayed payments and duplication of claims processing services. However, issue #1 is related to inpatient and skilled nursing claims that are almost always high dollar transactions.

What we do know is that these errors represent the ten most common reasons that claims are rejected.  Beyond the top ten, it is even more likely that the remaining errors are at least as equally preventable as these common ones.

As a provider, you should check to see if your process would allow these types of errors to occur.  If it can, ask your vendor why.


By Kalon Mitchell – President, MEDTranDirect