OHDSI Home | Forums | Wiki | Github

Procedure Modifiers

CDM Builders
#1

We are trying to decide what to do with procedure modifiers in our data.
The problem (as usual) is that the corresponding procedure codes map to different domains, but only Procedure_occurrence table has the place for a modifier (modifier_concept_id).

Usually we solve this problem by mapping modifiers separately from procedure codes and then linking them in fact_relationship. But it looks really complicated for the end-user of data. Most likely no one will use fact_relationship to look for the related records.

Now we would like to go another way.
We looked at the pairs (procedure code - modifier) with top counts for each of the domain and we would like to do the following solutions:

Procedure - map all modifiers to modifier_concept_id field

Observation - ignore modifier data
Top examples:

  • Hospital outpatient clinic visit for assessment and management of a patient - Excepted service provided at an off-campus, outpatient, provider-based department of a hospital
  • Ground mileage, per statute mile - Bachelors degree level
  • Ambulance service, basic life support, non-emergency transport, (bls) - Bachelors degree level
  • Mobility: walking & moving around functional limitation … - Services delivered under an outpatient physical therapy plan of care
  • Travel allowance one way in connection with medically necessary … - Laboratory round trip
  • Ground mileage, per statute mile - Integrated mental health/substance abuse program

Measurement - ignore modifier data
Top examples:

  • Prothrombin time - Clia waived test
  • Blood count; complete (CBC), automated (Hgb, Hct, RBC, WBC and platelet count) … - Professional Component
  • Thyroid stimulating hormone (TSH) - Reference (Outside) Laboratory
  • Lipoprotein, direct measurement; LDL cholesterol - Distinct Procedural Service
  • Comprehensive metabolic panel This panel must include the following: Albumin (82040) Bilirubin … - Provider attestation that the hospital laboratory test(s) is not packaged under the hospital opps

Drug - map modifiers meaning route of administration to route_concept_id and ignore other modifiers
Top examples:

  • Injection, epoetin alfa, 100 units (for esrd on dialysis) - Administered intravenously
  • Injection, epoetin alfa, (for non-esrd use), 1000 units - Erythropoetic stimulating agent (esa) administered to treat anemia not due to anti-cancer radiotherapy or anti-cancer chemotherapy
  • Albuterol, inhalation solution, fda-approved final product … - Single drug unit dose formulation
  • Injection, epoetin alfa, 100 units (for esrd on dialysis) - Administered subcutaneously

Device - ignore modifier data
Top examples:

  • Oxygen concentrator, single delivery port, capable of… - Rental (use the ‘rr’ modifier when dme is to be rented)
  • Filter, disposable, used with positive airway pressure device - New equipment

Is it a good idea? What do you think?

#2

@nzvyagina,
A CDM module to support cancer research (accepted last week) includes extension of the MEASUREMENT table to support modifiers for multiple domains:

To explicitly link cancer diagnosis, treatment, or episode record to its modifier, we propose to add the following fields to the Measurement table:

Field Required Type Description
modifier_of_event_id No integer A foreign key identifier to the event (e.g. condition, procedure, episode) record for which the modifier is recorded.
modifier_of_field_concept_id No integer The concept representing the table field concept that contains the value of the event id for which the modifier is recorded (e.g. Condition_Occurrence.condition_occurrence_id).

For cancer use case, we are planning to use this extension to modify conditions (e.g. modifier grade of breast carcinoma diagnosis), procedures (e.g. modifier dose of radiotherapy procedure), and episodes (for one “vetted” set of episode modifiers).

I think this approach is applicable to the general procedure modifier use case you have described. Moreover, it supports more complex scenarios like multiple modifiers for one procedure. It’s also applicable to other domains.

#3

Option 2: Nothing stops you from adding columns to a table. Add a column to each table for the modifier_value and modifier_concept_id. OHDSI tools will not use it, but easier than trying to follow fact_relationship

#4

Friends:

Hold on a minute.

@rimma: these are modifiers for claims. Nothing to do with the cancer modifiers.
@DTorok: Non-standard. Can’t be utilized by any tool. Don’t encourage people to step out of line. :slight_smile:

Exactly. And your idea is head on: We discussed something like this previously. Let’s do what you are suggesting and put it into THEMIS as well. Can you ping them?

#5

@Christian_Reich
Modifiers are modifiers whether they modify procedures, diagnoses, or other events or whether they modify cancer-specific or other events. Why not apply the generic modifier approach to multiple use cases?

#7

BTW, where are with this measurement table extension?

#8

@rimma: No. Because the modifiers are defined by the CMS to characterize the claims. Has nothing to do with the type of clinical modifiers (attributes) that you are looking at. We define that.

#9

@Dymshyts
It was just ratified. We’ll be working with @clairblacketer on the implementation.

1 Like
#10

Thank you! I will ping Themis.

#11

The issue was addressed here. Please have a look.

t