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

The uri that is used to identify this concept map when it is referenced in a specification, model, design or an instance (should be globally unique URI, and an be urn:uuid: or urn:oid:).

Formal identifier that is used to identify this concept map when it is represented in other formats, or referenced in a specification, model, design or an instance.

Typically, this is used for values that can go in a v3 II data type.

The identifier that is used to identify this version of the concept map when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the profile author manually and the value should be a timestamp.

There may be multiple resource versions of the concept map that have this same identifier.

A free text natural language name describing the concept map.

Support human navigation.

Not expected to be unique.

The name of the individual or organization that published the concept map.

Helps establish the "authority/credibility" of the concept map. May also allow for contact.

Usually an organization, but may be an individual. This item SHOULD be populated unless the information is available from context.

Contacts to assist a user in finding and communicating with the publisher.

May be a web site, an email address, a telephone number (tel:), etc.

The name of an individual to contact regarding the concept map.

If there is no named individual, the telecom is for the organization as a whole.

Contact details for individual (if a name was provided) or the publisher.

A free text natural language description of the use of the concept map - reason for definition, conditions of use, etc.

Human understandability.

The description is not intended to describe the semantics of the concept map. The description should capture its intended use, which is needed for ensuring integrity for its use in models across future changes.

Explains why this concept map is needed and why it's been constrained as it has.

This element does not describe the usage of the concept map (that's done in comments), rather it's for traceability of why the element is either needed or why the constraints exist as they do. This may be used to point to source materials or specifications that drove the structure of this data element.

A copyright statement relating to the concept map and/or its contents.

Frequently, the copyright differs between the concept map, and codes that are included. The copyright statement should clearly differentiate between these when required.

The status of the concept map.

Identify when/if the concept map should be used.

Allows filtering of ConceptMaps that are appropriate for use.

This ConceptMap was authored for testing purposes (or education/evaluation/marketing), and is not intended to be used for genuine usage.

Allows filtering of ConceptMaps that are appropriate for use.

The date that the concept map status was last changed.

Need to know when a concept map was first legal for use or became withdrawn or replaced.

Note that this is not the same as the resource last-modified-date, since the resource may be a secondary representation of the concept map.

The source value set that specifies the concepts that are being mapped.

Should be a version specific reference.

The target value set provides context to the mappings. Note that the mapping is made between concepts, not between value sets, but the value set provides important context about how the concept mapping choices are made.

Mappings for an individual concept in the source to one or more concepts in the target.

Generally, the ideal is that there would only be one mapping for each concept in the source value set, but a given concept may be mapped mutliple times with different comments or dependencies.

Code System (if the source is a value value set that crosses more than one code system).

Identity (code or path) or the element/item being mapped.

A set of additional dependencies for this mapping to hold. This mapping is only applicable if the specified element can be resolved, and it has the specified value.

A reference to a specific concept that holds a coded value. This can be an element in a FHIR resource, or a specific reference to a data element in a different specification (e.g. v2) or a general reference to a kind of data field, or a reference to a value set with an appropriately narrow definition.

The code system of the dependency code (if the source/dependency is a value set that cross code systems).

Identity (code or path) or the element/item that the map depends on / refers to.

A concept from the target value set that this concept maps to.

Ideally there would only be one map, with equal or equivalent mapping. But multiple maps are allowed for several narrower options, or to assert that other concepts are unmatched.

The code system of the target code (if the target is a value set that cross code systems).

Should be a version specific reference.

Identity (code or path) or the element/item that the map refers to.

The equivalence between the source and target concepts (counting for the dependencies and products). The equivalence is read from source to target (e.g. the source is 'wider' than the target.

A description of status/issues in mapping that conveys additional information not represented in the structured data.

A set of additional outcomes from this mapping to other elements. To properly execute this mapping, the specified element must be mapped to some data element or source that is in context. The mapping may still be useful without a place for the additional data elements, but the equivalence cannot be relied on.