OHDSI Home | Forums | Wiki | Github

Relation between MedDRA and SNOMED

vocabularies

(Denys Kaduk) #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?


Mapping ATC and MedDRA to OMOP vocabularies
MedRa to SNOMED
(Christian Reich) #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?


(Alexander Davydov) #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?


(Dmytry Dymshyts) #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?


(Christian Reich) #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?


(Dmytry Dymshyts) #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.


(Christian Reich) #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.


(Alexander Davydov) #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.


(Christian Reich) #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.


(Vikas Sinha) #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.


(Alexander Davydov) #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.


(Christian Reich) #12

We could. Like we did with ATC.


t