Skip to main content

Check your code list

Paste the codes from a claim (up to 25 — 12 fit a professional CMS-1500, 25 an institutional claim) and check them against the official CMS ICD-10-CM tabular data, the Medicare Code Editor, and the CMS-derived rules MedCoder holds, before you submit. Deterministic, official-data-only, and free.

What Claim Check verifies

Every code on your list is checked against the official CMS ICD-10-CM tabular data and the Medicare Code Editor for 14 kinds of problem — and then, reported separately below, against the other CMS rules MedCoder holds:

  • Excludes1 conflicts — The tabular list marks certain code pairs as mutually exclusive (“not coded here”). Reporting both, such as type 1 and type 2 diabetes together, is an error unless the two conditions are documented as unrelated (ICD-10-CM Official Guidelines, Section I.A.12.a).
  • Excludes2 review items — An Excludes2 note means the excluded condition is not part of the code, but a patient may have both. These are reported under Review, apart from blocking conflicts, as allowed when both conditions are documented.
  • Same-category specificity — An “other specified” and an “unspecified” code from the same category (such as D50.8 and D50.9) aren’t ordinarily reported together for one condition, even though the tabular list carries no Excludes note between them (ICD-10-CM Official Guidelines, Section I.B.18).
  • Laterality — When a right-side and a left-side code for the same condition appear together and the registry holds a bilateral code, the bilateral code is suggested for review (ICD-10-CM Official Guidelines, Section I.B.13). Flagged for review, not as a blocking issue: whether the condition is documented as bilateral is a chart question, not a lookup.
  • Sequencing instructions — When one listed code carries a “Code first” or “Use additional code” note covering another listed code, the report shows which code must be sequenced first on the claim. Hypertensive heart disease with heart failure (I11.0), for example, is sequenced before the heart failure code (I50.-) it instructs you to add. When a code carries such a note and nothing on the list satisfies it, the report flags it as a review item naming the instruction — a documentation question, since Claim Check cannot see the chart, never a statement that a code is missing.
  • Code Also instructions — A Code Also note names a second code that may also be required, without fixing the order. Pairs on your list that one code’s note names are reported so the pairing is deliberate.
  • Billable status — Non-billable header codes (like E11 instead of E11.9) are flagged, with the billable child codes to use instead.
  • Registry presence — Codes that don’t exist in the current registry are called out as probable typos or retired codes.
  • Missing 7th characters — Injury, fracture and external-cause codes require a 7th character encoding the encounter (A initial, D subsequent, S sequela, plus the fracture-specific values). Submitting the base code — S82.101 instead of S82.101A — is an invalid code. The flag is raised only from the code’s own tabular instruction, and the suggested replacements are real registry codes, so X-placeholder forms (S06.0X0A) come out right.
  • Principal diagnosis edits — For principal-diagnosis checks, the first code on your list is treated as the proposed principal diagnosis and checked against the CMS Medicare Code Editor, which rejects three groups in that position: codes describing a circumstance rather than a treated condition (Z-codes such as aftercare), manifestation codes that require their underlying etiology first, and external cause codes (V, W, X, Y). Each is perfectly valid as a secondary diagnosis, so the flag is raised only for first position. Claim Check reports what the edit says; choosing which condition should lead depends on the documented reason for admission, which is a coder’s judgement, not a lookup.
  • Age conflicts — When you enter the patient’s age, every diagnosis is checked against the Medicare Code Editor’s four age-category lists (perinatal/newborn age 0, pediatric 0–17, maternity 9–64, adult 15–124). A newborn diagnosis on an adult’s claim is an automatic MCE rejection. The MCE sex-conflict edit is deliberately not checked: CMS deactivated it as of October 1, 2024.
  • Date-of-service validity — ICD-10-CM turns over every October 1. Enter the encounter date and each code is checked against the code set actually in force that day, not today’s — including codes whose billable status changed.
  • POA reporting — On an inpatient institutional claim each diagnosis needs a present-on-admission indicator unless CMS exempts the code; professional claims do not carry one. Your list is split into the codes that require one and the codes on the exempt list.
  • CC/MCC severity and MS-DRG context — Secondary diagnoses that CMS designates a complication or major complication are identified, and the grouper pathways the submitted diagnoses touch are listed with their relative weight, geometric mean length of stay and national unadjusted base payment, with the derivation shown. Preliminary context worked out from the published appendices — not a grouping result, and not a run of CMS’s own grouper software. A final MS-DRG comes from the inpatient panel, where MedCoder’s own implementation of CMS’s published grouper logic runs on the inpatient inputs a coder supplies.

Rules reported separately

