| OHDSI Home | Forums | Wiki | Github |
Hello @Christian_Reich,
I am trying to create era in CONDITION_ERA.
But I don’t have any data in my source system that can populate CONDITION_OCCURRENCE’s condition_end_date. So, my condition_end_date is basically null.
In this case what should be my condition_era_end_date?
Thanks.
Era tables are derived tables using standard codes. You don’t have to worry about null condition_end_date. It has algorithm to handle the situation, e.g., add 1 day or 30 days to the condition_start_date etc. The SQL code for generating these tables are here:
Thanks a lot @QI_omop.
@Christian_Reich , @Chris_Knoll Just one more small question-
Should CONDITION_ERA be implemented as-is as provided in the above code? Or should it be customized?
Thanks in advance.
I think you should implement it as-is. even tho your conditions don’t have end-dates, the algorithm will assume a 1 day duration, with a 30 day ‘gap window’. Meaning: if you have 2 conditions within 30 days, they will be considered part of the same era. I wouldn’t modify that logic (to say, 45 days or 180 days) since the de facto standard is to use a 30 day gap.
Only changes you will need to make is to update the script to reference your own CDM schema.
@Chris_Knoll @QI_omop
In the above drug era code - vocabulary_id =‘Rxnorm’ is considered.
But we have data from other vocabulary_id like RxNorm Extension. we are having a data loss if we are not considering such vocabulary_id’s.
As its mention we have to use the provided code for drug era with out any modification, its resulting in loss of data in our side. Can we modify the code to add vocabulary_id like RxNorm Extension.
As per OMOP we consider concept_id’s which are valid in ATHENA.
But in the given drug era code we have not added filter like Invalid_reason <> ‘D’ and Invalid_reason <> ‘U’, which are providing data having invalid drug_concept_id .
Can we modify the above code to add valid concept_id’s only
Thanks
I agree, this should be added.
This is fine. Non-standard (all deprecated concepts are non-standard) aren’t included in CONCEPT_ANCESTOR, so we don’t need this filter.
Hello @Chris_Knoll, @Christian_Reich, @Dymshyts,
While checking the code for DRUG_ERA, found that the gaps_days is hard-coded as ‘30’ instead of the difference between the dates? Please find below screenshot :
Why can’t the gap_days be calculated?
Can you please explain what do you mean?
I think he is asking why the gap days can’t be set dynamically (say 45 days) instead of hard coded.
To identify eras dynamically, you can use drug_exposure/condition_occurrence and specify the gap on your own at the bottom of cohort definition page in ATLAS:
And just in case, the rationale for 30 days is that in OHDSI it is assumed that <30 days gap means that a patient was actually taking this drug continuously (or had a condition).
I think that gap_days is being confused with the number of days allowed between end of one treatment period and start of the next.
From ETL specification:
gap_days: The number of days that are not covered by DRUG_EXPOSURE records that were used to make up the era record.
The Gap Days determine how many total drug-free days are observed between all Drug Exposure events
that contribute to a DRUG_ERA record. It is assumed that the drugs are “not stockpiled” by the
patient, i.e. that if a new drug prescription or refill is observed (a new DRUG_EXPOSURE record is
written), the remaining supply from the previous events is abandoned.
The difference between Persistence Window and Gap Days is that the former is the maximum drug-free
time allowed between two subsequent DRUG_EXPOSURE records, while the latter is the sum of actual
drug-free days for the given Drug Era under the above assumption of non-stockpiling.
Hi, everyone, sorry for late reply:
1: the RxNorm vocabulary: the code in question pre-dates Rx norm extension, and if you can find valid concetps in the RxNorm Extension, then you should include that vocabulary. If you want to change it to ‘any standard ingredeitn concept’, then you can just remove the vocabulary check entirely and just look for standard ingredient concepts. However, this roll-up is just looing for ingredient concepts…are you saying that there are ingredient concepts found in RxNorm extension that are not in RxNorm?
2: Invalid Concepts: we’re joining to concept_ancestor, and there are no invalid concepts in concept_ancestor.
3: Gap days: for the standard Drug Era calculation, we use 30 days. this is so that if you’re doing a study across different datasources, the standard era calcualtion is to use a 30d gap. If one datasource used 10 days and another used 60 days, you would have eras built on different logic. As @aostropolets says, you can create a cohort to create custom drug eras based on your own user-defined gap value. On DTorok’s point, the gap_days in the algorithm is being used to store what the gap (the time between one exposure end and the next exposure starts) that was used to calcuate the era. So, the algorithm is not calculating gap_days per the ETL specification. Any takers on modifying the query to calculate the gap_days from the underling exposures + the final eras, that would be a welcome enhancement to the algorithm.
Thinking about calculating gap days (if anyone is interested in this enhancement):
The trick is going to be creating the era in 2 passes: the first pass collects all the individual drug exposures and flattens them (with a gap window of 0) so that any overlapping drug exposure days are not double counted. Looking like this:
|------------|
|------------|
|------------|
|------------|
Creating a 0-gap era from the above gives us:
|--------------------------|
15d
|------------|
So with this first pass we have the non-overlapping continuous exposures, Note the gap of 15 days.
The second pass will create the final drug_era with the 30 day gap window:
|---------------------------------------------|
The last era will be what’s put into the drug era start_date and end_date. to calculate the gap_days for the drug era, we simply subtract the total days in the drug era - the duration of each ‘sub-era’ found between the final drug_era start and end. From the above picture, we know that there’s 15d that were not covered by en sub-era. So, if I am interpreting the ETL spec correctly, the gap_days would store 15 days. A final example:
After overlaps are removed:
|------------|
12d
|----------------|
21d
|-------------------|
Final Era:
|---------------------------------------------------------------|
Gap Days = 21d + 12d = 33d
@DTorok: would you agree with this logic?
Yep, there is a bunch of ingredients that can be found in RxE only (its contains some valid ingredients from outside of the US like fludiazepam). Shouldn’t be hard to fix, so will add a PR to the era-constructor repo.
Great, I can provide a PR to properly calculate gap_days after the logic is settled. Which repository are you posting this PR to?
Hi,
Thank you @Chris_Knoll, @DTorok , @aostropolets, @Dymshyts.
Appreciate your efforts for explaining the logic and algorithm.
However, when I checked the code for DRUG_ERA at the link provided by @aostropolets, it is different from the code provided by @QI_omop.
I am confused as which one should I refer now? Is the logic being discussed implemented or needs to be implemented?
Thanks in advance.
Hi @Chris_Knoll, @DTorok, @Dymshyts,
Can you please direct me to the correct code?
Thanks in advance.