Skip to end of metadata
Go to start of metadata

New guide in development

The namespace-identifier identifies the Extension in which the component originated. However, within specified limits and with agreement between the responsible organizations, the maintenance responsibility may be reassigned without issuing a new Identifier. Therefore, the namespace-identifier may not identify the Extension in which a component is now maintained.

The permitted reassignments of responsibility are limited to ensure that the organization responsible for maintaining a component can be determined. Thus the end result of any transfer of responsibility must result in the component being maintained by the organization responsible for one of the following:

The values of the of the partition-identifier which previously indicated that a component was part of an Extension, continue to indicate that the SCTID contains a namespace-identifier. However, some components with a namespace-identifier may now be maintained as part of the International Edition. Therefore, for clarity, the definition of partition-identifier indicates whether the SCTID conforms to the long format (with a namespace-identifier) or the short format (without a namespace-identifier). Only SNOMED International can issue short format SCTID (without a namespace), whereas an Extension owner must issue a long format SCTID (including a namespace-identifier that is registered as belonging to them).

The moduleId field, introduced in Release Format 2 and held against each component, records the organization currently responsible for maintaining the component. The moduleId must refer to a module delivered by the organization maintaining the component and the namespace-identifier of this moduleId must belong to the maintaining organization .

Following the change, migration of components between Extensions would be possible without a change to their SCTID , according to the following rules:

In all other cases, the existing rules for moving components between Extensions should be used. These require a change of SCTID to occur with tracking of inactivation in the appropriate Component Inactivation Reference Set and cross-references created in the appropriate Historical Association Reference Set (or as historical relationships in Release Format 1 ).


Components that originated in the International Release must not be moved to any Extension without a change to the SCTID .

In order to make explicit which Extensions are parents of which other Extensions, concepts under the Namespace Concept may now be rearranged as a n ested hierarchy of namespaces. All namespaces at the top level of this hierarchy are considered to have as their parent the International release. The Namespace Concept for an Extension that is dependent on another Extension may be nested as a child (sub-type) of the Namespace Concept for the Extension on which it depends.


Components that originated in an Extension must not be moved to any other Extension unless the Namespace Concept associated with the target Extension is an ancestor of Namespace Concept associated with source Extension. The ancestry of Namespace Concepts is determined by the subtype hierarchy distributed as part of the International Release. Other moves between Extensions require a change of SCTID .

Guidance has been developed for producers and consumers of SCTID, to help avoid conflicts of ownership and to facilitate identification of owning organizations ( see and ).