How we verify

Medcoder.ai makes MS-DRG grouping inspectable by showing the versioned reference, grouping pathway, and verification status behind the result.

MedCoder does not ask you to trust a result. This page shows the reference the grouper was built from, the version of the implementation that produced your result, what a recorded comparison against CMS’s own grouper software found, and the reasoning path behind every answer — together with what has not been checked.

Which releases these figures are about

Every verification figure on this page was measured at CMS grouper package version V400, V401, V410, V411, V420, V421, V430, V431 and V440. A figure measured at one CMS release says nothing about another release, so no figure here is repeated under a release it was not measured at.

Every CMS grouper package this build loads is among the releases above.

The releases this repo knows of that no figure here is about: none. That is 0 of the 9 CMS grouper package versions this build recognises.

An uncompared release is a statement about what has been checked, not about whether its results are right. It has not been shown to disagree with CMS’s software either — it has not been asked.

What this result is

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 verification result

MedCoder’s MS-DRG grouper is written from scratch in MedCoder’s own software. It is checked by putting the same controlled claims to CMS’s own compiled grouper software and comparing the two answers field by field. On the committed corpus, every comparison matched: MedCoder and CMS’s software answered all 117 corpus claims identically on every compared field, at every one of the 9 CMS releases spanning FY2023 through FY2027.

THESE ARE CONTROLLED CLAIMS WRITTEN TO EXERCISE CMS’S GROUPING LOGIC, NOT A SAMPLE OF HOSPITAL CLAIMS. Every figure on this page is a verification result for that corpus. None of them is an accuracy rate for real-world claims, and none of them can be read as one: the corpus was built to reach particular branches of the grouper, so its composition says nothing about how often those branches occur in anyone’s casemix.

Corpus claims answered by both groupers, at each release: 117 claims × 9 releases = 1053 answer comparisons
Of those answer comparisons, how many matched on every compared field: 1053 of 1053 (100% of this corpus, at every release)
Comparisons in total, counting the decision traces and the counterfactuals as well: 2232 of 2232 matched
Differences left unresolved: 0
Differences accepted as known and allowed through: 0

What each number counts

Two totals appear on this page and they count different things. Neither is a subset of the other by accident, and they are never added together.

1053 answer comparisons

What it counts: Each of the 117 corpus claims, answered once at each of the 9 releases: 117 × 9 = 1053. Each comparison checks every field of the grouping, not the final MS-DRG alone.
How many matched: 1053 of 1053

2232 comparisons in total

What it counts: The answer comparisons above, PLUS a byte-for-byte comparison of CMS’s own decision trace for each claim, PLUS the counterfactual claims (the same claim with one code removed) compared separately. Three suites, each run at all 9 releases.
How many matched: 2232 of 2232

What exactly matched

An exact match here means both groupers produced the same value for every field below — not merely the same final MS-DRG. Two groupers can reach the same DRG by different routes, and a comparison that looked only at the answer would call that agreement. Comparing the intermediate fields is what turns "the same DRG" into "the same grouping".

This is also what makes the mutation test below meaningful: the defect it introduces changes one of these intermediate fields and never changes the final MS-DRG, so a comparison of the DRG alone would have reported a clean pass.

The final MS-DRG, and the initial one before any severity adjustment
The major diagnostic category (MDC), including the pre-MDC routes that bypass ordinary MDC logic
The base DRG the final DRG belongs to
Whether the claim took the medical or the surgical pathway
The severity of the final DRG — with MCC, with CC, or neither
The grouper return code and the flags CMS sets on the result
Each diagnosis’s function — how CMS classified it within the grouping
Each secondary diagnosis’s final severity usage — whether it counted as an MCC, a CC, or neither
Each procedure’s operating-room classification
Whether each procedure affected the grouping, and which cluster it contributed to
The hospital-acquired condition verdict for each diagnosis that carries one
The present-on-admission value CMS read for each diagnosis, and the return code it produced
CMS’s own decision trace for the claim, compared byte for byte after declared normalisations

How the comparison works

MedCoder does not call CMS’s grouper when you check a claim, and does not display a result CMS produced. The grouping logic is implemented independently in MedCoder’s own software, from CMS’s published definitions and its published grouper.

CMS’s software is used as a test oracle, and only in testing. The same controlled claim is put to both, and the two answers are compared field by field. CMS’s software is not part of MedCoder’s running service, is not shipped with it, and is not called on your behalf.

What you see when you check a claim is MedCoder’s own answer, labelled with the CMS release it was produced at and the build of MedCoder that produced it.

One controlled claim — the same diagnoses, procedures, POA values and patient attributes
↓ put to both, separately
CMS’s compiled grouper software (test only) → CMS’s answer and CMS’s decision trace
MedCoder’s own grouping engine (what runs in production) → MedCoder’s answer and trace
↓
Compared field by field, and the trace byte for byte. Any difference is a finding, never a rounding.

We tested the test itself

A verification harness that always reports a pass is not evidence of anything — it may simply be incapable of reporting a failure. So a known defect was deliberately introduced into MedCoder’s own engine to check that the comparison catches it.

The defect made one procedure code stop being reported as an operating-room procedure. That is the shape a real grouper defect takes: not a wholesale divergence, but one field of one stage going quietly wrong.

IT DID NOT CHANGE THE FINAL MS-DRG, WHICH IS THE POINT. A comparison that checked only the answer would have reported a clean pass on all 117 claims. Because the intermediate fields are compared, the run failed, named the stage, and named the claims.

The defect was reverted immediately afterwards and MedCoder’s production code is untouched by it. What is kept is the record of what the harness did when the defect was present.

What was broken, on purpose: One procedure code stopped being reported as an operating-room procedure (code-flags.ts)
Exact-match rate with the engine intact: 100% of this corpus — 1053 of 1053 answer comparisons
Exact-match rate with the defect present: 95.7265% of this corpus — 5 of the 117 corpus claims failed, at every release the run covered
What the run reported: Every failure at one stage — procedure marking — and in one major diagnostic category; every other per-stage rate unchanged at 100% of this corpus
Where the observation is recorded: tests/msdrg-differential-validation.test.ts
Did the final MS-DRG move?: No. Only the intermediate field moved — which is why comparing intermediate fields is what caught it
State of the code now: Reverted. The defect exists only in the record of this test

Where the agreement was measured, stage by stage

The figures below are from the V440 run (CMS version 44.0, FY2027). Every stage was compared on all 117 claims and every stage matched.

THE RIGHT-HAND COLUMN IS THE ONE TO READ CAREFULLY. It says how many of the claims actually reach that stage — a claim with no procedures cannot exercise procedure marking, and a claim with no hospital-acquired condition cannot exercise the HAC pass. A stage exercised by ten claims has been checked against CMS ten times, not 117. That is thinner evidence than the stages above it, and a small number there is a statement about coverage, not a failure.

Exact match — every compared field

Matched at V440: 117 of 117 compared (100% of this corpus)
Corpus claims that actually exercise this stage: 117 — every claim in the corpus reaches it

Input validation

Matched at V440: 117 of 117 compared (100% of this corpus)
Corpus claims that actually exercise this stage: 117 — every claim in the corpus reaches it

Diagnosis function

Matched at V440: 117 of 117 compared (100% of this corpus)
Corpus claims that actually exercise this stage: 117 — every claim in the corpus reaches it

MDC assignment

Matched at V440: 117 of 117 compared (100% of this corpus)
Corpus claims that actually exercise this stage: 103 of 117

CC / MCC severity

Matched at V440: 117 of 117 compared (100% of this corpus)
Corpus claims that actually exercise this stage: 79 of 117

Procedure marking

Matched at V440: 117 of 117 compared (100% of this corpus)
Corpus claims that actually exercise this stage: 42 of 117

Hospital-acquired conditions

Matched at V440: 117 of 117 compared (100% of this corpus)
Corpus claims that actually exercise this stage: 37 of 117

Present on admission

Matched at V440: 117 of 117 compared (100% of this corpus)
Corpus claims that actually exercise this stage: 38 of 117

Surgical hierarchy

Matched at V440: 117 of 117 compared (100% of this corpus)
Corpus claims that actually exercise this stage: 10 of 117

Final MS-DRG

Matched at V440: 117 of 117 compared (100% of this corpus)
Corpus claims that actually exercise this stage: 117 — every claim in the corpus reaches it

How broad is the corpus?

117 claims is a route-exercising verification corpus, not a statistical sample of hospital claims. Each claim exists to drive the grouper down a particular path so that CMS’s answer on that path can be compared. Nothing about how many claims take each path in the real world can be inferred from how many claims take it here — the proportions were chosen, not observed.

Stated plainly, so that no figure on this page is read as something it is not:

It supports no inference about real-world casemix.
It supports no inference about claim volume.
It supports no inference about payer mix.
It supports no inference about how often any condition or procedure occurs.
It predicts no accuracy rate on claims outside the corpus.
Surgical hierarchy is exercised by 10 claims only.
The pre-MDC routes — transplant, ECMO, tracheostomy, bone marrow and CAR-T, which CMS selects before ordinary MDC logic — are exercised by 7 claims, and reach only some of the pre-MDC DRGs CMS defines.
Patient age was not varied: every claim was put to CMS with an age of zero. See the age limitation below.

