FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

4.10 Resource ConceptMap - Content

Terminology Infrastructure icon Work GroupMaturity Level: 3 Trial UseSecurity Category: Anonymous Compartments: No defined compartments

A statement of relationships from one set of concepts to one or more other concepts - either concepts in code systems, or data element/data element concepts, or classes in class models.

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

  • a child code value corresponding to the http://hl7.org/fhir/conceptmap-properties#relationshipRefinement concept (from the ConceptMap Properties code system) and
  • a child valueCode or valueCoding value to indicate the precise relationship.
In this case, well-known relationships, such as those from the Simple Knowledge Organization System (SKOS) icon, 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:

  • because there are multiple possible mappings (e.g., ambiguous)
  • to specify a correct map, and specify other mappings as invalid
  • when there are multiple mappings depending on the values of other elements (dependsOn)

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.

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

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

Implementation Note: This resource has undergone an extensive redesign between Release 4 and Release 5. Key changes:

  • A number of metadata fields have been added (same as CodeSystem and ValueSet)
  • source and target were renamed to sourceScope and targetScope for clarity
  • ConceptMap.group.element.target.equivalence has been renamed to ConceptMap.group.element.target.relationship for clarity, and the set of relationship codes has simplified, and the code umatched has been moved to the noMap element
  • ConceptMap.group.element.target.property has been added to support providing additional details about the relationship between source and target. Like with CodeSystem and ValueSet, properties are defined using ConceptMap.property
  • ConceptMap.group.element.target.dependsOn.property was renamed to ConceptMap.group.element.target.dependsOn.attribute to clarify that these are not properties of the mapping, but additional attributes of the source or target content. The data type was changed from url to code which references ConceptMap.additionalAttribute to allow for a more concise representation, along with documentation
  • ConceptMap.group.element.valueSet was added to facilitate mapping all concepts from a source value set
  • ConceptMap.group.element.target.valueSet has been added to facilitate mapping to each concept in a target value set
  • relationship and valueSet have been added to the unmapped element and some other clarifications have been made

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. ConceptMap TU DomainResource A map from one set of concepts to one or more other concepts
+ Warning: Name should be usable as an identifier for the module by machine processing applications such as code generation

Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
Interfaces Implemented: MetadataResource
... url ΣC 0..1 uri Canonical identifier for this concept map, represented as a URI (globally unique)
+ Warning: URL should not contain | or # - these characters make processing canonical references problematic
... identifier Σ 0..* Identifier Additional identifier for the concept map

... version Σ 0..1 string Business version of the concept map
... versionAlgorithm[x] Σ 0..1 How to compare versions
Binding: Version Algorithm (Extensible)
.... versionAlgorithmString string
.... versionAlgorithmCoding Coding
... name ΣC 0..1 string Name for this concept map (computer friendly)
... title ΣT 0..1 string Name for this concept map (human friendly)
... status ?!ΣC 1..1 code draft | active | retired | unknown
Binding: PublicationStatus (Required)
... experimental Σ 0..1 boolean For testing only - never for real usage
... date Σ 0..1 dateTime Date last changed
... publisher ΣT 0..1 string Name of the publisher/steward (organization or individual)
... contact Σ 0..* ContactDetail Contact details for the publisher

... description T 0..1 markdown Natural language description of the concept map
... useContext Σ 0..* UsageContext The context that the content is intended to support

... jurisdiction ΣXD 0..* CodeableConcept Intended jurisdiction for concept map (if applicable)
Binding: Jurisdiction ValueSet (Extensible)

... purpose T 0..1 markdown Why this concept map is defined
... copyright T 0..1 markdown Use and/or publishing restrictions
... copyrightLabel T 0..1 string Copyright holder and year(s)
... approvalDate 0..1 date When the ConceptMap was approved by publisher
... lastReviewDate 0..1 date When the ConceptMap was last reviewed by the publisher
... effectivePeriod Σ 0..1 Period When the ConceptMap is expected to be used
... topic XD 0..* CodeableConcept E.g. Education, Treatment, Assessment, etc
Binding: Definition Topic (Example)

... author 0..* ContactDetail Who authored the ConceptMap

... editor 0..* ContactDetail Who edited the ConceptMap

... reviewer 0..* ContactDetail Who reviewed the ConceptMap

... endorser 0..* ContactDetail Who endorsed the ConceptMap

... relatedArtifact 0..* RelatedArtifact Additional documentation, citations, etc

