Overview

Documents the process for updating a map project destination terminology during an editing cycle when it is updated.

Details

Consider the example of the SNOMEDCT to ICD10 mapping project.  There is an infrequent and at most annual update to ICD10. The map projects and terminology content are "version aware", meaning there is a terminologyVersion field that must be maintained. Depending on choices made regarding this value, there are different strategies for ensuring the mapping tool has access to the intended version of the destination terminology.

Maintaining terminologyVersion

There are two strategies for using terminology version that are useful for different use cases.

• Use a real terminology version reflecting the actual release.
  • For example, for ICD10, this would be something like "2010" or "2015"
  • This is ideal when the maps are released on a different cycle than the destination terminology and it is desirable to have both the previous and current versions of the destination terminology loaded so that comparisons between them can be used to drive editing (e.g. codes with new siblings).
  • This is also ideal when multiple mapping projects are mapping to different versions of the same target terminology within the same environment.
  • This strategy is used for "SNOMEDCT to XXX" mappings.
• Use a meta-value that does not need to be changed from release to release
  • For example, we could use the value "latest"
  • This is ideal when there is only one version of the the destination terminology needed, the maps are released on a different cycle than the destination terminology, and it is not important or necessary to compare changes in the target terminology to drive re-editing of map records.
    
    

Updating the target terminology content and version

There are two strategies here.

• Remove the old version and import the new version
  • This involves using the terminology remover to remove the prior version of the terminology and then completely reloading the release version using the corresponding terminology loader.
  • This strategy works with either choice for "maintaining terminologyVersion" and guarantees the correctness of the terminology representation.
• Simply import the new version.
  
  • This strategy only works well if using the style of "maintaining terminologyVersion" that involves having multiple simultaneous versions.
  • This strategy is used for "SNOMEDCT to XXX" mappings.

Updating the map project target terminology version

When using an actual terminology version value, when a new version of the terminology is loaded, the map project metadata must be updated to reflect the change in "destination terminology version".  This can be done by an admin in the map project metadata editing tools.

When using a terminology version value of "latest", it is presumed that the map project metadata is already set to this and does not require updating.

Identifying cases for re-editing maps on destination terminology change

When updating to a new version of the destination terminology, such as ICD10 2010 to ICD10 2015, it is desirable to identify areas in which the terminology has changed in order to re-edit maps with those map targets.  Some conditions of interest in this regard may include:

• Retired codes
• Codes with new or different preferred names
• Codes with additional inclusions/exclusions or other "descriptions"
• Codes with new siblings in the hierarchy (or new children)

This is really a terminology-specific determination and a specification for how to identify the types of change that would be desirable to drive re-editing of mappings should be developed on a case-by-case basis.

Once algorithms are determined, the QA Check mechanism can be used to identify maps with target codes that warrant re-editing due to changes.  For example, the following query is used to identify concepts mapped to codes that have new siblings in the updated destination terminology.

select distinct 'all' value, conceptId itemId, conceptName itemName
from map_records a, map_entries me,
(select a.terminologyId self, b.terminologyId sib
from tree_positions a, tree_positions b
where a.terminology = ':DESTINATION_TERMINOLOGY:'
   and a.terminologyVersion = ':DESTINATION_TERMINOLOGY_VERSION:'
   and b.terminology = a.terminology
   and b.terminologyVersion = a.terminologyVersion 
   and a.ancestorPath = b.ancestorPath
   and a.terminologyId != b.terminologyId) b
where a.mapProjectId = :MAP_PROJECT_ID:
and a.id = me.mapRecord_id
and me.targetId=b.self and NOT EXISTS
(select *
from tree_positions c, tree_positions d
where c.terminology = ':DESTINATION_TERMINOLOGY:'
   and c.terminologyVersion = ':PREVIOUS_DESTINATION_TERMINOLOGY_VERSION:'
   and d.terminology = c.terminology
   and d.terminologyVersion = c.terminologyVersion 
   and c.ancestorPath = d.ancestorPath
   and c.terminologyId != d.terminologyId
   and b.self = c.terminologyId and b.sib = d.terminologyId);

Review hardcoded information in terminology-specific handlers

In some cases, some content (such as specific IDs from the index file) may be involved in the identify/modify/validate routines and should be revisited to see if the lists are comprehensive and complete.   e.g. the ICD10 project specfic handler method "getIcd10ExternalCauseCodes()".

Updating Concept/Target Names

Once everything is updated, use the Concept and Target Name Updater to update the target name of map entries. 

References/Links

• Terminology Loader and Remover