What MedCoder implements

MedCoder’s MS-DRG grouper is a TypeScript implementation of the grouping logic CMS publishes in its MS-DRG Grouper and Medicare Code Editor package, run over that package’s own rule sections. Given a claim it returns a DRG and base DRG, the major diagnostic category, the medical or surgical split, the severity, the grouper flags, and a per-code validity, present-on-admission and hospital-acquired-condition marking — together with a trace of the decisions that produced them.

It is a MedCoder implementation and the result is MedCoder’s. Running it is not a run of CMS’s own grouper software, which CMS publishes separately and which anyone can obtain and run against the same claims.

The implementation carries a version of its own, declared by a person rather than derived from a build. A test hashes every file of the engine and fails the build if the engine changes without that version changing, so a result’s version is a fact about the code that produced it rather than a label nobody maintains.

Implementation version this build declares: medcoder-msdrg-1.4.1
Engine source that version covers: src/lib/rules/msdrg (every TypeScript file, recursively), plus 2 modules outside it: src/lib/rules/msdrg-grouper-shared.ts and src/lib/rules/parsers/msdrg-drg-formulas.ts
Digest recorded over that source when the version was declared: 227ba299d548c1454f33c2881f8c76bc17971212d070e216118e7ae3a2e71757
Implementation versions declared so far: 8

The CMS-published reference material

CMS publishes the MS-DRG grouper and the Medicare Code Editor as a software package with its rule sections alongside, and publishes the grouping logic in the documentation that ships with it. Those are the reference this implementation was built from. They are works of the US federal government in the public domain, and the download link below is CMS’s own.

The package is measured before it is loaded — section by section, byte count by byte count, against figures taken from CMS’s published file, together with a SHA-256 of the whole file. After loading, a read-only script counts the rows that are in the database and compares them with those same measured figures. One of those figures is not checkable that way and is reported as not checkable rather than counted as a pass; it is published under known limitations below.

The acquisition record below is for CMS package V440 and for no other. A checksum is a claim about one specific file, so it is not repeated beside a release it is not about.

Published by: Centers for Medicare & Medicaid Services (CMS)
Document: MS-DRG Grouper and Medicare Code Editor (MCE) Java Standalone package, version 44.0 (V440)
Release recorded here: V440
Acquired as: ms-drg-mce-v44-java-jars.zip
SHA-256 of that file as loaded: 6fa0ea78bf56112312513dd8c13f2a2ce855ebc4acfe004766796cc37bcf8461
Published at: https://www.cms.gov/medicare/payment/prospective-payment-systems/acute-inpatient-pps/ms-drg-classifications-and-software

Fiscal year and version handling

CMS ships a grouper release per fiscal year and sometimes a mid-year revision within one. This build recognises 9 release version strings and answers claims at 9 of them, back to discharges on or after October 1, 2022. Which release answers a claim is decided by that claim’s own date of service, never by today’s date.

Those 9 releases are served from 3 loaded CMS packages, and the two counts are different on purpose. CMS publishes each grouper package carrying its own release’s rule data and every earlier release’s, so one loaded package can answer several releases. The list below names, for each release, the package its rule data is actually read from.

A date of service no registered release covers is refused rather than answered by a neighbouring year’s grouper. Substituting a fiscal year would answer a question about a different year while labelling the result with the year that was asked for, which is the release mixing this project forbids everywhere. Reading an earlier release’s rules out of a later package is not that: the rules are the ones CMS designated for the claim’s own year, and a result names the release and the package separately so neither is mistaken for the other.

CMS’s package version and MedCoder’s implementation version are different strings answering different questions: the first says which CMS release the rule data and the logic are modelled on, the second says which build of MedCoder’s own code produced the result. Every surface that emits a result carries both.

V440 — CMS designates it for fiscal year 2027, and it answers discharges on or after October 1, 2026. Its rule data is loaded from its own CMS package. Every verification figure on this page was measured at this release.
V431 — CMS designates it for fiscal year 2026, and it answers discharges on or after April 1, 2026 and before October 1, 2026. Its rule data is loaded from its own CMS package. Every verification figure on this page was measured at this release.
V430 — CMS designates it for fiscal year 2026, and it answers discharges on or after October 1, 2025 and before April 1, 2026. Its rule data is loaded from its own CMS package. Every verification figure on this page was measured at this release.
V421 — CMS designates it for fiscal year 2025, and it answers discharges on or after April 1, 2025 and before October 1, 2025. Its rule data is read from the loaded V440 package, which CMS published carrying this release’s rules as well as its own. Every verification figure on this page was measured at this release.
V420 — CMS designates it for fiscal year 2025, and it answers discharges on or after October 1, 2024 and before April 1, 2025. Its rule data is read from the loaded V440 package, which CMS published carrying this release’s rules as well as its own. Every verification figure on this page was measured at this release.
V411 — CMS designates it for fiscal year 2024, and it answers discharges on or after April 1, 2024 and before October 1, 2024. Its rule data is read from the loaded V440 package, which CMS published carrying this release’s rules as well as its own. Every verification figure on this page was measured at this release.
V410 — CMS designates it for fiscal year 2024, and it answers discharges on or after October 1, 2023 and before April 1, 2024. Its rule data is read from the loaded V440 package, which CMS published carrying this release’s rules as well as its own. Every verification figure on this page was measured at this release.
V401 — CMS designates it for fiscal year 2023, and it answers discharges on or after April 1, 2023 and before October 1, 2023. Its rule data is read from the loaded V440 package, which CMS published carrying this release’s rules as well as its own. Every verification figure on this page was measured at this release.
V400 — CMS designates it for fiscal year 2023, and it answers discharges on or after October 1, 2022 and before April 1, 2023. Its rule data is read from the loaded V440 package, which CMS published carrying this release’s rules as well as its own. Every verification figure on this page was measured at this release.

When CMS changed its answer, MedCoder changed with it

CMS’s own software answers 5 of the corpus claims differently at V440 (FY2027) than at the eight releases before it. MedCoder reproduced each of those changes at the release it applies to, rather than carrying the earlier answer forward.

A DIFFERENCE BETWEEN CMS RELEASES IS NOT AN IMPLEMENTATION FAILURE. CMS revises its grouper every year, and the same claim legitimately groups differently in different fiscal years. The question a verification run has to answer is whether the implementation follows the release that applies to the claim’s date of service — and these five claims are where that question has a visible answer.

cluster-met

What the claim exercises: cluster Z@0266 both choices present
CMS’s software answers, at V400, V401, V410, V411, V420, V421, V430, V431: MDC 8, DRG 467 (base 466), SURGICAL, CC, OK
CMS’s software answers, at V440: MDC 8, DRG 464 (base 463), SURGICAL, CC, OK
Did MedCoder follow the change?: Yes — matched CMS at every release, including the one where the answer changed

cluster-met--without-sdx0

What the claim exercises: counterfactual: cluster-met without secondary 0 (C7952)
CMS’s software answers, at V400, V401, V410, V411, V420, V421, V430, V431: MDC 8, DRG 468 (base 466), SURGICAL, NON_CC, OK
CMS’s software answers, at V440: MDC 8, DRG 465 (base 463), SURGICAL, NON_CC, OK
Did MedCoder follow the change?: Yes — matched CMS at every release, including the one where the answer changed

cluster-met-co

What the claim exercises: same under CODE_ORDER
CMS’s software answers, at V400, V401, V410, V411, V420, V421, V430, V431: MDC 8, DRG 467 (base 466), SURGICAL, CC, OK
CMS’s software answers, at V440: MDC 8, DRG 464 (base 463), SURGICAL, CC, OK
Did MedCoder follow the change?: Yes — matched CMS at every release, including the one where the answer changed

hac11

What the claim exercises: HAC 11 dx + procedure
CMS’s software answers, at V400, V401, V410, V411, V420, V421, V430, V431: MDC 5, DRG 264 (base 264), SURGICAL, CC, OK
CMS’s software answers, at V440: MDC 5, DRG 362 (base 361), SURGICAL, CC, OK
Did MedCoder follow the change?: Yes — matched CMS at every release, including the one where the answer changed

tie-proc-carrier--without-proc2

What the claim exercises: counterfactual: tie-proc-carrier without procedure 2 (0SU64JZ)
CMS’s software answers, at V400, V401, V410, V411, V420, V421, V430, V431: MDC 1, DRG 68 (base 67), MEDICAL, NON_CC, OK
CMS’s software answers, at V440: MDC 1, DRG 30 (base 28), SURGICAL, NON_CC, OK
Did MedCoder follow the change?: Yes — matched CMS at every release, including the one where the answer changed

The reference corpus

The comparison runs over a committed corpus of claims. Every claim, CMS’s recorded answer to it and CMS’s recorded trace for it are files in this repository, each with its own SHA-256, so the thing the figures were measured over is fixed and checkable rather than regenerated on each run.

