OHDSI Home | Forums | Wiki | Github

Procedure Occurrence Modifier

CDM Builders
#15

Hi Richard:

Are these cost modifiers, or clinical modifiers (if you can tell)? Or maybe something related to procedure quantity? Maybe all of the above? It would just be educational to know what people are seeing with modifiers/qualifiers. And what kinds of vocabularies they are modifying (e.g., procedures, drugs, diagnoses, etc.)

Mark

#16

…and most importantly , does someone have an analytical use case that
requires using these modifiers?

#17

Thanks @Richard_Starr! That is a novel way of solving the problem. So that I understand your solution, is this what you’re doing for (example) an assistant surgeon cataract surgery done on the right eye:

Raw Data:
CPT = 66984
Modifier 1 = 80
Modifier 2 = RT

Procedure_occurrence record:
procedure_source_value = 66984
qualifier_source_value = 80,RT
modifier_concept_id = 0

Getting to what @Mark_Danese was asking about, does EPIC have CPT/HCPCS modifiers assigned to procedures (CPT or HCPCS) available in EPIC data? Does EPIC use CPT and HCPCS vocabularies? I am familiar with EPIC but I have never seen the data available to researchers and I’m just curious. I heard that all codes entered in EPIC were mapped to SNOMED. But, I have never independently verified this.

@Patrick_Ryan, for a use case (or why modifiers are even important), please see my comment earlier in the post: Procedure Occurrence Modifier

1 Like
#18

Friends:

Could anybody (@burrowse, @schillil, @mark_danese, @jenniferduryea, @Richard_Starr) be so kind and fill out a proposal form plus use case here.

#19

The data I am working with has already been extracted from the EPIC systems and consolidated into a research data warehouse, so I am not exactly sure about how the data is represented on the EPIC side. I am getting mostly CPT4 and HCPCS in the procedures data. They are coming as a single procedure ( mapped to an epic_procedure_id mapped to the cpt4 or hcpcs code ) with comma separated modifiers in one field. Some of the modifiers are not mapped in OMOP. I am seeing codes for X1, X2, X3, … These seem to be mainly related to imaging, but do not correlate to number of views in the CPT description. Could this be the number of times the procedure happened?

Here is an example:
CPT: 73590 ( Radiologic examination; tibia and fibula, 2 views )
modifiers: 26, X2, RT
26= Professional Component
X2= ??
RT= Right side

I am not sure of an analytic use case. I just wanted to be able to flag a record as having modifiers in case that information is needed. Then we can look inside the qualifier_source_value and extract from there.

Another way of representing the data would be to use the fact_relationship to create a relationship from the procedure_occurrence to the concept_id of the actual modifier:

procedure_occurrence table:
procedure_occurrence_id:  123
procedure_concept_id:     2211485
modifier_concept_id:      0
qualifier_concept_id      26, X2, RT

fact_relationship table:

( 26 modifier )
domain_concept_id_1:      10           -- procedure
fact_id_1:                2211485      -- procedure_occurrence_id
domain_concept_id_2:      12           -- Modifier
fact_id_2:                42739576     -- 26 modifier
relationship_concept_id:  12           -- modifier? 

( RT modifier )
domain_concept_id_1:      10           -- procedure
fact_id_1:                2211485      -- procedure_occurrence_id
domain_concept_id_2:      12           -- Modifier
fact_id_2:                45888271     -- RT modifier
relationship_concept_id:  12           -- modifier?

This doesn’t help with any unmapped modifiers. But they would still be in the source record’s qualifier_source_value field.

This make also break the desired design of the fact relationship table.

#21

For anyone interested in use cases, or is unsure of whether modifiers contribute anything meaningful to a patient’s visits, I’m going to give a couple of clinical examples of how modifiers add to the medical service, clinically.

List of modifiers that indicate what part of the body the service was done on:

  • Finger modifiers indicate what digit on the hand (left thumb, right pinky, etc) had the service - F1, F2, F3, F4, F5, F6, F7, F8, F9, FA
  • Toe modifiers are similar to finger modifiers - T1-T9, TA
  • Right and Left modifiers indicate what side of the body the service happened on (e.g. cataract surgery on the left eye) - RT, LT
  • Eyelid modifiers indicate procedures done on the upper or lower and left or right eyelid - E1-E4
  • Coronary artery modifiers indicate where in the coronary artery the procedure happened - LC, LM, LD, RC

