Skip to main content

MS-DRG grouping

CMS-based MS-DRG grouping with explainable results. Given the inpatient details of a claim, MedCoder groups it against CMS’s published grouper tables for the fiscal year covering the date of service, and shows not only which MS-DRG the claim reached but how it got there and which codes changed it.

The explanation is the point

A DRG number on its own tells a coder very little. What makes a grouping useful is being able to see the path: which diagnoses and procedures the grouper read, which formula matched, what severity it evaluated, and what the result would have been without any one code on the claim.

So MedCoder reports the grouping alongside a per-code impact list — for every secondary diagnosis and every procedure, the claim is regrouped without it and the difference stated — and reproduces CMS’s own grouping trace verbatim rather than paraphrasing it.

How the grouper actually works

The port follows CMS’s own sequence rather than a simplified account of it. The outer chain runs preprocessing, an initial grouping pass, initial code marking, hospital-acquired condition processing, a final grouping pass, and final marking. Hospital-acquired condition processing sits between the two passes because it can change what the second pass sees.

Each grouping pass is itself five steps, in this order: pre-MDC grouping, a reroute, principal-diagnosis MDC grouping, a second reroute, and results. Severity is not a separate stage — it is recomputed inside the formula loop, once per candidate formula, because which secondary diagnoses count towards severity depends on the formula being tested. Medical or surgical is likewise a property of whichever formula matched, not a pathway chosen in advance.

Version awareness

The same claim can group differently under different grouper versions, and this is not an edge case. CMS ships a package per fiscal year and, for most years, a point release partway through it, so two dates of service within one fiscal year can be answered by two different packages. The formula tables, code attributes, cluster tables, exclusions and hospital-acquired condition lists are all read for one specific package version.

The date of service alone chooses the grouper. MedCoder never reads a clock, never asks what the current package is, and never falls back to the newest one — so a claim dated in a past year is answered by the grouper that governed it, or not answered at all. When the details on the form change after a claim has been grouped, the previous result is taken off screen rather than left standing beside inputs it did not answer.

What a grouping shows

Every value below comes from the grouper run, the package it ran against, or the CMS tables that package carries. A title CMS does not publish is reported as absent rather than invented.

  • MS-DRG and title — The DRG the claim grouped to, with CMS’s own description where the loaded tables carry it.
  • Base DRG — The base DRG the matched formula belongs to, with its description, before the severity tier is applied.
  • MDC — The Major Diagnostic Category reported for the grouping, with its description where held. The reported MDC is not always the principal diagnosis’s own: a rerouted claim reports the category CMS’s rules send it to.
  • Severity tier — Whether the claim evaluated to a major complication, a complication, neither, or none.
  • Medical or surgical — Read off the formula that matched, which is what determines it.
  • Return code — CMS’s own grouper return code, shown for every value and rendered in words. A return code of zero is as much a fact about a grouping as any other value.
  • Codes that move the result — For each secondary diagnosis and procedure, what the claim groups to without it: no change, a different severity tier, a different DRG, or a claim CMS returns.
  • Fiscal year and grouper version — The fiscal year covering the date of service and the CMS package version the claim was grouped against.
  • Grouping trace — CMS’s own trace of the run, reproduced as published rather than re-described.

The outcomes, and what each one means

A grouping either happened or it did not. There is no partial result, and no estimate is ever presented as a grouping.

  • Grouping result — The claim grouped. The DRG, base DRG, MDC, severity tier, medical-or-surgical designation and CMS return code are reported together with the trace and the per-code impacts.
  • Claim returned by the grouper — CMS’s grouper returned the claim rather than grouping it — an invalid principal diagnosis, an invalid discharge status, a sex-specific code against an unstated sex, or a hospital-acquired condition case. The return code is reported in words so the reason is legible on the claim in front of you.
  • Ungroupable — A real, reportable outcome rather than an error: CMS’s own ungroupable result for a claim its rules do not classify.
  • DATA UNAVAILABLE — no grouper for that fiscal year — MedCoder carries no CMS grouper package covering the date of service, so the claim was not grouped. No DRG, no estimate and no partial result is shown.
  • DATA UNAVAILABLE — tables not fully loaded — A package covers the date but its rule tables were not finished loading in this deployment. Reported as a gap rather than answered from incomplete tables.

The deliberate boundary

MedCoder is not certified by, endorsed by, approved by or affiliated with CMS. The grouper data is published by CMS as a work of the US federal government; the implementation reading it is MedCoder’s own, and a grouping it produces carries no CMS sanction.

No payment figure and no relative weight appear beside a grouping, deliberately. A money figure next to a real DRG reads as a price, and a grouping is a classification rather than a payment determination. MedCoder does not promise reimbursement and does not describe a grouping as a guarantee of payment.

A grouping runs only on the inputs a coder actually supplied. Nothing is defaulted silently — where a required input is missing, MedCoder says which one rather than filling it in and answering a different claim.

Where the grouper tables for the applicable fiscal year are not loaded, the answer is that the data is unavailable. An estimate dressed up as a grouping is the one failure this feature exists to avoid.

Grouping is an inpatient classification. It is kept separate from NCCI procedure-to-procedure rules, from utilization thresholds and from coverage policy, all of which answer different questions.

Inputs, source and versioning

Grouping uses the applicable inpatient information: the principal diagnosis and its present-on-admission indicator, the admitting diagnosis, secondary diagnoses each with their own present-on-admission indicator, ICD-10-PCS procedures, sex, discharge status, and whether the hospital is exempt from present-on-admission reporting. The order of the codes is preserved, because CMS’s own rules read them in order.

Secondary diagnoses and procedures are each capped at twenty-five entries. A claim over the cap is refused rather than truncated: silently dropping codes would answer a smaller claim than the one asked about, with nothing saying so.

The source is the CMS MS-DRG Grouper and Medicare Code Editor package, held as CMS’s own published rule sections. MedCoder records which package version each section came from and refuses to mix sections from different packages.

Every result names the CMS source it came from and the release version behind it, with the effective window that release covers and, where CMS publishes one, the rule’s own effective and deletion dates. A claim is evaluated against one release per source, never a mixture, and a release that does not cover the date of service is reported as not consulted rather than quietly skipped.

Frequently asked questions

Is this a run of CMS’s own grouper software?

No. The CMS grouper software itself is not distributed or run here. What MedCoder runs is its own implementation of CMS’s published MS-DRG grouper logic, against CMS’s own published grouper tables, and it says so on every grouping. Medcoder.ai is not certified, approved, endorsed, or operated by CMS.

Why does the date of service change the DRG?

Because it chooses the grouper. CMS publishes a grouper package per fiscal year and, for most years, a point release partway through, and the formula tables, code attributes, exclusions and hospital-acquired condition lists all belong to one specific package. Two dates that fall in different packages can classify the same clinical facts differently. MedCoder answers a claim with the package that governed its date, never with the newest one.

Does a grouping tell me what the claim will pay?

No, and no payment figure is shown beside one. A grouping is a classification of the stay, not a payment determination. What a claim actually pays depends on the hospital’s own rates and adjustments, which MedCoder does not model and does not display next to a DRG.

What does the per-code impact list tell me?

Which codes are doing the work. For every secondary diagnosis and every procedure on the claim, MedCoder regroups the claim without that code and states the difference: no change, a code that holds the severity tier, a code that changes the DRG outright, or a code whose absence makes the claim one CMS returns. It states what the grouper did, not what you should do about it.

Run this rule set on a code list with Claim Check, or see all CMS coding rules. Release versions and checksums are on the Data Sources page.