CPT Modifier Codes

[jturan]

The use of CPT Modifier Codes often affects the final negotiated rate, and allowing them to be included is crucial to fully understanding plan pricing. For example, radiologist professional claims often include the modifier code "26", which indicates only the reading of a scan. A value of "TC" indicates the technical component, which is the actual scan itself. No modifier code typically means a global bill, which includes both the professional and technical component. The presence and/or absence of these codes alongside relevant CPTs is used by both Medicare and Commercial claims in claims adjudication. Are there plans to include CPT Modifier Codes in the transparency file schemas?

[mikiltaylor]

I concur - the Modifier Code is critical to understanding actual prices. For example, one Radiologist will often have different negotiated rates for the same CPT depending on whether they're doing the read alone (26 modifier) or the global service (no modifier). How would those two be distinguished in the schema?

[Kam-cog]

I agree. The rules say that additional information can be given such as disclaimers, notes and anything as long as we try to add more meaning to the information we furnish .

[tdfow]

The schema doesn't seem to support the 'additional information'---so will the schema be updated to include anything for the 'notes' or additional info?

[mdill-1965]

I would tend to disagree. If you think about how this data is meant to be used, a member would not be requesting the pricing for individual components of a service. In your example, the member would not likely request the TC or the 26 components of a service separately.

I agree that for the purposes of billing, separate modifier components exist so individual components can be billed by the provider, but that does not change the use case for the member. The goal is to give the member a reasonable approximation of costs for desired services. Additionally, adding CPT Code/Modifier combinations will only serve to increase the volume of data contained with the files.

[adriennefranke]

Just want to reiterate how important these Modifier Codes are. Without them, we'll lose the full picture of the final rate. The fact that Medicare and Commercial claims use CPT Modifier Codes indicate that they are an important piece to the pricing puzzle. Just as an additional example, breast ultrasounds for both sides are sometimes billed simultaneously with bilateral modifier code 50. Without knowing that a particular fee schedule price is specific to bilateral reimbursement, that particular provider would look abnormally expensive.

[shaselton-usds]

Thanks for the feedback! We, CMS, are working through this example. Hope to have something that makes sense from an implementation standpoint soon.

[BonHadVan]

@shaselton - this issue is impacting multiple payers. Can we please get clarification?

Here is a CMS Example that shows 3 different rates based upon no modifier, modifier 26 and modifier TC:

HCPCS Modifier Short Description Non Facility Price
72020 X-ray exam of spine 1 view $25.12
72020 26 X-ray exam of spine 1 view $ 8.03
72020 TC X-ray exam of spine 1 view $17.10

If these were any other payer's rates, how would they be reported in the In-Network File?

[TimGallegos]

Since the MRF doesn't have a spot for modifier, wouldn't you just pick the non-modifier version each time?

[jamessiefke]

this would mean that you would be averaging out the billed/allowed amounts for different services. Reading a CAT Scan versus actual scan amounts would be vastly different and could not show the intended cost to the person searching the file.

Clarification by CMS would be greatly appreciated. @shaselton-usds @shaselton

[Ginger228]

@shaselton-usds - Is there an update on the modifiers?

[ryan-thomas-peterson]

@shaselton , @shaselton-usds Back in April there was suggestion that inclusion of modifier(s) was something that was "working through". Is this still on the horizon? Would love to see allowance for a billing code flagged as CPT or HCPCS allowing 7 (or 9) digits where the first 5 are the CPT / HCPCS and digits 6 and 7 would be a modifier (and 8 and 9 would reflect Modifier 2 if you go that far to help with some DME services).

[jonberkery-work]

This is really a tough one for me. My company has gone back and forth on the topic. I can see the benefit to both sides of the discussion. For now, since there is no location for modifier, we have proceeded with only providing "no modifier"\global reimbursement rates.

I agree modifiers could impact reimbursement rates, and I agree the idea is to present a complete picture to the "file consumer."

On the flip side, I can see how adding modifiers to the file would drastically increase the size of this file, making it more unmanageable for both the "file producer" and "file consumer," and possibly unusable - thus defeating the purpose of this file.

