OHDSI Home | Forums | Wiki | Github

Understanding drug_strength

I’m implementing a ETL for ‘drug_exposure’ table, and am struggling to understand how to fill the quantity field for liquids.

For instance, drug_concept_id = 19079524 (sodium chloride 9 MG/ML Injectable Solution). I would expect ‘drug_strength’ to have the following values

|numerator_value|9.0|
|numerator_unit_concept_id|8576 (mg)|
|denominator_value|1.0|
|denominator_unit_concept_id|8587 (mL)|

However, the actual value for ‘denominator_value’ is NULL, what makes no sense to me.

Other example, for concept_id = 19036828 (10 ML calcium chloride 100 MG/ML Injection), we have

|numerator_value|1000.0|
|numerator_unit_concept_id|8576|
|denominator_value|10.0|
|denominator_unit_concept_id|8587|

This time the proportion is right (1000/10) however, the title specifies 100mg/10mL, so why are the ‘numerator_value’ and ‘denominator_value’ 10x bigger?

Should I assume that, when ‘denominator_value’ is NULL and ‘denominator_unit_concept_id’ is not zero, then the actual denominator value is 1?

Thanks

@djogopatrao:

We don’t have the total volume as part of the reference record. We only know the concentration. It’s probably a liter of saline, but the “liter” is not available. If it were, the denominator_value would have that information.

Here we do have the total volume of the solution (10mL). But instead of having 10 mL and 100 mg/mL we multiply and have 1000 mg in the total of 10 mL. It’s the same thing, just a different notion.

You should assume that you don’t have the total volume. Of course, the concentration is 100 mg/1 mL by default. But the denominator value should contain the total volume.

Makes sense?

So If I understand correctly:

  • the concentration unit is numerator_unit_concept_id / denominator_unit_concept_id

  • if denominator_value is not null, it is the volume available in the drug’s presentation, and the concentration is numerator/denominator.

  • if it is null, then the volume is not known/applicable and the concentration is numerator/1

Is that so? It seems that there are a lots of different semantics mixer in the same place.

Correct.

Why mixed semantics? If we know the volume it is in the denominator. If we don’t know the volume it is NULL. Normal RDBS.

The question is what do you do with that information during ETL. Because more often than not, the actual volume administered is part of the data, not part of the reference data in DRUG_SAFETY. And that’s what we want to fix with the proposal.

My opinion? numerator/denominator should be used exclusively for concentration, and there should be a field for volume.

This way, if the concentration is 9mg/mL and the volume is 10mL, we got
numerator = 9
denominator = 1
volume = 10

Conversely, if the volume is unknown, volume is NULL and the other fields are kept that way

If I were to facilitate calculating the amount of ingredients from the volume infused/prescribed, I would even add a “concentration” float field, so if the units from the source match with drug_strength, I would only multiplicate them and get what I need.

For context, I’m writing an ETL part in which I compare the source concentration unit with the one from drug_strength, to convert one to the other if needed.

@djogopatrao:

Ha! You are proposing three fields instead of two for the exact same information, right? :slight_smile:

Other than preference, is there any good reason to make that change in the model, requiring all tools and modules to change?

I realize the job of an ETLer for getting the dose right is a tough one. Which is why we are trying to make it easier, even though it’s not our fault that the data is so crazy. Why don’t you respond to the proposal on the table and make your suggestions?

Well, I’m not proposing anything (yet), just thinking aloud :grinning:

Having a unique clear purpose for each field/column/property allows for better readability and reusability (as in the FAIR principle).

In this case, we have two distinct entities => the concentration, and the volume. I split the concentration into numerator and denominator to allow acurate representation of fractional values (such as 3.5 / 1 or 35/10 ) as described on the drug documentation.

In the current situation, we use two fields to represent three distinct entities, so we need rules to correctly interpret data (the rules I described in my last post). That saves storage space, but I’m not sure that should be the focus of OMOP CDM.

I started reading the proposal, and would gladly contribute if I can. Thanks for the invitation!

cheers!

dfcp

t