OHDSI Home | Forums | Wiki | Github

SNOMED Edition and Version Questions

Vocabulary Users
#1

Hi,

In regards to the SNOMED - Systematic Nomenclature of Medicine - Clinical Terms (IHTSDO) updated April 1, 2020 vocabulary contained within Athena

Couple of questions - which edition and version of SNOMED is in this vocabulary? Or is it some custom edition?

If using HL7 FHIR, it recommends returning the SCTID of the edition being used (as per: https://www.hl7.org/fhir/snomedct.html#4.3.1.0.3)

The particular edition being used has a given sctid as per: https://confluence.ihtsdotools.org/display/DOCEXTPG/4.4.2+Edition+URI+Examples

In addition, there doesn’t seem to be a SNOMED release that corresponds to April 1, 2020 - at least not for either of International or US Editions. Does this date of April 1, 2020 correspond to the date Athena/OHDSI updated and not a SNOMED release date? And would that means it would correspond to the March 1, 2020 release of US Edition of SNOMED?

Any help would be appreciated.

#2

Hello!
SNOMED in OMOP is formed from 3 different editions: UK, US and International.

April, 1st is the date SNOMED was last updated in OMOP. It includes latest SNOMED Editions that were available to date.

So for US and international, actual version is March 2020, including urgent interim changes for COVID19. Similar urgent changes to SNOMED UK released 14 April and are also included (our actual release was end of April).

Starting from next OMOP release, all contributing SNOMED editions will be listed alongside with their source-given versions in version field instead.

2 Likes
#3

@Eduard_Korchmar Thank you for the quick reply.

Based on what you said, in current OMOP state it’s not possible for us to know if for a given SNOMED concept whether it’s from the International, US or UK SNOMED edition; we only know it’s SNOMED. That’s certainly complicates things to try and meet HL7 FHIR API requirements/specifications where the sctid of the edition must be provided.

We are using OMOP for its excellent concept relationship mappings in the concept_relationship table. We find the mappings to be very high quality and clean so kudos to the team on that. One use case is to map from ICD10-CM codes/concepts to SNOMED concepts. Just to confirm - would an ICD10-CM (US) code/concept potentially map to say a SNOMED (UK) concept? Or was there some effort to map ICD10-CM (US) specifically to SNOMED (US) codes?

In regards to your last sentence. That would be great addition to specify all contributing SNOMED editions and their versions. But does that mean each edition would become its own vocabulary or would there still be one combined vocabulary of all three editions?

Thanks again.

#4

Anyone else on the vocabulary team that might have some insights to my follow up questions?

#5

Sorry for the late response!

No, there was no such efforts. However, from our experience, local editions of SNOMED are formed to include concepts that are originating from locally used classifications, so ICD10CM concepts are still more likely to be mapped to US part of SNOMED.

SNOMED will still be kept as a single vocabulary, we have no plans to change that. However, we are considering including additional metadata about concepts (such as module it originates from) in CONCEPT_RELATIONSHIP table. Would that help your use-case?

#6

Hi @Eduard_Korchmar,

Thanks for the reply and clarification.

I am not sure if the extra module information will help my use case specifically. Ultimately, our case would require us to be able to determine which edition a given SNOMED code is from - International vs US vs UK. As we will be returning data via HL7 FHIR APIs it is a requirement to specify which code system and version a given concept is from. I provided an example below of a patient with a condition of Stroke from the SNOMED US Edition (sctid 731000124108) version September 2020. Would adding module to the concept relationships be able to tell us which edition the code/concept is from?

"code": {
     "coding": [
      {
           "system": "http://snomed.info/sct",
           "code": "422504002",
           "version" : "http://snomed.info/sct/731000124108/version/2020090",
           "display": "Ischemic stroke (disorder)"
     }
    ],
   "text": "Stroke"
  }
#7

Internally in RF2 format SNOMED originally is supplied from, each edition is a sum of contributing modules. No concept, description or relation exist outside of a module. All editions consist of big “core” module and several metadata modules, which are shared among all editions including international, and a limited number of edition-specific modules.

So if the concept belongs to core or other shared modules, it is encountered in all editions and can be treated as originating from international edition, otherwise it will have unambiguous country-specific module attached to it. There is a module dependency table which could be used to infer edition from moduleid computationally, but since number of modules is limited, I think it’s easier to just list them out.

As for exact edition version number, it cannot be directly inferred from CONCEPT_RELATIONSHIP, but when you know which edition the concept is from, you can take version field from VOCABULARY table — once separate list of versions is implemented, that is.

#8

Probably a good idea to talk to SNOMED, @Marco_Di_Cesare. From the OMOP Vocabulary perspective, it is sufficient to treat all SNOMED editions as a continuum. Concepts are stable, and the hierarchy and links go across the editions no problem. But I am sure somebody solved that problem for FHIR. Let me know if you need help to triangulate and find the right folks.

#9

You can do it for long codes if you isolate the module id out of the SNOMED code. But unfortunately, you can’t know from OMOP when the SNOMED concept was promoted from Extension to SNOMED International.

--Namespace Identifier (extension) in SNOMED
SELECT DISTINCT SUBSTR (c.concept_code, length(concept_code) - 9, 7),
            COUNT (*),
            array_agg(c.concept_code ORDER BY random()) ::varchar(1000) as examples
FROM devv5.concept c
WHERE c.vocabulary_id = 'SNOMED'
    AND length(c.concept_code) > 10
GROUP BY 1
ORDER BY 2 DESC

Links:
SNOMED CT Namespace Identifier Registry
Namespaces

#10

So if the concept belongs to core or other shared modules, it is encountered in all editions and can be treated as originating from international edition, otherwise it will have unambiguous country-specific module attached to it. There is a module dependency table which could be used to infer edition from moduleid computationally

@Eduard_Korchmar - I don’t believe the the SNOMED module id currently available for concepts in the OMAP data model, right?

As for exact edition version number, it cannot be directly inferred from CONCEPT_RELATIONSHIP, but when you know which edition the concept is from, you can take version field from VOCABULARY table — once separate list of versions is implemented, that is.

Yes, that will be helpful. Looking forward to that addition.

#11

@Alexdavv Hi Alexander,

Thanks for the suggestion. Seems though from the link you sent that the Namespace Identifier Registry shouldn’t be used to

Caution The namespace identifier used in an extension’s SCTIDs should NOT be used as the mechanism to determine which edition or extension a component belongs to. Instead, the moduleId attribute is used for this purpose.

https://confluence.ihtsdotools.org/display/DOCEXTPG/4.1+Namespaces

#12

@Christian_Reich - yes, if there is someone who has solved this we’d love to hear about it. Let me know if you have any folks we can talk to

#13

Right. You can only know the origin of the concept, not the actual residence.

Unfortunately, it’s not a usecase for OMOP, but potentially there’s an option of implementing this in OMOP through the links from term concept to metadata concept:
https://athena.ohdsi.org/search-terms/terms/1147638

#14

Thanks for the reply. I understand this is not a use case for OMOP - I just wanted to make sure I wasn’t overlooking something but it appears not.

I would like to hear a little more about what @Eduard_Korchmar said above regarding using module id. But again, I don’t believe the SNOMED module id is currently in the OMAP model as far as I can tell.

#15

Correct, we are considering including metadata for concepts following the next release. As I said before, if we know the moduleid of the concept, it is possible to know if it is a part of International SNOMED (and is therefore included in every single one SNOMED edition) or belongs to a specific national edition.

For instance, SNOMED concept for diabetes mellitus would have a link to SNOMED CT core module, which would identify it as part of SNOMED international, while concept for pre-diabetes would have a link to SNOMED CT United Kingdom clinical extension module, which would obviously identify it as a exclusive part of UK SNOMED.

Module id for all SNOMED concepts is preserved as a special field in SNOMED source files. Concepts may only belong to one module at a time and usually only change module when moved from local to international edition.

Here is how it looks in rf2_concept table for those two concepts:

image
image1336Ă—128 12.8 KB

And here is entry for CT guided insertion of fiducial marker into lung, which had retained code and namespace it “belongs” to, but changed module from UK clinical extension to SNOMED CT core in July 2020:

image
image1164Ă—128 12.1 KB

It means that this concept is now part of SNOMED international and every other SNOMED edition.

So if we do include moduleid and other metadata as attributes in CONCEPT_RELATIONSHIP table, I believe it would both help your usecase, as well as possibly assist our own team with automating mapping local terminologies to SNOMED. And if we ever to make OMOP SNOMED Extension, it would make it easier to keep it closer to SNOMED specs.

@Alexdavv @Dymshyts @Polina_Talapova
Would you agree to these changes?

1 Like
#16

Good! Now it sounds more doable than expected.

What about the representation of version? Considering we store the only version in concept and concept relationship, how would metadata/links can support this?

#17

Versions for each edition are all stored in VOCABULARY.VERSION field starting this release. When you know the SNOMED edition, you can extract the version from there.

#18

@Eduard_Korchmar - that proposal sounds like it would be really useful. And yes, with the module id info and the version info that would definitely help solve my particular use case of identifying which edition and what version a given SNOMED concept is is from. I will keep an eye out for future release of OMOP.

Thanks for contributing to this discussion and answering my questions!

t