For the modifier examples above, regarding how my company handles them.....

• Professional and Technical modifiers (26 and TC) - when one of those modifiers is present the reimbursement rate to the provider is a standard, defined percentage of the global rate (aka - no modifier rate). The sum of the "26 Rate" and the "TC Rate" equals the global rate.

• For the bilateral modifier (50), and similar modifiers like assistant surgeon (80, 81, 82), and "partial service like" modifiers (52 - 56) - modifiers like those, and the reimbursement rates for modifiers like those gets deeper into the entire episode of service. I don't believe a single, static file like these machine readable files can properly reflect when\how those reimbursement rates are decided upon\chosen, since we have to consider the entire claim\service. I also think that is what "Phase 2" of this rule is meant to address (aka the Cost Tool)

Based on that information - my vote would be to not include\require modifier on the files, only include the global rate. Especially, while all of us make this first attempt at building a meaningful, and useable file for the "file consumer."

If it were to be decided that modifier was necessary and required, I would then suggest that it be placed within the negotiated price object in the schema, and not within the in-network\out-of-network object in the schema.

@BobSyracuse
@tdfow
@ryan-thomas-peterson
@shaselton-usds
@jturan
@adriennefranke
@TimGallegos

[tdfow]

@taylorpatriciab what is recommended for those other combinations? Would LOCAL Billing Code Type be used? LOCAL Billing Code seems to have unique definitions, so they too will have highly customization that may or may not be accurately conveyed. @shaselton Is there any guidance on how 'combinations' should be reported? Without a modifier reference, then only the rates without modifiers could be reported--as there wouldn't be anything to distinguish the other scenarios without some type of indication

[taylorpatriciab]

@tdfow Modifiers only apply to CPT and HCPCS procedure codes. For other combinations of industry standard codes, such as RC and ICD, LOCAL would be used and to your point, they are highly customized. LOCAL would also be used in those situations where industry standard codes are not used as the basis for contracted amounts @shaselton-usds we would also look to CMS to provide guidance

[ryan-thomas-peterson]

We have been working toward an implementation that includes modifiers with CPTs where they are specified explicitly in the underlying fee schedule. (26, TC, NU, RR, there may be a small handful of others). There will be other places where modifiers impact payment that we don't include (discontinued service, pre-op and post-op services, assistant surgery, team surgery, etc. We don't intent to include the variant for 50 modifier. If the decision doesn't change and we're forced to list only global rates we would pull all listings that have modifiers. The inability to distinguish if something was for a technical service or global service, a new item or rental would make the rates misleading and we'd rather not list them than list them implying the rate is globally defined.

[nmayle]

The final rule states that a billing code must be included in the machine-readable file:

https://www.law.cornell.edu/cfr/text/26/54.9815-2715A3
26 CFR § 54.9815-2715A3

(B) A billing code, which in the case of prescription drugs must be an NDC, and a plain language description for each billing code for each covered item or service under each coverage option offered by a plan or issuer; and

and the definition of billing code clearly includes CPT codes:

https://www.law.cornell.edu/cfr/text/26/54.9815-2715A1
26 CFR § 54.9815-2715A1

(iv) Billing code means the code used by a group health plan or health insurance issuer or provider to identify health care items or services for purposes of billing, adjudicating, and paying claims for a covered item or service, including the Current Procedural Terminology (CPT) code, Healthcare Common Procedure Coding System (HCPCS) code, Diagnosis-Related Group (DRG) code, National Drug Code (NDC), or other common payer identifier.

It seems like there is general agreement that modifiers are part of CPT and HCPCS coding and reimbursement.
And the AMA "CPT Manual" defines modifiers and their use:

https://www.cms.gov/files/document/chapter1generalcorrectcodingpoliciesfinal112021.pdf

The AMA "CPT Manual" and CMS define modifiers that may be appended to HCPCS/CPT codes to provide additional information about the services rendered. Modifiers consist of 2 alphanumeric characters.

So, to summarize:

• billing codes are required by the final rule in the machine-readable files,
• CPT codes are defined by the rule as a billing code
• modifiers are part of CPT codes,
  so, the schema should support modifiers.