The corpus is not only well-formed claims. Some of it exists to exercise refusals and edge cases: an invalid principal diagnosis, an invalid procedure, a discharge status CMS does not recognise, a sex that conflicts with the principal diagnosis’s own diagnostic category, and a claim that stops grouping altogether when one procedure is taken off it.

It also carries counterfactual variants — the same claim with one code removed — because “which codes move this DRG” is answered by regrouping, and a claim with a code removed is itself an ordinary claim that CMS’s software can be asked directly.

Claims in the committed corpus: 117
Of those, variants with one code removed, compared separately: 14
Corpus files, each carrying its own SHA-256: msdrg-oracle-corpus/claims.tsv, msdrg-oracle-v400/data.json, msdrg-oracle-v400/expected.jsonl, msdrg-oracle-v400/traces.txt, msdrg-oracle-v401/data.json, msdrg-oracle-v401/expected.jsonl, msdrg-oracle-v401/traces.txt, msdrg-oracle-v410/data.json, msdrg-oracle-v410/expected.jsonl, msdrg-oracle-v410/traces.txt, msdrg-oracle-v411/data.json, msdrg-oracle-v411/expected.jsonl, msdrg-oracle-v411/traces.txt, msdrg-oracle-v420/data.json, msdrg-oracle-v420/expected.jsonl, msdrg-oracle-v420/traces.txt, msdrg-oracle-v421/data.json, msdrg-oracle-v421/expected.jsonl, msdrg-oracle-v421/traces.txt, msdrg-oracle-v430/data.json, msdrg-oracle-v430/expected.jsonl, msdrg-oracle-v430/traces.txt, msdrg-oracle-v431/data.json, msdrg-oracle-v431/expected.jsonl, msdrg-oracle-v431/traces.txt, msdrg-oracle/data.json, msdrg-oracle/expected.jsonl and msdrg-oracle/traces.txt
SHA-256 over the corpus as a whole: 37c22f0aac9d51116117c8a260df56d01658605d847a3f2c3fd15dbe397854bb
CMS grouper package version the recorded answers were produced at: V400, V401, V410, V411, V420, V421, V430, V431 and V440

Automated comparison against CMS’s own grouper software

CMS publishes its grouper as Java software. MedCoder runs that software as a test oracle: every corpus claim is put to it, its answers and its trace text are recorded into the committed fixtures, and MedCoder’s own answer for the same claim is compared against the recorded one — field for field, and for the trace, byte for byte.

MedCoder’s answer matches the answer recorded from CMS’s own software on every claim in this corpus at V400, V401, V410, V411, V420, V421, V430, V431 and V440. That is a statement about this corpus at those releases and about nothing else.

Every CMS grouper package this build loads is among the releases above.

Those figures are counted from a per-case record committed beside them: src/lib/msdrg-verification-cases.json carries one row for each of the 2232 comparisons — the claim it was run on, the suite that ran it, the CMS grouper package it was run at, and how it came out. It references CMS’s own recorded answers and traces rather than copying them, so there is never a second copy of CMS’s answers to disagree with the first.

The comparison declares 4 steps that make two unequal spellings compare equal. Each carries the kind of difference it must still report, and a test of the same name proves it cannot absorb that kind. They are:

ungroupable-empty-title-is-absent — On an ungroupable result only, and on its three description fields only, CMS’s empty string compares equal to this implementation’s absent value. Everywhere else the two are different values, and a difference between two non-empty titles is always reported.
hac-usage-order — The hospital-acquired-condition usage numbers on a procedure are compared in ascending order, because CMS prints them by iterating a set whose order is an artefact of the run. Order only: a different set, a repeat or a different count is still a difference.
matched-attribute-order — On the single trace line listing the attributes a formula matched on, the list is sorted on both sides, so that one line is compared as a set. Every other byte of that line and every other line is compared exactly.
trace-attribute-order — Each list of attribute names a trace prints -- the mask an MDC was analysed with, and the attributes shown against each code -- is sorted on both sides, so each is compared as a list of names rather than in order. CMS printed them from an unordered collection until its fourth release and from a sorted one after, so its own order is a per-run artefact before that. The names, the counts and every other byte are compared exactly.

Comparisons run against CMS’s recorded answers at V400: 248
Of those, comparisons at V400 that produced zero differences: 248
Comparisons at V400 whose every difference is adjudicated and cited: 0
Comparisons at V400 carrying an unadjudicated difference: 0
Comparisons run against CMS’s recorded answers at V401: 248
Of those, comparisons at V401 that produced zero differences: 248
Comparisons at V401 whose every difference is adjudicated and cited: 0
Comparisons at V401 carrying an unadjudicated difference: 0
Comparisons run against CMS’s recorded answers at V410: 248
Of those, comparisons at V410 that produced zero differences: 248
Comparisons at V410 whose every difference is adjudicated and cited: 0
Comparisons at V410 carrying an unadjudicated difference: 0
Comparisons run against CMS’s recorded answers at V411: 248
Of those, comparisons at V411 that produced zero differences: 248
Comparisons at V411 whose every difference is adjudicated and cited: 0
Comparisons at V411 carrying an unadjudicated difference: 0
Comparisons run against CMS’s recorded answers at V420: 248
Of those, comparisons at V420 that produced zero differences: 248
Comparisons at V420 whose every difference is adjudicated and cited: 0
Comparisons at V420 carrying an unadjudicated difference: 0
Comparisons run against CMS’s recorded answers at V421: 248
Of those, comparisons at V421 that produced zero differences: 248
Comparisons at V421 whose every difference is adjudicated and cited: 0
Comparisons at V421 carrying an unadjudicated difference: 0
Comparisons run against CMS’s recorded answers at V430: 248
Of those, comparisons at V430 that produced zero differences: 248
Comparisons at V430 whose every difference is adjudicated and cited: 0
Comparisons at V430 carrying an unadjudicated difference: 0
Comparisons run against CMS’s recorded answers at V431: 248
Of those, comparisons at V431 that produced zero differences: 248
Comparisons at V431 whose every difference is adjudicated and cited: 0
Comparisons at V431 carrying an unadjudicated difference: 0
Comparisons run against CMS’s recorded answers at V440: 248
Of those, comparisons at V440 that produced zero differences: 248
Comparisons at V440 whose every difference is adjudicated and cited: 0
Comparisons at V440 carrying an unadjudicated difference: 0
Implementation version the figures were measured for: medcoder-msdrg-1.4.1
Figures measured on: 2026-09-14
Engine digest they were measured against: 227ba299d548c1454f33c2881f8c76bc17971212d070e216118e7ae3a2e71757

answers at V400

The question this comparison asks: Does this implementation answer each corpus claim exactly as CMS's own grouper software answered it -- DRG, MDC, severity, every grouper flag and every code's marking?
CMS grouper package version its figures are about: V400
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-oracle-regression.test.ts

trace at V400

The question this comparison asks: Does this implementation's decision trace, rendered in CMS's own trace format, match the block CMS's software wrote for the same claim, byte for byte?
CMS grouper package version its figures are about: V400
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-trace-regression.test.ts

counterfactuals at V400

The question this comparison asks: When one code is removed from a claim, does this implementation regroup it to the result CMS's software answered for that same shortened claim?
CMS grouper package version its figures are about: V400
Comparisons run: 14
Of those, comparisons that produced zero differences: 14
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-code-impact-oracle.test.ts

answers at V401

The question this comparison asks: Does this implementation answer each corpus claim exactly as CMS's own grouper software answered it -- DRG, MDC, severity, every grouper flag and every code's marking?
CMS grouper package version its figures are about: V401
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-oracle-regression.test.ts

trace at V401

The question this comparison asks: Does this implementation's decision trace, rendered in CMS's own trace format, match the block CMS's software wrote for the same claim, byte for byte?
CMS grouper package version its figures are about: V401
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-trace-regression.test.ts

counterfactuals at V401

The question this comparison asks: When one code is removed from a claim, does this implementation regroup it to the result CMS's software answered for that same shortened claim?
CMS grouper package version its figures are about: V401
Comparisons run: 14
Of those, comparisons that produced zero differences: 14
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-code-impact-oracle.test.ts

answers at V410

The question this comparison asks: Does this implementation answer each corpus claim exactly as CMS's own grouper software answered it -- DRG, MDC, severity, every grouper flag and every code's marking?
CMS grouper package version its figures are about: V410
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-oracle-regression.test.ts

trace at V410

The question this comparison asks: Does this implementation's decision trace, rendered in CMS's own trace format, match the block CMS's software wrote for the same claim, byte for byte?
CMS grouper package version its figures are about: V410
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-trace-regression.test.ts

counterfactuals at V410

The question this comparison asks: When one code is removed from a claim, does this implementation regroup it to the result CMS's software answered for that same shortened claim?
CMS grouper package version its figures are about: V410
Comparisons run: 14
Of those, comparisons that produced zero differences: 14
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-code-impact-oracle.test.ts

answers at V411

