OHDSI Home | Forums | Wiki | Github

Relation between MedDRA and SNOMED

Vocabulary Users
#1

Hi all, right now we have around 5k mappings from MedDRA to SNOMED, only for ‘LLT’ class and thinking about add it to OMOP vocabulary.

For example such relationships were built:

MedDRA_name MedDRA_code Relationship Snomed_name Snomed_code
Abdominal spasm 10051889 Maps to Abdominal colic 9991008
Incision site pain 10058043 Is a Postoperative pain 213299007
Streptococcal urinary tract infection 10070300 Is a Bacterial urinary infection 312124009
Streptococcal urinary tract infection 10070300 Is a Streptococcal infectious disease 85769006

We currently have MedDRA hierarchically above SNOMED (MedDRA Subsumes SNOMED), but if we add the mappings, MedDRA will be below SNOMED (MedDRA ‘Is a’ or ‘Equivalent’ SNOMED).

As example it will change relationship that we have now:

MedDRA_name MedDRA_code Relationship Snomed_name Snomed_code
Dysphasia 10013951 MedDRA - SNOMED eq(Subsumes) Dysphasia 20301004
Dysphasia 10013951 MedDRA - SNOMED eq(Subsumes) Dysphasia as late effect of cerebrovascular disease 441529001

will become :

MedDRA_name MedDRA_code Relationship Snomed_name Snomed_code
Dysphasia 10013951 Maps to Dysphasia 20301004

According to this ‘Classification’ MedDRA concept that has ‘Maps to’ become non-standard and MedDRA concept that has ‘Is a’ become standard, but as we haven’t mapping for all MedDRA concepts, those MedDRA concept will be mixed. I have proposal to implement this step by step:

  1. Map only ‘LLT’ concept_class, as they are lowest in hierarchy

  2. Leave all other MedDRA concept_class as ‘Classification’.

Will this affect the research that is being conducted? Will it be a good logic? @Christian_Reich, @Dymshyts, @Alexdavv , what do you think about it?

MedRa to SNOMED
Mapping ATC and MedDRA to OMOP vocabularies
#2

@Denys_Kaduk:

Right now MedDRA is a classification on top of SNOMED. Reason is the use case: MedDRA is not a vocabulary of data converted to OMOP CDM (source vocabulary), but one that is used to define cohorts. Reason is that MedDRA is used for recording adverse events in Clinical Trials, which currently are not typically converted to OMOP. Instead, the use case is to find equivalent patients to those in clinical trials, for which a classification is better suited.

Any reason we want to change that?

1 Like
#3

@Denys_Kaduk Thanks for bringing it up! I would prefer to incorporate these mappings right after finishing the whole set we’re working on, but the discussion started in advance is always the right choice.

MedDRA low-level terms (LLT) and less likely preferred terms (PT) are used in the Clinical Trial datasets (registration of adverse events, medical history, death reasons, etc.) which are converted to the OMOP CDM from time to time.
For now, just 9% of MedDRA LLTs have ‘MedDRA - SNOMED eq’ links, and mostly they are deprecated. PT level is covered better (39%). But I’m actually not sure if all the required SNOMED concepts are caught.

From my perspective it means:

  • We cannot efficiently use LLT or PT codes to build the equivalent cohort in the MedDRA-free dataset. We need to go up to High-level terms where MedDRA codes are hopefully linked better with SNOMED. Is it accurate enough for studies?
  • When having just MedDRA codes in the source, ETL becomes challengable.
  • LLT (always) and PT (mostly) don’t look like classification terms. Please look at them. They’re ordinary conditions/procedures/measurements may be mapped to Standard.

Not sure we really need to use ‘Is a’ links making them standard. For sure, we are losing something. But isn’t this a case for the SNOMED Extension?

So my vision is:

  1. Insert the available mappings of LLT codes, making them non-standard.
  2. Figure out how LLT/PT and their links to SNOMED are used in the studies. And fix something if affected.
  3. Think about the “MedDRA more specific then SNOMED codes” from the SNOMED Extension perspective.

