OHDSI Home | Forums | Wiki | Github

ICD10CM codes map to multiple standard SNOMED codes

As the topic says, I’m having an issue with ICD10CM codes mapping to multiple standard SNOMED codes. I don’t see any other posts about this, which makes me wonder if I’m understanding OMOP correctly.

For instance, I61.1 (Nontraumatic intracerebral hemorrhage in hemisphere, cortical) maps to two Standard SNOMED codes: Cortical hemorrhage:4176892 and Spontaneous cerebral hemorrhage: 43530727 (see http://athena.ohdsi.org/search-terms/terms/35207809)

Both of these show as the Primary Condition. Can I have two primary conditions? Does that make sense?

Moving on, when I query these from the Concept Relationship table for 35207809 (concept_id for I61.1):

SELECT [concept_id_1]
,[concept_id_2]
,[relationship_id]
,[valid_start_date]
,[valid_end_date]
,[invalid_reason]
FROM [OMOP].[concept_relationship]
where [concept_id_1] = 35207809

I get:
image

Several things jump out at me. The two “Maps to” relationships have different valid_start_dates, but have the same valid_end_dates. Does this mean that after 2017, both values are valid, but only the first before that? Or should the valid_end_date of the first be 2017-09-30, and there is just a single valid mapping during each range? (As a side note, I don’t see any valid_end_date other than 2099-12-31.)

I decided to see if there are any other ICD10CM codes that have multiple concepts mapped
SELECT [vocabulary_id]
,[concept_id_1]
,count([concept_id_2]) as countCONCEPTS
,[relationship_id]
,[concept_relationship].[valid_start_date]
,[concept_relationship].[valid_end_date]
FROM [EpicCare].[OMOP].[concept_relationship]
inner join omop.concept on concept_id_1 = concept_id
where [relationship_id] = ‘Maps to’ and [vocabulary_id] = ‘ICD10CM’
group by [vocabulary_id],[concept_id_1]
,[relationship_id]
,[concept_relationship].[valid_start_date]
,[concept_relationship].[valid_end_date]
having count([concept_id_2])>1

image

It turns out there are >11,000 IDC codes that map to multiple codes. I group them by valid_start_date, which means all of these have the SAME valid_start_date, not different ones like I61.1.

So I returned all the details of records,
with Count2 as
(
SELECT [vocabulary_id]
,[concept_id_1]
,count([concept_id_2]) as countCONCEPTS
,[relationship_id]
,[concept_relationship].[valid_start_date]
,[concept_relationship].[valid_end_date]
FROM [EpicCare].[OMOP].[concept_relationship]
inner join omop.concept on concept_id_1 = concept_id
where [relationship_id] = ‘Maps to’ and [vocabulary_id] = ‘ICD10CM’
group by [vocabulary_id],[concept_id_1]
,[relationship_id]
,[concept_relationship].[valid_start_date]
,[concept_relationship].[valid_end_date]
having count([concept_id_2])>1
)
SELECT [concept_relationship].[concept_id_1]
,[concept_id_2]
,[concept_relationship].[relationship_id]
,[concept_relationship].[valid_start_date]
,[concept_relationship].[valid_end_date]
,[invalid_reason]
FROM [OMOP].[concept_relationship]
inner join Count2
on [concept_relationship].[concept_id_1] = Count2.[concept_id_1]
where [concept_relationship].[relationship_id] = ‘Maps to’
–AND [concept_relationship].concept_id_1 = 35210345
order by [concept_relationship].[concept_id_1]

Which shows there are in fact multiple mappings with the same valid date
image

And so here is where my confusion lies. I thought an ICD10CM code should map to a single SNOWMED code. If it can map to multiples, which code should I choose to represent the condition? Or is it correct to list them both?

Please help me understand.

1 Like

So I’m a scientist/researcher not a database person. The SNOMED terms are less specific in my view. Which is “correct” is a medical call. It might be an interesting exercise to see how the terms maps to MedDRA.

Some research articles:
Nontraumatic intracerebral hemorrhage in hemisphere, cortical

Spontaneous cerebral hemorrhage

Cortical hemorrhage

@roger.carlson an ICD10CM concept can have more than one (2-4) “Maps to” relationship in a case when there is no a full SNOMED equivalent. Such a combination of SNOMED concepts gives an opportunity to cover more ICD1OCM attributes (such as localisation, laterality, gender, clinical course, morphological peculiarities, some circumstances, etc.) and reflect the meaning of a source concept as accurate as possible. So, it is correct to list all standard SNOMED concepts mapped from each ICD1OCM concept you need.

1 Like

Yes, it’s correct when ICD maps to couple of SNOMED concepts.
The general rule:
Concept “A with B” (ICD)
When “A with B” exists in SNOMED, we map it to “A with B” (SNOMED)
if not
we have
“A with B” (ICD) Maps to A (SNOMED)
“A with B” (ICD) Maps to B (SNOMED)

Okay. I guess I see that. The fact that OMOP retains the original concept code adds whatever additional information needed to tie them together.

So now the question about valid dates. So for those with different valid start dates, i.e.

  • A: 1970-01-01
  • B: 2017-10-01

should it be:

Before 2017-10-01
“A with B” (ICD) Maps to A (SNOMED)

After 2017-10-01
“A with B” (ICD) Maps to A (SNOMED)
“A with B” (ICD) Maps to B (SNOMED)

@roger.carlson Yes, this is correct!

valid_start_date in the concept_relationship table indicates when such a relationship (mapping) was created. “1970-01-01” is about an unknown exact date in the distant past.

Hello,

Sorry for reviving this old thread. So a single ICD code mapping to two SNOMED codes (standard OMOP concept ids), should just be stored as 2 rows of data in the condition_occurrence table. Does this valid_start_date and valid_end_date columns matter?

I see all the concepts that I came across end on 2099-12-31, so does the start_date even matter? So, am I right to understand that we can just store it as 2 rows of data in condition_occurrence table… If it maps to 3 standard concepts, I am just storing it as 3 rows in condition_occurrence table. Can someone correct me on this?

Valid start date indicates when this relationship was introduced to OMOP vocabulary. So it doesn’t matter for an ETL.

Yes, 2 rows

Yes, 3 rows

No correction needed, you’re absolutely right :slight_smile:

1 Like

Hi @Dymshyts - Thanks for your help and time. I have another follow-up question.

q1) Is there anyway to fetch from Athena such concepts? or from the vocabulary tables without having any source terms? I would like to see what are those terms that have this multiple term mappings… For ex: If I had source term, I can put that and find in Athena the corresponding multiple concepts. Now, let’s say that I don’t have any source but would like to get an idea on what kind of terms are being mapped to multiple concepts. So, is there anyway to identify such multiple term concepts in Athena?

