Missing RxNorm mappings for cholesterol medications

Vocabulary Users
1

We’re working on a project involving cholesterol medications and our query wasn’t picking up all the drugs that we thought it should. Deeper investigation revealed some RxNorm medication codes that are not mapped to their corresponding RxNorm ingredient codes (in either concept_relationship or concept_ancestor).

A few examples:

concept_id_1 concept_code_1 concept_name_1 concept_id_2 concept_code_2 concept_name_2
19095325 848943 cholestyramine resin 4000 MG Powder for Oral Suspension 19095309 2447 cholestyramine resin
40231765 1048450 colestipol hydrochloride 5000 MG Granules for Oral Suspension 1501617 2685 colestipol
19077577 310459 gemfibrozil 600 MG Oral Tablet 1558242 4719 gemfibrozil
19019117 197905 lovastatin 40 MG Oral Tablet 1592085 6472 lovastatin
19019301 198024 niacin 500 MG Oral Tablet 1517824 7393 niacin

We confirmed these relationships by checking the U.S. National Library of Medicine’s RxNav tool. For example, here is the entry for RxCUI = 848943 showing an ingredient of cholestyramine resin (RxCUI = 2447).

Our full list of 32 RxNorm codes is in the attached spreadsheet: Unmapped-RxNorm-concepts_2021-01-06.xlsx (12.6 KB)

If these relationships are part of the RxNorm vocabulary, why wouldn’t they be reflected in Athena? Is there an Athena guru who can take a look?

2

File this under the foot-in-mouth or egg-on-face department:

We’ve discovered that these RxNorm relationships are, in fact, included in the concept_ancestor table.

SELECT
 ca.descendant_concept_id 
,c1.concept_code 
,c1.concept_name 
,ca.ancestor_concept_id 
,c2.concept_code 
,c2.concept_name 
FROM omop_cdm.concept c1
INNER JOIN omop_cdm.concept_ancestor ca
ON c1.concept_id = ca.descendant_concept_id
INNER JOIN omop_cdm.concept c2
ON ca.ancestor_concept_id = c2.concept_id
WHERE c1.concept_id IN (
19095325, 40231765, 19077577, 19019117, 19019301, 1517827 ,
19020516, 19078988, 40237545, 40237547, 1551838 , 19112640,
1551924 , 1539407 , 19023563, 1539411 , 1539462 , 1539463 ,
40175390, 40175394, 40175400, 1545959 , 19123592, 1545996 ,
1545997 , 40167020, 40165257, 40165261, 40165245, 40165253,
1526476 , 1526479 )
AND c2.concept_code IN (
'2447'  , '2685'  , '4719'  , '6472'  , '7393'  , '8703'  ,
'36567' , '42463' , '83367' , '141626', '301542', '341248',
'495215');

We were led astray by this sentence in the OMOP data dictionary for concept_ancestor and didn’t confirm via SQL query:

Only direct parent-child relationships between Concepts are stored in the CONCEPT_RELATIONSHIP table.

Here is our query that confirms these relationships are not in concept_relationship because it returns zero rows:

SELECT
 cr.concept_id_1
,c1.concept_code 
,c1.concept_name 
,cr.relationship_id 
,cr.concept_id_2 
,c2.concept_code 
,c2.concept_name 
FROM omop_cdm.concept c1
INNER JOIN omop_cdm.concept_relationship cr
ON c1.concept_id = cr.concept_id_1
INNER JOIN omop_cdm.concept c2
ON cr.concept_id_2 = c2.concept_id
WHERE c1.concept_id IN (
19095325, 40231765, 19077577, 19019117, 19019301, 1517827 ,
19020516, 19078988, 40237545, 40237547, 1551838 , 19112640,
1551924 , 1539407 , 19023563, 1539411 , 1539462 , 1539463 ,
40175390, 40175394, 40175400, 1545959 , 19123592, 1545996 ,
1545997 , 40167020, 40165257, 40165261, 40165245, 40165253,
1526476 , 1526479 )
AND c2.concept_code IN (
'2447'  , '2685'  , '4719'  , '6472'  , '7393'  , '8703'  ,
'36567' , '42463' , '83367' , '141626', '301542', '341248',
'495215');

I can envision a way to combine the concept_ancestor and concept_relationship into a single table via the intelligent definition of relationship types (along with a willingness to store multi-level hierarchical relationships in concept_relationship).

Yes, I understand the distinction between direct parent-child links and indirect links like grandparent–grandchild or great-grandparent–great-grandchild. But end users use them the same way. My proof is the similarity of the join conditions in the FROM clauses of my two queries above.

Is there any appetite for considering such a proposal?

3

CONCEPT_RELATIONSHIP table contains not only hierarchical but lateral relationships.
So, if I want to find the descendants - usually needed when creating a concept set - as you actually did, I would use CONCEPT_ANCESTOR, and don’t worry about getting something else through lateral relationships.
Then I thought, that I might look at the relationship_id in this proposed ancestor-relationship table.
In this case to deal with hierarchical relationships, I would need to collapse different relationships into one category: Consists of (RxNorm), Has marketed form (OMOP), Has tradename (RxNorm), Is a (RxNorm) and so on, which is already done in CONCEPT_ANCESTOR.
And lateral relationships such as ‘Has dose form’ and ‘Has brand name’ just don’t have several nesting levels.

I enjoyed the exercise of thinking of possible changes, and satisfied that the current model is the best (at least for me).

1 Like