Modifiers can also give limited lab result information in claims data:

  • Modifiers G1-G6 indicate what was the most recent urea reduction ratio for a dialysis patient
    • G1 Most recent Urea Reduction Ratio (URR) of less than 60%
    • G2 Most recent URR of 60% to 64.9%
    • G3 Most recent URR of 65% to 69.9%
    • G4 Most recent URR of 70% to 74.9%
    • G5 Most recent URR of 75% or greater
    • G6 ESRD patient for whom less than seven (7) dialysis sessions have been provided in a month
  • Modifiers EE and ED report hematocrit levels
    • EE - Hematocrit level has not exceeded 39% (or Hemoglobin level has not exceeded 13.0 G/DL) for 3 or more consecutive billing cycles immediately prior to and including the current cycle.
    • ED - Hematocrit level has exceeded 39% (or Hemoglobin level has exceeded 13.0 G/DL) for 3 or more consecutive billing cycles immediately prior to and including the current cycle

Modifiers can also confirm exactly why a drug was given and other patient related information:

  • Modifiers EA-EC confirm that epogen was given for chemotherapy-induced anemia
    • EA Erythropoetic stimulating agent (ESA) administered to treat anemia due to anticancer chemotherapy
    • EB Erythropoetic stimulating agent (ESA) administered to treat anemia due to anticancer radiotherapy
    • EC Erythropoetic stimulating agent (ESA) administered to treat anemia due to anticancer radiotherapy or anticancer chemotherapy.
  • Modifiers C(H-N) indicate the patient’s functional limitation when getting any kind of rehabilitative therapy (PT, OT, Speech, etc).
  • CH 0 percent impaired, limited or restricted
  • CI At least 1 percent but less than 20 percent impaired, limited or restricted
  • CJ At least 20 percent but less than 40 percent impaired, limited or restricted
  • CK At least 40 percent but less than 60 percent impaired, limited or restricted
  • CL At least 60 percent but less than 80 percent impaired, limited or restricted
  • CM At least 80 percent but less than 100 percent impaired, limited or restricted
  • CN 100 percent impaired, limited or restricted

If modifiers are not included in the CDM, this information will be lost in the OHDSI CDM. Modifiers are generally the only way to get this type of information in claims data. From a clinical point of view, these codes contribute to detailing the patient’s visit.

1 Like
#22

I have a couple of suggestions for your issue X1, X2, X3, etc modifiers, @Richard_Starr. Is this data from Illinois or Wisconsin or Michigan? Modifiers X1-X9 are local modifiers used to indicate equipment was transported somewhere. I found some information about it here. Since these modifiers are indicated at the state level, it doesn’t surprise me that they are not in the OHDSI vocabularies. I know that there are very specific Medicaid modifiers used in California too. I’m not sure how to reconcile this into the vocabularies. But I’ll leave all the heavy lifting to @Christian_Reich :stuck_out_tongue_winking_eye:

I also like your suggestion of using the fact_relationship table, but I am concerned that it would not pick up the unmapped modifiers. I actually really like your first suggestion of just putting the comma-separated modifiers in the qualifier_source_value and set the modifier_concept_id = 0. Smart!

#23

Sorry to revive an old topic, but I couldn’t find any current information on the qualifier_source_value in the PROCEDURE_OCCURRENCE table. Or a resolution to the above discussion.
The current definition is “The source code for the qualifier as it appears in the source data”. Are people using this as the source_value for the modifier? We are about to start loading modifier_concept_id to the PROCEDURE_OCCURRENCE table.

Thanks!

#24

@MPhilofsky:

No, the above discussion hasn’t been resolved yet. Modifiers are just not part of any burning use case. If they where, @jenniferduryea would have made that clear. :smile:
So, yes, it is the source value of the qualifier. In other words, the CPT-4 code.

1 Like
#25

I see that the Standardized Clinical Data Tables are undergoing changes. Would now be the time to fix the error?

I vote that we pick the term “modifier” and change qualifier_source_value to modifier_source_value. Our EHR data has modifiers to further describe procedure location.

1 Like
#26

agreed @MPhilofsky. I believe it is already mentioned on the CDM working group here. I would like to add your suggestion for change, which I believe the originator of the topic tried to do. I cannot access this page to make edits and to clarify the request. @Christian_Reich should all users have access to editing this page? I would also like to be added to this workgroup (if one needs to be created for this topic).

#27

Friends:

Trying to pick things up here where they were left behind. I think there are two possible solutions:

  1. We just add more space to add those modifiers. So, we can have as many as we want together withe the corresponding procedure code. Currently, they are parallel (having their own fully-fledged PROCEDURE_OCCURRENCE record).
  2. We create FACT_RELATIONSHIP records between them, which is a similar solution at in 1). Except I hate it even more. :smile:
  3. We actually disect those Modifiers and treat them in OMOP CDM fashion - we put them were they belong. Just because claims shove all sorts of different things into a construct “Modifier” it doesn’t mean it’s the right thing to do from an analytical use case perspective. Always think of the poor analyst from, say, Australia who has to figure out why the result of a dialysis is suddenly stored in a Procedure Modifier (as opposed to a MEASUREMENT). Or worse, why the manufacturer of a biologic has to be found in here (ZA - “Novartis/Sandoz”).

