Concept hierarchy for OMOP Conditions

[lrasmus]

Thanks so much for the excellent leaf-scripts for OMOP. I am sorry to ask for 'more, more, more', but before working on this myself I was wondering if anyone had created a Leaf Concept hierarchy for OMOP Conditions? Given that OMOP relies on SNOMED for conditions, I was curious in part of any SNOMED-based hierarchy for conditions is the best way to go, or if using an ICD-based hierarchy is better.

Happy to contribute back anything we create if a solution doesn't already exist.

[ndobb]

Hi @lrasmus,

I'm glad those scripts have been useful and that's totally fine. @artgoldberg and I and others have discussed strategies for diagnoses a bit and I think many have questions similar to this.

My personal opinion is that users are >90% of the time going to be much more comfortable using and interpreting ICD{9|10} codes rather than SNOMED, given widespread use in EHRs and billing, etc. Given that there there are also far less ICD-10 codes than SNOMED, for example, it's also more compact and presumably easier to navigate than a SNOMED hierarchy, potentially.

Given those assumptions, we haven't found a nice one-size-fits-all solution as different sites have different preferences and may populate their OMOP DBs differently, for example using SNOMED vs. ICD-10 for concept mapping, and populating the source_condition_value with ICD-10 or not, etc. So what the WHERE clause does in Leaf potentially can vary quite a bit. Last, if I recall correctly when last I checked the ICD-10 tree was not fully represented in the OMOP concept_ancestor table, so we weren't able to properly leverage that as we'd like.

@lrasmus in your OMOP DB, how are you populating conditions?

[ndobb]

@artgoldberg, I just checked our prod UW Leaf instance and UMLS DB (which is up to date, to my knowledge). I'm seeing 72,616 unique ICD10 codes in UMLS and slightly less in our Leaf instance (which probably is overdue for adding newer ICD10 codes). The UMLS_ICD10 table includes ranges of codes in a hierarchical format, so it makes sense that that would have more rows.

So I would say 72,616 ICD10 codes should be roughly what we should aim for, using UMLS as our gold standard. Any idea what codes could be being dropped? I'm happy to help debug if feasible.

For reference, the UMLS query I'm doing is:

SELECT COUNT(DISTINCT CODE)
FROM UMLS.MRCONSO
WHERE SAB = 'ICD10CM'
      AND TTY = 'PT' /* Preferred Term */

[lrasmus]

One consideration I've wrestled with before, do we include all ICD10 codes (and just let people know if there are 0 patients with any code), or do we only load the ICD10 codes that have been assigned to patients? I've opted for the former, just because I can imagine confusion searching for an ICD10 code to perform a query and the code doesn't exist.

I mention it wondering if @artgoldberg is seeing fewer codes because if the source isn't the UMLS, if it's only including a subset of ICD10 codes that could be assigned (meaning it may have already filtered out codes that aren't allowed for billing)?

[ndobb]

Ah that's a really good point, @lrasmus. At UW we include even codes that have never been used (ie, zero patients) so our users can distinguish between codes that haven't been given versus codes that haven't yet been added to Leaf.

[artgoldberg]

You've hit the nail on the head @lrasmus . My more clinical colleagues have recommended that we filter out diagnoses that have not been assigned to patients in the EHR. My 49,503 unique ICD10 codes includes that filter.

But if I obtain all ICD10 codes, including ones that map to Epic codes that are have not been used by clinicians, I find 95,506 unique ICD10 codes in our clinical DW. Given your point @ndobb , I'll revisit that recommendation by my colleagues.

Overall, I'm comfortable with the number of unique ICD10 codes we have. They're in the neighborhood of what you find Nic, and our number of active codes makes sense.

Arthur

[artgoldberg]

Hello @ndobb and @lrasmus

I've been thinking about this discussion. We should more carefully analyze the decision whether to include ICD10CM codes that map to Epic codes that have not been used by clinicians.

Not including these ICD10CM codes only changes the CDM's concept_relationship table. Leaving them out does not change the LeafDB.app.Concept table, because it is determined by the UMLS_ICD10 table, which depends only on the UMLS table MRHIER.RRF that maps ICD10CM concepts into a hierarchy. Thus, the structure of the Leaf interface depends only on MRHIER.RRF.

Since a complete concept_relationship table may help other software that uses the CDM, I conclude that all 1-to-1 mappings between Epic EDG .1 codes and ICD10CM codes should be included in it.

Arthur