General Mapping Strategy

[BorisDelange]

General Mapping Strategy

Summary

Following the review feedback from Paul Hilders and Maxim Moinat, we need to establish a clear, unified mapping strategy that applies across all concepts in the INDICATE dictionary.

To do:

• Abandon "Recommended / Not Recommended" labels
• Define a general rule block that applies to all concepts (see Discussion: Expert Comments)
• Decide on FACT_RELATIONSHIP usage and when it is appropriate
• Define priority rules when a source concept matches multiple standard concepts
• Document Mapping Strategy in Data Provider Handbook
• Create practical ETL examples showing how mappings should be implemented in OMOP tables

---

Current Proposal: General Mapping Rules

This section will be updated based on discussion feedback.

Core Principle

The _concept_id column must always contain a standard concept. This is mandatory for OMOP compliance.

Map to the closest standard concept that accurately represents your source data. Even if no exact match exists, choose the most appropriate standard concept that remains clinically coherent with your source data.

Source Value Preservation

Always preserve the original source information:

• _source_value: original code and description as [<code> - <description>]
• _source_concept_id: the source concept ID (can be non-standard)

This allows traceability from the standardized concept back to the original source data.

Granularity

1. Use the most specific standard concept that matches your source data
2. If no exact match exists, use the closest parent standard concept that remains clinically appropriate

---

Open Questions

1. FACT_RELATIONSHIP table usage

Current OHDSI recommendation: The FACT_RELATIONSHIP table can link related clinical facts (e.g., a measurement to its clinical context). However, it adds complexity to data retrieval.

What we currently do: Expert comments recommend using FACT_RELATIONSHIP to link measurements with position or clinical context (e.g., linking a blood pressure measurement to "Supine body position" SNOMED concept).

Feedback from Maxim:

"I would not recommend using fact relationship in this way. It makes it difficult to retrieve the data. With current OMOP/OHDSI tooling it is easier to list all concepts that have 'oxygen at rest' than making the join with fact relationship."

Questions:

• Should we recommend FACT_RELATIONSHIP for linking context (position, clinical setting)?
• Or should we recommend using pre-coordinated concepts when available (e.g., "Heart rate --supine" instead of "Heart rate" + FACT_RELATIONSHIP to "Supine position")?

2. Priority when a source concept matches multiple standard concepts

Context: LOINC uses pre-coordinated concepts that combine multiple dimensions (measurement method + position + clinical context) into single codes. A source concept may match multiple standard concepts of equivalent granularity but from different dimensions.

Example: A source concept "Heart rate by Pulse oximetry, supine, post bronchodilation" (very unlikely in practice!) could potentially map to:

• Heart rate by Pulse oximetry (LOINC 8889-8) - by measurement method
• Heart rate --supine (LOINC 68999-2) - by position
• Heart rate --post bronchodilation (LOINC 89282-8) - by clinical context

Questions:

• Should we establish a priority hierarchy between concept dimensions (e.g., measurement method > position > clinical context)?
• Or should we let data providers choose the most relevant dimension for their use case?

---

How to Contribute

Please share your thoughts on the open questions above by replying to this discussion. Based on your feedback, the "Current Proposal" section will be updated to reflect the agreed-upon mapping strategy.