OHDSI Home | Forums | Wiki | Github

Make relationships vocabulary non-specific

CDM Builders
#1

Dear OHDSI!

During our work on implementation LOINC Parts into CDM, we found concepts with identical meanings in different vocabularies. Nowadays common practice suggests creating vocabulary-specific relationships for each vocab. It produces a lot of excessive relationships that can be grouped by their meaning.

Some examples of intersection between LOINC and SNOMED:

Relationship_id
Relationship_id1664×304 298 KB

Some more examples from other vocabularies:
Relationship_id_2

An attempt to make sense of this diversity can be confusing to users so we propose to make relationships vocabulary non-specific and summarize them group by meaning.

@Christian_Reich, @Dymshyts, @aostropolets, @Polina_Talapova, @Alexdavv

2 Likes
#2

Many relationship are common sense so no wonder that we end up with similar ones coming from different sources.

This problem is related to a different issue - documenting where this relationship was “stolen from” (imported from) (comes from).
Is this relationship a one time import or an SDO (=standard dev. org.) is committed to keeping it current.

If a one time import and becomes outdated, we may have to retire those relationships.

So we can make changes to them but before providing opinion, I need to know what is our strategy on keeping track of where relationships come from. (because has dose form (rxnorm) and has dose form (ndfrt) - the suffix was serving as this “origin tracking” (my guess).

#3

+1 @Vojtech_Huser

#4

This has come up before. The extreme case is to drop all relationships and their microcoded attributes about provenance, which vocabularies are connected, what concept classes are connected, etc. So, something like “Has dose form” indicates that we link to Dose Forms, which is evident from the Concept Class of concept_id_2.

Another problem is that we steal a lot of them, but we also keep tweaking the stolen relationships.

So, the extreme and tidy list of relationship is:

  • “Horizontal non-hierarchical” - connects concepts without creating categorizations or contributing to the hierarhcy. An example would be “Has dose form”. “Maps to” would fall in this, but we still should consider keeping it separate. Same is true for “Concept replaced by”.
  • “Horizontal hierarchical” - connects concepts without creating categorizations, but participating in the hierarchy construction. An example would be “ATC - RxNorm” connecting ingredients.
  • "Vertical non-hierarchical - connects concepts by placing concept into a category, but without this being hierarchical. Drug to indication should be such a relationship, even though we currently have it as hierarchical.
  • “Vertical hierarchical” - this is a synonym for “Isa”, which already is used in a standardized fashion across all vocabularies.

There was also the idea of having “Vertical” be only within a vocabulary, and horizontal and another categorical “Diagonal” between, but the value is not clear to me - I can see if a relationships connects between different vocabularies without that.

If we wanted to do this, things would become a lot easier. Also for ATLAS etc. However, it would be a big abdominal surgery, and tons of existing query code would have to change, including PALLAS (vocab construction engine). If we wanted to do that we’d probably want to wait till ATLAS is out of rehab, so we could actually quickly release a version that can utilize these relationships.

1 Like
Classifying surgical complications
Improve LOINC representation in OMOP Vocabulary (Athena) (link parts to lab tests)
#5

@Christian_Reich, unfortunately, the issue is a blocker of the upcoming LOINC release.

Can we change at least the following relationships:

‘Has method (SNOMED)’ => ‘Has method’
‘Has property type (SNOMED)’ => 'Has property type ’
‘Has time aspect (SNOMED)’ => ‘Has time aspect’
‘Has component (SNOMED)’ => ‘Has component’
‘Has scale type (SNOMED)’ => ‘Has scale type’

?

By the way, in the Athena, there is quite useful data representation which indicates the provenance of a target concept (e.g., http://athena.ohdsi.org/search-terms/terms/4046130)

1 Like
#6

@Christian_Reich
I suggest you want to understand the logical meaning of

by the concept classes of concept_id_1 and concept_id_2. It will not work, see an example below.

Here is a list of possible horizontal relationships between SNOMED ‘Clinical Finding’ concepts

Asso finding of
Asso with finding
Due to of
Finding asso with
Followed by
Follows
Has asso finding
Has due to
Has interprets
Has manifestation
Has temp finding
Interprets of
Manifestation of
Occurs after
Occurs before
Temp related to

#7

I know. These horizontal and vertical ones are hierarchical ones. Not the medical ones.

#8

Go for it.

But sooner or later we need to figure out a general solution how we capture attributes of relationships:

  • Provenance - who made it
  • Medical purpose - what does it mean
  • Strength - probably or certain
  • Hierarchical - we have that already
  • Categorical - hierarchical, but not in a Isa sense
  • Cross-Domain
  • Cross-Vocabulary
  • Cross-Concept Class
1 Like
t