ConceptMap

Defines the core relationship between a source concept and a target concept using precise equivalence codes:

• equivalent: The concepts mean exactly the same thing
• equal: The concepts are identical in meaning and scope
• wider: The target concept is broader than the source
• narrower: The target concept is more specific than the source
• inexact: The mapping is approximate or partial
• unmatched: No valid mapping exists

This granularity allows terminology servers to make intelligent decisions about when a translation is safe for clinical use versus when it requires human review.

ConceptMap supports both unidirectional and bidirectional mapping declarations:

• A single ConceptMap can define mappings from source to target only, or declare that the relationship is reversible
• The reverse property on each mapping element indicates whether the equivalence holds in the opposite direction
• Bidirectional maps are critical for round-trip translation scenarios, such as converting a SNOMED CT code to ICD-10-CM for billing and then back for clinical decision support

This explicit directionality prevents dangerous assumptions about reversibility that could lead to data loss or clinical errors.

Mappings within a ConceptMap are organized into logical groups for maintainability and clarity:

• Each group specifies a distinct source and target system (e.g., source: "http://snomed.info/sct", target: "http://hl7.org/fhir/sid/icd-10-cm")
• Within each group, individual mapping elements connect specific codes
• Groups can also define unmapped handling instructions, specifying what to do when no explicit mapping exists for a source concept

This structure allows a single ConceptMap resource to manage complex, multi-system translation scenarios while keeping the provenance of each mapping clear.

Advanced mappings can declare contextual dependencies that must be satisfied for the translation to be valid:

• dependsOn: Specifies additional properties that must be provided to resolve the mapping. For example, mapping a lab code from LOINC to a local code might depend on the specimen type
• product: Specifies properties that are created as output of the mapping. For instance, translating a single SNOMED CT concept might produce both a condition code and a body site modifier

These features enable ConceptMap to handle complex clinical scenarios where simple one-to-one code translation is insufficient, supporting the rich semantics of healthcare terminology.

ConceptMap is a first-class resource in the FHIR Terminology Service API, supporting several critical operations:

• $translate: The primary operation that takes a code, a source system, and a target system, and returns the mapped concept along with its equivalence status
• $closure: Maintains a transitive closure table for iterative mapping across multiple ConceptMaps
• Servers can chain multiple ConceptMaps together to perform multi-hop translations (e.g., local code → SNOMED CT → ICD-10-CM)

This standardized API allows any FHIR-compliant system to perform terminology translation without custom integration code.

ConceptMap includes robust metadata for tracking the authority and currency of mappings:

• publisher and author fields identify who created and maintains the mapping set
• date and version track when mappings were last updated and which iteration is in use
• Individual mapping elements can include sourceReference to cite the authoritative mapping source, such as the SNOMED CT to ICD-10-CM map published by IHTSDO
• This provenance is essential for auditability in regulated environments where the origin of a code translation must be traceable for compliance and patient safety reviews

A CodeSystem resource formally defines a terminology, enumerating all valid concepts and their associated codes. It is the source of truth that a ConceptMap draws from.

• Declares the canonical URL and version for a code system like SNOMED CT or LOINC
• Defines properties such as whether codes are case-sensitive or compositional
• ConceptMap references CodeSystems in its sourceUri and targetUri elements to establish the mapping context

A ValueSet resource defines a curated set of codes drawn from one or more CodeSystems, intended for use in a specific clinical context. ConceptMaps often translate between ValueSets rather than entire code systems.

• Specifies which codes are allowed for a particular data element through terminology binding
• Can be defined intensionally (by rules) or extensionally (by explicit enumeration)
• ConceptMap can map a source ValueSet to a target ValueSet, enabling translation between constrained code subsets

Terminology binding is the mechanism in FHIR that links a coded element to a specific ValueSet, defining the allowed set of codes and the binding strength.

• Binding strengths include required (must use codes from the ValueSet), extensible (may use codes outside if no match), and example (suggested only)
• ConceptMap supports translation when different systems use different bindings for the same clinical concept
• A ConceptMap with equivalent mapping strength can justify automated translation between differently-bound elements

The FHIR Terminology Service is a RESTful API specification for interacting with a terminology server. It provides operations that leverage ConceptMap resources for runtime code translation.

• $translate operation: Accepts a code and a ConceptMap URL, returning the mapped code in the target system
• $closure operation: Maintains a transitive closure table for hierarchical concept relationships
• $validate-code operation: Checks whether a code exists in a ValueSet, optionally using ConceptMap to test if a translation is valid

A StructureMap resource defines a detailed, executable transformation from one set of FHIR resources to another, mapping element by element. While ConceptMap handles terminology translation, StructureMap handles structural transformation.

• Uses FHIR Mapping Language to define input-to-output field mappings
• Often used alongside ConceptMap: StructureMap transforms the data structure while ConceptMap translates the codes within
• Together they enable full legacy-to-FHIR conversion pipelines

The FHIR Mapping Language is a domain-specific language designed by HL7 to author transformation rules that convert legacy healthcare data formats into FHIR resources.

• Provides syntax for defining source-to-target field assignments, conditions, and loops
• ConceptMap resources can be invoked within mapping rules to perform code translation during transformation
• Essential for building repeatable, auditable data conversion pipelines from HL7 v2 or CDA to FHIR