Should we include Fact relationships in OMOCL and if yes how?

Integration OHDSI OMOP
1

So the problem is simple, the CDM has often no faithful representation for some of the archetype nodes e.g. the body site of an problem diagnosis.
If we want to persist this information, we need to use unspecific fields like Observation and Note.
So far so good.
But we need to link these table to the initial table that was mapped from the archetype.
In case of the problem diagnosis this would be a CONDITION_OCCURRENCE.
To do so we must add a fact_relationship that links both tables.
Nevertheless, the fact relationship has no support in the tooling provided by OHDSI.
Not processing this link will bloat a CDM with useless context information like a body site observation without a link to the CONDITION etc.

So there are now 2 ways we can tackle this:

Don’t add it to OMOCL

Add it, but then we need to provide some logic for the ETL engines so these mappings that require fact relationships can be ignored, if required.
How ?

We add a new syntax to OMOCL where we specify granularity levels inside the mapping files e.g. (syntax needs improvement ):

level-1 mappings:
all the necessary stuff we already have

level-2

Mappings dependent on fact rel.

archetype_id: "openEHR-EHR-EVALUATION.problem_diagnosis.v1"

mappings:
 - type: "ConditionOccurrence"
   level: 1
   concept_id:
     alternatives:
       - path: "data[at0001]/items[at0002]"
   condition_start_date:
     alternatives:
       - path: "data[at0001]/items[at0077]"
       - path: "../context"
   condition_end_date:
     optional: true
     alternatives:
       - path: "data[at0001]/items[at0030]"
   condition_status_concept_id:
     optional: true
     alternatives:
       - path: "data[at0001]/items[openEHR-EHR-CLUSTER.problem_qualifier.v1]/items[at0004]"
       - code: 32893
  1. We could also maintain two versions of each files like two versions of OMOCL but thats some overhead, but more clean.

Any other suggestions and thoughts?

@yampeku

2

Thought one. As you say having random notes or observations isn’t really useful if they are not related to the other concepts, so maybe the debate should be about the usefulness of those attributes for research purposes in the first place. Personally, while I think in fact that the fact_relationship table is a missed opportunity in OMOP, it is also true that if you really need all the specific information or context for your research you should use openEHR directly :wink:
So my recommendation would be to leave this mappings as simple as possible, and only add a mapping for an Element in openEHR if the result would end in one of the non-note/non-observation tables

1 Like
3

I agree that non Note/Observation are a good start. I would extend that to the point were we only support fact rel. where a rel code is present. If we link tables which have no relationship code its kinda useless since you dont know HOW they relate.

Im just scared, that to some point OMOP tooling will add support for fact rel (or new rel codes) and then we need to redefine all the mappings. Since we are at the start of it my thought was we include it in the first place if its ever needed. Maybe we should move this discussion to the OHDSI discourse and ask for their opinion.

Also what do we do with the measurement event links, they are currently also not used by anyone ?

1 Like