OHDSI Home | Forums | Wiki | Github

CPT4 and HCPCS Procedure Modifiers

Are there a separate set of CPT4 and HCPCS procedure modifiers or is there one set of procedure modifiers that are applicable to both CPT4 and HCPCS codes? How has the vocabulary addressed this? My Googling comes up with

  • Level I Modifiers: Normally known as CPT Modifiers and consists of two numeric digits and are updated annually by AMA American Medical Association.
  • Level II Modifiers: Normally known as HCPCS Modifiers and consists of two digits (Alpha / Alphanumeric characters) in the sequence AA through VP. These modifiers are annually updated by CMS - Centres for Medicare and Medicaid Services

Vocabulary seems to have duplicated procedure modifiers in the CPT4 and HCPCS vocabularies. Can some describe how procedure modifiers should be applied and mapped?

As they come from the same official source and represent full duplicates (e.g. the codes and the names are the same) I’d simply use the modifiers according to their vocabularies. So, if you have CPT4 in your source data you would use CPT4 modifiers and HCPCS modifiers for HCPCS. And this is how the vendors would typically use them: they would use HCPCS modifiers if they use HCPCS vocabulary for billing.
If you have another vocabulary in your source data, I believe both are possible as long as you stick to one.

Well, why not to map them?
HCPCS to CPT4 modifiers, or vice versa? not sure which vocabulary is “more standard”.


There is a Themis job around it. Not sure where they are. Not part of the release I think. Let’s find out.

we’re thinking about NOT using CPT4 and HCPCS vocabularies for the modifier_concept_id mapping in the PROCEDURE_OCCURRENCE table - and instead, use qualifiers in SNOMED …thoughts? thx !

How does your source data code modifiers? Do they use HCPCS, CPT4, SNOMED or a custom vocabulary?

Yeah. There is an urgent need to clean up the Modifiers. They are a mess: Many HCPCS shares the CPT4 modifiers, but they are differently mapped and badly mapped, there is a lot of junk unrelated to patient data (Dmepos item subject to dmepos competitive bidding program that is furnished by a hospital upon discharge). We’ll do a consolidation workshop and come up with a solution. They have been popular with the community, lately. :slight_smile:

Let’s also touch them in OPCS4. They’re not located, can be used in coding as a mixture with the real procedures.

44517228 Z94.3 Left sided operation Procedure Standard Valid Procedure OPCS4
46233622 Z93 Other veins of pelvis Body Structure Standard Valid Spec Anatomic Site OPCS4

Was anything decided regarding modifiers?

I’m struggling to understand how to deal with modifiers that are assigned to different domains based on concept class (i.e., CPT4 modifier v. HCPCS modifier). I wasn’t able to infer a justification for different domains based on CPT and HCPCS codes in our source data associated with these modifiers.

Here’s a breakdown of domain assignment for the 148 modifiers (of 400+) that have different domains based on concept class:

Is this by design, or just part of the vocabulary that still needs a little TLC?


@DTorok, @Christian_Reich -
Just wanted to follow up on this.
Would be nice to get in cleaned up…

Hi @piper
We have 0 concepts within the Modifier Domain at the moment. The reason for this is that the clean up job is not done or even started.

At the same time, the Domains assigned to CPT4/HCPCS modifiers seems to look more or less correct, while the real modifiers (in OMOP sense) are vanished between the Domains. The rational behind this is that many CPT4/HCPCS modifiers imply the entire events (not just the modifiers in OMOP sense): Procedures, Devices, Providers, etc.

Unfortunately, this is the task of ETL at the moment to decide whether the CPT4/HCPCS modifier record worths only to be a modifier_concept_id of the associated procedure (if such exists and ends up in the Procedure Domain) or can be an entire event (if the Domain assigned has its own table). I haven’t heard about any heuristic applied around it. One of the options is to bring them to both places even creating some data duplication

We’ve recently looked into the issue, and the situation is like that:

