Documentation of mapping methodology and decisions made is important:

• to allow reproduction of the mapping process for updates

• as evidence of the mapping process undertaken and the rules applied for compliance assessment

A map is not necessarily static; future versions of a map may require changes to decisions or rules, which will need to be clearly defined and consistently applied.

Clear documentation will allow the correct usage of the map and allow users to identify when the meaning of the results of the map has changed

Documentation should include:

Background

SNOMED CT is a clinical terminology with global scope covering a wide range of clinical specialties and requirements. To support the implementation of SNOMED CT, there is often a need to create maps from current in-use, local and proprietary code systems to SNOMED CT. Similarly, there is often a need to create maps from SNOMED CT to classifications and reporting code systems to support reporting, billing and statistical purposes.

What is a map?

A map is a collection of associations between codes, concepts or terms in one code set (the 'source') to codes, concepts or terms in another code set (the 'target') that have the same (or similar) meanings.

Maps are developed in accordance with a documented rationale, for a given purpose and as a result there may be different maps between the same pair of code systems to meet different uses cases.

A code set can be:

• a list of codes and/or terms

• a vocabulary

• a terminology

A map is often published as a table but can also be published in RF2 as a map reference set or a FHIR ConceptMap.

Mapping is the process of defining a relationship between the source and target codes, concepts or terms.

The SNOMED CT Mapping Guide describes the best practices and guidelines for mapping between other code systems and SNOMED CT. Specialized mapping guidance designed for specific source and target code systems is available in other documents. For example, the .

The target audience of this document includes any users who are involved in the mapping process, including

• SNOMED CT National Release Centers;

• eHealth system designers and developers, including designers and developers of EHR systems, information models, data entry interfaces, storage systems, decision support systems, retrieval and analysis systems, communication standards and terminology services;

• SNOMED CT terminology developers, including concept model designers, content authors, map developers and release process managers.

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

Considerations when choosing an approach include:

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.

Mapping requires a multidisciplinary group of people to:

A wide range of expertise is required for the development of a map including:

Personnel doing the mapping (mappers) should:

• understand and be able to apply the structure, content and relationships for the source and target code systems

• understand the purpose of the map

• understand the way the map will be implemented

Ensuring the quality of a map is a critical step in the map process, often requiring validation of initial processes and adherence to best practices such as dual mappers and reviewers, conducting consensus reviews, and establishing clear map principles.

Project Scope and Planning

The foundation for any mapping QA framework rests on a clear definition and documentation:

• Clearly defining the map's purpose and use case from the outset, since a map that is fit for analytics may not be appropriate for clinical decision support or regulatory reporting.

• Defining clear source and target terminology and version baselines, because mappings can change significantly between releases.

• Carefully consider the scope of your map and set inclusion criteria, specifying whether you are targeting procedures, diagnoses, medications, or other types of clinical concepts. In some cases, specifying a sub-hierarchy may be helpful (e.g., cardiology-related disorders).

• Document the scope and criteria clearly in your project plan to maintain focus and consistency.

One way to support automatic map suggestions (e.g., using Snap2Snomed and lexical-based mapping) is by ensuring the source terms are descriptive, clear, and unambiguous:

• Avoid using acronyms, abbreviations, or jargon that may be unclear or have multiple interpretations.

• If a source term could be interpreted in multiple ways, provide additional context, such as usage examples, definitions, or notes, which can be imported as an additional column.

• Conduct a pre-map review of your source terms to identify and address any terms that may cause confusion or ambiguity.

It is essential to discuss and agree on how to deal with maps that have a relationship type other than 'exact' and maps stated as 'no map':

• Aim for exact matches wherever possible.

• Distinguish between exact, broader, and narrower matches, and be explicit about how ambiguity, unmapped concepts, and one-to-many or many-to-one relationships are handled.

• Inexact Matches: Evaluate the clinical impact, relevance, and necessity of revision. Options may include adding the meaning as a SNOMED CT extension concept, selecting the most specific supertype, or refining the source code.

• Use peer review and dual review, supported by clinical and domain expert validation.

