OHDSI Home | Forums | Wiki | Github

Drug Era


(Anna Ostropolets) #1

Recently, I’ve been looking at drug_era (and I must say I have a strange bias against it) and figured out that it collapses everything regardless of drug_type_concept_id. So we can’t actually distinguish between prescribed and administered drugs even if we captured this info in drug_exposure.
Is it the way we want it to be?


(Chris Knoll) #2

Was there a recent change to store drug_type_concept_id in drug_era? Without it, how can you store both types in the drug era table?


(Anna Ostropolets) #3

No, you can’t. This is actually my question: we first want to separate records with different provenance and then mix them together again in drug/dose_era.


(Chris Knoll) #4

It’s a simple change to the era building logic to partition the eras based on drug_type_concept, if that was available in the table. So, once it becomes available, I’m happy to update the published script.


(Michael Kahn) #5

Or change the current drug era building code to only use administered or dispensed drugs?


(Christian Reich) #6

Yes. That is the idea. The use case is exposure to active compound, irrespective of dose and formulation, and irrespective of how we learned about it (which is what the drug_type_concept_id tells us).

Standard Christian question: Is there a use case for having to change that?


(Anna Ostropolets) #7

I’m assuming that we generally trust administered drugs more than prescribed. for this reason, we don’t want them to be mixed together. So it just doesn’t make sense to ETL the data, make efforts to preserve all the data, separate records with different provenance in drug_exposure… and then end up with mixed overlapping records in drug/dose_era, where you don’t actually understand the source of the data, what those records actually mean and so on.
Long story short: drug_era is super convenient, but I can’t actually use it as I want administered drugs only.


(Eldar Allakhverdiiev) #8

On the one hand I see the rationale of separating eras by record type .
The 2 cases of using drug era (not regarding standard features in FeatureExtraction package)
are: to handle gaps and islands problem and simplify implementation of criteria like 'used at least X drugs from list of Y).
And for both cases it can happen that researcher want’s to make search only against records of a certain type.
On the other hand I hardly imagine simple decision which will satisfy all community.

The possible solutions can be grouped to the following:

  • Resolve this within data
  • Keep possibility for such options in the tools

The first option doesn’t seem attractive to me: if remove current approach and replace it by
stratified eras…then what if I trust all records types? Still have trouble in exploration of sequences
Adding stratified eras to unstratified one (insead of replacing) is even worse because
a) we are overloading and degenerating data,
b) we need to create additional conventions for researchers (and cross fingers and pray for them to follow it - haha)
and finally c) we’ll still need to adopt tools.

Hoping to find something useful I’ve taken a look in current documentation of DRUG_ERA table and ch.8 of conventions made me totally confused.

What do they mean under Researchers are encouraged to consider creating their own Drug Eras with different parameters as Cohorts and store them in the COHORT table. ?

Anyway, I see the solution to be placed in tools rather that in data ( or mixed one but still with prevalence of tools :wink:). Below is the way that I can imagine:

  • Leave drug_era as it is
  • Extend cohort builder. Provide user to choose between old good predefined era and customized one.
    If former is picked - then do it in the old way, if latter - then temporary customized era should be built.

Such extensions seems affordable for implementation.
(Atlas now does almost the same stuff for cohort exit if defined by end of drug exposure except for adding filters)
I see no cons of such an approach but memory resources…

@Chris_Knoll, as main contributor of era constructor and cohort builder you have more profound picture,
any thoughts?


(Christian Reich) #9

Is that a use case? Define “want”.

Look. The DRUG_ERA table is for convenience purposes, and our attempt at creating a quick and dirty solution for cobbling together many individual Drug Exposure records into a continuous exposure of the organism to a pharmaceutical compound. I agree there can be any number of more refined eras. There is nothing preventing anybody to build the perfect cohorts putting together exactly the kind of drug exposures they want.


(Chris Knoll) #10

The same logic that builds the drug era is the same logic that creates cohort eras in Circe cohort definitions.

If you want to make custom eras out of drug exposures that fit a specific profile (such as the form, the administration setting, the visit provider, etc) you can select all the events as cohort criteria, and then collapse them into eras using the cohort era settings.

I believe they mean what I described above: use criteria for your specific scientific question to create the cohort eras that represent the custom drug_era logic you want.

Using this approach, everyone gets what they want.

-Chris


t