Skip to main content

NCCI procedure-to-procedure rules

MedCoder provides supported CMS-derived NCCI PTP rules within its non-CPT data scope. Given two codes and a date of service, it reports whether the loaded release records a procedure-to-procedure relationship between them, which code CMS lists as Column 2, and what the modifier indicator on that row permits.

What an NCCI PTP rule says

CMS’s National Correct Coding Initiative publishes pairs of codes it does not expect to see reported together for the same beneficiary on the same date of service. The pair has a direction: one code is listed as Column 1 and the other as Column 2, and the Column 2 code is the one denied when both are reported without an appropriate modifier.

The direction is meaningful and MedCoder never normalises it away. CMS may publish a pair in one direction, in both, or in neither, so a pair is looked up in both orderings and the direction of whatever row is found travels with the result.

What the check needs

Two things, and neither is assumed. Without a care setting no comparison runs at all, because the applicable edits differ between practitioner, hospital outpatient and DME supplier claims and answering with the wrong file answers a different question. Without a date of service there is no release to resolve.

The programme is not asked for. MedCoder resolves it from what is loaded and covers the date: where both a Medicare and a Medicaid release cover it, Medicare is used, and the result says which.

Modifiers, and what MedCoder will not tell you

Where the indicator on a row permits it, a modifier may allow the two procedures to be reported separately — but only where the circumstances of the encounter support separate reporting. MedCoder does not recommend a modifier and does not tell a coder to append one. That judgment rests on the documentation and on applicable coding guidance, not on the presence of an edit.

What it does instead is state the question: review whether the services were separately reportable under the applicable coding circumstances. Where modifiers were submitted on the lines carrying the pair, the report says so and stops there — MedCoder holds no CMS-published list of the modifiers associated with a given edit, so it does not claim to know whether a submitted modifier is one of them.

What a result shows

Every field below comes off the CMS row that produced the result, or off the release it was read from. Nothing is inferred, and a field CMS did not publish is reported as absent rather than filled in.

  • Column 1 — The code CMS lists first in the pair.
  • Column 2 — The code CMS lists second — the one denied when both are reported without an appropriate modifier.
  • Correct Coding Modifier Indicator — CMS’s indicator for the row: 0 means no modifier permits separate reporting, 1 means a modifier may, and 9 means CMS has marked the edit not applicable.
  • Rationale — CMS’s own reason text for the edit, quoted as published.
  • Effective date — The date CMS gives for the row itself, shown for provenance.
  • Deletion date — The date CMS ended the row, where it published one. Absent while the row is current.
  • Release and version — The NCCI release the row was read from, with the effective window that release covers.
  • Programme and care setting — Medicare or Medicaid, and practitioner, hospital outpatient or DME supplier — the file the row came from. CMS publishes these separately and MedCoder never merges them.

The outcomes, and what each one means

Six outcomes, and the differences between them matter more than any one of them. Three of the six mean MedCoder looked and found nothing to raise; the other three mean something quite different.

  • PASS — MedCoder looked and the loaded release records no edit between these two codes, in either direction, for this date of service. It is a statement about the loaded release, not about the whole NCCI programme.
  • PTP EDIT — A rule applies and its indicator is 0, which admits no exception: no modifier permits the two procedures to be reported separately.
  • REVIEW MODIFIER — A rule applies and its indicator is 1. A modifier may permit separate reporting where the circumstances support it. This is a prompt to review, not a recommendation to append anything.
  • NO ACTIVE EDIT FOUND — A rule exists for the pair but its effective window does not include this date of service. It is shown rather than hidden, so a historical rule is never silently merged with the current ones.
  • NOT APPLICABLE — Either CMS marked the rule not applicable with an indicator of 9, or the claim carries fewer than two procedure codes and there is no pair to compare.
  • DATA UNAVAILABLE — The pair could not be checked: a code falls outside the code sets MedCoder holds, no release is loaded for the setting, no loaded release covers the date, or the care setting was not supplied. A gap on MedCoder’s side, never a statement that no rule exists.

The deliberate boundary

CPT is permanently outside MedCoder’s scope. The CMS files behind this rule set are keyed on both HCPCS Level II and CPT; only the HCPCS Level II rows are stored, and the CPT-keyed rows are counted and discarded at ingest. MedCoder therefore holds a supported subset of this rule set and never the whole of it, and a pair or code it holds no row for is a gap here — not a statement that CMS published nothing.

This means MedCoder does not contain the NCCI database and does not evaluate all NCCI edits. The rules it holds are the HCPCS Level II to HCPCS Level II relationships it is permitted to retain, and a pair involving a code from a licensed set returns data unavailable — which the result says in those words, naming the gap as MedCoder’s rather than CMS’s.

The number of rows excluded at that boundary is recorded at ingest as a data-scope metric, so the size of the gap is stated rather than hidden. It is a count of rows in a file. No excluded code is stored, indexed, displayed or published anywhere on this site.

Data unavailable is its own answer. 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.

An NCCI PTP result is a coding-relationship finding and nothing more. It is not a coverage determination, not a utilization threshold, and not a statement about payment.

Source and versioning

CMS National Correct Coding Initiative procedure-to-procedure edit tables, published quarterly. CMS distributes six independent files — Medicare and Medicaid, each for practitioner, hospital outpatient and DME supplier claims — and MedCoder loads and reports them as six separate sources.

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.

Each rule row carries its own effective window, which MedCoder filters on in addition to the release window. A row CMS ended before the date of service is reported as an inactive rule, never applied as though it were current.

Frequently asked questions

Does MedCoder contain the complete NCCI PTP edit tables?

No, and it does not claim to. The CMS files are keyed on both HCPCS Level II and CPT; CPT is licensed by the American Medical Association and is permanently outside MedCoder’s scope, so only the HCPCS Level II rows are stored and the CPT-keyed rows are counted and discarded at ingest. What MedCoder evaluates is a supported subset. Where a pair falls outside it the result is DATA UNAVAILABLE, which names the gap as MedCoder’s rather than implying CMS published no edit.

Will MedCoder tell me which modifier to use?

No. Where an edit’s indicator permits a modifier, MedCoder says that separate reporting may be permissible and asks you to review whether the services were separately reportable under the applicable coding circumstances. It does not recommend a modifier, because whether one is supported is a documentation question rather than a lookup. CMS recognises a HCPCS Level II subset — XE for a separate encounter, XS for a separate structure, XP for a separate practitioner and XU for a separate service — and MedCoder names those where relevant without instructing you to append any of them.

What does PASS actually mean here?

That MedCoder looked in the release loaded for the care setting and date of service you supplied, and it records no procedure-to-procedure rule between the two codes in either direction. It is a statement about that release and that pair. It is not a statement that the pair is correctly coded, that the service is covered, or that a claim will be paid.

Why does the care setting change the answer?

Because CMS publishes different tables for practitioner, hospital outpatient and DME supplier claims, and a pair edited in one is not necessarily edited in another. MedCoder does not pick a setting on your behalf: without one it reports that the check could not run, rather than answering from whichever file happened to be loaded.

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.