OHDSI Home | Forums | Wiki | Github

Replicate ResDAC phenotypes for chronic conditions

General
#1

In efforts to build phenotype library (in addition to PheKB), it would be interesting to replicated ResDAC phenotypes defined here

https://www.ccwdata.org/web/guest/condition-categories

We use VRDC platform and use those flags all the time and to make comparable analysis in OHDSI network, having them as OHDSI cohort would be very powerful.

For example, for OPIOIDS, there are nice valuesets defined here
https://www.ccwdata.org/documents/10280/19139421/other-condition-algorithms-and-reference-list-opioids.pdf

We could even compare if we get same results using mapped HCPCS procedure-drugs vs. CCW query using original source_values.

list of some examples

image.png928Ă—664 45.5 KB

#2

@Vojtech_Huser
How do you know that narcotics in, for example,
T40605S Adverse effect of unspecified narcotics, sequela
T40691D Poisoning by other narcotics, accidental (unintentional), subsequent encounter

are opioids? Actually, according to ICD10CM classification, they are not.

Although building a phenotype repository is a great idea, these CCW Chronic Conditions are not phenotypes but rather sets of codes. Am I missing something on the website?

#3

just to report that Sentinel GUI-based query tool is using these definitions to generate covariates. I think there is some need in OHDSI to have at least some chronic condition phenotypes…

Just to illustrate a COPD example:

image
image1719Ă—342 36.7 KB

for COPD: for example one code of J44.0 maps to SCT:35208023
Going one level up in SNOMED goes to SCT:13645005

It would be possible to develop concept_relationship table queries to arrive at as close as possible OMOP definition.

for COPD: for example one code of J44.0 maps to SCT:35208023
Going one level up in SNOMED goes to SCT:13645005

It would be possible to develop concept_relationsnhip table queries to arrive at as close as possible OMOP definition.

Perhaps someone in OHDSI already had this problem of mapping a set of ICD codes to a closest list of athena codes. (SCT codes essentially). Anyone out there doing this?

#4

Thanks @Vojtech_Huser, this is a useful direction for the community to consider. Just to confirm, are you recommending that 1) we add CCW concept as classifications within the standardized vocabularies (to whatever extent possible, subject to the ICD9/10 -> SNOMED mapping), or 2) that we create cohorts that represent each CCW element, to be used as inputs as Ts, Cs, and Os in any OHDSI standardized analyses; or 3) that we add more features to the FeatureExtraction package, so that CCW-like covariates can be selected into prediction models, such as the propensity score within a CohortMethod estimation or a PatientLevelPrediction analysis? Or all of the above?

1 Like
#5

Just one technical note on some of these definitions. When the idea of “2 outpatient claims” is used (see CCW for diabetes), it can create immortal time problems for creating cohorts. Typically these definitions look for at least 2 codes at least 30 days apart and within 365 days. For diabetes CCW, the codes only have to be at least 1 day apart. But that is not the tricky part – it is the “within” piece that can be a problem if, for example, someone qualifies for a cohort by virtue of 2 codes that were 300 days apart. If the first code is used as the index date, that person cannot die for 300 days. So, it is important to use the second code for setting a cohort index date. On the other hand, if one wants to use the algorithm as an outcome variable, it is probably better to use the first date. Similarly, for a baseline variable, the first is probably more useful, particularly if one wants to measure duration of diabetes as a covariate.

Specific research questions will dictate the proper construction of the algorithm, of course.

1 Like
#6

We actually thought of bringing things like the CCW in. The problem is this: They are a classification of ICD codes (amongst others), which are source concepts. Source concepts do not participate in the hierarchy. The reason is simple: Porting it over and attaching it to SNOMED will create constant hierarchy clashes (and already does with the rudimentary internal ICD hierarchy, see @Polina_Talapova’s poster at the recent European Symposium).

Also, I am not sure SNOMED doesn’t already have those well covered. Would have to check it out.

Very well observed. Currently, we don’t have any systematic tools, scripts or even cookbook chapters that cover these issues. People have to just “know” them. Lots of opportunity for systematic work.

#7

to reply to Patrick - Yes to points 2 and 3. (point 3 - as features in FeatureExtraction is the most important.

(probably no need to do 1)

t