According to @jenniferduryea’s list we have a number of types of Modifiers, and I suggest to treat them as following:

  • True modifiers to a Procedure - existing field (JD “Skin substitute not used as a graft”)
  • Anatomical site definition for procedure - new field
  • Involved Provider information - new field (80 “Assistant Surgeon”)
  • Billing and service details - new field in the COST table (such as CS “Gulf oil 2010 spill related”, CD “Amcc test has been ordered by an esrd facility or mcp physician that is part of the composite rate and is not separately billable”)
  • Lab test type modifiers - Measurement (like Jennifer’s examples above)
  • Observation about functional limitations - Observations (CH “0 percent imparied, limited or restricted”)
  • Indication or rationale modifiers - Observation (“Erythropoetic stimulating agent (esa) administered to treat anemia due to anti-cancer chemotherapy”)
  • All other junk - Observation (HR “Family/couple with client present”)

Thoughts?

#28

Just checking in on this one, was a final decision ever made on naming them qualifier vs. modifier, looks like it’s leaning toward ‘modifier’, can we call that official?

#29

Hi All,

I am van working on an observational study. We have created PERSON, VISIT OCCURANCE AND OBSERVATION PERIOD table as per the OMOP CDM version 5.

For Drug Exposure for which I have some doubts which are as follows:

As per OMOP guideline Medical History data will be captured in Observation Table so do we also need to capture Medication History data in Observation as well or it will go in Drug Exposure Table?

We have got three types of Medication data in our raw data
A) Medication history some with start date and some with missing start dates.

B)Current medication data other than Study drug which does not have start dates but they are ongoing on baseline visit.

C)Study Medication Drug with start dates has been captured.

Please help me that for above all three mentioned types which should we capture in Drug Exposure or Observation Table?

Do I also need get Medication coded (WHO ATC) before mapping or I can go ahead with captured verbatim?

All inputs will be welcome…

Thanks

#30

True. We didn’t record the decision. Will do.

#31

@VanSamoa:

Welcome to the family.

That depends what you mean by “history”. If this is a current medication list the patient reports, it goes into the DRUG_EXPOSURE table. If it is past history, it goes into the observation, becasue the date is not the date when the drug was taken, and that is important for the analytics.

The one with start_date goes into DRUG_EXPOSURE, the other one into OBSERVATION.

They go into the DRUG_EXPOSURE and you infer the start date. If you have nothing to hang your hat on take the visit date as start date.

DRUG_EXPOSURE. Only problem here is the fact that we have no concepts for drugs not yet on the market. If you want you tell us what these study drugs are and we put them in.

You need to code it. To RxNorm and RxNorm Extension. You can use the USAGI program for doing that. But if you have ATC 5th it is easy to code because they have the mapping to RxNorm in the CONCEPT_RELATIONSHIP table.

#32

Thanks Christian…

Just to follow up, Some of the medication which was taken by the subject in past (before enrolling in our study) have Start dates of medication as well as end date.

If I put these dates dates in Drug exposure start date and Drug Exposure End date then I’m afraid I will be deviating from the OMOP guideline which says that No dates should be captured before Observation Period Start date.

Our Observation Period start date is the date when the subject enrolled in the study which we call Informed Consent date.

Could you please give your inputs.

Thanks,
Van

#33

@VanSamoa:

Hm. This is tricky, Van. You are stepping on uncharted territory. The reason is that we actually have not yet figured out how to exactly model prospective clinical studies, which is what you seem to be doing here.

Here is the problem. In clinical studies you select patients, observation time and data per protocol and CRF beforehand, and then collect and load the data. In observational studies you collect everything that’s happening to as many patients as possible before any study, and then you select the cohorts and data out of there through a query defined in the protocol. The Common Data Model is designed for this. But it really doesn’t know what to do with data cut arbitrarily into snapshots, and therefore everything that happens outside the Observation Period is considered an historical observation.

But it could still work. We have listed clinical studies as an extension in the list of things for the CDM Working Group (everybody is invited), but nobody has started it. Now you have. :smile:

Put it in.

Just move the start date to include the first relevant data you have.

Understood, but I wouldn’t do that. Move your start and end_date so you have space to operate.

The time span the clinical study was active, as well as the definition of treatment arms, randomization and subject termination events are all things we just don’t have yet in the Model.

#35

Hi @Romario_Ozmandos - I am not a clinician and have never heard of Medic. I am sorry to hear about your ailments but unfortunately I cannot help you. Best of luck to you.

#36

The issue was addressed here. Please have a look.

t