• Establishing acceptance criteria or quality metrics, for example, accuracy thresholds, inter-reviewer agreement, or sampling approaches, is necessary. A representative sample should cover: the breadth of the target terminology; the range of clinical settings (e.g., inpatient, outpatient, and primary care); high-volume data fields; and validation against ground-truth source data, not against other coded outputs.

• Ensure provenance and auditability: who created and reviewed each map, when, and using which methodology or tools.

• Where possible, testing maps against real-world workflows or datasets is recommended to confirm fitness for purpose. Initial testing can inform updates and assist in developing custom QA checks.

• Governance and ongoing maintenance, including stakeholder feedback, are required, including monitoring for terminology updates and downstream impacts as source vocabularies evolve.

• Map projects that target structured laboratory or analyte content (such as LOINC and NPU) lend themselves more readily to automated mapping and checks than narrative classifications such as ICD-10. Assigning ICD-10 codes, in particular, is highly idiosyncratic and depends on expert judgement.

• For SNOMED CT as the target, documenting allowed attribute values based on editorial guidance and any project-specific restrictions supports consistency between reviewers and across time.

Even a dual-authored, dual-reviewed, clinically assured equivalence map may not provide a comprehensive and long-term solution in every case.

The table below shows a well-formed map.

The consequence here is that the new SNOMED CT content reflects only what was pre-existing, with no change in scope or range of clinical content, and with the features of the legacy source system maintained.

Despite investing effort in producing a well-formed map, we achieve only what we already have, with merely a change in codes/identifiers. There is no improvement in clinical utility, standardisation, interoperability with other standard SNOMED CT-enabled systems, or analytics that might exploit the logical definitions of SNOMED CT, which are not readily performed using subsumption or ECL queries.

In this scenario, the SNOMED CT map target concepts can be regarded as the minimum viable 'mapset' of concepts that will support migration or longitudinal data analyses. But to provide future utility, for integration, interoperability among and between systems and settings, and to support SNOMED CT-aware analytics, this mapset would need to be expanded to form a more comprehensive and sustainable ValueSet. Mapping is a great first step, but it is not the whole journey.

Map products that contain broader or narrower relationships may influence how data is analysed and interpreted. Reports of patient data that are formulated using such maps will likely reflect at least some of those map features.

This may result in some slippage in understanding or direct comparability between reports generated directly using the old source code set and mapped data reports, and/or between mapped data reports and reports formulated using SNOMED CT-encoded data directly. It may appear that data analyses are 'skewed' when a map product is in use. It is recommended that map performance be evaluated and compared across retrospective and prospective analyses to determine the impact of the map product.

Again, all of these consequences, intended or not, are choice points that jurisdictions and users might consider when embarking on and designing a roadmap for their mapping strategies.

Ensuring map quality is important for the successful use of SNOMED CT. It is crucial that the map's content references the concepts that represent the meaning of the source data it is to be linked to. In addition, it is important that the human interpretation of the concepts referred to aligns with the logical definition provided by SNOMED CT. Even when using maps for less patient safety-critical purposes, the quality of the map needs to be sufficient to be trusted to serve its purpose.

Stages of Quality Assurance

Reviewing a map set is important throughout the map development process; at least three types of validation should be emphasized, see illustration below.

• Design review: The overall objective of this review is to verify whether the map design meets the requirements.

• Content review: The overall objective of this review is to verify whether the selected targets are appropriately mapped to the source codes.

• Test: The overall objective of testing the map is to validate it in the context in which it will be used. Testing is conducted to ensure the map meets the needs of the stakeholders involved.

In addition to the abstract assurance of the subset in isolation, there may be a requirement for a level of testing to be undertaken in healthcare systems, and tested under the exact circumstances of intended use. This may be undertaken by releasing a technology preview targeted at specific bodies for feedback. An impact assessment and, most importantly, safety testing will need to take place upon deployment of the subset into systems, particularly where significant changes have taken place.

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).

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 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:

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.

Whenever the meaning of one code is being translated into another, there is always a potential change or loss of meaning due to the differences in the semantic structures of the source and target code systems.

If a map is used to map data collected for clinical purposes, a level of risk is introduced that can have clinical impacts.

During development