... property ΣC 0..* BackboneElement Additional properties of the mapping
+ Rule: If the property type is code, a system SHALL be specified

.... code Σ 1..1 code Identifies the property on the mappings, and when referred to in the $translate operation
.... uri Σ 0..1 uri Formal identifier for the property
.... description Σ 0..1 string Why the property is defined, and/or what it conveys
.... type ΣC 1..1 code Coding | string | integer | boolean | dateTime | decimal | code
Binding: ConceptMap Property Type (Required)
.... system ΣC 0..1 canonical(CodeSystem) The CodeSystem from which code values come
... additionalAttribute Σ 0..* BackboneElement Definition of an additional attribute to act as a data source or target

.... code Σ 1..1 code Identifies this additional attribute through this resource
.... uri Σ 0..1 uri Formal identifier for the data element referred to in this attribte
.... description Σ 0..1 string Why the additional attribute is defined, and/or what the data element it refers to is
.... type Σ 1..1 code code | Coding | string | boolean | Quantity
Binding: ConceptMap Attribute Type (Required)
... sourceScope[x] Σ 0..1 The source value set that contains the concepts that are being mapped
.... sourceScopeUri uri
.... sourceScopeCanonical canonical(ValueSet)
... targetScope[x] Σ 0..1 The target value set which provides context for the mappings
.... targetScopeUri uri
.... targetScopeCanonical canonical(ValueSet)
... group 0..* BackboneElement Same source and target systems

.... source 0..1 canonical(CodeSystem) Source system where concepts to be mapped are defined
.... target 0..1 canonical(CodeSystem) Target system that the concepts are to be mapped to
.... element C 1..* BackboneElement Mappings for a concept from the source set
+ Rule: If noMap is present, target SHALL NOT be present
+ Rule: Either code or valueSet SHALL be present but not both.

..... code C 0..1 code Identifies element being mapped
..... display 0..1 string Display for the code
..... valueSet C 0..1 canonical(ValueSet) Identifies the set of concepts being mapped
..... noMap C 0..1 boolean No mapping to a target concept for this source concept
..... target C 0..* BackboneElement Concept in target system for element
+ Rule: If the map is source-is-broader-than-target or not-related-to, there SHALL be some comments, unless the status is 'draft'
+ Rule: Either code or valueSet SHALL be present but not both.

...... code C 0..1 code Code that identifies the target element
...... display 0..1 string Display for the code
...... valueSet C 0..1 canonical(ValueSet) Identifies the set of target concepts
...... relationship ?!C 1..1 code related-to | equivalent | source-is-narrower-than-target | source-is-broader-than-target | not-related-to
Binding: ConceptMapRelationship (Required)
...... comment C 0..1 string Description of status/issues in mapping
...... property 0..* BackboneElement Property value for the source -> target mapping

....... code 1..1 code Reference to ConceptMap.property.code
....... value[x] 1..1 Value of the property for this concept
........ valueCoding Coding
........ valueString string
........ valueInteger integer
........ valueBoolean boolean
........ valueDateTime dateTime
........ valueDecimal decimal
........ valueCode code
...... dependsOn C 0..* BackboneElement Other properties required for this mapping
+ Rule: One of value[x] or valueSet must exist, but not both.

....... attribute 1..1 code A reference to a mapping attribute defined in ConceptMap.additionalAttribute
....... value[x] C 0..1 Value of the referenced data element
........ valueCode code
........ valueCoding Coding
........ valueString string
........ valueBoolean boolean
........ valueQuantity Quantity
....... valueSet C 0..1 canonical(ValueSet) The mapping depends on a data element with a value from this value set
...... product 0..* see dependsOn Other data elements that this mapping also produces

.... unmapped C 0..1 BackboneElement What to do when there is no mapping target for the source concept and ConceptMap.group.element.noMap is not true
+ Rule: If the mode is 'fixed', either a code or valueSet must be provided, but not both.
+ Rule: If the mode is 'other-map', a url for the other map must be provided
+ Rule: If the mode is not 'fixed', code, display and valueSet are not allowed
+ Rule: If the mode is not 'other-map', relationship must be provided
+ Rule: If the mode is not 'other-map', otherMap is not allowed
..... mode C 1..1 code use-source-code | fixed | other-map
Binding: Concept Map Group Unmapped Mode (Required)
..... code C 0..1 code Fixed code when mode = fixed
..... display C 0..1 string Display for the code
..... valueSet C 0..1 canonical(ValueSet) Fixed code set when mode = fixed
..... relationship ?!C 0..1 code related-to | equivalent | source-is-narrower-than-target | source-is-broader-than-target | not-related-to
Binding: ConceptMapRelationship (Required)
..... otherMap C 0..1 canonical(ConceptMap) canonical reference to an additional ConceptMap to use for mapping if the source concept is unmapped