Each of these is a separate question with its own CMS source and release, reported on its own and never merged into a single verdict. Where a release is not loaded the answer is that the data is unavailable — which is not the same as no rule, and not the same as allowed.

  • Procedure-to-procedure edits — Every pair of listed codes is checked against the National Correct Coding Initiative procedure-to-procedure tables for the programme and care setting you select, and a match is reported with CMS’s own modifier indicator for that pair and the release it came from. MedCoder stores only the HCPCS Level II rows of those files — the CPT-keyed rows are AMA-licensed and are counted and discarded at ingest — so a pair MedCoder raises nothing about is a pair MedCoder holds no row for, which is not the same as CMS publishing no edit.
  • Published utilization limits — Where CMS publishes a Medically Unlikely Edit for a listed HCPCS Level II code in the programme and setting you select, the report states the published value, its adjudication indicator and its rationale, and says when the units assumed for the claim sit above it. That is a published utilization threshold being exceeded, not an adjudication. As with the procedure-to-procedure tables, the CPT-keyed rows are licensed and not held, so what MedCoder checks is part of the MUE universe and never the whole of it.
  • Modifier review — The modifiers you put on a line are read against the CMS HCPCS Level II modifier registry: whether the modifier exists in the release covering the date of service, and what CMS’s own description says it means. The report quotes that description and does not tell you which modifier to append — which modifier the documentation supports is a coder’s decision, not a lookup.
  • Coverage policy — Choose a National Coverage Determination and the listed diagnoses are checked against the code list CMS publishes for that policy, reporting coverage-policy support where the list identifies the code. A policy whose list MedCoder does not hold reports data unavailable rather than treating MedCoder’s gap as CMS’s silence. Local Coverage Determination code lists are distributed only under licences this project does not hold, so every coverage result carries that gap on its face instead of implying an LCD was consulted.
  • MS-DRG grouping — Given the principal diagnosis, the secondary diagnoses with their present-on-admission indicators, the procedures, the sex and the discharge status, MedCoder’s own implementation of CMS’s published MS-DRG grouper logic groups the claim against CMS’s published grouper tables for the fiscal year covering the date of service. The implementation is version-specific and is verified against CMS’s published grouper software during validation — see /how-we-verify for the record. The result states the grouping — the DRG the claim reached, CMS’s return code in words, and which of the codes on the claim change it — and shows a trace of the grouping decisions in CMS’s published format. Where the grouper tables for that year are not loaded, it says the data is unavailable and shows nothing else: an estimate presented as a grouping would answer a question nobody asked. MedCoder is not certified, approved, endorsed, or operated by CMS.

Every finding quotes the official instruction it came from — deterministic, official-source, no AI-generated coding facts. This does not guarantee claim payment or prevent a payer denial. Payer-specific edits, Outpatient Code Editor logic, Local Coverage Determinations and medical-necessity policy beyond the published National Coverage Determinations are outside its scope.

Comparing just two codes? Use Compare Codes. Or look up a single code in the official registry.

Frequently asked questions

How many diagnosis codes can I check at once?

Up to 25. A professional CMS-1500 carries 12 diagnosis codes and an institutional claim carries 25 — a principal diagnosis plus 24 others — so the cap is the larger of the two and a whole institutional claim fits in one check. Every code is checked against every other, not just against the first.

What does Claim Check actually check?

14 kinds of check, all from official CMS data: excludes1 conflicts; excludes2 review items; same-category specificity; laterality; sequencing instructions; code also instructions; billable status; registry presence; missing 7th characters; principal diagnosis edits; age conflicts; date-of-service validity; poa reporting; cc/mcc severity and ms-drg context. Reported separately from those, and never merged with them into one verdict, are the CMS rules MedCoder holds: procedure-to-procedure edits; published utilization limits; modifier review; coverage policy; ms-drg grouping. Every finding quotes the official instruction it came from and names the CMS release it came from.

Why is one of my codes flagged as not billable?

Because it is a header (category) code rather than a leaf code — E11 instead of E11.9, for example. Header codes group their children and are not reportable as submitted: additional specificity is required before the code is reportable. The report lists the billable child codes underneath it so you can pick the one the documentation supports.

Does the date of service change the result?

Yes. ICD-10-CM changes every October 1, so the date of service determines which fiscal-year code set applies. Supplying it lets the report flag codes that were not valid on that date — an addition that had not taken effect yet, or a code that had already been deleted.

Does Claim Check cover payer edits, medical necessity or CPT?

Partially. It checks a code list against the official ICD-10-CM tabular rules, and — as separate checks, never one combined verdict — the Medically Unlikely Edits, NCCI procedure-to-procedure edits, and Medicare National Coverage Determinations that CMS publishes, all limited to HCPCS Level II because the CPT rows in those CMS files are AMA-licensed and not published here. Local Coverage Determinations are also licensed and not held, so they are never checked. Payer-specific edits and medical-necessity policy beyond the published NCDs remain outside its scope. A claim that passes every check here can still be denied on a policy this tool does not model.

Does Claim Check assign an MS-DRG?

It groups the claim rather than assigning one. Supply the inpatient details — the principal diagnosis, the secondary diagnoses with their present-on-admission indicators, the procedures, the sex and the discharge status — and MedCoder’s own implementation of CMS’s published MS-DRG grouper logic groups the claim against CMS’s published grouper tables for the fiscal year covering the date of service, showing the DRG it grouped to, CMS’s return code in words, which codes on the claim change the result, and a trace of the grouping decisions in CMS’s published format. No payment figure is shown beside the grouping. Medcoder.ai is an independent implementation of MS-DRG grouper logic based on CMS-published grouper software and documentation for the selected fiscal year. The implementation is version-specific and provides a trace of the grouping decisions so coders can review how the result was reached. Medcoder.ai is not certified, approved, endorsed, or operated by CMS. Results are coding decision support and should be independently reviewed. They do not predict reimbursement or payment. The implementation is verified against CMS’s published grouper software during validation, and the verification record is published at /how-we-verify. Where the grouper tables for that fiscal year are not loaded, the result says the data is unavailable and shows no grouping at all.

Should I paste patient information into it?

No. Do not enter protected health information. The tool needs diagnosis codes and, optionally, a date of service — never names, dates of birth, medical record or member numbers, or clinical narrative.