View raw Markdown
type: resourceresource: ConceptMap

ConceptMap

Introduction

Scope and Usage

A concept map defines a mapping from a set of concepts defined in a code system (commonly referred to as the "system") to one or more concepts defined in other code systems. In the mapping context, a system can be a typical code system based on a recognized standard or local terminology (in any of its forms), or in some cases it may be an "implicit" code system that is not based on a recognized terminology but still represents a set of "concepts" that can be usefully mapped. Mappings are one way - from the source to the target system. In many cases, the reverse mappings are valid, but this cannot be assumed to be the case.

Mappings between code system concepts are only intended to be defined in the context of a particular business usage. The business use case is normally defined by the specification of the source and target value sets. The mappings may be useful in other contexts, but this must be determined based on the context of use and meaning; it cannot be taken for granted automatically. An example where the usage context is important for choosing the correct mapping is mapping from a clinical terminology (e.g. SNOMED CT) to a classification (e.g. ICD-10) for either data analysis or billing. Mappings in the data analysis context would be targeted for an appropriate classification (often at a higher level), whereas in the billing context there may be specific requirements to be met (e.g. leaf level codes only) that could result in multiple mappings for a single source concept and then require additional information beyond the source concept itself in order to select the correct final mapping.

Note that all code systems (explicit or implicit) represented in FHIR have URI identifiers for value sets (also either explicit or implicit) that include the entire code system, and these "all codes" value sets can be used for mappings that are valid in all use contexts that are appropriate for the code system.

Each mapping from a source concept to a target concept includes a relationship element describing the semantic correspondence between the two (or, in some cases, that there is no valid mapping). If none of the relationships in ConceptMapRelationship is precise enough, then a ConceptMap.group.element.target.propertydata element can be used with

In this case, well-known relationships, such as those from the Simple Knowledge Organization System (SKOS), should be used where possible.

There can be an element for each concept or field in the sourceScope value set or group.source code system that needs to be mapped. Each source concept may have multiple targets:

The mapping applies to all members of the expansion of the group.element.valueSet which are also within the scope of sourceScope if specified.

The meaning associated with the use of group.element.valueSet is the same as having individual group.element.code mappings for each concept in the expansion of the group.element.valueSet.

The mapping applies to all members of the expansion of the group.element.target.valueSet which are also within the scope of targetScope if specified.

The meaning associated with the use of group.element.target.valueSet is the same as having individual group.element.target.code mappings for each concept in the expansion of the group.element.target.valueSet.

The expansion of the group.unmapped.valueSet value set provides the set of fixed codes to use when the mode = 'fixed'. All unmapped source codes are then mapped to each of these fixed codes.

There SHOULD be at least one target for each element, but some incomplete concept maps might not have a target for each concept.

A key concept for the ConceptMap resource is the $translate operation. This operation is a formal definition of an API by which a terminology server can allow clients to ask for a translation to be done based on the content in the ConceptMap resource. As such it also provides useful perspective on the operational use of ConceptMap resources in any context.

Boundaries and Relationships

While ConceptMap resources are not referred to directly from any other resource, they may be included and used in ImplementationGuide resources, and provide background knowledge that is useful in many contexts, including operations defined in this specification.

In addition to ConceptMap, there is also the StructureMap resource. The ConceptMap resource defines relationships between concepts in their own right, along with grading of their equivalencies, while the StructureMap defines an executable transform for instances that conform to a known structure.

Both Code System supplements and Concept Maps may be used to define relationships between concepts in different systems. ConceptMaps are assertions of the relationships between different concepts that are associated with particular contexts of use, while CodeSystem supplements are used to define inherent properties and semantics of the concepts in the code system

Background and Context

Further discussion of the issues involved in mapping between concept definition systems can be found in the HL7 v3 Core Principles document and the functionality described in the OMG CTS 2 specification.

[%impl-note%] This resource has undergone an extensive redesign between Release 4 and Release 5. Key changes:

[%end-note%]

Notes

Notes

Grouping Mappings

The concept mappings in element are arranged into groups that share common source/target systems. These groups have no semantic significance; they exist to make the representation more concise. Concept maps may contain more than one group with the same source and target - this would be a less concise representation but may be useful in order to maintain a fixed order for the concepts that are mapped.

Concepts that are labeled as 'unmatched' are considered to be unmatched in the target value set, irrespective of whether they are contained in a group with a stated target system or not. Groups that contain no target system may only contained 'unmatched' concepts. There is no difference in the meaning of an unmatched target whether or not there is a stated target system.

