Mapping rules should be decided and documented from the beginning of the process and available to all personnel to reference during the mapping process. 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 direction of the map, 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 to be used "flipped" and used in the reverse direction. "Flipping" a map can lead to nonsensical maps or lead to unintended consequences such as the assumption of additional clinical information which may not be correct when reversing the direction of a SNOMED CT to ICD 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 might end up being, rules need to placed to decide what is allowed.

For example, in a funding case scenario, we would expect a N:1 (including 1:1) pattern, but not a 1:N as we would expect that a single code should only belong in one single category (requirement for mutual exclusivity).

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

Allowable relationship types  should be determined for the map. Some maps may require equivalence only. Use cases like grouping or funding may require broader (target to narrower source), but rules on how broad to go should be considered.

For example source code Acute myocardial infarction can be mapped to target codes Myocardial infarction or Cardiovascular disease, Amoxil 500 mg capsule, 20 can be mapped to amoxicillin or to penicillin - these decision would be made based on the use case and what would make a useful map.

Narrower (target to source code) may also be required to increase coverage and allow greater content usage in some use cases like mapping a legacy code system to a new target code system for implementation for data entry.

Examples:

Using post coordinated expressions as targets

If mappers are not able to find an existing term within the target terminology to map to they may be able to map to a post coordinated expression.Post coordinated expressions can be a solution, however they can be difficult to implement.

Consider if the system that the map is being implemented in is capable of implementing post coordinated maps and whether other downstream users are able to consume and use post coordinated expressions.

All mappers must bee familiar with the rules of creating a concept model compliant post coordinated expression if this is an approach being taken.