Documents the process for updating a map project source terminology at the point between one editing cycle and the next.


Consider the example of SNOMEDCT.  There is a January/July release cycle and maps are updated to be in sync with the release cycles.  At the end of one editing cycle, the next version of SNOMED is officially released and the mapping tool should reflect the state of this release.  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 source terminology.

Maintaining terminologyVersion

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

Updating the source terminology content and version

There are two strategies here.

Updating the map project source 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 "source 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.

Computing Worfklow

Any time a terminology changes, any map projects using that as a source terminology need to have workflow recomputed. This is done using the compute workflow (see Workflow Tools).

Updating Concept/Target Names

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

Handling Changes in Delta Processing

There is one other tricky wrinkle in all this.  If an editing cycle started with a clean load of the previous release version of the terminology and was followed by a series of applications of daily builds (say each Sunday) there's a few data conditions that are not properly handled.  In particular, if data elements are changed in one daily build, and then those changes are retracted in a subsequent daily build, there is not enough information to identify and reconstruct the prior state.

Thus, it is recommended that at the end of an editing cycle, the previous release terminology be reloaded from scratch and then the final (definitive) delta applied to that.  This will yield exactly the next release and can be used as a basis for computing worfklow one last time and ensuring all in-scope concepts are mapped.