target.dependsOn and target.product

In the simple case, a mapping is made from one code to another. E.g. from "home address" in one code system to "address - home" in another. But in other cases, the mapping is not a simple one to one mapping. A typical example might be mapping between EHR diagnosis codes whose interpretation depends on the field they occur in in the source data: diagnosis, history, or family history. Furthermore, the target EHR might distinguish diagnosis codes depending on the subject: patient or family. In this case, it is not possible to map just from one code to another. Instead, the mapping might contain entries like this:

Source Concept DetailsRelationshipTarget Concept Details
Code from http://example.com/ehr/codesfield (dependsOn)
diabDiabetesdiagnosis
diabDiabeteshistory
diabDiabetesfamily

When attempting to translate the source to the target, an application SHOULD also provide a value for the element(s) identified in dependsOn.property so that the correct mapping can be performed.

All dependsOn and product values are included in the output of $translate.

Interpretation and use of these values is based on the definition of the associated property.

The use of valueCode implies the CodeSystem is known from the property definition.

To see real examples of mappings with dependencies, check Specimen Type Mapping and Message ADT A04 to Bundle Mapping.

Handling Unmapped Codes

If there is no explicit mapping for a code - that is, the engine processing the ConceptMap finds a group with a matching source system, but not matching element for the code it is translating, processing proceeds to the unmapped element that specifies what should happen.

The unmapped element can specify one of the following different actions to take if there is no mapping for a concept:

providedUse the code source as provided in the $translate request. This is especially useful for translations between versions of the same code system, where only a few codes have changed
fixedUse the code (and display) explicitly provided in the group.unmapped. This is useful when there's a fall back general code - especially for classifications
other-mapUse the map identified by the canonical URL in otherMap. This is useful when a published concept map needs to be varied for a few specific cases on an institutional basis - the institution can create a simple concept that expresses their special cases, and then refer to the general purpose mappings

Note that this element is not used when there is an element with a matching code value, and a relationship value of not-related-to.

Implicit Concept Maps

Implicit concept maps are defined in a specification which references the underlying code system structures or other release data, and includes a prescribed URI pattern to identify the concept map. For example, there are some implicit concept map URI patterns defined for SNOMED CT.

Implicit concept maps allow the URI to serve as the basis for the ConceptMap $translate operation without the need to create a ConceptMap resource instance.

Some advantages of using implicit concept maps are that they may be used:

If there is an explicit concept map resource with the same URI as a known implicit concept map, it SHALL conform the pattern described in the definition of the implicit concept map. It is up to the discretion of the server how to handle explicit instances when it is also able to process requests for the implicit concept map.

[%impl-note%] If the relevant server(s) support implicit concept maps, implementers are discouraged from creating their own explicit concept maps with the same URI, as their existence may create confusion. [%end-note%]

Implicit concept map URIs can be used anywhere a concept map URI can be used. Support for implicit concept map URI patterns varies across terminology servers. Code system publishers may define implicit concept map URI patterns. FHIR terminology servers might or might not support any or all of these URI patterns. Caution should be exercised when using concept map URI patterns that have not been defined by HL7 or the code system publisher.

The following link describes the currently defined FHIR implicit concept map URL patterns for SNOMED CT:

StructureDefinition

Elements (Simplified)

Mappings

Implementation Guide

implementationguide-ConceptMap-core.xml

<?xml version="1.0" encoding="UTF-8"?>

<ImplementationGuide xmlns="http://hl7.org/fhir">
  <id value="ConceptMap-core"/>
  <version value="0.01"/>
  <name value="ConceptMapCore"/>
  <title value="ConceptMap Core"/>
  <status value="draft"/>
  <date value="1970-01-01T10:00:00+10:00"/>
  <publisher value="HL7"/>
  <description value="Defines common extensions used with or related to the ConceptMap resource"/>
  <definition>
  </definition>
</ImplementationGuide>

Operations

Full Operations

Resource Packs

list-ConceptMap-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir">
  <id value="ConceptMap-packs"/>
  <status value="current"/>
  <mode value="working"/>
  <entry>
    <item>
      <reference value="ImplementationGuide/ConceptMap-core"/>
    </item>
  </entry>
</List>

Search Parameters

Full Search Parameters

Examples

Full Examples

Mapping Exceptions

conceptmap-fivews-mapping-exceptions.xml

Unmapped Elements