When developing a map, consideration should be given to the implementation setting in which it is intended to be used. Where a map is intended for implementation in a clinical setting, further consideration is required; it may be that mapping is deemed unsuitable.

Clinical review during the mapping process may be required to support safe clinical practice. Testing against real patient data is also recommended to evaluate the impact of mapping on data outcomes, particularly if there are concerns around clinical safety.

Prior to implementation

Before implementing a map in a clinical setting, it is important to do a risk assessment, including (but not limited to):

• Identification of all patient safety risks that arise from using the map in a clinical setting

• Perform and document a risk assessment

• Implement risk mitigation measures

• Undertake and document the risk management activities for both the mapping process and for ongoing maintenance of the map

Interoperability

For interoperability, it would be ideal for all systems in the healthcare ecosystem to implement the same terminology in the same way, and with the same information model. However, this is not realistic, as there are many systems with historical proprietary clinical systems already in existence.

In these situations, maps can be useful in different ways.

• Maps can enable systems that use different terminologies or code sets to communicate temporarily while they migrate to a common terminology. These maps will not alter the UI for data entry, but can be implemented alongside data entry to allow users to see the term mapped to their entry term, or implemented in the back end when information is being sent, received, retrieved, or reported.

• Maps can also be used to help migrate legacy code systems to standard code systems like SNOMED CT, by providing a way to translate historical terms to the new standard; this would be a one-time, one-step migration strategy

• Maps may be required to enable systems with legacy or proprietary code systems to work with knowledge resources that use standards such as SNOMED CT for decision support.

As secondary users of data, we often cannot influence how it is collected, since it is often historical or collected for a variety of use cases. Where data may be collected from different sources with different code sets and/or versions, maps that allow comparison of different code sets by converting the codes to a single SNOMED CT code set are useful.

Data collected for one purpose is often required to be used for other purposes, not just the original intention; this is data reuse and repurposing. Codes collected might need to be assigned to higher-level groups for reporting, funding, cohort identification, etc. Maps can be used to assign higher-level grouper code sets to the original code set, allowing data to be categorised and reused.

Data conformance is about ensuring the data collected meets a set of defined data quality measures. Maps to a standardised clinical terminology, such as SNOMED CT, can provide a consistent representation of data collected across disparate systems using different measures or methods. Providing accuracy, completeness and consistency to data that would otherwise not be standardised. This does not mean though that maps will transform 'dirty', or poor quality data into high quality data they potentially will add to the quality through standardisation through enhanced quality measures.

Authoring is the process of defining the relationship between concepts in the source code system and the target code systems.

Authors can assign none, one, or more target codes to a source code and assign a relationship type.

When assigning a target code, authors need to consider the map's use case and purpose, as well as the code system's structure, rules, term composition, and granularity.

Automated mapping tools

Once data has been pre-processed, automated mapping tools may be useful.

• Automated mapping is the use of computer algorithms to create mappings between code systems.

• Lexical mapping is the process of comparing and analyzing the structure of words in a clinical term to determine whether they are the same, similar, or different, and is often incorporated into automatic mapping.

Maps generated by a tool need to be checked by a map specialist. Significant care must be taken with automated mapping, as severe errors can result if not done in a controlled manner.

Automated mapping, in conjunction with human review (and manual remapping where necessary), is likely to achieve better results than automated mapping alone.

Appropriate filters or scope constraints should be applied to the tool to improve the accuracy of the automated mapping tools. A record of the tool, the scope constraint and matches should be kept to test the reproducibility of methods

Human mapping is the use of human knowledge and skill to author maps. Each map is built singularly. The process requires examination of each and every concept in the coding system. Informed judgments or decisions are made about the shared meaning of concepts. Electronic or computational tools may be used, but only in support of the work process.

There are some tools available to assist in this process. Manually mapping into tables without tooling support (e.g., spreadsheets) is time-consuming and error-prone because it requires copying and pasting from a browser into the table.

Defining firm guidelines for mappers will save time and go a long way towards ensuring higher inter-rater reliability in situations with more than one mapper. These guidelines will also be valuable for highlighting why certain target concepts were chosen over others. Editorial Guidelines are very important to map users and are a necessary step in the creation of useful, reliable, and usable maps.

