Medicare coverage policy
Medicare coverage policy asks a different question from coding correctness: not whether a code is right, but whether Medicare policy supports the service. MedCoder answers the part of that question its published sources can answer, and is explicit about the part they cannot.
- Find an LCD — Local Coverage Determinations, by code or keyword
- Find an NCD — National Coverage Determinations, by code or keyword
Current data releases:ICD-10-CM FY2027 · ICD-10-PCS FY2027 · HCPCS October 2026 · MS-DRG v44 · Medicare Code Editor v44.0 · NCCI PTP Q4 2026 · MUE Q4 2026 · NCD code lists 2026-01 · LCD export September 28, 2026 · All releases and sources
NCD and LCD
A National Coverage Determination, or NCD, is a coverage policy CMS issues that applies nationally. A Local Coverage Determination, or LCD, is issued by a Medicare Administrative Contractor and applies within that contractor’s jurisdiction. Both can govern whether Medicare covers a service; they differ in who issues them and where they apply.
MedCoder’s rule checks evaluate National Coverage Determinations. They do not evaluate Local Coverage Determinations, and every coverage result says so on its face rather than leaving a reader to assume one was evaluated. Claim Check’s separate LCD Policy Review identifies potentially relevant LCDs for a claim and lists them as review items — which policy to read, not whether its requirements are met.
LCD Policy Review is not an LCD coverage determination
LCD Policy Review: MedCoder can identify potentially relevant Medicare LCD policies from supported CMS policy data and provide access to policy details, jurisdiction, status, and effective dates where available. This is a policy-reference function, not a determination that an LCD’s medical-necessity or documentation requirements have been satisfied for a specific claim.
LCD coverage determination: Determining whether a particular service satisfies an LCD’s medical-necessity, documentation, frequency, or other coverage requirements. MedCoder does not perform this function and does not adjudicate claims; the applicable Medicare Administrative Contractor and the policy text do.
What coverage can depend on
Whether a Medicare coverage policy supports a service can turn on the policy itself, on the jurisdiction, on the date, on the diagnosis, on the service, on the documented coverage requirements, and on limitations the policy states. MedCoder reads the parts of that CMS publishes as structured data and links to the policy for the rest.
- The policy — which NCD is being asked about. MedCoder never chooses one on your behalf: a diagnosis checked against a policy nobody selected answers a question nobody asked.
- The diagnosis — whether the policy’s published code list identifies it, and under which of CMS’s own resolutions.
- The date — which loaded release covers the date of service, and whether the individual mapping was still in effect on it.
- The service — where CMS assigns a coverage status code to a supported HCPCS Level II code.
- The documented requirements and limitations — which live in the policy text, and which MedCoder links to rather than paraphrasing.
Jurisdiction, and why it changes nothing here
A jurisdiction or a place of service can be supplied, and MedCoder accepts both. Neither is used, and the result says as much. Both are ways of scoping a Local Coverage Determination, no rule check here evaluates an LCD for them to scope, and a National Coverage Determination applies nationally and is not narrowed by either value. Claim Check’s LCD Policy Review does not guess a jurisdiction either: it lists potentially relevant LCDs for every MAC, each with the MAC and states CMS lists for it.
So nothing MedCoder reports is filtered by a jurisdiction, and nothing it reports is specific to one. Saying that plainly is the point: an input silently ignored is worse than an input refused.
What a result shows
Coverage results identify the policy they came from and link to it, so the policy text itself remains the authority.
- Policy identifier — The NCD section number, for example 190.22.
- Policy title — CMS’s own title for the section.
- Policy type — National Coverage Determination. Local Coverage Determinations are never the source of a rule-check result; potentially relevant LCDs are listed separately, in Claim Check’s LCD Policy Review, as review items.
- Jurisdiction — Accepted and reported as accepted, but not applied — an NCD applies nationally, and no rule check here evaluates a jurisdiction-scoped policy for it to narrow.
- Effective date — The date the policy states, where it states one. Many NCD sections state none, and MedCoder reports that rather than substituting a transmittal date, which describes a CMS memo and not when a policy took effect.
- Diagnosis relationship — Where the policy’s published list identifies the diagnosis, and under which CMS resolution: codes covered, codes denied, or codes that do not support medical necessity.
- Service coverage status — Where CMS assigns a coverage status code to a supported HCPCS Level II code, with CMS’s own published label for it.
- Source and release — The coverage release the result was read from, with its effective window. Individual mappings carry their own termination dates where CMS publishes them.
- Policy link — A direct link to CMS’s own page for the policy.
The outcomes, and what each one means
The conservative reading is the correct one throughout. None of these outcomes establishes that Medicare will pay, and none of them establishes that it will not.
- COVERAGE SUPPORT FOUND — The policy’s published list identifies the diagnosis under CMS’s coverage resolution. It reports what CMS published; it is not a statement about how any particular claim will be handled.
- COVERAGE REVIEW — CMS directs that its own coverage instructions be consulted for the code, or leaves the code to local judgment. Either way the policy text, not MedCoder, holds the answer.
- CMS states the opposite of coverage support — The policy list or the coverage status table identifies the code under a resolution that is not coverage support — denied, not supporting medical necessity, or non-covered. A definite negative is not an absence, and MedCoder reports it as what it is.
- Not identified in this policy — The diagnosis does not appear in the list CMS published for the policy. A code’s absence from a published list does not establish non-coverage by itself; whether it does depends only on what the policy itself states.
- NO APPLICABLE POLICY IDENTIFIED — The coverage table assigns no coverage status code to the code. This reports what the release does and does not list. Failure to identify an applicable policy does not by itself establish coverage.
- DATA UNAVAILABLE — No policy was selected, no loaded release covers the date, the code belongs to a licensed set MedCoder does not carry, or MedCoder holds no published diagnosis list for the policy asked about. Each is reported with which of those it was.
- LCD requirements are not evaluated by these rule checks — Reported on every coverage result, whatever else it found. No rule check evaluates a Local Coverage Determination’s requirements, so no rule-check result can claim to reflect one. Potentially relevant LCDs are listed separately, in the LCD Policy Review, which does not evaluate their requirements either. The gap is MedCoder’s; it says nothing about what any Medicare Administrative Contractor has published.
The deliberate boundary
MedCoder does not say Medicare will pay, does not say Medicare covers a claim, and does not treat the absence of a policy as coverage. Failure to identify an applicable LCD or NCD does not by itself establish coverage.
Claim Check can identify potentially relevant CMS Local Coverage Determinations from available structured policy data. LCD findings are presented as review items and are not coverage or payment determinations. Users should review the actual CMS policy for applicable requirements.
Those LCD findings come from one relationship MedCoder holds: the ICD-10-CM code lists in the CMS Billing & Coding Articles linked to each LCD. Each LCD is checked against the date of service — a future or retired policy is not shown as in effect — and listed with its MAC and states, without guessing a jurisdiction. HCPCS codes are not matched, because MedCoder holds no LCD-to-HCPCS relationship, and finding no match is not a statement that no LCD exists. No rule check applies an LCD, and because an LCD might govern any service on any claim, that gap is reported on every coverage result. Full LCD policy text is searchable in Medicare LCD Policy Search.
The published diagnosis code lists MedCoder holds come from CMS’s laboratory NCD code list, which covers the laboratory sections of the NCD manual and no others. For any other policy MedCoder reports that it holds no list — never that the diagnosis is absent from CMS’s list, which would state MedCoder’s gap as CMS’s silence.
The full NCD manual is held for policy identity and text: section numbers, titles and the published wording. It carries almost no codes, so no code-to-policy relationship is ever inferred from a policy title.
Where CMS lists no coverage status code for a supported code, that is not a statement that CMS covers the service. Null is not coverage.
Data unavailable is its own answer. Data unavailable means MedCoder does not have sufficient supported source data to make that particular determination. It means MedCoder could not look, not that there is nothing to find — it is never the same as no rule, no coverage, or allowed.
Source and versioning
The CMS Medicare National Coverage Determinations Manual, for policy numbers, titles and text.
CMS’s published laboratory NCD ICD-10-CM code list, for diagnosis-to-policy mappings. Individual mappings carry CMS’s own termination dates where published, and MedCoder filters on them so a mapping CMS ended is never applied to a later date of service.
The coverage status codes CMS publishes in the HCPCS Level II release, reported with CMS’s own labels.
Every result names the CMS source it came from and the release version behind it, with the effective window that release covers and, where CMS publishes one, the rule’s own effective and deletion dates. A claim is evaluated against one release per source, never a mixture, and a release that does not cover the date of service is reported as not consulted rather than quietly skipped.
Frequently asked questions
Does MedCoder check Local Coverage Determinations?
It identifies them; it does not evaluate them. Claim Check can identify potentially relevant CMS Local Coverage Determinations from available structured policy data — the diagnosis code lists in the CMS Billing & Coding Articles linked to each LCD — checked against the date of service. LCD findings are presented as review items and are not coverage or payment determinations; users should review the actual CMS policy for applicable requirements. No rule check evaluates an LCD’s requirements, and every coverage result says so.
No policy was identified for my code. Is the service covered?
That does not follow, and MedCoder does not suggest it. Failure to identify an applicable LCD or NCD does not by itself establish coverage. What the result reports is what the loaded data does and does not list — and because MedCoder relates LCDs to diagnosis codes only, through CMS’s article lists, a policy that governs the service may exist entirely outside what MedCoder can see.
My diagnosis is not in the policy’s list. Does that mean it is not covered?
Not by itself. A diagnosis code’s absence from a policy’s published list does not establish non-coverage; whether it does depends only on what that policy itself states. MedCoder links to the policy for exactly that reason. Note also the different case: where MedCoder holds no published list for the policy at all, it says so rather than reporting the diagnosis as absent from one.
Why was the jurisdiction I supplied not used?
Because there is nothing here for it to scope. A jurisdiction narrows a Local Coverage Determination, no rule check evaluates one, and a National Coverage Determination applies nationally. The LCD Policy Review lists LCDs for every MAC rather than narrowing to a jurisdiction it cannot verify. The input is accepted and then reported as accepted-but-unused, so no reader assumes a result was filtered to their jurisdiction when it was not.
Run this rule set on a code list with Claim Check, or see all CMS coding rules. Release versions and checksums are on the Data Sources page.