Hi @SCYou, just so its documented:
The options that are currently available to the OHDSI community for creating cohort definitions are:
-
Create a cohort definition that uses a conceptset that contains standard concepts. Pros: it will be a cohort definition that can run across the OHDSI network, independent of the source coding scheme. Cons: the standard concepts may have mappings from certain source codes that others may prefer not to see in their phenotype definition. In this example, when defining ‘cerebral infarction’, one group could reasonably argue that they should include ICD10 G43.6x ‘persistent migraine aura with cerebral infraction’ (because it explicitly suggests the presence of cerebral infarction), while other researchers could reasonably argue that this isn’t the same clinical construct of cerebral infarction that they are looking for.
-
Create a cohort definition that uses a conceptset that contains source codes. Pros: you can tailor your list of codes to whatever level of precision you want (e.g. cherry picking the ICD9 and ICD10 codes without regard to how they map up to SNOMED). Cons: this cohort definition will only be applicable to databases that use the same source codes.
My general preference is to support global research across the diverse community of researchers and databases throughout OHDSI, so I advocate for #1 whenever possible, but there are certainly instances when #2 is necessary and ‘good enough’ if you know you are only doing your study in your own data. In either case, both of these alternatives are fully supported in the OMOP CDM and also fully supported using ATLAS as OHDSI’s standard platform for defining and instantiating cohorts.
Now, to the specific question of ‘what did I do for stroke when we were designing the protocol for LEGEND?’, I did the same investigation tat you did @SCYou, I empirically evaluated how often the questionable ICD9/10 codes for ‘migraine with cerebral infarction’ actually arose across my databases. And it wasn’t never, but it was very uncommon…less than 1% of the total number of strokes across all the databases. The other thing I noticed is, in a good chunk of the cases, a person who had the ‘migraine with cerebral infraction’ code also had a ‘cerebral infarction’ code, meaning they’d be picked up in our phenotype definition whether or not we included that code. So, in the interest of enabling global research, I went with approach #1, keeping in this code that some would argue to keep in and some would argue to keep out, recognizing that it actually doesn’t have any practical impact one way or the other.
In general, I think the approach we should be taking is not to subjectively argue for or against a given code, but using the data to determine whether that code makes a difference in the prevalence and composition of a given phenotype. And I agree we should be trying to more systematically validating our phenotypes. One of the compelling aspects of @jswerdel’s PheValuator approach is that it provides an objective basis to compare the operating characteristics of alternative definitions. So, from this example, if we were worried about the impact of inclusion/exclusion of the ‘migraine with cerebral infarction’ code, we could create 2 phenotypes and then run PheValuator to see the impact on sensitivity/specificity/positive predictive value. And since the indepedent prevalence of the code in question is so low, we’d see that it doesn’t make a difference and so probably not where we should be spending our time wringing our hands.
