| OHDSI Home | Forums | Wiki | Github |
Hi everyone,
I was wondering how gap_days works in the v5 CDM. Is it a concept_id that references a certain number of days, i.e. 30 days, 45 days, 60 days, etc, so that certain drugs can have a “gap” that is reflective of their intensity, potency, and other qualities?
If not a concept_id, could someone please explain how gap_days would be implemented in the structure of the database? Where would the gap_days come from when we are building the drug_era?
Thank you in advance,
Taylor
This has been a long-standing discussion. At the OMOP CDM, we call gap_das “Persistence Window”, but it is the same thing. We assume a standard of 30 days. We have experimented with a Persistence Window of 0 days. The number of eras was different that with 30 days, but the methods estimating the strength of a drug-outcome association came up with pretty much the same result. So, we concluded that other than for compliance measurements and things like that where the gap has a direct influence on the result, we probably shouldn’t worry too much about it.
So, the DRUG_ERA table assumes 30 days. If you need another Persistence Window feel free to create those as a cohort and place the result into the COHORT table.
However, if you have a way to come up with a dynamic persistence window that takes into account the “intensity, potency or other qualities” please let us know and we absolutely will consider.
I think @taylordelehanty is asking something different. @christian_reich
is correct that when we are combining across DRUG_EXPOSURE records to
produce a DRUG_ERA for a given ingredient, that our general convention is
to use a 30d persistence window, such that two successive records that are
within 30d of one another are combined to produce one era. however,
GAP_DAYS is a field in the DRUG_ERA table to record how many days did exist
between the records that were used to make up the era record. The
motivating rationale for adding this field was to facilitate estimate of
adherence, where there are measures such as ‘proportion of days covered’
(PDC) and ‘medication possession ratio’ (MPR), which fundamentally rely on
understanding how much drug was available during a duration of time. An
example, lets say you have 3 30d dispensings of the same drug, first on
1Jan, second on 15Feb, third on 1May. The first two dispensings would
become one era, from 1Jan -> 15Mar, with a GAP_DAY = 15, because there was
15day gap between the first dispensing end and second dispesning start.
Then, there’d be a second era 1May->1Jun, with GAP_DAY=0. If you wanted
to estimate PDC from 1Jan->1June, you can now simply do SUM
(DRUG_ERA_END_DATE - DRUG_ERA_START_DATE) - SUM (GAP_DAY),. In this case,
you’d recover the 90d of coverage, because the was no stockpiling going on.
We don’t currently have any standardized analytics for adherence measures,
but I think it’d be a great opportunity for contribution, and would fit
nicely in ACHILLES, HERACLES and other current OHDSI apps.
One caution is that GAP_DAY may have different interpretations depending on what evidence you use to determine exposure: order, prescription, implied refill, filling, payment, administration (MAR), or narrative evidence of current exposure.
George
Thanks @patrick_ryan for the great explanation! How does GAP_DAYS work when more than 2 successive records are used to create an era, and they have different gap days-- say 15 days and 29 days (so in this example both fitting within the 30 day convention)-- should we report the greatest gap day value that occurred during the drug era?
Yes, @hripcsa is exactly right, inferring eras from exposures requires
local domain knowledge, depending on the data elements that are available
and their reliability. I think it’d be great if the community shares the
practices they followed to implement the _ERA tables, so that those with
similar local assumptions can use similar implementations.
@schillil, the intention is to add up all days that were inferred to be
‘unexposed’ within the era. So, lets say you have 3 30d scripts, 1June,
15July, 25Aug. That’d give you record-specific end dates of 1June->1July,
15July->15Aug, 25Aug->25Sept. Each of these successive records have a gap
that’s less than the 30d persistence window, so we’d consider this person
continuously exposed with a little non-adherence. The gap between the
first and second script is 15 days, the gap between the second and third
script is 10 days, so the total GAP_DAY for this one DRUG_ERA record would
be 25.
Another example, where you’ve got overlapping records: lets say you have
3 30d scripts, 1June, 15June, 25July. That’d give you record-specific end
dates of 1June->1July, 15June->15July, 25July->25Aug. Now, the first and
second script overlap by 15days, and you have to make a choice of how to
handle that period of overlap. During the initial OMOP work we evaluated
the difference between looking at stockpiling methods vs. just inferring
the new script signified a new start, as well as looking at different
persistence window assumptions, and our bottom line conclusion was it
didn’t matter all that much in general. Because we saw a fair bit of
overlap occuring when there was dose changes, and that seemed to be more
plausible to stop/start, than to stockpile, we adopted the convention to
combine the records without adding overlap to the end. So, in this
example, the first and second record would be combined to make one
temporary era, 1June->15July, and then this record would be combined with
the third script to make one final era that goes from 1June->25Aug. Now,
because there was a 10day gap between the end of the second script and the
start of the third script, the GAP_DAY = 10.
It’s important to reinforce, none of these rules are inherently right or
wrong. They are simply assumptions imposed on the data. I personally
believe there is very large value in imposing a consistent set of rules and
conventions to your data, so that you are not requiring the analysts to 1)
make up new rules, and 2) have to figure out how to code up this logic
without error. But, building up your eras does not preclude you, in a
custom-study-specific fashion to go back to your DRUG_EXPOSURE table and
use denovo custom logic. However, our experience is having the eras
pre-populated with easily defensible common assumptions becomes a
straight-forward and more-than-often sufficient step to preparing your data
for analysis.
This is an interesting discussion. We have worked with CMS VRDC data (virtual research data center, Medicare data) and ran into the same problem. We used paid drug claim date and days_supply.
The issue with stockpiling is something we considered. We looked at how patients switch drugs within the same class or concomitant drug use using the model of claim date+days_supply. (simple model) However some rows had very high days_supply and this model had limits.
A better model (extending the mere date+days_supply) would be to analyze each dispensing date in relationship to the previous and following (same ingredient or same class prescription [date+days_supply+context(previous and next re-fill)) (extended model) and see if gap_days occur or “excess_days” occur (excess days were more important in our project). Perhaps we could even consider using negative gap_days to record excess_days?
The question was whether a patient is switching to a different ingredient in the same class or same ingredient-different-vendor or completely switching classes (ACEi to beta-blocker). The extended model could be a little hard to do in SQL alone.
@Patrick_Ryan, you are correct, that was what I was asking, and thanks very much, your explanations were extremely helpful!
@Christian_Reich, thank you though for clarifying that; I did end up using 30 as the default Persistence Window when I was adapting Chris Knoll’s era codes to PostgreSQL, so we’re all good there!
Sounds good, except that’s not how we described it in the documentation. Want to write the fix distinguishing it from the Persistence Window (which is not mentioned at all in the text)?
I agree that it should be updated. I got confused and thought the first part of the definition of gap_days was what Patrick gave in his examples here on the thread, and the second part of it sounds like the Persistence Window definition that you were talking about, Christian, so I didn’t know what gap_days was asking for… thus this thread was created!
So @Patrick_Ryan, just to make sure I understand what you are saying here, you are saying that there are basically two ways to do this:
… did I get this right? Is there anything I missed/didn’t seem to understand correctly?
Correct. In the stockpiling method you would even extend the overall duration if enough drug was stockpiled during those overlaps and the decremented gap_days are negative.
Fixed in the documentation.
Need to get the standard algorithm published. Taylor: Consider putting yours into the OHDSI github. Start a new repo called “Standard Algorithm for creating Era tables” and publish.
Hi @Christian_Reich,
When you say “extend the overall duration if enough drug was stockpiled during those overlaps”, do you mean extend the end_date of the era?
Taylor
Sure! Does it matter that everything is written in PostgreSQL?
Yes. Folks would honest to God finish every one tablet they have in all those yellow drug flasks. 
That was the wrong question. Remember those days, when you asked your mother “You mean, I should do the dishes too?”
Would be wonderful to get them in all three supported dialects. But if not, one is better than none, absolutely. It’s Open Source. If somebody needs an Oracle version instead of PostgreSQL - it’s his job! But at least he can use your version as a starting point.
Hahaha sounds good Christian! I’ll get started putting it all together
Taylor