q2) How does Usagi map these multiple terms? I assume it maps only to one or is the tool intelligent enough to map it both (because of concept relationship and all)? I don’t have any source term that meets this requirement to try it in Usagi myself.

Thanks a lot for your help and time

No. Only by writing the SQL query. Let me know if you need help with this.

Good question.
I’m not sure Usagi can map to several concepts.
I know that usagi matches your source concepts not only to standard concepts directly, but to non-standard (ICD10, for example) and then gets the proposed mapping through existing ICD10 to SNOMED mapping.
@MaximMoinat how such cases, when the intermidiate ICD10 concept has multiple mappings, are processed?

1 Like

@Dymshyts - How does it impact my analysis if I choose to map it to only one term instead of 2 terms.

For example, with click here example unspecified complication of pregnancy, Can I map it only to Complication occurring during pregnancy with a concept id 43530950

If I ignore the other concept which is Finding related to pregnancy with a concept id 444094, how will this affect my analysis? What’s the probem in mapping it to only one term?

Because I feel the concept id 43530950 kind of covers what I am looking for. Why do I have to worry about 444094?

So, is it okay to map only to one of the 2 or 3 related terms and ignore the rest?

From a data guy perspective, it seems okay to me. But yes, your inputs would be helpful

But is there any OMOP CDM convention/guideline that exists which mandates us to map it to multiple terms (as in Athena) or it’s totally fine to map it to a term which we find as appropriate (purely an ETL decision)?

As an ETL guy myself (and the person who started this thread), I understand why this is so confusing.

First of all, the purpose of OMOP is to be able to share data across institutions/platforms. Even though 43530950 covers what you want, what happens if 444094 is the code that your data sharing partner wants? Having common codes that map to the same condition is vital to the whole idea of OMOP. You’re not going to query the condition_occurrence table for how many conditions a person has, because that’s meaningless all by itself. What’s important is what conditions they had and how you can match that to other people’s data.

Secondly, I’m not sure I understand what you mean by “choosing to map”. The mapping has already been done in the concept, concept_relationships, concept_ancestors, etc. You don’t have to do any mapping yourself for standard code systems (like ICD10). USAGI is only used for mapping codes local to your EHR that do not have standard mappings.

1 Like

In addition to what Dymtry and Roger stated above.

I HIGHLY recommend reading Chapter 5 in The Book of OHDSI! This will further explain mapping and vocabularies.

Hi, I am a data analyst and I still new to OMOP and learning. I have a question related to this thread.

Question:
when an ICD code returns 3 matching SNOMED concept_ids, and if the other two SNOMED concept_ids also match with other ICD codes, how do we make sure we search for the right patients based on the combination of all 3 SNOMED concept_ids. I am not sure if ICD to SNOMED is a one-to-one match, but if it’s not, then it could be hard to search for patients.
For example,
the following ICD-9
800.92 - Open fracture of vault of skull with intracranial injury of other and unspecified nature, with brief [less than one hour] loss of consciousness

returns 3 SNOMED concept_ids

439143 Open fracture vault of skull with intracranial injury
381135 Brief loss of consciousness
437385 Intracranial injury with loss of consciousness

When I search condition_occurrence table using these 3 concepts, what if 381135 pulls a patient that is not related to fracture? Does that ever happen?

@sairam:

Yeah, that question comes up from time to time.

The particular ICD you are quoting defines three different conditions, and as you correctly pointed out each of them could occur under different circumstances. So, why would you ask for exactly that combination of things? There could be two reasons: (i) somebody is used to and adamant on getting his ICD10 codes, only those and nothing else, or (ii) you really need a combo of those three things. Either way, the solution is to look for all three (open fracture of the skull, intracranial injury and loss of consciousness) on the same day.

You might get patients where these things were not recorded in a single ICD, but separately. Is that a problem? Does not look like one to me.

@Christian_Reich
Thank you. I’ve been provided with a set of ICD-9 codes, such as 800.92, which yield multiple SNOMED standard concept IDs. I’m concerned that if these SNOMED concepts aren’t used in conjunction (using the OR operator rather than the AND operator), it might result in pulling patients who never experienced a fracture but had a momentary loss of consciousness. Since I’m not a clinician, I’m unsure if this scenario occurs, but it certainly seems problematic. The easier solution I can think of is to double-check that my patient list actually includes cases of fractures to eliminate any false positives.

Worry not. The ICD9s were created to report on patients’ morbidity and mortality, most often for reasons of paying providers. They were not passed down by the Lord to the Prophet. If the researchers want to study skull fracture, injury to the brain and loss of consciousness all at once they will ask for this. If they want 2 out of 3, they will do that. It works. ICD9 and ICD10 don’t jive that much anyway, and SNOMED rarely has these combo conditions.

t