Mapping data from clinical records encoded using non-SNOMED CT code systems to SNOMED CT for analysis may be considered when there is a requirement to produce:
Two important characteristics of a map, which affect its ability to be used for a particular purpose, are the direction of the map, and the correlation between the source and target codes. Where the analytics use case requires SNOMED CT to be used, the direction of the map must be from the non-SNOMED CT codes to SNOMED CT codes. A map designed to move data from code system A to code system B will serve poorly (if at all) 'in reverse' if it is used to map from B to A, unless all the links are exact semantic matches.
For analytics purposes where patient safety or data accuracy is important (e.g. point of care clinical decision support or data integration), it is important that the correlation of the map is an 'exact match' (or equivalence). For other purposes (e.g. epidemiology or care service delivery planning) it may be acceptable for the SNOMED CT code to be broader than (or a supertype of) the non-SNOMED CT code. However, broad-to-narrow and narrow-to-broad maps need to be used with care.
When a non-SNOMED CT code is being mapped into SNOMED CT, and an equivalent precoordinated SNOMED CT concept does not exist, a number of options are possible, including:
For example, map "DX0162: arthritis of left knee" to a new extension concept
|Please note that this concept does not exist in the international edition of SNOMED CT, but is shown here as a hypothetical example of a concept added in a SNOMED CT extension.|
Designing and authoring maps requires expertise and appropriate resources. Large maps (e.g. tens of thousands of codes) are typically created and maintained by SNOMED International, National Release Centers, large healthcare organizations, specialist data suppliers and large system vendors. However, smaller maps may be created and maintained by smaller system suppliers, hospitals or clinics. Maps must be maintained to ensure that both the SNOMED CT content and non-SNOMED CT content remains current whenever either code system is updated.
A typical scenario requiring mapping to SNOMED CT is shown below in
. In this example, two source systems (using ICD-9 and ICD-10 respectively) are being
integrated into a data warehouse using SNOMED CT as the common 'reference terminology'
for analysis. Once this mapping is done, the same analytic techniques as used on native
SNOMED CT records may be applied (See Section
6 SNOMED CT Analytic Techniques).
Mapping from ICD classifications to SNOMED CT
Maps are represented in SNOMED CT's RF2 using a Simple map reference set, a Complex map reference set, or an Extended map reference set (depending on what additional information is required to support the implementation of the map). Code mappings are then performed by matching each non-SNOMED CT code in a patient's record with the 'mapTarget' field of the corresponding row of the map reference set, and using the SNOMED CT code found in the 'referencedComponentId'.
The UK Terminology Centre's Data Migration Workbench demonstrates some advanced uses of data migration and mapping products published by the UKTC, including Read Code Version 2 and CTV3 maps to SNOMED CT. A number of vendor products also map non-SNOMED CT codes to SNOMED CT for use in analytics, including Allscript's terminology service, Apelon's Distributed Terminology System, the Cerner Millennium Terminology (CMT) package, and Epic's electronic patient record systems.