The Oncology LCD Is on Version 220

Novitas maintains a local coverage determination called Biomarkers for Oncology. It took effect on October 1, 2015, and it is currently on version 220.

Its published revision history lists 33 entries.

Both numbers come out of the same request, and you can run that request yourself in about four seconds with no login, no contract, and no scraper pointed at an ASPX page. CMS has operated an API over the Medicare Coverage Database since July 2024, and the coverage work most of us do by hand is already sitting behind it as JSON.

What is actually at api.coverage.cms.gov

The overview page describes the scope in one sentence: "comprehensive access to National and Local Coverage data available on the Medicare Coverage Database (MCD)."

The scope holds up. One call to the final-LCD report returned 977 rows this morning, twelve fields each, in a single page with no pagination token.

The article report returned 2,199. The NCD report returned 345.

The access model splits in two, and the split is the only thing you need to know before you start:

• Report and metadata endpoints take no key at all. No registration, no email, no application. A bare GET to /v1/reports/local-coverage-final-lcds came back 200 with 448,792 bytes of JSON.
• Document-level endpoints take a license token, which you get by calling /v1/metadata/license-agreement anonymously. The token covers the AMA CPT, ADA CDT and AHA NUBC agreements, lives for one hour, and rides in an Authorization: Bearer header. Calling /v1/data/lcd without it returns a 401 that says exactly that.

The build has come in five published releases. Local coverage reports in July 2024, national coverage reports that August, the national document endpoints in May 2025, then the piece that matters most for revenue cycle: on June 17, 2025, per-document LCD and article endpoints, 17 and 24 sub-resources respectively. Every release note carries the same line about deprecations. There are none.

The version number is the part nobody uses

Pull the 977 rows, drop the 112 marked retired, and you are left with 865 working policies carrying a document_version each.

The median is 22. The minimum in the whole library is 3, and 661 of the 865 are past their tenth revision (chart below).

That tail on the right is where the oncology policy sits, along with External Infusion Pumps at 171, Molecular Pathology Procedures at 156, and Genetic Testing in Oncology: Specific Tests at 149.

Now, the churn spreads unevenly across the calendar. Measured on updated_on against today, 444 of the 865 moved in the last year, 147 in the last 90 days, and 22 in the last 30.

So roughly half the library is genuinely live and the other half is sitting still, and the API tells you which half a given policy is in before you spend an analyst's afternoon reading it.

Which brings back the 220 against the 33. The version counter and the narrated revision history are two different fields, returned by two different endpoints, and they do not move together. /v1/data/lcd/revision-history gives you the entries a MAC wrote up; document_version gives you every stored version underneath them. External Infusion Pumps returns 16 revision entries against 171 versions. The MolDX hereditary thrombophilia policy that goes effective October 12 returns zero entries at version 3.

The code tables come back as rows

Here is where it stops being a curiosity and starts being an afternoon you get back.

Of the 2,199 local coverage articles, 1,236 are titled "Billing and Coding," and those are the documents whose diagnosis lists get re-keyed into edit engines and spreadsheets. The API returns them as records.

• The MolDX non-NGS targeted panel article, A60310, returns 680 covered ICD-10 rows.
• The non-invasive abdominal and visceral vascular study article, A57591, returns 609, plus its 6 HCPCS rows.
• Each row arrives with its code group, its description, its range flag and its own last_updated stamp.

icd10-noncovered, hcpc-modifier, revenue-code and bill-codes sit on the same article endpoint. So does code-table.

The week has a number too

The quietest endpoint is the useful one. /v1/metadata/update-period returns the capture windows the database itself is organized around: 52 of them, every one exactly seven days, every one beginning on a Monday, covering an unbroken 364 days with each window's end date equal to the next one's start.

The current window is period_id 1215, running August 17 to August 24.

That is the answer to the question anyone diffing coverage policy eventually asks, which is not what changed but when does CMS think it changed. The database publishes its own clock, and it publishes it without a key.

Final Thoughts

None of this is new capability. It shipped fourteen months ago with a release note, a Swagger file, and a listserv signup buried under an accordion labeled Application Development Organization Services.

The gap between what a payer publishes and what the industry actually reads is usually a discovery problem rather than a transparency one.

A coverage policy on its 220th version is telling you how much movement lives under a document you probably treat as static. The useful part is that CMS already counted it for you.

Thanks for reading.