New fact_relationship relationship_id

CDM Builders
1

We have the cases where relationship_id we needed don’t exist

Cancer diagnosis to cancer stage
Smoking status to disorder observed
Antibiotic [Susceptibility] to Organism detection
etc.

  1. should we create all possible domain combination relationships
    Condition to Observation
    Condition to Measurement, Condition to Drug, etc.?
    as 581410 Observation to Measurement is created.
    Actually it doesn’t make a lot of sense as we have domain_concept_id_1 and domain_concept_id_2 in fact_relationship already
    Or
  2. should we create the relationship for each use case?
    like:
    “Cancer diagnosis to cancer stage”
    “Susceptibility to Organism”
    or
  3. allow populate the concept_relationship with “0”
    ?

I like the 2nd option as it actually represents the logic behind the connection. But in this case we need to develop the way these new relationships will be added to the OHDSI vocabulary.

2

@Dymshyts:

Good question. I’d say 2). 1) - that’s pretty useless for the reason you state, and 3) - would leave it to the imagination of the tool or analyst. What is this 581410? Why did we put that in?

3

I like idea #2 better because we would achieve finer granularity. Here’s a use case I posted to the forums last year.

4

@Christian_Reich
That was asked in some of the projects to be added. So I don’t remember the use-case. but yes, those time we used the case 1 logic. Seems that nobody complains about these
581410 Observation to Measurement
581411 Measurement to Observation
so we’ll leave it there.

@MPhilofsky @nzvyagina @aostropolets
can you please share the cases where do we need new relationship_id according the #2 idea.
waht facts should be connected?

5

@Dymshyts and @Christian_Reich,

We will always have concept_id = 0, unmappable, because not every representation of a thing will be added to the OMOP vocabulary.

  1. Smoking status to other smoking status concepts. The data contain
    type of tobacco, dosage, length of usage

  2. Cancer condition to cancer stage. The data have the type of cancer
    and the associated stage data

  3. Cancer condition to smoking status. The data has has row level data
    for cancer condition and smoking status

6

@MPhilofsky:

  1. We will solve this through a hierarchical terminology. In other words, you will have “cigarettes” combined with “heavy” combined with “length”. Soon.

  2. We are working on special cancer eras or episodes

  3. Not sure what you mean? What relationship is that?

7

We have the following use case… We have a table containing information about lab tests on organism presence in specimen and their susceptibility to antibiotics. So one source record contains information about lab test, detected organism, its growth and antibiotics susceptibility all together. We want to keep the link of these facts in OMOP.
As a result we have 3 OMOP records to be connected in fact_relationship:

  1. Lab test and result (organism found) - Measurement
  2. Organism and result (its growth) - Observation
  3. Antibiotic and result (susceptibility level) - Measurement

In our case I would prefer option #2 because it gives much more sense to the relation we want to keep and thus makes it easier to use fact_relationship.

8

We have one more use case. We need to link records:

  1. Allergic reaction - Condition
  2. Adverse reaction to substance and result (substance) - Observation
9

Curious where this is at now, @Christian_Reich

If it is still a ways off, would it be possible to get a standard relationship_id to link two facts in the Fact Relationship table? We would like to link all tobacco facts for a Person. In EHR source data, we have cigarette, chew, snuff, etc. use along with attributes for exposure to cigarette smoke past smoker, current smoker, heavy smoker, passive smoker, never smoker, etc. We would like to link all these positive assertions of tobacco exposure or use together for one Person.

@Dymshyts @Alexdavv An Observation table to Observation table link would be perfect :slight_smile:

10

It’s still here. :smiley:

I’m curios why everyone tries to link the medical facts using the relationship_ids developed for the vocabularies to link the concepts between themselves.

Even specification doesn’t ask to do it.

A couple of examples from there:

  • Person relationships (parent-child);
  • care site relationships (hierarchical organizational structure of facilities within a health system;
  • indication relationship (between drug exposures and associated conditions);
  • usage relationships (of devices during the course of an associated procedure);
  • facts derived from one another (measurements derived from an associated specimen).

We’re not gonna use ‘Is a’, ‘Subsumes’ and ‘Maps to’ for individuals, right?

So my suggestion would be:
You have the domain_concept_id_1 and domain_concept_id_2 so it’s already from ‘Observation’ to ‘Observation’.
For the rest of the meaning try to find the closest concept within any vocabulary/domain.

I know that we have some, i.e. Diastolic to systolic blood pressure measurement, Child to Parent Measurement.
But please, let’s stop mixing the things. If we need to provide the relationships for the fact_relationship table here, let’s make it a separate vocabulary and at least support the usecases from the specs.

1 Like
11

For those of us who have kids, I can totally see a parent-child relationship being handled by the ‘Subsumes’ relationship.

drumkick Thank you, thank you, I’ll be here all week.

-Chris

3 Likes
12

I know this is cursing in the church (as we say in Dutch), but v6 supports this with ‘observation events’

image
image1578×464 72 KB

Would it not work for you to use the existing concept hierarchy for this? As in make a concept set, with parent concept ‘tobacco user’ and include all its descendants?

13

I’m using these concept_ids where vocabulary_id = ‘Relationship’ and standard_concept = ‘S’. This is how I link facts between or within domains. Is this not correct?

It doesn’t ‘ask’, but it is very broad definition in the conventions “The FACT_RELATIONSHIP table contains records about the relationships between facts stored as records in any table of the CDM.” We’re trying to link chain smoker/pipe smoker/snuff user/chew user/passive exposure/ex-smoker/packs per day/tobacco use in years/etc.

Not there, yet…

No, our data contains more children than are present in the existing concept hierarchy. Hence, the ask for a new relationship to link the facts in the ugly Fact Relationship table since the tobacco hierarchy is still in progress.

I like it :slight_smile:

14

Seems to be correct, but I’m saying that this way of sorting out the relationships between the concepts and events is not a friendly one. Also it doesn’t provide enough use cases (even examples from the specs), so I’d look into the whole vocab (what is not conflicting with any convention). And finally, why would we need ‘Domain to Domain’ since it’s already in the domain_concept_id_1/2 fields?

15

Overdue to be released.

Need to fix it. Can you put on the list to discuss, @Alexdavv?

!!! :slight_smile: Question is, who “subsumes” whom.

2 Likes
16

Good question! I don’t know. I guess because I prefer to have a standard concept_id in a required field instead of 0! Honestly, I’d prefer the hierarchy to be built out. Harmonized terminologies and hierarchies in the Concept Ancestor table are HUGE benefits of the OMOP CDM. I’ll use 0 for the time being with hopes

will be sooner rather than later! Thanks :slight_smile: