When Following the Coding Guidelines Still Gets You Marked Wrong

What are coders supposed to do when auditor, payer, and CDI expectations conflict with the coding guidelines we have been taught to follow?

That question came up during a coaching call I had this morning with a coder who was understandably upset about her audit results from last month. She had three DRG errors. All three were tied to diagnosis codes that were determined to be not clinically supported.

Had those diagnoses not been marked as errors, her audit score would have been 100%.

Instead, it was 67%.

Well below a passing coding audit score.

And here is where the frustration begins: the diagnoses were documented by the provider.

This directly conflicts with a guideline many experienced coders and auditors know well. Section I.A.19 of the ICD-10-CM Official Guidelines for Coding and Reporting states that diagnosis code assignment is based on the provider’s diagnostic statement that the condition exists. It also states that code assignment is not based on the clinical criteria the provider used to establish that diagnosis.

So what happens when a coder follows that guideline and is still marked wrong?

That is the uncomfortable space many coders are working in, and still fighting today.

We are trained to follow coding guidelines. We are taught that the guidelines take precedence over facility policy, payer preference, and individual opinion, except for instructional notes in the Tabular List and Alphabetic Index. Yet in real-world auditing, denials, and CDI reviews, coders are increasingly being held accountable for whether a documented diagnosis is clinically supported.

Clinical validation has become one of the biggest pressure points in coding.

Many of us have seen this scenario: a diagnosis is documented throughout the record by the attending provider and specialists. The coder assigns the code because the documentation supports reporting it under the coding guidelines. Then, after an internal audit, CDI review, or payer review, the diagnosis is determined not to be clinically supported.

The result? The coder takes the error.

And that is what feels so wrong to many coders. They know they followed the rule. They know the diagnosis was documented. They know the guideline supports code assignment based on provider documentation.

So why is it being counted as a coding error?

For years, I fought these findings. I fought them for myself. I fought them for coders I audited. I fought them in appeals. My position was simple: this may be a clinical validation issue, but it is not a coding error when the provider documented the condition and the coding guideline supports reporting it.

And honestly, I still understand why coders feel that way.

But I also had to accept what the industry has made very clear: this is now part of the coder’s reality.

Whether the guideline has changed or not, coders and auditors are increasingly expected to recognize when the clinical picture does not appear to support the documented diagnosis. If we do not, the case may come back as an audit finding, a denial, or a CDI/coding disagreement.

That does not mean coders are diagnosing patients. It does not mean coders should ignore provider documentation. And it does not mean every questionable diagnosis should automatically be removed.

It means we have to strengthen our review process.

We already know there are times when a condition appears in the assessment but is not truly a reportable current condition. Maybe it did not impact the admission. Maybe it was copied forward. Maybe it was historical. Maybe it was listed without evaluation, treatment, monitoring, or clinical significance.

Those situations are already addressed by coding guidance. Guidance that isn’t ignored.

That is where coders are being tested now.

The guideline itself has not caught up with the reality coders are living every day. I am honestly surprised it hasn’t changed, because this one guideline has contributed to countless audit findings, appeals, denials, and coder frustration. Coders are following what the guideline says, yet they are being judged by a standard that goes beyond it and directly conflicts with it.

Still, until the guidance changes, we have to work within the environment we are in.

That is why I teach clinical validation as part of the coder’s review process. Not because I think every diagnosis needs to become a research project. But because I know what happens when coders do not take that extra step.

Audit errors happen.

Denials happen.

Rebuttals get denied.

And good coders are left wondering how following the rules resulted in a failing score.

The coding role is changing again.

With AI becoming a larger part of coding, auditing, CDI, and revenue cycle operations, this shift is only going to become more obvious. Coders are moving further into audit, validation, and critical thinking roles. The value of a coder will not only be in assigning the code, but in knowing when the documentation, the clinical picture, and the coded data do not align.

Now is the time to prepare for that shift.

Many experienced coders and auditors are approaching retirement, and the need for strong subject matter experts is growing. Employers need coders who understand guidelines, but they also need coders who can recognize risk, identify clinical validation concerns, and communicate those concerns clearly.

So if you are a coder, do not wait.

• Learn what clinical validation is.
• Learn the common clinical indicators for high-risk diagnoses.
• Learn when to query.
• Learn how to defend your coding when it is defensible.
• And learn when a documented diagnosis may not survive review, even when it appears clearly stated in the record.

This is where coding is now.

The coders who understand that now will be the ones best prepared to lead, audit, educate, appeal, and make an impact in the years ahead.

~Ann Reilly, Founder | Reilly Coding Education™

Reference: CMS ICD-10-CM Official Guidelines for Coding and Reporting FY 2027
https://www.cms.gov/files/document/fy-2027-icd-10-cm-coding-guidelines.pdf