> 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/evaluating-mapping-as-a-solution/4-evaluating-mapping-as-a-solution.md). # Feasibility and implications of mapping Mapping often appears to be the simplest or quickest solution for transforming data from one code system to another; however, it is important for developers and users of maps to be aware of the implications of developing and using a map. While mapping can solve some problems, there are instances where it is not suitable or useful and may be more problematic. When creating a map, the first step is to understand the data to be transformed or migrated and the requirements for its use. Key questions to address include: {% columns %} {% column %} Are the business requirements well understood? Are there other options for meeting the business requirements without mapping? What are the potential risks arising from using the maps? What is the data quality and compatibility of the source and target code systems? {% endcolumn %} {% column %} To what extent can the source data contribute value to the target data? Will it limit the utility of data being collected in the future? How should this be mitigated? What are the expert resource requirements and costs of creating, quality assuring and **maintaining** the maps over a period of time? {% endcolumn %} {% endcolumns %} Careful consideration should be given to care settings, workers' skill sets and their existing workflows, and available infrastructure or tooling. Importantly, the business requirements for a map might mean that different map types or map directions should be preferred. For instance, in care settings with trained clinical coders, they routinely abstract and transform SNOMED CT concepts and encode them in ICD-10 (or similar); they are trained to do this in context to meet operational and business needs, including funding models. Here, SNOMED CT replaces only the clinicians' handwritten notes and narrative, which the coders have always had available in patient records. {% hint style="info" %} In this scenario, the clinical coders **are** the map authors, constructing a meaningful transformation of SNOMED CT to ICD as part of their normal/usual workflow - prospectively. It may be more advantageous and provide more accurate, comparable statistical data to utilize the clinical coding workforce, rather than a map, to produce ICD or DRG data. This is a point of choice that individual jurisdictions can evaluate for themselves, taking workforce, resourcing, and budgets into account. {% endhint %} If we are trying to update an existing code set and migrate to a standard SNOMED CT reference set going forward, there are a number of considerations that jurisdictions might consider, such as: * how formal, widespread and entrenched is the existing code set? * how well is it working? How well is it documented? * is the existing code set constructed to serve a single (CIS) delivery system, perhaps with search or navigation functionality that is unnecessary for a SNOMED CT implementation? * how much of the existing code set has ever been used and appears in a longitudinal Patient data collection? * is it worth mapping only the terms that have ever been used in patient records? If some terms have never been used, does this mean users found them unhelpful or unnecessary? {% hint style="success" %} If yes, then consider map direction; it might be more feasible to map backwards from SNOMED CT to the existing code set to provide a retrospective map for existing patient data collections {% endhint %} {% hint style="success" %} If yes, perhaps use the existing code set and frequency-of-use (in data) measures to scope a new SNOMED CT reference set, and then create a retrospective map to join historical data when that becomes necessary for trend analyses. {% 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/evaluating-mapping-as-a-solution/4-evaluating-mapping-as-a-solution.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.