Making an executive decision is what we love to do. 
And clearly, this term confusion isn’t right. But I am still confused what the options are, because I don’t know the use cases. The Qualifiers/Modifiers were introduced to characterize procedures more concretely. For example, for right and left of the body, etc. I forgot who brought this up. I can imagine there are good use cases (counting how often a procedure ends up having to be performed on both sides, like with hip replacements), but at the end of the day you need to step up and point them out. Otherwise, removal of the field might be the best decision.
I’m copying & pasting @burrowse’s first post regarding this – I believe it was just a naming error -where in the Proc_Occ table 'modifier-concept-id" should have been ‘qualifier-concept-id’.
- Is there a “Modifier” domain in the vocabulary? I was not able to
locate one to reference valid concept ids for the “modifier_concept_id”
field. - There isn’t a corresponding “modifier_source_value” to the
“modifier_concept_id” in the procedure occurrence table. There is a
“qualifier_source_value” in this table. Is this an error? In the
Observation there is the qualifier_concept_id and qualifier_source_value
pair.
That is correct. That is an editorial error. We call it qualifier in one place and modifier in another. We can fix that by picking one.
However, which one? In order to answer that, we need to understand what the data are used for. We are not building an attic where people dump all their data, just in case it might become useful some day (and`, as you know from your own attic, never will). So, the third option is to drop the whole thing and simplify the model.
Do you ever use those qualifiers/modifiers of procedures?
OK, I guess I wasn’t looking to rehash its existence, but was working on the assumption that it already passed this criteria. But, as always you make a good point. I likely won’t be using this field, and it is not in the draft PCORNet CDM V3 (for those of you wondering), but I’ll leave it for other forum members to answer regarding their use cases and needs.
Lisa Schilling, MD, MSPH
Associate Professor of Medicine
Division of General Internal Medicine
University of Colorado, School of Medicine
office AO1-Room 8219: 303-724-2254
office UPI Building- ACCORDS: 303-724-5138
fax AO1: 303-724-2270
Mailing Address:
Division of General Internal Medicine
University of Colorado School of Medicine
8th Floor, Academic Office 1-Office 8219
Mailstop B180
12631 E. 17th Ave
There is definitely useful information in the modifiers. Lab values (hematocrit for people taking erythropoietic agents) and body location. At least, this is true for Medicare HCPCS codes. If these can be mapped to other places in the CDM, then it would be fine. For example, hematocrit seems like it should go in measurements if possible. I am going to see what @jenniferduryea thinks. There may be costing implications (but maybe the information goes in the cost table then).
There are definitely use cases involving modifiers, so the fields should not be removed. Instead the “qualifier_source_value” should be renamed to “modifier_source_value”. I do not know of any other use case these fields would be used for, besides modifiers. From a claim perspective, modifiers are the only fields that would be used.
For @Patrick_Ryan and @Christian_Reich, here are some use cases to consider when using U.S. claims data:
- Identifying a procedure performed by an assistant surgeon (using modifier 80). If a surgery involved a surgeon and assistant surgeon, both doctors would submit a claim with the same procedure codes. However, the assistant surgeon would use modifer 80 to denote that his procedures were “assists” and should only be reimbursed at 25% of the fee schedule. Since US claims data does not usually give us de-identified physician information (and most users are not ETL’ing the physician information in the first place because of this), there would be no way to determine why a patient has duplicate procedure codes for the same visit. Was it a bilateral procedure and the patient had two procedures done on both sides? Were two physicians working only on one surgery? Which procedure was primary and which one was from the assist? We won’t know this information unless we knew the modifier. You might be able to infer some information by looking at the related costs, but that is very tricky when looking at private vs Medicare claims due to different fee schedules.
- As @Christian_Reich alluded to in a previous reply, modifiers denote bilateral procedures vs one-sided procedures. Bilateral procedures use a modifer 50. This is used heavily in eye surgeries (i.e. cataract surgery). If you are doing any epi work, and want to identify how many “eyes” had cataract surgery, you need to double count procedures with a modifier 50. You might be able to figure it out using the associated cost of the procedure, but again, that is a tricky slope since fee schedules are different across providers (for private claims) and geographic areas (for Medicare claims). So obviously, if you remove the modifier field, you would not get the “modifier 50” information for eye procedures, and you would be under counting the number of “eyes” that had surgery.
To answer @burrowse vocabulary question, yes there is a vocabulary for modifiers. If you look under concept_class_id “CPT4 Modifier” and “HCPCS Modifier” under the concept table, you should find them. And just a reminder that there are two different types of modifiers - CPT and HCPCS. Common CPT modifiers include LT and RT to show procedures being performed on the “left” or “right” side of the patient’s body. You will not see these modifiers in Medicare data.
To address @Mark_Danese’s reply, I do think the modifier information should be in the procedure_occurrence table, not the procedure_cost table or anywhere else. Since these modifiers give more information about the procedure itself. Now they do affect reimbursement in some ways. But in my “modifier 50” example above, there is an epi use case for them. And it would seem that epi analysts would rarely venture into any cost table for data. But coming from a health econ perspective, I could be wrong. But since the modifier field is in the procedure_occurrence table now, why change it?
Some things to note, which I’m probably going to post as a different topic on the forums, but since we’re talking about modifiers, this seems appropriate. US claims can now be submitted with up to 8 modifiers per procedure. However, in the data we have received from data providers, it seems we only get up to the first 4 modifiers. But CDMv5 only has the ability to store one modifier. So the person doing ETLs would have to make an executive decision as to what modifier to keep in the CDM and throw out all of the other data. Or the ETL person could duplicate the procedure and put a different modifier on each one. But that seems way more confusing for an analyst. I’m just bringing this up as an issue and don’t have a resolution yet. But if actual claims are being sent with up to 8 modifiers, it is reasonable to assume that claims data for researchers will also get more than the 4 modifiers eventually. And the CDM will have to be revisited at some point.
4 Likes
Ah! One of the insightful @jenniferduryea-contributions. Nice.
I wonder whether we should actuall swallow the second assistant-claimed procedure and merge it with the first. Remember: The CDM creates a picture of what happened to the patient, not to the doctor or the healthcare system. We could add the cost up for both of these or keep two procedure_cost (in future: cost) records.
Can you give an example of what they would combine?
2 Likes
Ha! Thanks @Christian_Reich. And I can always count on you to be my devil’s advocate 
Let’s start with the easy question.
Data providers (who sell data to researchers) do not combine modifiers from claims data. They literally give you the first four modifiers from the procedure and then drop the rest. To be fair, it’s pretty rare to have more than four modifiers on a procedure (in my experience). But I have seen it before in real life (in actual claims).
I definitely agree with keeping two procedure_cost (future: cost) records on file. And in my epi example above using modifier 50, this modifier 80 will be used to de-dup procedures in the CDM, preventing over-counting of procedures. You could link two procedure_cost records to one procedure_occurrence_id, but you would lose the context as to why there are two procedure_cost records to one procedure_occurrence_id. The modifier field will help demystify these relationships for the analyst. I do understand your concern about duplicate procedures in the procedure_occurrence table. But they are not truly duplicate procedures when each procedure_occurrence row holds different meta-data (one has a modifier, one does not; one has a different procedure_type_concept_id than the other).
As a side note, I am confused about what “patient perspective” actually means. So anytime someone uses this term to justify changes to the CDM and vocabulary, I want to understand what exactly those boundaries are. Since the patient saw two surgeons, isn’t it realistic to note that in the CDM, showing two procedures from two different surgeons with one having an 80 modifier noting this was an assistant surgeon? Does the “patient perspective” include costs? Generally, patients are only aware of what their cost responsibility is and don’t care what their insurance paid to the providers. So why are we capturing this information in the CDM? Even though we tout OHDSI’s CDM is from a “patient perspective”, and that may have been the intent all along, but I would argue it’s from a “researcher perspective”. When we make changes to the CDM, it’s based on use cases that researchers have, not from broadening the “patient’s perspective”. We look at what data researchers used most often in studies. And generally, those data elements are what we normally get from data providers, which include modifiers for claims data.
Now before I start a revolution 
, if we are still uncomfortable with storing modifier information in the procedure_occurrence table, I could see moving modifier information to the observation table and using the fact_relationship table to link those observations to a procedure_occurrence_id. This would solve the impending “8 modifier” problem (or existing “4 modifier” problem) by just adding observation records and linking them to one procedure_occurrence id. But I’m not sure how that affects the vocabulary, since we’ll be storing HCPCS/CPT vocabularies in the observation table. Thoughts on that, @Christian_Reich?
1 Like
Hi @jenniferduryea, I wanted to let you know I am seeing the multiple modifiers in EMR data also ( EPIC ). Since they are coming in a comma separated list, I am just storing that in the qualifier_source_value until a standard way to store them is developed.
I am planning on making the modifier_concept_id = 0 if the multiple modifiers are present. I think that is keeping with the standard conventions.
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
…and most importantly , does someone have an analytical use case that
requires using these modifiers?
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
Friends:
Could anybody (@burrowse, @schillil, @mark_danese, @jenniferduryea, @Richard_Starr) be so kind and fill out a proposal form plus use case here.
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.
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
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
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!
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!
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. 
So, yes, it is the source value of the qualifier. In other words, the CPT-4 code.
1 Like
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
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).