@zhuk, @Alina_Vaziuro, @Vlad_Korsik, I am sure you are the best feeling this MedDRA. :slightly_smiling_face: Any ideas?

#4

In short, you want to say that nobody can really use MedDRA to define cohorts due to poor current state of its hierarchy, right?

#5

@Alexdavv:

Love your energetic approach to making the vocabulary system better, BUT:

This is by design. The LLTs were mapped opportunistically. Only PTs were mapped systematically. Thsi was decided for a number of reasons: (i) PTs are pretty much leaf concepts and therefore easy to map (as you correctly pointed out), (ii) LLT are supposed to be synonyms of PTs (which in reality is not true very often) and (iii) the higher concepts are sufficiently connected through the hierarchy. The latter would avoid hierarchy conflicts, like we have with ICD10 to SNOMED mappings, except a lot worse, since MedDRA is richer.

If you want to change that you need to do a couple things:

  • Analyze the size of the problem
  • Figure out a solution (you have some of that, essentially abolish MedDRA as a classification, but turn it into a source vocabulary, including SNOMED Extensions to bridge the gaps).
  • Propose that change with use cases (which you have in the mapping of clinical trial data) to the CDM WG (and you started doing that with your vision).

So, let’s say you turn MedDRA into a source, and map LLTs and PTs over. Those become non-standards. What are you going to do with the HLTs, HLGTs and SOCs? They cannot become Standard Concepts, since they would duplicate SNOMED concepts. They cannot stay Classification concepts because they are no longer connected to SNOMED. And they cannot become source concepts because they are not used in the source, and they have this tendency to create hierarchy clashes with SNOMED.

Any good idea?

#6

It can be the same approach as with LLT and PT - map them to SNOMED, If mapping doesn’t exist create SNOMED Extension.
So if somebody has concept set defined as descendants of given MedDRA concept, they go through Maps to then ancestor and get their concept set.

#7

And what are you going to do with the inevitable hierarchy disagreements? Usually, the source vocabularies are flat, and you place them into whatever best SNOMED concept you can find. We have a little bit of that problem with the ICD hierarchy. This is going to be a lot worse here.

#8

Well, probably right answer is:

  • make all MedDRA non-Standard;
  • detect the disagreements;
    a) when we have it: create new SNOMED Extension equivalents of MedDRA HLT/HLGT/SOC using ‘Maps to’ between them. And then build correct SNOMED-fashioned hierarchy under.
    b) if we have no disagreements: Simply use ‘Maps to’ between the rest of MedDRA HLT/HLGT/SOC and SNOMED.

Then ask people to switch their MedDRA-based concept sets to SNOMED/SNOMED Extension since it perfectly fits and all they need is just looking at ‘Maps to’.

Not sure how long it would take. So, I am not a fan of this idea and have another proposal:

  1. Turn MedDRA LLT/PT into non-Standard and link to SNOMED with ‘Maps to’. Create new SNOMED Extension equivalents of MedDRA where needed (not a hierarchy issue as mentioned above. Just if we need more granularity on the lowest levels).
  2. Leave MedDRA HLT/HLGT/SOC being Classification (as per design).
  3. Enrich the list (or replace current if needed) of SNOMED descendants for MedDRA HLT/HLGT/SOC. To do it properly, just use all the ‘Maps to’ links between MedDRA’s children (LLT/PT) and SNOMED.

With this, people will be able to convert all MedDRA source data to Standard, but still using their MedDRA-based concept sets and then actually compare the results switching the queries from source_concept_id to event_councept_id and back. Also, MedDRA will be a vocabulary of choice to detect adverse events by system/organs. It will be easily combined with SNOMED and its hierarchy in concept sets with the only limitation of not using LLT/PT levels.

#9

We could do that. Essentially, retire MedDRA as a classification and turn it into a source vocabulary.

However, the problem with the hierarchy mismatch is not solved: Let’s say somebody has a HLGT Concept. Folks will expect that the HLT, PT and LLT in the MedDRA hierarchy belong to it. However, it gets mapped over to SNOMED, and SNOMED will decide who the children are. So, some PT descendant will map to a different branch of SNOMED. That will cause stress for folks.

I don’t have a good idea.

