ConceptMap

The core of a ConceptMap is the relationship element, which defines the semantic correspondence between a source and target concept. This goes beyond a simple 'match' to specify the degree of alignment.

• relatedto: A generic, non-specific association.
• equivalent: The definitions are identical.
• equal: The concepts are exactly the same.
• wider: The target concept is broader than the source.
• subsumes: The target concept fully encompasses the source.
• narrower: The target concept is more specific than the source.
• specializes: The target concept is a subtype of the source.
• inexact: The mapping is imprecise but useful.
• unmatched: No valid target concept exists.

A ConceptMap organizes mappings into logical group elements, each defining a specific translation scope. A single group specifies a source code system (e.g., SNOMED CT) and a target code system (e.g., ICD-10-CM). Within each group, individual element entries list the source code and its one or more target code matches. This structure allows a single ConceptMap resource to handle complex, multi-system translation tasks, such as mapping a single SNOMED CT concept to multiple ICD-10-CM codes based on different clinical contexts.

A FHIR ConceptMap is inherently unidirectional. It defines a translation from a specific source to a specific target. To create a reversible mapping, a separate ConceptMap instance must be authored with the source and target systems swapped. This design choice ensures clarity and avoids the ambiguity of implied bidirectionality, which is often inaccurate in complex medical terminologies where a single target code might map back to multiple source concepts. The sourceCanonical and targetCanonical fields explicitly declare the direction of the mapping.

A single source concept can map to multiple target concepts based on context. The dependsOn and product elements within a target mapping allow for conditional logic. For example, a SNOMED CT code for 'diabetes' might map to one ICD-10-CM code if the patient is type 1 and another if type 2. The dependsOn element specifies the property (like 'patient type') and its required value to trigger a specific mapping, enabling precise, rule-based translation that accounts for real-world clinical variability.

Each mapping within a ConceptMap can carry its own provenance using the extension element. This allows implementers to record critical metadata such as the author, review date, and justification for a specific mapping assertion. This is essential for governance in regulated clinical environments, providing a complete audit trail for why a particular translation was made. The resource-level publisher, version, and status fields further support lifecycle management, ensuring that only validated and current mappings are used in production systems.

The algorithmic process of generating candidate mappings by analyzing the logical structure of ontologies, not just text labels. It leverages description logic axioms and hierarchical context.

• Uses reasoners to check logical consistency.
• Identifies structural homologies between source and target graphs.
• More robust against lexical ambiguity than pure string matching.
• Often combined with BERT-based alignment for hybrid accuracy.

A curated, authoritative list of codes that defines a specific clinical data element. ConceptMaps are often scoped to translate codes within a specific Value Set.

• Intensional definitions use logical rules (e.g., all descendants of a concept).
• Extensional definitions list each code explicitly.
• The FHIR $expand operation generates the full list of codes from an intensional definition.
• Ensures mappings are contextually relevant to a specific use case like a quality measure.

Metadata that records the complete audit trail of a mapping assertion. Critical for regulatory compliance and clinical safety governance.

• Tracks who authored the mapping and when.
• Records the confidence score and justification.
• Documents if a mapping was generated by an algorithm or a human.
• Essential for human-in-the-loop validation workflows to identify high-risk automated mappings.

The lifecycle process of updating ConceptMaps when underlying terminologies release new editions. Semantic drift can break existing mappings.

• Handles deprecated and retired codes.
• Re-evaluates mappings when a concept's hierarchical placement changes.
• Automated regression testing ensures that a migration does not degrade translation accuracy.
• Critical for maintaining alignment between annual ICD-10-CM and biannual SNOMED CT releases.