OHDSI Home | Forums | Wiki | Github

SNOMED code deprecation - mapping SOURCE to STANDARD

Vocabulary Users
#1

Hi - I’ve had a look at other posts re issues etc relating to deprecation and wasn’t sure whether to start afresh as nothing seemed quite the same angle.

Where SNOMED CT replace a code (eg allergy to latex) - what is the best reliable route to use CONCEPT and CONCEPT_RELATIONSHIP to ensure that I get always and only the appropriate new standard concept IDs for the now-deprecated codes?

I’ve had a dig around and can see that using the relationships “Concept poss_eq to” or “Concept poss_eq from” might be useful

However, where there’s a direct replacement for one or more deprecated codes to a new standard active SNOMED code - is there possibly a better relationship that could be created to show this more definite, direct linkage - and so aid in the SOURCE_TO_STANDARD mappings for deprecated codes?

Thanks

#2

Hi @lizzie.poole - thank you for your question which I assume many others may have as well. In the respective version of SNOMED content that we have processed (you may have read that we merge three different lineages into one: International, US and UK), we normally make every effort to also process relationships. For one, those we get from SNOMED directly indicating which code is replacing an existing one and then (that is the hardest part) also going through all the existing relationships from non-standard codes in other vocabularies pointing at a former standard SNOMED code that now is deprecated and finding a proper replacement. For the first this is probably a good example for which you may see the “Concept replaced by” relationship. And for the latter, we can navigate into the new target and will find that a Read code now maps into this newer SNOMED concept. Then there are complex SNOMED codes (e.g. with an “OR” connection, eeek!) like this one that SNOMED has rightfully retired and we also process them for possible replacements, assigning “Inactive possibly_equivalent_to active” relationships so that an ETL person, if they would ever encounter such a code, have a fighting chance to track down something usable. So, if you have had custom mappings and you have updated your vocabulary, you would obviously have to verify that all your mappings still go to standard concepts and for those where this is not true anymore, the above relationships should help you repairing your custom mappings before you run another ETL. I hope this somewhat answered your question. Please feel free to come back with more questions!
P.S.: to be fair, there also will be the occasional orphan code that has no proper replacement, so factor those in, too. For them good old manual search and mapping may be required.

1 Like
#3

I’m going to use this thread as a jump off point although it’s not specifically about SNOMED.

I’ve got some standard code I use in my ETL that maps non-standard to standard codes.

    SELECT C2.CONCEPT_ID AS CONCEPT_ID
    ,C1.CONCEPT_ID AS SOURCE_CONCEPT_ID
FROM SH_OMOP_DB_PROD.CDM.CONCEPT AS C1
INNER JOIN SH_OMOP_DB_PROD.CDM.CONCEPT_RELATIONSHIP AS  CR
    ON C1.CONCEPT_ID = CR.CONCEPT_ID_1
        AND UPPER(CR.RELATIONSHIP_ID) = 'MAPS TO'
INNER JOIN SH_OMOP_DB_PROD.CDM.CONCEPT AS  C2
    ON C2.CONCEPT_ID = CR.CONCEPT_ID_2
WHERE C2.STANDARD_CONCEPT = 'S'
    AND (
        C2.INVALID_REASON IS NULL
        OR C2.INVALID_REASON = ''
        )

Nothing remarkable, but is there any reason I could not add “Concept replaced by” to this:

AND UPPER(CR.RELATIONSHIP_ID) IN (‘CONCEPT REPLACED BY’, ‘MAPS TO’)

I’m not entirely certain how the vocabularies evolve over time, so I don’t know if this could be an issue.

#4

Concept replaced by is higher order than maps to, I look for it first before maps to.

EDIT: I build a temp table of unique ‘source id’ and concept_id, then do updates as where concept_id IS NULL. I do an update first on where there is a valid concept_id without any mapping, second is the concept replaced by and then thirdly, maps to.

EDIT 2: I do updates, in steps, as I found that there were a few collisions between the two mapping types, on a few source concepts, that I was mapping over. It has been a few weeks, so I do not remember any of the individual collisions. I also had to run some recursion on ‘maps to’ as well to get a valid and standard concept.

#5

Gents:

Short answer: No need. The concept_replaced_by and similar lateral links are chained together and appended to the Maps to before a release, creating a new Maps to from any source to the target concept.

Longer answer: Having said that, I am not sure the team is not struggling with some bugs in this chaining. But it should work that way. You don’t have to make your own sausage.

1 Like
Snomed concept_relationship = 'Concept replaced by' not in Snomed concept_relationship = 'maps to'
#6

