Mapping Guide

Search

SNOMED CT Document Library

    Loading...

Page tree

  

The method of creating a map, the rules and processes associated are 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 documented clearly for reference during development and for implementations. The map's use case and purpose have flow on effects through the maps 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?

Use case and purpose

  • 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

Example: The purpose of this map is to allow for Emergency Department SNOMED CT principal diagnosis codes to be mapped to the national Emergency Department National Minimum Data Set for funding.

CAUTION: Beware when reusing maps or repurposing mapped data, as even though the source and target code systems may appear the same and the healthcare setting may be the same, the purpose (and hence the rules used to build the map) may differ and can give unexpected and/or unwanted results!

Examples:

  • Coding for a clinical purpose vs a financial/funding purpose
  • Two different funding maps

Example use case, purposes and considerations

Use casePurposeConsiderations
Interoperability

Retrospective maps for backward compatibility when migrating a legacy code system to a national standard code system

  • For historical data
  • To define code systems for use based on existing legacy code systems

What data do you need to map?

  • Only codes/terms that exist within the historical data collection

Maintenance

  • Is this a single use/snapshot map?
Interoperability

Prospective maps for continuing use to transform codes from a local code system to a national standard code system

What data do you need to map?

  • All valid codes from the source code system as you cannot predict what is required by users

Maintenance

  • Continuing use means continuous maintenance is required
  • Consider how dynamic these code systems are to understand maintenance burden/costs
  • Is there an option to migrate in the longer term to phase out maintenance burden?
  • Who needs to carry the maintenance burden? The implementer of the local code system or a national body?
Integration

Maps to allow the comparison of different code sets by converting codes to a single code set: collection of data sets from different implementations of the same system which has different terminologies

Which code system is your target code system? What will get the best results?

Are the code systems compatible?

  • How different (content, structure, semantics) are the code systems and can you get a sensible map?
  • What rules and conventions need to be applied to get a best match?
Categorising or reporting

Maps for assigning codes to higher level groups for

  • reporting - KPIs, priority health areas
  • funding – billing, access, service planning
  • cohort identification, research, analytics – epidemiology, surveillance
  • safety/efficacy audits
  • workflow or CDS – linking a patient journey,

Rules of the map

  • Mutual exclusivity (can 1 source code map to more than 1 target code?)
  • Does every source code require at least 1 map?

Maintenance

  • Consider how dynamic these code systems are to understand maintenance burden/costs
Feedback
  • No labels