#10

I do not see any posting on the topic of MedDRA and SNOMED mapping since the last one in this thread. Have we dropped this effort completely? If yes, from where is OMOP getting this mapping ? With the growing need to use RWD in new discoveries there is a need to have this mapping available. Please share alternative effort, projects working on this effort. I have come across the Web-RADR 2 initiative that has worked on this mapping but it is not extensive I am told.

#11

The mappings mentioned above had been done internally, but not published yet since there is no agreement on how to handle the MedDRA/SNOMED hierarchies. So it’s not dropped, just keep waiting for its time.

BTW, @Christian_Reich can’t we simply add ‘Maps to’ links from MedDRA to SNOMED, but keep the structure as it is, at least for now?

MedDRA by itself is working on the SNOMED-MedDRA mappings, look.

image
image1259×596 70.3 KB

How to map Meddra code into standardized concepts?
#12

We could. Like we did with ATC.

#13

Well, I think this forum post deserves an update, as we have finally released a MedDRA refresh including the changes we intended to do about the MedDRA mappings to SNOMED. With the help of the SNOMED-MedDRA collaboration and a substantial number of additional mappings donated by other contributors (among those, J&J stood out) we have hopefully created something very useful for those who have MedDRA codes in their source data. @Alexdavv , maybe you can go into more details and provide some background, too?

1 Like
#14

Yes, sure!

We added 13,672 “Maps to” / “Maps to value” relationships for the MedDRA codes most frequently found in the RWD.
So now doing the ETL, MedDRA concepts can be recognized as the source concepts (placed into the source_concept_id field) with the mapping to Standard vocabulary (with the respective Standard concept placed into the event_concept_id field).
Because of the MedDRA/SNOMED hierarchy discrepancies discussed here above, we don’t merge the hierarchies in any way. Users can use both MedDRA hierarchy and SMQs (querying the source_concept_id) as well as Standard OMOP hierarchy (querying the event_concept_id).

Thank you for your contribution and the very fruitful and interesting collaboration we were able to have: @Eva-M @Clinhar1 @Patricia

2 Likes
#15

@Alexdavv I’m curious as to whether any of the MedDRA to SNOMED relationships have made it into the CONCEPT_ANCESTRY table. Based on what I’ve read in The Book of OHDSI it sounds like MedDRA is the classification vocabulary used to facilitate hierarchical queries for conditions. As such, I was expecting to see MedDRA-to-SNOMED mappings in the CONCEPT_ANCESTOR table similar to the ATC-to-RxNorm mappings however I’m only seeing MedDRA-to-MedDRA mappings currently. There do appear to be MedDRA-to-SNOMED mappings in the CONCEPT_RELATIONSHIP table…would this be the source for hierarchical relationships between MedDRA and SNOMED?

#16

@mlbernauer MedDRA isn’t standard vocabulary for OHDSI. So as much as possible concepts will be mapped to standard vocabularies (most common SNOMED) with relationships “Maps to” / “Maps to value”. Currently we continue this work. You can use hierarchical relationships between concepts inside the MedDRA vocabulary or inside the SNOMED separately. But as @Alexdavv wrote above due to MedDRA/SNOMED hierarchy discrepancies we’ll not plan to merge the MedDRA and SNOMED hierarchies in any way.

#17

Hi @Alexdavv - I have been reading through some of your comments and had a question regarding medra/snomed mapping. Is there an available dataset of medra and snomed terms that are NOT mappable? Also, I was wondering if there was a way to connect via pm or email as I have additional questions. Thanks in advance!

#18

@Alexdavv, just wanted to follow up on this! Thank you!

#19

Hi @choim09,

There are some SNOMED and MedDRA terms that can’t be mapped 1-to-1 where we need to implement uphill mapping. But, this is not the actual issue that prevents us from creating a single hierarchy between MedDRA and SNOMED. The actual issue is that when you build the hierarchy the semantics of each term implies not only the actual terms but also a subset of all its descendants. If the rules on which the descendants are gathered are different, then you need to consider all the concepts down the hierarchy when you deal with each concept. What is not a trivial task.

We will ping you in PM.

t