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.
We add a new syntax to OMOCL where we specify granularity levels inside the mapping files e.g. (syntax needs improvement ):
all the necessary stuff we already have
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
- 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?