> 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.4-mapping-and-review-approach.md).

# Mapping and review approach

There are a number of different mapping and review approaches that can be done.

Considerations when choosing an approach include:

{% columns %}
{% column %}
**Team resources**

* size of team
* time resources
* personnel/expertise levels
  {% endcolumn %}

{% column %}
**Project timelines**

**Map content**

* use cases
* clinical risk
  {% endcolumn %}
  {% endcolumns %}

SNOMED International does not recommend a single mapping approach, but independent approaches are typically feasible for achieving high-quality maps. Alternatively, or additionally, a combination of review methods can be recommended to ensure a reliable and usable review process. Ideally, maps should be reviewed iteratively until the users are satisfied. Examples of the approaches to take are illustrated in the following table.

<details>

<summary>Single author, no reviewer</summary>

In this approach, each source row is authored by a single author with no review process. This approach could involve a single user completing all source rows, or the source rows being shared across multiple users. This may be suitable for very small teams for maps that are not intended for clinical use and have very low clinical risk.

</details>

<details>

<summary>Single author, single reviewer</summary>

In this approach, each source row is authored by a single author and reviewed by a single reviewer. This approach could have a single user completing authoring or reviewing of all source rows, or the source rows shared across multiple users.

Example scenarios:

* One user authors maps for each source code, and one user reviews all maps.
* A group of users author the maps for each source code, while another group reviews them.
* A group of users are responsible for both authoring and reviewing all maps; each user authors maps and also reviews other users' maps.

In a really small team, an author and reviewer may be the same person. However, this is not ideal, and it is highly recommended to include two or more people in the map development process.

These approaches may be suitable if there are sufficient resources and there is appropriate personnel to complete a review to mitigate clinical risk. However, independent author/review processes are considered the gold standard and should be considered if there is a clinical risk and resources allow.

</details>

<details>

<summary>Dual (or multi) independent author with adjudicator (no review)</summary>

In this approach, each source row is independently authored by two or more authors. This approach could have users either authoring all maps or sharing them across multiple users.

After authoring, mappings are compared. Where there is conflict between the authors, then:

* the authors can work together to solve the conflict and come to an agreement. There may be a need for an external adjudicator when agreement cannot be reached
* an independent adjudicator can act to review and resolve conflicts

This approach can produce higher-quality maps because each author independently cross-checks the other's material without being biased by the other's decisions. As adjudication is only required when there is a conflict, this approach can be quicker than conducting a full review.

</details>

<details>

<summary>Workshop</summary>

Validation workshops are dedicated to reviewing and validating the design and/or content of a reference set. In these workshops, the content or uncertainties are discussed in detail, or test-persons are asked to prioritise and assess specific subset members, etc. The participants may have had a chance to review the reference set individually prior to the workshop to prepare questions and comments for discussion. The number of people in the workshop and their roles should be considered and selected based on the format and scope of the specific workshop.

This approach is time-consuming, and this should already be acknowledged in the planning stage. However, this approach may also be rewarding. Workshops often give rise to detailed or unplanned discussions of relevant issues, but they also provide an opportunity for increased ownership and participation among participants, which may positively affect the adoption of the reference set. It is recommended to plan these workshops in detail and to include a set of workshops. The number of workshops required depends on the size of the reference set and how feedback is shared.

</details>

<details>

<summary>Other</summary>

Single author, dual (or multi) independent review

Dual (or multi) independent author with a single reviewer

Dual independent author with dual independent review

</details>

<a href="https://docs.google.com/forms/d/e/1FAIpQLScTmbZIf0UEQwYDkY27EEWBkaiYkHSbR0_9DmFrMLXoQLyL7Q/viewform?usp=pp_url&#x26;entry.1767247133=Mapping+Guide&#x26;entry.670899847=Mapping%20and%20review%20approach" 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.4-mapping-and-review-approach.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.