doco Documentation for this format icon

See the Extensions for this resource

 

Additional definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) , the spreadsheet version & the dependency analysis

Path ValueSet Type Documentation
ConceptMap.versionAlgorithm[x] VersionAlgorithm Extensible

Indicates the mechanism used to compare versions to determine which is more current.

ConceptMap.status PublicationStatus Required

The lifecycle status of an artifact.

ConceptMap.jurisdiction JurisdictionValueSet Extensible

This value set defines a base set of codes for country, country subdivision and region for indicating where a resource is intended to be used.

Note: The codes for countries and country subdivisions are taken from ISO 3166 icon while the codes for "supra-national" regions are from UN Standard country or area codes for statistical use (M49) icon.

ConceptMap.topic DefinitionTopic Example

High-level categorization of the definition, used for searching, sorting, and filtering.

ConceptMap.property.type ConceptMapPropertyType Required

The type of a ConceptMap mapping property value.

ConceptMap.additionalAttribute.type ConceptMapAttributeType Required

The type of a ConceptMap mapping attribute value.

ConceptMap.group.element.target.relationship ConceptMapRelationship Required

The relationship between concepts.

ConceptMap.group.unmapped.mode ConceptMapGroupUnmappedMode Required

Defines which action to take if there is no match in the group.

ConceptMap.group.unmapped.relationship ConceptMapRelationship Required

The relationship between concepts.

UniqueKeyLevelLocationDescriptionExpression
img cnl-0Warning (base)Name should be usable as an identifier for the module by machine processing applications such as code generationname.exists() implies name.matches('^[A-Z]([A-Za-z0-9_]){1,254}$')
img cnl-1Warning ConceptMap.urlURL should not contain | or # - these characters make processing canonical references problematicexists() implies matches('^[^|# ]+$')
img cmd-1Rule ConceptMap.group.element.targetIf the map is source-is-broader-than-target or not-related-to, there SHALL be some comments, unless the status is 'draft'comment.exists() or (%resource.status = 'draft') or relationship.empty() or ((relationship != 'source-is-broader-than-target') and (relationship != 'not-related-to'))
img cmd-2Rule ConceptMap.group.unmappedIf the mode is 'fixed', either a code or valueSet must be provided, but not both.(mode = 'fixed') implies ((code.exists() and valueSet.empty()) or (code.empty() and valueSet.exists()))
img cmd-3Rule ConceptMap.group.unmappedIf the mode is 'other-map', a url for the other map must be provided(mode = 'other-map') implies otherMap.exists()
img cmd-4Rule ConceptMap.group.elementIf noMap is present, target SHALL NOT be present(noMap.exists() and noMap=true) implies target.empty()
img cmd-5Rule ConceptMap.group.elementEither code or valueSet SHALL be present but not both.(code.exists() and valueSet.empty()) or (code.empty() and valueSet.exists())
img cmd-6Rule ConceptMap.group.element.target.dependsOnOne of value[x] or valueSet must exist, but not both.(value.exists() and valueSet.empty()) or (value.empty() and valueSet.exists())
img cmd-7Rule ConceptMap.group.element.targetEither code or valueSet SHALL be present but not both.(code.exists() and valueSet.empty()) or (code.empty() and valueSet.exists())
img cmd-8Rule ConceptMap.group.unmappedIf the mode is not 'fixed', code, display and valueSet are not allowed(mode != 'fixed') implies (code.empty() and display.empty() and valueSet.empty())
img cmd-9Rule ConceptMap.group.unmappedIf the mode is not 'other-map', relationship must be provided(mode != 'other-map') implies relationship.exists()
img cmd-10Rule ConceptMap.group.unmappedIf the mode is not 'other-map', otherMap is not allowed(mode != 'other-map') implies otherMap.empty()
img cmd-11Rule ConceptMap.propertyIf the property type is code, a system SHALL be specifiedtype = 'code' implies system.exists()

  • The value of the system, version and code elements are the same as used by the Coding data type
  • When a mapping relationship is characterized as "source-is-broader-than-target", some explanation of the scope difference SHALL be provided in the comments
  • The concept map is a statement of mapping in a single direction. The existence of a matching mapping in the reverse direction cannot be assumed to exist automatically, but only through human review.
  • For simplicity, it is better if is only one element for each source concept. if there is more than one, then just as one element can have multiple targets, multiple occurrences of element with the same element.code simply aggregate their target elements as if there was only one element

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.

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 Details Relationship Target Concept Details
Code from http://example.com/ehr/codes field (dependsOn) Code from http://snomed.info/sct subject (product)
diab Diabetes diagnosis is equivalent to 73211009 Diabetes mellitus patient
diab Diabetes history is equivalent to 161445009 H/O: diabetes mellitus patient
diab Diabetes family is equivalent to 161445009 H/O: Diabetes mellitus family

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.

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:

