US Medical Billing
Coding, Modifiers & Edits

NCCI Procedure-to-Procedure Edits: A Rule About a Pair

A procedure-to-procedure edit is not a judgment about a code. It is a statement about a pair of codes, and it has a direction: report both and the first is eligible for payment while the second is denied. Understanding it as a property of the pair rather than a fault in either code changes what a practice does about it — because half of these edits are not the kind everybody assumes they are.

Updated 9 min read

On this page

Key takeaways

  • An edit is a pair with a direction. The Column One code is eligible for payment; the Column Two code is denied. That outcome is the edit working, not a processing error.
  • The scope is narrow and specific: the same provider, the same beneficiary, the same date of service. Outside those conditions the edit does not apply.
  • CMS instructs that services must not be moved to different dates to avoid an edit, and frames it as a patient-safety and convenience question rather than a billing one.
  • The comprehensive/component model is only half the story. CMS calls that terminology a misnomer, because many edits are simply two codes that should not be reported together — not one contained in the other.
  • So you cannot infer an edit's reason from its existence. “This was not part of that” is an argument against one kind of edit and irrelevant to the other.
  • Whether an exception exists at all is a per-pair lookup, not a judgment. Where one does, the grounds are a separate encounter or a separate anatomic site, and the record has to support whichever is claimed.
  • Sometimes the right answer is neither a modifier nor an appeal, but a different code that describes the two services performed together.

What the edit actually says

The published tables are lists of code pairs that in general should not be reported together. Each pair has a Column One code and a Column Two code, and the mechanics follow from that ordering: where a provider reports both codes of a pair, the Column One code is eligible for payment and the Column Two code is denied. Nothing about that outcome indicates an error in processing. It is the designed result of reporting the pair.

Reading it as a property of the pair rather than of either code matters, because it reframes the question a denied second line raises. The question is not “why was this code rejected?” — the code is fine, and would have paid on its own. The question is “does this pair's rule apply to what actually happened here?”, and that has a small number of possible answers.

The scope is three conditions, all of which must hold

These edits are built around services provided by the same physician, to the same beneficiary, on the same date of service. All three. An edit pair reported for two different patients, by two unrelated providers, or on two different dates is not the situation the edit describes. That is worth knowing precisely, because it is also the boundary that tempts the wrong response — and CMS addresses that directly: physicians are not to inconvenience beneficiaries or increase risk to them by moving services to different dates in order to avoid an edit. The instruction is framed around the patient, not around the claim.

The model most coders carry, and why CMS calls it a misnomer

The standard explanation of these edits is that the Column Two service is a component of the more comprehensive Column One service — you do not bill the part separately from the whole. That explanation is true of many edits and it is where the program starts: services integral to another service are component parts of the more comprehensive one, and where those components have their own codes, the edit places the comprehensive service in Column One and the component in Column Two.

But the manual is unusually direct about the limits of that model. The table was originally called the comprehensive/component table, and CMS records that the name was a misnomer: although the Column Two code is often a component of a more comprehensive Column One code, that relationship does not hold for many edits, where the pair simply represents two codes that should not be reported together. The clear case is two alternative approaches to the same operation — neither is a component of the other, they are alternatives, and reporting both describes something that did not happen. A separate table of those once existed; in April 2012 it was folded into the same single table as the rest, which is why one list now holds two genuinely different kinds of relationship.

The consequence for how a practice argues

You cannot read an edit's reason off the fact that it exists, and the most common response assumes you can. “This service was not part of that one” is a sound argument against a component-type edit and simply beside the point against the other kind, where the objection is that the two codes describe incompatible accounts of the same episode. Working out which kind of pair you are looking at comes before deciding whether there is anything to say about it.

A third category sits alongside both: pairs flagged because using the Column Two code with the Column One code is treated as a coding error given the nature of the Column One procedure. The manual's own explanation of why that happens is worth carrying — a code's descriptor does not contain exhaustive information about the code, so a clinician unfamiliar with one can report it in a context it was never meant for. The edit is doing the work the descriptor could not.

When an exception exists, and what it rests on

Edits define when two codes may not be reported together except under special circumstances, and the special circumstances are narrow. Where a pair permits a modifier at all, the grounds are that the two procedures were performed at two different patient encounters or at two different anatomic sites. Not that they were different procedures — that is the near-universal misreading, and the X modifiers covers it along with the choice between the specific flags.

  1. Check whether an exception exists for this pair at all

    Every pair carries a correct coding modifier indicator saying whether the edit will accept a modifier. Where it will not, no modifier changes the outcome and the remaining options are a different code or nothing. Checking this first prevents a great deal of wasted work.

  2. Establish which ground actually applies

    A separate encounter and a separate anatomic site are different facts, proved by different things. Deciding which one is being asserted before selecting a modifier is the discipline; selecting a modifier first and reasoning backward is how unsupported claims get submitted.

  3. Confirm the record satisfies the modifier's own criteria

    CMS is explicit that a modifier must not be used to bypass an edit unless the proper criteria for that modifier are met, and that documentation in the medical record must satisfy them. The modifier is a claim about the record; if the record does not support it, the modifier is an unsupported assertion on a submitted claim.

  4. Ask whether a code exists for the two services together

    This is the option that gets skipped. Where both services genuinely were performed and the code set contains a code describing them as one combined service, reporting that code is the correct answer — not a modifier on the pair, and not an appeal. A pair that keeps recurring in a practice's edits is often a signal that a combined code is being missed.

