DowncodedTwo Curl Commands to the Whole Coverage Database
CMS runs a free API over the Medicare Coverage Database, no key and no registration, and it publishes the declared reason behind every LCD revision. We spent an afternoon in it: of 183 LCD revisions last quarter, 98 declared an administrative reason and 27 declared a change to policy content.
Ask the CMS Coverage API for an LCD without a token and it refuses you in the most government way possible: an HTTP 401, with the full American Medical Association CPT license agreement pasted into the response body.
That reads like a wall. It is a turnstile.
The way through is one more GET, no key, no registration, no sales call. /v1/metadata/license-agreement/ returns the AMA, ADA and AHA agreements and a GUID. Drop the GUID into an Authorization: Bearer header, repeat the call that just refused you, and 48 fields of LCD 33797, Oxygen and Oxygen Equipment, come back on version 50.
Two requests, cold start to full policy text. No procurement, no vendor, no demo call.
What sits behind the turnstile
The Coverage API is the machine-readable face of the Medicare Coverage Database, and it has been quietly growing for two years. Release 1.1 in July 2024 opened the local coverage reports; 1.2 added national coverage a month later; 1.3, 1.4 and 1.5 through the middle of 2025 added document-level endpoints for NCDs, NCAs, MEDCAC meetings, technology assessments, and finally the LCDs and articles themselves.
That is 97 documented endpoints as of this week.
An API key was required at the start and CMS dropped that requirement on February 8, 2024. What is left is a 10,000 requests per second throttle, which is not a limit anyone reading this will find.
We pulled the corpus this morning to see what the reports endpoints actually hand over.
861 active final LCDs. 1,985 active local coverage articles. 102 proposed LCDs, 345 NCDs, and 144 contractor records with their contract numbers attached.
The endpoint that pays for the afternoon
A change alert answers the question "did L36690 change?" The expensive part of your week is the next question, and the API answers that one for free.
/v1/data/lcd/reason-change returns the reason the contractor declared for a revision. Run it against L36690, Wound Application of Cellular and/or Tissue Based Products, version 39, and you get back "Other (Annual Review )". The revision history endpoint is blunter: "Revision Explanation: Annual review, no changes."
So we did it at scale. We took every distinct LCD revision event in the 13 update periods ending August 31, 183 of them, and asked the API why each one happened (chart above).
98 of the 183, more than half, declared a purely administrative reason: a corporate name, a change in affiliated contract numbers, a typographical fix. 27 declared something touching policy content. Another 27 were annual reviews stating no change, 9 were retirements, and 22 returned no reason at all.
Sit with the 27 for a second. Provider Education/Guidance on Intravenous Immune Globulin and External Infusion Pumps, both paired with CPT/HCPCS code changes. Trigger Point Injections rewritten under "Creation of Uniform LCDs" plus "Other (reduce improper payment)". Facet Joint Interventions moving toward a uniform LCD across jurisdictions. That is a quarter's worth of genuine coverage movement, and it is a list you could read in ten minutes.
The 9 retirements deserve the same ten minutes. The 98 administrative ones are what your alerting tool made you read anyway.
A year of churn in 52 calls
/v1/metadata/update-period/ returns the 52 weekly snapshot windows CMS keeps online, and /v1/reports/whats-new/local/ takes any one of them. Fifty-two calls later you have every local coverage document added, revised or retired in a rolling year: 2,493 events, 1,703 articles and 790 LCDs, across eight contractor names.
The churn is lumpy in a way a monthly average hides completely (chart below).
Median week: 35 documents. Quietest week: 5, in early June. Loudest: 223, in the week ending July 20.
That spike is worth understanding before you staff up for the next one. 208 of the 223 carry the contractor name Wellpoint Federal, 187 of them with an effective date of 04/01/2026, and 184 stamped as updated on a single day, July 14. April 1 is the date National Government Services began operating as Wellpoint Federal across its ten states.
Wellpoint Federal's entire active set today is 88 LCDs and 124 articles. The rebrand touched essentially all of it at once, three and a half months after the fact, and CMS labeled all 77 of the LCD revisions "Change in Corporate Name."
A change feed alone shows you a policy avalanche. The reason code shows you a letterhead.
Where it stops, and what that costs you
Every document endpoint is addressed by document id. /v1/data/lcd/hcpc-code wants an lcdid, and there is no parameter for "show me every LCD that touches 93000."
If you want that index, you build it yourself by walking the 861 LCDs and 1,985 articles and pulling their code lists.
At 10,000 requests per second, walking 2,846 documents is a coffee break. Worth knowing before you scope it as a project.
One more thing to put on the calendar. /v1/metadata/local-data-schedule/ tells you exactly which snapshot you are reading, and right now that is data_captured_through 08/30/2026, refreshed_on_date 09/03/2026.
The API is fed by the same Thursday batch as the weekly MCD download, so anything a MAC posted since Sunday the 30th is not in there yet, no matter how many times you poll.
Final Thoughts
We have been pulling current_lcd.zip every Thursday like everyone else, and the API turns out to be the same data with the joins already done and the reasons attached. The reason codes in particular are the sort of field that exists because a contractor had to fill in a form, and it survived all the way into a public endpoint anyone can query.
None of this replaces reading the policy. It does tell you which fifteen percent to read first.
Thanks for reading.