OHDSI Home | Forums | Wiki | Github

Use of multiple modifiers/qualifiers

I have a question about how to deal with multiple possible parameters for a procedure.
Specifically, we are storing the results of hearing tests. We plan to put the auditory thresholds into the Observation table, e.g. 37208573 (Auditory threshold of right ear at 1000 Hertz), and link these to the Procedure_occurrence table using the observation_event_id. There are standard concepts for pure tone audiometry, e.g. 4091134, but we would like to store more detail about the exact parameters the test was done under, i.e. air or bone conduction, masked or unmasked, through speakers or through headphones, etc., some of which we will need to create local concepts for.
As I understand it, we can’t add more than one modifier to the Procedure_occurrence, or more than one qualifier to the Observation, so how would anyone recommend we do this? Should we create our own local concepts for each possible combination of these hearing test parameters and use these in Procedure_occurrence or Observation? Or, as I’ve seen suggested here, use qualifier_source_value or modifier_source_value to house the full list of parameters used?
Thank you for any help.

@RuthS

No “squishing” of data into the OMOP CDM. It won’t help you, because the analytical methods don’t expect you to abuse a field in a way that is not standard and will therefore not be able to make use of it.

Question: What is the use case? What do you want to do with that information? Do you have a study in mind?

We plan to extract routine clinical data concerned with hearing tests from hospital systems, and would like to standardise them such that data from several locations can be merged into one database for analysis. Hearing tests are performed in slightly different ways depending on the location, the best practice at the time, etc. Research questions that will be asked of the data in the future are likely to require knowledge of the specific conditions under which hearing tests were performed (not least to ensure we are comparing like with like), and so we wanted to be able to easily extract subsets of the data based on these conditions.
Thank you.

Makes sense. What are the parameters? Are they discreet or continuous? In other words, can the auditory threshold assume any value (1000 Hz, 999 Hz, 990 Hz, 900 Hz), or are there standards? What else do you need?

Reason I am asking is we can create pre-coordinated concepts combining the procedure of hearing test with those parameters. That’s how it should be, but it isn’t always possible.

The alternative is you treat those as Open World data, and therefore outside of OMOP. The rest of the clinical data stays inside.

Hi Christian,

I’m working with Ruth on this project, thanks for your input so far.

Auditory threshold values generally take discrete values of 250Hz, 500Hz, 1000Hz, 1500Hz, 2000Hz, 3000Hz, 4000Hz, 6000Hz and 8000Hz but sometimes frequencies in between these values will be tested.

My current thought is to use the qualifier_concept_id row of the Observation table to modify the observation depending on how it is conducted. We would then need to make qualifier concepts that combine various parameters (eg. bone conduction + masked, air conduction + masked, bone conduction + unmasked, air conduction + unmasked) since you’ve highlighted that we shouldn’t put multiple concepts in this row. I think this is what you’re alluding to?

Nikhil:

Can you make a calculation of how many different permutations you need? Is the matrix really full (9 frequencies * 2 conductions * 2 maskings = 36 settings)? Also, what is the result? Just one number-unit combination for the threshold?

At present we need options for:

  • Conduction type: Bone or air
  • Masking: Masked or unmasked
  • Tone: Normal or Most Comfortable Loudness or Uncomfortable Loudness Level

2 x 2 x 3 = 12 combinations/ new concepts needed. There are existing concepts for all the auditory thresholds already (observation type). The result of each auditory threshold is a number-unit combination.

The issue was addressed here. Please join the discussion.

t