OHDSI Home | Forums | Wiki | Github

FACT_RELATIONSHIP: proposal for new conventions

CDM Builders
#1

Hello Chris and All,

CDRN ETL workgroup has identified several use cases that can leverage FACT_RELATIONSHIP table.

  1. Explicitly link visits. Our use cases are Emergency Room or Outpatient visits resulting in Inpatient admissions.
    We propose to use the following relationship concepts: ‘Occurs before’ (44818881) or ‘Occurs after’ (44818783).
    Please note we considered and decided against combining any of these visits into one.

  2. Explicitly link Systolic and Diastolic BP measurements.
    We could not identify appropriate relationship concept, need a new one.

  3. Use FACT_RELATIONSHIP to link records from any domain to its attributes stored in the OBSERVATION table in case OBSERVATION table does not have a foreign key to the domain in question (e.g. PERSON_ID or VISIT_OCCURRENCE_ID). Our use case is connecting diagnosis and diagnosis source which is not the first class attribute in the model. We propose to store diagnosis source in the OBSERVATION table and connect the CONDITION_OCCURRENCE and OBSERVATION records via FACT_RELATIONSHIP.
    We can use relationship concept ‘Has property (SNOMED)’ (44818772) concept.

Thank you for your thoughts and consideration,
Rimma

1 Like
#2

Dear Colleagues,

I am reviving this issue because we, the OMOP-based CDRN networks, need these relationship concepts to support the CDRN use-cases and finalize OMOP-PCORnet CDM interoperability specifications.

I believe that the first two use cases, visit links (ER-inpatient) and systolic-diastolic blood pressure measurement links will find a much broader utilization than CDRN. Presently, there is no unambiguous way to link connected visits (transfers) or BP measurements.This poses a problem when aligning multiple BP measurements where date/time of measurements do not have a sufficient precision. Looking at length of stay and other metrics related to the efficiency of care may also become problematic when no explicit link between patient transfers (ER to Inpatient, Outpatient to Inpatient) exists.

The use-case #3 is a workaround for a missing first class attribute that is required by the PCORnet model: diagnosis source. We do believe that this is an important data element because it provides information about the stage in patient care when the diagnosis is made: admitting, preliminary, final. It may shed light not only on the patient progression during their encounter with the health care, but also on the precision/correctness of diagnostic process. We are requesting to add this attribute to the Condition_Occurrence table. In the meanwhile, we are proposing the workaround described in the original message.

Thank you for your consideration,
Rimma

#3

with regard to systolic and diastolic bp, could you use the term “with” (concept id 4069676) or “associated with” (concept id 4165382)? The former is somewhat generic and the latter is typically used in the context of “caused by” but they might work. There is also the term “simultaneous” that might work (concept id 4195896). Let us know what you are doing. My apologies if this is not helpful - I am just getting familiar with the vocabularies. (The reason I stumbled across this is that the term “with laterality” is something we need for SEER data and possibly for modifier codes for procedures in claims data.)

#4

Would that work, @rimma? If we used those generic link concepts?

We need something for referral or transfer between wards in a hospital. But do we? Can we not assume that if a visit ends on the same day that the next day starts and both are ER or hospital visits that the patient got transferred?

We should put this on the next version of the CDM 5.1. I am not sure the FACT_RELATIONSHIP table is what I would use here. The fact relationship table should link facts that are concrete for a patient situation, not generic to organize the CDM, like the domains.

#5

@rimma:

I think we should use either condition_type_concept_id, or we create another field called condition_workup_concept_id, with the possible fields admitting, preliminary and final.

#6

I think “with” would work best. As always, there are risks and benefits in using either generic or specialized relationships. In the first case, if there are other measurements connected via “with”, a query will need to constraint by relationship and concepts. In case of a specialized constraint, you only need the constraint to run your query. Therefore, it is an important design decision. But we can always start with a generic relationship and, if we see the need to specialize, we can do it later.

#7

Chris, I vote with both hands for creating another field.

#8

I am not aware of any other use cases. If we can add the desired attribute as a new field to CONDITION_OCCURRENCE, we may not need to use this solution again.

However, if we accepted the convention of using OBSERVATION table to store attributes from other domains as a temporary workaround, then we also need a solution for connecting these attributes with their “first class” domain record. In case of CONDITION_OCCURRENCE and other tables not directly linked to OBSERVATION, there should be some intermediate table that links them. FACT_RELATIONSHIP would work.

#9

We have learned that we cannot rely on transfer dates. In the source systems, they are often poorly defined and overlapping. Therefore, it would be difficult to establish the link using these dates. The link though is very important.

t