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:
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?
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?
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.
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.
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?
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
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.
Last updated