Open hwang2739 opened 3 years ago
@hwang2739:
Because 37061620 is a LOINC component, and not a full-fledged LOINC concept. Therefore, it does not have standard status and will not participate in the hierarchy.
What you want is 40771922 "Glomerular filtration rate/1.73 sq M.predicted [Volume Rate/Area] in Serum, Plasma or Blood". That one is a standard concept, and a 2nd degree descendant of the chemistry concepts.
Please check these issues also: https://github.com/OHDSI/Vocabulary-v5.0/issues/438 https://github.com/OHDSI/Vocabulary-v5.0/issues/301
Thanks for referencing the other issues that our group have created, @Alexdavv :) I think the confusion for us is that we use Athena and assume the 'Is a' relationship corresponds to concepts found in the concept_ancestor table, which does not seem to be the case. For example, you can get to 37061620 from the 'Is a' links within Athen for 40771922.
How should we align Athena and what we find in the concept_ancestor table? @cgreich @Alexdavv
I think the confusion for us is that we use Athena and assume the 'Is a' relationship corresponds to concepts found in the concept_ancestor table
You're right. The convention is concept_ancestor implies the links for Standard/Classicicaion concepts only. While the LOINC parts are non-Standard concepts, but have their internal "Is a"-like hierarchy connected to the LOINC Classifications and, finally, LOINC tests.
Maybe we should avoid hierarchical links for the concepts that are non-Standard by their design. While the concept_ancestor filtering rule is less confusing for deprecated concepts that were Standard/Classification at some point. @cgreich
@Alexdavv and @cgreich - hierarchical links in vocabularies with mostly non-standard concepts (e.g. lots of procedure terminologies or ICD) appears to be quite valuable for many researchers. We even might need an extension to the tools like ATLAS that could make use of these hierarchies to determine matching standard concepts starting from a high level non-standard concept. I vote against dropping hierarchies in a non-standard context. Could we maybe make the concept_ancestor relations visible in Athena instead?
I disagree. We have a system of standard concepts, which represent the facts. They are built into hierarchies (i.e. pre-computed strings of "Is a" links). The others can have the same relationships, but no hierarchies. Otherwise we would undermine the standardization and all the advantages that come with it. If somebody wants local codes - they don't need the OMOP CDM.
Otherwise we would undermine the standardization and all the advantages that come with it.
I’m afraid we already did: https://github.com/OHDSI/Vocabulary-v5.0/issues/517#issuecomment-889389539
I think most of the users blindly believe that non-Standard concepts cannot affect the hierarchy.
We need to review the LOINC concepts and their hierarchies. It works well in the other domains.
@Alexdavv have we kickstarted the process of reviewing the LOINC concepts and their hierarchies then?
When using concept ancestor table to find lowest level common ancestor of these concept_ids (37024736,37027780,37033687,37045756,37052213,37068907,37077746), the lowest level common ancestors found were 37023425, Chemistry - non-challenge and 37032269, Chemistry - challenge. These are too broad. By using Athena, we found the more appropriate concept id 37061620. However, 37061620 is not incorporated in the concept ancestor table, as it is a LOINC Component term.
Could anyone help us understand why these LOINC Component terms are not incorporated in concept ancestor table? What would be the alternative method to look for appropriate lowest level common ancestor?
The vocabulary version we are using is v5.0 02-APR-21.
Thank you so much. Hong
@cgreich @swined @cukarthik