OHDSI Home | Forums | Wiki | Github

Fact_relationship usage



@Chris_Knoll, @Ajit_Londhe

Hello guys,

Can you please help me in determining the data points for fact_relationship entity ? I am having no clue on what this entity should contain.

Also, if it will be used in Atlas/Achilles analysis.


(Ajit Londhe) #2

@avalimbe, the wiki provides a good overview of this table:

It is not mandatory to insert any rows into this table, it just depends on if you want to capture relationships between stuff in the data. For instance, one common usage of the table is to capture mother-child linkages, if your data has pregnancy episode information and family identifier information.

Fact_relationship is not used in Atlas or Achilles at this time. It is a table that you can query directly to potentially augment the standard queries from the tools.

(Christian Reich) #3

We should add the mother child thing to the backlog, don’t you think? So you can create cohorts based on exposure to mothers, but the outcomes is in children.

(Ambuj) #4

so shall we assume that it works like a metadata or a bridge table where we can store the information about the entities that we need to refer somewhere in future?
As it is independent of any of the OMOP entities and stores only parent child data so can it be considered as obsolete?
@avalimbe and myself are in doubt on how to utilize this piece of model in our cdm.

Thank You.

(qiongwang) #5

Could I ask few questions?
1.Does OMOP CDM have a connected information of baby’s with mother’s, which mean you can match the mother’s patient_ID to a baby’s patiend_ID?

2.Do all babies have different Patient_ID? I know in some case, if the baby doesn’t registerd as an inpatient(health baby, but we need counted them in), they won’t give the baby an unique ID in the system. Just give them a “number”. And if it’s the second child of the mother, they may just use the same ID which her first child used. Have anyone worked with this case?

(Christian Reich) #6

It is a table to link records to each other with some semantic connection (you can call it bridge) that don’t have a direct foreign key connection in the current tables. In general, we prefer the latter and link tables directly (like the person_id field in almost every table). For those that are odd or rare we have the FACT_RELATIONSHIP table as a stopgap. So, instead of having a field for parent_1 and parent_2 in the PERSON table we use FACT_RELATIONSHIP. Another use case is to link MEASUREMENT records for bacterial drug cultures and the antibiotic resistance of the germs testing positive.

Bottom line: This table is not used very often, and ATLAS ignores it completely.

(Christian Reich) #7

That’s what people use FACT_RELATIONSHIP for.

In the OMOP CDM each person has to have a unique record in the PERSON table. If the source data have different solutions the ETL needs to figure that out.

(Will Roddy) #8

Sorry to revive this old topic but I’m curious if this topic went any further or if there’s additional updates? I’m working on a project where the cohort is based on premature neonates but we’re also interested in antenatal care and maternal health history. I know I’ll need the fact_relationship table to get these associations but it’d be great if I could include it in the cohort definition directly.

Thanks in advance!