OHDSI Home | Forums | Wiki | Github

Duplicate CONCEPT_ID's for different Condition Concept ID's

(John Dolan) #1

I have noticed that in the CONCEPT RELATIONSHIP file that there are multiple CONCEPT_ID_2 records for CONCEPT_ID_1. This is causing multiple rows in the CONDITION_OCCURRENCE table for these CONCEPT_CODE’s. These concept codes (‘642.33’, ‘654.23’, ‘719.46’, ‘724.4’) translate to these concept_id’s (44833715, 44830241, 44831507, 44836203) in the concept table. they in turn translate to these concept_id_2 records in the Relationship table.
44830241 444114 Maps to
44830241 4060559 Maps to
44831507 77074 Maps to
44831507 4024561 Maps to
44833715 441922 Maps to
44833715 444094 Maps to
44836203 4012690 Maps to
44836203 4027396 Maps to

(Anna Karenina) #2

Hello @johnnyd,

It’s OK for some concepts to have several mappings. Regarding your example, these specific ICD terms can be “decomposed” into several standard SNOMED concepts, which are more granular. For example, 44831507 “Pain in joint, lower leg” is, without doubt, a Joint pain, and it also indicates that patient has a Pain in lower limb, which is more specific. This allows to collect cohorts based on less/more granular criteria, as required by the use case.

So it’s not a bug but a feature. But if still in doubt, you can summon someone from vocabulary team to the rescue (Alexdavv, for example).

(John Dolan) #3

Anna, my issue is that if I have one ICD code and it returns two rows for 100,000 patients, then the result is 200,000 rows in my OMOP Condition table. And how do I know which of the two relationship records is correct?

(Anna Karenina) #4

They both are. For Condition domain, SNOMED is the standard coding system; if a concept from other system cannot be mapped directly to a single SNOMED concept, it is mapped to several concepts to preserve the meaning of the source code through available standard terms.
These codes do not represent two completely unrelated conditions, they describe a single condition. The resulting records in Condition table will have all other attributes equal.

By the way, having two target concepts is not the limit :slight_smile:


I am surprised these two concepts are not related though through the concept_ancestor table. For example, I cannot see that they are descendants or ancestors of each other. Is it just saying in ‘Maps’ to it is equivalent?

(Anna Karenina) #6


I don’t know. Basically, each relationship between concepts should also be represented in Concept Ancestor table, so this is indeed strange. Let’s ask @Dymshyts about it.

(Alexander Davydov) #7

The CONCEPT_ANCESTOR table provides the complete hierarchical relationships between concepts (all parent-child relationships, as well as grandparent-grandchild relationships and those of any other level of lineage).

‘Maps to’, ‘Has unit’, ‘Has direct morphology’ are not hierarchical, while ‘Is a’/‘Subsumes’, ‘Has ingredient’ are. Can be easily checked in the RELATIONSHIP table - look at is_hierachial field. Also, there are some more complex things: ‘MedDRA to SNOMED equivalent’ is not hierarchical, but participates in the CONCEPT_ANCESTOR table (look at defines_ancestry field).

Also, keep in mind that:

  • Each concept is also recorded as an ancestor of itself.
  • Only valid and Standard/Classification concepts participate in the CONCEPT_ANCESTOR table. It is not possible to find ancestors or descendants of deprecated or non-Standard concepts.