OHDSI Home | Forums | Wiki | Github

Why don't relationship concepts belong to different vocabularies beyond 'Relationship'?

#1

All the vocabulary concepts belong to a vocabulary named ‘Relationship’? See SQL here:

select distinct c1.vocabulary_id
from relationship r join concept c1 on r.relationship_concept_id = c1.concept_id

Since relationships are assertions of how concepts relate to one another, should they not belong to some non-‘OMOP generated’ vocabulary in at least some cases? I get that a lot of them might be curated by the OMOP vocabulary team, but aren’t some of the “stolen” from the native vocabularies themselves?

Also, there are some mapping vocabularies that don’t introduce any new concepts themselves but simply state the relationships between two concepts in two other vocabularies. It would be nice to be able to import these kinds of relationships into OMOP and know the provenance of the relationship assertions.

For example, the Observational Research In Oncology Toolbox (OROT), makes assertions between NAACCR concepts and CPT/HCPCS/ICD9/10 procedure codes. It would be nice to be able to import these relationships into OMOP and assign ownership of the assertions to OROT. OROT also makes assertions between surgical CPT/HCPCS/ICD9/10 procedure codes and ICDO3 topographies that the surgeries are treatments for.

#2

@mgurley:

I like the idea to use the relationship_concept_id as a mechanism to identify provenance. Right now we don’t have that. All relationships are the same, whether we import them or create them de-novo. It’s burried in the Pallas vocabulary building system.

The relationship_concept_id you see there is just a concept placeholder for the relationship_id. For example “Maps to” corresponds to 44818977. Why do we need that? To support an information model that graph databases can use for navigation. All entities in the Standardized Vocabularies have an equivalent in the CONCEPT table. However, nobody has done anything with it yet, even though such semantic web / non-SQL / graph database / information model concepts are being brought up regularly.

#3

@Christian_Reich
So it does not sound like putting a relationshp_concept_id in different vocabualry_id besides ‘Relationship’ would break anything, correct?

#4

No, but that’s irrelevant. All relationships are of the vocabulary “Relationship”. You can’t put “ICD10CM” or anything in there. Plus, many relationships link concepts from different vocabularies.

Bottom line: If you want the relationships from OROT then all you need to provide is the source concept ID (concept_id_1), the target concept ID (concept_id_2) and the relationship_id (either “Maps to” or some equivalence relationships).

What do you have?

#5

OROT has no source concepts. It only has assertions of relationships between concepts in OTHER vocabularies. Like NAACCR and CPT or NAACCR and ICD9-PCS or CPT and ICDO3. This is why I am focusing on the concept pointed to in the relationship_concept_id being placed is some other vocabulary_id than ‘Relationship’. Namely, I would like to put it in OROT, so I know who is responsible for making the assertion.

#6

I understand that. But we don’t have a good mechanism for that. Only a hook. The fact that a relationship is coming from OROT can be put into the relationship_name. You can see how it works if you query the RELATIONSHIP table. We could introduce an “Is A (OROT)” and a “Subsumes (OROT)” relationship. But leave those concept_ids alone.

Would that work?

#7

Yes, I noticed the embedded names within existing relationship_names. I was hoping for something more computable without resorting to wild-card like ‘LIKE’ searches. But that would be an OK shim. Was trying to understand if doing something less hacky was possible within today’s model or if placing ‘Relationship’ domain concepts within other vocabularies than ‘Relationship’ would grind today’s gears.

t