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
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.
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.
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?
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?
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.
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.)
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:
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.
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:
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.
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.
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.
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.
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).
Trying to pick things up here where they were left behind. I think there are two possible solutions:
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).
We create FACT_RELATIONSHIP records between them, which is a similar solution at in 1). Except I hate it even more.
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”)
Let’s start with the easy question.
, 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, 