If I run across the collisions and/or those in need of a recursive search (it may be next quarter), I will forward them to the vocab team.

Edit:
AOU judges us on missing concepts, so I do go to extra length to find something standard to place in the concept_id; again, I realize this is not the experience of normal OMOP’ing.

Snomed concept_relationship = 'Concept replaced by' not in Snomed concept_relationship = 'maps to'
#7

My particular case is in the UCUM unit ‘mL/min/1.73 m2’ (concept_id: 9117) which is no longer standard. There is a ‘Concept Replaced By’ record (720870) in the Concept table, but no ‘Maps to’.

My thought was that by adding ‘Concept replaced by’ to the concept mapping code, it would have produced the correct concept_id, but I don’t know if there could be both a ‘Maps to’ and a ‘Concept replaced by’ record causing a possible duplication.

I only use this standard mapping code for the main concept of a table (i.e. measurement_concept_id), and not for the other concept_ids in a table (like the unit_concept_id). But I was wondering whether I should.

And so the question stands: will that cause any problems?

#9

That’s ok. And in fact the Maps to should have been added automatically. Needs debugging.

#10

While upgrading to use the latest version of the vocabulary table I am trying to rescue deprecated concept and update the concept map to use the newly assigned standard concept.
I see that there are three options in the relationship_id in my use case:

  1. Concept replaced by
  2. Concept same_as to
  3. Concept poss_eq to
    Given these options in the relationship_id column, is there a “guidance” as to how we should use the relationship_id to re-map the deprecated concept to the newly assigned standard concept? There is not "Inactive possibly_equivalent_to active (SNOMED)” relationship_id that I was hoping to find. In N3C we have 80+ sites and 32+ OMOP sites using various version of OMOP vocabulary and we are working to re-harmonize the vocabulary terms to use one version of the OMOP vocabulary tables and re-map deprecated terms and if possible find the the standard concept if it has been replaced.
#11

It should be Maps to, @stephanieshong.

#12

I know, but if the “Maps to” no longer exist how to find the standard concept?

#13

Overtime, with new vocabulary updates, often the concept can become deprecated and standard concept can become non-standard concept. Furthermore, for some concepts the “Maps to” relationship is no longer found in the concept_relationship table.

#14

Site are submitting non-standard concept that no longer has the “Maps to” relationship to locate the standard concept. Sites are using older version of the vocabulary table at the time of their
ETL.

#15

Site are submitting non-standard concept that no longer has the “Maps to” relationship to locate the standard concept.
Are you mapping from the original source codes OR from the mapped to concepts that were valid at the time of the ETL?

Suggest mapping from the original source codes using the latest vocabulary release and the “Maps to” relationship. This should give you a new set of ‘standard concepts’ without a problem. The “Maps to” relationship is suppose to continue to map source concepts that are now obsolete and to handle when a source concept was replaced by another concept. So all you need to do is use the “Maps to” relationship.

If you see some source codes where this fails, please provide some examples including the source vocabulary and source code.

#16

Hi, @stephanieshong

Could you please provide an example?

#17

I would not use anything except for following explicit ‘Maps to’ relations for the purpose of automated handling of the deprecated concepts.

SNOMED CT has their own internal complex process for handling concept deprecation. When SNOMED authors decide to deprecate a concept, they do most often have to pick one or more replacements, depending on the original reason for concept deprecation.

In our more recent vocabulary releases, only a subset of these replacement relationships are now considered when building ‘Maps to’ relationships. Whenever SNOMED uses links that do not confirm semantic equivalency of the source to the replacement (through using ‘possibly equivalent to’ instead of ‘replaced by’ or ‘same as’), or if multiple replacement options are offered, ‘Maps to’ relationship can not be built.

Because of this, a ‘Maps to’ relationship will not always be present even when source offers replacements of a sort. Of course, the context may be different, but in general I would assume that if a concept was not good enough for SNOMED to be inactivated without an unambiguous replacement, it is likely not a good mapping target for us now. Quite possibly, SNOMED did not have anything better at that time the mapping was made, but now well may have.

In addition, SNOMED’s internally produced replacement relationships are not harmonized between different SNOMED editions. Only ‘Maps to’ are important enough to keep clean. There is no guarantee that there are, for example, no circular replacements, ambiguous leads or dead chain ends for old local UK and US concepts.

As such, concepts that used to map to now deprecated targets without a new ‘Maps to’ must be manually remapped on a case by case basis – any rigid systematic logic rule for making a decision will never guarantee a semantic equivalence for the replacement.

t