I was introduced to OHDSI, ATLAS and the slew of tools just a couple months ago. So, pardon the newbie question - why does ATLAS an open-source tool require MedDRA, a paid vocabulary? I understand that MedDRA is kind of a superset for SNOMED but why is it mandatory? Can you not make it optional?
Thanks in advance
PD
P.S. I work for a profit organization. am therefore assuming that I have to pay to get a MedDRA license
Hi @PDNeurance - actually MedDRA should not be mandatory for ATLAS operation. Where do you see that as a mandatory prerequisite? People processing pharma data very often have MedDRA data in their sources and then would like to have it as a source vocabulary for their ETL process, hence they will have to license it.
MedDRA is not a superset of SNOMED at all. It provides a lot of classification codes that translate to (map into) SNOMED, but that is actually the secret sauce in the OHDSI vocabularies: the relationships provided.
Thanks Michael. And, thanks for clarifying MedDRA for me.
Maybe I’m missing something about MedDRA being mandatory. So, here are more details:
'am using the following version numbers to load my patient data into Atlas
OS: Windows
jdk: 1.8
WebAPI: 2.8
Atlas: 2.8.2
CDM v5.4
I followed the instructions to set up WebAPI and Atlas, inserted my data, and ran Achilles. I can see only Person and Observation Period tables, charts and treemaps in Atlas. I cannot see conditions, drugs, measurement and observation related information in Atlas. I dug around and found the following:
My concept_hierarchy table is empty/blank. So, I looked at the ddl that WebAPI generated, and I found SQL queries with inner join that use MedDRA
INSERT INTO results.concept_hierarchy
.........
LEFT JOIN (
SELECT
c1.concept_id AS snomed_concept_id,
max(c2.concept_id) AS pt_concept_id
FROM public.concept c1
INNER JOIN public.concept_ancestor ca1 ON c1.concept_id = ca1.descendant_concept_id
AND c1.domain_id = 'Condition'
AND ca1.min_levels_of_separation = 1
INNER JOIN public.concept c2 ON ca1.ancestor_concept_id = c2.concept_id
AND c2.vocabulary_id = '**MedDRA**'
GROUP BY c1.concept_id
) snomed_to_pt ON snomed.concept_id = snomed_to_pt.snomed_concept_id
'am still picking up PostgreSQL. So, I assumed that for the above Insert command to work, MedDRA was mandatory.
Hi @Frank - @PDNeurance seems to have trouble getting his Achilles running here. I am a bit at a loss why MedDRA would be required to get the concept_hierarchy table filled (or otherwise it stays empty…).
Also, Prashanth, I think it would be helpful to learn about the vocabularies you downloaded and have in your OMOP CDM (can be found in your vocabulary table).
I can shed some light on the user of MedDRA here and historical context:
In the ACHILLES application, we display a visualization of proportion of conditions (and other domains) that was made into a 4 level hierarchy. It started with DRUG, and the 4 levels were ATC1, ATC3 ATC5 then Ingredient. We didn’t have the same sort of hierarchy level in the vocabulary for conditions, so we had to ‘figure something out’ for building a condition hierarchy, and you see it being built in concept_hierarchy. I think 1) it’s out of date and 2) we could ask the vocabulary team for a mechanism to make a 4-level hierarchy for conditions.
To answer your question about MedDRA, if you don’t have MedDRA concepts, it will just mean the concepts that are presented in the Condition domain under ‘DataSources’ in atlas (which is ACHILLES) will present a hierarchy of ‘NA-NA-NA-NA’ for the grouping. Nothing will ‘break’ but the visualization will seem ‘flat’.
A few updates: I commented out lines that used MedDRA in ddl scripts for generating results table, and Achilles generated all the results. I’m now able to view all my reports in Atlas. But like @Chris_Knoll said, I see NAs in the conditions and drugs treemap, and a few of the measurements and observations treemaps. It is fine for now, but I would like something more than a band-aid fix.
I could be wrong here but without MedDRA and ATC vocabularies Achilles was not generating treemaps (like condition treemap ) because it uses concept_hierarchy_id. I was seeing only patient reports before because Achilles does not use concept_hierarchy_id for patient report generatoin. I have something working now by commenting out the MedDRA inner join lines when generating results tables, but it would be nice to not rely on my hacks. Is paying for MedDRA the solution?
Paying for the MedDRA vocabulary would allow you to join to the concept tables that require those concepts, but I’m unclear why you needed to remove the join when if it can’t find a match to join on, the row isn’t returned, and (I thought) the default behavior is to return NA on those unknown levels. Are you saying that if you leave the join in, and the query can’t match on the MedDRA records (because they are not there) your reports don’t appear? If so, I think we should think about fixing that such that if the hierarchy can’t be found for a concept, it defaults to NA.
Thanks for getting back @Chris_Knoll. And yes, 'am saying that if I do not comment the join then my reports do not appear. The only change I made was to comment the MEDRA join lines and my reports appeared.
I have not paid for MEDRA vocabulary yet and 'am in the process of installing ATLAS on another server. I can confirm this behavior in a couple of days.
@mik you are right on both counts - i do not have ATC and neither do i have MedDRA. and the inner join queries look for both ATC and MedDRA.
@Chris_Knoll - i can confirm that at least for my datasets i have to comment out join queries containing ATC and MedDRA to see condition_occurrence, procedure, measurement and observation treemaps.