Missing RxNorm mappings for cholesterol medications

quinnt · January 14, 2021, 4:07pm

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?

quinnt · January 14, 2021, 10:46pm

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?

Dymshyts · January 15, 2021, 12:27pm

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).