CPT4 and HCPCS Procedure Modifiers

[Alexdavv (Alexander Davydov)]

@piper

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.

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

@piper

Would be nice to get in cleaned up…

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