Also, a map is not necessarily static; future versions of a map may require changes to decisions or rules, which need to be clearly defined and applied consistently.

Mapping cannot mitigate data quality issues.

Poor data quality

Poor-quality source data or insufficient information for the map development team to understand the source code and identify an appropriate target code will result in poor or low-quality maps, with many source codes remaining unmapped.

Also, "dirty" data, e.g., abbreviations, shorthand, use of symbols, or free-text sentences, can be expensive to process and map. "Dirty" data is difficult to process, and incorrect maps can be created if the author's true intent is unclear.

Unknown, unfamiliar or undocumented source code sets

Often, legacy code sets have existed for some time, have been developed locally, and may not be well documented. The original intent of the source code set may be vague, not well understood, or not agreed upon. There may only be informal documentation, or the documentation may have aged. Understanding both the source and target vocabularies is essential; guessing at the intended meaning of either the source or the target will result in a less robust, less safe map product.

Provide Feedback

Mapping can be a bridge between two different code systems, but the prerequisite is that the two code systems being mapped have compatible semantic domains.

The semantic meaning of a concept or code can be made up of a combination of

• the representation in the code system, e.g. the description associated with a code

• the meaning provided by its structural representation in the code system, e.g. attributes inherent in the modelling within the code system

• the context of use, e.g. the clinical information model or clinical workflow

Prior to mapping, it is important to understand these points and assess the compatibility of the two code systems. Where the two code systems do not have compatible semantic domains, it may not be possible to build a meaningful or useful map.

Maps intended for ongoing use often require a commitment of resources and tools, and so can be quite costly to maintain.

Maintenance may be required whenever there is a change to the source or target code sets. Some terminologies are more dynamic than others, with a faster update cycle, which can increase the maintenance burden - for example, Medication releases can be monthly, whereas some classifications have an annual cycle. The more dynamic the code sets, the greater the maintenance burden.

During maintenance, the following should be considered:

• for new source codes, new map rows need to be created

• for retired/removed source codes, the map rows need to be removed

• for retired/removed target codes of maps, the map rows need to be updated to find suitable targets

• for non-equivalent maps, the map targets should be re-evaluated to check if there is a more suitable target

Maintenance can be non-trivial, and consideration should be given before beginning the mapping process to determine whether it is worthwhile to develop, implement, and maintain a map or whether a different implementation pathway is more appropriate.

Maps developed for ongoing use may require maintenance.

When developing or evaluating a change management process, it is important to consider various factors. Some of these factors are introduced in the table below.

These guidelines were developed to assist map developers in producing a map that benefits all users and ensures that downstream users of data produced by the map can use the information consistently and reliably.

A robust mapping methodology will assist in producing quality maps that are usable, reproducible and understandable.

This playlist brings together all videos on Mapping SNOMED CT to different code systems from the SNOMED International Implementation Course. The videos introduce key concepts, practical implementation considerations, and real-world examples to help you understand the fundamentals of maps to and from SNOMED CT.

Open playlist on YouTube:

👉 Click here to view the full playlist on YouTube

How to navigate the playlist in GitBook

When a YouTube playlist is embedded in GitBook, only one video is shown on the page at a time, but all playlist videos are still available.

• Use the forward () and back () arrows on the video player to move between videos in the playlist

To get the best mapping results, it's important to prepare your data prior to beginning the mapping process.

Data in the real world is rarely clean and tidy.

Data may have:

• an underlying data structure that could be represented with indents

• white space (leading, trailing)

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?

• 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

Prior to building the map, it’s important to define the scope, processes, and mapping rules to ensure consistency among all personnel involved. These should be documented clearly and updated frequently as required.

The scope of a map is tightly bound to the map's use case and purpose. Once the use case and purpose have been defined, the scope of the map's source and target code systems can be determined.

When defining the scope of the source and target code systems of the map, consider the following:

Defining the map scope

SNOMED CT contains a number of hierarchies, each representing different types of concepts. When mapping to SNOMED CT, it's important to understand the scope of the source content that you are mapping so you can define the SNOMED CT scope appropriately. When mapping to SNOMED CT, you should constrain the target scope to a specific hierarchy, subhierarchy or subset of SNOMED CT. This will improve the accuracy of any automated mapping tools you may be using and reduce the risk of errors caused by users developing the map.

