Drop table SOURCE_TO_CONCEPT_MAP
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start by locating the SOURCE_TO_CONCEPT_MAP definition and every reference to it in the Common Data Model DDLs and related workflows. Read how CONCEPT, standard_concept, and CONCEPT_RELATIONSHIP represent source codes, then determine the changes needed for consumers to use those structures instead. Done means the redundant table and its dependencies are removed without breaking the model or its supported workflows.
Written by the indexing model from the issue text.
Description
This table is a remnant of OMOP CDM Version 3, when we didn't have the notion of source concepts. All sources were codes. That created havoc, because many vocabularies had both source only and standard content. Of course, some standard content is also used in the source. In addition, names from the source codes were not available anywhere. Finally, searching for source codes could only be done in the STCM table, which meant, we had to add a ton of records without any mapping. So, it was a mess.
The solution was to have all codes as concepts, and indicate their nature in the standard_concept field. That system, together with the "Maps to" CONCEPT_RELATIONSHIP records are the comprehensive solution to the problem. STCM is now completely redundant and only left in there for convenience, so not everybody had to change their mechanism to manage their mappings.
That was what? 7 years ago? It's time to move on. Codes in STCM are essentially hidden from any activity except ETLing, which could easily pivot to CONCEPT_RELATIONSHIP. ATLAS doesn't use it, and no other analytic for whatever use case uses it.
- Dominant language
- HTML
- Stars
- 1.1k
- Forks
- 513
- Avg merge
- 8d 3h
- Merged PRs (30d)
- 4
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from OHDSI/CommonDataModel
-
Difficulty 1/5 Under an hour Newbie friendliness 74/100
OHDSI/CommonDataModel#802 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
OHDSI/CommonDataModel#799 ·
-
fix: mark cohort_definition_id as primary key in cohort_definition table for v5.3 and v5.4Possibly taken @rtmalikian claimed this 136 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
OHDSI/CommonDataModel#787 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
OHDSI/CommonDataModel#784 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
OHDSI/CommonDataModel#823 ·
All issues in OHDSI/CommonDataModel
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
scylladb/kafka-connect-scylladb#297 ·
Maintainers usually reply within 2 days
-
--dry-run runs the real operation in ruvector migrate, ruvector backup restore and deployment deployPossibly taken @tanishqbaweja claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
GoogleCloudPlatform/spanner-migration-tool#1479 ·
Maintainers usually reply within 8 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
mferretti/SeedStream#443 ·
Maintainers usually reply within 4 days