The question this comparison asks: Does this implementation answer each corpus claim exactly as CMS's own grouper software answered it -- DRG, MDC, severity, every grouper flag and every code's marking?
CMS grouper package version its figures are about: V411
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-oracle-regression.test.ts

trace at V411

The question this comparison asks: Does this implementation's decision trace, rendered in CMS's own trace format, match the block CMS's software wrote for the same claim, byte for byte?
CMS grouper package version its figures are about: V411
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-trace-regression.test.ts

counterfactuals at V411

The question this comparison asks: When one code is removed from a claim, does this implementation regroup it to the result CMS's software answered for that same shortened claim?
CMS grouper package version its figures are about: V411
Comparisons run: 14
Of those, comparisons that produced zero differences: 14
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-code-impact-oracle.test.ts

answers at V420

The question this comparison asks: Does this implementation answer each corpus claim exactly as CMS's own grouper software answered it -- DRG, MDC, severity, every grouper flag and every code's marking?
CMS grouper package version its figures are about: V420
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-oracle-regression.test.ts

trace at V420

The question this comparison asks: Does this implementation's decision trace, rendered in CMS's own trace format, match the block CMS's software wrote for the same claim, byte for byte?
CMS grouper package version its figures are about: V420
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-trace-regression.test.ts

counterfactuals at V420

The question this comparison asks: When one code is removed from a claim, does this implementation regroup it to the result CMS's software answered for that same shortened claim?
CMS grouper package version its figures are about: V420
Comparisons run: 14
Of those, comparisons that produced zero differences: 14
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-code-impact-oracle.test.ts

answers at V421

The question this comparison asks: Does this implementation answer each corpus claim exactly as CMS's own grouper software answered it -- DRG, MDC, severity, every grouper flag and every code's marking?
CMS grouper package version its figures are about: V421
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-oracle-regression.test.ts

trace at V421

The question this comparison asks: Does this implementation's decision trace, rendered in CMS's own trace format, match the block CMS's software wrote for the same claim, byte for byte?
CMS grouper package version its figures are about: V421
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-trace-regression.test.ts

counterfactuals at V421

The question this comparison asks: When one code is removed from a claim, does this implementation regroup it to the result CMS's software answered for that same shortened claim?
CMS grouper package version its figures are about: V421
Comparisons run: 14
Of those, comparisons that produced zero differences: 14
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-code-impact-oracle.test.ts

answers at V430

The question this comparison asks: Does this implementation answer each corpus claim exactly as CMS's own grouper software answered it -- DRG, MDC, severity, every grouper flag and every code's marking?
CMS grouper package version its figures are about: V430
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-oracle-regression.test.ts

trace at V430

The question this comparison asks: Does this implementation's decision trace, rendered in CMS's own trace format, match the block CMS's software wrote for the same claim, byte for byte?
CMS grouper package version its figures are about: V430
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-trace-regression.test.ts

counterfactuals at V430

The question this comparison asks: When one code is removed from a claim, does this implementation regroup it to the result CMS's software answered for that same shortened claim?
CMS grouper package version its figures are about: V430
Comparisons run: 14
Of those, comparisons that produced zero differences: 14
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-code-impact-oracle.test.ts

answers at V431

The question this comparison asks: Does this implementation answer each corpus claim exactly as CMS's own grouper software answered it -- DRG, MDC, severity, every grouper flag and every code's marking?
CMS grouper package version its figures are about: V431
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-oracle-regression.test.ts

trace at V431

The question this comparison asks: Does this implementation's decision trace, rendered in CMS's own trace format, match the block CMS's software wrote for the same claim, byte for byte?
CMS grouper package version its figures are about: V431
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-trace-regression.test.ts

counterfactuals at V431

The question this comparison asks: When one code is removed from a claim, does this implementation regroup it to the result CMS's software answered for that same shortened claim?
CMS grouper package version its figures are about: V431
Comparisons run: 14
Of those, comparisons that produced zero differences: 14
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-code-impact-oracle.test.ts

answers at V440

The question this comparison asks: Does this implementation answer each corpus claim exactly as CMS's own grouper software answered it -- DRG, MDC, severity, every grouper flag and every code's marking?
CMS grouper package version its figures are about: V440
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-oracle-regression.test.ts

trace at V440

The question this comparison asks: Does this implementation's decision trace, rendered in CMS's own trace format, match the block CMS's software wrote for the same claim, byte for byte?
CMS grouper package version its figures are about: V440
Comparisons run: 117
Of those, comparisons that produced zero differences: 117
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-trace-regression.test.ts

counterfactuals at V440

The question this comparison asks: When one code is removed from a claim, does this implementation regroup it to the result CMS's software answered for that same shortened claim?
CMS grouper package version its figures are about: V440
Comparisons run: 14
Of those, comparisons that produced zero differences: 14
Comparisons whose every difference is adjudicated and cited: 0
Comparisons carrying an unadjudicated difference: 0
Where the comparison is asserted: tests/msdrg-code-impact-oracle.test.ts

Regression testing

The comparisons are not a one-off exercise written up afterwards, and all of them are ordinary tests in this repository, run on every change, against the same committed fixtures. A change that moves any answer or any trace byte fails them, naming the claim and the field.

Two further tests keep the published record honest rather than the engine correct. The first hashes every file of the engine and compares the result against the digest recorded beside the implementation version: change the engine without declaring a new version and the build fails. The second regenerates the verification summary from the comparisons and compares it with the committed file field for field, so the figures on this page cannot survive the thing they count changing.

Hardcoding those figures was considered and refused. Nothing in this repository compares a typed number against the corpus, so a stale one would stay green indefinitely — which is exactly the unearned assurance this page exists to avoid.

Comparison suites re-run on every change: 27
Where they live: tests/msdrg-oracle-regression.test.ts, tests/msdrg-trace-regression.test.ts, tests/msdrg-code-impact-oracle.test.ts, tests/msdrg-oracle-regression.test.ts, tests/msdrg-trace-regression.test.ts, tests/msdrg-code-impact-oracle.test.ts, tests/msdrg-oracle-regression.test.ts, tests/msdrg-trace-regression.test.ts, tests/msdrg-code-impact-oracle.test.ts, tests/msdrg-oracle-regression.test.ts, tests/msdrg-trace-regression.test.ts, tests/msdrg-code-impact-oracle.test.ts, tests/msdrg-oracle-regression.test.ts, tests/msdrg-trace-regression.test.ts, tests/msdrg-code-impact-oracle.test.ts, tests/msdrg-oracle-regression.test.ts, tests/msdrg-trace-regression.test.ts, tests/msdrg-code-impact-oracle.test.ts, tests/msdrg-oracle-regression.test.ts, tests/msdrg-trace-regression.test.ts, tests/msdrg-code-impact-oracle.test.ts, tests/msdrg-oracle-regression.test.ts, tests/msdrg-trace-regression.test.ts, tests/msdrg-code-impact-oracle.test.ts, tests/msdrg-oracle-regression.test.ts, tests/msdrg-trace-regression.test.ts and tests/msdrg-code-impact-oracle.test.ts
What generates the published figures: scripts/generate-msdrg-verification-summary.ts

Trace generation

CMS’s software can print what it did: which diagnostic category it analysed under which mask, which formula matched on which attributes, what every code looked like at each step. MedCoder’s engine emits its own structured event at each of the same points, and a renderer turns those events into the same text format.

Reproducing CMS’s format is what makes byte equality checkable, and byte equality is what makes the trace evidence rather than commentary. So the byte-identical rendering stays available verbatim and is never rewritten to read better; the coder-facing view is a rendering beside it that names the step and expands a token.

The trace is MedCoder’s, generated by MedCoder’s renderer from MedCoder’s own events. It is not a recording of CMS’s software running, and headings that suggested otherwise were removed.

Trace comparisons run at V400: 117
Of those, traces identical byte for byte, under the one declared trace normalisation: 117
Where the comparison is asserted: tests/msdrg-trace-regression.test.ts

How mismatches are handled

A comparison that differs has two possible fates and no third. Either the difference is adjudicated — recorded with the CMS source line that makes CMS’s answer the one to leave alone, and with a review date after which the suite fails until someone looks again — or it is unresolved, and it is published as unresolved.

An accepted divergence narrows; it never exempts. An entry names the field or the line it excuses, and every other field of that claim is still asserted, so accepting one difference cannot switch off the checks around it. A citation below a minimum length is not accepted as a citation, and a review date cannot be set further ahead than a year.

Describing an unresolved mismatch as a match, or as an adjudicated difference without a citation, is refused. The published summary carries both lists, and the figures above count comparisons that produced zero differences — counted from the comparisons, never as the total minus the differences, because that subtraction is only true when the suite is green and a committed file cannot know whether it was.

The committed summary currently records neither kind.

Adjudicated differences recorded in the committed summary: 0
Unadjudicated differences recorded in the committed summary: 0

An edge case we found, and then closed: present on admission = W

CMS recognises eight present-on-admission values. One of them is W, “clinically undetermined”, which CMS treats as present on admission for this logic — its own return code HAC_STATUS_INVALID_MULT_HACS_POA_NOT_Y_W names W beside Y, so the value does real work in the hospital-acquired-condition pass rather than being decorative.

