Advice for Coding Medical Necessity on Outpatient Claims

Don’t confuse your payer policy with providers’ medical degrees

My recent article regarding secondary diagnosis coding and my advice to “just follow the guidelines” seems to have touched a nerve. Because it’s never quite that simple, is it? There’s the textbook answer on how we should be coding, and then there’s the reality that not all payers adhere to the coding guidelines, and they don’t all use the fields available on the UB-04. So when the textbook answer doesn’t pay claims, what’s the proper course of action?

Here’s the issue: say Susie comes into the ER complaining of leg pain and swelling, and clinical evaluation raises concern of a blood clot, so a venous Doppler study is ordered to rule out deep venous thrombosis (DVT). It turns out Susie doesn’t have DVT, and she’s discharged with a diagnosis of a leg contusion. The coder assigns the code for contusion and the claim is denied by insurance for failure to meet medical necessity, because according to their policy, a bruise isn’t a condition that warrants a venous Doppler study.

The claim was coded correctly and in my non-physician professional opinion, I can see why the physician ordered the test and why he felt it was medically necessary. So why can’t the insurance company see that?

I recently came across a coffee mug that I think all physicians should own; it read, “Please don’t confuse your Google search with my medical degree.” I think maybe we should have a new version that reads, “Please don’t confuse your medical necessity policy with my medical degree.” There’s no question that rising healthcare costs are a concern, but for the most part, I think we can agree that most physicians are typically acting in the best interests of their patients rather than thinking about payment for themselves or the facility.

Reason for Visit and the UB-04

When the UB-04 (and the CMS-1450 electronic claim form) was implemented in 2007, it included three new diagnosis fields to report the patient’s reason for visit (RFV). The idea of the RFV fields was to allow for reporting additional diagnoses that don’t meet the definitions for final diagnoses, according to the coding guidelines, but which are important for communicating to the payer. In other words, this is the perfect place to report conditions that do meet medical necessity for tests and procedures performed on the patient when the list of final diagnoses does not.

In Susie’s case, if we lived in a textbook world, we could code leg pain and swelling in the RFV fields and then contusion as a final diagnosis. This would meet medical necessity guidelines while also assuring the payer that the doctor didn’t order the test just to see how badly bruised Susie was, but rather to rule out a more serious and potentially life-threatening condition.

But we don’t live in a textbook world, and the fact of the matter is that while the RFV fields may be used by coders when reporting facility codes, they may not be recognized by the payer. This may be a result of a transmission error during the electronic billing process or simply the fact that payers just don’t look at those codes. If your payers are looking at the RFV fields, you likely don’t have a large problem with medical necessity denials. But if your payers aren’t doing so, your coding compliance could be called into question.

Balancing Coding Guidelines with Fiscal Responsibility

While performing coding audits, I frequently recommend removal of diagnosis codes in accordance with the official coding guidelines. During the rebuttal process, I am often told those additional diagnoses were added to cover medical necessity for tests. There’s a part of me that understands that we need to be reimbursed for medically necessary services, but there’s another part that starts twitching when I hear that we are not following coding guidelines so that we can get the claim paid. Balancing coding compliance and fiscal responsibility is the true issue here.

The American Health Information Management Association (AHIMA) updated its Standards of Ethical Coding in December 2016; it is a code of conduct that all coding professionals should follow. The Standards stress the importance of following the official coding guidelines and not “coding for dollars.” One could argue that by coding Susie’s symptoms of leg pain and swelling in addition to her contusion, we are accurately presenting her clinical picture and supplying codes for medical necessity. But the fact is, we broke a basic coding rule to do so (ICD-10-CM Official Guidelines for Coding and Reporting, section I.B.4. “Signs and Symptoms”).

Blanket Policies Aren’t the Answer

The issue of medical necessity is a gray area, and you may often feel stuck between a rock and a hard place. How do you apply textbook guidelines in an imperfect world? The American Hospital Association (AHA) published advice for dealing with conflicts between payer policies and guidelines in its Coding Clinic published during the first quarter of 2014, page 16. The article offers steps to help providers resolve coding disputes. But no matter how much we try, there will always be a diagnosis that doesn’t meet medical necessity because the patient’s final diagnosis isn’t on the payer’s list. In most cases, that’s a good thing, because it means a more serious condition was ruled out.

Where I think the problem lies is in generalities. The cases in question are often outpatient diagnostic tests, and hospitals churn a lot of those out every day. Coders are performing transactional work and are expected to hit productivity targets to prevent coding backlogs and increased accounts receivable (A/R) days. In order to meet the production standard, it’s easier to tell coders to assign all signs and symptoms in addition to established conditions “just in case” those extra codes are needed for medical necessity. However, we should treat coding signs and symptoms separate from related established conditions as the exception rather than the rule.

If your payer doesn’t accept the RFV fields, then your coders should be reviewing payer policies for medical necessity to see if the codes that meet coding guidelines satisfy medical necessity before adding codes for signs and symptoms. This means training coders to use the policies and adjusting productivity levels to account for policy review.

I’m sure that last statement, like my previous article, will touch a nerve. Stay tuned for my next article, which will provide strategies for nurturing coders into revenue integrity professionals who can fully participate in capturing quality information while safeguarding your organization’s fiscal health.

Comment on this article