Electronic Health Reporter

Guest post by Alex Tate, consultant and digital marketing specialist, CureMD.

Regardless of how brilliant a medical biller is, they are guaranteed to come across rejections and denials from time to time. These terms are frequently used to discuss medical billing claims and are often used interchangeably by even the most experienced team members in the health field. However, a rejection differs vastly from a denial. Additionally, the processes necessary to effectively overturn the ruling of a rejection is different from that of a denial. Understanding these fundamental differences is not only essential for ensuring that medical billing claims can be processed without unnecessary frustration, but will also help increase the efficiency of the revenue cycle and may potentially grow the profitability of the organization you work with.

Claims that do not meet the specific data requirements or the basic format necessary will be rejected, according to the Centers for Medicare & Medicaid Services (CMS). Rejected claims will not be processed because they are not considered to have been “received” by the payor, thus do not make it into the adjudication system. This may sound complicated, but it really isn’t. It simply means that a rejected claim must be resubmitted when the error (or errors) is corrected appropriately. It’s important to note that beneficiaries of a rejected claim cannot be held liable because the services were never actually billed.

Denied claims, on the other hand, have been received by the adjudication system of the payor, and cannot be resubmitted because the payment determination has already been decided upon. A denied claim can, however, be appealed by the request of the payor to necessitate the proper modifications, additional required documents, etc.

Improving Revenue Cycles through Term Clarity

Educating staff members of the differences between a denied or a rejected claim can not only accelerate the appeals process drastically, but also help pinpoint where improvements can be made in the future. For instance, if your team comes across an inordinate amount of rejected claims, you may want to focus additional effort toward improving the process of your claim edits or scrubber to provide your clean claims rate with an added boost. This would likely require the involvement of IT, the business office, and possibly the vendor.

Making an effort to reduce the amount of denied claims will require additional effort as the direct cause can be slightly more difficult to sniff out. Many organizations update their accounting system continuously, making changes where needed in an attempt to improve, but often times further complicate certain tasks in the process. An example would be if your accounting system were configured to reduce rejected claims by accepting the claim adjustment reason codes (CARCs) assigned by HIPAA by parsing them according to queues based on the designated CARCs. Although the system setup may reduce the amount of rejections, it very well may increase the amount of denials. When it comes to configuring a patient accounting system, small details can make all the difference in how claims are processed. This may sound like a lot of technical jargon, but it’s important to have a basic understanding of the operations that your accounting system undergoes when processing claims so that simple mistakes can be avoided and rejected/denied claims can remain separate from one another.

Unseen Opportunity to Improve the Revenue Cycle

By lumping the terms, denied and rejected together, you may be completely overlooking a possible situation where your organization’s revenue cycle can greatly benefit. Here is a very real scenario that has played out in many organizations virtually unnoticed by all. Imagine if an organization had been receiving notifications for rejected claims as part of an acknowledgement report. The only problem was that no one was actually tasked to work the reports. Instead, the staff member that received the reports was under the impression that rejections and denials were the same thing, but knew that the system this organization had in place was designed to drive denials / rejections to work queues. So, instead of separating the rejected claims, the staff member simply ignored the reports all together creating a problem that could potentially impair the organization’s overall revenue if not properly attended to.

Later on down the line, the rejected claim would appear in the work queue of an A/R staff member. It wasn’t until then that it was realized that the claim had never actually been received by the payor. Obviously, this would greatly hinder the entire claim adjudication process. If the payor pays approximately 45 days after receiving the claim, but the claim was delayed for an additional 20 days because it was needlessly sitting in the work queue, the provider would then be forced to wait 65 days past the date that the claim was originally billed before the payment would be received. In some instances, if the claim sits idle for long enough, too much time will have elapsed, and the provider will lose the revenue associated with that claim. Obviously, that is the worst case scenario, but you’d be surprised at how often this actually occurs. All of this trouble could easily be avoided if a single staff member was aware of the differences between a denied and a rejected claim.

Once workflows are assigned to process denied and rejected claims separately, the bottom line of that organization will improve immediately.

For those that have been in the health industry for many years, it may be habitual to use these terms synonymously, but doing so may be having negative repercussions. It’s incredible to consider that the minor disparity between two similar words can have such a profound impact on your organization. It is up to management to be on the same page as their team so that everyone understands the difference between a denied claim versus a rejected claim. Once that occurs, the appropriate resources can be allocated to ensure that operations run as smoothly as possible.