> 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.2-defining-use-case-and-purpose.md).
# Defining use case and purpose
The method for creating a map, along with the rules and processes associated with it, is tightly bound to the map's purpose, use case, and requirements.
It is important that the map's use case and purpose are well-defined prior to beginning map development and clearly documented for reference during development and for implementations. The map's use case and purpose have flow-on effects throughout its lifecycle.
When thinking about this, consider:
* what is the main purpose of this map?
* who is the intended audience?
* what is the scope of content (source and target)?
* who is responsible for developing and maintaining the map?
* how will the map be implemented?
## Use case and purpose
* A map must have a defined and specific purpose
* Provides context to the map
* Influences decisions/rules made when mapping and how to map when there is discrepancies between the source and target code systems
{% hint style="success" %}
**Example:** the purpose of this map is to link Emergency Department SNOMED CT principal diagnosis codes to the Emergency Department National Minimum Data Set for funding.
{% endhint %}
{% hint style="danger" %}
Beware when reusing maps or repurposing mapped data, as even if the source and target code systems appear the same and the healthcare setting is the same, the purpose (and hence the rules used to build the map) may differ, leading to unexpected and/or unwanted results!
Examples include:
* coding for a clinical purpose vs a financial/funding purpose
* two different funding maps
{% endhint %}
## Example use cases, purposes, and considerations
Interoperability
Retrospective maps for backwards compatibility when migrating a legacy code system to a national standard code system:
* for historical data
* to define code systems for use based on existing legacy code systems
{% hint style="warning" %}
**Considerations**
What data do you need to map?
* Only codes/terms that exist within the historical data collection
Maintenance
* Is this a single-use/snapshot map?
{% endhint %}
Prospective maps for continuing use to transform codes from a local code system to a national standard code system.
{% hint style="warning" %}
**Considerations**
What data do you need to map?
* All valid codes from the source code system, as you cannot predict what is required by users
Maintenance
* Continuing use means continuous maintenance is required
* Consider how dynamic these code systems are to understand the maintenance burden/costs
* Is there an option to migrate in the longer term to phase out the maintenance burden?
* Who needs to carry the maintenance burden? Is the implementer of the local code system or a national body?
{% endhint %}
Integration
Maps to allow comparison of different code sets by converting codes to a single code set: the collection of data sets from different implementations of the same system that use different terminologies.
{% hint style="warning" %}
**Considerations**
Which code system is your target code system?
What will get the best results?
Are the code systems compatible?
* how different (content, structure, semantics) are the code systems, and can you get a sensible map?
* what rules and conventions need to be applied to get the best match?
{% endhint %}
Categorising or reporting
Maps for assigning codes to higher-level groups for
* reporting - KPIs, priority health areas
* funding – billing, access, service planning
* cohort identification, research, analytics – epidemiology, surveillance
* safety/efficacy audits
* workflow or CDS – linking a patient journey
{% hint style="warning" %}
**Considerations**
Rules of the map
* Mutual exclusivity (can one source code map to more than one target code?)
* Does every source code require at least one map?
Maintenance
* Consider how dynamic these code systems are to understand the maintenance burden/costs
{% endhint %}
Provide Feedback
---
# 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.2-defining-use-case-and-purpose.md?ask=&goal=
```
`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.