> For the complete documentation index, see [llms.txt](https://docs.snomed.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.snomed.org/snomed-ct-practical-guides/snomed-ct-mapping-guide/developing-use-case-and-requirements/5.3.2-mapping-rules.md).

# 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:1 | One-to-one  | One source term is related to one target concept                |
| --- | ----------- | --------------------------------------------------------------- |
| 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

| Relationship type  | Description                                                                                                                                                                                                            |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 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:

| Purpose                                                                | Relationship type              |
| ---------------------------------------------------------------------- | ------------------------------ |
| 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.

<a href="https://docs.google.com/forms/d/e/1FAIpQLScTmbZIf0UEQwYDkY27EEWBkaiYkHSbR0_9DmFrMLXoQLyL7Q/viewform?usp=pp_url&#x26;entry.1767247133=Mapping+Guide&#x26;entry.670899847=Mapping%20rules" class="button primary">Provide Feedback</a>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.snomed.org/snomed-ct-practical-guides/snomed-ct-mapping-guide/developing-use-case-and-requirements/5.3.2-mapping-rules.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.