Report an error

What to include

The more of this you can give, the faster it can be traced — but a bare code and “this looks wrong” is still worth sending.

• The code and the page URL.
• What the page says and what it should say.
• Your source — the Tabular List, the Official Guidelines, the addenda, or a Coding Clinic reference. This matters most when the disagreement is about interpretation rather than a plain data mismatch.
• Fiscal year, if it is not FY2027.

Send it to corrections@icdcodes.org.

Errors worth reporting

• A description that does not match the official release
• A code shown as billable that is not, or the reverse
• A missing or misattributed Excludes1, Excludes2, Code First or Use Additional note
• A wrong 7th-character meaning
• A code placed in the wrong chapter, section or parent
• A change incorrectly classified as a subdivision rather than a retirement
• A missing code, or one that should have been removed this fiscal year

Things that are not errors

These come up often enough to be worth stating, because they look like bugs but are working as intended:

• A payer denied a code the site calls billable. “Billable” means valid under the classification. Coverage is a separate question decided by the payer.
• A code from a previous fiscal year is missing. This build covers FY2027. Codes valid in earlier years were correct for encounters in those years.
• An “unspecified” flag looks wrong. That flag is a derived text heuristic and it has known false positives — a description can be unspecified on one axis while specific on another. The rule is documented in the editorial policy. Report it anyway if it is misleading in a way the rule should handle better.

How reports are handled

• Data corrections are triaged ahead of feature work.
• A confirmed error that changed what a page asserted is recorded on the changelog rather than fixed silently.
• Where the cause is a pipeline bug, the fix is applied to the rule so every affected code is corrected at once — not patched one page at a time.