OHDSI Home | Forums | Wiki | Github

Ingredient specific Persistence Window (drug exposure and drug era)

For our HIV research study (component of HIV Rx Treatment pathway), we want to define ingredient specific Persistence Window.

The CDM specs recommend using COHORT table for this. (see below).

Our public cohort definition for this cohort is here http://www.ohdsi.org/web/atlas/#/cohortdefinition/1771629

The intend is that for non-compliance for ingredient tenofovir, we will still be fine with gap of 60 or 90 (for the purpose of Rx Pathway analysis, not true compliance)
(different from the default of 30 (or other) chosen by a given site at ETL time).That way we can ensure the same tenofovir Persistence Window across sites in our study.

What is the proper place to enter 60 or 90?
Is there a site and research project that ever defined ingredient specific gaps?

(tagging @schuemie, @Patrick_Ryan, @Christian_Reich )

Here:?
image


specs

@Vojtech_Huser:

The settings for DRUG_ERA are set. 30 days persistence and no stockpiling. If you want to replace that with ingredient-specific settings - please propose to the CDM WG. Of course you would have to create or adopt such a heuristic.

The persistence window in ATLAS and its ability to consolidate cohort records has nothing to do with the ERAs. It’s up to you what you define in your cohort.

I am OK with current approach of fixed persistence window. No need to go to CDM WG.

The questions is whether anyone is following the advice in convention DRUG_ERA.8 https://github.com/OHDSI/CommonDataModel/wiki/DRUG_ERA#conventions
It says : Researchers are encouraged to consider creating their own Drug Eras with different parameters as Cohorts and store them in the COHORT table.

So I am asking if Atlas can be used to generate SQL that would establish a different gap. (or otherwise get to such SQL). Ideally, it would be part of OhdsiRTools package. You would specify ingredient concept_id and preferred gap and your desired cohort_id for it and it would make it happen. (just like Atlas does it for other cohorts via web or via method insertCohortDefinitionInPackage defined here https://github.com/OHDSI/OhdsiRTools/blob/master/R/WebApiTools.R#L115

From your answer I understand that currently in Atlas, that is not possible. (did I get that right?)

No, you did not get that right. You can define cohorts in atlas, and if you want ingredient specific persistence windows, then you define your cohort to use each drug_exposure for a given ingreidnet, and specify a fixed persistence window.

The screenshot you provided in your first post focused on the ‘cohort era collapse’ which just combines sub-episodes of cohort eras together if the end of one is within X days of the start of the next. Which you could do if you made each cohort event the individual drug exposure, and you wanted to use the drug exposure’s start_end date.

However, in your case, I think you want to assume a fixed duration of the exposure from the start of the exposure (Is this what you intend?) If so, you can instead use the ‘event persistence’ option to specify that you want the event (the drug_exposure to the ingredient) to persist for 60 or 90 days, like this:

So, to put it all together, you would define your cohort like this:

Cohort entry event: drug exposure of drugs with descendants from Ingredient X
Cohort Exit: event will persist until ‘fixed duration relative to initial event’: Start Date + 60 days

This will produce a series of 60 day episodes for the person, each episode begins with a drug exposure that descends from the Ingredient. A different ingredient could be used in a differnt cohort, using ingredient specific persistence.

Finally, you can decide that if there are 2 drug episodes that are within 45 days (for example) of each other (ie: the datediff between the earlier episode’s end date and the later episode’s start date <= 45) should collapse into a single episode. that is what the Cohort Era’s ‘gap size’ refers to.

The idea of ‘stockpiling’ is not handled in Atlas cohort definitions, so if you want to handle cases where overlapping exposures should lead to ‘expanding’ the duration based on the amount of overlap (ie: stockpiling means you are going to extend the next episode), then you will have to write custom queries to handle that.

1 Like
t