MedCoder implements W and treats it as present on admission. For a time nothing in the corpus exercised it, so everything known about that was MedCoder checked against itself — and that was published here, as a gap, because a gap that reports as covered is worse than a gap. It was found by the differential run rather than reported by a user.

It is now closed. Four claims carrying W — one on a hospital-acquired condition, one where the admitting value is unknown, one mixing W with another value across two secondary diagnoses, and one carrying W on the principal diagnosis — were put to CMS’s own grouper software at all nine releases and its answers recorded into the committed fixtures. Its software answers POA_RECOGNIZED_YES_POA for W on every one of them, at every release, which is what MedCoder already did. They are ordinary corpus claims now, counted in every figure on this page and compared field for field and trace byte for byte like the rest.

Is W implemented?: Yes — accepted, and treated as present on admission
Is W exercised by the corpus?: Yes — at all 9 releases
What CMS’s software answers for it: POA_RECOGNIZED_YES_POA — the same answer its software gives for Y
Did MedCoder agree?: Yes, on every compared field and on the decision trace, at every release
How the gap was found: By the differential run’s own coverage analysis, not by a report from a user

Known limitations

These are the parts of the method that are weaker than the figures above might suggest. Each names the committed file it was read out of, so it can be checked rather than taken on trust, and each is re-read by a test on every run so it cannot quietly stop being true.

Age is zero on every claim in the corpus, and no loaded release’s formulas read it

What it means: CMS’s grouper takes a patient age. Every claim in this corpus was put to CMS’s software with an age of zero years and zero days: the reference harness fills those three fields with literal zeros, and the corpus file has no age column to fill them from. MedCoder’s own claim carries no age either, so there is nothing to compare. What that does and does not mean was measured rather than assumed: at every loaded release, NOT ONE DRG formula row references the age atom, and no operand name in the corpus closures contains the word at all. So age cannot change which formula matches at any release this deployment serves, and the zero is not hiding a wrong DRG. What it does leave untested is anything CMS’s software may do with age OUTSIDE formula evaluation, which this corpus cannot see either way.
Where to check it: tools/msdrg-oracle/OracleMain.java (withAgeDaysAdmit(0), withAgeDaysDischarge(0), withAgeInYears(0)); tests/fixtures/msdrg-oracle-corpus/claims.tsv (column header row); src/lib/rules/msdrg/claim.ts (the claim carries no age field); src/lib/rules/msdrg/special-attributes.ts (invalid_age is dispatched and referenced by no formula); tests/fixtures/msdrg-oracle/data.json

One of CMS’s specially-dispatched atoms, invalid_age, is referenced by no formula in the compared release

What it means: CMS dispatches a closed set of named logic lists specially, and invalid_age is one of them. No formula in the compared release references it, so no comparison built from this corpus can reach it, whatever ages the corpus carried. It is implemented because CMS dispatches it, and it is recorded here rather than left to look covered.
Where to check it: src/lib/rules/msdrg/special-attributes.ts (SPECIAL_LOGIC_LISTS)

The trace records the branch that was taken, not the branches that were not

What it means: The decision trace is a log of the events CMS’s own grouper writes a trace line for: the claim, the codes at each stage, the MDC analysed under each mask, the formula that matched and on which attributes, the results, the hospital-acquired-condition pass and the markings. It records no surgical hierarchy step and no rejected candidate — a formula that was evaluated and did not match leaves no line, so the trace can show why the answer is what it is but not why some other DRG was not the answer.
Where to check it: src/lib/rules/msdrg/trace.ts (the MsdrgTraceEvent union)

One load-verification figure cannot be checked against the database, and is reported as not checkable rather than as a pass

What it means: Each CMS package is measured section by section before it is loaded, and a script then counts what is actually in the database and compares. One figure resists that: the number of CMS formula objects before this build expands them into per-fiscal-year rows. The table holds only the expanded rows, and re-collapsing them in SQL would mean asserting an equivalence nobody has established. So no figure is claimed for it: the run reports it as not checkable and does not count it as verified.
Where to check it: scripts/verify-msdrg-load.ts (the NOT CHECKABLE branch on distinctFormulas)

A recorded match is about this corpus and nothing outside it

What it means: The corpus holds 117 claims, written to exercise routes through CMS’s logic — each major diagnostic category, refusals, edge cases and claims with one code removed. It is not a sample of real claims and carries no claim volume, no payer mix and no clinical distribution. A match means this implementation and CMS’s software answered the same corpus claim identically. It is not a rate, and it is not a claim about a claim nobody has run.
Where to check it: tests/fixtures/msdrg-oracle-corpus/claims.tsv

The error route to DRG 999 carries no corpus claim, because it is unreachable in the compared release

What it means: CMS’s match route to DRG 999 is unreachable in the release the corpus was measured at — no diagnosis or procedure row carries the operand the route needs, and no diagnosis row carries the diagnostic category it needs, measured twice against the package’s own rule data. So no corpus claim reaches it, and a claim asserting otherwise would assert something its own note denies. It has to be re-measured at each release.
Where to check it: tests/fixtures/msdrg-oracle-corpus/claims.tsv (the header comment recording both measurements)

Nine releases are compared, but this corpus separates only the last two of them by DRG

What it means: CMS’s own software answered these claims at all nine of its published MS-DRG releases, and every answer and every trace matched. That is what was measured, and here is what it is worth. Put the corpus through the eight earlier releases claim by claim and the DRG is the same at each: only the step from CMS’s current package to its next one moves any claim, and it moves five. This corpus was hand-written to exercise the newest release’s logic, so the sameness is a fact about the CORPUS, not a finding that CMS left grouping unchanged for four fiscal years — the claims that would separate the earlier releases were never written. What the older releases’ coverage does establish is narrower and real: each release answers with its OWN titles (CMS renamed one of the nervous-system DRGs at the newest release, and the recorded answers show it), and the differences in CMS’s software before that release — how an uncharged hospital-acquired condition is reported, whether severity marking reads the suppression flag, which procedures count as operating-room ones, and four differences in the trace text itself — are compared against CMS’s own recorded output at eight releases rather than inferred from two. No figure on this page should be read as evidence that the grouping LOGIC differs where this corpus cannot see a difference.
Where to check it: tests/fixtures/msdrg-oracle-corpus/claims.tsv (the one corpus every release answered); src/lib/rules/msdrg/release-behaviour.ts (the per-release software differences, measured from CMS’s own bytecode); tests/msdrg-oracle-regression.test.ts (the per-release comparison)

The figures belong to the build that recorded them, not to the deployment serving you

What it means: The comparison figures on this page were recorded by one run of the comparison suites and committed with the build that ran them, on 2026-09-14, for implementation version medcoder-msdrg-1.4.1. Nothing is re-measured when this page is rendered. They are a record of a run, not a live statement about the code answering your claim right now.
Where to check it: src/lib/msdrg-verification-summary.json (generatedAt, implementationVersion, engineDigest)

What MedCoder does not claim

The positioning statement at the top of this page says what a MedCoder MS-DRG result is. This section says what it is not, item by item, because a refusal stated once in a paragraph is easier to skim past than a list.

That this is a run of CMS’s own grouper software. It is MedCoder’s implementation of logic CMS publishes, and CMS’s software remains available for anyone to run against the same claims.
That a result predicts payment: it does not. A DRG is one input to a payment calculation that also turns on a hospital’s own rates and adjustments, none of which is modelled here.
That a figure measured at V400, V401, V410, V411, V420, V421, V430, V431 and V440 says anything about another release. It does not, and this page does not repeat one under a release it was not measured at.
That the figures describe the deployment serving you. They are a record of one run, committed with the build that produced it, and nothing on this page is re-measured when it is rendered.
That a match on this corpus is a rate, a percentage of real claims, or a statement about a claim outside it.
That any of this replaces a coder’s review. A result is coding decision support and is stated as such wherever it appears.

Current verification status

A recorded snapshot, not a live measurement. It belongs to the build that committed it and changes when the engine, the corpus or the CMS releases covered change.

CMS releases covered: 9 — V400 through V440 (FY2023–FY2027)
Controlled claims in the corpus: 117
Answer comparisons: 1053, all matched on every compared field
Comparisons in total, with traces and counterfactuals: 2232, 2232 matched
Unresolved differences: 0
Known differences allowed through: 0
Mutation test: Passed — the deliberate defect was detected, named by stage, and reverted
MedCoder implementation version that produced this record: medcoder-msdrg-1.4.1
Engine digest it names: 227ba299d548c1454f33c2881f8c76bc17971212d070e216118e7ae3a2e71757
SHA-256 over the corpus as a whole: 37c22f0aac9d51116117c8a260df56d01658605d847a3f2c3fd15dbe397854bb
Verification run identifier: 654b8b6d35952d8287e166365e22bbcb160e4415f5c422807d348345f398f2da — sha256 over the corpus digest, the engine digest and the CMS releases compared, so it can be recomputed from this repository and checked against the value published here
Verification record generated: 2026-09-14

