OHDSI Home | Forums | Wiki | Github

Procedure Occurrence Modifier

CDM Builders
#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