Example scopes:

Mapping process

During the map process, once the target scope has been defined to the appropriate hierarchy, subhierarchy or subset of SNOMED CT, authors and reviewers can then search for an appropriate code to map to.

When selecting a code, the user must review the concept’s Fully Specified Name and defining relationships to understand the intended meaning of each concept, and use the use case and rules of the map (such as requirements for equivalence, allowance for 1:many maps, context of implementation, etc) to determine what is an appropriate match.

An example process a user may conduct is:

• search SNOMED CT for a matching concept

• find an appropriate candidate concept

• assign it to the source code with a relationship type

There may be instances where there is more than one candidate concept; depending on the map's rules, it may be appropriate to select more than one. It may also be appropriate to select the most general supertype concept that completely matches the required semantics.

Where there are no appropriate SNOMED CT concepts available, it may be appropriate to

• Create or request an appropriate pre-coordinated concept in an extension to be used in the map

• Use a SNOMED CT postcoordinated expression that captures the requirements, if the use case of the map can support this

• Define the map as having no map target

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:

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.

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?

The consistent view is that AI should be treated as an additional "mapper" rather than a replacement for QA processes. The same quality principles still apply, but AI introduces specific new considerations.

AI as an Additional Mapper

• AI assistance is useful for speeding up the initial draft of maps.

• A human-in-the-loop remains essential when quality-assuring AI-generated maps.

• In SNOMED International projects like SNOMED-ICD-10 and MedDRA, QA remains fundamentally manual, and AI assistance has not yet been incorporated into these workflows.

Experience with AI-generated maps has shown mixed quality:

• Issues observed include hallucinated concepts or SCTIDs that do not match their descriptions.

• Where the code was plausible, it was not always as precise as it could have been.

• Better prompting may improve results, but verification remains critical.

When AI is involved, the QA framework should explicitly include:

• Confidence scoring and risk-based review, with stronger review requirements for low-confidence or high-impact maps.

• Ensuring reproducibility, since AI-generated outputs can vary over time and across models.

• Clearly distinguishing between AI-suggested maps and human-approved maps throughout the dataset.

The level of quality assurance required depends on the map's practical use case.

There are a number of methods that can be used to validate the accuracy of the map's content.

Dual/multiple user independent mapping

Dual independent mapping is often considered the "gold standard" approach and should be used when a high-quality map is required.

In this approach, each source code is independently mapped by 2 (or more) authors, and the results are then compared. When the authors agree on a mapping, it is accepted. If there is a conflict, the authors have a conflict resolution process to reach an agreement on the correct mapping.

An agreement is achieved for a given source code when all selected targets (or no map) and their respective relationship types are the same among the mapping authors.

The conflict resolution process may involve a workshop between the authors or the use of an adjudicator or subject-matter expert to make a decision.

Full review process

Reviewing is the use of human knowledge and skill to review maps.

Each and every map row is reviewed singly and individually. It is preferred that users conducting the review are not involved in the map's authoring to ensure unbiased validation. Due to resourcing constraints, this is not always possible; in such cases, it is recommended that users conducting the reviews not review their own mapping work.

In this approach, a sample set is selected from the whole map. The sample set is then reviewed. Like the full review process, it is preferred that users performing the review are not involved in authoring of the map to ensure an unbiased validation, due to resourcing constraints, this is not always possible, and in these cases, it is recommended that users performing the reviews do not review their own authoring work.

If taking a sampling review approach, care should be taken when selecting the sample set and acceptable error rate, depending on the map's risk rating. This approach may not be suitable for most maps, as it does not necessarily validate the entire map, but it may be more suitable for ongoing map maintenance.

The SNOMED CT Mapping Guide describes the best practice and guidelines for mapping between other code systems and SNOMED CT. Specialized mapping guidance designed for specific source and target code systems are available in other documents. For example, the Specifications.

For a list of available SNOMED CT mapping tool, please visit the Mapping Tools page of the SNOMED CT Implementation Support Portal.

Provide Feedback