OHDSI Home | Forums | Wiki | Github

Data and use of source_to_concept_map table

Implementers
, , , ,
#1

Hello Everyone,

May I know why don’t we have any data for source_to_concept_map table in vocab files?

Currently our source_to_concept_map table is empty. Is it usually empty?

Is it only used to upload our custom concepts or we expected to see some source_to_concept mappings for OMOP concepts?

Am not sure I deleted the data by mistake. Where can I find the data for source_to_concept_map table if at all it exists else am I right to understand that it is only for our custom concepts?

Can someone shed some light on this?

#2

Hello @Akshay,

source_to_concept_map is for custom mappings only. It doesn’t have any data by default, you can add your own source codes there and map them to standard concepts.

1 Like
Methodology for Converting Source-To-Concept-Map to Concept/Concept_Relationship (2 billionaires)
#3

@Akshay:

To extend what @rookie_crewkie is saying:

The SOURCE_TO_CONCEPT_MAP is a remnant from Version 4 of the CDM. Mapping in V5 or greater is done through “Maps to” relationships between the source Concepts and the Standard Concepts. Before that, there were no “source concepts”, only codes.

The reason we still have it is the ease with which mapping of local codes can be managed. You don’t have to create Concepts for every silly little source codes. Often times, these source codes aren’t even codes but short strings.

Bottom line: Use the table only for your own internal mapping purposes. Only the stuff not relevant to the network or analytics. In my opinion, there is no need to have this standardized anymore, and it can be made obsolete entirely in future versions.

1 Like
#4

@Christian_Reich , I came upon this table while exploring the database as well… and wondered whether it could be repurposed to allow for the one to many source to standard concept map? Is there anyway this could be used to link together multiple standard codes within the condition_occurrence table for a given source row?

#5

Hi Andy.

Can you explain what purpose you are pursuing? Do you want to do a post-coordination?

#6

Yes, this could be the way to link the primary SNOMED map to the attribute SNOMED maps… For example ER+ Malignant neoplasm of the breast…

#7

Two answers:

  1. Oncology: We fixed that. Come to the Oncology WG. Post-coordination is solved through Cancer Modifiers in the Measurement table, including estrogen receptor and other biomarker status.
  2. Non-oncology: For typical post-coordinations of conditions we have the solution of the OMOP Extension concepts, which would then be put into the existing hierarchy. So, viral hepatitis with hepatic coma would then result in an equivalent concept, which would be a descendant of each of the components. @Eduard_Korchmar has a tool how to automate that locally.

I am not friend of the things like FACT_RELATIONSHIP. except for special cases. Reason: it’s not standard, so nobody will know it is even there and look for it, and it is very slow.

#8

Well, I am trying to get away from creating new standard concepts for each precoordinated source concept. I thought that an alternative would be a table which stores the post coordination concepts but links them together via a foreign key to a source concept, which then can be used as a shortcut to identifying the individual post coordinated concepts and holding them together… I have been following Oncology WG but I think there is a need to be able to not only have the individual modifiers in the measurement table.

#9

How is that different from OMOP extension? the table is CONCEPT, the foreign key is organized through CONCEPT_RELATIONSHP and the individual concepts are also in CONCEPT. It works. Only difference to your proposal: They are not local, but global. They could be local though (concepts with concept_id>2B, local CONCEPT_RELATIONSHIPs).

Do explain. What is missing or not working?

#10

There is now a tool we developed that allows to use existing OMOP ecosystem and tools with SNOMED-style post-coordinated expressions. If your data is Condition concepts, it may be well fit for you.

t