I. Modifiers in the RWD are messy and mostly are:

  1. Service stuff (policies, levels of care, type of program, therapy plan, other circumstances).
  2. Laterality (uni/bi) / side (right/left).
  3. Detailed localization (very specific anatomic site).
  4. Topographic characteristic, such as superficial, surrounding, sagittal.
  5. Indication of distinct procedure/encounter vs part of other event.
  6. Doctor/laboratory qualification.
  7. Approach / access.
  8. Equipment used.
  9. Completeness (percent) of involvement/impairment.
  10. Anesthesia type.
  11. Route of administration.

II. In many cases 1 procedure in the sources comes with 2-5+ modifiers from different groups that almost prevents us from leveraging them throught the modifier_concept_id field.

III. The clean-up job we propose implies the following:

  • A. Making it non-Standard completely get rid of 1, 2, 4, 5, 6 bacause it has limited value in observational reserch.

  • B. Map over the following to the separate Measurement concepts and records (or leave the concept as Standard): 9. Will not be linked to the respective procedure in either vocabularies or CDM tables.

  • C. Map over the following to the separate Procedure concepts and records (or leave the concept as Standard): 10. Will not be linked to the respective procedure in either vocabularies or CDM tables.

  • D. Map over the following to the separate Device concepts and records (or leave the concept as Standard): 8. Will not be linked to the respective procedure in either vocabularies or CDM tables.

  • E. Map over the following to the Route concepts: 11. It would be a task of ETL to link them with the respective drug_exposure records.

  • F. Consider pre-coordination with the associated procedure within the OMOP Extension vocabulary. New concepts would be created as the hierarchical descendants of the associated procedure. We believe it makes sence to apply it only to 3, 7 and only under the use case-driven approach. What is beyond it, has to be throwen away as nonStandard concepts without mapping.

IV. Outline:

  • Sorting out and A jobs is probably a relatively small tasks.

  • B-E requires manual curation and fully depends on the number of the concepts in the buckets, but still sounds doable.

  • F is expected to be a huge task with mostly manual processing as it’s an authoring of a new content. But here we need an input from the community on the “accosiations”: what exactly requires a pre-coordination with the localization and approach. Otherwise, we end up with a permutational explosion and non-existing dummy concepts.

  • Once the consolidation is done, modifier_concept_id can be completely removed from OMOP.

P.s.: we also had a didicated triage session, and it turned out that procedural modifiers are not recognized as the top priority task, while it’s still of a considerable importance.

Thought? Objections?

Tagging @piper @DTorok @Christian_Reich @ellayoung @clairblacketer @burrowse @Mark_Danese @schillil @Patrick_Ryan @jenniferduryea @Richard_Starr @MPhilofsky @PatrickHosokawa @VanSamoa @MaximMoinat @spiros @QI_omop

What does domain_id tell us for procedure modifiers? I know that in evaluating a source procedure record, domain_id indicates what target CDM table it goes into but the appropriate use of domain_id for procedure modifiers is not clear to me. There’s only a space for procedure modifiers in Procedure Occurrence as far as I know so if I have a procedure record that belong in Procedure Occurrence but the modifier has a domain_id of Observation, what should I do with the modifier? @Christian_Reich

Maybe this would help answer your question:
so far modifiers can belong to different Domains and that is ok as long as the modifier represents the semantics correctly.

@TatianaSkugarevskaya Thank you. Your answer is helpful. It sounds like ignoring the domain_id of the modifiers is OK as long as we think the modifiers make sense.

@Alexdavv - I am documenting that THEMIS should dive into this a bit and document the resolution of what to do when multiple modifiers are provided by the raw data. THEMIS would need to review what was done by the Vocabulary team.

@ericaVoss I’m afraid we’ve done not that much apart from investigating the issue and drafting the proposal I published above

No, that is completely fine - I’m just documenting that it is an idea that needs to be prioritized and tackled.