Version history

Two histories, kept apart because they answer different questions. The first is CMS’s: every grouper release this build answers a claim at, the fiscal year CMS designates it for, the loaded CMS package its rule data is read from, and whether any figure on this page is about it. The second is MedCoder’s: every implementation version this repository has declared, in order, as a full release note.

Each MedCoder release note records the implementation version and the date it was declared, the CMS grouper package versions its comparisons were run at and the fiscal year CMS designates each of those for, what logic was new and what changed, what moved in the test corpus, how many comparisons were run and how they came out, and the limitations published for that release.

None of it can drift from the code. The fiscal years are derived from the recorded package versions rather than typed; the limitations are named by id and their wording read from the list above; the comparison figures on the current release note are asserted against the committed verification summary, and the digest test asserts that the last entry is the version and engine digest in force. A superseded note is frozen deliberately: its figures were measured against a corpus and a summary that no longer exist, and re-deriving them from today’s would be reporting today’s work under an old release’s name.

CMS grouper release V440

Fiscal year CMS designates it for: 2027
Claims it answers: Discharges on or after October 1, 2026
CMS package its rule data is read from: V440 — its own package, loaded here
Verification figures on this page measured at this release: yes

CMS grouper release V431

Fiscal year CMS designates it for: 2026
Claims it answers: Discharges on or after April 1, 2026 and before October 1, 2026
CMS package its rule data is read from: V431 — its own package, loaded here
Verification figures on this page measured at this release: yes

CMS grouper release V430

Fiscal year CMS designates it for: 2026
Claims it answers: Discharges on or after October 1, 2025 and before April 1, 2026
CMS package its rule data is read from: V430 — its own package, loaded here
Verification figures on this page measured at this release: yes

CMS grouper release V421

Fiscal year CMS designates it for: 2025
Claims it answers: Discharges on or after April 1, 2025 and before October 1, 2025
CMS package its rule data is read from: V440 — CMS published that package carrying this release’s rules as well as its own, and it is the package loaded here. No data of its own was loaded for this release.
Verification figures on this page measured at this release: yes

CMS grouper release V420

Fiscal year CMS designates it for: 2025
Claims it answers: Discharges on or after October 1, 2024 and before April 1, 2025
CMS package its rule data is read from: V440 — CMS published that package carrying this release’s rules as well as its own, and it is the package loaded here. No data of its own was loaded for this release.
Verification figures on this page measured at this release: yes

CMS grouper release V411

Fiscal year CMS designates it for: 2024
Claims it answers: Discharges on or after April 1, 2024 and before October 1, 2024
CMS package its rule data is read from: V440 — CMS published that package carrying this release’s rules as well as its own, and it is the package loaded here. No data of its own was loaded for this release.
Verification figures on this page measured at this release: yes

CMS grouper release V410

Fiscal year CMS designates it for: 2024
Claims it answers: Discharges on or after October 1, 2023 and before April 1, 2024
CMS package its rule data is read from: V440 — CMS published that package carrying this release’s rules as well as its own, and it is the package loaded here. No data of its own was loaded for this release.
Verification figures on this page measured at this release: yes

CMS grouper release V401

Fiscal year CMS designates it for: 2023
Claims it answers: Discharges on or after April 1, 2023 and before October 1, 2023
CMS package its rule data is read from: V440 — CMS published that package carrying this release’s rules as well as its own, and it is the package loaded here. No data of its own was loaded for this release.
Verification figures on this page measured at this release: yes

CMS grouper release V400

Fiscal year CMS designates it for: 2023
Claims it answers: Discharges on or after October 1, 2022 and before April 1, 2023
CMS package its rule data is read from: V440 — CMS published that package carrying this release’s rules as well as its own, and it is the package loaded here. No data of its own was loaded for this release.
Verification figures on this page measured at this release: yes

MedCoder implementation medcoder-msdrg-1.0.0

Declared on: 2026-09-13
What changed: First declared implementation version. The engine it names is the one verified against the committed V440 oracle corpus; no grouping logic changed in the commit that declared it.
New logic: GroupedClaimAnswer carries `implementationVersion` beside CMS's `packageVersion`, so a result says which build of MedCoder's own grouper produced it and not only which CMS release it was answered against (src/lib/rules/msdrg/grouper-service.ts, 5300aa46c).
Changed logic: None — no behaviour a claim can reach was changed by this release.
Test corpus changes: None. The comparisons ran over the 113-claim V440 corpus already committed; this release added no claim, edited none, and re-recorded no answer of CMS's.
Claims in the corpus its comparisons ran over: 113
SHA-256 of that corpus: a93a0dcc622fb394fbcace4c5a87b3d42bc19aca41a6ff9e2eed948c225000b8
CMS grouper package the corpus comparison was run at: V440
Fiscal year that package is designated for: 2027
Comparisons run: 240
How they came out: 240 of 240 comparisons matched CMS's own grouper software at V440; 0 known differences, 0 unresolved mismatches
Known limitations published for this release: No limitations list had been published when this version was declared. The list published today is about the implementation in force today and is not back-dated onto a superseded release.
Engine digest it named: c2ae4bd6cb3792cf0c9f03ec68dfdbc39ba6a5fa023887c002a9ec625e0d4f1a

MedCoder implementation medcoder-msdrg-1.0.1

Declared on: 2026-09-13
What changed: renderCmsTrace no longer defaults its header. It defaulted to CMS_HARNESS_HEADER, which is right for the oracle and silently wrong everywhere else: a caller that omitted the argument rendered Java's null case id and the harness's zero ages as the claim's own facts. No grouping logic changed and the V440 corpus still matches byte for byte; the argument is now required so the compiler asks whose facts a trace states.
New logic: None — this release changed existing behaviour and added none.
Changed logic: renderCmsTrace's header argument is required rather than defaulted, so a surface rendering a trace must state whose claim it is describing instead of silently inheriting the oracle harness's null case id and zero ages (src/lib/rules/msdrg/render-cms-trace.ts, 7179fbd9a).
Test corpus changes: None. The same 113-claim V440 corpus, and CMS's recorded traces still matched byte for byte, which is what made this a PATCH rather than a MINOR.
Claims in the corpus its comparisons ran over: 113
SHA-256 of that corpus: a93a0dcc622fb394fbcace4c5a87b3d42bc19aca41a6ff9e2eed948c225000b8
CMS grouper package the corpus comparison was run at: V440
Fiscal year that package is designated for: 2027
Comparisons run: 240
How they came out: 240 of 240 comparisons matched CMS's own grouper software at V440; 0 known differences, 0 unresolved mismatches
Known limitations published for this release: No limitations list had been published when this version was declared. The list published today is about the implementation in force today and is not back-dated onto a superseded release.
Engine digest it named: 0db3fe9c316ff4b696d2af369dc42e073b3034187c1030b7991d2cf67817d56f

MedCoder implementation medcoder-msdrg-1.1.0

Declared on: 2026-09-13
What changed: The engine is fiscal-year-specific where CMS's own grouper is. Five behaviours differ between CMS package V431 and package V440 in the SOFTWARE rather than the data, and the engine was V440-shaped at every release: it reported a HAC number CMS retracts to 0, implicated a procedure by a HAC the claim did not meet, ran the whole HAC pass on a POA-exempt claim, and rendered CMS's V440 trace literals. All five are now keyed on the MsdrgVersion already threaded through the engine, in one measured table (msdrg/release-behaviour.ts). MINOR, not PATCH: answers and trace bytes move at every release before V440. V440 answers and traces are unchanged -- its oracle corpus still matches CMS byte for byte -- and V431's now match CMS as well, so the verification summary publishes both releases.
New logic: src/lib/rules/msdrg/release-behaviour.ts: one table, measured from CMS's own published software, of the behaviours that differ between grouper packages in the SOFTWARE rather than the rule data. Every release this deployment can serve has a row (a980b5775).
Changed logic: The hospital-acquired-condition pass is keyed on the release: an uncharged HAC's number is retracted to 0, a procedure is implicated only by a HAC whose status the claim meets, and the pass is skipped outright on a POA-exempt claim, at the releases where CMS's software does each (hac-evaluation.ts, hac-processor.ts, hac-rebuild.ts, group-claim.ts). The CMS-format trace renderer emits each release's own literals -- V431 writes neither V440's brackets nor V440's HAC run on the code-marking line -- instead of rendering every release in V440's shape (render-cms-trace.ts).
Test corpus changes: Two more of CMS's recorded answer sets joined the committed corpus, over the SAME 113-claim claims.tsv: package V431 in bde0d568f and package V430 in fe281524b, each produced by running CMS's own grouper software for that package over those claims. No claim was added or edited -- claims.tsv is byte-for-byte identical at all three releases -- so the comparison count went from 240 to 720 because there are three recorded answer sets to compare against, not because the corpus grew.
Claims in the corpus its comparisons ran over: 113
SHA-256 of that corpus: 95daf21ff74a36c34dc9177873fcaf0396c5b351f937ae0b6046167b2246c468
CMS grouper package the corpus comparison was run at: V430, V431 and V440
Fiscal year that package is designated for: 2026, 2026 and 2027
Comparisons run: 720
How they came out: 720 of 720 comparisons matched CMS's own grouper software at V430, V431 and V440; 0 known differences, 0 unresolved mismatches
Known limitations published for this release: Age is zero on every claim in the corpus, and no loaded release’s formulas read it, One of CMS’s specially-dispatched atoms, invalid_age, is referenced by no formula in the compared release, The trace records the branch that was taken, not the branches that were not, One load-verification figure cannot be checked against the database, and is reported as not checkable rather than as a pass, A recorded match is about this corpus and nothing outside it, The error route to DRG 999 carries no corpus claim, because it is unreachable in the compared release and The figures belong to the build that recorded them, not to the deployment serving you
Engine digest it named: b289c5032dca67c545d959a6f87d22e594c0f9897f6c5c3c5e844d298cc22da7