The arguments that have been presented against them are:

• They will increase the size of the file and make it harder to produce the files and read the files
• Members won't use them when looking up procedures
• They aren't in the schema, so why add them

None of these arguments are very compelling since they don't address the requirements of the rule.
The machine-readable file was not intended for consumption by the general public, but intended for tool developers.
The size of the file is not a big issue for tools. The size of memory of computers and related devices is now quite large - the typical smart phone storage size is 64Gb.

Proposed solutions seem to be:

• Leave them out
• Just add a select subset of them
• Include them in billing_code field

How about instead just fixing the schema? If the modifiers are included in the billing_code field, it would be necessary to specify how they are included. Are they separated by a dash, no separator or by a space? I would hope that one goal of a standard like is to clarify ambiguities in format. If only a limited set of modifiers are included, care must be taken to include all that would change the charge or reimbursement.

[bryanbriegel]

The need to accommodate/require procedure modifiers is stated by the Departments in the Surprise Billing Interim Final Rule as well: "The Departments are of the view that it is important that the QPA methodology account for modifiers that affect payment rates under contracts with participating providers and facilities."

[shaselton-usds]

Modifiers are being introduced to both the in-network and allowed amount files in this PR: #334

[tdfow]

@shaselton-usds @nmayle for the 20 claim count rule, would both the procedure code and modifier value need to be considered to qualify for the Allowed Amount File for a given product, given provider?
So if the same procedure is used for 30 claims, where 19 claims have 1 modifier value and the other 11 have a different modifier for the same provider tin--then would this no longer meet the 20 claim count rule?
Or would the same procedure be the 20 claim count rule qualifier--then show the billed/allowed charges according to the modifier?

Based on the modifier being added to the negotiated price object in the In-Network schema, it seems the 20 claim count rule would only consider the procedure for the qualifying count--then publish all the billed/allowed charges that are applicable and adding modifier for the rates applicable. Can we get clarification on the handling of the 20 claim count rule?

[tdfow]

@shaselton-usds can you provide information in the upcoming webinar the timeline we should expect for Pull Requests that move from the originating branch to the develop branch to the master branch? There have been Pull Request closed but they are only in the develop branch and not master. It is my understanding the official CMS branch is master. Should we consider both develop and master official CMS schemas?

[tdfow]

@jturan @shaselton-usds @nmayle @taylorpatriciab @ryan-thomas-peterson
For the Allowed Amount Schema, the billing_code_modifier was added to the Allowed Amount object. Since the Billing Code is identified at the Out of Network Object and we know that there are certain billing codes that would allow modifiers and there could be differences in rates between those with or without claim modifiers, wouldn't the billing_code_modifier need to either be defined at the Out of Network Object level or the out-of-network_payments object level?

It seems that if you have a procedure that has some OON claims that meet the 20 claim count rule but different rates due to a modifier--if you include a modifier in the billing_code_modifier does that also mean that the payments ONLY are for the modifier published? If you have some claims without modifier and some with modifier, then do you have to repeat the same tin, service_code, billing_class & only payments associated without the modifier? It would seem if the modifier caused a different payment then Out-Of-Network Payment Object having the billing_code_modifier would possibly be a better placement. Thoughts? Or how are others handling the scenario of same billing code having different rates for OON claim with and without a billing code modifier?

[tdfow]

#361

[narayanan-sathiamoorthy]

@shaselton-usds
With respect to the newly added billing code modifier field, there is discrepancies on the name of the field:
For Allowed Amounts file:
Example and table description call out the field as: billing_code_modifier
JSON schema calls it out as: billing_class_modifier
XML schema doesn't have this field.

For INN file:
Example and table description call out the field as: billing_code_modifier
JSON and XML schemas call it out as: billing_class_modifier

Could you let us know which field name is accurate?

[shaselton-usds]

Thanks @narayanan-sathiamoorthy! PR with your observations here: #374

[tdfow]

@shaselton-usds Can you provide an update on this thread about the Allowed Amount Schema issues? Seems there are potential placement and schema related problems from the v0.10.1 schema changes published