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 some instances where mapping is not suitable or useful and may be more problematic.

When considering the creation of a map, the first step is to understand the data which needs to be transformed or migrated and the requirements for use of that data.

Key questions to address include:

• 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?
• 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 is the data quality and compatibility of the source and target code systems?
• What are the expert resource requirements and costs of creating, quality assuring and maintaining the maps over some period of time?

Careful consideration should be given to care settings, worker skills sets and their existing workflow, available infrastructure or tooling. Importantly, the business requirements for a map might mean that different map types or map directions should be preferred.

1. For instance, in care settings where there are trained clinical coders, they will 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 hand written notes and narrative the coders have always had available in patient records.
   • In this scenario, the clinical coders are the map authors, constructing meaningful transformation of SNOMED CT to ICD as part of their normal/usual workflow - prospectively. It may be more advantageous, and provide more accurate and comparable statistical data if the clinical coder workforce, rather than a map, is utilised to produce ICD or DRG  data outcomes.  This is a choice-point that individual jurisdictions can evaluate for themselves, taking workforce, resourcing and budgets into account.
2. 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.  
   • 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 ONLY mapping 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?
     • If yes, then consider map direction; it might be more feasible to map backward from SNOMED CT to the existing code set to provide a retrospective map for existing patient data collections
     • If yes, then perhaps use the existing code set and frequency of use (in data) measures to merely scope a new SNOMED CT reference set and then make a retrospective map to join historical data when that becomes necessary for trend analyses.

As well as the above considerations the following points should be considered before choosing to map

• 4.1 Clinical risk
• 4.2 Maintenance burden
• 4.3 Compatibility of source and target code systems
• 4.4 Data quality
• 4.5 Intended or unintended consequences of mapping