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.
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 !
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
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:
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:
Service stuff (policies, levels of care, type of program, therapy plan, other circumstances).
Laterality (uni/bi) / side (right/left).
Detailed localization (very specific anatomic site).
Topographic characteristic, such as superficial, surrounding, sagittal.
Indication of distinct procedure/encounter vs part of other event.
Doctor/laboratory qualification.
Approach / access.
Equipment used.
Completeness (percent) of involvement/impairment.
Anesthesia type.
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.
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.
