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 Extension namespace specified by the namespace-identifier of its Identifier ;
- an Extension with a namespace-identifier that is a hierarchical ancestor of the namespace-identifier of the originating Extension ;
- the International Release .
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 .
- A component can be moved from any Extension to the International Release without a change to its SCTID .
- A component can be moved from an Extension to a parent or ancestor Extension without a change to its SCTID .
- A component can be moved from the International Release back to its originatingExtension without a change to its SCTID .
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 ).
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 ).