Mapping rules
Mapping rules should be established and documented from the beginning of the process and made available to all personnel for reference during mapping. As mapping continues, there may be a need to update or add new rules, so documentation should be kept up to date.
Mapping rules are specific to the map being developed and should include the following
Map direction
The map direction is determined by the use case that it is intended to cover when implemented. It is important to consider the map's direction, particularly for non-equivalent maps.
During the mapping process, it is natural to map from source to target, which results in a unidirectional map. Unidirectional maps are not intended for use in the reverse direction. Reversing a map can lead to nonsensical maps or unintended consequences, such as assuming additional clinical information that may not be correct when reversing the direction of a SNOMED CT-to-classification map.
Map patterns
Depending on the use case, different map patterns may be required.
Prior to mapping, it may not be known what the final map pattern will be, so rules need to be established to determine what is allowed.
For example, in a funding case scenario, we would expect an N:1 (including 1:1) pattern, but not a 1:N pattern, as we would expect that a single code should belong to only one category (requirement for mutual exclusivity).
1:N
One-to-many
One source term is related to two or more target concepts
N:1
Many-to-one
Two or more source terms are related to a single target concept
1:0
One-to-none
One source term has no available target concept
Map correlation and types of map relationships (degree of equivalence)
The degree of equivalence between the source and target of the map is determined by the use case of the map. Each map between source and target should have a defined type of map relationship describing the type of relationship or degree of equivalence of source and target code
Example map relationship types include
Equivalent
The definitions of the concepts mean the same thing (including when structural implications of meaning are considered) (i.e. extensionally identical).
Broader
The target mapping is broader in meaning than the source concept.
Narrower
The target mapping is narrower in meaning than the source concept.
Inexact
The target mapping overlaps with the source concept, but both source and target cover additional meaning, or the definitions are imprecise and it is uncertain whether they have the same boundaries to their meaning.
No match/unmatched
There is no match for this concept in the target code system.
Allowable relationship types should be determined for the map. Some maps may require equivalence only. Use cases like grouping or funding may require a narrow-to-broad mapping, but rules on how broad to go should be considered.
For example,
a source code for 'Acute myocardial infarction' might be considered for mapping to either Myocardial infarction or Acute cardiovascular disease, where neither code fully expresses the exact same meaning as the source term.
a source code for 'Amoxil 500 mg capsule, 20' could be mapped to amoxicillin or to penicillin
Deciding which option is best would depend on the use case and what would make for a useful map.
Broad-to-narrower mappings may also be required to increase coverage and allow greater content usage in some use cases, such as mapping a legacy code system to a new target code system for data entry implementation.
Examples:
Categorising SNOMED CT codes to ICD 10AM codes for funding in the ED
Broader
Migrating legacy code set in CIS to SNOMED CT
Equivalence, narrower, broader
Translating a medication order to a Trade Product Pack for stock check
Narrower
Using post-coordinated expressions as targets
If mappers cannot find an existing term in the target terminology to map to, they may map to a post-coordinated expression. Post-coordinated expressions can be a solution; however, they can be difficult to implement.
Consider whether the system in which the map is being implemented can support post-coordinated maps and whether other downstream users can consume and use post-coordinated expressions.
All mappers must be familiar with the rules for creating a concept model-compliant post-coordinated expression if this approach is being taken.
Last updated