MedCoder implementation medcoder-msdrg-1.2.0

Declared on: 2026-09-14
What changed: The package a claim's rows are read from and the grouper release those rows are read at are two values rather than one. They were one string, correctly, while every loaded package answered for its own release alone; CMS's packaging is what parts them, because each package's blob carries its own release's rule data AND every earlier release's. The service now takes the release from the registry key that records which grouper covers the claim's date and the package from the ingest keys that record what was actually loaded, refuses a package older than the release it would be read at, and leaves the rest to the formula probe. MINOR, not PATCH: one registry arrangement that used to be refused outright now reaches that probe. No grouping logic changed and no answer or trace byte moved at any release CMS's software has answered -- V430, V431 and V440 all still match CMS on every corpus claim, and the published figures are unchanged.
New logic: src/lib/rules/msdrg-grouper-shared.ts declares MsdrgReleaseSelection -- the (package, release) pair -- with msdrgPackageCarriesVersion, the one ordering fact true of every CMS package without measuring one: a package cannot hold the rules of a release published after it. scripts/extract-msdrg-oracle-fixture.ts can cut a code closure from one package's blob at an earlier release's rules, stamping the rows with the package and filtering the year-keyed tables to the release, and records the pair in the fixture's own bytes when the two differ.
Changed logic: grouper-service.ts reads the grouper release off the package registry key and the package off the ingest keys that recorded a load, instead of using one string for both. The fiscal-year check stays asserted of the RELEASE, which is the value a fiscal year is a statement about. Ingest keys that recorded different packages, a package label this build does not know, and a package older than the release are each reported as incomplete tables before any read, exactly as they were before.
Test corpus changes: None that any published figure is about. The comparisons ran over the same 113-claim corpus at the same three releases, and claims.tsv, expected.jsonl, traces.txt and data.json are byte-for-byte unchanged at V430, V431 and V440. A fourth closure was added beside them, cut from the V440 package's blob at CMS's V421 rules (tests/fixtures/msdrg-oracle-v421/data.json), and it is PREPARED rather than measured: CMS's own grouper software has never answered the corpus at V421, so V421 is in no comparison, no figure and no published list.
Claims in the corpus its comparisons ran over: 113
SHA-256 of that corpus: 95daf21ff74a36c34dc9177873fcaf0396c5b351f937ae0b6046167b2246c468
CMS grouper package the corpus comparison was run at: V430, V431 and V440
Fiscal year that package is designated for: 2026, 2026 and 2027
Comparisons run: 720
How they came out: 720 of 720 comparisons matched CMS's own grouper software at V430, V431 and V440; 0 known differences, 0 unresolved mismatches
Known limitations published for this release: Age is zero on every claim in the corpus, and no loaded release’s formulas read it, One of CMS’s specially-dispatched atoms, invalid_age, is referenced by no formula in the compared release, The trace records the branch that was taken, not the branches that were not, One load-verification figure cannot be checked against the database, and is reported as not checkable rather than as a pass, A recorded match is about this corpus and nothing outside it, The error route to DRG 999 carries no corpus claim, because it is unreachable in the compared release and The figures belong to the build that recorded them, not to the deployment serving you
Engine digest it named: da7fa61f7100e62f155afb825784bce531b6033405b6f889b6acb83c4c2a7652

MedCoder implementation medcoder-msdrg-1.3.0

Declared on: 2026-09-14
What changed: Every one of CMS's nine published MS-DRG releases is now compared against CMS's own recorded answers and traces. Eight behaviours CMS changed in its SOFTWARE before its current package -- three in grouping and reporting, five in the trace text -- are carried per release, so an older release is answered in its own shape rather than in the newest one's.
New logic: release-behaviour.ts carries eight further measured differences between CMS's packages: whether the zero branch of the HAC rebuild reports every uncharged HAC or only the first (V400/V401 report one); whether severity marking reads DOWNGRADE_SEVERITY_SUPPRESSION at all (V400..V410 do not, so *_EXCLUDED_BY_DRG_LOGIC is a value those releases cannot answer); whether an operating-room procedure is one ON CMS's three OR lists or one NOT on its non-OR list (V400..V411 are the latter, so a code with no attributes is an operating-room procedure there); which collection the trace copies attributes into before printing them; whether the trace carries an `***Exclusion info:` block; whether the marking block is `***Affect Flag marking:` or `***Code Marking:`; whether the pre-MDC grouping step is traced at all and in which brackets; where clusters are traced and under which label; and whether the HAC block writes a procedure no HAC implicated. tests/fixtures/msdrg-oracle-v400, -v401, -v410, -v411 and -v420 hold CMS's own answers, traces and a code closure cut from the V440 package's blob at each of those releases' rules, and the three oracle suites run at all eight measured releases.
Changed logic: The claim corpus is committed ONCE, at tests/fixtures/msdrg-oracle-corpus/claims.tsv, instead of being copied into every release's fixture directory. Its bytes are unchanged (sha256 11d45722...), it is pinned in one place rather than once per release, and tests/msdrg-oracle-corpus.test.ts fails if a second copy appears anywhere under tests/fixtures/. The trace comparison declares a second order normalisation, trace-attribute-order: each list CMS writes with traceAttributes is sorted on both sides, because CMS copied those attributes into a plain collection at V400/V401 and a HashSet at V410/V411 before switching to a TreeSet at V420. At V420 and later it is the identity, so no covered release's comparison moved.
Test corpus changes: The same 113 claims, now answered by CMS's software at eight releases instead of three. V430, V431 and V440 did not move: their expected.jsonl, traces.txt and data.json are byte-for-byte what they were, and every one of their comparisons still matches. The corpus file itself is byte-for-byte unchanged and now lives at one path shared by every release, which is why the whole-corpus digest below differs from 1.2.0's: it is taken over the file set, and the file set grew by five releases' recorded answers.
Claims in the corpus its comparisons ran over: 113
SHA-256 of that corpus: e2d34156f0271e03fe6f202c6adfd27a4ae681ced91725c8c4111488fe0fd6e7
CMS grouper package the corpus comparison was run at: V400, V401, V410, V411, V420, V430, V431 and V440
Fiscal year that package is designated for: 2023, 2023, 2024, 2024, 2025, 2026, 2026 and 2027
Comparisons run: 1920
How they came out: 1920 of 1920 comparisons matched CMS's own grouper software at V400, V401, V410, V411, V420, V430, V431 and V440; 0 known differences, 0 unresolved mismatches
Known limitations published for this release: Age is zero on every claim in the corpus, and no loaded release’s formulas read it, One of CMS’s specially-dispatched atoms, invalid_age, is referenced by no formula in the compared release, The trace records the branch that was taken, not the branches that were not, One load-verification figure cannot be checked against the database, and is reported as not checkable rather than as a pass, A recorded match is about this corpus and nothing outside it, The error route to DRG 999 carries no corpus claim, because it is unreachable in the compared release, Nine releases are compared, but this corpus separates only the last two of them by DRG and The figures belong to the build that recorded them, not to the deployment serving you
Engine digest it named: 234b1c34b76a692c4ea9b45035c3b0e418b473d3b9501a25538557b91004609c

MedCoder implementation medcoder-msdrg-1.3.1