provided Use 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
fixed Use 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-map Use 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 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:

  • To enable the use of concept maps defined in a code system distribution (e.g., SNOMED CT)
  • To provide a convenient way, in the definition of a ConceptMap to reference another concept map provided in a code system distribution

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.

Implementation 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.

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:

Search parameters for this resource. See also the full list of search parameters for this resource, and check the Extensions registry for search parameters on extensions related to this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

Name Type Description Expression In Common
context token A use context assigned to the concept map (ConceptMap.useContext.value.ofType(CodeableConcept)) 30 Resources
context-quantity quantity A quantity- or range-valued use context assigned to the concept map (ConceptMap.useContext.value.ofType(Quantity)) | (ConceptMap.useContext.value.ofType(Range)) 30 Resources
context-type token A type of use context assigned to the concept map ConceptMap.useContext.code 30 Resources
context-type-quantity composite A use context type and quantity- or range-based value assigned to the concept map On ConceptMap.useContext:
  context-type: code
  context-quantity: value.ofType(Quantity) | value.ofType(Range)
30 Resources
context-type-value composite A use context type and value assigned to the concept map On ConceptMap.useContext:
  context-type: code
  context: value.ofType(CodeableConcept)
30 Resources
date date The concept map publication date ConceptMap.date 31 Resources
derived-from reference A resource that the ConceptMap is derived from ConceptMap.relatedArtifact.where(type='derived-from').resource
(Any)
9 Resources
description string The description of the concept map ConceptMap.description 29 Resources
effective date The time during which the ConceptMap is intended to be in use ConceptMap.effectivePeriod 12 Resources
identifier token External identifier for the concept map ConceptMap.identifier 35 Resources
jurisdiction token Intended jurisdiction for the concept map ConceptMap.jurisdiction 27 Resources
mapping-property uri Other properties required for this mapping ConceptMap.property.uri
name string Computationally friendly name of the concept map ConceptMap.name 28 Resources
other-map reference canonical reference to an additional ConceptMap to use for mapping if the source concept is unmapped ConceptMap.group.unmapped.otherMap
(ConceptMap)
predecessor reference The predecessor of the ConceptMap ConceptMap.relatedArtifact.where(type='predecessor').resource
(Any)
9 Resources
publisher string Name of the publisher of the concept map ConceptMap.publisher 31 Resources
source-code token Identifies elements being mapped ConceptMap.group.element.code
source-group-system reference Source system where concepts to be mapped are defined ConceptMap.group.source
(CodeSystem)
source-scope reference The source value set that contains the concepts that are being mapped (ConceptMap.sourceScope as canonical)
(ValueSet)
source-scope-uri uri The URI for the source value set that contains the concepts being mapped (ConceptMap.sourceScope as uri)
status token The current status of the concept map ConceptMap.status 35 Resources
target-code token Code that identifies the target element ConceptMap.group.element.target.code
target-group-system reference Target system that the concepts are to be mapped to ConceptMap.group.target
(CodeSystem)
target-scope reference The target value set which provides context for the mappings (ConceptMap.targetScope as canonical)
(ValueSet)
target-scope-uri uri The URI for the target value set that contains the concepts being mapped. (ConceptMap.targetScope as uri)
title string The human-friendly name of the concept map ConceptMap.title 28 Resources
topic token Topics associated with the ConceptMap ConceptMap.topic 10 Resources
url uri The URI that identifies the concept map ConceptMap.url 34 Resources
version token The business version of the concept map ConceptMap.version 32 Resources