Terminology code mapping

[joostholslag]

Currently it seems only the defining code of a dv coded text is mapped to OMOP, while the term mapping should (conditionally?) be mapped there as well.
this is especially relevant for the problem diagnosis archetype. diagnoses should be able to be recorded as free text (dv text.value) and only mapped to a terminology code as a secondary action using term mapping (https://specifications.openehr.org/releases/RM/development/data_types.html#_requirements_2).

[SevKohler]

True, we never mapped the term_mapping i think we should add that @yampeku what do you think ?

[yampeku]

I can see the use case, the only issue I can think about this is when multiple term_mappings exist how to choose the "good" one

[joostholslag]

I can see the use case, the only issue I can think about this is when multiple term_mappings exist how to choose the "good" one

Good one. Already picking the first one would be Better than the status quo.
A bit more comprehensive would be to evaluate the match operator: I guess we should prefer exact matches, and maybe exclude/manually verify narrower matches
Another consideration would be the target coding e.g. preferring a snomed mapping for the condition code.
And the 'purpose' could also be useful in controlled environments, e.g, prefer the mapping that has a purpose of 'export for analysis using OMOP CDM'.

[yampeku]

Yeah, we have available mappings for SNOMED (which is the actual standard terminology in OMOP), ICD9 and ICD10. Last two cannot be assumed to always map to the condition domain (specially ICD9). Apart from that, cancer codes (ICDO3) are always observations, we'll have to check if they end up in problem/diagnosis in the first place.
Other issues I can think of are when codes come from national snomed extensions (codes won't exist in omop) or if term_mappings have different flavors of "snomed" (SNOMED, SNOMED-CT, snomedct, etc.). We can probably limit the impact of this second one if we agree on cross-vendor terminology names.

[yampeku]

Affected class is DVTextCodeToConceptConverter
Both of these methods should be updated

    private ParameterWrapper buildQuery(DvText dvText) {
        return new ParameterWrapper(
                "String",
                List.of("conceptCode"),
                List.of("="),
                List.of(dvText.getValue()),
                "and"
        );
    }

    private ParameterWrapper buildQuery(DvCodedText dvCodedText) {
        String vocabularyId = VocabularyIdConverter.convert(dvCodedText.getDefiningCode().getTerminologyId().getValue());
        return new ParameterWrapper(
                "String",
                Arrays.asList("vocabularyId", "conceptCode"),
                Arrays.asList("=", "="),
                Arrays.asList(vocabularyId, dvCodedText.getDefiningCode().getCodeString()),
                "and"
        );
    }

we should create a new method getCodeOrMapping(dvText) that returns dvText.getMappings.get(0).getTarget().getCodeString() when dvText.getValue() is null (for DvText) or dvCodedText.getDefiningCode().getCodeString() is null (for DvCodedText)
Realistically vocabularyId should also be able to be calculated on the fly from dvCodedText.getDefiningCode().getTerminologyId().getValue(), but can be different in source than target. Maybe we can define a terminology name mapping CSV or yaml, which could easily support several source "spellings" for the same target terminology (see the SNOMED example in a prior comment)