Declared on: 2026-09-14
What changed: V421 is measured. CMS's own grouper software has now answered the committed 113-claim corpus at every one of its nine published MS-DRG releases, and every answer and every trace matches this port's at all nine, with all four divergence allowlists still empty. V421 was the one release that had been PREPARED and not measured -- its closure was cut from the V440 package's blob to prove that a package and a release are two values -- and it needed no engine change to come in green, which is a result rather than an assumption: its row in release-behaviour.ts was written from CMS's bytecode with no corpus to prove it, and running CMS's own V421 component over those claims is the proof.
New logic: None — this release changed existing behaviour and added none.
Changed logic: None — no behaviour a claim can reach was changed by this release.
Test corpus changes: The same 113 claims, now answered by CMS's software at nine releases instead of eight. No claim was added or edited: claims.tsv is byte-for-byte the file it has been (sha256 11d45722...), and the eight releases measured in 1.3.0 did not move -- their data.json, expected.jsonl and traces.txt are byte-for-byte unchanged, their pinned digests are untouched, and every one of their 1,920 comparisons still matches. The comparison count went from 1,920 to 2,160 because there is a ninth recorded answer set to compare against, and the whole-corpus digest below differs from 1.3.0's because it is taken over the file set, which grew by V421's three files. CMS's recorded answers at V421 are byte-for-byte V420's expected.jsonl: this corpus separates neither release from the other, nor either from V430, by DRG -- the limitation already published on /how-we-verify.
Claims in the corpus its comparisons ran over: 113
SHA-256 of that corpus: b31e9410b76bee61483647e1388452de41b3f695bcbe84f1ac9c36b2e62e8f5a
CMS grouper package the corpus comparison was run at: V400, V401, V410, V411, V420, V421, V430, V431 and V440
Fiscal year that package is designated for: 2023, 2023, 2024, 2024, 2025, 2025, 2026, 2026 and 2027
Comparisons run: 2160
How they came out: 2160 of 2160 comparisons matched CMS's own grouper software at V400, V401, V410, V411, V420, V421, V430, V431 and V440; 0 known differences, 0 unresolved mismatches
Known limitations published for this release: Age is zero on every claim in the corpus, and no loaded release’s formulas read it, One of CMS’s specially-dispatched atoms, invalid_age, is referenced by no formula in the compared release, The trace records the branch that was taken, not the branches that were not, One load-verification figure cannot be checked against the database, and is reported as not checkable rather than as a pass, A recorded match is about this corpus and nothing outside it, The error route to DRG 999 carries no corpus claim, because it is unreachable in the compared release, Nine releases are compared, but this corpus separates only the last two of them by DRG and The figures belong to the build that recorded them, not to the deployment serving you
Engine digest it named: 234b1c34b76a692c4ea9b45035c3b0e418b473d3b9501a25538557b91004609c

MedCoder implementation medcoder-msdrg-1.4.0

Declared on: 2026-09-14
What changed: A claim from an earlier fiscal year is now answered out of the CMS package this deployment has loaded, instead of being refused for tables it already holds. CMS ships each grouper package carrying its own year's rules and every earlier year's, so the rows a fiscal 2023, 2024 or 2025 claim needs are inside the V440 blob -- but the registry key recording that load carries an effective window opening in the package's OWN fiscal year, so a claim dated before it resolved no table package and was reported as incomplete tables on a completely correctly ingested database. The grouper YEAR is still chosen by the claim's own date and by nothing else; what changed is only which loaded package's rows that year is read out of, and both values are reported separately on every answer.
New logic: grouper-service.ts asks a second, date-free question when the three required table keys record no load covering the claim's date: which package have ALL THREE keys recorded a load of, at any date, that can carry this claim's grouper year -- and of those, the newest. The claim's own date still wins whenever it answers: a package registered as effective for the date is the package the runbooks promoted for it, and the date-free question is never asked when it does. NEWEST is a measurement, not a preference. The same grouper year's rows are not interchangeable between packages -- a formula's text references attribute atoms numbered inside the package it was cut from -- and the package each year has actually been compared against CMS's software at is recorded in tests/helpers/msdrg-oracle-releases.ts: V400 through V421 out of the V440 package, V430 out of V430, V431 out of V431, V440 out of V440. Taking the newest loaded package that carries the year reproduces exactly that matrix, and tests/msdrg-grouper-service.test.ts asserts it release by release from that same table rather than from a restated list.
Changed logic: A claim whose fiscal year predates every loaded package's registered window is grouped rather than refused, provided a loaded package can carry its year and all three required keys record that package. Every other refusal is unchanged: an unregistered grouper release is still noRelease, a package that cannot carry the year is still tablesIncomplete, three keys naming three packages is still tablesIncomplete, and no answer is ever given at a neighbouring year's rules.
Test corpus changes: None. The same 113 claims, the same nine recorded answer sets, the same four empty divergence allowlists: claims.tsv, and every release's data.json, expected.jsonl and traces.txt, are byte-for-byte unchanged, and all 2,160 comparisons still match. This release changes which loaded package a claim's rows are read from, which the oracle suites hold fixed by construction -- each is handed one release's closure directly -- so it could not have moved a comparison, and did not.
Claims in the corpus its comparisons ran over: 113
SHA-256 of that corpus: b31e9410b76bee61483647e1388452de41b3f695bcbe84f1ac9c36b2e62e8f5a
CMS grouper package the corpus comparison was run at: V400, V401, V410, V411, V420, V421, V430, V431 and V440
Fiscal year that package is designated for: 2023, 2023, 2024, 2024, 2025, 2025, 2026, 2026 and 2027
Comparisons run: 2160
How they came out: 2160 of 2160 comparisons matched CMS's own grouper software at V400, V401, V410, V411, V420, V421, V430, V431 and V440; 0 known differences, 0 unresolved mismatches
Known limitations published for this release: Age is zero on every claim in the corpus, and no loaded release’s formulas read it, One of CMS’s specially-dispatched atoms, invalid_age, is referenced by no formula in the compared release, The trace records the branch that was taken, not the branches that were not, One load-verification figure cannot be checked against the database, and is reported as not checkable rather than as a pass, A recorded match is about this corpus and nothing outside it, The error route to DRG 999 carries no corpus claim, because it is unreachable in the compared release, Nine releases are compared, but this corpus separates only the last two of them by DRG and The figures belong to the build that recorded them, not to the deployment serving you
Engine digest it named: 227ba299d548c1454f33c2881f8c76bc17971212d070e216118e7ae3a2e71757

MedCoder implementation medcoder-msdrg-1.4.1

Declared on: 2026-09-14
What changed: The present-on-admission value W is measured. It was the one implemented behaviour with no CMS comparison behind it -- published on /how-we-verify as an open gap, found by the differential run's own coverage analysis rather than reported by a user, with four claims written and held outside the corpus precisely so that nothing counted them as coverage. Those four have now been put to CMS's own grouper software at all nine releases and its answers recorded. Its software answers POA_RECOGNIZED_YES_POA for W at every release, on every claim, which is what this port already did -- so the port needed no change, and that is a result rather than an assumption.
New logic: None — this release changed existing behaviour and added none.
Changed logic: None — no behaviour a claim can reach was changed by this release.
Test corpus changes: The corpus grew from 113 claims to 117. The four added are the POA W claims that had been parked in tests/fixtures/msdrg-oracle-pending/: W on a hospital-acquired condition, W with an unknown admitting value, W mixed with another value across two secondary diagnoses, and W on the principal diagnosis. The pending fixture and the test that asserted the gap was still a gap are both gone, replaced by tests/msdrg-poa-w-coverage.test.ts, which asserts the inverse: the corpus must go on carrying W, and CMS's recorded answer for it must go on being POA_RECOGNIZED_YES_POA. The 113 claims that were already there are byte-for-byte unchanged and every one of their recorded answers still matches; each release's expected.jsonl gained exactly four lines. Their traces.txt differ only in the order of the `**Matched on attributes:` lists, which is the declared matched-attribute-order normalisation's per-JVM-run HashSet artefact and is why re-recording them changes no comparison. Comparisons went from 2,160 to 2,232 because the corpus is larger, not because a release or a suite was added.
Claims in the corpus its comparisons ran over: 117
SHA-256 of that corpus: 37c22f0aac9d51116117c8a260df56d01658605d847a3f2c3fd15dbe397854bb
CMS grouper package the corpus comparison was run at: V400, V401, V410, V411, V420, V421, V430, V431 and V440
Fiscal year that package is designated for: 2023, 2023, 2024, 2024, 2025, 2025, 2026, 2026 and 2027
Comparisons run: 2232
How they came out: 2232 of 2232 comparisons matched CMS's own grouper software at V400, V401, V410, V411, V420, V421, V430, V431 and V440; 0 known differences, 0 unresolved mismatches
Known limitations published for this release: Age is zero on every claim in the corpus, and no loaded release’s formulas read it, One of CMS’s specially-dispatched atoms, invalid_age, is referenced by no formula in the compared release, The trace records the branch that was taken, not the branches that were not, One load-verification figure cannot be checked against the database, and is reported as not checkable rather than as a pass, A recorded match is about this corpus and nothing outside it, The error route to DRG 999 carries no corpus claim, because it is unreachable in the compared release, Nine releases are compared, but this corpus separates only the last two of them by DRG and The figures belong to the build that recorded them, not to the deployment serving you
Engine digest it named: 227ba299d548c1454f33c2881f8c76bc17971212d070e216118e7ae3a2e71757

Claim Check — Where this grouper actually runs. A grouped result there names the CMS release it was answered at, the CMS package its rule data came from, and the MedCoder build that produced it — the same three values this page reports on.
Data Sources — Every release file behind this page, with the publisher’s own download link and the SHA-256 of the copy MedCoder loaded.
CMS coding rules — The other public CMS rule sets MedCoder implements, each carrying its own release.

Every release file behind this page, with the publisher’s download link and the SHA-256 of the copy MedCoder loaded, is recorded on the Data Sources page.