Add-on codes usually carry no edits of their own

The tables generally do not contain edits for most add-on codes, and the reason is structural rather than permissive: an edit on the primary procedure is enough, because if an edit prevents payment of the primary code, the add-on is not paid either. A practice reading the absence of an edit as permission has the logic backwards — the add-on's fate is decided by the primary's.

What a procedure-to-procedure edit is not

  • It is not a duplicate edit. Duplicate logic matches one code against itself on the same date and provider. A procedure-to-procedure edit is about two different codes. The modifiers differ accordingly, which is the subject of the repeat procedure modifiers.
  • It is not a unit limit. Whether too many units of a single code were reported is a separate edit family with its own per-code values and its own adjudication rules.
  • It is not a statement about medical necessity. The edit does not question whether either service was appropriate. It says the pair is not separately payable, which is a coding and payment conclusion rather than a clinical one.
  • It is not a permanent property of two codes. The tables are revised on a published schedule. A pair that edits today may not next quarter, and vice versa — which is why the answer to “is this pair edited?” is always a lookup against the current table rather than something to memorize or to copy from a secondary source.

Where these should be caught

An edit found on a remittance has already cost a cycle. The same tables are published and can be applied before submission, which is what claim scrubbing is for — Pre-Submission Claim Validation covers that layer generally. The part worth checking is whether the practice's scrubber is running the current tables, because an edit set that is a quarter out of date fails silently in both directions.

Common questions

The payer denied the second code. Is that an error we should appeal?

Not on its own. Where a procedure-to-procedure edit exists for the pair and both codes were reported, the Column One code paying and the Column Two code being denied is the designed outcome. The question worth asking is whether the pair's rule applies to what actually happened: were the two services performed at separate encounters or separate anatomic sites, does that pair even permit a modifier, and does the record support the assertion. If none of those hold, the denial is correct and the useful response is to look at whether a combined code describes what was done.

Is the second code always a component of the first?

No, and CMS says so directly. The table was originally named the comprehensive/component table and the manual records that this was a misnomer — although the Column Two code is often a component of a more comprehensive Column One code, the relationship does not hold for many edits, where the pair simply represents two codes that should not be reported together. Two alternative approaches to the same operation are the clear case: neither contains the other. Since April 2012 both kinds sit in the same single table.

Can we perform the two services on different days instead?

Not as a way of avoiding the edit. CMS addresses this specifically and frames it around the patient rather than the claim: physicians are not to inconvenience beneficiaries, or increase risks to them, by performing services on different dates of service in order to avoid an edit. Where separate dates are clinically right they are clinically right, and the edit — which is scoped to the same date — does not arise. Splitting dates for the edit's sake is the thing being ruled out.

Does a modifier always get both codes paid?

No, and there are two separate gates before it could. First, whether the pair admits a modifier at all is recorded per pair in the published files; where it does not, no modifier changes anything. Second, where a modifier is permitted, its own criteria still have to be met — CMS states that a modifier must not be used to bypass an edit unless the proper criteria are met and that documentation in the medical record must satisfy them. A modifier appended without either check is an unsupported assertion, and the fact that a claim pays does not make it supported.

Why do add-on codes rarely appear in the edit tables?

Because an edit on the primary procedure already does the work. CMS explains that edits related to the primary procedures are generally adequate, since if an edit prevents payment of the primary code, the add-on is not paid either. The program does include edits for some add-on codes where the primary-procedure edits need supplementing. The mistake to avoid is reading the general absence as permission — an add-on code's payment follows its primary's, whether or not the add-on has an edit of its own.

Key terms in this article

Defined once, on their own pages.

Continue learning

The modifier layer above these edits, and the neighboring edit families.

Authoritative sources

  • CMS — Medicare NCCI Policy Manual, Chapter I: General Correct Coding Policies (opens in a new tab)

    States that each edit is a pair with a Column One and a Column Two code, and that where both are reported the Column One code is eligible for payment and the Column Two code is denied; that the original comprehensive/component name for the table was a misnomer, because for many edits the pair simply represents two codes that should not be reported together rather than one containing the other; that the separate mutually exclusive table was folded into the single edit table in April 2012; that the edits are scoped to the same physician, beneficiary and date of service, and that services must not be moved to different dates to avoid them; that where an edit permits a modifier the grounds are separate patient encounters or separate anatomic sites, that a modifier must not be used unless its own criteria are met, and that the medical record must satisfy those criteria; and that most add-on codes carry no edits of their own because an edit preventing payment of the primary procedure also prevents payment of the add-on.

Ready to improve your revenue cycle?

Tell us about your practice and we’ll tell you where we would start.

Request a consultationBrowse the Knowledge Base